Yes, this is old news and there’s about 462 blog entries (ok, that’s a made up number, but there are a lot) about how to force Communicator 2007 R2 to do an Address Book (Galcontacts.db) update. These blog entries will talk about the July 2009 update for Communicator 2007 R2 and how it introduced a random delay of 0-60 minutes for Communicator 2007 R2 to download an updated GalContacts.db to prevent the network from getting hammered by so many clients downloading an updated GalContacts.db all at the same time. And yes, these blog entries also talk about a registry entry you can create called GalDownloadInitialDelay and creating a Dword set to 0 in order to force Communicator to do an instant update.
Some blog articles that talk about this include:
https://www.tincupsandstring.com/2009/12/01/forcing-address-book-download/
https://www.markc.me.uk/MarkC/Blog/Entries/2009/12/17_Force_Downloading_the_Address_Book_in_OCS.html
Now I’m sure you are asking yourself why I am creating this entry? Is it just to repeat information that’s already out there? Of course not!
So, Communicator 2007 R2 is a 32-bit (x86) application. That registry entry works perfectly fine on x86 systems. But, if you are running on a x64 system, it won’t. Why? Well, because when you run x86 applications on a x64 based system, it utilizes a system in Windows called Windows on Windows (WOW64). WOW64 has its own section within the registry called Wow6432Node.
So let’s say we take the registry key for our Communicator x86 (Communicator x64 not available) and run it on an x86 system. The following registry key works fine:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator]
“GalDownloadInitialDelay”=dword:00000000
But let’s say we have an x64 system. The above registry key will not work. We need to utilize the WOW6432Node part of the registry. The following registry key works for x64 systems:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Wow6432Node\Policies\Microsoft\Communicator]
“GalDownloadInitialDelay”=dword:00000000
Please make sure you back up your registry before making changes as making changes to the registry can be harmful to your system if not done properly.
I managed to trace this issue back to CRL on my OCS server. To test this there is a reg key in Win 7 (XP you have to create it) which you will need to change the Value of 1 to 0 as below. For XP just create this key.
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings
CertificateRevocation
Value = 0
Sign out and back in to communicator. Check your sip profile to ensure that the idx and db files download noting that this could take as long as 60 minutes to download.
If this key change works then you will need to check your CRL distribution points on the certificate on your OCS server to make sure its valid.
There is something still no right in to all this. If I apply the registry key hack then the Address Book is downloaded by the OC Clients but if I don't apply it, the Address Book is not downloaded (I have waited 24 hours). The OC client doesn't report any error such as: "Cannot syncronize with the corporate address book. This may be cause the proxy server setting in your web browser does not allow access to the addres book."
So my question is, the OC clients should be updating on their own. The reg hack is a hack and not a solution to this problem. What am I missing here?
HKEY_CURRENT_USERSoftwareWow6432Node does not exist on Server 2003 x64 it only exists on Windows 7 and server 2008
What is the "Communicator" Key does not exist? I run Win7 32 bit and cannot find the key, should i create the key?
Yes, you need to create the key. It does not exist by default.
FYI – The quotation marks in your registry entries need to be changed to regular quotations before you can import them using a .reg file (for me, anyway).
Thanks for the heads up. I've used the registry keys though as they are and seemed to work fine. Out of curiosity, what OS are you using?
JaBier,
It might also have to do with the CRL not being available to the client – check that the CRL location in the certificate is available to the client, if not (and you are using your own internal CA) you can change / add CRL paths in the CA Authority utility before re-issuing new certs.
Thanks, but I have a problem with this question.
My issue is my systems says ALWAYS "Cannot syncronize with the corporate address book. This may be cause the proxy server setting in your web browser does not allow access to the addres book."
I've search this question in forums, msoft and others, but I have still the issue.
Can you help me? any idea ?
Thanks
JaBier,
That error can be caused by several things. Make sure that Communicator is patched with the latest MSP. Make sure Outlook is patched. Make sure Windows is patched. Make sure the Front End certificate is attached to the Default Website in IIS on your Front End Server (Web Components Server which would be the Front End on an OCS 2007 R2 Consolidated Server). You also want to make sure that the Internal Web Farm FQDN is set correctly (Standard Front End and the Internal Web Farm FQDN would be the FQDN of your server and Enterprise Front End the Internal Web Farm FQDN would be the Pool FQDN).
Hope that helps.
Hi Mr. Elan, this is Jayden from Temasek Polytechnic, Singapore.
We are now doing our finaly year project and it is something like your OCS.
Would it be possible to have youe contact as we have so much to ask you.
:)
We have like 3 computers, and one dual-boot for Vista and Windows Server 2008, one XP install MOC and one windows server 2003 with Exchange Server 07.
Now having problem installing OCS on Windows server 2008 :(
And we want to ask your permission that can we follow something like your setup of OCS 07 R2? But maybe not so complex haha..
Hope to hear from you soon.
PS. Would be my honor to have you in my msn. [email protected]. :)
Thanks, and its really great to point everytime on the differences of x86 and x64 regarding communicator.
Most of these registry hacks were introduced far after RTM, and it seems the official GIGA-CHM will never include (or its just in a huge delay) a comprehensive list of all these finetunes.
I just forgot to say: as long as the everyday working state of ABS contains so many "mysterious" variables, we need such into-the-deep community posts like yours.
(I am working with OCS since the release of LCS2005, but it still has many-many nuances that I was not able to decipher.
Great info Elan. Don’t come across too many orgs with x64 deployed just yet, but 90% of the time we’re using this to test on the client’s IT team workstations, who are likely to be running at least some 64 bit.
Thanks. Ya, it was driving me mad why it wouldn't work. But then I remembered reading Matt McGillen's blog entry on QOS and x64 clients and him using the WOW6432Node section of the registry.
http://blogs.pointbridge.com/Blogs/mcgillen_matt/…