Home / server / Questions / 77071
Accepted
GodEater
Asked: 2009-10-22 23:34:02 +0800 CST

Office Communicator and cannot sync Address book error

  • 772

I have a recently done Office Communications Server 2007 R2 installation that I'm having trouble with. Every client (Office Communicator 2007 R2) in the office is reporting the problem "Cannot Synchronize Address Book". When I click this report for more details I'm seeing :

"Cannot synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book. If the problem persists, contact your system administrator".

We do not use a web proxy at all internally, so this message is not at all helpful.

Whilst looking for solutions to this issue, most of my googling has turned up issues with certificates as the root cause, but I'm nigh on positive this isn't the problem here. I'm able to surf to the URL being sent from the OCS server to Communicator as the Address book URL, and I get no issues reported by Internet Explorer at all.

What is concerning me most, is that checking in the IIS logs on the server which is hosting the Address book, I'm seeing no accesses at all from most of the machines in the office. The only ones which are showing up are a couple of Windows XP machines - whilst most of the others in the office are running Vista x64. They all run the same client (which I guess must be 32bit - I'm not aware of a native 64bit Office Communicator build).

I'm kind of at my wits end now - I've run out of things to try.

In case it's at all helpful - the OCS build has been homed in a resource forest seperate from the forest hosting most user accounts. Our original OCS install (vanilla 2007, not R2) used to be run out of the same forest our user accounts were in, and this had no issues with the address book at all.

One final thing is that all our clients are ALSO reporting Outlook Integration errors now (for those in the office that use Outlook - we don't run Exchange, so people are free pretty much to choose their own email client). This also wasn't a problem on the previous install of OCS.

So - any clues anyone ?

EDITS

So installing Communicator on the Front End Server itself works. The Galcontacts.db/.idx files are downloaded immediately.

Also - the MAPI Error (Outlook Integration Error) has now disappeared too (although I'm really not bothered about this).

The server is running Windows Server Enterprise 2008 SP1 if that helps at all.

EDIT THE SECOND :

Having run Fiddler on the session, I can see that communicator is trying to download the certificate revocation list from the CA in the resource forest, and is failing because there's no web server on that machine to return the list. So I'm now waiting for someone with admin privs to help me install one on it, and see where this takes me.

ms-office-communicator

4 Answers

  1. Few of quick tests you can try:

    1. Does the Web Component Validation wizard on the Front End report any error? One of it's test is checking the OCS Address book server.
    2. If you install and login the OC client on the Front End do you still get the Address book error?
    3. If you control right click on the Communicator icon in the system tray you should see the "Configuration Information..." option, if you click on this does the URL Internal For Server match the URL for your address book service?
    4. Which verison of the Communicator client are you running?

    regards Arcass

    • 1

  2. We'll add to your list of things to try...

    1. Delete GalContacts.db (%LOCALAPPDATA%\Microsoft\Communicator\) and the index from a profile on one of the computers that doesn't show a hit in the IIS logs. Close and reopen Communicator; this should force a hit against the ABS to pull down the full address book file.
    2. Use Snooper.exe and inspect the in-band provisioning data that you get from the front ends on login - the URL looks correct in there?
    3. Just to add to the confusion, I'm seeing problems with the ABS ... intermittently. I see that error sometimes, and then the error goes away. I haven't looked into it at all yet because it's not a priority at this point, but I'd be interested to see whether logging out and logging in a number of times would result in a different outcome. (You'll probably want to leave it logged in for about 10 minutes each time.)
    4. Did you check the error log for IIS also?
    • 1
  3. Best Answer

    Apparently I didn't read your second edit the other day. So if the CRL is the issue, there's a couple of options you have - the best option is to have said admin staff do the right thing with the CRL, which is to publish it to Active Directory. That's a simple matter of using certutil -dspublish. You also have other options, however. Some CAs (root CAs in particular) have a best practice where you don't even publish a location for a CRL. A CRL only needs to be located if the CA says that you should be able to locate it, primarily through the AIA or CDP. I'm guessing based on your description that the CDP has an HTTP url for the CRL (okay, the acronyms are ridiculous, sorry) and that either the CRL wasn't actually put in that location, which has to happen manually, or that location isn't available since as you've pointed out, it doesn't have an HTTP server on it. You can work through this issue; however, I think you'll be better off if you just publish the cert to AD and call it good enough. Note: if the CDP doesn't specify an LDAP location for the CRL, you may be SOL - they may have to redo a lot with the PKI in order to get that set up correctly. However, I've made the same mistakes myself in the past and it's worth fixing.

    So, hey, Server Fault! Do you have any badges for >20 acronyms in a single paragraph?

    • 1

  4. Resurrecting this old post, but I just wanted to add the two commands that did the trick for me:

    C:\Program Files\Microsoft Office Communications Server 2007\Server\Core>ABServer.exe -validateDB
C:\Program Files\Microsoft Office Communications Server 2007\Server\Core>ABServer.exe -syncNow
    • 0