How many items are in my FAST Search index?

Even though the vast majority of FAST Search administration options are governed via Powershell cmdlets, there is a quick way to determine the total number of items in an index without logging onto a FAST Search for SharePoint server.

Simply open any SharePoint site which is leveraging ‘FAST’, and type ‘#’

And total items are now returned!

Be aware though, this search option is ONLY available via FAST and will not work in native SharePoint 2010 search.


Someone has accidentally deleted my Site Collection!

It’s Christmas, the party season is in full swing and people with hangovers (or those still drunk) should not be touching SharePoint……

So when you receive the ‘please help me, I’ve slipped on a mince pie and accidentally deleted a site collection’, Powershell is your Secret Santa!


Take a note of the ‘Site ID’

Get-SPDeletedSite | where{$_.SiteId -eq “c2353156-4a07-4998-a95a-b962b2ceebf5”} | Restore-SPDeletedSite

If the ‘Get-SPDeletedSite’ cmdlet doesn’t work for you, it is probably because you are missing this feature which was made available in SP2010 SP1.

Check your SharePoint Server time skew

Following the deployment of a number of updated .wsp files across a four-server SharePoint 2010 Farm (two Web Servers), I noticed some inconsistencies with the custom controls which leverage these solutions.

Each error, in the form of a correlation ID, was linked to the following exception within the ULS:

An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. —> System.ServiceModel.FaultException: An error occurred when verifying security for the message

But, not everyone was witnessing these errors, infact it was only a subset of users. So why the inconsistency?

Using my local DNS hosts files, I was able to pinpoint which server was proving to be problematic as this allowed me to bypass the load-balanced address.

The error message is created when WCF is unable to verify the security of the message that was forwarded to the service, and this can be applicable to the server time skew not being in sync.

The server in question was indeed 8 minutes out (yes, that’s another story), but changing the time to its correct setting and reactivating the solutions did the trick.

So, even if your solutions appear to have been deployed correctly and Central Admin is not reporting anything to the contrary, check your server time skew if you experience inconsistencies.

Redirecting User Profile SP ‘Job Titles’ to MMD Term Set

I recently received a call from one of our SharePoint Information Architects who was somewhat puzzled with what they were witnessing within the available ‘Enterprise Keywords’. In addition to a long list of legitimate Keywords which had been made available by virtue of ‘Tagging’, there were thousands of entries which appeared to be linked to the Active Directory attribute ‘Job Titles’. In some cases, these job titles could have been leveraged as useful metadata, but in our case, this was only causing confusion…..and a bit of a mess!

After a little bit of digging, I discovered that, by default, the User Profile ‘SPS-JobTitle’ property is written directly to ‘Keywords’ when a Profile Import from AD takes place, unless you have performed some manual, remapping steps. (Er, yes, this is an out-of-the-box setting and yes, I can’t fathom the logic either!) So, how does this setting manifest itself?

Open Central Administration > Manage Service Applications > User Profile Service Application > People > Manage User Properties

Scroll down to the ‘Job Title’ Property Name and open the ‘Properties’:

As you can see, the ‘Configure a Term Set to be used for this property’ is highlighted, but the ‘Pick a Term Set for this property is left blank. And, as all of these values go directly into ‘Keywords’ and no Term Set is selected, they are set to the SharePoint system default.

So, what are out options, and how do you remove all of the Job-Title properties from Keywords?

Firstly, our approach was to create a ‘never to be used’ Term Set and map this to the property. So, to do this, I go into MMD and create this new Term Set:

Also, remember to uncheck the item ‘Available for Tagging’ to ensure these items don’t appear within your new Term Set when a Full Import from the User Profile Service takes place:

Now, you can go back into the ‘Job-Title’ property and remap accordingly:

Unfortunately, if you have already run a User Profile import before remapping ‘Job-Title’ and therefore have a mountain of unwanted Keywords items you’ll have to either delete them manually (er, that will be fun), write some fancy Powershell, or recreate your Managed MetaData Service. (and just hope the ‘legitimate Keywords are not missed).

SharePoint throwing out HTTP 403 errors

I was recently working within a SharePoint 2010 Intranet environment where there was widespread use of the ‘Content Query Web Part’ across multiple site collections. And to facilitate and enhance the performance of the CQWP, the SharePoint ‘Object Cache’ model was introduced.

