Office Communications Server Resource

[LEFT][CODE]http://communicationsserverteam.com/archive/2009/10/30/655.aspx[/CODE]

[FONT=Arial]Office Communications Server 2007 and Office Communications Server R2 have two multi forest topologies that have been tested by and are supported by Microsoft. One of these topologies is the Office Communications Server Resource forest \ User forest topology and the other is the Office Communications Server Central forest and User forest topology. The focus of this document will be to discuss the implementations of the Office Communications Server Resource forest \ User forest topology.[/FONT]
[FONT=Arial]The Office Communications Server Resource forest \ User forest topology allows resources like Exchange 2007, Exchange 2003, Sharepoint services and Office Communications Server which will reside in the Resource forest to be accessed by the users that reside in the User forest. The configuration of the Resource forest \ User forest topology requires that the following prerequisites be completed prior to the configuration of the domain user account information that will be hosted in the local Active Directory of each forest that is part of this topology.[/FONT]
[FONT=Arial]Here are the prerequisites that are required to accomplish the task of creating the office Communications Server Resource forest \ User forest topology.[/FONT]
[B][FONT=Arial]Firewall configurations[/FONT][/B]
[FONT=Arial]Depending on the two forests intra / inter active directory topology the usage, placement and configurations of firewalls can vary. Configuring any firewalls to securely manage the needed network connectivity can be a challenging task. If necessary this operation will have to take place first to allow the creation of the needed forest trust between the Resource and User forests. [/FONT]
[FONT=Arial]The Microsoft KB article listed below will describe the Server 2003 domain services protocols / ports that will need to pass through the organizations firewalls that separate the Windows Active Directory locations which host the Resource servers and the user domain accounts that will be enabled for Office Communication Server sign on. [/FONT]
[B][FONT=Arial]Service overview and network port requirements for the Windows Server system[/FONT][/B]
[URL="http://support.microsoft.com/kb/832017"][FONT=Arial][COLOR=#0000ff]http://support.microsoft.com/kb/832017[/COLOR][/FONT][/URL][FONT=Arial][/FONT]
[FONT=Arial] [/FONT]
[FONT=Arial]Please take into consideration the version of Office Communications Server and Microsoft Exchange that you will be deploying when planning your firewall configurations. Office Communications Server 2007 R2 UC client connectivity requires a wider range of port connectivity for client access to the larger range of services that Office Communications Server 2007 R2 hosts, when compared to Office Communications Server 2007. Exchange 2007 uses its web hosted Exchange Web Service for client mailbox access and Free \ Busy data access this requires the use of TCP port 443 from the UC clients in the User forest. Exchange 2003 will allow MAPI client mailbox access through the use of RPC and the Endpoint Mapper management of TCP ports in the ephemeral range. The Office Communicator client will also have to have access to the Exchange 2003 public folders using a range of TCP ephemeral ports. The use of Virtual Private Network technologies to manage the needed network communications between the network endpoints that separate the server deployment in the Resource forest from the domain user accounts in the User forest is a preferred method for secured communications between the two.[/FONT]
[FONT=Arial]For information on how Office Communicator accesses free busy data please read[/FONT]
[B][FONT=Arial]Communicator 2007 does not update the free/busy information as scheduled[/FONT][/B]
[FONT=Arial]http://support.microsoft.com/kb/941103[/FONT]
[FONT=Arial] [/FONT]
[FONT=Arial]The following KB article discusses how to limit the amount of TCP ephemeral ports that are managed by the domain's RPC Endpoint Mapper Service. This may help network administrators provide more security at the level of inter and intra forest firewalls.[/FONT]
[B][FONT=Arial]How to configure RPC to use certain ports and how to help secure those ports by using IPsec[/FONT][/B]
[FONT=Arial]http://support.microsoft.com/kb/908472[/FONT]
[FONT=Arial] [/FONT]
[FONT=Arial]To test domain service port access and all TCP port connectivity between to IP endpoints please download and use the Microsoft tool PortQryUI.exe which can be down loaded the Microsoft downloads web site.[/FONT]
[B][FONT=Arial]PortQryUI - User Interface for the PortQry Command Line Port Scanner[/FONT][/B]
[FONT=Arial]http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=8355e537-1ea6-4569-aabb-f248f4bd91d0[/FONT]
[B][FONT=Arial] [/FONT][/B]
[B][FONT=Arial]How to use Portqry to troubleshoot Active Directory connectivity issues[/FONT][/B]
[FONT=Arial]http://support.microsoft.com/kb/816103[/FONT]
[FONT=Arial] [/FONT]
[FONT=Arial]The following Microsoft KB article provides information on the various VPN technologies that Microsoft has to offer.[/FONT]
[B][FONT=Arial]Virtual Private Networks[/FONT][/B]
[FONT=Arial]http://technet.microsoft.com/en-us/network/bb545442.aspx[/FONT]
[FONT=Arial] [/FONT]
[B][FONT=Arial]DNS resolution[/FONT][/B]
[FONT=Arial]The active directory forests / domains that participate in any multi forest topology will require name resolution. The Resource forest / User Forest design requires at least DNS resolution for the Users in the User forest to access the server resources in the Resource forest. This one way DNS solution will work with the manual deployment method (which is described below) when you do not have to use a scripting tool in the Resource forest to access the domain user account information in the User forest. When using the automatic method (which is described below) the Exchange Linked Mailbox wizard will have to be able to access the active directory in the User forest. This will require DNS resolution from the User forest to the Resource forest and the User forest will require DNS resolution from the Resource forest to the User forest. Also, the type of DNS infrastructure that is required will be instrumental in the implementation of the required Server 2003 forest level trust relationship.[/FONT]
[FONT=Arial]The Outlook 2007 and Office Communicator clients that will be hosted in the Users forest will require an additional HOST record in the DNS zone that represents the active directory domain which hosts the Exchange 2007 resource. This record will allow the Outlook 2007 client access to the Exchange Web Services for autodiscover and availability. The host record should be entered in the following format e. g. autodiscover.domain.com. This additional FQDN will be used to make secure requests to the Exchange Web Services folders that are hosted on the Exchange 2007 CAS such as [url]https://autodiscover.domain.com/autodiscover/autodiscover.xml[/url]. These secure requests to the Exchange 2007 server on TCP port 443 require the use of an additional Web Server certificate that will be hosted locally on the Exchange 2007 server's computer certificate store and assigned to the local IIS Default web server. This certificate will have a Subject Name value that matches the FQDN of the Exchange server and it must contain the autodiscover FQDN in the SAN list e. g. autodiscover.domain.com.[/FONT]
[B][FONT=Arial]Forest Level Trusts[/FONT][/B]
[FONT=Arial]The type of Server 2003 forest level trust that will be required depends on whether you plan to use the manual method or the automatic method for the implementation of the Office Communications Server Resource forest \ User forest topology. The manual method will require a one way Server 2003 forest level trust where the Resource forest trusts the User forest. The automatic method will require a two way Server 2003 forest level trust relationship so both forests will trust the other forest for resource access. Please do not confuse the Server 2003 forest level trust with the Windows external trust. The external trust will function between any two forests and the Exchange 2007 Linked mailbox implementation is fully operational when using a two way Windows external trust between ant two forests, but the Office Communication Server users in the User forest will not be able to sign into Office Communicator when using the Windows external trust. The design of the Server 2003 forest level trust supports both the use of NTLM and Kerberos v5 authentication methods.[/FONT]
[B][FONT=Arial]Forest Functional Level[/FONT][/B]
[FONT=Arial]The creation of the Server 2003 forest level trust requires a forest functional level of Server 2003. Again the Exchange 2007 Linked mailbox implementation only requires a Windows 2000 forest functional level. So Exchange could already be operational in a Resource forest \ User forest environment as per a prior deployment too Office Communication Server. This can lead to sign on issues with the Office Communicator client in the User Forest.[/FONT]
[FONT=Arial]Here are the steps you will need to take to implement the automatic and manual methods for creating the Office Communications Server resource forest \ User forest topology:[/FONT]
[FONT=Arial]1. [B]Manual method[/B]: make sure that the User forest can perform DNS resolution to the Resource forest. [B]Automatic method[/B]: Make sure that each forest can perform DNS resolution for the resources in the other forest. If you are using a Microsoft Server 2003 DNS infrastructure then you will be able to use the DNS manager which is located on the Server 2003 DNS server or servers in either forest to create the needed secondary DNS forward lookup zones that will allow domain name resolution to the other forest in the multi forest topology.[/FONT]
[FONT=Arial]2. The forest functional level has to be set to Server 2003. This can be confirmed by using the Active Directory Domains and Trusts MMC on the domain controller in the forest root domain that holds the PDC emulator role. This step requires research in a mixed domain forest. Please read the following Microsoft KB article before proceeding with this step.[/FONT]
[B][FONT=Arial]How to raise domain and forest functional levels in Windows Server 2003[/FONT][/B]
[FONT=Arial]http://support.microsoft.com/kb/322692[/FONT]
[FONT=Arial] [/FONT]
[FONT=Arial]3. Creating the forest trust relationships can be done by using the Server 2003 trust wizard that can be accessed in the Server 2003 Active Directory Domains and Trusts MMC. Please read the following Microsoft Technet information before proceeding with creating the needed forest trust relationship between the Resource forest and the User forest.[/FONT]
[B][FONT=Arial]Creating Domain and Forest Trusts[/FONT][/B]
[URL="http://technet.microsoft.com/en-us/library/cc740018.aspx"][FONT=Arial][COLOR=#0000ff]http://technet.microsoft.com/en-us/library/cc740018.aspx[/COLOR][/FONT][/URL][FONT=Arial][/FONT]
[FONT=Arial] [/FONT]
[B][FONT=Arial]Certificates[/FONT][/B]
[FONT=Arial] [/FONT]
[FONT=Arial]The Exchange server and the Office Communications Server will require their certificates to be managed as per the PKI deployments that are described in their deployment documentation. Please read the available certificate documentation for these products. Certificate design can vary to meet the needs of the different hardware configurations that Exchange and Office Communications Server can be deployed using. If the services that are hosted in the Resource forest use a Windows PKI for certificate level security, then be sure to assign that trusted Root CA certificate to the Windows clients in the Users forest that will require secure access to these services. If you are using Exchange 2007 with Outlook 2007 clients please read the information about certificate design listed above under the DNS sub title.[/FONT]
[FONT=Arial] [/FONT]
[B][FONT=Arial]Resource \ User Forest Deployment Methods[/FONT][/B]
[FONT=Arial]There are two methods that can be used to ensure access to Office Communications Server in the Resource forest by domain user accounts that exist in the User forest. The first is the manual method. The [B]manual[/B] method will be typically used when Exchange 2003 or Exchange 2007 is not installed in the Resource forest or user mailboxes are not configured yet and Office Communications Server 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 enabled in the User forest. These accounts must have at least matching first and last name, sign on name, and password information. These domain user accounts must be homed to the local Office Communications Server front end server or pool that is located in the Resource forest. The domain user accounts should be disabled in the Resource forest domain that they are hosted in for security purposes. 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. The second method known as the [B]automatic[/B] method is the more preferred method, preferred because it incorporates the extensibility of Microsoft Exchange 2003 or Microsoft Exchange 2007 along with the use of Office Communications Server services. This design can include the integration features of Office Communications Server and Exchange 2007 Unified Messaging for a richer user experience. The use of either version of Exchange will ensure the integration of the enhanced presence features of Office Communications Server for use with the Office Communicator and Outlook 2007 SP1 clients. The automatic method will use the Linked Mailbox enablement procedure to create the Exchange 2007 mailbox for the domain users in the User forest. This procedure will also create the matching disabled user accounts in the Resource forest. This step will not enable the use of Office Communications Server for users in the User forest. First, the disabled user accounts have to be enabled for Office Communications Server in the Resource forest and homed to the Office Communications Server Pool or FE server. The automatic method allows the use the Office Communications Server Resource Kit tool sidmap.wsf to locate the Exchange mailbox enabled / Office Communications Server enabled account and map the objectSid attribute from the user object in the User forest to the correct attributes of the matching disabled user object in the Resource forest.[/FONT]
[B][FONT=Arial]Manual Method[/FONT][/B]
[FONT=Arial]The manual method does not require that Exchange 2007 or Exchange 2003 be installed into the Resource forest. However Office Communications Server does have to be installed in the Resource forest and the Office Communications Server enabled for sign on user accounts must exist only in the Users forest. The manual method provides us with a good way to test the Office Communications Server functionality of the Office Communications Server Resource forest / User forest deployment prior to adding other server resources to the Resource forest. This method will allow the Office Communications Server enablement of a few user accounts so administrators can test instant messaging and other built in functionality of the Office Communicator client. The result of this implementation is basically the same as the automatic method just less the availability of Exchange services. Here's how it’s done:[/FONT]
[FONT=Arial]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 simply be defined with a username, first name, last name, and a password.[/FONT]
[FONT=Arial]2. Now move to the Resource forest and from a domain controller in the active directory domain that is hosting Office Communications Server create a domain user account using the same information that was used to create the domain user account in the User forest. Please remember to disable the new domain user account in the Resource forest for security purposes.[/FONT]
[FONT=Arial]3. Now on the Office Communications Server in the Resource forest open the dsa.msc (AD Users & Computers). Locate the domain user account that you just created and then open its properties dialog. Use the Communications tab to associate the account with a SIP URI and the Office Communication Server pool or server that the user will be homed to.[/FONT]
[FONT=Arial]4. Now all we have to do is use adsiedit.msc on a domain controller that hosts the new domain user account in the User forest and access that domain user account's properties. Browse the attributes of the domain user account and locate the objectSID attribute. Edit the attribute and then copy the SID value to notepad and save it to a shared location on the server. Make sure that the SID value does not get accidentally updated in either location, then exit out of adsiedit.msc without saving any changes.[/FONT]
[FONT=Arial]5. Now from a domain controller in the active directory domain that hosts the Office Communications Server installation use adsiedit.msc to locate the new domain user account that you want to use with Office Communications Server in the User forest. Open the properties dialog of this domain user account and then search the attribute listing for the msRTCSIP-OriginatorSID attribute. Edit the msRTCSIP-OriginatorSID attribute, and paste the SID value from the objectSID of the user forest / domain user account into the SID value window in adsiedit.msc. Apply the changes and close adsiedit.msc.[/FONT]
[FONT=Arial]a. [B]msRTCSIP-OriginatorSID = objectSID[/B] of the User Forest User[/FONT]
[FONT=Arial][/FONT][FONT=Arial][/FONT]
[B][FONT=Arial][URL="http://communicationsserverteam.com/photos/ocs_images/picture650.aspx"][IMG]http://communicationsserverteam.com/photos/ocs_images/images/650/592x454.aspx[/IMG][/URL][/FONT][/B]
[B][FONT=Arial]msRTCSIP-OriginatorSID [/FONT][/B]
[FONT=Arial]This attribute is used in resource and central forest topologies to enable single sign-on when a user’s ObjectSID from the Windows NT principal account is copied into this attribute of the corresponding user or contact object in the resource or central forest. Communicator Web Access searches for a user in Active Directory using this attribute or the user’s ObjectSID. This attribute is marked for global catalog replication.[/FONT]
[FONT=Arial]6. Now from a client in the Resource forest you can sign into Office Communicator using the domain user account that is enabled for Office Communications Server in the Resource forest. [/FONT]
[FONT=Arial]7. Perform this task with two or three domain user accounts to test the basic usages of Office communicator in the User forest.[/FONT]
[B][FONT=Arial]Automatic Method[/FONT][/B]
[FONT=Arial]The automatic method requires the installation of Exchange 2007 or Exchange 2003 in the Office Communications Server resource forest. This method will also require the installation of the Office Communications Server Resource Kit tools on a server in the Resource forest. [/FONT]
[FONT=Arial]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 simply be defined with a username, first name, last name, and a password.[/FONT]
[FONT=Arial]2. Exchange 2007 SP1 allows the Administrator to create mailboxes for domain users in remote forest by using the New Mailbox wizard option called appropriately "Linked Mailbox". [/FONT]
[FONT=Arial][URL="http://communicationsserverteam.com/photos/ocs_images/picture652.aspx"][IMG]http://communicationsserverteam.com/photos/ocs_images/images/652/618x459.aspx[/IMG][/URL][/FONT]
[FONT=Arial]a. The wizard will prompt you to create a new user or use an existing one. Using these steps you can create a new domain user account in the Resource forest using the same information that was used to create the domain user account in the User forest.[/FONT]
[FONT=Arial]b. Choose the mailbox database for the new account. Click Next[/FONT]
[FONT=Arial]c. Choose the trusted User forest. [/FONT]
[FONT=Arial]d. Enter the credentials for the Administrator in the Resource forest and choose the specific Domain Controller that you can authenticate to in the User Forest which hosts the user account for mailbox creation.[/FONT]
[FONT=Arial]e. Choose the user account in the User forest that you want to create the mailbox for.[/FONT]
[FONT=Arial]f. Click Next / Next / Finish to create the mailbox[/FONT]
[FONT=Arial]6. Upon the creation of the mailbox user in the User forest you will have created a matching disabled user account in the Resource forest. The new disabled user account will contain all the MSEXCH* attributes along with User forest and Resource forest accounts will contain different objectSID attribute values. However, the msEXCHMasterAccountSID attribute of the Exchange enabled domain user in the Resource forest will have been updated in the following manner.[/FONT]
[FONT=Arial]a. [B]msEXCHMasterAccountSID = objectSID[/B] of the User Forest User[/FONT]
[FONT=Arial][/FONT][FONT=Arial][/FONT]
[FONT=Arial] [URL="http://communicationsserverteam.com/photos/ocs_images/picture653.aspx"][IMG]http://communicationsserverteam.com/photos/ocs_images/images/653/592x412.aspx[/IMG][/URL][/FONT]
[B][FONT=Arial]msExchMasterAccountSid[/FONT][/B]
[FONT=Arial]If the mailbox is owned by a user that is outside of the local Windows 200x forest, msExchMasterAccountSid should contain the SID of that external user account. In this case, the disabled user account is also not used to log on directly, but instead this configuration allows a user outside of the forest to own an Exchange 200X mailbox within your organization. The foreign user account may be either a Windows 200X user from a separate forest, or a Windows NT 4.0 user account. If the value of msExchMasterAccountSid is the SID of an external account, the value must be unique. You may not have more than one disabled user account with the same SID in msExchMasterAccountSid in the entire forest. The msExchMasterAccountSid attribute should not point to a security principal (User or group) that is in the local forest, with the exception of foreign security principals. The external account 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.[/FONT]
[FONT=Arial]7. The next step is to Office Communications server enable the disabled domain user or users accounts. If the domain user's SIP address matches their SMTP address then you can use the AD U & Cs Office Communications Server Enable Users wizard to SIP enable the domain user accounts in their OU or the Users container. If not then you can use the manual method in AD U & Cs, by first accessing the property dialog of the domain user account in its OU or Users container and then from the Communications tab assign the domain user’s SIP URI and home them to the Office Communications Server Pool or FE server.[/FONT]
[FONT=Arial]8. Now you can use the Office Communication Server Resource kit tool sidmap.wsf to populate the following disabled domain user account's attributes in the Resource forest as follows:[/FONT]
[FONT=Arial]a. [B]msRTCSIP-OriginatorSID = objectSID[/B] of the User Forest User[/FONT]
[B][FONT=Arial][/FONT][/B][B][FONT=Arial][/FONT][/B]
[B][FONT=Arial][URL="http://communicationsserverteam.com/photos/ocs_images/picture651.aspx"][IMG]http://communicationsserverteam.com/photos/ocs_images/images/651/592x437.aspx[/IMG][/URL][/FONT][/B]
[B][FONT=Arial]msRTCSIP-OriginatorSID [/FONT][/B]
[FONT=Arial]This attribute is used in resource and central forest topologies to enable single sign-on when a user’s objectSID from the Windows NT principal account is copied into this attribute of the corresponding user or contact object in the resource or central forest. Communicator Web Access searches for a user in Active Directory using this attribute or the user’s objectSID. This attribute is marked for global catalog replication.[/FONT]
[FONT=Arial]The objectSID attribute for the user account in the resource forest and the user forest retain their original and unique SID values.[/FONT]
[FONT=Arial]Here’s the how to information on using the Office Communications Server Resource Kit tool sidmap.wsf[/FONT]
[B][FONT=Arial]Microsoft Office Communications Server 2007[/FONT][/B]
[B][FONT=Arial]Populating the Required Attributes for Office Communications Server[/FONT][/B]
[URL="http://technet.microsoft.com/en-us/library/bb663753.aspx"][FONT=Arial][COLOR=#0000ff]http://technet.microsoft.com/en-us/library/bb663753.aspx[/COLOR][/FONT][/URL][FONT=Arial][/FONT]
[FONT=Arial] [/FONT]
[FONT=Arial]Our Microsoft Technet documentation mentions the use of other user object attributes, such as:[/FONT]
[FONT=Arial]telephoneNumber[/FONT]
[FONT=Arial]displayName[/FONT]
[FONT=Arial]givenName[/FONT]
[FONT=Arial]surname[/FONT]
[FONT=Arial]physicalDeliverofficeName[/FONT]
[FONT=Arial]l (city)[/FONT]
[FONT=Arial]st (State)[/FONT]
[FONT=Arial]Title[/FONT]
[FONT=Arial]Company[/FONT]
[FONT=Arial]Country[/FONT]
[FONT=Arial]Mail (SMTP Address)[/FONT]
[FONT=Arial]Except for the Mail attribute which is added at the creation of the user's mailbox, the use of all other attributes in the list above is arbitrary. However, they do add descriptive factors to the user account that will help distinguish the difference between to Office Communications Server enabled accounts when the Office Communicator user performs s a AD search for a contact using the Add Contact Wizard. [/FONT]
[FONT=Arial][URL="http://communicationsserverteam.com/photos/ocs_images/picture654.aspx"][IMG]http://communicationsserverteam.com/photos/ocs_images/images/654/455x424.aspx[/IMG][/URL][/FONT]
[FONT=Arial][/FONT][FONT=Arial][/FONT]
[FONT=Arial]When a domain user in the Users forest performs a AD search using the Add Contact wizard the search will take place in the Resource forest and not in the users forest. Please remember since the domain user objects will reside in two separate forests achieving consistent active directory searches based on these attributes, will require that the domain user attributes in the Resource forest match the domain user attributes in each separate active directory Users forest.[/FONT]
[FONT=Arial]Exchange 2003 does support the use of Resource forest. In Exchange 2003 this was called the Dedicated Exchange forest as noted in the linked Microsoft Technet article listed below.[/FONT]
[B][FONT=Arial]Exchange Server 2003[/FONT][/B]
[B][FONT=Arial]Using a Dedicated Exchange Forest[/FONT][/B]
[FONT=Arial][URL="http://technet.microsoft.com/en-us/library/aa997312%28EXCHG.65%29.aspx"]http://technet.microsoft.com/en-us/library/aa997312(EXCHG.65).aspx[/URL][/FONT]
[FONT=Arial] [/FONT]
[FONT=Arial]In this topology MIIS 2003 could have been used to provision user attributes to the manually disabled duplicate account in the Resource forest or these attribute values such as the msExchMasterAccountSid could have been manually mapped from the objectSID of the enabled sign on account in the User forest. The Dedicated Exchange forest topology does not use MIIS to synchronize Exchange information as it would in the Exchange 2003 Cross Forest topology where Exchange 2003 could be hosted in multiple forests. [/FONT]
[FONT=Arial]I would like to say that deployments that are hosting this type of Exchange 2003 Resource forest / User forest topology are using a legacy deployment that was intended for just the Exchange 2003 Resource. They may want to add Office Communications Sever to their Resource forest though. [/FONT]

[LIST=1][*] [FONT=Arial]If so then all the prerequisites should already be in place [/FONT][*] [FONT=Arial]They will have to add Office Communications Server to their Resource Forest and then Office Communications Server enable the disabled user accounts in the Resource forest.[/FONT][*] [FONT=Arial]Next they would use the Office Communication Server Resource kit tool sidmap.wsf to populate the following disabled user account's attributes in the Resource forest as follows:[/FONT][*] [FONT=Arial]msRTCSIP-OriginatorSID = objectSID of the User Forest User[/FONT][*] [FONT=Arial]The msEXCHMasterAccountSID should already be populated with the correct SID information from the Exchange 2003 mailbox enabled account in the user forest. I have not tested this yet, but the resource kit information does not specify a required version of Exchange Server[/FONT][/LIST]

[/LEFT]

Office Communications Server Resource - User Forest Topology