Resource Forest Topology with Office Communications Server 2007 R2 and Exchange 2010

Abstract: This article describes how to deploy Microsoft Office Communications Server 2007 R2 in the resource forest with the user forest, and multiforest topology by using Microsoft Windows Server 2008 and Active Directory directory services with Office Communications Server 2007 R2 and Exchange 2010 hosted in the resource forest. The user forest client software consists of Microsoft Office Communicator 2007 R2 and Microsoft Office Outlook 2007 with Microsoft Office 2007 SP3 installed.

Author: Michael Adkins

Publication date: April 2010

Product version: Microsoft Office Communications Server 2007 R2, Microsoft Exchange 2010

This article focuses on the Microsoft Office Communications Server 2007 R2 resource forest and user forest topology.

Using the Microsoft Windows Server 2008 Active Directory directory service forests, the Office Communications Server resource forest and user forest topologies support the following resources in the resource forest:

  • Microsoft Exchange 2010
  • Microsoft Windows SharePoint Services 3.1 with SP1
  • Microsoft Office Communications Server 2007 R2

The article will explain the used of two processes that can be used to deploy Office Communications Server 2007 R2 with Exchange 2010 in a resource forest and user forest topology. These two methods are described as follows:

Manual

The manual method provides a good way to perform the initial tests for the configuration and connectivity that are used for the Office Communications Server 2007 R2 resource forest and user forest deployment. The manual method doesn't require the use of Exchange 2010 in the resource forest.

Automatic

The automatic method requires that Exchange 2010 and Office Communications server 2007 R2 be deployed in the resource forest. Though more work is required to complete the manual method, the overall results provide a resource forest and user forest environment that is fully equipped for resource user sign-in for Exchange 2010 mailbox services and all the benefits of Office Communications Server 2007 R2 hosting.

Supportability Information

Office Communications Server 2007 R2 currently supports the use of two multiforest topologies. They have been tested by Microsoft and are as follows:

  • Resource forest with user forest topology
  • Central forest with user forest topology

Office Communications Server 2007 R2 is now supported by Windows Server 2008 R2.

For more information on Windows Server 2008 supportability for server applications and Active Directory, see the following:

Prerequisites

Because Active Directory forests are inherently disparate, the first steps to deploying the Office Communications Server 2007 R2 resource forest and user forest topology is to meet the required set of network prerequisites that allow secure communications to exist between the Active Directory hosted resource forest and the user forests. The following information describes what is needed to sustain network communication between the resource forest and user forests.

Firewall Configurations

Firewall configuration and placement can vary, depending on the separate resource forest and user forest inter-Active Directory topology. Configuring these firewalls too securely passes the needed TCP and User Datagram Protocol (UDP) transport protocols for interforest communications can be challenging. This operation is needed to allow the creation of the forest-level trust between the Office Communications Server resource forest and user forests.

This section provides links to several Microsoft articles to help you work with firewall configurations.

The Service overview and network port requirements for the Windows Server system article at go.microsoft.com/fwlink/?linkid=179695 describes the Windows Server 2008 domain services protocols and their ports. They require configuration on the organization's firewalls that separate the Windows Active Directory locales that host the server resources and the user domain accounts that will be enabled for the remote Exchange 2010 and Office Communication Server 2007 R2 hosting.

The following articles provide network infrastructure requirements for a supported Office Communications Server 2007 R2 environment and the port requirements that are required to support the full range of Office Communications Server 2007 R2 functionality on a network:

Virtual Private Network (VPN) technologies provide the security that is needed to pass Active Directory domain information between disparate networks that are sharing Active Directory information. VPNs provide a measure of convenience for firewall administrators by allowing a minimal port configuration to pass the array of protocols that are required to support Active Directory services. Choosing one of the many VPN technologies that are on the market today helps secure communications between the resource forest and the user forest. This helps ensure the safety of your information. For more information, see Overview of virtual private networks (VPN) at go.microsoft.com/fwlink/?linkid=156322.

Exchange 2010 supports the Client Access Server role. It allows the Office Outlook client access to user mailboxes by using a secure TCP port 443 connection. This eliminates the need for Remote Procedure Call (RPC) port access from Office Outlook clients on the network, limiting the RPC communications to inter-Exchange 2010 server role communications.

The following article describes how to limit the amount of TCP ephemeral ports that are managed by the domain's RPC Endpoint Mapper Service. This limitation may help network administrators provide more security through limiting the number of RPC ports that can be used across their WAN links between the resource and the user forest. For more information, see How to configure RPC to use certain ports and how to help secure those ports by using IPsec at go.microsoft.com/fwlink/?LinkId=190504.

