Rui Silva - UCspotting

A long time ago in a galaxy far, far away… there was a device called Microsoft RingCam:

RingCam: an inexpensive omnidirectional camera and microphone array designed for capturing meetings.

Hummm, could this be the missing link in Microsoft RoundTable evolution?

Can you notice the “subtle” differences on the video capturing head?

Oh well, at least the computer screen display didn’t change a lot from those early days:

After some thorough investigation, I realized that Microsoft RingCam was developed as part of the Distributed Meetings project from Microsoft Research:

“The project was initiated in 2001 in the Communication, Collaboration, and Multimedia Processing group in Microsoft Research with Anoop Gupta as group manager. Later Anoop Gupta toke the position of Bill Gates technical assistant and the research group was merged with Signal Processing Group in Microsoft Research with group manager Rico Malvar. The new name of the research group was Communication, Collaboration and Signal Processing.

Around 2003 a decision was made to convert the technologies, designed during this project, into Microsoft product. Ross Cutler left Microsoft Research to become architect of the new team. Microsoft researchers continued to help the product team. Three years later the product was named RoundTable and deployed for evaluation in most of the conference rooms in Microsoft. Now it is available for our customers and is the default client for Microsoft LiveMeeting and Microsoft Office Communicator. More information for this product can be found here. See Bill Gates and Jeff Rikes introducing the new product on CNN here.”

Here’s a small collection of some of the technical papers produced, as well as an explanatory video about the use of the distributed meeting technology:

• Distributed Meetings: A Meeting Capture and Broadcasting System
• PING: A Group-to-Individual Distributed Meeting System
• Automatic Head-Size Equalization in Panorama Images for Video Conferencing
• Boosting-Based Multimodal Speaker Detection for Distributed Meeting Videos
• Distributed Meetings
• VIDEO: Microsoft RingCam

I also collected some news that were published around that time:

• Microsoft RoundTable – like a webcam on steroids
• RingCam – Videoconferencing makes a comeback in 360 degrees
• Microsoft announces RoundTable (Formerly RingCam) a 360 Degree "Super Webcam”
• Microsoft develops a different way to meet online

It’s really fascinating how the vision of some people turns into one of the most fantastic collaboration products available today. Microsoft RoundTable it’s just another example of Microsoft Research motto: Turning Ideas into Reality!

Trivia

Did you know that Microsoft invested $8.2 billion in R&D in 2008? Are you aware that’s more than the combined R&D spending of IBM and either Oracle or Google?

Here’s a small excerpt from the "Shareholder Letter" in its 2008 Annual Report:

"At the heart of our success lies our commitment to innovation. No company in our industry invests more in research and development or has the same depth and breadth of talented researchers, scientists, and engineers working across the globe to create new technology breakthroughs. In 2008, we invested $8.2 billion in research and development, an increase of almost 15 percent compared with fiscal 2007."

Chances are that, if you live in one of the green countries from the picture below (courtesy of Wikipedia), and if you tried to setup the OCS 2007 R2 Edge server role, you probably felt the frustration, combined with a little bit of despair and asked yourself at some time: “Am I going nuts?”, “Did I suddenly lose my skills?” or “Did I fell into a wormhole and I am now living in a parallel Universe?”.

Why only the green countries? I will explain in detail shortly, but in order not to create too much suspense, let me just say that these countries use a comma "," as the decimal separator and not a period ".".

I've been planning on blogging about this issue for some months now, but for one reason or another, I didn't manage to do it until now. Meanwhile, some other people decide to share their experiences about the very same issue, writing them in some blog posts that I would like to recommend:

• A/V Authentication Service can't be reached...due to a comma
• OCS 2007 R2 and Localization

I would also like to add that there is now a permanent fix for the problem I'm about to describe.

The Symptoms

Imagine the perfect installation of OCS 2007 R2, where all the requirements were met, where every single detail was taken care of, where every step of the official deployment guide was followed. But, at the very end, in the test phase, you taste the bitter taste of failure as some errors emerge:

1. Users see a “Limited External Calling” error in Communicator. If they click details, they get the message: "Some calls to and from people outside of your corporate network may not connect due to server connectivity problems. Try signing out and signing back in. If this problem continues, contact your system administrator with this information".
   
   
   
2. When an external user tries to call an internal user, the call is unsuccessful with the error: "The call was disconnected because you stopped receiving audio from <user>. Please try the call again".
    
3. When you validate the A/V Conferencing Server from the OCS Front-End, you get a "Validation Wizard completed with failures".
   
   The Office Communications Server 2007 R2 Deployment Log shows the following error:
   Failure
   [0xC3FC200D] One or more errors were detected

   A/V Authentication Edge Server: Could not contact A/V Authentication Edge Server.
   To resolve this error, check for the following
   1. The outbound proxy is reachable.
   2. The outbound proxy and A/V Authentication Edge Server are in trusted server list of each other.
   3. The outbound proxy and A/V Authentication Edge Server have valid certificates.
   4. Conference Server certificate is valid.
   5. A/V Authentication Edge Server Gruu is correct.

4. At the Mediation server, the Event 25015 is logged (this is actually the responsible for the Limited External Calling issue previously described): 
   "The A/V Authentication Service returned invalid response. Connections that require Firewall traversal will not be successful.
   Response Code: 400
   Response Text: Bad Request
   Cause: Either the A/V Authentication Service is not running or unreachable."
    

The Cause

Although OCS has lots and lots of (good) troubleshooting tools, sometimes it's not easy to spot the error, even when it is right in front of your eyes.

Analyzing the Communicator log from the external user, revealed the "Version Mismatch" error. The error has to do with localization (decimal separator), which caused a string comparison to fail: "2,0" with a comma it's different from "2.0" with a period! I must confess I would never get there without the help from a Microsoft colleague.

Here's the relevant excerpt from the communicator log and a glance of the Snooper Tool:

A Workaround

To workaround this problem, change the locale setting to English/US for the local account that the A/V Edge service and the A/V Edge Authentication service use (RTCProxyService).

1. Give the RTCProxyService account local login rights (it’s quicker to just add it to the local Administrators group).
2. Logon to the OCS Edge server with the RTCProxyService credentials.
3. Open Control Panel > Regional and Language Options and change the Current format to English (United States).
   
4. Log off the RTCProxyService, log back in with the Administrator, remove the RTCProxyService from the Administrators group, restart all the OCS services and voilá! If everything else is well configured, you now have a fully functional OCS solution.

The (Definitive) Solution

Fortunately, the April updates for Communications Server 2007 R2 include a patch for this specific problem. Read the following KB article for more information: The Communications Server 2007 R2 - A/V Edge Authentication Server does not recognize a token request if the locale for RTCProxyService is not en-US/409 (and then apply the KB967831 hotfix).

The Wrong Way!

When you apparently reached a dead-end and start doubting about yourself, you usually start trying some silly things. One of the approaches I took was to add the OCS Edge server to the list of authorized hosts. Don’t do this!!! The Edge server should never be placed in the Host Authorization tab, doing so will break the communication workflow.

The (Wrong) Usual Suspect: NAT

