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.
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?