Print | posted on Friday, July 08, 2011 11:51 AM
One of the most common complaints about the User Profile Synchronization service in SharePoint Server 2010 is the time it takes to perform synchronization runs or “sync” for short. This is due to a number of factors not least of which is that by leveraging Forefront Identity Manager (FIM) SharePoint now effectively includes a metadirectory. This is a good thing. However if you are just doing import then there is a huge increase in the time it takes over previous versions which were simply performing an ADSI query and inserting the results into a database.
It’s very important to note that there are many other factors which influence the time it takes to perform a sync, many of which are under your control as the farm administrator. I may do another post about these in the future.
Microsoft have heard this common complaint loud and clear and have been working hard to reduce the time taken to sync since RTM.
The December 2010 Cumulative Updates (CU) first introduced a significantly reduced sync time, due to the re-implementation of the SharePoint Management Agent that is created when you provision the UPS service instance. Depending upon environmental factors the December 2010 CU would decrease sync time by around 30-38%.
The really good news is that the June 2011 CU (*not* Service Pack 1) introduces some more changes that also help significantly reduce the sync time. This post takes a quick look at these.
A new build of Forefront Identity Manager (FIM)
The release of SharePoint Server 2010 includes a bundled version of FIM. However it wasn’t the RTM of FIM, but rather a stable build chosen to meet the release schedule of SharePoint. This by no means is the reason for all of the problems with UPS, but it is a factor.
The August 2010 CU included a minor build revision of the FIM bits, but since then the version has remained the same.
With the June 2011 CU, another build revision of the FIM bits has been included. This is one of the reasons why the UPS service instance must be re-provisioned after the installation of the June 2011 CU. This new build improves numerous aspects of the capability, including the sync time.
It’s important to note however that the bundled FIM is still not FIM RTM. Don’t get bogged down by this thou. Remember that UPS in SharePoint 2010 is not supposed to be full FIM, it’s FIM “Light”. The new build of FIM in the June 2011 CU is 4.0.2450.34. You can also see that the ‘Release Candidate 1’ text box on the about screen has been removed!
Here for your reference are the various build numbers:
| Product | Version | FIM Build |
| FIM 2010 | RC1 | 4.0.2560.0 |
| FIM 2010 | RC1 Update 1 | 4.0.2570.0 |
| FIM 2010 | RC1 Update 2 | 4.0.2574.0 |
| FIM 2010 | RTM | 4.0.2592.0 |
| SharePoint Server | RTM | 4.0.2450.5 |
| SharePoint Server | August 2010 CU + | 4.0.2450.11 |
| SharePoint Server | Service Pack 1 | 4.0.2450.11 |
| SharePoint Server | June 2011 CU | 4.0.2450.34 |
Changes to Synchronization Runs
Because FIM is a metadirectory, it works like one. :) One of the fundamental characteristics of a metadirectory is the requirement to perform delivery receipt and confirmation. This ensures the metadirectory is up to date and it also allows one to support a myriad of directory services, including those that may have intermittent network connectivity issues. All of this has been true since the very first true enterprise metadirectory (Zoomit Via in 1997).
This is the main driving force behind how directory synchronization works in SharePoint Server 2010. Even though the product can only do import or export it uses the synchronization engine provided by the metadirectory (FIM).
But if you are just doing an import from say Active Directory to SharePoint, that’s overkill. Take a look at the following screenshot of Synchronization Service Manager (miisclient.exe) which shows the sync runs for an incremental sync performed using SharePoint Server 2010 Service Pack 1, which is doing import only using the default property mappings:
Note that there are eight runs, and that the time taken is roughly six minutes. We of course here are only importing a couple of users, but it would still take six minutes if there were 50 adds. The number of users does influence sync time, but it is not a linear user/time relationship.
Now, take a look at the same thing this time with the June 2011 CU:
This time there are only five runs and the time is roughly 1.7 minutes. Nice! That’s another 33% time improvement (roughly) and you will experience the same improvements with more realistic numbers of users.
This improvement is due to the new version of FIM, and new versions of the AD, SharePoint and Metaverse management agents included in the June 2011 CU. I could bore you with the technical minutiae, but it’s not relevant. The thing you need to know is that sync is a lot quicker with the June 2011 CU!
Other Changes
With the June 2011 CU Profile synchronization now supports domain migration.
Synchronization Connections for SunOne (or later Oracle versions) LDAP are now possible regardless of the state of the nsslapd-return-exact-case base attribute. In previous builds creating the sync connection would fail.
The Profile Synchronization Status view now includes all stages and a better view of progress. (but miisclient.exe is still the way to go if you know what you are doing).
ULS reporting is vastly improved. Instead of just reporting a stage was started, we get the following detail:
This might seem pointless on face value, but it means that if there are errors during a run they are now bubbled up back to SharePoint, and can be recorded etc via ULS. It also avoids the need to use Synchronization Service Manager (miisclient.exe) to know there were problems. In the past even with errors, there would be nothing in the ULS.
Take this example:
The highlighted row is a problem with the export to AD. Of course to see the root cause of the problem we still need to dive into miisclient.exe. In this case, it’s the old chestnut – lack of permissions on the attribute in AD we are trying to write:
But the point is, in the past SharePoint would report success even if there were failures. Now it will report failures and that makes it much easier to manage the operational service of the farm with standard SharePoint tooling.
Synchronization Connections now run in parallel
If you have multiple Synchronization Connections their associated runs will now execute in parallel. Before the June 2011 CU, each run would run serially, thus increasing the overall time for sync to complete. Now, this is NOT a reason to have multiple connections. That remains as bad an idea as it always was, but there are some cases where it is the only way to achieve the end results desired. You should always try and avoid multiple connections, especially more than one for the same AD forest. However if you are using more than one, the sync will now be significantly quicker.
Check out the following, two Synchronization Connections:
And here are the sync runs, note that they run in parallel:
The IsSynchronizationRunning property
There is also now a property on the UPA (service application) that allows us to check if a profile sync is running before doing other operations such as adjusting timeouts or creating connections etc:
$upa = Get-SPServiceApplication 972fe314-7eb9-47b7-a265-20ffbc94680b
$upa.IsSynchronizationRunning
True
This is really important when developing custom code or Windows PowerShell automation solutions for UPA.
Conclusion
Some really great improvements to UPS are included in the June 2011 CU. Perhaps this is why Microsoft are so keen that you deploy! If you are dealing with a large synchronization requirement this package is definitely for you. But remember to test thoroughly before you deploy and watch out for the UPA gotchas with this update:
.