BlackBerry® Client Support for OCS R2

I have been asked several times recently about the BlackBerry® client support for OCS R2 (RIM makes a BlackBerry client that works with OCS. You can read more about it in my original post: Mobile Options for OCS).

The short answer is that OCS R2 is not supported, however there is a workaround that amounts to leaving an OCS R1 CWA (Communicator Web Access) Server for the BlackBerry client to use after upgrading to OCS R2. Trying to install an OCS R1 CWA after upgrading to R2 will not work. You must leave an OCS R1 CWA server intact before upgrading. My understanding is that OCS R2 Active Directory changes will not make it possible to install an OCS R1 CWA after the fact.

The official workaround is described in more detail here: BlackBerry Enterprise Instant Messaging is not functional with Microsoft Office Communications Server 2007 R2.

The issue is that the BlackBerry client uses the Web API used for R1 Communicator Web Access (the Asynchronous JavaScript® and XML (AJAX) API) and Microsoft no longer supports this API in the OCS R2 version of CWA.  There are no current plans at this time to re-release or support this API in future releases.

(BlackBerry® is a registered trademark of Research in Motion Limited).

The OCS 2007 Automatic Sign-In Troubleshooting Tool V2.0

I released a small free troubleshooting tool back in October 2008 to help diagnose Communicator automatic sign-in issues.  It queries all the possible DNS records that Communicator could use to connect to the OCS server, and displays all the associated matches on the client computer.

I have made some significant improvements based on feedback and rolled it up into Version 2.0. Here are the improvements:

• The preferred DNS match (that Communicator will first attempt to use) is highlighted in the results.
• The type of DNS record that matched (e.g. SRV or A record) is displayed in the results.
• The availability of the Port associated with any DNS match can be tested with a single-click.
• Provides a warning if the record being used is TLS and the SIP domain does not match the FQDN of the OCS server/pool.
• The installed version of the Office Communicator client is shown (if one is installed).

Free Download & Additional Details: http://www.insideocs.com/tools/MOCLogin.htm

Here is a screenshot of version 2.0

For more information about the Communicator Automatic Sign-In process, see my other blog postings:

• DNS Records and Office Communicator Automatic Client Sign-In
• Automatic Office Communicator Sign-In (Part 1 – The Correct DNS Service Location (SRV) Record)
• Automatic Office Communicator Sign-In (Part 2 – ensuring the correct Subject Name on the Certificate)
• Automatic Office Communicator Sign-In (Part 3 – ensuring the client trusts the issuing Certificate Authority)

Missing Share Desktop Feature in Communicator R2

Recently I have been involved in several cases involving users on Windows XP SP3 machines who have upgraded to the Communicator R2 client and do not have the Share Desktop feature available in Communicator R2. The whole “Share” option is completely missing from the right-click menu on a user contact!

In all cases installing MSXML 6.0 SP1 and restarting Communicator R2 has resolved the issue.

As per the Office Communications Server 2007 R2 Client System Requirements the minimum Operation System requirements for Windows XP is only SP2, but it appears the Share feature has a dependency on a more recent version of MSXML (or it is getting uninstalled during the upgrade process).  Despite no mention of this prerequisite in the Communicator R2 Deployment Guide, Release Notes, or System Requirements, I found a TechNet article stating that indeed MSXML 6.0 is a requirement for Communicator R2.

Desktop Sharing is one the best new features of Communicator R2 (see my previous post: Communicator R2 Desktop Sharing Rocks!).

OCS WMI Reference

OCS installs a set of Windows Management Instrumentation (WMI) classes that expose a wealth of information on everything from global settings about an OCS deployment, OCS user settings, or configuration information about a particular server. These classes can be used to programmatically gather configuration information, manage an OCS environment, and automate administrative tasks using a Windows Scripting Host language or Powershell.

The WMI classes that are installed with the OCS Administrative Tools and Server Roles are part of the Office Communications Server Management API.  Below I provide a handy reference to the most useful MSDN OCS WMI information.  Note:  R2 = OCS 2007 R2; R1 = OCS 2007.

Description	OCS 2007 R2	OCS 2007
OCS WMI Reference Portal Start here if you are unfamiliar with the WMI classes.	http://msdn.microsoft.com/en-us/library/dd146871(office.13).aspx	http://msdn.microsoft.com/en-us/library/bb679969.aspx
OCS WMI Class Reference A complete reference to all the available classes and their respective details.	http://msdn.microsoft.com/en-us/library/dd146501(office.13).aspx	http://msdn.microsoft.com/en-us/library/bb680173.aspx
WMI Class Management Scopes and Roles (*) What classes are available on which server roles (or admin tools installation), and what scope a class has.	http://msdn.microsoft.com/en-us/library/dd130068(office.13).aspx	http://msdn.microsoft.com/en-us/library/bb680173.aspx
WMI Error Messages  What specific error codes mean (which can be difficult because of the WMI provider architecture).	MSDN WMI Error codes returned by the Office Communications Server 2007 WMI provider MSDN WMI Error Constants How to track down the WMI error in OCS (from Joe Calev’s WebLog)

