SharePoint 2010 – Provisioning User Profile Synchronization

This blog is intended to quickly ramp up the reader on requirements and steps to successfully provision a user profile synchronization service. User Profile Service Application setup has been one of the most problematic issues for customers so I hope this will clear up some misconceptions.  I’ll cover some basics including components involved and improvements made in this area (User Profile Synchronization). The user profile service application contains several new and existing features from previous SharePoint build. User Profile Service Application has broken away from the SSP and is now a separate entity. It is no longer tied to an SSP and contains 3 SQL databases that are bound to each User Profile Service Application. User Profile Sync no longer relies on search architecture\crawl. User Profile Sync now relies on Forefront identity manager to facilitate full\incremental synchronization between a SharePoint 2010 User Profile Service Application (UPA) and directory servers like Active Directory. For the remainder of this blog, I’ll refer User Profile Service Application as “UPA”. The basic steps to completely provision a UPA:

1.) Provision a UPA either through the Farm Configuration Wizard or from Manage Service Application page within Central Administrator.

2.) Start the "User Profile Synchronization Service" within Central Administrator\System Settings\Manage services on server

Note: This provisions FIM services

3.) Within Manage Profile page, create a new Sync Connection

4.) Start a full sync

Note: Steps 2 and 3 must meet specific permission requirements for functional UPA.

In the following section, I’ll break down the components involved and permission requirements to successfully provision a User Profile Service Application Synchronization service.

 

 Important:  Provisioning User Profile Synchronization will not work in single server installs with built-in databases.   You must have a full install of SQL...

http://technet.microsoft.com/en-us/library/cc263202.aspx

 

Components

 

Forefront Identity Manager (FIM)

