I've now run into this issue a few times where after deploying Office Communications Server 2007 Enterprise Edition that the Office Communicator client is unable to download the address book from the IIS server. Below are some troubleshooting steps that I used to determine the cause and steps you can try to resolve this issue.

Author: David Lebar

Publication date: December 2007

Product version: Office Communications Server 2007 R2

When starting Office Communicator, it will sign the user in but then present you with the following prompt to download the address book. Normally there is no prompt and Communicator downloads the address book seamlessly. This prompt will not accept any credentials so you must click cancel to stop the address book download.

After clicking cancel you then see in Office Communicator that the address book failed to download.

 

Let's begin troubleshooting this issue by discussing what is required to download the address book.  When Office Communicator signs in it receives a referral from the OCS 2007 frontend to the address book URL.  The default is a HTTPS URL which requires a valid certificate assigned to IIS.  You can see the address book URL in the status page of the Front End server:

 

If there is a valid certificate assigned on the IIS box we should be able to access the default website.  Using the example above, https://pool02.domain.local should bring up the default under construction page.  If you are not able to access the URL and bring up the under constuction page you will want to check your Internet Explorer proxy settings.  Setting an exception for any local domains would be best (ie. *.domain.local).

If the browser is able to access the under construction page using SSL, you can then try to download the address book files manually.  Using the above example try to download one of the address book files, https://pool02.domain.local/Abs/Int/Handler/F-0993.dabs.  This should prompt you once, then allow you to download the file.  If Internet Explorer prompts continuously you are likely having an authentication problem.  The default setting for the virtual directory is to use Integrated authentication.  This will use Kerberos as a primary method of authentication.  To rule out Kerberos as an issue, you can try changing the virtual directory to use Basic authentication and specify the domain name in the Default domain textbox.  Since we are using SSL the username and password are secured.

 

At this point you need to determine why Kerberos is failing.  First change the setting back to Integrated Windows Authentication.  Once this is completed unselect Require secure channel (SSL) on the virtual directory in Secure communications on the Directory Security tab:

 

You will now be able to get a network trace of the issue.  Connect to the same URL as before without SSL encryption so we can see the failure (ex. http://pool02.domain.local/Abs/Int/Handler/F0993.dabs).  When prompted enter valid credentials and stop the network trace.  Below is an example of what you might find in the network trace:

 

In the above example we see that Kerberos is failing with a KRB_AP_ERR_MODIFIED.  This error is indicating that the Kerberos ticket was modified or is not what the server was expecting.  The issue is that it should not be using Kerberos as the name pool02.domain.local is only virtual and should not by default have a service principal name (SPN).  In this case the SPN was registered and when the Kerberos ticket request went to the domain controller the client was issued a ticket.  The issue was resolved by using SETSPN.EXE to remove the additional service principal name from the computer account.  You may also have to dump active directory using LDIFDE (ldifde -f output.txt -d "dc=domain,dc=local") to find the service principal name.  You can then search the output.txt file for the SPN.
If you are not having any authentication issues as illustrated above but still fail to download the address book, review the security configuration of the UNC path specified.  Ensure that RTCUniversalGuestAccessGroup has the following permissions:

  • Share level: Read
  • NTFS level: Read & Execute, List Folder Contents, and Read.

After verifying the permissions on the share, review the IIS settings for the virtual directory.  Below is an example of the structure for Abs.  The Files virtual directory should be referring to the UNC path in its properties. 

Ensure that we have set the correct account that will be used to access the UNC share in the virtual directory properties as in the example below:

I hope the above troubleshooting steps are useful in resolving any address book download issues you may have.  Many of the above steps can be helpful in troubleshooting other similar issues.

Lync Server Resources

We Want to Hear from You