Building a Lync Enterprise Pool allows you to protect your users and services in the event of hardware or software failure on one (or more) servers in your pool. While this is great for redundancy, it can make troubleshooting a particular user error a little more complicated. For example, if you have eight servers in your pool, logging on to each one can create a lot of additional work just to troubleshoot a problem; especially if it is just for
one user.
As an example, at a recent customer deployment, Federation wasn’t working for users on a new Lync Pool. This was a large and rather complex environment that was still in co-existence mode with OCS R2 and I didn’t want to have to dig through a bunch of logs. But have no fear, PowerShell came to the rescue!
The following command will tell me to which server(s) my Lync client will connect, and in which order (the command should be all on one line)
Get-CsUserPoolInfo –Identity “user” | Select-Object –ExpandProperty PrimaryPoolMachinesInPreferredOrder
Here is a sample output from my lab:
In the example above, the user will first connect to “1:1-2” which is EE2.contoso.local. If for any reason that server is unavailable, the next server tried will be ee1.contoso.local. If the user’s home server is up and running, their Lync client will connect to it. This allows the administrator to run Logger just on that server for troubleshooting purposes. This will make your job a little bit easier.
To put this to test, we’ll go through the process. My lab has a DNS load-balanced Enterprise Edition Pool with servers EE1.contoso.local and EE2.contoso.local. The SIP Domain is contoso.com and I have 2 DNS A records for my pool as indicated below:
For my first sign-in I have manually configured my client to
use “eepool.contoso.com” as its logon server.
I’ve also enabled logging so we can examine the results in Snooper. By default the logs can be found in %userprofile%\tracing and will be named “Communicator-uccapi-0.uccapilog”. This file can be opened with Snooper. Snooper is available from the Lync Resource Kit available here.
Now let’s break down the SIP traffic. First we see our initial Register. Notice that
the client attempts to talk to 10.255.106.152 (EE1)
After the initial Register you will see three “401 Unauthorized” messages. This is normal
as the client has not authenticated yet. After the three “401 Unauthorized” messages, you will see a new Register attempt. This time with an authentication type set.
After the Lync clients has authenticated to EE1, we immediately see a “301 Redirect Request to Home Server”. This tells our client that it should connect to EE2.contoso.local (the preferred server) since it is online and servicing clients. We can tell EE2 is our
preferred server by the “q=0.7” section at the end of the first “Contact” line.
In the screen shot above we also see a second “Contact” entry with “q=0.3”. This tells our
client its Backup Registrar is “se.contoso.local”. The Backup Registrar can be a Lync Standard Pool or an Enterprise Pool in a backup datacenter.
Now that our client knows which server it should talk to, we attempt to register to the new server. As in the previous case, the client will receive three “401 Unauthorized” errors before it successfully registers using TLS authentication.
If for any reason our preferred server is not available, we will attempt to connect to all other entries listed in the order shown in the first screen capture above. If our pool
is down, our client will connect to the backup pool after the failover interval has elapsed.
Now that we are sure which server we are connecting to, we can log in and run the logging tool to troubleshoot any issues:
I’ve chosen to log the SIP Stack as you can see in the screen shot below:
After I’ve started and stopped logging, I can click the “Analyze Log Files” button and as long as snooper is installed, I’ll be able to jump right into troubleshooting from the server.
Some great reference material is available on what I’ve covered in the following links. I highly recommend these articles:
Another Reason to Include a Director in Your Lync Server 2010 Deployment
The Lync Guy's Blog 
Pingback: Logging on a Lync Enterprise Pool | The OCS Guy’s Blog « JC’s Blog-O-Gibberish
Pingback: Logging on a Lync Enterprise Pool | The OCS Guy’s Blog « JC’s Blog-O-Gibberish
Pingback: Lync Server 2010 Troubleshooting « msunified.net
Question. I see when you connected to EE2 you got in-band what the backup registrar was (se.contoso.com). But I thought you need a registar based on what the “Another Reason to Include a Director in Your Lync Server 2010 Deployment” stated. Was this fixed in a recent patch so now the FEs will provide in-band what the Backup Registar is?
Nevermind. I see it’s because you’re pointing to the wrong Pool Member, get the 301 redirect, and because you get the 301 redirect you see both the primary and backup.