Over the years, I’ve seen a number of different discussions about the directors, what they do, how they behave, and when we should use them. This post summarizes what I believe to be the salient points concerning the director component. Hopefully, this will serve to clarify rather than confuse.

One of the advantages of directors that we originally touted was that it “offloaded authentication” and relieved the pool of that duty. This is only partially true. The behavior is slightly different whether we are talking about external users or internal users.

Director Traffic

Please consider the following diagram while I describe the traffic flow:

External case (the Chicago user in the diagram):

• The remote user initiates SIP registration with the Access Edge. The Access Edge validates some SIP headers and determines that the registration should be sent to its next internal hop—the Director. (For the purposes of this discussion, the Director could be any Pool configured as the next internal hop. There is no functional difference.) This is the flow marked A in the diagram.
• The Director authenticates the registration and performs an AD lookup to find the user’s home pool. (Authentication here must be via NTLM because the client cannot contact a domain controller to acquire a Kerberos ticket.)
• The Director proxies the traffic to the user’s home pool. (Redirecting an external user makes no sense since the external Communicator client cannot contact the pool directly.) This is the flow marked B in the diagram.
• Traffic proxied to the pool from the director does not require additional authentication. (The client performed NTLM authentication at the director, each SIP message is now correctly signed, and the traffic to the pool is coming from a trusted server—the director—not the client.)

Internal case (the London user in the diagram):

• Internal user initiates SIP registration with the Director. (This happens because this company has configured their internal DNS SRV records to automatically configure Communicator to register with the director.) This is the flow marked X in the diagram.
• The Director authenticates the registration and performs an AD lookup to find the user’s home pool. (Kerberos can be used here because the client is internal.)
• The Director redirects the client to the user’s home pool. (Redirecting, in this case, simply means that it sends a 301 SIP response to the registration request. The response contains the FQDN of the user’s home pool.)
• The user now follows the regular registration process with their home pool (discovered via the 301 response). This requires authenticating to the pool. The second authentication is necessary because of the challenge/response authentication nature of client-to-server communications. No information from the original authentication request will be contained (nor would it make sense) in these requests. This is the flow marked Y in the diagram.

Director Benefits

Given the above understanding, let’s make some application. Here are the benefits of directors:

Security: In an environment with an access edge but no director, unauthenticated traffic will be sent to your production pool for authentication. The edge server will validate some SIP headers but it would be possible to craft a SIP message that gets through. This gives an attacker a direct path to your internal production server. The director component lets you isolate that unauthenticated traffic to a server that is less critical. Some organizations will find this very important even in single pool deployments.

Performance: For remote users, the director will proxy all SIP traffic. Without directors, you have to pick a pool that will proxy the traffic. This could have a performance impact to the users homed on that pool. The director is also handling authentication for those remote users.

When to Use a Director

I have been asked if there’s a certain number of users that your deployment should be supporting before it makes sense to have a director. It’s not the user-count that is important; it is whether or not the deployment has remote access and the number of internal pools. Let’s consider the four different combinations of these two factors:

• Environments with multiple pools and remote access: The director serves a critical role as the “next hop” inbound from the edge and proxies traffic from remote users to the appropriate pool. A director should always be used when the customer has multiple pools and remote users.
• Environments with multiple pools and no remote access: One way to provide automatic configuration of Communicator involves configuring the internal DNS records to point the client to the director. The director is useful in this scenario as it will handle the redirection of your internal clients. In the absence of a director, you can configure Communicator to register with any pool and it will be redirected but you must plan for this additional load. (Some customers will be uncomfortable requiring the use of a remote director to sign into a local pool and may prefer an unsupported solution that involves configuring DNS differently or a supported solution using manual or group policy-based configuration.)
• Environments with one pool and remote access: The benefit of preventing unauthenticated SIP traffic from reaching the user pool may be sufficient to justify a director.
• Environments with one pool and no remote access: Even if the customer is not currently planning multiple pools, during migrations or for piloting different versions or configurations, it will be required to establish multiple pools. Start the design with no director but add it as part of the project that installs the second pool.

Note: I should point out that in the above traffic flow descriptions, when evaluating how to handle the registration request, the director or the pool doesn’t really know if the user is external or internal. All it knows is whether it is the first hop or not (based on SIP Via headers). The default behavior of every OCS front end (whether in a director pool or a user pool) is to redirect traffic to the correct home server if it is the first hop and proxy the traffic if it is not. (This default behavior can be changed by modifying the RedirectMethods property of MSFT_SIPEsEmSetting.)

--Doug

This post has been brought to you by Visio. Pretty drawing, huh?

The on-premise conferencing capability in Office Communications Server allows you to invite anonymous participants. These anonymous participants shouldn’t be allowed to have a meeting all by themselves, though. At least one authenticated enterprise user is required to be in the meeting.

With data conferencing in the Live Meeting Console, an anonymous participant can activate the conference. But — after a grace period — if no enterprise users join, the meeting will be terminated. Once the enterprise user does join, the meeting is safe. The enterprise user doesn’t have to be a presenter. A presenter will be needed to manipulate content in the meeting but the attendees can still talk to each other.

You would expect audio conferences to work similarly. (In an audio conference, the “presenters” are called “leaders.”) Except, there has been a bug in this feature until recently. (If you’d like more information on the OCS dial-in conferencing architecture, start here.)

The bug prevented the anonymous PSTN callers from being allowed into the meeting until a leader joined. Enterprise users that joined could talk to each other but the anonymous participants would continue to hear only music on hold until a leader joined.

The Conferencing Attendant fix just released will make the audio conferencing behavior consistent with the data conferencing behavior. Any authenticated enterprise participant that joins will start the audio conference and bring in the anonymous PSTN callers without the leader being present.

This fix is part of a big release of fixes for almost every component of OCS 2007 R2.

--Doug

This post has been brought to you by the letters Q, F, and E.

A new feature in Office Communications Server 2007 R2 is PSTN dial-in to audio conferences. (OCS 2007 had audio conferencing. It just didn’t have an attendant to which you could dial-in, provide a conference ID, and be placed in the right conference.)

The most important features of a traditional reservationless audio bridge are provided by OCS. One of these important features is a conference ID that represents your personal audio conference. (You can have unique conference IDs for each of your calls. But, the default option when you schedule a meeting simply uses your assigned conference ID.)

I had a colleague recently tell me that her assigned OCS conference ID kept changing. This was wreaking havoc with her meetings because, for no apparent reason, the ID that the meeting was created with had become invalid.

I just learned this was another bug that was (at least partially) addressed in the OCS QFE released last week. The problem is with the Conferencing Add-in for Outlook. When you delete one occurrence of a recurring meeting that uses your default conference ID, the add-in mistakenly sends a command to delete that conference ID. This will make all the meetings that use that conference ID invalid.

The real fix will be made in some future version of the Conferencing Add-in. In the mean time, with these fixes, the server will ignore the incorrect conference delete commands. Now you can schedule OCS conference calls and be confident that your ID will work when you need it.

--Doug

This post has been brought to you by Microsoft Update. Please update your servers!