Inside OCS » Pools

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

Curtis Johnstone — Wed, 29 Jul 2009 20:02:51 +0000

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:

Six Tips for Deploying OCS R2 with OCS R1

Curtis Johnstone — Wed, 24 Jun 2009 14:22:55 +0000

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.

An important updated tip (tip #6 – a bonus), if you have Blackberry users, consider keeping an OCS 2007 R1 CWA server so that they are still able to connect to the OCS 2007 R2 infrastructure. See the Inside OCS blog entry BlackBerry Client Support for OCS R2 for more information.

1) 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 .

2) 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.

3) 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.

4) 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.

5) 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″.

6) 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 – Summary of the Changes to Server Roles

Curtis Johnstone — Tue, 10 Feb 2009 15:23:04 +0000

In light of the new OCS R2 server roles and capabilities, here is a summary of the significant changes on the server side and topology (from OCS 2007).

Changes to Existing OCS 2007 Server Role

OCS 2007 Role	Change(s)	Notes
Front-End	Several key changes: · Application Sharing Server Added (1) · Device Update Service Added · Telephony Conferencing includes PSTN dial-in audio bridge capability	The Application Sharing Server ships with 4 new voice and conferencing applications (see below). The Device Update Service can be used to keep your R2 Communicator Phone Edition and Microsoft RoundTable devices up to date.
Archiving & CDR	CDR is removed and the Archiving capability is a dedicated R2 role.
QoE	Becomes the R2 Monitoring role (which includes the CDR functionality).
Communicator Web Access (CWA)	CWA R2 now enables desktop sharing and conferencing calling.

(1) The Application Sharing Server ships with 4 new UC Applications (implemented as services on the OCS R2 Front-End in addition to the Application Sharing service)

a. Conferencing Attendant – Provides the ability for PSTN users to dial into a conference.

b. Conferencing Announcement Service – Enables audio notification when users join or leave a conference.

c. Response Group Service – Enables the creation of automated response groups by users to route or queue incoming phone calls to designated agents.

d. Outside Voice Control – Enables call control functionality for mobile phones that are not enabled for enterprise voice.

New OCS R2 Server Roles

New Server Role	Notes
Monitoring	Includes QoE and Call Detail Record (CDR) functionality. The QoE functionality consists of the OCS 2007 QoE functionality plus many new metrics and redesigned reports.
Group Chat Server	Enables users to create and participate in persistent chat rooms. Archival of chat room content can be achieved by deploying an optional Group Chat Compliance Server.

A complete list of the capabilities enabled by the OCS R2 server roles is available here: http://www.microsoft.com/communicationsserver/en/us/capabilities.aspx Key Topology Changes

Topology

Change

Expanded Edition Server Roles

Enterprise Edition Expanded Topology is no longer a preferred deployment scenario. Consolidated pools are the recommended deployment option. The Expanded pool options is not available in the R2 Pool Setup wizard.

Edge

A consolidated edge role is the only supported R2 edge topology. Multiple servers behind a load balancer is recommended and supported for redundancy and high availability.

Managing the Size of OCS 2007 Contact Lists

Curtis Johnstone — Mon, 01 Dec 2008 21:55:57 +0000

I was surprised to recently learn that the Presence functionality typically ranks #3 in bandwidth usage in most OCS 2007 deployments (behind Audio/Video and Application Sharing). The simple act of updating Presence for a contact consumes negligible bandwidth, but when you are dealing with large contact lists (e.g. 200+ contacts) with Enhanced Presence, the aggregate bandwidth consumed shows up on the overall bandwidth radar.

If the average size of your users’ contact lists (aka buddy list) is the important number, not necessarily the maximum size of the contact lists you allow your users to have. How do you know the average contact list size in your deployment, and how can you control it?

Note: the default number of contacts at the pool/server level is 150, and 1000 on the Office Communicator 2007 client. The lower number will take precedence.

What is your average contact list size?

You can report on the both the average number of contacts per user, and the maximum number of contacts per user directly in the OCS management console:

Click on the Enterprise Pool (or Standard Edition Pool)
Select the Database tab
Under “User Summary Reports” click the “Go” button

How can you control the maximum number of contacts per user?

The maximum number of contacts any one user can have can be set at the pool level, and on the client side (as a Microsoft Office Communicator GPO setting).

To set it on all Front-End servers in a Pool:
• Expand Enterprise pools in the managment console, right-click on a Pool and select Properties, select “Front End Properties”, and go to the General tab.
• For a Standard Edition Server, expand Standard Edition servers, right-click the pool and select Properties, Front End Properties, and go to the General tab.

The maximum you can set at the pool level in OCS 2007 and OCS 2007 R2 is 1000.

The set this on the Office Communicator client, there is a GPO settings (MaximumNumberOfContacts), that can be specified. The default is 1000, which is also the maximum that this can be set to. You can find this and other GPO settings here:

Differences between OCS Consolidated and Expanded Enterprise Pools

Curtis Johnstone — Thu, 02 Oct 2008 20:15:07 +0000

One of the goals of this blog is provide answers to important questions or issues that the public documentation does not clearly address. I recently encountered such an issue while trying to definitively determine the best OCS pool type in a relatively small deployment (about ~3500 users): Consolidated or Expanded.

The basic differences between Consolidated and Expanded are well documented in any of the Microsoft OCS Deployment and Planning Guides, so I won’t cover the basics here.