* Note: Practically speaking, the class scope affects your ability to use the class in two ways:

1. The WMI class might only be available on a particular machine (server role), meaning your script will need to remotely connect to that machine to get access to it. If there is a “*” in the Admin column, you need to connect remotely to the machine.
2. You need the appropriate access rights to a particular scope if it is a Singleton.  For example, if your script is running in a child domain, and a particular class is can only have one instance in the Global scope (AD), the user running your script needs permissions to access to the parent AD domain.

Importing and Exporting OCS User Contacts

There are several administrative uses for manipulating user contacts – the two primary uses are backup & restore, and inserting a standard set of contacts for an organization or department. There are two options available to import and export user contacts which I explain below.

 1) Command Line Tool (DBIMPEXP.EXE)

DBIMPEXP.EXE is a little-known tool which can be used export or import a contact list for any user hosted in an OCS Enterprise Pool, or OCS Standard Edition server. The tool is available in one of three places:

1. On an OCS 2007 Front-End in the C:\Program Files\Microsoft Office Communications Server 2007\Server\Support directory.
2. On an OCS 2007 R2 Front-End in the C:\Program Files\Common Files\Microsoft Office Communications Server 2007 R2\Support directory.
3. In the ‘Support’ directory on the OCS 2007 or OCS 2007 R2 installation media.

 In the same directory there is a DBIMPexp.exe Readme file that gives good information on usage and a FAQ.

 With an Enterprise pool configuration, the big difference on the command line is the need to specify the backend SQL server with the /sqlserver switch. Here are 2 examples of how to use this tool:

• To export the contact list for all users in an Enterprise Pool:  dbimpexp.exe /hrxmlfile:contacts.xml /sqlserver:<Pool SQL Hostname>
• To import a contact list for a specific user homed on a Standard Edition server:  dbimpexp.exe /hrxmlfile:contacts.xml /user:<sip URL>

 2) Using WMI (via a Custom Script or the LCSAddContacts.wsf Resource Kit Tool)

Two WMI class expose user contact information. The MSFT_SIPESUserContactData class specifies a single contact for an Office Communications Server user, and the settings for a contact group are represented by the MSFT_SIPESUserContactGroupData class.

You can use your favorite scripting language (VBScript, Jscript, or Powershell) and write a custom solution, or you can use the Windows Script LCSAddContacts.wsf in the OCS Resource Kit. This resource kit script uses the above mentioned WMI classes and allows programmatic adding of contacts for OCS users.

Free Microsoft Press E-Books: OCS 2007 R2 Resource Kit & Programming for Unified Communications with Microsoft OCS 2007 R2

This has been picked up by a few blogs recently. It is such a good offer, I thought I would get the word out also.

I can vouch for the OCS 2007 R2 Resource Kit being an excellent resource, and for a limited time you can get a free digital copy of it and “Programming for Unified Communications” from Microsoft Press.

Click the appropriate book below to link to the MS Press site where you can register and get your free E-Book.

Six Tips for Deploying OCS R2 with OCS R1

Being familiar with these 6 items before introducing an OCS R2 pool into an OCS deployment (with an existing OCS 2007 R1 pool) could save you some valuable time and frustration.

Familiarize Yourself with the Microsoft OCS R2 Migration Guide
The TechNet online migration guide is available here: Migrating From Office Communications Server 2007. Note, if you are coming from LCS 2005, there is a migration guide available as well: Migrating From Office Communications Server 2005.

Move your OCS Global Settings from the System Container to the Configuration Container in Active Directory
See the “Move Global Settings” in the “OCS 2007 R2 Migration from 2007” guide. Aaron Tiensivu has a very practical good write-up about the process and the associated details: http://blog.tiensivu.com/aaron/archives/2009/01/06.html.

Ensure your OCS 2007 Servers are Up-to-Date

There have been several OCS 2007 high priority updates in the last year; some of them will help your OCS R2 co-existence. Knowledge Base Update 956389 from November, 2008 addresses several issues for example, and you will want to have that update package installed. Most updates are applicable to all OCS server roles. For more updates and the current top OCS issues, visit the Office Communications Server 2007 Solution Center.

 

The R2 Edge requires an R2 Pool or R2 Director

An OCS 2007 (R1) Director or Front-End is not a supported next hop for an OCS R2 Edge.

 

Side-by-Side OCS R2 Edge Server Has Implications

It is not possible to deploy an R2 Edge and R2 Director side-by-side with a R1 Edge and maintain the PIC and Federation functionality for the newly migrated R2 pool users. This sounds more complex than it is. The external DNS entries can only point to one inbound Edge entry-point, so you cannot have both the R1 and R2 Edge running in parallel.

 

