Ian Morrish's WSSDemo.com SharePoint blog

Have you exported your User Profile Service (FIM) encryption key?

corp\ianmorr — Fri, 11 May 2012 21:59:28 GMT

Body:

If you have to move the User Profile Service to another server or restore the server hosting the UPS, you have to reconfigure the service and run a full sync.

A better option is to export the FIM import/export encryption key and import it on the other servers in your farm (at least the other Application servers which are potential candidates to host the UPS).

These steps will only work if the Sync Service has successfully started at least one time ;-) . You will see this event log message the first time the service starts.

To export the key, follow these steps on the server currently running UPS:

Open folder %program files%\Microsoft Office Servers\14.0\Synchronization Service\bin
Run miiskmu.exe /e [filename] /u:[domain\user] [password]
Note: use the account the UPS is running under

To import the key, follow these steps on a server you wish to move the UPS to:

Open folder %program files%\Microsoft Office Servers\14.0\Synchronization Service\bin
miiskmu.exe /I [filename] {0E19E162-827E-4077-82D4-E6ABD531636E}

If you had already tried moving the UPS service before importing the encryption key, you will see the Profile Synchronization Service status remain in Starting. There may also be an event log error about missing encryption keys.

After import the key, stop and restart the UPS from the Service on Server Central Administration Page (Do not try doing this on the FIM Windows Service).

If you have provisioned the UPS on the same server as Central Admin, then an IIS reset may also be required before the Profile Sync Service will start.

All of this is very relevant to getting FIM to automatically fail over to another server, more on that next time…

Published: 11/05/2012 7:59 p.m.

SharePoint Crawl Component Server CPU Overload

corp\ianmorr — Sat, 03 Mar 2012 04:03:11 GMT

Body:

Oh No, my SharePoint Server CPU is maxed out at 100%! SCOM alarm bells are ringing and that nice 55" plasma screen in the IT department, that everyone thought was such a good idea, is flashing read.

There must be something wrong?

Answer: Yes and no.

When SharePoint executes a crawl of a content source, it doesn't hold back. The default configuration for crawling is to go as fast as possible (faster than possible in this example) with multiple threads for indexing document contents. If your content sources is a network share and you have a fast network connection direct to a SAN acting as an SMB share, there will be no let-up in CPU usage by mssdmn.exe until all content has been indexed.

If you execute a full crawl that overlaps with normal business hours it could have an adverse effect on SharePoint users if the crawl server is used for other services (single or multiple server farms) such as query or WFE roles. Even if crawl is running on a traditional application server in a 3 server farm (2 WFE's), the Central Admin site on the app server will run like a dog and if the query role wasn't moved to the WFE's then the search center results page will also perform badly during crawl operations (even an incremental crawl could have this impact if a lot of content had changed since the last crawl).

So, what can you do about this? I will just focus on the crawl configuration here, not the appropriate allocation of services on servers and other things (check out this article http://technet.microsoft.com/en-us/library/ff678212.aspx which although is for Search Server Express, is the same impact if you have a single SharePoint Server or single app server in medium server farm).

There are 3 main areas where you can determine the CPU resources that will be consumed during crawling.

Crawler Impact Rules

These let you specify rules targeted at specific content locations. The options are to specify a wait time between the current document indexing is complete and when the next document is opened from the source location or the number of parallel threads that will be used to fetch and index files. This is useful for content sources that are already overburdened with access request and you don't want SharePoint indexing to impact other users/systems accessing that content source.

Search Service Performance Level

In MOSS 2007 it was easy to set this to one of 3 levels in Central Admin. I can't find it in 2010 but you can set it from PowerShell (either when you create the search service or after) .

The PerformanceLevel property in the Set-SPEnterpriseSearchService command specifies the relative number of threads for the indexer performance. The value must be one of the following:

Reduced: Total number of threads = number of processors, Max Threads/host = number of processors
Partly Reduced: Total number of threads = 4 times the number of processors , Max Threads/host = 16 time the number of processors
Maximum: Total number of threads = number of processors

Note: this is from Technet and seems like partly reduced would generate more load than maximum. The last 2 are the wrong way round I suspect.

[Update] the correct performance level properties are:

Reduced: Total number of threads = number of processors, Max Threads/host = number of processors

PartlyReduced: Total number of threads = 4 times the number of processors , Max Threads/host = 16 times the number of processors

Maximum: Total number of threads = 4 times the number of processors , Max Threads/host = 16 times the number of processors (threads are created at HIGH priority)

Note 2: The crawler can accommodate a maximum of 256 threads per Search service application but you would need some impressive IO to feed that monster;-)

Antivirus Exclusions

Most organisations insist on running AV on every server. Even when you have a SharePoint AV solution installed, indexing will copy the file to a temporary location on the server and the local OS based AV will scan it also.

This obvious causes more cpu load (and longer time to perform a full index if every file has to be rechecked for viruses). The default temporary location for index files should of course be changed to another volume rather than c: for optimal performance.

See http://support.microsoft.com/kb/952167 for other default exclusions that should be applied.

Published: 2/03/2012 5:03 p.m.

Take control of Network Shares before deploying SharePoint for ECM

corp\ianmorr — Mon, 16 Apr 2012 18:39:00 GMT

Body:

I have yet to come across a customer who has installed the File Server Resource Manager (FSRM).

Everyone complains about the information management problems with networks shares but they don't do anything about it (except to think that an EDRMS or ECM platform solution will fix the problem). This is a learned helplessness.

Microsoft has added some grate tools since Windows 2003 to improve network shares but virtually no one has ever installed them (please let me know if you have!)

FSRM is part of Windows Server 2008 and up but you have to enable it (can be download for 2003).

What does it give you?

Quota management. Set soft or hard space limits on a volume or folder tree. You can create and apply quota templates with standard quota properties.
File screening management. Define filtering rules that monitor or block attempts by users to save certain file types on a volume or folder tree. You can create and apply screening templates with standard file exclusions.
Storage reports management. Generate built-in reports to track quota usage, file screening activity, and patterns of storage use.

The last two are of particular value in planning a move to SharePoint.

File Screening management means that you don't have to be a brutal as setting network shares to Read-Only as part of you migration strategy as there are still valid reason for keeping an existing share for some file types that aren't suited/support in SharePoint (like Access database .mdb files).

Storage reports can give you a good indication on the space wasted by duplicate files. No more dramatics over "we need 30TB of SharePoint storage because we have 20 TB of network share storage.
An example of the OOTB box reports:

For more information on FSRM see http://technet.microsoft.com/en-us/library/cc754810(v=WS.10).aspx

Practicing what I preach, here is the evidence from my own 2 TB Raid 5 home server storage array

So what are you waiting for? Take responsibility for your storage mess and be proactive in doing something about it.

Published: 16/04/2012 6:39 a.m.