Exchange 2010 uses the Exchange Client Access Server role to fulfill the need for Outlook and Office Communicator clients Free/Busy presence updates. This eliminates the need for public folder access by using a MAPI or RPC connection from any supported Windows client. For information about how Office Communicator accesses free/busy data, see Communicator doesn't update the free/busy Information as Scheduled at go.microsoft.com/fwlink/?LinkId=190505.

Test domain service port access and all TCP port connectivity between to IP endpoints by using the Microsoft tool PortQryUI.exe. For more information, see the following articles:

DNS Resolution

The Active Directory forests and domains that participate in any multiforest topology require DNS resolution. The Office Communications Server 2007 R2 resource forest that has user forest multiforest topology requires at least DNS resolution. This allows users into the user forest so they can access the server resources in the resource forest. This one-way DNS solution works with the manual deployment method when you don't have to use the Office Communications Server 2007 R2 sidmap.wsf scripting tool in the resource forest to access the domain user account information in the user forest.

When you use the automatic deployment method, you must use the Office Communications Server 2007 R2 sidmap.wsf scripting tool in the resource forest to access Active Directory in the user forest. This requires DNS resolution from the user forest to the resource forest. The user forest requires DNS resolution from the resource forest to the user forest. Also, the type of DNS infrastructure that is required is instrumental in the implementation of the required Windows Server 2008/Windows Server 2003 forest-level trust relationship.

The Outlook 2007 and Office Communicator clients that are hosted in the user forest require an additional host record in the DNS zone. It represents the Active Directory domain that hosts the Exchange 2010 resource. This record allows the Outlook 2007 client access to the Exchange Web Services for the autodiscover and availability. The host record should be entered in the following format; for example, autodiscover.domain.com. This additional fully qualified domain name (FQDN) is used to make secure requests to the Exchange Web Services folders that are hosted on the Exchange 2010 Client Access Server, such as https://autodiscover.domain.com/autodiscover/autodiscover.xml. These secure requests to the Exchange 2010 server on TCP port 443 require the use of an additional Web server certificate. It is hosted locally on the Exchange 2010 server's computer certificate store and assigned to the local IIS default Web server. This certificate has a Subject Name value that matches the FQDN of the Exchange 2010 server. It must contain the autodiscover FQDN in the system area network (SAN) list; for example, autodiscover.contoso.com.

Forest-Level Trusts

The Windows Server 2008 forest-level trust type that is required depends on whether you plan to use the manual method or the automatic method for the implementation of the Office Communications Server 2007 R2 resource forest and user forest multiforest topology.

The manual method requires a one-way Windows Server 2003 forest-level trust where the resource forest trusts the user forest.

The automatic method requires a two-way Windows Server 2003 forest-level trust relationship so that the user forest and the resource forest will trust each other for resource access.

Don't confuse the Windows Server 2003 forest-level trust with the forest-level external trust. The Windows external trust primary use is to provide backward compatibility with Active Directory-aware forests and legacy Microsoft Windows NT 4.0 domains. Keep in mind that the external trust functions between any two Active Directory forests. The Exchange 2010 linked mailbox implementation is fully operational when a two-way Windows external trust is used between any two Active Directory forests. However, the Office Communications Server 2007 R2 users in the user forest aren't able to sign in to Office Communicator when they use the Windows external trust. It supports only Windows NT LAN Manager (NTLM) authentication. The design of the Windows Server 2003 forest-level trust supports the use of both NTLM and Kerberos v5 authentication methods. For more information, see Deploy Exchange 2010 in an Exchange Resource Forest Topology at go.microsoft.com/fwlink/?LinkId=190510.

Forest Functional Level

The creation of the Windows Server 2003 forest-level trust requires a forest functional level of at least Windows Server 2003. Again, the Exchange 2010 linked mailbox implementation requires only a Windows 2000 forest functional level. Exchange 2010 could already be operational in a resource forest/user forest environment, according to a prior deployment to Office Communication Server 2007 R2. This forest functional level configuration can lead to sign-in issues with the Office Communicator client in the user forest.

Use the following steps to implement the automatic and manual methods for creating the Office Communications Server resource forest /user forest topology:

