Demystifying the Office Communicator 2007 R2 Client Auto-Update feature and how to setup it up

Following the release of the first Office Communicator 2007 R2 hotfix/update, which I wrote about here, I wondered exactly how to approve and install the release to the clients. The documentation surrounding this aspect has been hard to track down and vague at best. Even though there is a section specifically for Office Communicator client updates inside WSUS, it doesn't control the automated deployment of the updates.

Even though you might think the client update configuration would be buried inside the Device Updater portion of the OCS 2007 R2 server, the section you need to investigate is the Client Version Filter.

Depending on how your OCS environment is setup, you can either setup this filter at the Enterprise Edition pool level or at the Standard Edition server level. You can always test deployment on a Standard Edition server, and then later once you have verified that the update works properly, deploy it to your Enterprise Edition pool.



In the past, this section was primarily used to block older versions of software from connecting into the newer server pools. In OCS 2007 R2, this has been expanded upon to allow you to point users to a static URL page upon blocking, or better yet, offer up the updated client bits.

Because the recent update takes the OC version from 3.5.6907.0 to 3.5.6907.9, you'll want to add a version filter to match 3.5.6907.0. Select Allow and Upgrade as the action, and type in a directory name that makes sense for your organization. I tried to specify a multi-level directory, such as OC\3.5.6907.9\ and OC/3.5.6907.9/ in order to maintain version control inside the file share, but I could not get those to work properly. I relented and just used OC as the folder name.

Here is what the Client Version Filter editor looks like while you are setting up the new version entry:


Here is what the Client Version Filter editor looks like once you have set up the entry:


The Client Version Filter editor automatically filled out the directory structure as \\AutoUpdate\OC\x32\fre\1033. The fre relates to the licensing edition and the 1033 refers to the locale. I would have expected the use of x86 instead of x32, and I wasn't sure where \\AutoUpdate needed to be on the OCS server. After a bit of trial and error, here is what I figured out.

On a Standard Edition server, the location is %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files. The folder to place the communicator.msp file into is %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files\OC\x32\fre\1033\.

On an Enterprise Edition server, the location is inside the file share you specified for Device Updates, for instance, \\OCS-EE-POOL\Updates. Assuming your Device Updates file share is located at C:\OCS\Updates\, the folder to place the communicator.msp file into would be C:\OCS\Updates\OC\x32\fre\1033\, which in theory maps to \\OCS-EE-POOL\Updates\OC\x32\fre\1033\communicator.msp.

Why do I say in theory? Originally, I could not get the Enterprise Edition to work as expected. The IIS request that comes in from the Office Communicator client when it tries to request an update looks something like this:
POST /AutoUpdate/Ext/Handler/OCUpgrade.aspx folder=OC&lang=1033&mode=non-ui&arch=x32&flavor=pm&build=fre

The Office Communicator clients were receiving a 401 error and not even attempting to authenticate to the server. After digging through IIS failed trace logs, I figured out that the IIS code was trying to contact the file share as the Enterprise Edition pool name (\\OCS-EE-POOL\Updates) and not the server name of the Front End server (\\OCS-FE1\Updates). Browsing from the Run dialog box on the front end server, I could get to \\OCS-FE1\Updates\file share path just fine, but I could not resolve or get to \\OCS-EE-POOL\Updates\.

After thinking about it a while, it made sense to me. There isn't a file share resource registered anywhere in Active Directory with the OCS EE pool name, because there isn't a clustered file share involved or an actual server registered as OCS-EE-POOL.

Although there probably is a better solution than this, I ended up registering cifs/OCS-EE-POOL and cifs/OCS-EE-POOL.contoso.com as additional SPNs for the computer object of the Front End server (OCS-FE1). You can do this using SETSPN or using ADSIEdit. If you're looking for a good example of how to do this, check out this blog post related to Communicator Web Access here. Make sure to remember to register the entries as cifs/ and not http/ on the Front End server's computer account. I'm only using that blog entry as a reference on how to add a SPN entry with ADSIEdit.

As soon as I did that, I could access the file using the EE pool name like how the AutoUpdate code tries to do. The HTTP 401 errors went away and the internal clients could download the update successfully.

With that accomplished, I attempted to update an Office Communicator client connected to the Internet and not the office network. I only saw Address Book Service requests coming into the Front End server. After a few minutes, I remembered that I had not updated our ISA reverse proxy to accept /AutoUpdate/ requests. /AutoUpdate/ did not exist until OCS 2007 R2 and should be added to your ISA configuration if you are updating from OCS 2007 R1.



Once that configuration change was in place, external clients were able to update to 3.5.6907.9. Even computers that were not joined to the domain updated correctly. The mystery had been solved!

Some additional debugging/troubleshooting tips:

The telltale sign that you have set up the updates correctly is that your IIS logs on the Front End server should start showing BITS requests for /AutoUpdate/Int/Files/OC/x32/fre/1033/communicator.msp and /AutoUpdate/Ext/Files/OC/x32/fre/1033/communicator.msp and have a HTTP status code of 206 and not 401.

Your internal clients will use the /Int/ URL and external clients will use the /Ext/ URL.

You can also "fake" requests from a web browser by requesting the same path. Assuming your reverse proxy server was published to https://owc.contoso.com, you could simply request https://owc.contoso.com/AutoUpdate/Ext/Files/OC/x32/fre/1033/communicator.msp and be able to download that file.

On a client computer that is in the process of downloading the update after Office Communicator launches, you can check the status that computer by running bitsadmin /list, assuming the client is Vista SP1 or higher.



Using a trick gleamed from this blog entry here, you can also check to see if an Auto-Update has been offered and the overall status of that update. Much like the Outlook [Ctrl]-Right-Click tray icon trick, you can press [Ctrl] on your keyboard and right click on the Communicator icon in your system tray to access an additional option called Configuration Information... This is a brand new option in Office Communicator 2007 R2, but offers some great debugging information for problematic client computers.



With all of this information, hopefully this clears up some of the confusion over Office Communicator 2007 R2 Client Auto-Updates!

I wouldn't have been able to figure all of this out without the help of John Fedor! Many thanks again!

Update: Corrected "HOST" SPN to "cifs" SPN, thanks to Robert Lacroix! Also, I have since found out that there is a tool inside the Office Communications Server 2007 R2 Resource Kit that will automatically setup the file paths for you inside the updates folder - CvcMsiUploader.