Question:   Why are replicate-directory-changes permissions needed to synchronize with AD and on what in AD?
Answer:In order to interrogate AD about “what has changed since time xyz”, we need the replicate-directory-changes permissions on partitions being synchronized, for example the domain partition being synchronized.These permissions are needed in particular to be able to read data within the deleted objects container of the partition. Standard users do not have permissions to read the content of this container, and we cannot simply grant rights over that container to the synchronization account.

In RC we also require these permissions on the cn=configuration container, in order to access the netbios information for the domain (we are working to fix this for RTM, so this container permissions will be required only if your netbios name is different than your domain name)

Question: Do the replicate-directory-change permissions allow the holder to modify AD?
Answer:Holder cannot modify AD using these permissions

Question: What additional privileges are granted (beyond the ability to read and inquire of delta changes) with replicate-directory-changes permissions?
Answer:Holder can read all AD data for the domain, except passwords. Note that most of the directory information is by default readable by everyone, including data in the configuration partition.

Question: I have very sensitive information in AD, such as pay-levels and now I am worried that these permissions will expose that information
Answer:The replicate-directory-changes permissions will only expose sensitive data if explicitly mapped and imported into SharePoint. SharePoint out-of-the-box mappings do not expose custom AD data. This account cannot use LDAP querying to access information otherwise not available for read; it has to specifically use replication interfaces of the system to trigger sync in order to access the data.

Question: Why do I need the Replicate-directory-changes permissions at all if I am only doing a full sync?
Answer:Replicate-directory-changes permissions can also be used to do a full import as well, to get consistent read, for the respective delta-imports. SharePoint admin must explicitly map a property for export, there is no out-of-the-box mapping to export to AD . Even if the SharePoint admin creates a mapping, there will be no export of the data unless additional AD permissions allow so. Replicate-directory-changes do not allow for creation, modification or deletion of data in AD.

Question: Is there a local box admin requirement for provisioning user profile synchronization service?
Answer:When provisioning sync (hitting start on the user profile sync service in the central admin services on server page), you must be logged in as a farm “account” who is also the local box admin on the box you are provisioning the sync service. This requirement exists because sync process needs to make some changes in the local groups and modify registry entries on the machine. This is typically done at the early install time, but with sync SP2010 follows a two-phased provisioning process which necessitates this for provision time of the sync service. Note that this requirement exists only during provisioning (moving to another machine or starting for the first time). This requirement will remain for SP2010 RTM.

Question: User profile synchronization service on the “Services on Server” page continues to stay in the starting state. How can I reset it to stopped state?
Answer:Fire up powershell. Get a handle for the respective user profile service application (UPA), say $UPA. Then use the method $UPA.ResetSynchronizationMachine().

Question: I see obsolete users in the profile store, for example, on the org chart. These users are no longer in AD.
Answer:There can be two reasons for obsolete users in the profile store:

1. MySite clean up timer job is not active. The user profile synchronization job marks users deleted from the directory source to be deleted. When the MySite cleanup job runs, it looks for all users marked for deletion and deletes their profiles. Respective mysites are then assigned ownership to the deleted profile’s manager and an email is sent to the manager.

2. There were users that existed in the profile store and were not brought in by user profile sync. This can occur, for example, if a customer upgraded from previous version of SharePoint. And chose to only synchronize a sub-set of domains with 2010. You can find these users by utilizing the following commandlet:
$upa = Get-spserviceapplication –identity <UPA ID>
a) To view users and groups that’ll be deleted:
Set-SPProfileServiceApplication -Identity $upa – GetNonImportedObjects $true

b) To delete these users and groups (this action can’t be undone):
Set-SPProfileServiceApplication -Identity $upa – PurgeNonImportedObjects $true
To view or delete users only, please select users-only option in the user profile synchronization settings through central admin. Similarly, to view or delete both users and groups, please select users and groups option in the user profile synchronization settings through central admin.

Question: I know my netbios and domain name are different or I am seeing wrong samAccountnames after import. What gives?
Answer:If your NetBIOS name is different from your domain name, at least Replicate Directory Changes permission is also needed on the cn=configuration container and you must enable NetBIOS domain names on the corresponding User Profile service application. For more information about enabling NetBIOS names on a User Profile service application, see Get-SPServiceApplication.

The UPA property NetBIOSDomainNamesEnabled is used to control whether the CNC partition is included in the AD Connection or not.  By default it is false (not enabled) and the CNC and associated run steps are not included in the AD Connection configuration.  If it is enabled, then the CNC partition and run steps are included.

When editing a connection, the flag is ignored.  If the CNC was included in the AD Connection when it was created, then it will continue to be included in the AD Connection.  If the CNC was not included when the AD Connection was created then it will never be included in the AD import.

To “enable” NetBIOS domain names once a connection is created requires the connection to be deleted and a new connection created with the flag turned on (set to 1 or true).  This will delete all the users which had their SAMAccountNames incorrectly formed due to the NetBIOS domain name being incorrect.

How To:  Enable import of NetBIOS Domain Names

Using the 2010 SharePoint Management Shell:

Get-SPServiceApplication
<lists the Service Applications and their GUIDs>
$UPA = Get-SPServiceApplication –Id <GUID of User Profile Service Application>
$UPA.NetBIOSDomainNamesEnabled=1
$UPA.Update()

Question: For whatever reason, I’d like to reprovision the sync service from scratch. How can I reset sync and will resetting harm my user profile data?
Answer:User profile sync serves as a staging area for data, and the data in profile store and social databases is the data consumed by the user profile service. So if the right steps are followed, you should be able to reset the sync service and related databases, without harming the user profile data. Here are a set of suggested steps:

1) Login as farm account

2) Backup the User Profile DB and the User Profile Sync DB

3) Stop the SharePoint 2010 Timer service:
PS D:\> net stop sptimerv4

4) Delete the data in the Sync DB using the following PowerShell script:
PS D:\> Get-SPDatabase

5) Copy the GUID associated with the User Profile Sync DB in the command line below
PS D:\> $syncdb=Get-SPDatabase -Id <GUID of User Profile Sync DB>

6) Execute these commands, in exactly the following order. This is not a script. So please cut and paste each of these commands one by one.
PS D:\> $syncdb.Unprovision()
PS D:\> $syncdb.Status=’Offline’
PS D:\> Get-SPServiceApplication
#Copy the GUID associated with the User Profile Service and paste it after “Id” in the next command:
PS D:\> $upa=Get-SPServiceApplication -Id <GUID of User Profile Service
PS D:\> $upa.ResetSynchronizationMachine()
PS D:\> $upa.ResetSynchronizationDatabase()

7) Provision the Sync DB:
PS D:\> $syncdb.Provision()

8) Add the User Profile Synchronization service account (farm account) as the dbowner on the Sync DB (using SQL Server Management Studio).

9) Start the SharePoint 2010 Timer service
PS D:\> net start sptimerv4

10) Start the User Profile Synchronization Service in the Central Administration UI.

11) After the User Profile Synchronization Service is started, reset IIS.
PS D:\> iisreset

12) Create connections to data sources in the Central Administration UI.

13) Run full user profile synchronization.