1. The two methods that we use in this article to define the resource forest and user forest topology for Office Communications Server 2007 R2 are manual and automatic. Here are the types of DNS configurations that you will need to support the needed forest functional level for each:   

  • Manual method: make sure that the user forest can perform DNS resolution to the resource forest.
  • Automatic method: Make sure that each forest can perform DNS resolution for the resources in the other forest.
  • If you are using a Microsoft Windows Server 2008 DNS infrastructure, you can use the DNS manager. It is located on the Windows Server 2008 DNS server or servers in either forest. Use the DNS manager to create the needed secondary DNS forward look-up zones. They allow domain name resolution to the other forest in the multiforest topology.

2. Set the forest functional level to at least Windows Server 2003. Confirm this by using the Active Directory Domains and Trusts MMC on the domain controller in the forest root domain that holds the primary domain controller (PDC) emulator role. This step requires research in a mixed domain forest.

Important: Read the following Microsoft KB articles before you set the forest functional level:   

3. Creating the forest trust relationships can be done by using the Windows Server 2008 trust wizard. Access it in the Windows Server 2008 Active Directory Domains and Trusts MMC. Read the following Microsoft TechNet information before you create the needed forest trust relationship between the resource forest and the user forests:   

Certificates

The Exchange 2010 server and the Office Communications Server 2007 R2 deployment requires that their certificates be managed according to the public key infrastructure (PKI) deployments that are described in their deployment documentation. Read the following certificate documentation for these products:

Certificate design can vary to meet the needs of the various hardware configurations that Exchange 2010 and Office Communications Server 2007 R2 can be deployed with. If the services that are hosted in the resource forest use a Windows PKI for certificate-level security, be sure to assign its trusted Root Certificate Authority certificate to the Windows clients in the user forest that requires secure access to these services. If you are using Exchange 2010 with Outlook 2007 clients, read about certificate design in the "DNS Resolution" section of this article.

Resource with User Forest Deployment Methods

Either the manual or the automatic deployment method can be used to ensure access to Office Communications Server 2007 R2 in the resource forest by domain user accounts that exist in the user forest.

Manual Method

The manual method of deployment is typically used when Exchange 2010 is not installed in the resource forest or user mailboxes are not configured yet and Office Communications Server 2007 R2 is deployed in the resource forest. The manual method requires that you manually create user accounts in the resource forest that match the domain user accounts that you want to be Office Communications Server 2007 R2-enabled in the user forest. These accounts must have at least matching first name and last name, sign-in name, and password information. These domain user accounts must be homed to the local Office Communications Server 2007 R2 front-end server or pool that is located in the resource forest. For security purposes, the domain user accounts should be disabled in the resource forest domain that they are hosted in. The most important step is the manual mapping of the objectSID attribute from the user account in the user forest to the disabled user account in the resource forest.

Automatic Method

The automatic method of deployment is preferred because it incorporates the extensibility of Exchange 2010 along with the use of Office Communications Server 2007 R2 services. This choice allows the inclusion of the integration features of Office Communications Server 2007 R2 and Exchange 2010 Unified Messaging for a richer user experience. The use of Exchange 2010 helps ensure the integration of the enhanced presence features of Office Communications Server 2007 R2 for use with both the Office Communicator client and the Outlook 2007 SP1 client. Here's how it works:

  1. The automatic method uses the linked-mailbox-enablement procedure to create the Exchange 2010 mailbox for the domain users in the user forest.

  2. This procedure also creates the matching disabled user accounts in the resource forest.

  3. This enablement procedure doesn't enable the use of Office Communications Server 2007 R2 for users in the user forest.

  4. The disabled user accounts have to be enabled for Office Communications Server 2007 R2 in the resource forest and homed to the Office Communications 2007 R2 Server Pool or FE server.

  5. The automatic method allows the use of the Office Communications Server 2007 R2 Resource Kit tool, sidmap.wsf, to locate the Exchange mailbox-enabled-Office Communications Server 2007 R2-enabled user account in the resource forest, and then maps the objectSid attribute value of the user object in the user forest to the correct attributes of the matching disabled user object in the resource forest.

Deploy by Using the Manual Method

The manual method deployment doesn't require that Exchange 2010 be installed in the resource forest. However, Office Communications Server 2007 R2 does have to be installed in the resource forest. The soon-to-be Office Communications Server 2007 R2 user accounts must pre-exist in the user forest. The manual method provides us with an efficient way to test the Office Communications Server 2007 R2 functionality of the Office Communications Server 2007 R2 resource forest/user forest deployment prior to adding other server resources to the resource forest. This method allows the Office Communications Server 2007 R2 enablement of a few user accounts so that administrators can test instant messaging (IM) and other built-in functionality of the Office Communicator client. The result of this implementation is basically the same as the automatic method except the Exchange 2010 services are not available.

