Tuesday, April 21. 2009
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.
OCS R2: Client Version Filter - Allow & Upgrade
In OCS 2007 R2 it is fairly easy to block certain clients from connecting to OCS, just like in OCS 2007
Weblog: OCS 2007 R2
Tracked: Jun 30, 11:23
Tracked: Sep 11, 13:04
Display comments as (Linear | Threaded)
Wow, amazing! You should get the money that was paid the guys who wrote the OCS docu.
You know what - that is one of the best comments I've ever received on this website. This really made my day. I really appreciate that!
I had a bit of a bad day and a horrible migraine - so, thank you!
I have found the msp file, but I am wondering about this folder that the clients pull from. I don't see the \\autoupdate share anywhere on the system, and when i browse IIS there is no OC folder under the Autoupdate/Int/Files folder. Do I need to manually add this folder structure in IIS and on the front-end?
Hopefully I'm missing something simple...
I guess I might have been vague in my post, but yes, you need to manually create the "OC" directory if you decide to mimic my setup. It doesn't exist by default.
I tried to leave it blank to see what it would do - but the version editor didn't let me do it.
Just to clarify, if you are on a Standard Edition server, %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files\ already exists, but %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files\OC\x32\fre\1033\ does not.. so you need to manually create that directory tree structure for it to work. Easiest way it to browse into the Files directory and just create the folders under there.
Good stuff. Hopefully we'll see some official documentation around this in the future, but in the meantime this is by far the best info around the AutoUpdate feature for MOC.
I guess I'm in a bit of a dilemma - I placed the share for the updates on a different server and cannot for the life of me get this to work. This is for an enterprise server.
Ricardo: So true. Does the OCS documentation even include any of the auto update docs? All I saw was something along the lines of "point it at your share"
I solved my issue after going over this again - I created OC manually because you can't apparently point it to the root of the share. ba bing!
Just wanted to say thanks! This is a great blog and has been very helpful!
I wish that were the case but I don't believe so. It would be great if it were included.
Just wanted to post and see if anyone else saw this issue or would have any input...
Internally this is working great, external users are failing to download the update. However if I have those same users browse to the full URL from a web browser it prompts them for credentials and then prompts them to download.
The only 3 people I have tested with are not on the domain, am trying to test with a domain machine and see if it has something to do with that. I would assume it would use the already provided credentials in communicator to authenticate though, any ideas?
It might be how you are publishing your reverse proxy for authentication passthru.
When I do a request externally from a non-domain joined computer using a web browser, I will get an authentication prompt for credentials. As long as I enter in a proper password, it sends me the file. If I abort out of the handshake, it gives me 401 access denied.
If I update the non-domain joined clients externally, I only get prompted for admin elevation - I don't get prompted for passwords.
I tested this on a standard edition, and you don't need to have the \\..\Update share, Communicator will download the update thru http.
I my case the IIS log is showing
2009-04-04 19:10:57 W3SVC1 172.20.20.20 GET /AutoUpdate/Ext/Files/OC.3.5.6907.9/x32/fre/1033/communicator.msp - 443 domain\user 172.20.20.1 Microsoft+BITS/7.0 206 0 0
2009-04-28 21:10:57 W3SVC1 172.18.0.137 GET /AutoUpdate/Int/Files/OC.3.5.6907.9/x32/fre/1033/communicator.msp - 443 inceptio\sg 172.18.0.25 Microsoft+BITS/7.0 206 0 0
Correct. Only Enterprise Edition cares about/uses the \\servername\share\ architecture due to it being a pool of servers and not a Standard Edition server.
I tried to word it as carefully as I could, but it is definitely a confusing aspect of the whole thing.
Just a note to let others know I started having Address Book issues after setting up the SPN on the pool. I found this article http://communicationsserverteam.com/archive/2007/12/17/52.aspx that discusses this and specifically states:
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.
In my case I removed the SPN and it resolved the issue with the address book but of course I do not have working automatic updates.
Just an FYI in case someone else has an issue after adding the additional SPN for an enterprise pool.
I have been having fun with this for a day or so.
There is a reskit tool for "publishing" the patches, it created the directory trees needed.
Although I have run into an issue and the only solution I can find is to turn on anonymous access to the language (1033) directory for the "int" tree.
If I try to update externally I get prompted to for my domain password, which once entered the download continue without issue (this appears to be a prompt triggered for the BITS download). After this the IIS logs show a username against the BITS log entries.
If I try to update internally I get prompted for a password, and get into a continuous loop which never ends.
Has anyone come across a similar issue?
Just a point for people trying to do some versioning of their communicator patches. That doesn't seem to work well.
I've tried the following:
Only OC worked for me.
Great post and very helpful...
But the updates only seem to work properly if the end user is configured as local administrator on their computer. This is definatley not the case in most corporate environments.
We need a solution that works for non-admins or the patches should be applied using WSUS.
Once Communicator downloads the .msp file, what context does it use to actually install it? This feature is only useful if Communicator is able to use the local SYSTEM account to perform the installation.
If the patch installation runs as the end user then this feature is useless - it would be very unusal for the end user to have the administrator rights required for the installation.
Comment: using UNC path is not recommended when firewalls isolate the OCS pool from its clients. Windows file share are known to be security holes.
Thanks you for your post, I have a issue with the download files, in fact when I tape on my browser
I can download it
But when I put
An authentification windows appears (login and password)
From the IIS log
401 1 0
From the client OC
I see the start downloading but an error mesage appears
How I modifiy the path of communicator download ?
What do I need change to work perfectly
Thks in advance
I have a message from my communicator
"OC attempted to download an update, but the file does not exist on the server. Your system administrator will need to update the file or location before an update will be availaible "
I can download the file from
But not from
Someone have an idea to fixe my issue ?
Slightly different take on this problem. My users are not administrators on their workstations and cannot install updates. I don't want them to be able to check the Tools, Options, Alerts, Automatic Updates check box.
Support tells me their is no way to disable this option and hopefully it will be in a product enhancement - which I requested - and controllable via the standard MOC ADM file.
The answer is to make a custom ADM file like below. When working with custom ADM files make sure you uncheck "Only show policy settings that can be fully managed" in the Group Policy Object Editor, View menu, Filtering... dialog each time you reopen the editor.
Here's the ADM that worked for me:
CATEGORY "Microsoft Office Communicator Policy Settings"
CATEGORY "PNHS MOC User Updates"
VALUEON NUMERIC 0
VALUEOFF NUMERIC 1
EXPLAINText="Set MOC, Tools, Options..., Alerts, Automatic Updates on or off. Users at PNHS do not have the ability to update their client therefore the option is set to disable which set the registry value to zero."
POLICYText="Disable MOC Tools Options Alerts Auto Updates"
SupportedMOC="Communicator Version 3.5.6907.83"
Using your instructions (which were fantastic by the way!) my external OC clients are getting the update. Problem is when they try to install the update I get the error that the upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, etc, etc. This is due to the fact that OC is running as Standard User, therefore it can't install the update.
All our users are non-domain joined computers. Do you know of any solution to this issue? Honestly it seems quite stupid that even though the local user is a local admin, Communicator doesn't prompt to elevate the permissions to install, it just fails.
Any ideas on how to fix this issue?
So yeah, I'm an idiot. I added the Attendant Console MSP file to the same folder as the OC MSP update thinking maybe I would be lucky and attendant clients would also automatically update. I guessed wrong. Instead, it was pushing out the attendantconsole.msp file instead of the Communicator.msp file out to the clients, thus the error. I deleted the Attendant Console file and it worked perfectly.
Any idea how to make this work for the Attendant Console? I didn't see an AC option in the client filter.
If I want to use the Client Version Filter to block someone client verion not all user. Do u know How to do? or is it possible?
I used to get this thing working. Recently i am getting errors stating that the update file is not in place. This is third client filter i am applying. Do you guys think it might be the reason ? since i have other communicator.msp files in the same location i rename the files. Any suggestions ?
Just wanted to add another huge THANK YOU!!! for writing this post. I had been searching for two days trying to figure out how to get this to work and through the hundreds (or thousands) of pages of documentation for the product. Your write up is right on the money and so very much appreciated!
Search this blog
Translate this page
Creative Commons Restrictions
Original content in this work is licensed under a Creative Commons License