Expanded pools are generally only required for much larger deployments, but we foresaw the need for additional Web Conferencing resources in the future. The thought of being able to just add a dedicated server for the Web Conferencing needs was attractive. However, by definition, a Consolidated pool requires that all roles (except the Back End) be installed on each member server, thereby negating the possibility of a dedicate Web Conferencing role. I have witnessed multiple roles being installed on servers in an Expanded pool, so I was left wondering if we could deploy an Expanded pool, install all primary roles on one member server, and then install an additional dedicated Web Conferencing role (on a separate physical server) when the need arose.

If this is possible, it begs the question: “why have the Consolidated and Enterprise pool definitions if you can mix-and-match roles on member server(s) regardless of the pool choice”.

While there are still some unanswered subtle questions, here are some interesting and important points uncovered so far:

1. While the first step in creating an OCS Enterprise Pool (with the deployment tool) explicitly asks whether it will be a Consolidated or Expanded Pool, nothing technically imposes limitations on the collocation of the roles on the member server(s). You can, for example, choose an Enterprise Pool, and co-locate one or more roles on a member server.

2. The definition and use of Consolidated versus Enterprise therefore appears to be to simplify the deployment of the most supported (and recommended) configurations. When your pool deployment goes outside of these definitions, you may need to tweak settings with WMI to make all the functionality work smoothly. I am looking into more specifics on this.

Until this is publicly made clear, you are best to stick with a deployment that follows the basic pool definitions unless you are confident that you understand how to successfully deploy the custom role collocations you have in mind.

A frustrating aspect about this question is that beyond the basic pool definitions, there doesn’t seem to be any Microsoft documentation outlining the supportability on role collocation in an Enterprise pool.

For your benefit, here the references found in the existing documentation:

1. Page 48 of the Office Communications Server 2007 Planning Guide

“If you are deploying Enterprise Edition, Expanded Configuration, you must install the Web Conferencing Server and A/V Conferencing Server on separate computers from those hosting the Front End Servers”.

2. Page 3 of the Microsoft Office Communications Server 2007 Technical Reference

“In an Enterprise Edition expanded configuration, the A/V Conferencing Server and Web Conferencing Server roles are distributed and run on separate servers”

Note: I have seen a successful deployment with the Front End and Web Conferencing installed on the same server in an expanded pool.

Automatic Office Communicator Sign-In (Part 2 – ensuring the correct Subject Name on the Certificate)

Curtis Johnstone — Sun, 14 Sep 2008 04:00:24 +0000

A crucial setting to make automatic Office Communicator sign-in work is ensuring that the correct Subject Name (and possibly Subject Alternative Name) is specified on the certificate which resides on the OCS server where the Communicator client connects (e.g. on the Front-End or Director role). When you look at the Certificate details, the Subject Name is listed as the “Subject” property.

The basic requirement for the Subject Name on the certificate is that it match the DNS FQDN of the hostname that the client is connecting to. For example, if Office Communicator determines that it needs to connect to the FQDN host1.example.com, the Subject Name on the certificate should be host1.example.com.

Note: the actual requirement is that the Common Name (CN) portion of the Subject Name matches the DNS FQDN, but many documents use Subject Name and Common Name interchangably (the Common Name is just the CN portion of the SN).

Certificates also have one or more Subject Alternative Names (SANs) which specify alternate hostname(s) that the host can be known as. Generally speaking, if the correct FQDN does not match the SN, but is listed as one of the SANs, the certificate naming requirement will be satisfied. For OCS clients connecting to an Enterprise pool, the pool name must be the Subject Name.

The primary use for this certificate check is for security purposes. It allows the client to be sure that the server it wants to connect to is indeed that server. Think of a server certificate as a passport for that server – it validates its identity to all the clients that use it.

Two factors can make setting the proper SN confusing:

Using OCS 2007 Standard Edition vs. Enterprise.
Use of a Director (between the client and OCS 2007 server).

As a general rule, the Subject Name of the certificate should match the fully qualified hostname of the first OCS server the client connects to. If it is an enterprise edition deployment, the Subject Name should be the FQDN of the enterprise pool.

FYI – Hardware Load Balancers (HLBs) do not affect the SN on the certificate. HLBs just pass the connection through to the OCS server.

The following table summarizes the Subject Name requirement on the certificate for different OCS deployments:

Situation	With Director	With HLB	Certificate Subject Name (SN/CN)
Standard Edition Server			Front-End FQDN
Standard Edition Server	Yes		Director FQDN
Consolidated Enterprise Pool			Pool FQDN
	Yes		Director FQDN
		Yes	Pool FQDN
Expanded Enterprise Pool		Yes	Pool FQDN
	Yes		Director FQDN
	Yes	Yes	Director FQDN

Note: For an Enterprise Pool, the Subject Alternative Name (SAN) should include a entry for each supported SIP domain in the format sip. if you selected either of these options when creating the pool with the Configure Pool Wizard: 1) Configure Clients for Automatic Sign-In, or 2) Configure this pool to redirect sign-in requests. If you have multiple SIP domains and use the OCS certificate wizard, it will automatically add “sip.domain.com” to the SAN for all supported SIP domains.

In August 2009, Microsoft released an excellent white paper clearly describing the certificate requirements for OCS: Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2 (the link refers to a collection of OCS documentation – scroll down to find the ”OCS 2007 R2 Deploying Certificates.doc“).

InsideOCS has a free download tool (the Automatic Sign-In Troubleshooting Tool) that will query for all of the automatic sign-in DNS records and show which ones exist, and which one will be used.

For more details all the automatic sign-in process and it’s requirements, see: