Skip to content

User Profile Service Across Farms

February 26, 2011

Introduction

User Profile data store provides the basics for Social Computing  in SharePoint Server products.  Properties in the profile are either “mapped,” i.e. imported from external sources, or unmapped.  The latter properties are typically managed by the users themselves or by code.

External User Data Sources

There are two possible external sources for mapped properties: an LDAP store and a BDC (BCS in 2010) connection.  The LDAP store connection is managed on the Import Connection screen.  Many organization find it useful to store user information in Active Directory and use a direct connection to Active Directory as the LDAP store to map many organizational properties (e.g. Employee Number, Title, Manager)  from the standard AD schema (Windows 2003) and even company-specific properties to user profile properties in SharePoint.

Other organization may find that maintaining these additional properties in Active Directory is not a good option.  In larger organization the number of properties may become a maintenance challenge.  In very small organization there may be no Active Directory, etc.  Of course, some organization may be running Linux as their primary data center, but this is a SharePoint blog…

BDC/BSC import is not a great option for external data mapping into User Profile.  Performance is abysmal; configuration is relatively complex; and at the end of the process you have two batch processes to monitor and maintain. 

User Profile Service in a Multi-farm Environment

A multi-farm environment multiplies the challenges or maintaining user data. User Profiles are maintained per farm (“Shared Services” are only shared within a single farm.) So, multi-farm environment also means multi-user-profile.  Each farm has to run its own version of the import process increasing the cost for maintenance and monitoring. In addition, users modify their own profile properties by visiting My Site.  My Site are homed to different farms and now each farm has a different version for the user profile.  Even if all mapped properties were stored in Active Directory, properties that are maintained by users in User Profile database are still not synchronized across farms.

Multi-farm configuration are quite common.  For larger organizations it is not reasonable to expect that a single farm in a single location can satisfy the access needs for the entire organization.  Further, even for smaller organizations, different farms exists to address different needs (collaboration, record management, project management, etc.)  Yet, the ability to connect and locate skills and resources across the organization require that the social aspects of all farms be merged.

User Profile Replication

Microsoft does have tool to address this issue – the UPRE (User Profile Replication Engine.)   The UPRE works reasonably well by using SharePoint API to instantly replicate profile properties among farms.  However, the UPRE has some shortcomings. The interface looks like it was designed by a sleep-deprived engineer over the weekend (no offense, really!! you are one of us..)  Full replication happens by domain, while the incremental *suppose* to respect Trusted My Site boundaries (it doesn’t.  At least not always)  If you set your Trusted My Site not by domain, then you’re out of luck.  The tool also stops working if there are too many differences.  I’m sure that there is a good reason for that, but if you are a sleep-deprived SharePoint administrator you want a tool that just works and is able to repair itself when a problem occur.

Bottom Line

The bottom line is this:  If you are going to use User Profile Service as your source for Social Networking in the environment, and you are planning to use the Out-of-the-box solution in a multi-farm environment you are in for a ride.  The solutions offered by Microsoft may end up working, but the road is not going to be smooth.  and the final configuration will require constant monitoring and regular maintenance to keep humming.

If you are willing to live with that then read no further.  If, however, you are like me and would like to go skiing or to the pool on the weekend instead of spending your time recovering lost records, then read on.

User Profile Replication – Take II

Here is a drawing of a 3 farms replicating User Profile data

image

There is a replication agent running in each farm, which points to the other two instances.  As more farms are added to the replication scheme the replication picture becomes that much more complex with each farm replicating its Trusted My Site users to the all other farms.

The Active Directory, which is drawn as a single source in this picture, will in reality contain many instances that automatically synchronize in a seamless and reliable manner….  Wait… what was that?   a program (that you already own) has the very feature that we are looking for.  It is set up to run on many instances across the organization and seamlessly and reliably synchronize many instances.  It is also independent of the number of SharePoint farms and presents no additional costs.

Using Active Directory may have some risks, though.  You will have to change the schema to include all profile properties, including user-defined properties and an ever increasing number of application specific properties.  You will also need Write and modify permission into Active Directory and that may not go over well with your friendly network administrator.

AD-LDS Store

While using Active Directory may be overreaching, AD-LDS, or ADAM in its previous incarnation (OK.  If anyone can explain to me how renaming ADAM as LDS is a good idea please raise your hand.. but I digress) offers a reasonable compromise.  It relies on Active Directory technology to maintain multiple instances of the user store.  It has an extensible schema and can reliably replicate and synchronize from Active Directory while allowing an application to add, modify, and delete properties with users.

A replication schema relying on AD-LDS looks like this

image

The communication between our AD-LDS instance and User Profile services in all farms are two-way communication.  User Profile Import runs on a schedule for “full import” and a secondary schedule for “incremental import.”  (Incremental import suppose to pick up only replication changes to the LDS store, but typically it does not have the proper rights set up and reverts to picking up the entire store.  Of course, there are no documentation from Microsoft about how to set up the LDAP source to make incremental changes work right, but I’m griping again…)

Advantages of AD-LDS

  1. Single authoritative source for all user properties
  2. Reliable and seamless replication across the organization
  3. Can alter schema without affecting Active Directory
  4. Built-in tools allow reliable synchronization from Active Directory
  5. Can support additional scenarios, including:
    1. External Users/vendors added to domain users in a single store
    2. No domain/multiple domains/mixed domains
    3. DMZ Intranet without access to domain servers
  6. LDS instances can be placed with low latency to each farm for faster import action

Conclusion/Next Steps

This article presents the idea of using AD-LDS as the authoritative source for user profile source data instead of a combination of direct access to Active Directory.  The notion of accessing AD-LDS store has strong appeal to anyone who had to deal with replicating User Profile information across multiple SharePoint farms in the same organization.  It also offers a good solution for allowing users outside of the organization to access portals by using the same hierarchies as Active Directory without being tied to an actual domain.

To start implementing AD-LDS instance you need to run Windows Server 2008 (or download ADAM from here for previous Windows versions).  A good starting point to understand and configure AD-LDS can be found here.

A great explanation of the User Profile import process can be found in this blog article

Advertisements

From → SharePoint

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: