7 tips and tricks about the User Profile Replication Engine

 

The SharePoint User Profile Replication Engine (part of the SharePoint Administration Toolkit) is a powerful beast that you can use to:

 

 

 

• Migrate user profiles from a different farm to your farm (MOSS 2007 to SPS 2010 IS supported)
• Synchronize user profiles from a master a farm to a different farm (geographical replication or disaster recovery farm replication)

I have been playing with this tool a bit lately and here are a few things I noticed that might interest you. First of I would advise you to start with the official documentation at: http://technet.microsoft.com/en-us/library/cc663011.aspx . You will most likely only use the full and incremental commands.

1 -Full replication DOES NOT use any windows service

The Full synchronization ( Start-SPProfileServiceFullReplication )does not uses the Windows Service (aptly named “Replication Engine”) used by the incremental command (Start-SPProfileServiceIncrementalReplication). This is important as it means that the full sync is done with the account you launched the command line with WHEREAS the incremental sync is done with the “Replication Engine” service account. Knowing which account is running is important to know which account needs the permissions on the User Profile Service Applications.

2 - Local Admin permissions IS NOT needed for incremental sync

Running the incremental sync (i.e. the windows service) is possible with a non-local administrator account, but it needs:

• Full permissions on the local folder where the replication engine is installed (C:\Program Files\Microsoft\SharePoint 2010 Administration Toolkit\Replication Engine)
• Full permissions on the registry hive
• HKLM:\Software\Microsoft\Replication Engine
• HKLM:\SYSTEM\CurrentControlSet\services\eventlog
• HKLM:\Software\Microsoft\EnterpriseCertificates

This is not based on any official documentation; I had to use Process Explorer to actually see what was preventing the Replication Engine from starting when running with a non-local admin account. The last two permissions might be optional but I added these anyway to be on the safe side. So far I haven’t seen any downside to this workaround.

3 - Full replication IS NOT needed before starting incremental sync

At least it is not always needed. If the User Profiles are already in sync because you did a fresh install and imported the profiles on source and destination with no other changes, you might skip the full sync and start with the incremental sync.

But if there is any difference between your two User Profiles SAs, start with the full as these differences will not be propagated.

In fact the incremental sync only propagates information that has been changed while it is running.

4 - Account changing option (credential parameter) behaves badly

The credential parameter of the Start-SPProfileServiceIncrementalReplication should be used to specify the windows service credential on the first run according to the documentation, well I don’t because it works erratically giving inconsistent results. Instead I set the windows service account itself. You can even do it in scripts.

5 - Social sync IS supported BUT

Social sync doesn’t included managed metadata (because it isn’t part of the User Profiles Service Application obviously) event though tagging is based on managed metadata. In fact tagging is stored in the User Profile DB as reference to the managed metadata entry.

Thus if you need to replicate tags you MUST replicate the managed metadata SA data as well.

6 - MySite URL CAN be replaced with the central administration Url

The documentation tells you to use the MySite Host Url for Source and destination but you can use the central administration URL as well.

In DRP (Disaster Recovery Plan) configuration it might be cumbersome to do so as URLs are shared on the source and destination farm. But the central administration URL being based on machine names is different on both farms.

Beware: this might depend on whether or not you User Profile SA is in the default Service Application Proxy group.

7 - Incremental sync is as fast as light

Yup it is seriously fast, so fast I thought my test protocol was broken when I started to test the replication :)

Beware of SharePoint 2010 Web Analytics on SQL Server Enterprise

