Client Version Filtering for OCS 2007 R2 EE

 

I recently worked on a case with a customer who needed assistance in configuring the Client Version Filtering for OCS 2007 R2 EE. For those unfamiliar with this feature here’s a few links that cover the capabilities:

Microsoft Office Communications Server 2007 R2
Configuring Client Version Filtering
https://technet.microsoft.com/en-us/library/dd572488(office.13).aspx

To configure this using the steps in this blog you’ll also need the OCS 2007 R2 Resource Kit Tools installed:

Office Communications Server 2007 R2 Resource Kit Tools
https://www.microsoft.com/downloads/en/details.aspx?familyid=9E79A236-C0DF-4A72-ABA6-9A9602A93ED0&displaylang=en

The easiest way that I‘ve found to set this up is to use a tool in the OCS 2007 R2 Resource Kit called CvcMsiUploader.exe. In my lab I pulled down the latest public update to Communicator 2007 R2, copied it to the ResKit Folder and then ran this command:

C:\Program Files\Microsoft Office Communications Server 2007 R2\ResKit>CvcMsiUploader.exe /mode:upload /folder:oc /arch:x32 /build:fre /lang:1033 /ee:ocsr2pool.picmepicme.local communicator.msp

To which I received this output:

communicator.msp => \\ocsr2-sql-be\Updates\oc\x32\fre\1033\communicator.msp

Uploaded msi file sucessfully.

In other words, the tool copied the file up to the share and created the folder structure needed.

As a side-note, I’m not sure what to think about the ‘x32’ reference other than it must be a mix-up of ‘x86’ processors supporting 32-bit operating systems. It’s a minor detail for a Resource Kit Tool that I’m not going to wonder about since it works.

You can check what work the tool did by using this command:

C:\Program Files\Microsoft Office Communications Server 2007 R2\ResKit>CvcMsiUploader.exe /mode:verify /ee:ocsr2pool.picmepicme.local

This should return output similar to this:

C:\Program Files\Microsoft Office Communications Server 2007 R2\ResKit>CvcMsiUploader.exe /mode:verify /ee:ocsr2pool.picmepicme.local

============================================================

Processing Folder: OC

============================================================

Total number of MSI file in store: 1

Validating msi paths...

Info: All msi paths are correct

File: \\ocsr2-sql-be\Updates\OC\x32\fre\1033\communicator.msp

Architecture: x32

Build Type: fre

Language: 1033

----------------------------------------------------------

[ Skipping ]

Info: All msi in store do have same version.

Info: All paths in store contains single installer file

At this point the URL to the update looks like this: 

https://ocsr2pool.picmepicme.local/AutoUpdate/Int/Files/OC/x32/Chk/1033/Communicator.msp

The UNC to the update is:

\\ocsr2-sql-be\Updates\oc\x32\fre\1033\communicator.msp

The client actually receives the updates through IIS so let’s take a look at what this looks like from an IIS perspective; here’s the folder structure:

And here are the authentication settings on that folder:

The last step is to configure OCS so that clients are configured to use the service. You can access it within the OCS Manager at the Pool Properties:

Forest –> Enterprise Pools –> Pool Name –> Right-Click and Selection Filtering Tools and then Client Version Filter:

Before enabling this functionality you should configure it meet your needs. I recommend going through this process about quarterly or so since that’s our update cycle on the Communicator client. Here’s a link to our updates portal if you need it:

Updates Resource Center for Office Communications Server 2007 R2 and Clients
https://technet.microsoft.com/en-us/office/ocs/ee695846.aspx

I’ve had good success in keeping Communicator updated when I configure the filter as follows:

Here’s the text of my configuration:

Major version number: 3

Minor version number: 5

Build number: 6907

Qfe number: 233

Select comparison operation to perform: <

Select the action to apply to this version: Block and Upgrade

Folder that contains the upgrade images: OC

As you’ll see in the user interface there are plenty of options to configure this to meet various needs so my settings above certainly aren’t mandatory; it’s just what works for my lab. From an IIS perspective you can confirm this is working by looking in the IIS logs where you should see data similar to this:

2011-06-23 13:55:31 192.168.1.45 GET /AutoUpdate/Int/Files/OC/x32/fre/1033/communicator.msp - 443 - 192.168.1.107 Microsoft+BITS/6.7 401 2 5 0

2011-06-23 13:55:31 192.168.1.45 GET /AutoUpdate/Int/Files/OC/x32/fre/1033/communicator.msp - 443 - 192.168.1.107 Microsoft+BITS/6.7 401 1 2148074254 15

2011-06-23 13:55:31 192.168.1.45 GET /AutoUpdate/Int/Files/OC/x32/fre/1033/communicator.msp - 443 PICMEPICME\R2User 192.168.1.107 Microsoft+BITS/6.7 200 0 0 687

Note that the first two GET requests fail because the client tried anonymous authentication first and it fails (we know this by the hyphen denoting an anonymous request and the HTTP 401 response). However, the authenticated request by PICMEPICME\R2User succeeds (we know this by the HTTP 200 response).

It should be noted that ‘success’ in this context means the download to the client is successful; it doesn’t necessarily mean the client could install the download which likely will require administrative privileges on the machine to complete the installation.

I hope you find this helpful!