Here's how to deploy by using the manual method:

  1. In the user forest, create a user account in one of the Active Directory domains that will be hosting Office Communication Server services. The domain user account can be defined with simply a user name, first name, last name, and password.
  2. Go to the resource forest: 
  • From a domain controller in the Active Directory domain that is hosting Office Communications Server 2007 R2, create a domain user account by using the same information that you used to create the domain user account in the user forest.

Note: For security purposes, disable the new domain user account in the resource forest.

3. On the Office Communications Server in the resource forest, open dsa.msc (Active Directory Users and Computers MMC): 

1. Locate the domain user account that you just created, and then open its Properties dialog box.

2. Use the Communications tabbed page to associate the account with a SIP URI and with the Office Communications Server 2007 R2 pool or server that the user will be homed to.

4. Start adsiedit.msc on a domain controller that hosts the new domain user account in the user forest, and then access that domain user account's properties:

1. Browse the attributes of the domain user account to locate the objectSID attribute.

2. Edit this attribute, and then copy the SID value to Notepad (or another editor), and then save it to a shared location on the server.

3. Make sure that the SID value isn't accidentally updated in either location.

4. Exit adsiedit.msc-don't save your changes.

5. Using a domain controller in the Active Directory domain that hosts the Office Communications Server 2007 R2 installation, start adsiedit.msc as shown in Figure 1:

1. Locate the new domain user account that you want to use with Office Communications Server 2007 R2 in the user forest.

2. Open the Properties dialog box of this domain user account, and then search the attribute listing for the msRTCSIP-OriginatorSID attribute.

3. Edit the msRTCSIP-OriginatorSID attribute, and then paste the SID value from the objectSID of the user forest/domain user account into the SID Value window in adsiedit.msc.

4. Apply the changes, and then close adsiedit.msc.

Figure 1. msRTCSIP-OriginatorSID = objectSID of the user forest user

6. The msRTCSIP-OriginatorSID attribute is used in resource and central forest topologies to enable single sign on when a user's ObjectSID value from the Windows NT principal account is copied into this attribute of the corresponding user or contact object in the resource or central forest. The 2007 R2 release of Microsoft Office Communicator Web Access searches for a user in Active Directory by using this attribute or the user's ObjectSID value. The msRTCSIP-OriginatorSID attribute is marked for global catalog replication.

7. From a client in the resource forest, you can now sign in to Office Communicator by using the domain user account that is enabled for Office Communications Server 2007 R2 in the resource forest.

8. Manually deploy two or three domain user accounts to test the basic things you can do with Office Communicator in the user forest.

Deploy by Using the Automatic Method

Automatic method deployment requires that Exchange 2010 be installed in the Office Communications Server 2007 R2 resource forest. This method also requires that Office Communications Server 2007 R2 Resource Kit tools be installed on a server in the resource forest.

Here's how to deploy by using the automatic method:

1. In the user forest, create a user account in one of the Active Directory domains that will be hosting Office Communications Server services. The Domain user account can be defined simply by a user name, first name, last name, and a password.

2. In the resource forest, the Exchange 2010 Administrator can use the Exchange 2010 management console to create user mailboxes for the domain users in the user forest. This can be done by using the Exchange 2010 New Mailbox wizard option, which is appropriately called Linked Mailbox as shown in Figure 2. The wizard prompts you to create a new user or use an existing one. Use the following steps to create a new domain user account in the resource forest by using the same information that was used to create the domain user account in the user forest:

1. Select the mailbox database for the new account, and then click Next.

2. Select the trusted user forest.

3. Enter the credentials for the Administrator in the resource forest, and then select the specific domain controller that you can authenticate to in the user forest that hosts the user account for mailbox creation.

4. Select the user account in the user forest that you want to create the mailbox for.

5. Click Next, Next, and then click Finish to create the mailbox.

Figure 2. Linked Mailbox wizard option

3. You've created both a mailbox user in the user forest and a matching disabled user account in the resource forest. The new disabled user account contains all the MSEXCH* attributes. However, the user forest enabled user account and the disabled resource forest user accounts contain unique objectSID attribute values. However, the msEXCHMasterAccountSID attribute of the Exchange-enabled domain user in the resource forest has been updated as shown in Figure 3.

