DNS and certificates work together to create a trust and the ability for server-to-server authentication and client-to-server authentication to occur.

For more information about certificates, see the section titled "Securing Office Communications Server with PKI" later in this chapter. The specific understanding from this section is that the clients and the servers involved in mutual authentication or simple authentication using a Transport Layer Security (TLS) certificate use DNS to find the name of a server and then compare the name retrieved from DNS to the name on the certificate that the server submits for authentication. If the name that DNS presents is different than the name on the certificate, the authentication fails.

DNS is used to locate servers and to determine what interface of a server is to be used. If a server has two interfaces, which is common for all Edge Servers, DNS is referred to when needing to resolve the name to the IP address. The administrator needs to design a DNS system to resolve both the internal-facing interfaces as well as the external-facing interfaces. This can either be done with a split-brain DNS, a DNS structure that handles both internal queries and external queries with neither side knowing that the other exists. Or, a more common scenario is to have an internal DNS to handle all internal queries and an external DNS to handle all external queries.

Office Communications Server introduces the concept of SIP namespaces or domains to route SIP requests internally and externally by using DNS. This is similar to how e-mail messages are routed.

When installing Office Communications Server 2007 R2, the default SIP domain server becomes authoritative for the Active Directory’s forest (that is, root domain) name. For example, if your forest’s FQDN is Litwareinc.com, Office Communications Server will be authoritative for the SIP domain @Litwareinc.com. In the case of a multitree Active Directory forest, Office Communications Server 2007 R2 picks up only the first tree’s FQDN as its SIP domain. The other tree’s FQDN must be defined manually. However, this default namespace is probably not the namespace you will want to expose externally. In most cases, you will want to make the user’s SIP URI identical to the user’s e-mail address for simplicity. This is not a requirement, but it keeps the user’s corporate identity consistent. If your corporate e-mail namespace does not match your Active Directory root domain FQDN, you must change the default SIP namespace to match your Simple Mail Transfer Protocol (SMTP) namespace. Fortunately, you can modify the list of SIP domains.

You can easily modify the set of authoritative SIP domains through the Administrative Tools MMC. To open global settings, right-click the forest node and then select Properties. The General tab appears by default. Click Add and Remove to modify the list of authoritative SIP domains, as shown in Figure 4-17.

Figure 4-17. Configuring SIP domains for Office Communications Server

Users in your organization must be enabled for Office Communications Server with a SIP URI that has a domain suffix supported by the Office Communications Servers in your organization.

After the initial configuration, there is little need to add or remove SIP domains; however, sometimes this need does arise. For example, if a company changes its public identity, the old SIP domain must be discontinued and the new SIP domain must be added. If a company with an existing deployment of Office Communications Server is merged with your organization and you want to support only a single SIP domain namespace, the acquired company’s SIP domain name must be added to your Domain list until the migration is completed. For these and other reasons, simply adding the new SIP domain to the Domain list and removing the old SIP domain is not sufficient. In addition to this step, you must migrate all users whose SIP URI uses the acquired SIP domain to the existing SIP domain. To remain valid, each user’s contacts also need to be updated from the acquired SIP domain to the new corporate SIP domain.

A common administrative task is to move users from one SIP namespace to another. This could be done to move users from one company organization to another, such as a job or role change. It might also be done when a company decides to restructure the Office Communications Server environment to create more SIP domains to allow for a location-based organization of users.

The procedure to move users from one SIP domain to another is as follows.

Performing step 1 is easy; however, steps 2 and 3 become more challenging because there are no tools to perform these steps. Fortunately, Office Communications Server 2007 R2 provides Windows Management Instrumentation (WMI) application programming interfaces (APIs) that can be leveraged via scripting (for example, VBScript and PowerShell) to automate these steps.

One approach is to query all users in Active Directory that are enabled for Office Communications Server, determine if any user matches the source SIP domain to change, and change the domain portion of the SIP URI (leaving the user name portion intact) to the target SIP domain desired. Because users could have added a contact with a SIP URI that you must change to match the new SIP domain name, this utility needs to "peek" into each user enabled for Office Communications Server, check whether any contact’s SIP URI matches the same source SIP domain, and update the domain portion of the contact’s SIP URI. Step 4 involves requesting a new server certificate from your preferred public CA provider. For additional details, see the section titled "Configuring the Subject Alternative Name" later in this chapter.