You might have missed this information (we did :( ) but when running your SharePoint 2010 farm on SQL Server 2008 Enterprise (or 2008 R2), the Web Analytics reporting database uses the table partitioning feature provided in SQL Server.

 

 

 

For large-scale environments, we recommend that you run the Web Analytics service application Reporting database on a server that is running SQL Server 2008 Enterprise Edition so that the Web Analytics service application can take advantage of table partitioning.

           

         From: Databases Types and Descriptions (http://technet.microsoft.com/en-us/library/cc678868.aspx)

What this means is that your reporting databases will span one additional “NDF” file (and file group, named with the Aggregation DATE suffix) every week as illustrated below:

We realized this while trying to setup the logshipping of this base (which is supported according to this page by the way).

Hope it helps !

SharePoint 2010 – Resizing the Ribbon bar

Recently I was asked to add some element in the ribbon upper part just before the Site Actions Menu. Thus I needed to increase the height of the upper part of the ribbon to fit our content (blue part in the screenshot above).

Problem

After spending an insane amount of time on what seemed so simple, I managed to get it kinda working. I say “kinda” because no matter what I did I couldn’t get the ribbon to display correctly when it was opened.

After checking this article from the SharePoint team: http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?PageType=4&ListId={72C1C85B-1D2D-4A4A-90DE-CA74A7808184}&pID=426

I understood that it came from a FixRibbonAndWorkspaceDimensions() javascript function from init.js that just kept setting the height at 44px (ribbon collapsed) or 135px (ribbon opened) no matter what my CSS said. The culprit line is:

var baseRibbonHeight=RibbonIsMinimized() ? 44 : 135;

No need to tell you that after hearing Microsoft boast about their compliance with the latest Web Design best practices, I was expecting more than to find hard-coded height values in a JavaScript file…

Solution

Yet everything isn’t lost as the actual ribbonHeight is the aforementioned value plus a padding value

var ribbonHeight=baseRibbonHeight+g_wpadderHeight;

Thus if you want to increase the ribbon height, you just need to set the javascript variable g_wpadderHeight to the value you want to increment. You might do that in your masterpage as such :

<script type="text/javascript">

g_wpadderHeight = 30;

</script>

Something else to note, the WebPart adding part of the ribbon stopped displaying the “Add”, “Cancel” button after resizing the ribbon bar as they were out of the box. I solved this problem with a bit of css :

.ms-wpadder-buttonArea{

padding-bottom:30px;

}

Custom site logo not appearing on WebPart page

As you probably all know, SharePoint 2010 allows site administrators to change the sites logos just like 2007 did. This is done on the “Title, description, and icon” page

The picture then appears in the top left of the site pages, just before the page title/breadcrumb

 

The trouble is that this doesn’t work on WebPart pages, no matter what you do; users will still see the default yellow icon.

 

Cause

WebPart pages use the TitleBarWebPart, this WebPart allows you to specify a title and logo for the page using the button in the ribbon bar

The problem here is that whatever you do, this Web Part always overrides your site logo setting. If you specify a page specific logo along with the title, it will use it. If you don’t specify a page specific logo, it will use the default SharePoint logo.

This overriding is done in javascript by the code below that you will find at the end of your web part page :

var logoImg = documentGetElementsByName('onetidHeadbnnr0');
if (logoImg != undefined && logoImg[0] != undefined)
logoImg[0].src='/_layouts/images/siteIcon.png';

This javascript code is generated by the TitleBarWebPart, the “/_layouts/images/siteIcon.png” is replaced with the page specific logo if you set one. Thus this WebPart systematically overrides the site wide logo settings.
By the way you will notice that it doesn’t work under Chrome 8 because of a Javascript error.

Solution

Aaron Han suggested removing the Web part from the pages impacted on a MSDN forum:
http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010customization/thread/9706669e-0488-45cd-9cf6-2edfef91f77f
If you don’t want to edit every single WebPart page and/or if you want to retain the ability to change the page title I have another solution for you.
My solution is to change the SiteLogoImage node name in the master page. Thus the javascript generated by the PageTitleWebPart is no longer able to change the logo.

Details

Open your master page and find the line starting with:

<SharePoint:SiteLogoImage name="onetidHeadbnnr0"

And replace the “onetidHeadbnnr0” name with something else; “onetidHeadbnnr1” will do the trick.

Conclusion

I haven’t seen any drawback with this technique, yet :). Tell me if you do !