SharePoint Experts, Information Architects, Expert Witness

We provide consulting in a broad array of business and technology from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. Specialists in Microsoft, we are a premier provider of SharePoint Expertise (including 2016 and Office 365). We also provide Expert Witness/Legal Expert in eDiscovery, source discovery, patent infringement, piracy and more! We also have established SICG DLDS s.a. - our counterpart in Costa Rica that specializes in water systems (http://www.crwatersolutions.com) - Contact me direct: david_sterling@sterling-consulting.com or call 704-873-8846 x704.

Search This Blog

Wednesday, March 23, 2011

SharePoint 2013 Slow to render pages and the SharePoint Cache (applies to 2010 too)

You may notice that after some time running, SharePoint appears to 'slow down' even if using something like the SPWakeup service.

Unfortunately, the Health Checker won't tell you about it but the System Application Event Log does. If you are running slow, check this log and usually, SharePoint will start displaying an error regarding the SharePoint Cache. 

The error states that the SharePoint Cache is not working properly due to the Super Reader account being set to LOCAL SERVICE - the issue of course being that the account does not have access to the SharePoint database. A rarity, SharePoint actually tells you how to fix the problem however, there's not much information about what account to use.

To configure the account use the following command 'stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue account -url webappurl'. It should be configured to be an account that has Read access to the SharePoint databases.

In addition, there is ANOTHER account that needs to be set too; this account is the portalsuperuseraccount.

So for the portalsuperREADERaccount, it turns out, two additional accounts should be created - one for the Super User and the other for the Super Reader. These are simply domain user accounts and should be named to fit the environment (i.e. SPProd_SuperReader).

Once an application has been created, it is necessary to assign these accounts through both Central Administration (the UI) and using PowerShell (the SharePoint 2013/2010 Management Shell). 

First, in Central Administration, go to Application Management > Manage Web Applications. Click on the web application then click the User Policies icon in the ribbon. Add the two accounts:

  • Super User - Full Control
  • Super Reader - Full Read

BTW: While you are at it, make sure the Search Service account has Full Control and the Content Access account has Full Read. 


After saving the changes, it is necessary to check the list of accounts for the USER NAME listed, NOT the Display Name - in 2010, there was NT and Claims, in 2013 there is only claims. Claims User Names includes the 'provider' for authentication (different between NT, FBA, etc.):

NT: domain\user
Claims: i:0.w|domain\user 

So in the list, the User Name would be something like i:0.w|SPSuperUser.

The second step is to open the SharePoint Management Shell using Run as administrator. Use notepad to modify this script and paste it in:

$wa = Get-SPWebApplication -Identity "<WebApplication>"
$wa.Properties["portalsuperuseraccount"] = "<SuperUser>"
$wa.Properties["portalsuperreaderaccount"] = "<SuperReader>"

$wa.Update()

Where WebApplication = URL and SuperUser/SuperReader the accounts - for example in a Claims environment - standard for 2013:

$wa = Get-SPWebApplication -Identity "http://SPSite.myintranet.com"
$wa.Properties["portalsuperuseraccount"] = "i:0#.w|spdomain\SPSuperUser"
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|spdomain\SPuperReader"
$wa.Update()

Or the old way (NT) for 2010:

$wa = Get-SPWebApplication -Identity "http://SPSite.myintranet.com"
$wa.Properties["portalsuperuseraccount"] = "spdomain\SPSuperUser"
$wa.Properties["portalsuperreaderaccount"] = "spdomain\SPuperReader"
$wa.Update()

Lastly, run:

iisreset /noforce

If you are running multiple servers, you have to run IISReset on all of them (NOT the STSADM command).

After you've done this, navigate to the site to be sure it still opens up. 

If there is a problem opening the site afterwards, it means that the accounts were either a) not added to the web application or b) were specified incorrectly. In a pinch, you can change the accounts (both super user and super reader) to the SharePoint Farm account until you determine what is wrong.

SharePoint State Service (2013 and 2010)

When setting up SharePoint, it is necessary to start up the State Service for SharePoint to work correctly. You'll see this specifically in SharePoint 2013 Health Analyzer - it will indicate that InfoPath forms won't work because no State Service has been established.

Fixing this is done using the SharePoint Management PowerShell using the following script:

PS C:\users\SPFarmAcct> $theServiceApp = New-SPStateServiceApplication -Name “State Service”

Where "State Service" is the name of the service - usually State Service but doesn't have to be.

IF YOU RECEIVE “The Specified Name is not unique” you can skip next step and simply exit (it means the service is already running). If not however, you have to create the State Service Database and associate it with a service application:

PS C:\users\SPFarmAcct> New-SPStateServiceDatabase -Name ”StateServiceDatabase” -ServiceApplication $theServiceApp

Where "StateServiceDatabase" is the name you want to use (be sure to use any standards in naming if you have them - and you should!).

Once the database has been created, you need to create the State Service Application Proxy and associate it with the service application:

PS C:\users\SPFarmAcct> New-SPStateServiceApplicationProxy -Name ”State Service” -ServiceApplication $theServiceApp –DefaultProxyGroup


Where "State Service" is the name of the service (must match the one you used on the first command).



SharePoint Usage and Health Data Collection Proxy stopped

If you've been working with SharePoint 2010 and have had some troubles with the Usage Proxy Service not running, it turns out it is a common problem. Like many, I'd searched high and low for the answer and finally came across the 'right' answer from Jeremy (no last name) in the SharePoint Commander blog.

You can determine if you have this problem by opening the Service Applications (Central Administration > Application Management > Manage Service Applications) - under the Web Analytics service, you see the Usage and Health Data Collection Proxy as 'Stopped'. Apparently another 'bug' in 2010, this is because the service is not completely provisioned when created. To fix the best method is via the SharePoint PowerShell.

Open the PowerShell then enter (italised):

PS C:\users\SPFarmAcct > Get-SPServiceApplicationProxy

This will return a list of all of the Service Proxies inlcuding the Display Name, Type Name and Id (a GUID value) - locate the Usage and Health proxy in the list and copy the Id next to it (usually the last item).

Return to the PowerShell and enter:

PS C:\users\SPFarmAcct > $UsageProxy = Get-SPServiceApplicationProxy | where {$_.ID -eq "ID you copied"}
PS C:\users\SPFarmAcct > $UsageProxy.Provision()

When you return to the Service Applications page, refresh it and the proxy should be running!

Saturday, March 12, 2011

The Importance Of Governance

We used to see this in the old days – can’t document the software because we have to write it first! And of course, the documentation never gets done. In our new development environment with products like SharePoint, the dynamic has changed – but not much.
The ‘buzzword’ here is Governance – best described as “setting the rules” before you deploy. Unfortunately, it seems folks don’t understand the importance of this and like the old developers figure “we’ll do that after we release” – they make the release date but trouble begins almost immediately. Time and time I again, I get called in because their sites, content and security are all over the map – whatever was determined as the starting Information Architecture is usually not recognizable; most often, rebuild is the only option.
So what can you do? When you start looking at a new deployment, don’t skimp on what you need: 1) Establish a good information architecture and stick to it; it can be adjusted over time but if it keeps changing, users will be confused and use will drop off. 2) Develop planning and a team for Governance and actually do it – create the team you need to include stakeholders, techs and end users. If you don’t know how, get help – don’t wing it. With the team, build the actual plan – don’t worry about being too broad (that’s not possible) but make sure it is workable – don’t create rules that will be impossible to follow. 3) Don’t deploy like you have a gun to your head – we all hate to miss dates but if your Governance planning is adequate, you shouldn’t miss the date. That said don’t kill yourself to try to make an unrealistic date as you will make mistakes and overlook things. I usually set the target 2 weeks before it is really due to give some breathing room; alternately I like to deploy quietly, make sure it is working, then do the big release.
Once out there, Governance does not go away – in fact, the team should meet regularly and discuss enabling new options, view 3rd party tools, etc. as well review the current state of the system – are you following the IA? Adjustments needed? Any complaints from users? This effort may seem like a bother but it will ensure a return on the investment.

Saturday, March 5, 2011

Using DevExpress ASPxMenu control in SharePoint 2010

I am sure some of you have used this control either in ASP.NET or using SharePoint 2007. I recently implemented this in SharePoint 2010 to create a custom navigation bar for my client. In general, the control works as designed except for the 'boundaries' of the page in 2010. This apparently is due to the base 503 compliance for the v4.master.

When I implemented at first, I found the navigation would drop just below the browser - this means that the scroll itself would drop below view causing the page to veritically scroll. I fixed this by adding:

Menu.SubMenuStyle.Paddings.PaddingBottom = System.Web.UI.WebControls.Unit.Pixel(10);

MenuItem.SubMenuStyle.Paddings.PaddingBottom = System.Web.UI.WebControls.Unit.Pixel(10);

to every menu item created. This corrected the primary navigation items and the scroll appears as normal.

Alas, that was not the only problem - the flyout submenus have the same settings - adding the padding 'almost' fixed the bottom of the menu, but the top of the menu is hidden behind the "Site Actions" Div in the master page. After much scratching and searching, I was able to get just what I wanted by simply adding a Span of my own around the control in the master page as follows:

<span style="z-index:1;"><control here ></span>

The key fix is the Z-Index setting - this causes the control to be rendered last, therefore on top of the page! Works perfectly now and the menu goes 7 levels deep! Note that embedding the span in the control will not work; it must be on the page.

UPDATE FROM DEVEXPRESS:

The SharePoint Master page for SP2010 is the v4.master which has a DOCTYPE of "Strict"; this is on their 'to do' list to enable - at present, they recommend using "Transitional". I have not completely tested this in SharePoint yet but unless I see something, follow their recommendation.