This posting is provided "AS IS" with no warranties, and confers no rights.The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway. Please use the Microsoft Forums for support requests.
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:
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.
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,email@example.com,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,firstname.lastname@example.org,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,email@example.com,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
#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
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:
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
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.
Recently I had the opportunity of participating in a Pilot of Lync Server in a customer that has the internal network segregated by firewalls. So, one of the first questions was about the ports and protocols used by Lync Server.
The requirements of this pilot included:
The ports and protocols used by Lync are pretty well documented in the following TechNet pages:
Additionally, the Microsoft Lync Server 2010 Protocol Workloads Poster does a very good job illustrating not only the ports and protocols used by each UC workload, but also their dependencies and relationships.
Instead of letting the customer compile and aggregate all the provided technical information, we decided to provide some Visio drawings, in order to facilitate the configuration tasks of the security team. In the end we delivered the following schematics:
Please note that these were built for a pilot and not for a Production environment, thus minor errors/inconsistencies may have been depicted. If you find one, please let me know.
If you want the Visio document, it can be downloaded here.
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.
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.
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:
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 :-)
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.
In my job, I do a lot of UC pilots. Before heading to a potential customer, I usually write a small technical document with the hardware and software requirements.
Over time, I noticed that these pilots are very similar, that's why I decided to write this post. My objective is to list a small Bill of Materials for a UC pilot capable of delivering the following features:
The image below depicts the reference architecture for a pilot like this:
Finally, here's a table with the recommended Bill of Materials:
The architecture figure shows a single Edge server, because, for simplicity, we use the consolidated edge topology: the Access Edge Server, Web Conferencing Edge Server, and A/V Edge Server are collocated on a single computer.
Since the Edge server is placed on a perimeter network (or DMZ), the firewalls must be configured in order to allow the OCS network traffic. All the required ports are depicted on the next picture (the different Edge roles are shown as separate machines for better understanding, but only one server will be used).
Although Exchange Server 2007 is part of the Microsoft Unified Communications portfolio, it isn't listed here. I intentionally left it out, because usually the Exchange infrastructure is already in place. And after all don't forget, this is just for reference, there isn't such a thing as 2 equal customers with equal business needs.
What are the next steps? The immediate one is to gather the necessary technical information. I strongly recommend the following documents:
This pretty much covers the requirements for a successful UC pilot. If you already have all this stuff in place, hey, give me a call and I'll pay you a visit!