Figure 3. msExchMasterAccountSid

4. If the mailbox is owned by a user who is outside of the local Active Directory forest, the msExchMasterAccountSid attribute should contain the SID of that external user account as shown in Figure 3. In this case, the disabled user account is not used to log on to the Exchange 2010 resource forest mailbox directly. Instead, this configuration allows a user who is outside the forest to own an Exchange 2010 mailbox within your organization. The foreign user account can be Active Directory-enabled or a member of a Windows NT 4.0 domain. If the value of msExchMasterAccountSid is the SID of an external account, the value must be unique. Only one disabled user account with the same SID in msExchMasterAccountSid can exist in the entire forest. The msExchMasterAccountSid attribute should not point to a security principal (user or group) that's in the local forest except foreign security principals. The external account that is specified in the msExchMasterAccountSid attribute should also have Full Mailbox Access rights granted in the Mailbox Security Descriptor. The SID must be written in a binary format-not security descriptor definition language (SDDL) format.

5. Enable the disabled Office Communications Server 2007 R2 domain user or user accounts:

1. If the domain user's SIP address matches their SMTP address, you can use the Active Directory Users and Computers Office Communications Server Enable Users wizard to SIP-enable the domain user accounts in their Organizational Unit or the Users container.

2. If not, use the manual method in Active Directory Users and Computers to access the Properties dialog box of the domain user account in its Organizational Unit or Users container. From the Communications tabbed page, assign the domain user's SIP URI and then home them to the Office Communications Server 2007 R2 Pool or FE server.

6. Use the Office Communications Server 2007 R2 Resource Kit tool, sidmap.wsf, to populate the disabled domain user account's attributes in the resource forest as shown in Figure 4.

Figure 4. msRTCSIP-OriginatorSID = objectSID of the user forest user

msRTCSIP-OriginatorSID

The msRTCSIP-OriginatorSID attribute is used in resource and central forest topologies. This attribute enables single-sign on when a user's objectSID value from the Windows NT principal account is copied into the msRTCSIP-OriginatorSID attribute of the corresponding disabled user account in the resource forest. This attribute is marked for global catalog replication.

Note: Remember that user forest-enabled user account and the disabled resource forest user account will contain unique objectSID attribute values.

For more information about using the Office Communications Server 2007 R2 Resource Kit tool, sidmap.wsf, see Populating the Required Attributes for Office Communications Server at go.microsoft.com/fwlink/?LinkId=190517.

Attribute Synchronization in Cross Forests for Office Communications Server 2007 R2 at go.microsoft.com/fwlink/?LinkId=190518 describes user object attributes, such as the following:

  • Company
  • Country
  • displayName
  • givenName
  • l (city)
  • Mail (SMTP Address)
  • physicalDeliverofficeName
  • st (State)
  • surname
  • telephoneNumber
  • Title

Except for the Mail attribute, which is added when the user's mailbox is created, the use of all other attributes in the previous list is arbitrary. However, these attributes add descriptive factors to the user account. This helps distinguish the difference between two Office Communications Server 2007 R2-enabled accounts when the Office Communicator user performs an Active Directory search for a contact by using the Add a Contact wizard as shown in Figure 5.

Figure 5. Search results in the Add a Contact wizard

When a domain user in the user forest performs an Active Directory search by using the Office Communicator 2007 R2 Add a Contact wizard, the search takes place in the resource forest-not in the user forest.

Note: Because the domain user objects reside in two separate forests, achieving consistent Active Directory searches based on these attributes requires that the domain user attributes in the resource forest match the domain user attributes in each separate active directory user forest.

Summary

Some of the benefits of being able to use Exchange 2010 and Office Communications Server 2007 R2 in a resource forest and user forest topology are as follows:

  • Hosting communications services to business partners that require them
  • Corporate mergers-providing extensibility to business partners
  • Centralized management of resources for your organization

These are a few of the many good reasons to expand the use of Exchange 2010 and Office Communications Server 2007 R2. Making sure that all the commitments for a secure network infrastructure are in place is a wise first step to help ensure that your forest's Active Directory information is secured as well as your messaging communications. The infrastructure helps provide your remote users with efficient and secure communications.

Additional Recourses

Communications Server Resources

We Want to Hear from You

  • To give us feedback about this article or to propose a topic for an article, e-mail us at NextHop@microsoft.com.
  • You can also send us a tweet at <www.twitter.com/DrRez>.