Forefront Identity Manager (FIM), formerly known as Microsoft Identity Integration Server (MIIS), is used to facilitate synchronization between multiple endpoints. For Example: (FIM sits between Active Directory and User Profile Service Application and is responsible for syncing changes between both endpoints. Without a healthy FIM, SharePoint sync isn’t possible and will fail. FIM automatically gets installed when SharePoint 2010 is installed.

One of the UPA SQL databases is called the Sync database by default. FIM utilizes the profile Sync Database to store data. So what components make up FIM?

1. Two Services

•  
  • Forefront Identity Manager Service
  • Forefront Identity Manager Synchronization Service

        

2. Profile Sync database (SQL)

3. MIIS Client.exe used to view progress\troubleshoot sync

4. FIM binaries including the MIIS Client tool are located here:

C:\program Files\Microsoft Office Servers\14.0\Synchronization Service

 

UPA Components

A user profile service application has multiple components including the following:

· Consists of 3 SQL databases (Social, Profile, Sync)

· Admin Page (ManageUserProfileServiceApplication.aspx)

· User Profile Service Application Proxy

· SharePoint Services (User Profile Service and User Profile Synchronization Service)

Note: These services are located in Central Admin\System Settings\Manage Services on server

 

 

Permission Requirements

There are two separate permission requirements that involve running full\incremental profile sync. Specific permissions are required for the account doing either of the following:

1. User Profile Sync account

2. Directory Sync account

 

User Profile Sync Account

The User Profile Sync Account is responsible for provisioning\running the User Profile Synchronization Service. It is the same account that runs both FIM services. This account requires the following permissions for provisioning:

· Farm Account (timer service account)

· Local Admin (for duration of sync provisioning)

· Logged on as the account during provisioning

· Member of Pre-Windows 2k compatibility group

Question:

Q. Why does this account need to be a member of Pre-Windows 2k compatibility group?

A. It needs membership to this group at a minimum because we call some functions like AuthzInitializeContextFromSid which require access to read the TGGAU attribute. The Pre-Window 2k compatibility group has access to read this attribute. See my blog for more details:

http://blogs.msdn.com/russmax/archive/2010/01/20/why-the-tokengroupsglobalanduniversal-tggau-attribute-matters-in-sharepoint-2010.aspx

 

Directory Sync Account

The directory sync (dir sync) account is responsible for authenticating\enumerating against a directory server in order to sync changes. This account requires specific permissions to a directory server in order to read and “sometimes” write to a directory. In this example, I’ll be using Active Directory as my directory server because it will be the most widely used directory server. Where\How do you set this account in SharePoint 2010? This account is specified as part of step 3 above which is during the creation of a Sync connection. The permission requirements depend on the following:

• Domain netbios name is the same as the FQDN domain name
• Domain netbios name is different than the FQDN of the domain.
• Syncing changes from AD to SharePoint/Syncing changes from SharePoint to AD

 

Permission requirements: Domain netbios name is the same as the FQDN of the domain

This is the easiest scenario and nothing must be done other than granting directory changes permission to each import domain NC. In a multi domain scenario where a root domain and child domain exists. If users reside solely in the child domain, then the only requirement is to grant the dir sync account replicate directory changes permission on the child domain NC. The dir sync account requires “no” permission within the root domain in order to successfully sync to\from the child domain.

The following permissions are required for functional full sync between UPA and Active Directory. The Directory Sync account needs the following:

· Replicate directory changes permission to each import domain NC

The following article describes how to set this:

How to grant the "Replicating Directory Changes" permission for the Microsoft Metadirectory Services ADMA service account

 

 

Permission requirements: Domain netbios name is different than the FQDN of the domain

This is not the easiest scenario and requires some explanation. When the domain netbios name is different than the FQDN of the domain, that is the domain netbios name is different than the first portion of the FQDN. For Example:

Domain netbios name: Contoso

FQDN of Domain: rootdomain.local

When domain naming scheme is set in this manner, the requirements are the following:

1. Enable the NetBiosDomainNamesEnabled property to true for the UPA
2. Grant Replicate Directory Changes perms to each import Domain NC
3. Grant Replicate Directory Changes perms to the Config NC

Note: A walkthrough of each step is detailed below

 

NetBiosDomainNamesEnabled

NetBiosDomainNamesEnabled is a property that is set on every UPA. By default, this value is set to false which means that you must set it to true in the scenario where the domain netbios\FQDN names are different. PowerShell can be used to drop the UPA into a variable and set this property to true.

For Example:

1.) Get-SPServiceApplication

a. Note: This will output every service application specifically the User Profile Service Application

2.) $var = Get-SPServiceApplication –Identity 00a380ed-2e99-4de3-ae22-dbe8c1b03bab

Note: the identity is the GUID associated with the User Profile Service Application which was retrieved and copied from running the Get-SPServiceApplication cmdlet

3.) $var.NetBiosDomainNamesEnabled

Note: if this is true then it’s enabled and you can skip directly to step 7

4.) $var.NetBiosDomainNamesEnabled = “True”

Note: Here you are setting the property to True

5.) $var.update()

Note: This is simply running update method against the variable which officially updates the property

6.) $var.NetBiosDomainNamesEnabled

Note: This confirms the steps were run correctly as the output will display True instead of False

7.) To utilize the domain Netbios name, a new sync connection must be created and used. Yes, this means you cannot use an existing sync connection and expect it to work. Create a new sync connection via the UI:

Central Admin\Application Management\Manage Service Applications\User Profile Service Application\Configure Synchronization Connections

 

Grant Replicate Directory Changes perms to each import Domain NC and Config NC

For the Domain NC: Utilize the same step described in the “Permission requirements: Domain netbios name is the same as the FQDN of the domain” section.

For the Config NC:

1. Launch ADSI Edit

2. Right click ADSI Edit and hit connect to

3. Under, “Select a well known Naming Context”, choose Configuration and hit OK:

4. Expand Configuration object and (right click + properties) on the configuration container which should be in a DN format like the following:

CN=Configuration, DC=Contoso,DC=com