The R2 Migration Guide calls this out in the “Choose a Deployment Strategy” (http://technet.microsoft.com/en-us/library/dd572317(office.13).aspx) section: “‘Federation’ and/or ‘PIC’ functionality is not possible for any R2 migrated user until after the edge has been also been upgraded to R2”.

 

The OCS 2007 and OCS 2007 R2 Administrative Consoles Cannot Be Installed on the Same Computer

See my previous blog entry regarding Quick Facts about the OCS R2 Administrative Tools.

 

OCS R2 Administrative Tools – Quick Facts

As many OCS R1 deployments move to OCS R2, mixed deployments with both OCS R1 and OCS R2 pools are becoming more common.

Here are some notable reminders about the OCS  R2 Administrative Tools in a mixed deployment that you should know about:

1. The R1 and R2 Admin Tools cannot be installed side-by-side together on the same machine.
2. The R1 and R2 Admin Tools can only administer their respective OCS server versions). For example, the R2 Administrative Tools cannot be used against an R1 pool.
3. The R2 Admin Tools are not supported on a Windows XP O/S.  Windows 2003 SP2, Windows 2008, and Windows Vista SP1 are supported.  For Vista and Windows 2008 there are some pre-requisites you must install first (follow the links).
4. Although OCS 2007 R2 is only supported on a 64-bit platform, the 32-bit Administrative Tools are available in the Support\i386 directory of the R2 installation media.
5. Active Directory Users & Computers is not automatically extended for R2 management like the R1 Admin tools did.

Troubleshooting Microsoft Office Communicator Issues 101

Much has been written about troubleshooting Microsoft Office Communicator issues. In this blog entry I wanted to highlight and simplify two steps that will help you catch most problems without having to do more time consuming troubleshooting.

1) Know Which DNS Records are Being Used by Communicator

Communicator relies heavily on DNS to figure out which OCS server to connect to.  Knowing how Communicator uses DNS, and what DNS records are being returned with the client DNS settings, is the key to debugging most issues.

My previous post, DNS Records and Office Communicator Automatic Client Sign-In, summarizes how Communicator uses DNS to connect to the server.

My Automatic Sign-In Troubleshooting Tool will query the local client DNS for all the DNS records Communicator might use, and display which ones match.

Knowing what DNS records are being used and which server Communicator is connecting to will help you understand the logging files in the next step.

2) Turn on and Use Communicator Logging

a) Turn on Communicator Event Logging (Options | General | Turn on Windows Event logging for Communicator)

This will produce explicit Application event log entries for any issues Communicator is experiencing.  For example: “Communicator could not connect securely to server sip.example.com because the certificate presented by the server did not match the expected hostname (sip.example.com)”.  There may be additional Informational or Warning log entries that provide additional context.

b) Turn on regular Communicator Logging (Options | General | Turn on logging in Communicator)

This generates a debugging log file in %userprofile%/Tracing (e.g. the filename will look something like “Communicator-uccapi-0.iccapilog”).  This log file will give specific details about what Communicator is doing internally. For example, we can clearly see in this log file there is a DNS hostname lookup failure:

• 06/05/2009|10:26:45.553 700:EE8 INFO  :: QueryDNSSrv – DNS Name[_sipinternaltls._tcp.example.com]
• 06/05/2009|10:26:45.563 700:FAC INFO  :: domainName:quest.com: serviceName:sip: transportName:tls:
• 06/05/2009|10:26:45.563 700:EE8 ERROR :: QueryDNSSrv GetDnsResults query: _sipinternaltls._tcp.example.com failed 9
• 06/05/2009|10:26:45.563 700:EE8 ERROR :: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b

(Note this file can be opened in Notepad even though it does not have a .txt file extension).

Taking these first steps will go a long way in understanding how Communicator is behaving.

The Microsoft TechNet Library has a more good information on troubleshooting specific Communicator R2 Features: http://technet.microsoft.com/en-us/library/bb963945.aspx.

Webcam’s, Headset’s, and Handset’s Optimized for Microsoft Office Communicator

Choosing the right end user devices for your OCS roll-out is important and not easy considering all the choices in the market.

If you are going through this process, the following Microsoft TechNet resource is a good start: http://technet.microsoft.com/en-us/office/ocs/bb970310.aspx. It lists all the webcam’s, headset’s, handset’s, speakerphones and desktop phones that have the Optimized for Microsoft Office Communicator designation, which basically means they have been tested and qualified by Microsoft as providing a high level of quality right from installation to feature usage (including a high quality audio/video experience).

I’ve had good personal experience with several of the Microsoft LifeCam webcam’s (VX-7000 and VX-5000). Although this site doesn’t list any Logitech devices, I’ve also had heard good experiences with the Logitech QuickCam webcam products.