Microsoft SharePoint 2010 Administration Toolkit v1.0 Released

We’ve recently released the first administration toolkit for SharePoint Foundation and SharePoint Server 2010.  The toolkit includes a new User Profile Replication Engine, a new Security Configuration Manifest, a new Content Management Interoperability Services (CMIS) Connector, and the Load Testing Kit (LTK).

User Profile Replication Engine

The User Profile Replication Engine was first introduced as a standalone application in later adminisration toolkits for Office SharePoint Server 2007 to replicate profiles between Shared Services Providers (SSP).  The User Profile Replication Engine for SharePoint Server 2010 was built on Windows PowerShell and now enables the replication of Profile and Social data between the User Profile Service Application in SharePoint Server 2010, in addition to backwards compatibility with Office SharePoint Server 2007 SSPs.  These improvements enable replication between SSP’s or User Profile Service Application services, as well as across versions.  Note Replication is limited to Profile data, SSP’s in Office SharePoint Server 2007 contains no Social activity tracking.

Security Configuration Manifest

The Security Configuration Manifest is an attack surface reduction feature in Windows Server products.   The manifest inlcuded in the administration toolkit adds roles for SharePoint 2010 to Windows Server 2008 with SP2 or Windows Server 2008 R2.

Content Management Interoperability Services Connector

The Content Management Interoperability Services (CMIS) Connector enables consumers of SharePoint to interact with content stored in any repository that has implemented the CMIS standard and in additional enables SharePoint 2010 content to be available to any application that has implemented the CMIS standard.

Load Testing Kit

The Load Testing Kit (LTK) generates a Visual Studio Team System 2008 (VSTS) load test based on Windows SharePoint Services 3.0 Internet Information Services logs.  Load test can be used to generate synthetic load against SharePoint 2010 as part of a capacity planning exercise or a pre-upgrade stress test.

The Microsoft SharePoint 2010 Administration Toolkit v1.0 can be downloaded from

Microsoft SharePoint 2010 Administration Toolkit v1.0 documentation for SharePoint Foundation 2010 can be downloaded from and for SharePoint Server 2010 from

Social Computing and Collaboration Resources

Today we released a new whitepaper that provides prescriptive guidance about profile synchronization and My Site planning and administrative tasks for SharePoint Server 2010 that combines real world scenarios and step by step instructions with accompanying screenshots to help IT Professionals and Developers successfully understand, deploy, provision, and manage the services, components, and features that support and enable user profiles, synchronization, My Site Web sites, and more.


When designing a solution for business collaboration and social computing, it is important to think about a ‘social identity’ that represents each user in the organization. This identity, which lives in SharePoint Server, is typically an aggregate of data from directory sources such as Active Directory® Domain Services (AD DS) and other business systems… more…

Related Resources

Plan for social computing and collaboration (SharePoint Server 2010)

User Profile service overview (SharePoint Server 2010)

User Profile service administration (SharePoint Server 2010)

My Site Web sites overview (SharePoint Server 2010)

Collaboration site planning (SharePoint Server 2010)

Planning a 100,000+ My Site personal site deployment? Notes…

This topic has frequented my Inbox over the past months, planning a My Site personal site deployment for 100,000+ users.  In this post we’ll examine the issues and potential solutions.

First it is important to understand that while a My Site personal site is a site collection in basic form, it’s instantiation via a browser request or managed code results in significantly greater overhead than a traditional collaboration-type site collection.  The majority of overhead is presented through the numerous data building operations that occur both on the private and public pages associated with the template, private.aspx and person.aspx respectively.

The My Site private page (private.aspx) is considered to be a private view that hosts information specific to you (or the site collection owner).  This information is presented in part based on your membership in a specific audience in many configurations.  The private page also serves as a host to your documents, alerts and subsequent alert results.  Private.aspx also provides the capability to view your Inbox, calendar, and other Exchange views.

The My Site personal site public page is intended to present information to be shared with other users and contains information such as personal and professional interests, shared links and documents.  The public page also provides out of the box functionality that can be used to determine organizational similarities between the user requesting your profile and themselves (also known as the Organization Hierarchy Web Part).  Other comparative Web Parts include In Common with You and Memberships.

The result of these two unique views presented in a My Site personal site is approximately a 50% more costly public view when compared to the private view as a result of resource intensive operations required to build and present the profile information for a specific user requesting the My Site personal site public page.

The majority of the information that is presented on the public page is derived from the profile database, since that content is isolated to a single database there are no options to spread the load across multiple database servers.  The database is the smallest unit of file system representation for SharePoint and cannot be logically partitioned (clustered indexing strategy comes in play here); however, you can physically partition the database and stripe the data files across dedicated physical disks to gain parallelism which will help with data access I/O.


A distributed topology provides the most efficient mechanism to support a large number of My Site personal sites and is commonly comprised of two or more independent server farms supporting the associated Web applications from unique geographic regions.  For example, server farm A in Seattle hosts the My Site host Foo, and an audience defined in the Shared Services Provider for domain users in the North America region is configured to use the My Site host Foo as their trusted My Site host (Figure 1) whereas server farm B in Dublin hosts the My Site host Bar, and an audience (Figure 2) defined in the Shared Services Provider for domain users in the EMEA region is configured to use the My Site host Bar as their trusted My Site host.  This topology generally requires a parent Shared Services Provider to which server farms A and B are consumers, a local Shared Services Provider can be configured; however, certain profile replication mechanisms should be in place to keep the SSP’s synchronized.  In either scenario when user B who is a member of an EMEA based domain users group, e.g. EuropeDomain Users requests Foo, the audience membership is read and subsequently the user is redirected to Bar, this process conversely applies to user C who is a member of a North America based domain users group, e.g. AmericaDomains Users.


Figure 1 Trusted My Site host locations (Shared Services Provider administration)


Figure 2 Configure Trusted My Site host location and audience

*An important consideration is the requirement to have two or more unique URI’s to supported the distributed topology, for example http://mysite in North America and http://mysiteemea in EMEA.


Consider RAID 0+1 or 1+0 sets to supported the Shared Services Provider database and define a subsequent scale-up strategy.

Consider running profile synchronization operations during non-core business hours.

Consider removing costly Web Parts and determine their overall business value, this may include Organizational Hierarchy, In Common with You, and Memberships.

Consider a distributed topology where possible.

Remember the sizeable fraction of visits to a My Site personal site are from that of the site collection owner themselves.

RPS – Throughput can decline as the number of site collections in a given content database increase.

Consider Kerberos where possible to improve authentication performance and reduce overhead.

Plan for capacity and ensure a proper governance plan is endorsed and implemented.


About My Site

About Audiences

Plan for software boundaries (Office SharePoint Server)

Planning and Monitoring SQL Server Storage for SharePoint: Performance Recommendations and Best Practices

Migrating User Accounts in Windows SharePoint Services

While attending Ask the Experts at the Microsoft Office SharePoint Server Conference 2008, I was asked about migrating user accounts in Windows SharePoint Services 3.0 to a new login name programmatically, fortunately Windows SharePoint Services addressed user account migrations with the Windows SharePoint Services 2.0 post SP1 hotfix package 896593 which was followed by a number of applications including SPUserUtil Keith Richie corrected me today – SPUserUtil preceeded the MigrateUser API – Thanks Keith!.  The good news is that with the exception of minor OM changes, the base functionality is retained in WSS 3.0.

Programmatically (Multiple User Scenarios)

Where working with a large number of users, you may wish to programmatically migrate those users using the MigrateUserAccount method which migrates a user account in WSS to a new login name and binary Id updating the site collection user in the UserInfo tables, people lists, and security policies across the farm. The MigrateUserAccount method is a member of the Microsoft.SharePoint.Administration namespace, SP Farm class and takes three arguments, oldLogin, newLogin, and enforceSidHistory.

  1. oldLogin is the is the login name you would like to modify – if the login name exists, it will be deleted to allow the change.

  2. newLogin is the desired login name.

  3. enforceSidHistory will query the Active Directory for the SID history attribute to ensure that the new logon name is truly correspondent to the old one (checks and balances).  NOTE Set enforceSidHistory to False when working with non-Windows user accounts, for example, Forms-Based Authentication users.

Sample Code

using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;

namespace MigrateUser
class Program
static void Main(string[] args)
SPFarm Farm = SPFarm.Local;
Farm.MigrateUserAccount(“CONTOSO\UserA”, “CONTOSO\UserB”, true);

This code snippet is provided under the Microsoft Permissive License.

NOTE  WSS stores user information based on both the Security Identifier and user logon information, when either changes in Active Directory, WSS needs to be updated with the new user information otherwise that user will be unable to access the WSS environment.

SharePoint Administration Tool (Single User Scenarios)

User accounts can also be migrated using the SharePoint Administration Tool (STSADM) migrateuser operation documented here The ignoresidhistory parameter should be set to True when working with non-Windows user accounts, for example, Forms-Based Authentication users. Where working with a large number of users that are migrated in Active Directory subsequently changing those users corresponding Security Identifiers and/or where modifying the logon information for those users consider utilizing the MigrateUserAccount method to reduce the administration overhead of working with single user entities on a one by one basis.

Profiles and Properties – Questions and Answers

A e-mail dialogue came up with a colleague surrounding Profiles and Properties in Microsoft Office SharePoint Server 2007, with the questions specific to profile cleanup and management of changes in profile properties.

  1. How are inactive user profiles managed…

  2. How do I manage Active Directory property changes in Microsoft Office SharePoint Server 2007’s profile database…

After I sent my reply, I realized this was not the first time the question arrived in my inbox so I’ve decided to include the explanations here:

Profile Cleanup

User profiles are checked against the Active Directory to determine whether or not there is a matching Active Directory object. If a matching object exists, the bDeleted flag is removed or set if a matching object does not exist during an incremental import. Management of these objects where a match could not be determined is handled through the native MySite Cleanup Job through either deleting the MySite collection for the unmatched object or assigning permission to the user’s manager and generating an e-mail notification.

Handling Active Directory Changes

Common occurrences in most organizations are changes in a user’s Active Directory properties, for example, a name change as the result of marriage or some other event. The user may report that when uploading documents, updating list items, etc. their name is incorrect; however, their SharePoint profile references the correct information. To resolve such occurrences, delete the user profile from the Shared Service Provider an execute a profile import to introduce a “clean” data set into the SSP or optionally run STSADM –o migrateuser to migrate the user data properly, edit some property on the profile to trigger the synchronization job.