5. Select Security tab and hit add the Dir Sync account and grant Replicate Directory Changes (This object only)

For Example, Bill is my dir sync account:

6. Click OK

Note: The account used to access the Configuration NC via ADSI Edit must be a member of Enterprise Administrators group to perform this operation.

 

Questions and Answers:

Q. My domain netbios name is different than the FQDN. My AD administrator refuses to grant replicating directory changes permission to the Configuration Container without an explanation.

A. This is a read only permission and will not write to the Configuration NC. Also, the dir sync account requires this permission to the Config NC because that’s where Domain NetBios names are stored.

Q. My domain netbios name is different than the FQDN. My AD administrator refused to grant the dir sync account replicating directory changes permission against Configuration NC. The dir sync account was only granted replicating directory changes permission on the domain NC. This appears to work okay and I can view all my users profiles in SharePoint after a full sync? I don’t get it?

A. It’s not that it won’t work if appropriate permissions are missing on the Config NC. The problem is that it will be an undesirable result in that the SAM account name will show up with the first portion of the FQDN as the domain name instead of the netbios domain name of the domain. This has many potential implications which are mostly unknown at this point. This is the reason why this setup will not be supported by Microsoft.

Q. My domain netbios name is different than the FQDN. How can I validate that the permission was properly set on the Config NC for the dir sync account after a full sync?

A. This question assumes that the questioner doesn’t have access to AD/ADSI edit to validate the dir sync account has appropriate permissions. Two ways to validate permissions are correct.

1. Go to Central Admin\Application Management\Manage Service Applications\User Profile Service Application Management page\Manage User Profiles and search by the netbios name of the domain name and ensure all user profiles appear.

2. Access the User Profile database within SQL and inspect some rows within the UserProfile_Full table. The NT column should display the domain name in CAPS for the netbios name of the domain.

 

Permission requirements: Syncing changes from AD to SharePoint/Syncing changes from SharePoint to AD

This is a major improvement to SharePoint 2010 sync in that now changes can go both ways. Instead of only syncing changes from AD to SharePoint, SharePoint changes can now sync to and update AD. The permission requirements already listed above meet the requirements for syncing changes from AD to SharePoint. However, additional permissions are required for the dir sync account to sync changes from SharePoint to AD:

· Create all child objects (This object and all descendants) to each export domain NC

· Write (This object and all descendants) to each export domain NC

 

Validation

Great, so permissions are now setup properly and it’s time to follow the original steps which are:

1.) Provision a UPA either through the Farm Configuration Wizard or from Manage Service Application page within Central Administrator.

2.) Start the "User Profile Synchronization Service" within Central Administrator\System Settings\Manage services on server

Note: This provisions FIM services

3.) Within Manage Profile page, create a new Sync Connection

4.) Start a full sync

I will discuss validating Step 2 and 3 in sections below.

 

Validating User Profile Synchronization Service Provision

After a User Profile Service Application is provisioned, the User Profile Sync Service must be started if the UPA will be used for syncing. As stated previously, starting the service provisions FIM so really two ways to validate successful provisioning.

1.) The service will be listed as started within Central Admin

2.) FIM service and FIM Sync service is started

3.) Timerjob status page displays success

In some cases due to lack of permission or some other issues, the User Profile Synchronization Service will get stuck in a Starting state and may never come out of it. This is when validation should include real time monitoring. I recommend using ULS viewer which can be downloaded here:

http://code.msdn.microsoft.com/ULSViewer

Using ULS Viewer, open the current ULS log and filter on category User Profile:

 

Validating a new Sync Connection

One way to validate a Sync Connection is valid besides a quick visual in Central Administrator is to use the MIIS tool and ensure a third management agent (MA) is present.

 

 

More Information

http://technet.microsoft.com/en-us/library/ff182925(office.14).aspx

 

http://technet.microsoft.com/en-us/library/ee721049(office.14).aspx

 

- Russ Maxwell, MSFT