Understanding User Replicator in Lync Server 2013 and Skype for Business Server 2015

[Sri Todi]

First published on TECHNET on Apr 17, 2017
Reference: https://docs.microsoft.com/en-us/archive/blogs/toml/lcs-2005-user-replicator-faq

This post starts of with a reference at the top, only because it is indeed a very well written blog post from a little over 10 years ago. Since LCS 2005, we have had User replicator and while a lot has changed, the principles for User Replicator is essentially the same.

---

User replicator runs under the Front-End Service context, rather than a different service. It now writes to the SQL Express installation on each server (RTCLocal Instance), and runs on every server in the pool. It runs on any server that has the registrar role installed.

What does User Replicator do?

User Replicator is responsible for ensuring that the Lync Server or Skype for Business Server database  and Active Directory are synchronized. What this means is that any time an user object or contact object is created or modified in Active Directory, it is User Replicator’s responsibility for ensuring that the changes are propagated to database. To accomplish this, User Replicator first performs a Full-Sync (or Initial Sync) and then subscribes to a Delta Sync (Incremental Changes) using DirSync.

What setting in User Replicator are configurable ?

With Lync Server 2010 we introduced Set-CsUserReplicatorConfiguration to allow an organization to control the user replicator. Here we discuss the different switches

ReplicationCycleInterval - Since UserReplicator only tracks delta changes from the Active Directory (AD), the using a smaller replication interval like 5 minutes, ensures that the Distribution List Expansion (DL Expansion) and Address Book Web-Query (ABWQ) provide accurate information. It also allows for users to be created in Active-Directory and be provisioned in Lync or Skype for Business within minutes.  It is to be noted that since we only subscribe to delta changes, the load on a domain controller is negligible.

ADDomainNamingContextList - specifies the Domains that may have user objects and contact objects, that need to be synchronized. When this is not-set, User replicator will try to locate all the different domains and perform replication. ADDomainNamingContextList can be used to exclude say an empty root domain, or a domain if it's was used only to store computer accounts.

SkipFirstSyncAllowedDowntime - This was introduced only in Skype for Business Sever 2015. It sets the Front-End Service (RTCSrv)  from pending to started, even though a the initial Sync hasn't been completed.

DomainControllerList - This was introduced only in Skype for Business Sever 2015, and allows to specify a list of domain controllers, however, we suggest to to leave this to default. I will explain why in a little bit.

Can I control which DC’s User Replicator connects to in order to perform synchronization?

In Skype for Business Server 2015 ( not in previous versions) , while its configurable, its not recommended, because the User replicator uses a Windows API called DsGetDcName to connect to a Domain Controller. The response of the DsGetDcName  API really depends on how your Active Directory Administrator has configured the AD Sites and Services in your organization. The response is either (i) An in-site Domain Controller or (ii) An out-of-site Domain Controller

It is to be noted, that an the definition of Site here is an AD Site, which is defined by a list of Subnets and should typically be a representation of your physical site.

To know which site your Lync / Skype for Business Server belongs to, all you need to do is run nltest.exe /DSGetSite from a command-prompt. If the server is not associated to a site, chances are User Replicator will connect to a less than optimal domain controller for both initial Sync and delta syncs.

If AD Sites are configured correctly, either an in-site domain controller  ( if one exists) is chosen, or an out-of-site, which has the lowest cost (based on the cost configured in AD Sites and Services). If the Lync or Skype for Business Server is not a member of any AD site, then the Lync / Skype for Business Server will connect to a random domain controller, which may not even be in the same continent.

How long does the initial replication cycle typically take?

There are a number of variables that affect the length of the initial cycle, chief among them the number of objects ( User object and Contact Objects combined) being synchronized, the domain controller that was chosen, the available band-width and load on the domain controller. Assuming minimum spec hardware or better and no serious network latency/bandwidth issues, an initial cycle with 100,000 objects will take about 30 minutes. In contrast, an SBA server can be in a remote location with limited bandwidth and potentially no in-site domain controller, in such a case, the initial sync can take considerably longer.

Examples #1:
A SBA server didn't exist in any AD Site and this caused for User Replicator Initial Sync to connect to a Domain Controller in a different Continent, with poor network connectivity, eventually taking well over 6 hours to Synchronize, causing Front-End Service to be in Starting Mode for 6+ Hours. A simple AD Site configuration change caused the service to start in ~ 45 minutes when the initial Sync was interrupted, and the service was restarted. With Skype for Business Server 2015, the SkipFirstSyncAllowedDowntime parameter for Set-csUserReplicatorConfiguration would have been useful.  This is one of the many reason why we recommend not to configure the DomainControllerList parameter using Set-csUserReplicatorConfiguration

Examples #2:
In a particular case that I handled several months ago, we found that AD replication between sites was configured to occur only between 06:00 PM and 06:00 AM in 30 minute intervals. This caused users in a site to be able to communicate with a new hire almost immediately, while it took several hours ( up to 12 hours) for users on another site to view the newly created user. Once the AD replication interval was set to perform replication in 30 minute intervals, round the clock, we a newly created user was accessible in ~ 30+ minutes from both sites.