On each Lync Front End there runs the rtcsrv.exe service (Front End Service). Every 60 seconds the rtcsrv.exe executable will crawl Active Directory for changes (more on this in a minute). So which Attributes is Lync looking at?
Should a change be found it is placed into the RTCab sql database (Depending on version of Lync you’re deploying will determine where the RTCab database is. If you’re running an enterprise pool, thus a dedicated SQL server, the RTcab will be installed on there. If you’re running standard Lync, the RTCab will be local to the Front End).
Now, you may ask which Domain Controller(s) will Lync sync with in a multi-domain environment. Good question! I originally though Lync would find the closest Global Catalog as it appears that all attributes Lync is looking for are replicated in the GC. I was pleased to find that Lync will go to a Domain Controller in each domain to do the sync. You can see this if you use resource monitor and pin it to rtcsrv.exe. Why is this a good thing? Well, imagine you’re in a large AD environment. It may take a long time for changes to make their way into a GC.
How often does RTCsrv.exe sync? Every 60 seconds! That’s right, changed made in Active Directory will make their way into Lync within 60 seconds (pending AD replication is working).
There is another kind of synchronization that Lync does. It’s done by the ABServer.exe. By default the ABServer.exe will look into the sql RTCab database (again, depending on version of Lync you’re deploying will determine where the RTCab database is) and will write it’s content to the file share used by Lync \\FQDN\Share\WebServices\ABFiles0000000-0000-0000-0000-0000000000000000000-0000-0000-0000-000000000000. This happens each night at 1:30am (by default). You may ask, does the ABServer.exe run on each front end? The answer is yes and no. The Abserver.exe has the ability to run on every front end in a pool. However, at any given point in time, only 1 front end in the pool will be running the EXE.
So you may ask, why does Lync use RTCsrv.exe to update the SQL database and then use ABServer.exe to update the Address Book file share. Why not just use one and get rid of the other? Here’s why:
One of the things you can do with Client Policies is define how your Lync clients (end users) search for Lync enabled users.
- Web Query: When you define a client policy to use web query, essentially nothing is downloaded on the Lync client and when a user wants to find another Lync user, they query the Front End server their Lync client is talking to. On the back-end, the web server is running SQL queries looking into the RTCAB sql database. Now, once that user is found, his/her info is then cached on the local computer. Similar to how DNS lookups are, Lync queries first look into cache then query the front end. It is unclear how long info is cached into this file (like TTL times on DNS entries). You can imagine strange situations can arise when info is updated in AD but a lync user has already downloaded info about a given user. It would be nice to be able to set a TTL for the data in the Lync Cache…..should I find out i’ll update this post.
- Web Query and Download: When the Lync client is started up it will use the method above to look for users however, lets say the Lync client was started at 10am, well sometime between 10am and 11am, the Lync client will download the Address Book (from the file share described above). Once downloaded the Lync client will start looking for users only within the address book. Now, how often is the locally cached Address Book update? Once every day. As stated above, you can run into strange things if you are constantly updating information in AD.