The CQWP leverages cross-list query caching to improve its response time and efficiency as no round-trip call to SQL is required and by default, two OOTB system accounts are used to cache queries. As a best practice, the recommended approach is to run these two accounts (Super User & Super Reader) under the context of a domain user account and this policy was adhered. (so far, so good)

However, these two domain accounts were configured to run as SharePoint ‘Managed Accounts’ (not at all necessary), and recently, to comply with a security password policy, their passwords were changed (by SharePoint). No visibility was required to their new passwords, but somehow (and more like someone), in their wisdom decided to remove both accounts from the User Policy of the Web Application which hosts the Intranet platform. The end result, a number of http 403 errors when users tried to edit any SharePoint list items:

The http 403 wasn’t helpful in the slightest, although what we found in the ULS provided us with a good troubleshooting starting point……

/home/department/management: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)), stack trace:    at Microsoft.SharePoint.Library.SPRequest.GetAclForCurrentWeb(String bstrWebUrl, Boolean fRequirePermissionCheck, Object& pvarRawAcl, UInt64& lAnonymousMask)     at Microsoft.SharePoint.SPReusableAcl..ctor(SPWeb web, Boolean requirePermissionCheck)     at Microsoft.SharePoint.SPWeb.GetReusableAcl(Boolean requirePermissionCheck)     at Microsoft.SharePoint.Publishing.AclCache.AddAclIfNecessary(Guid scopeId, SPSecurableObject o)     at Microsoft.SharePoint.Publishing.CachedArea..ctor(PublishingWeb area, String id, String parentId, CachedUserResource title, String url, CachedUserR…    2866034f-1c05-4f35-bac2-655847b2ebbd

Once we added Object Cache Super Users back to the policy of the Web Application, all of the list items were not responding and the panic was over. Now the witch-hunt could begin….

Reporting Services is sleeping…and won’t wake up

I experienced an issue recently where, after extended periods of inactivity, our SharePoint 2010 Reporting Services (SQL 2012 RTM) environment would essentially ‘go to sleep’ and was showing no signs of waking up. Each morning, following an overnight ‘quiet period’ my users would be on the phone complaining that their Reports weren’t functioning and the error message they received was as a generic one. Under the SharePoint hood, this is what we were witnessing in the ULS:

  • Server Reporting Services     Report Server Catalog             0000    Unexpected    Throwing Microsoft.ReportingServices.Diagnostics.Utilities.SharePointException: , Microsoft.ReportingServices.Diagnostics.Utilities.SharePointException: Report Server has encountered a SharePoint error. —> System.Runtime.InteropServices.COMException (0x800703FA): Retrieving the COM class factory for component with CLSID {BDEADF26-C265-11D0-BCED-00A0C90AB50F} failed due to the following error: 800703fa.     at Microsoft.SharePoint.Library.SPRequest..ctor()     at Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(SPSite site, String name, Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous)     at Microsoft.SharePoint.SPRequestManager.GetContextRequest(SPRequestAuthenticationMod…    0dedb9f0-be02-4297-b334-2594a9681274

    As a workaround while this was investigated, I was using Windows Task scheduler to action a restart of SSRS Service Application at regular intervals overnight:

    Stop-SPServiceInstance -Identity d8f38b2d-9588-4e83-8031-8a6ed33559ed -Confirm:$false

    Start-Sleep -s 180

    Start-SPServiceInstance -Identity d8f38b2d-9588-4e83-8031-8a6ed33559ed

    The SSRS layer had recently been upgraded from SQL 2008R2 to SQL 2012 and thus, the application was now being leveraged as a SharePoint Service Application. And one key change was the fact that the SSRS Application was now running within its own IIS App Pool under a dedicated domain service account. And it was a setting in IIS which was proving to be the root of the problems.

    The Application Pool(s) running SSRS need to have the ‘Load User Profile’ setting set to True

    IIS will not load the domain user profile, although a user profile has to be created to store temp data in either the profile directory or registry hive. By default, if you were using ‘Network Service’, this would always be available as it was created by the system, but in this instance we’re using a domain service account. Only the OOTB standard IIS pools (Default and Classic .Net have user profiles on disk but of course, nothing is generated when you manually create an AppPool. And this is where the ‘Load User Profile’ attribute comes into play and should be set to ‘True’