Welcome to Community Server Sign in | Join | Help

OCS 2007 - Continuous prompts for Address Book download

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.

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.

- David Lebar

  Network Support Engineer - OCS

Published Monday, December 17, 2007 11:40 AM by ocsteam
Filed Under:

Comments

 

mes007 said:

Hi,

The images require to be logged in. Could you change them so that they'd be available without logging in.

Best regards,
Mika
December 18, 2007 3:28 AM
 

Robert said:

Hi
I wonder, is there a way to change the locations for ABS folder AFTER installation of OCS 2007 server.
I would like to change the location on the 3 shares added during installation, I'm thinking on ABS, Presentation and Metadata folder.
For ABS its the value of "Output location: \\server\abs", would like to place it on DFS or on another fileserver.

Best regards
Robert
February 27, 2008 6:59 AM
 

Pedro said:

Hello, i'm having some trouble with the address book download but only to clients that do not belong to the corporate domain.

These clients all get the error message that cannot syncronize address book.

I've already check through the ie and i get the download as expected ( https://poolfqnd/Abs/Int/Handler/fff.abs )

Any ideas ?

Thanks in advance
Pedro
February 29, 2008 8:01 AM
 

Mnemosis said:

Hi,
Pedro, Ihad the same problem with external users. In my case that was because I used an ISA 2006 HTTP reverse proxy.
All internal users works fine but external users. I found the issue: the OCS 2007 certificate wizard for the pool create a bad certificate request: the SAN (Subject Alternative Names) contain all the required name but in the wrong order for ISA 2006.
For instance: imagine you have a pool named pool1.contoso.com and a SIP domain contoso.com, OCS 2007 certificate wizard request a certificate with the following name SN=pool1.contoso.com and SAN=sip.contoso.com,pool1.contoso.com. This works fine for all internal users because you add this certificate on the Front-End and on the IIS web site.
But when you publish this web site through an ISA 2006 reverse proxy for external users, ISA 2006 generate an error when external users connect because the pool name doesnt correpond to the FIRST SAN entry.
The resolution is to force the OCS 2007 certificate wizard with the pool name at first in the SAN request windows when you add a certificate to your pool, like this:
SN=pool1.contoso.com
SAN=pool1.contoso.com,sip.contoso.com

I hope this help you.

Mnemosis
March 18, 2008 4:39 AM
 

srinivp said:

Hello Robert,

After OCS 2007 we can not change the ABS location form the OCS 2007 console. We have to use WMI editor to do the same. Follow the procedure mentioned in the below link for the same.

http://www.ocspedia.com/ABS/Addsrv_Set.htm

Best Regards
Srini
March 27, 2008 9:41 AM
 

BarryU said:

I am having this problem, however I am pretty sure it is something with IIS, but havent been able to find anything.  I can't browse to anything https:// on my front end server, and I have tried re-issuing and re-assigning the cert several times.
The strange thing and I think this may be where the problem is, if I try to view the cert in ISS under directory security, when I click on View certificate tab, nothing comes up.  Restarting IIS and the server does not help.
Anyone have any ideas on what could be causing this?  It was working fine before.
April 1, 2008 9:29 AM
 

mhynek said:

I got the same error message.
But the root cause of this continuous reqest for password was because I changed THE PASSWORD ON THE SERVICE ACCOUNT.
Run the IIS manager mmc.
Inside the "application pools" area, there is a gear icon called LSGroupExpApp...
Go to properties (rght-click), then the Identity tab.
It should list "Application pool idenity" and the service account is domain\RTCComponentService.
Change the password there.
Recycle gear icon (right-click) choose recycle.
May 22, 2008 9:57 AM
 

AntK said:

I am pretty sure that you should be able to modifiy the output location of the ABS share \\newserver\ABS by re-running the OCS "Deploy Pool Wizrd" and changing the settings.
June 25, 2008 2:38 AM
 

jschmidtke said:

hi,
in IIS i set on the default website the authentification on "Windows Integrated" and inheritance it to all other webs and folders. Now it works fine!
September 2, 2008 9:21 AM
 

Muhammimi said:

Hi David Lebar;

I would like to know is there any KB article to rebuild the OCS2K7 Address Book Server Virtual Directory in Front End consolidated Server.

In addition, is there any OCS2K7 Virtual Directory Hierarchy documentation as well default permission and configuration for the OCS2K7 virtual directory.
September 16, 2008 3:06 AM
 

Petri said:

One part what you have left out is, how the Communicator knows which files it should download? At least I do have two FEs and two Web Components server. Web Comp servers are serving the AB service.

From the IIS logs I can see, that communicators from other server are getting correct file by 401 first and then 200. But on the another Web Comp server I can see tries to file which does not exist and clients gets 404.
November 24, 2008 5:23 PM
 

btm said:

In my case the RTCComponentService account had no SPN while the CWAService account had both 'http/HOSTNAME' and 'http/fqdn'. I transfered those two SPNs to the former account to fix the ABS authentication issues, then deleted the CWAService account and moved it's IIS application pools to use the RTCComponentService account.
December 20, 2008 2:20 AM
 

danucalovj said:

I was having the same issue - but my problem was resolved in a different way. I was having SSL issues. What I did was uninstall the web components from Add/Remove programs, then uninstall IIS, then I re-installed IIS, re-installed the web component server, configured the SSL certificate from the main installation and FINALLY installed the same certificate on the Default web site of the web component.

Immediately after that my Communicator started working and all web pages as well.

~Jonathan
February 24, 2009 6:36 PM
 

mi74 said:

In my case authorisation when accesing http://FQDNServerName/abs/int/handler/F-0ba0.dabs goes ok (integrated windows auth. in action). But when I'm will try to connect using https, I'll get 401.2. This same if changing authentication method to basic (in properity of virtual folder - Handler). Site is added to intranet zone, and in that zone login goes automaticaly (IE7.0 properity). Any idea what's wrong?
February 25, 2009 5:33 AM
 

danucalovj said:

It also seems like an SSL issue as well, I ran into something similar. Try this: on the default website properties under directory security enable anonymous access and un-check all authentication methods below. In the same page under secure communications un-check require SSL. Now under the ABS virtual directory disable anonymous access, enable windows authentication, and set to require SSL. Make sure you have the same SSL cert on both the Default website as well as the one you configured your server with during the setup wizard. Re-start SSL and re-start your communicator client. If that doesn't work simply delete the "GalContacts" database under your application data files in your profile and re-start the communicator client.
February 25, 2009 12:28 PM
 

MarkO said:

I had this exact problem, but the cause turned out to be the fact that I had installed IIS from a non slipstreamed version of server 2003 SP2.  Once I reinstalled SP2 the problem was resolved.
March 12, 2009 1:45 PM
Anonymous comments are disabled
Powered by Community Server, by Telligent Systems