At the beginning of the troubleshoot process, my prime suspect was NAT, since I was using for the first time one of the coolest features of OCS 2007 R2 (the A/V Edge interface can now be NAT'ed) and the symptoms were typical of NAT'ed A/V Edge interface.

There are some requirements for this particular configuration to work, I strongly recommend the reading of the excellent post by Rick Varvel: Configuring R2 A/V Edge Service for NAT.

At the end, NAT had nothing to do with the problem, I can assure you this features works perfectly.

The Butterfly Effect

The Butterfly Effect has origin in chaos theory and describes how small variations of the initial condition of a dynamical system may produce large variations in the long term behavior of the system. The phrase refers to the idea that a butterfly's wings might create tiny changes in the atmosphere that may ultimately create a tornado in a certain location.

In other words, sometimes a comma makes all the difference!

In a previous post, How to upgrade Polycom CX700 1.0.452.0 using the OCS 2007 R2 Device Update Service, I asked if someone could lend me an Office Communicator Phone Edition (OCPhone) with firmware version 1.0.199. Well, Minsoo Park from LG-Nortel (kudos for him) was kind enough to lend me one IP Phone 8540 with this old firmware version, so that I could test the OCS 2007 R2 Device Update Service is capable of upgrading it.

My first step was to provision the Device Updater with an appropriate firmware version (3.5.6907.9) for the LG-Nortel IP Phone 8540, which I immediately approved.

There was no need to modify the Client Version Filter, since I was already allowing OCPhone software version 1.0.199 and higher to connect to my OCS pool.

As soon as I plugged the device in and signed in with valid credentials, I noticed it was requesting the Address Book files, but there was no sign of it willing to contact the update service.

#Software: Microsoft Internet Information Services 7.0
#Version: 1.0
#Date: 2009-05-22 16:05:55
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2009-05-22 16:51:13 192.168.200.101 GET /Abs/Int/Handler/F-0bf7.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 2 5 0
2009-05-22 16:51:15 192.168.200.101 GET /Abs/Int/Handler/F-0bf7.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 1 2148074254 0
2009-05-22 16:51:15 192.168.200.101 GET /Abs/Int/Handler/F-0bf7.dabs - 443 DEMO\ocphone 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 200 0 0 15
2009-05-22 17:05:50 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d8b.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 2 5 15
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d8b.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 1 2148074254 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d8b.dabs - 443 DEMO\ocphone 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 404 0 0 15
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/F-0d8b.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 2 5 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/F-0d8b.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 1 2148074254 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/F-0d8b.dabs - 443 DEMO\ocphone 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 404 0 0 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d8a.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 2 5 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d8a.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 1 2148074254 15
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d8a.dabs - 443 DEMO\ocphone 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 404 0 0 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/F-0d8a.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 2 5 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/F-0d8a.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 1 2148074254 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/F-0d8a.dabs - 443 DEMO\ocphone 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 404 0 0 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d89.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 2 5 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d89.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 1 2148074254 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d89.dabs - 443 DEMO\ocphone 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 404 0 0 15
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/F-0d89.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 2 5 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/F-0d89.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 1 2148074254 0
2009-05-22 17:05:53 192.168.200.101 GET /Abs/Int/Handler/F-0d89.dabs - 443 DEMO\ocphone 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 404 0 0 0
2009-05-22 17:06:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d8b.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 2 5 0
2009-05-22 17:06:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d8b.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 1 2148074254 0
2009-05-22 17:06:53 192.168.200.101 GET /Abs/Int/Handler/D-0bf7-0d8b.dabs - 443 DEMO\ocphone 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 404 0 0 0
2009-05-22 17:06:53 192.168.200.101 GET /Abs/Int/Handler/F-0d8b.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 2 5 0
2009-05-22 17:06:53 192.168.200.101 GET /Abs/Int/Handler/F-0d8b.dabs - 443 - 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 1 2148074254 0
2009-05-22 17:06:53 192.168.200.101 GET /Abs/Int/Handler/F-0d8b.dabs - 443 DEMO\ocphone 192.168.20.115 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 404 0 0 0

The solution

The solution to this particular problem is at the very end of the Microsoft Office Communicator 2007 R2 Phone Edition Release Notes:

If the ExternalUpdatesDownloadURL and ExternalUpdatesStoreURL properties of the Windows Management Instrumentation (WMI) class MSFT_SIPUpdatesServerSetting are set to NULL, you need to use the following procedure to change the settings to update the device.

1. Click Start, click Run, and then type wbemtest to open Window Management Instrumentation Tester.
2. Click Connect. In Namespace, type root\cimv2, and then click Enter. This enables all the buttons on the wbemtest user interface.
3. Click Query, and type the following query, where $poolbackend$ is the back-end database for the pool (use '(local)\\rtc' for the OCS Standard Edition):
   select * from MSFT_SIPUpdatesServerSetting where backend='$poolbackend$'
4. This query opens one instance of this class. Double-click the instance.
5. Double-click the ExternalUpdatesDownloadURL and ExternalUpdatesStoreURL properties to edit them, and type the values for each property as follows:
   For ExternalUpdatesDownloadURL, type:
   https://**POOL_FQDN**/RequestHandlerExt/ucdevice.upx
   For ExternalUpdatesStoreURL, type:
   https:// **POOL_FQDN**/DeviceUpdateFiles_Ext
6. Click Save Property and Save Object to save the instance.
7. Verify that the Windows Management Instrumentation (WMI) values are updated by querying the class as described in step 3. The ExternalUpdatesDownloadURL and ExternalUpdatesStoreURL properties  should be set to a non-NULL value.

Updating older firmware versions fails because the devices are expecting both the internal and external download URLs to be populated in the inband provisioning data received from the pool. With a clean R2 install, those fields are not populated, and as a result, the device rejects the inband provisioning data (thanks Thijs).

After making these changes and restarting the OCS Frontend Service, I rebooted once again the IP Phone 8540 and it was magic! The device got the inband provisioning and the expected 2-step upgrade process (update first to the interim version 1.0.522.103 and afterwards to the R2 version 3.5.6907.9) ran really smoothly, as you can see from the IIS logs below…

#Software: Microsoft Internet Information Services 7.0
#Version: 1.0
#Date: 2009-05-22 17:38:28
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2009-05-22 17:40:13 192.168.200.101 POST /RequestHandler/ucdevice.upx - 80 - 192.168.20.115 Microsoft+UCPhone+Device 200 0 0 6563
2009-05-22 17:42:27 192.168.200.101 GET /DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt - 80 - 192.168.20.115 Microsoft+UCPhone+Device 200 0 0 134262
2009-05-22 17:42:27 192.168.200.101 GET /DeviceUpdateFiles_Int/OCInterim/ENU/CPE.cat - 80 - 192.168.20.115 Microsoft+UCPhone+Device 200 0 0 31
2009-05-22 18:10:09 192.168.200.101 POST /RequestHandler/ucdevice.upx - 443 - 192.168.20.115 Microsoft+UCPhone+Device 200 0 0 171
2009-05-22 18:13:02 192.168.200.101 GET /DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.9/CPE/CPE.nbt - 80 - 192.168.20.115 Microsoft+UCPhone+Device 200 0 0 172705
2009-05-22 18:13:02 192.168.200.101 GET /DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.9/CPE/CPE.cat - 80 - 192.168.20.115 Microsoft+UCPhone+Device 200 0 0 31
2009-05-22 18:15:14 192.168.200.101 GET /Abs/Int/Handler/F-0bf7.dabs - 443 - 192.168.20.115 Microsoft+UCPhone+Device 401 2 5 15
2009-05-22 18:15:14 192.168.200.101 GET /Abs/Int/Handler/F-0bf7.dabs - 443 - 192.168.20.115 Microsoft+UCPhone+Device 401 1 2148074254 0
2009-05-22 18:15:14 192.168.200.101 GET /Abs/Int/Handler/F-0bf7.dabs - 443 DEMO\ocphone 192.168.20.115 Microsoft+UCPhone+Device 200 0 0 0
2009-05-22 18:19:17 192.168.200.101 POST /requestHandler/ucdevice.upx - 80 - 192.168.20.115 Microsoft+UCPhone+Device 200 0 0 125
2009-05-22 18:21:48 192.168.200.101 POST /RequestHandler/ucdevice.upx - 443 - 192.168.20.115 Microsoft+UCPhone+Device 200 0 0 171

…and also from the Device Update Audit logs:

Logging DateTime,User Name,User Host Address,Device Type,Request DateTime,Mac Address,Serial Number,Vendor,Model,Revision,Locale,Requested<FileName;Version;TimeStamp>[# Seperated for Multiple],Response<FileName;Version;TimeStamp>[# Seperated for Multiple]
05-22-2009 18:40:12,,192.168.20.115,UCPhone,22-05-2009 10:40:06,"001B9E2CCD9A","1108006386","LG-Nortel","IP8540","A","ENU",cpe.nbt;0.0.0.0;01-01-1601 00:00:00,http://PTSTU-OCS01.demo.local/DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt;1.0.522.103;05-04-2009 20:09:14
05-22-2009 19:10:09,ocphone@demo.local,192.168.20.115,UCPhone,22-05-2009 11:10:10,"001B9E2CCD9A","1108006386","LG-Nortel","IP8540","A","ENU",cpe.nbt;1.0.522.103;05-04-2009 20:09:14,http://PTSTU-OCS01.demo.local/DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.9/CPE/CPE.nbt;3.5.6907.9;05-04-2009 20:09:14
05-22-2009 19:19:17,,192.168.20.115,UCPhone,22-05-2009 11:18:00,"001B9E2CCD9A","1108006386","LG-Nortel","IP8540","A","ENU",cpe.nbt;3.5.6907.9;05-04-2009 20:09:14,
05-22-2009 19:21:48,ocphone@demo.local,192.168.20.115,UCPhone,22-05-2009 11:21:47,"001B9E2CCD9A","1108006386","LG-Nortel","IP8540","A","ENU",cpe.nbt;3.5.6907.9;05-04-2009 20:09:14,

With this post I conclude the OCS 2007 R2 Device Update Service Troubleshooting trilogy:

1. Troubleshooting OCS 2007 R2 Device Update Service for Communicator Phone Edition
2. How to upgrade Polycom CX700 1.0.452.0 using the OCS 2007 R2 Device Update Service
3. The OCPhone Update Wars: The Return of the LG-Nortel 1.0.199

QED, quod erat demonstrandum, the Device Update Service from Office Communications Server 2007 R2 can successfully upgrade any Communicator Phone Device that has firmware version 1.0.199 or later.

A final note, there are some very, very old pre-production devices that have firmware version 1.0.111.0, which cannot be updated neither by OCS 2007 R2 nor by OCS 2007 “R1”. The pre-production devices can be updated to newer R1 firmware using the Beta3 Update Server of OCS 2007 (good luck trying to find the Beta 3 version!). However, you cannot use them against an RTM 2007 or 2007 R2 Update Server. The problem is that devices must report their brand, firmware, version, model, etc to the Update Server. The pre-production devices report an empty string for brand, model and revision, which the Update Server doesn’t understand or accept (thanks again Thijs).

One of the coolest features of Office Communications Server (OCS) 2007 R2 is the Response Group Service (also known as Automatic Call Distribution – ACD – in telephony world), a technology that’s mostly used in Contact Centers, but that can be applied in many different scenarios…

But the purpose of this post is not to describe the Response Group Service, instead is to discuss some problems I faced when configuring custom tabs in Communicator (custom tabs are the preferred method to sign in to formal groups in Response Group Service).

The problem

I followed the detailed instruction to configure the Response Group Tab. Basically there are 2 steps involved:

1. Create the custom tab definition file;
2. Configure Group Policy to apply that file to clients.

Regarding the first step, my XML file consists of the definition of 2 tabs: one for the Response Group, and other for displaying a Live Search box.

<?xml version="1.0"?>
<tabdata>
  <tab>
    <image>https://ptstu-ocs01.demo.local/Rgs/Clients/RgsOcTab.png</image>
    <name>Response Group Tab</name>
    <tooltip>Response Group Tab</tooltip>
    <contenturl>https://ptstu-ocs01.demo.local/Rgs/clients/Tab.aspx</contenturl>
    <siteid>1</siteid>
  </tab>
  <tab>
    <image>https://ptstu-ocs01/images/windows-live.png</image>
    <name>Microsoft Mobile</name>
    <tooltip>Microsoft Mobile Tab</tooltip>
    <contenturl>http://mobile.microsoft.com</contenturl>
    <siteid>2</siteid>
  </tab>
</tabdata>

The second step is also very simple: importing the Communicator R2 Group Policy extension (communicator.adm), and then configuring the setting “Tab URL” (in my case, the value was https://ptstu-ocs01.demo.local/OCTabs.xml).

The problem was that, although all the necessary configuration was in place, there was no sign at all of the 2 custom tabs I had defined previously!

The solution (and troubleshooting process)

In order to solve the problem, I had to change 4 settings.

1. According to Configuring Custom Tabs in Communicator 2007 R2, the site defined by contenturl must “be located on the intranet, or on a secure or trusted site on the internet” .(particularly if you’re using integrated authentication). The first step to solve my problem was adding http://*.demo.local to Internet Explorer Trusted Sites.
    
   
2. After modifying the Trusted Sites setting there was still no sign of the custom tabs. After a little research on the Internet, I found out that the <contactid> behavior changed in OCS 2007 R2:
   “The Communicator R2 client tab functionality has changed from what it was in Communicator 2007. In OC 2007 you could pass the contactID parameter to tabs that were listed at the bottom of the Communicator contacts display. Microsoft has changed the use of tabs in OC 2007 R2 such that you can only display static tabs at the bottom of the Communicator contacts display area. The previous functionality has been moved to the tabs at the bottom of the contact card for each user.” 
   Since I had <contactid>true</contactid> in my XML file (I omitted the <contactid> element on purpose from my previous listing), this was preventing the Response Group tab from displaying correctly. So, where was the missing tab, you may ask… Again, according to Configuring Custom Tabs in Communicator 2007 R2:
   !ELEMENT contactid (“true” | “false”) - Determines whether the tab appears in the contact card. Tabs defined without contactid or with contactid=false will appear only in the Communicator window.Tabs defined with contactid=true will appear in the contact card, and Communicator will pass the selected contact to the defined page. The default value is “false.”
   And you know what? Opening the contact card from my user (see the picture below) revealed the link to the tab.
   
   
3. Once I modified the Trusted Sites setting and removed the <contactid> element, the tabs appeared in Communicator, but the content wasn’t being shown:
   
   This kind of error is most often related with proxy settings. Changing the list of exceptions in Internet Explorer advanced proxy settings usually solves the problem.
   
4. The last configuration setting I had to change was only affecting a small subset of users that already were using Windows 7 and Internet Explorer 8.  This small group still didn’t have the tabs displayed in Communicator. After a long troubleshooting process I finally spotted the problem: in the Tab URL Group Policy I typed a backslash “\” instead of the usual “/” (picture below):
   This was the very last issue preventing the tabs from displaying correctly. I guess this is somehow related with stronger security settings in Windows 7 and IE 8.
     

Let me start by saying that, although the title of this post refers Polycom CX700 (because was this device I used), the procedures described here will probably work with other devices (e.g. LG-Nortel or Microsoft).

If you read my previous post Troubleshooting OCS 2007 R2 Device Update Service for Communicator Phone Edition, you probably noticed the comments about upgrading Office Communicator Phone Edition (OCPE) version 1.0.452.0.

When I wrote that post, I hadn’t tested anything lower than 1.0.522.34, so, to tell you the truth, I was not sure it was possible to upgrade these early (Beta) versions. Until today!

When I had the chance to put my hands on one of these early babies (thanks Paulo Silva), I didn’t think twice.

The upgrade process

As soon as I plugged the device into my test environment and tried to sign in, I got the following error:

Cannot sign in to Communications Service. Current version
does not work with the available server. Contact your
system administrator.

I immediately understood what the problem was: the Client Version Filter. Lowering the allowed OCPhone version to 1.0.199 did the trick.

After a quick reboot and still no signs of a successful upgrade, I noticed that I was getting an Update Status (0x0/404) on the phone. The IIS log confirmed the HTTP error 404 – File Not Found. The device was requesting the file /UCDeviceUpdates/ucdevice.upx, which cannot be found because the virtual dir /UCDevicesUpdate doesn’t exist.

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2009-04-15 17:47:37 192.168.200.101 POST /UCDeviceUpdates/ucdevice.upx - 80 - 192.168.20.103 Microsoft+UCPhone+Device 404 0 2 0

I’m not sure why the device requests that specific URL. In the tests I made with an even lower version, 1.0.199, the requested URL was /RequestHandler/ucdevice.upx, which is the correct one. Further investigation is needed to determine the cause of this issue.

In order to try to overcome the situation, I decided to create the /UCDevicesUpdate virtual dir, replicating all the settings of the /RequestHandler folder. Here’s how to do it on IIS 7.0 (with IIS 6.0 would probably be easier, since there is an option to redirect a virtual dir):

1. Open Internet Information Services (IIS) Manager, right click the web site and select Add Application. Name it UCDeviceUpdates, select the LSGroupExpAppPool, and point it to the same Physical path as /RequestHandler.
   
2. Select the newly created application (/UCDeviceUpdates), on the Features View select Authentication and then disable Windows Authentication.
   
   If we stop now (as I first did), we would get the HTTP Error 405.0 - Method not allowed.

   #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
   2009-04-15 18:07:35 192.168.200.101 POST /UCDeviceUpdates/ucdevice.upx - 80 - 192.168.20.103 Microsoft+UCPhone+Device 405 0 64 31

3. The Handler Mappings for /UCDeviceUpdates must be changed so that they match /RequestHandler, particularly the *.upx Script Map.
   
   

With these changes in place, the upgrade process went as expected: the device gets in-band provisioning about the update URL, downloads and installs the interim version (1.0.522.103), reboots, downloads and installs the approved version (3.5.6907.9), does a final reset and it’s ready to use with Office Communications Server 2007 R2.

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2009-04-15 18:36:09 192.168.200.101 POST /UCDeviceUpdates/ucdevice.upx - 80 - 192.168.20.103 Microsoft+UCPhone+Device 200 0 0 6531
2009-04-15 18:38:28 192.168.200.101 GET /DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt - 80 - 192.168.20.103 Microsoft+UCPhone+Device 200 0 0 139006
2009-04-15 18:38:28 192.168.200.101 GET /DeviceUpdateFiles_Int/OCInterim/ENU/CPE.cat - 80 - 192.168.20.103 Microsoft+UCPhone+Device 200 0 0 15
2009-04-15 18:46:05 192.168.200.101 POST /requestHandler/ucdevice.upx - 80 - 192.168.20.103 Microsoft+UCPhone+Device 200 0 0 2093
2009-04-15 18:49:09 192.168.200.101 GET /DeviceUpdateFiles_Int/UCPhone/Polycom/CX700/A/ENU/3.5.6907.9/CPE/CPE.nbt - 80 - 192.168.20.103 Microsoft+UCPhone+Device 200 0 0 183461
2009-04-15 18:49:09 192.168.200.101 GET /DeviceUpdateFiles_Int/UCPhone/Polycom/CX700/A/ENU/3.5.6907.9/CPE/CPE.cat - 80 - 192.168.20.103 Microsoft+UCPhone+Device 200 0 0 15
2009-04-15 18:50:29 192.168.200.101 POST /requestHandler/ucdevice.upx - 80 - 192.168.20.103 Microsoft+UCPhone+Device 200 0 0 140
2009-04-15 18:51:51 192.168.200.101 POST /RequestHandler/ucdevice.upx - 443 - 192.168.20.103 Microsoft+UCPhone+Device 200 0 0 187
2009-04-15 18:56:47 192.168.200.101 GET /Abs/Int/Handler/F-0bd2.dabs - 443 - 192.168.20.103 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 401 2 5 0
2009-04-15 18:56:47 192.168.200.101 GET /Abs/Int/Handler/F-0bd2.dabs - 443 DEMO\OCPhone 192.168.20.103 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+CE) 200 0 0 125

A final note: I didn’t use the Test Devices option, instead I approved the update (this means that all qualified devices would get the update without first testing it).

Epilogue

So far, the OCS 2007 R2 Device Update Service revealed to be capable of successfully upgrading OCPE version 1.0.452.0 and later. The early beta versions can sometimes be tricky and require some tweaks, like creating a new virtual dir (as explained in this post).

I’ve read some post regarding the 1.0.452.0 version stating that WINS is required. In the tests I made, I didn’t use WINS, only DNS (I had the UCUPDATES and UCUPDATES-R2 defined as A records and pointing to the OCS pool IP address).

I would love to test version 1.0.199. Can someone lend me one? :-)

Let me start by saying that, so far, every migration I did from OCS 2007 to OCS 2007 R2 went like a charm. Kudos for the Microsoft OCS team, who came up with a really easy process and pretty well documented: Migration From Office Communications Server 2007.

But every now and then, some minor problems occur. Recently, at the very end of the migration process, I got this error while trying to remove the legacy OCS pool:

Failure
[0xC3EC79F9] You need SQL Server, SQL Server 2000 Client Tools (for connecting to SQL Server 2000 SP4 or later) or SQL Server 2005 Backwards Compatibility Pack (for connecting to SQL Server 2005 SP1 or later) installed on this computer to be able to create an Enterprise pool.

The error occurred on the legacy front-end (OCS 2007) when I tried to remove the pool, using the Office Communications Server 2007 Management Console.

The solution is easy, the SQL Server 2005 Backwards Compatibility Pack must be installed on the front-end in which the remove operation is being performed, since a connection to the back-end database is required.

The SQL Server Backwards Compatibility Pack is part of the Feature Pack for Microsoft SQL Server 2005 and can be downloaded through this link.

And after that, well, the game was mine.

One of the big improvements with the release of Office Communications Server (OCS) 2007 R2 was the new Device Update Service, much more simple than the previous version. Goodbye Windows SharePoint Services on a different server, no more additional complexity in order to update the UC devices deployed in an organization. Now, the Device Update Service is automatically installed on the Web Components Server, which is part of the Front-end server, on a consolidated topology (the only one supported in R2).

Device Update Service supports two types of UC devices: OCS 2007 R2 Communicator Phone Edition (OCPE or Tanjay) and RoundTable (must be manually configured).

Device Update Service is mostly used to upgrade OCPE phones (LG-Nortel IP8540, Polycom CX700 and older Microsoft branded), so one could expect this process to be the most common cause of troubles and frustration. And that is, in fact, the case! Now even more, since there is a new version of the firmware for OCS 2007 R2.

Before we dive into the troubleshooting process, let us know better the Device Update Service Architecture and how it works:

In the default configuration, Communicator Phone Edition connects to Device Update Service in the following manner:

1. The first time a user starts Communicator Phone Edition and signs in, the device gets in-band provisioning information from the server or Enterprise pool hosting the device user account. The information contains the internal and external URL of the server running Device Update Service.
   If the device is turned on, but no user signs on, and no user has ever previously signed on to the device, the device sends a DNS lookup request to ucupdates-r2.<DNS domain name that was provided by DHCP> and obtains the internal and external URL of the server running Device Update Service.
2. Thereafter, when the device is turned on as well as every 24 hours by default, Communicator Phone Edition checks for updates by sending an HTTP request over port 443 to the Web Components Server hosting Device Update Service. The request includes the current version that Communicator Phone Edition is running.
3. Device Update Service returns a response containing one of the following:
   • If no approved updates exist for the current version of the firmware, the response contains downloads=0. For test devices, updates must be pending rather than approved for this to occur.
   • If an approved update exists for the current version, the response contains an internal and external URL for Device Update Service. For test devices, updates must be pending rather than approved for this to occur.
4. In the latter case, Communicator Phone Edition sends an HTTPS update request over port 443 to Device Update Service.
5. The update image is downloaded to the device.
6. The device waits for five minutes of idle activity, and then restarts to complete the update.

Obtaining and approving new OCPE updates

The latest firmware version, (3.5.6907.0, by the time this post was written), can be downloaded from the Microsoft site. The downloaded file is a self-extracting executable that contains a .cab archive with all the supported phones.

In order to upload the update file, we must run the Device Update Service Management Console: open the OCS R2 Management Console, right click the pool and select Device Updater. From the Tools menu, click Upload .cab File, navigate to the .cab file that you want to upload, and then click Open.

Check the Pending tab of the Device Update Service Management Console to verify that the new update is listed.

You can also verify that the upload process went OK by checking the shared updates folder (if you’re using Enterprise edition). For the Standard edition, the default path is %ProgramFiles%\Microsoft Office Communicator 2007 R2\Web Components\DeviceUpdateFiles. There should be a folder hierarchy like the one depicted in the following picture. Note that there are some Logs folders that I’ll cover a little bit ahead.

After the update file is uploaded, the corresponding firmware can be approved for all devices in the organization by selecting it and then clicking Approve. The revision should be more recent than the revision for the last update the UC devices received.

Prior to making the update widely available, it is recommended that you test it on some devices. To add a test device, go to the Test Devices tab, click Add, type a Friendly Name and then fill up the MAC address or serial number of the device (there’s no need to approve the update).

Restart the device and that should trigger the update process, as described before.

If the previous version of the device is less than 1.0.522.98, it will first get updated to an interim build (1.0.522.103) that comes with OCS 2007 R2. This means that, in this case, 2 upgrade cycles are necessary before the device gets the approved/pending build.

Log Files

You can use the logs in the Logs\Server\Audit\imageUpdates\ folder to audit software update requests from UC devices. There you can find some files named RequestHandlerAuditLog_<server_name>_<date>.log with the information you need to troubleshoot the update service. You can view server log files in a text editor or Microsoft Excel.

In the following example, an LG-Nortel device with version 1.0.522.34 is configured as a test device and will receive the most up-to-date firmware. Since 1.0.522.34 is lower than 1.0.522.98, the device must first be upgraded to the interim version (1.0.522.103), then reboot and finally it receives the most recent version available on the server.

Logging DateTime,User Name,User Host Address,Device Type,Request DateTime,Mac Address,Serial Number,Vendor,Model,Revision,Locale,Requested<FileName;Version;TimeStamp>[# Seperated for Multiple],Response<FileName;Version;TimeStamp>[# Seperated for Multiple]
03-06-2009 17:07:20,ruisilva@demo.local,10.1.1.123,UCPhone,06-03-2009 09:07:20,"0021630F207B","C185H001209","LG-Nortel","IP8540","A","ENU",cpe.nbt;0.0.0.0;01-01-1601 00:00:00,
03-06-2009 17:10:39,ruisilva@demo.local,10.1.1.123,UCPhone,06-03-2009 17:10:39,"0021630F207B","C185H001209","LG-Nortel","IP8540","A","ENU",cpe.nbt;0.0.0.0;01-01-1601 00:00:00,http://ocs.demo.local/DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt;1.0.522.103;16-12-2008 04:43:58
03-06-2009 17:18:54,ruisilva@demo.local,10.1.1.123,UCPhone,06-03-2009 17:18:53,"0021630F207B","C185H001209","LG-Nortel","IP8540","A","ENU",cpe.nbt;1.0.522.103;16-12-2008 04:43:58,http://ocs.demo.local/DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.0/CPE/CPE.nbt;3.5.6907.0;16-12-2008 04:43:58

In the first line, the device gets in-band provisioning information from the server or Enterprise pool hosting the device user account. After a *manual reboot*, on the second line, it gets the interim version. Finally, on the third line, and after an *automatic reboot* (notice the 8 minute gap) the phone receives the 3.5.6907.0 version.

But besides the logs from the update service,the IIS logs can be extremely valuable to the troubleshooting process. This is the corresponding IIS log from the example above (I removed some unnecessary lines):

#Software: Microsoft Internet Information Services 7.0
#Version: 1.0
#Date: 2009-03-06 16:00:51
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2009-03-06 17:07:20 10.1.1.90 POST /RequestHandler/ucdevice.upx - 443 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 124
2009-03-06 17:10:39 10.1.1.90 POST /RequestHandler/ucdevice.upx - 443 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 171
2009-03-06 17:12:57 10.1.1.90 GET /DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 137810
2009-03-06 17:12:57 10.1.1.90 GET /DeviceUpdateFiles_Int/OCInterim/ENU/CPE.cat - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 15
2009-03-06 17:18:54 10.1.1.90 POST /RequestHandler/ucdevice.upx - 443 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 187
2009-03-06 17:21:45 10.1.1.90 GET /DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.0/CPE/CPE.nbt - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 170679
2009-03-06 17:21:45 10.1.1.90 GET /DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.0/CPE/CPE.cat - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 15

Notice the line where the interim file CPE.nbt is downloaded to the phone. It takes some time (137.810 ms), because the file has a few megs.

2009-03-06 17:12:57 10.192.32.90 GET /DeviceUpdateFiles_Int/OCInterim/ENU/
CPE.nbt - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 137810

And then, notice  the line where the phone requests the most recent version available. It took 170.679 ms to download the file.

2009-03-06 17:21:45 10.192.32.90 GET /DeviceUpdateFiles_Int/UCPhone/
LG-Nortel/IP8540/A/ENU/3.5.6907.0/CPE/CPE.nbt - 80 - 10.1.1.123 Microsoft+
UCPhone+Device 200 0 0 170679

Troubleshooting Process

Now that we have a pretty good understanding of the Device Update Service, what can we do if something doesn’t go as expected? Let’s look at the troubleshooting process:

1. Reset the device and sign in with a user that is not signed in anywhere else (my advice is to create a special account for this purpose… And make sure it’s configured for Enterprise Voice!!!).
2. Make sure the Device Update Service is well configured and that the DHCP options required by OCPE are in place:
   • Device Update Service Required Components
   • Microsoft Office Communicator 2007 R2 Phone Edition Deployment Guide
3. Read Microsoft Office Communicator 2007 R2 Phone Edition Release Notes. Read this document all the way till the end, because there are important notes and suggested solutions for some common problems.
4. Confirm that a VDir named OCInterim is created under the DeviceUpdateFiles_Int and DeviceUpdateFiles_Ext folders in IIS. This folder contains the interim version (1.0.522.103) necessary for devices that are currently with version 1.0.522.98 or lower.
   
5. Open a browser and navigate to the URL that contains the update (for example http://ocs.demo.local/DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/
   3.5.6907.0/CPE/CPE.nbt). You should be able to download the CPE.nbt file.
   A common cause of problems for the Enterprise version has to do with permissions in the shared updates folder. If that’s the case, you’ll get a 500 HTTP error in the IIS log:
   

   2009-03-06 12:35:36 10.1.1.90 GET /DeviceUpdateFiles_Int/UCPhone/
   LG-Nortel/IP8540/A/ENU/3.5.6907.0/CPE/CPE.nbt - 80 - 10.1.1.1 Microsoft+
   UCPhone+Device 500 19 5 62

   One solution is to modify the ACL: add the Everyone group with Read permissions to the shared folder. Or you can also try this method, as explained by Jens: HTTP Error 500 19 when accessing OCPE firmware URLs on Windows 2008.
6. Make sure you’re using a supported device. Microsoft DV1 is no longer supported and even the interim update will not work.
7. If you’re trying to update a really old version of the software, make sure that’s not blocked by the Client Version Filter. Using the OCS Management Console, right click the pool name, select Filtering Tools and then Client Version Filter. Edit the OCPhone field accordingly.
   
8. Use the available audit update server logs and IIS logs. I’ve never used the client logs, because they require further processing, but I admit they can be useful if everything else fails.
9. On the phone About screen, validate when the device last checked for updates. On the About screen you’ll see: Last Update Status: (0x####/0x#####). The normal state should be 0×00/0 or 0x0/200. The first field is a WinInet error code. An error here would indicate a problem contacting the server. The list of possible values can be found in this KB article: WinInet Error Codes. For further explanation of these codes,please read this post: Microsoft Office Communicator 2007 Phone Edition Status Codes.
10. If you’re upgrading version 1.0.452.0, you may need to create a virtual dir called UCDeviceUpdates on the OCS server running the update service. Check the IIS logs to confirm the device is requesting that specific URL. Read this post with detailed instructions: How to upgrade Polycom CX700 1.0.452.0 using the OCS 2007 R2 Device Update Service.
11. If you’re brave enough, try to approve the update, instead of using Test Devices. Please be aware that this means that all qualified devices will be upgraded, before you properly test the update.
12. Wait 5 minutes! Remember the device will automatically update itself and reboot after 5 minutes of idle activity.

And this pretty much covers the troubleshooting process for the OCPE devices. I would like to hear from you if you have ever encountered a distinct situation that you managed to solve in a different way.

As you know, Office Communications Server 2007 Mediation Server uses a plus sign (+) to prefix E.164 numbers in the Request Uniform Resource Identifier (URI) for outgoing calls. However, certain private branch exchanges (PBXs) do not comply with RFC 3966 and do not accept numbers that are prefixed with a plus sign (+).

To make sure that OCS 2007 operates correctly with non-RFC 3966-compliant PBXs, Microsoft released an update for Mediation Server (R1), which is described in KB articles 952780 and 952785. After installing the update, it’s necessary to create a configuration file – MediationServerSvc.exe.config – with the following content:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
                 <appSettings>
                                <add key="RemovePlusFromRequestURI" value="Yes" />
                 </appSettings>
</configuration>

What about R2?

For OCS 2007 R2, the behavior changed a little bit. Microsoft incorporated the previous described workaround in the R2 binaries, but the configuration file is no longer needed. Instead, there’s a new WMI setting, RemovePlusFromRequestURI , which is described on this page: Enterprise Voice Server-Side Components:

Compatibility with PBXs That Do Not Support the Plus Sign

Actually the RemovePlusFromRequestURI is a boolean property that can be set to TRUE or FALSE. The easiest way of changing its value, is by means of a VBScript:

' RemovePlusFromRequestURI
'

  Dim objLocator
  Dim objService
  Dim objInstances
  Dim objInstance

  Wscript.Echo "Connecting to local WMI store..."

  Set objLocator = CreateObject("WbemScripting.SWbemLocator")
  Set objService = objLocator.ConnectServer(".", "root\cimv2")

  Wscript.Echo "select * from MSFT_SIPMediationServerConfigSetting"
  Set objInstances = _
    objService.ExecQuery("select * from MSFT_SIPMediationServerConfigSetting")

  If IsNull(objInstances) Or (objInstances.Count = 0) Then
    Wscript.Echo "Error: No instance"

  Else

    For Each objInstance in objInstances

      objInstance.Properties_.Item("RemovePlusFromRequestURI").Value = "TRUE"
      objInstance.Put_
      wscript.Echo "Done"
    Exit For
    Next

  End If

  Wscript.Echo ""

Run this script on the Mediation Server (don’t forget to run it using Administrator credentials) and you’re done.

To check the current value of this property (or to verify that the script worked), you can use the WBEMTest tool (also check this nice article: WBEM What?).

WMI Settings:
Namespace: root\cimv2
Class: MSFT_SIPMediationServerConfigSetting (Open Class)
Property: RemovePlusFromRequestURI
Possible Values: TRUE/FALSE

To use WBEMTest to verify WMI settings:

1. Log on to the Mediation Server as a member of the RTCUniversalServerAdmins group or an account with equivalent user rights.
2. Click Start, click Run and type wbemtest.
3. In the Windows Management Instrumentation Tester dialog box, click Connect.
   
4. In the Connect dialog box, type root\cimv2 in the Namespace box. Click Connect.
5. Click Open Class. In the Get Object Path box, type MSFT_SIPMediationServerConfigSetting, and then click OK.
6. In the Object Editor for MSFT_SIPMediationServerConfigSetting dialog box, click Instances.
   
7. Double-click MSFT_SIPMediationServerConfigSetting=”{…}”.
   
8. Scroll down to the property RemovePlusFromRequestURI and verify its value.
   
9. Close the Windows Management Instrumentation Tester dialog box.

Don’t forget to restart the Mediation Server service, after modifying this setting!

Have you noticed that after you install an OCS server, there are some additional files dropped in the root folder (C:\)? These are the temporary files of the VC++ 2008 Redistributable package, which extracts them to the root of the drive where the installation was run from.

This is the complete list of those pesky files:

11/07/2007  08:00 AM            17,734 eula.1028.txt
11/07/2007  08:00 AM            17,734 eula.1031.txt
11/07/2007  08:00 AM            10,134 eula.1033.txt
11/07/2007  08:00 AM            17,734 eula.1036.txt
11/07/2007  08:00 AM            17,734 eula.1040.txt
11/07/2007  08:00 AM               118 eula.1041.txt
11/07/2007  08:00 AM            17,734 eula.1042.txt
11/07/2007  08:00 AM            17,734 eula.2052.txt
11/07/2007  08:00 AM            17,734 eula.3082.txt
11/07/2007  08:00 AM             1,110 globdata.ini
11/07/2007  08:44 AM           855,040 install.exe
11/07/2007  08:00 AM               843 install.ini
11/07/2007  08:44 AM            75,280 install.res.1028.dll
11/07/2007  08:44 AM            95,248 install.res.1031.dll
11/07/2007  08:44 AM            90,128 install.res.1033.dll
11/07/2007  08:44 AM            96,272 install.res.1036.dll
11/07/2007  08:44 AM            94,224 install.res.1040.dll
11/07/2007  08:44 AM            80,400 install.res.1041.dll
11/07/2007  08:44 AM            78,864 install.res.1042.dll
11/07/2007  08:44 AM            74,768 install.res.2052.dll
11/07/2007  08:44 AM            95,248 install.res.3082.dll
11/07/2007  08:00 AM             5,686 vcredist.bmp
11/07/2007  08:50 AM         1,927,956 VC_RED.cab
11/07/2007  08:53 AM           242,176 VC_RED.MSI

The good news is that you can safely delete those files if they are really bothering you. But be careful! Be sure you don’t delete any other file necessary to the smooth operation of the server.

As you probably know by now, the setup process for Office Communications Server 2007 R2 has changed a little bit. One of the changes is that now you must manually install the Administrative Tools in a separate step (before, they were automatically installed with the product).

Whether you’re installing them on an OCS server or on any other x64 server you use for administration purposes, just kick the Setup Deployment Wizard and select Administrative Tools.

What about the Edge?

By now, you are wondering if the process for the OCS Edge server role is the same. The answer is YES! As you know, the administration of the Edge server is made through the Computer Management snap-in, rather than through the OCS R2 Management Console available in the Administrative Tools folder.

You only get the extended Computer Management snap-in *after* you manually install the OCS Administrative Tools.

Can I install the OCS R2 Admin Tools on a 32-bit machine?

Yes, you can. The supported platforms to deploy the OCS R2 Administrative Tools are: Windows Server 2003 with SP2 (x86, x64), Windows Server 2008 (x86, x64) and Windows Vista Business or Enterprise with SP1 (x86, x64).

Although OCS 2007 R2 is only supported on a 64-bit platform, the 32-bit Administrative Tools are available as part of the 64-bit installation media. You can find them under \SUPPORT\I386. In this folder there are a couple of files that are required as pre-requisites. Install them in the following order:

1. sqlncli.msi – SQL Server Native Client
2. vcredist_x86.exe – VC++ 2008 Redistributable
3. .NET Framework 3.5 SP1 – Download from web or use \Setup\amd64\dotnetfx35.exe
4. OCSCore.msi – Office Communications Server 2007 R2 Core Components
5. AdminTools.msi – Office Communications Server 2007 R2 Administrative Tools

The 64-bit experience is much better, because the Setup Wizard will install all the pre-requisites automatically. Just for fun, if you didn’t know the correct order for the x86 installation process, this is the pop-up you’d get when running the AdminTools.msi file:

OK, i see there’s a file OCSCore.msi, so let’s double click it. Damn! Another pop-up:

Hummm, the SQL Server Native Client must be this file: sqlncli.msi. Success, it’s installing! So, let’s try again the OCSCore.msi… Another pop-up, what else is new???!!

Running vcredist_x86.exe… Success! I’m pretty sure this was the last pre-requisite, let’s try again the OCSCore.msi. Ah, the .NET Framework 3.5 SP1, of course!!!

Did you have fun? I sure did :-)

First of all, don’t panic! Office Communications Server (OCS) 2007 R2 still has a nice graphical setup wizard that guides you through the installation process. But sometimes, for very specific tasks, the command line is your best friend.

This post is more a “note to self”, since I use this commands a lot, but I hope you find it useful too.

OCS 2007 R2

For OCS, the command-line utilities LCSCMD and RGSCOT are installed with the Office Communications Server 2007 R2 Administrative Tools. By default, they are located in the following location %ProgramFiles%\Common Files\Microsoft Office Communications Server 2007 R2.

To request a Web Server certificate from an online CA for Communicator Web Access:

LcsCmd.exe /Cert /Action:Request /sn:im.contoso.com /san:im.contoso.com,
download.im.contoso.com,as.im.contoso.com,cwa.contoso.com,cwa-server.contoso.com 
/ca:"ca-server.contoso.com\Contoso Root CA" /OU:IT /org:Contoso /country:PT 
/city:Lisbon /state:Lisbon /friendlyName:CWACertificate /exportable:TRUE 

To generate the Web Server certificate request file for Communicator Web Access:

LcsCmd.exe /Cert /Action:Request /sn:im.contoso.com /san:im.contoso.com,
download.im.contoso.com,as.im.contoso.com,cwa.contoso.com,cwa-server.contoso.com 
/filename:c:\certrequest.txt /OU:IT /org:Contoso /country:PT /city:Lisbon 
/state:Lisbon /friendlyName:CWACertificate /Online:FALSE /exportable:TRUE 

To create contact objects for Response Group Service:

RGSCOT /Create /PoolFQDN:ocspool.contoso.com /DisplayName:"Information Desk" 
/DisplayNumber:+3515555555 /PrimaryUri:sip:InformationDesk@contoso.com 
/LineUri:tel:+3515555555
 
RGSCOT /Create /PoolFQDN:ocspool.contoso.com /DisplayName:"Help Desk" 
/DisplayNumber:+3519999999 /PrimaryUri:sip:HelpDesk@contoso.com 
/LineUri:tel:+3519999999

Exchange Server 2007

When integrating Exchange Unified Messaging with OCS, there might be necessary to generate a new certificate, in order to replace the self-signed generated automatically by Exchange. This time, instead of using command-line utilities, I’ll use some Exchange Management Shell cmdlets.

To generate the request for the UM certificate:

New-ExchangeCertificate -generaterequest -subjectname "dc=com,dc=contoso,o=Contoso,
cn=um-server.contoso.com" -domainname UM-SERVER,um-server.contoso.com,
autodiscover.contoso.com -PrivateKeyExportable $true -path c:\certrequest.txt

To import the issued certificate:

Import-ExchangeCertificate -Path c:\certnew.cer

To enable the certificate:

Enable-ExchangeCertificate -Thumbprint 5113ae0233a72fccb75b1d0198628675333d010e 
-Services "POP, IMAP, UM, IIS"

This is just a sample of some commands that I generally use when installing and configuring OCS 2007 R2. There are many, many more actions that can be performed using the command line, such as preparing Active Directory, installing server roles, creating pools, moving the backend database and so on, and so on.

BTW, before you ask, there are still no specific PowerShell cmdlets for OCS 2007 R2. Let’s wait for OCS Wave “14”!

– How many public certificates do I need, in order to configure external access to my OCS 2007 pool?
– 3. One for the HTTP Reverse Proxy, one for the OCS Access Edge and one for the OCS Web Conferencing Edge.
– Even if I'm using a consolidated Edge topology?
– Yes!
– But can't I just use a super-mega-jumbo SAN certificate with all the required alternative names?
– No!
– Why not?
– Because!

Well, to tell you the truth it's not "because", it is the official support policy written in the OCS 2007 Supportability Guide, the OCS 2007 Planning Guide and the OCS 2007 Edge Server Deployment Guide.

Here's a summary of the external certificate requirements:

• For each unique IP address on the external interface that you use for the Access Edge Server and Web Conferencing Edge Server, you will need a separate certificate. We recommend that you use a separate external IP addresses for each server role, even if all servers are collocated. An external certificate is not required on the A/V Edge Server.
• Office Communications Server 2007 will support certificates with a length of up to 1024 bits.
• Office Communications Server 2007 server certificates must be configured with an enhanced key usage (EKU) extension for server authentication.
• For a list of public certificate authorities who have partnered with Microsoft to ensure that their certificates comply with specific requirements for Office Communications Server, see http://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=SupportedCAs.
• For both internal and remote clients, the CA certificate chain for the Office Communications Server 2007 deployment must be downloaded and installed to the certificate store of the client computer in the Trusted Root Certification Authorities folder.
• All server certificates must support server authorization (Server EKU 1.3.6.1.5.5.7.3.1).
• All server certificates must contain a CRL Distribution Point (CDP).
• Auto-enrollment is supported for internal Office Communications Server servers, including an array of Standard Edition Servers configured as Director.
• Auto-enrollment is not supported for Office Communications Server edge servers.
• For the A/V Edge Server, an additional certificate is required for audio/video authentication. The private key of the A/V authentication certificate is used to generate authentication credentials. As a security precaution, you should not use the same certificate for A/V authentication that you use for the internal interface of the A/V Edge Server. We recommend that you issue this certificate from an internal CA, but you can also use a certificate from a public CA

– But why can't I just use my internal CA?
– Well, to tell you the truth, it's technically possible, as long as you remember these guidelines:

• Public certificates are required if you enable Web conferencing and enable your users to invite anonymous participants (individuals from outside your organization that do not have Active Directory credentials).
• Public certificates are required for public IM connectivity, and they are highly recommended for enhanced federation. The public certificate must be from a public CA that is on the default list of trusted root CAs installed on the server.
• It is possible to use your Enterprise subordinate CA for direct federation, as well as for testing or trial purposes if all partners agree to trust the CA or cross-sign the certificate.

It is very unlikely that these requirements will change with the release of Office Communications Server 2007 R2.

Recently, I was doing some tests with Exchange Unified Messaging, but when I tried to connect to Exchange Voice Mail using Communicator R2, I got the following error:

"Incompatible security setting. 
The call could not be completed because security levels do not match"

An Exchange UM dial-plan supports three different security levels: Unsecured, SIP Secured, and Secured. The following table shows the differences in terms of Mutual TLS and SRTP for the various security levels.

When integrating Exchange UM with Office Communications Server 2007, consider the following when selecting the dial plan security level:

• Mutual TLS is required between Exchange UM and OCS, therefore the Unsecured level is not an option.
• Office Communicator 2007 clients support SRTP (Secure Real-Time Transport Protocol), therefore both Secured as well as SIP Secured security levels can be used. The encryption level that Communicator uses can be set by means of Group Policy or by changing the PC2PCAVEncryption registry key.
• If Communicator Phone Edition (aka Tanjay) is deployed, the security level should be set to Secured.

The registry key PC2PCAVEncryption (REG_DWORD) can be used to specify whether encryption is supported, required, or not supported when making and receiving audio and video calls. The supported values are:

• 0 = Support encryption, but do not require it. Should only be used with the TLS network protocol. (default)
• 1 = Require encryption. Unencrypted calls are not accepted. Should only be used with the TLS network protocol.
• 2 = Do not support encryption. Encrypted calls are not accepted.

BTW, if you're playing around with this registry key (or any other), you may find useful to know that Communicator uses the following precedence, when applying settings:

1. HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator
2. HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator
3. Office Communications Server 2007 in-band provisioning
4. Communicator 2007 Options dialog box

Further investigation revealed the following error on Communicator logs:

"SIP/2.0 415 Unsupported Media Type"

After this, it seemed quite obvious that the problem had to do with encryption, more specifically to the SRTP setting. The solution? There are 2 possible ones:

1. Change the Exchange UM VoIP Security level to "Secured" (it was SIP Secured before).
2. Create the registry key PC2PCAVEncryption and change its value to 0

One final note: the problem didn't affect Office Communicator 2007, only the R2 client, so we can assume the R2 clients will be more secure than its predecessors.

I recently had to upgrade 2 LG-Nortel IP Phone 8540 (aka Tanjay or OCPE) to the latest firmware available: Microsoft Office Communicator 2007 Phone Edition v1.0.522.101.

The device was running version 1.0.199 (1.23) of the software which was still a Beta version and had, of course, some annoying bugs.

So, how do you upgrade one of these babies? You use Microsoft Office Communications Server 2007 Software Update Service, a kind of WSUS specific for UC devices. I'm not going into details about deploying this service, for that please read Microsoft Office Communications Server 2007 Software Update Service Deployment Guide.

After you setup the OCS Update Service, you just need to turn on the device, sign-in and hopefully the device will automatically upgrade (there are a couple of additional steps, like preparing the infrastructure and approving the update, but let's keep it simple for now).

To sign-in, you must provide 3 things:

• SIP Address (user@domain.com)
• User name (DOMAIN\User)
• Password

My problems started here, I couldn't even sign-in, because the device didn't accept the certificate that was issued with my private Enterprise CA (BTW, using private certificates is 100% supported, as long as you publish the Root CA in Active Directory. I blogged about it recently and Jens Trier Rasmussen also has a great post about the subject).

The error message was "Cannot validate server certificate".

Let the troubleshooting begin:

1. Review Communicator Phone Edition Deployment Guide: CHECK!
2. Troubleshoot OCS Update Service: CHECK!
3. Anonymous FTP to the device and download system.clg1: CHECK!

What else could I do? I was about to send the devices to LG Nortel when I tried a different approach: changing the format of the user name at the sign-in window. Do you know what? IT WORKED!

The Solution:

If you have Beta Tanjay devices running version 1.0.199 of Communicator Phone Edition and don't seem to get it working, try to change the user name to one of these formats:

• user@domain.com
• domain.com\user

as opposed of using DOMAIN\user.

I'm now running version 1.0.522.101 that besides some bug fixes, it also supports R2!

[UPDATE]

Jens wrote a great article that could potentially be related to this issue: When do you need to use DHCP option 119 with OCPE powered devices?

After reviewing my environment, I confirmed that DHCP option 119 was in place, so the problems I had were probably due to some bug in the beta version.

Every OCS deployment needs the appropriate clients rolled out to the users. There are 3 client programs that almost every OCS solution must have:

• Office Communicator 2007
• Live Meeting 2007
• Office Communicator Mobile 2007

Since there has been some upgrades and patches to the RTM versions of these programs, I thought I could provide the latest download links to them.

Office Communicator 2007 (v2.0.6362.97)

This program is not free, so first of all you should download it from Microsoft Volume Licensing Services site (assuming you have a volume license agreement).

Next, you should apply the October 2008 hotfix, which will fix some issues (this update is needed in order to interoperate with OCS 2007 R2).

Live Meeting 2007 (v8.0.6362.91)

• Microsoft Office Live Meeting 2007 client - KB957491
• Conferencing Add-in for Microsoft Office Outlook - KB957979

Office Communicator Mobile 2007 (v2.0.467.0)

• Microsoft Office Communicator Mobile (2007 Release) - Communicator Mobile runs on Microsoft Windows Mobile 5.0 or 6.0 software for Pocket PC and smartphone devices.