Deploying an Exchange Resource Forest

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/planning-architecture/deploying-exchange-resource-forest-part1.html

PART-1

There are many companies that have separated forests and do not intend to merge these forests again. This might occur due to:

• Multiple businesses that require data and service isolation
• Different schema requirements
• Company merger or acquisition process

We still have the traditional way of deploying Exchange Server 2007, that is the single forest, but in Exchange Server 2007, we can play with multiple forests and in those scenarios we have two possible topologies to work with:
Cross-forest
This topology uses multiple Exchange forests. Each forest has an Exchange Server 2007 and a tool to synchronize the recipients between them, since we should use the same GAL for all forests.

Figure 1: Cross-forest scenario
Resource forest
In the Resource forest topology, there is a forest with Exchange Server 2007 installed and one or more account forests. The users will be hosted in the Account forest and the Mailbox-enabled users will be hosted in the other forest. We will associate these mailboxes with the users from the account mailbox.
In this kind of scenario, we do not have problems related to GAL because all the users are in the same forest (Resource Forest), but we might need more hardware and infrastructure to deploy a new forest to host all mailboxes.

Figure 2: Resource forest scenario
The Scenario

Let us take a scenario where we have two account forests called: apatricio.local and other.local. We will also have a new forest that will be our Resource forest. This forest will be called msexchange.local. In this article we will start a resource forest using Exchange Server 2007 from scratch. Right now we have two account forests without any installed messaging system.
From the security viewpoint, only the users with exchange permissions in the Resource Forest will be able to create users, even the Account Forest Administrators will not be able to manage accounts and mailboxes in the resource forest.
We will use a scenario (Figure 3), where we have two companies from different segments but from the same group, wanting to share the same message infrastructure.

Figure 3: Two account forests which contain all users and a resource forest that will receive Exchange Server 2007

We will then install Exchange Server 2007 in this Resource Forest to host all the mailboxes of both account forests. We should create this new forest according to Microsoft Best Practices, and if possible create a Disaster Recovery Plan with a high availability solution for this resource forest, including Domain Controllers and Exchange Server roles.
Now that we know what kind of topology we are going to deploy, we have to adjust some settings in this fictitious scenario.
Installing Exchange Server 2007

First of all, we have to install Exchange Server 2007 in the Resource Forest. This is a normal installation process which we can see how to accomplish in the article series written by fellow MVP Rodney Buike: Installing Exchange 2007 (Part 1). For this article scenario we will install a single Exchange Server 2007 with the Client Access, Hub Transport and Mailbox Server roles.
Although we are working on a Resource Forest scenario, there are no special steps to follow during the setup process. The installation process of Exchange Server 2007 is the same independent type of Exchange topology.
Adjusting the DNS Servers to resolve to the resource forest

Before starting to create the trusts, we have to configure the correct name resolution among forests; let us configure the DNS Server in the two account forests (Apatricio.local and Other.local). We have to perform the tasks below in each account forest:

1. Log on to the account forest Domain Controller server
2. Click on Start and Run
3. Type dnsmgmt.msc and click OK
4. Right-click on <Server Name> and click on Properties
5. Click on Forwarders tab
6. Click on New button and in the new box, insert this information: msexchange.local (name of our resource forest), then click OK
7. Click on the resource domain in the DNS domain andadd the IP address of the DNS Server of the Resource Forest, as shown in figure 4

Figure 4: In the account DNS Servers we are setting up the resolution for the msexchange.local (Resource Forest) to the specified DNS Server
Now, we have to configure the DNS resolution in the resource forest. To do that we can follow the following steps:

1. Log on to the resource forest Domain Controller server
2. Click on Start / Run
3. Type dnsmgmt.msc and click OK
4. Right-click on <Server Name> and click on Properties
5. Click on Forwarders tab
   
   For each account forest follow these steps:
6. Click on New… button, and add the account forest domain name (Ex.: apatricio.local)
7. Click on the recently created new zone in DNS Domain box, and add the IP address of the respective DNS Server in the field bellow and click Add

Figure 5: Setting up the DNS resolution in the Resource Forest DNS Server

Now we can reach all our forest servers using DNS resolution.
Establishing trust among the Forest

Now that we have set up DNS resolution, we can establish trust among the forests. We need to execute the procedures listed below from the Resource Forest. An administrative account is needed for each account forest to create the trusts.

1. Log in to the Resource Forest server
2. Click on Start, Programs, Administrative Tools and Active Directory Domains and Trusts
3. Right-click on Resource Forest domain (msexchange.local) and click on Properties
4. Click on Trusts Tab
   
   Now repeat these steps for each Account Forest:
5. Click on New Trust...
6. Welcome to the New Trust Wizard. First screen to create the trust, click on Next.
7. Trust Name. Fill out the Account Forest name in the box called Name, as shownin Figure 6. Click Next.

Figure 6: Specifying the trust name between Account Forest and Resource Forest

1. Trust Type. Click on Forest Trust and click Next.
   
   Note:
   If this option does not appear it is because the Forest is not in 2003 mode.
2. Direction of Trust. Click on One-way: outgoing and click Next.
3. Sides of Trust.Click on Both this domain and the specified domain, and click Next. This option allows us to create a trust relationship in the local domain and in the Account Forest.
4. User Name and Password. Fill out the User name and Password of the Account Forest, and then click Next.
5. Outgoing Trust Authentication Level—Local Forest. Click on Forest-wide authentication, click Next.
6. Trust Selections Complete. A summary of our last steps will be shown, then click Next.
7. Trust Creation Complete. A figure similar to Figure 7 will appear, just click Next.

Figure 7: The outgoing trust was successfully completed

1. Confirm Outgoing Trust. Select Yes, confirm the outgoing trust and click Next.
2. Completing the new Trust Wizard. The final screen of the wizard will appear, as shown in Figure 8.

Figure 8: The final screen of the New Trust Wizard informing us that we have created the outgoing trust between Resource Forest and Account Forest

We now have created a one-way outgoing trust for each Account Forest where the Resource Forest trusts the Account Forest. Let us validate the configuration in the Active Directory Domain and the Resource Forest Trusts which should be similar to Figure 9.
.
Figure 9: Resource Forest Trusts
Now looking at the Active Directory Domain and Trusts in the Account Forest, we should have a result similar to Figure 10.

Figure 10: The Active Directory Domain and Trusts in one of the Account Forests

We now have a new Resource forest setup with Exchange Server 2007 and we have created one-way outgoing trusts for the Account Forests.
Conclusion

In this article, we have just seen the two types of multi-forest implementations that we are able to deploy in Exchange Server 2007. We also started the process of implementing a resource forest from scratch using two existent account forests and building a new resource forest to host the mailboxes. We also worked on the infrastructure to use the Exchange Server 2007 Resource Forest. In the next article, we are going to get more action working on Exchange 2007.

---

موضوعات مشابه:

• Office Communications Server Resource - User Forest Topology
• Deploying an Exchange 2007 SP1 CCR Cluster on a Windows Server 2008 Failover Cluster
• Deploying Exchange 2007 Multi-site CCR Clusters – Do’s and Don’ts
• Domain Rename – Rename a Windows 2003 Forest with Exchange 2003 installed

---

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/planning-architecture/deploying-exchange-resource-forest-part2.html

PART-2

In the second part of this article we will be working with Exchange Server 2007. We will create users using the Exchange Management Shell and Exchange Management Console. One thing to keep in mind is that the next section will explain the current situation of the Exchange Resource Forest after which we will start to work on Exchange Server 2007.
Our current scenario

In the first article we worked on our infrastructure, where we fixed the name resolution, installed Exchange Server 2007 in the Resource Forest and created the one-way outgoing trusts between Resource Forest and Account Forests. Now, our scenario is shown below in figure 01.

Figure 01: Our scenario with Exchange Server 2007 installed, trusts created and DNS resolution working
Organizing the Resource Forest

Before we begin user creation, we can organize our Active Directory and Exchange Server 2007 to hold both account Forests. In our article let us put the users in separated OUs. To do that, we can create a parent OU called Host and two sub-OUs called: APatricio OU and Other OU, as shown in Figure 02.

Figure 02: Creating OUs to distribute the users

We are going to create two Storage Groups and consequently two mailbox databases for the users of both Account Forests, as shown in Figure 03. Following Microsoft's best practices, we should separate the mailbox databases and mailboxes into distinct disks.

Figure 03: Separated Storage Groups for each Account Forest

Okay, now that we have distinct OUs, Storage Groups, and mailbox databases for the Account Forest, we can start the last procedure, that is the user creation.
Creating a Linked Mailbox using the Exchange Management Console

The process to create a mailbox in this scenario is a little bit different than a usual mailbox. We are going to create a Linked Mailbox. This feature is available only in the Exchange Server 2007 Resource Forest scenario. In the steps below, we will be checking out all the tasks involved in the process.
Open the Exchange Management Console; click on Recipient Configuration, and on the Toolbox Actions click on New Mailbox. A wizard will appear in the screen, select Linked Mailbox as shown in figure 04, and click Next.

Figure 04: Starting the process to create a Linked Mailbox in the Resource Forest

We do not have many options in the User Type section of the wizard, just select New User, and click Next.
We will define user information in the User Information section of the wizard. First of all click the Browse button and choose the OU in which we will be creating the new disabled user, as shown in Figure 05. In this case, we are creating a mailbox for the Apatricio’s Account Forest.

Figure 05: Choosing the OU where the new linked mailbox will be created

Fill out the rest of the information, such as user name, pre-user logon name, and password. Even in the linked Mailbox we have to do that. However, the real user will never know about the disabled account in the resource forest, as shown in Figure 06. The most import thing to consider in this section will be the Name field since that is what appears in the GAL (Global Address List). Click on Next.

Figure 06: Filling out the Linked Mailbox user information

Now we have to choose in the Mailbox Settings section of the wizard, the related information where this mailbox will be hosted, such as Exchange Server name, Storage Group and Mailbox Database. We have created two different Storage Groups. Now let us create this user in the appropriate Storage Group and Mailbox Store as shown in Figure 07.

Figure 07: Setting up the Mailbox settings of the new Linked Mailbox

Now, we have something new in the Master Account section of the wizard. First of all, we have to choose which Account Forest we will be using for this linked mailbox, and then choose the wanted Account Forest by clicking in the first Browse button (Figure 08).

Figure 08: Choosing which Account Forest that will contain the user who we are going to be linked to the new mailbox

Now, we can check the option Use the following Windows user account to access linked domain controller, fill out the credentials (user name and password) for the wanted Account Forest. We are now able to find the Linked domain controller. To do that click on Browse… and click OK.

Figure 09: The Global Catalogs of the Account Forest

We are almost there. Click on the third Browse… button to find the Account Forest user to match with the mailbox, as shown in Figure 10. The mailbox that we are creating is UserA, then we are going to select UserA. Click OK.

Figure 10: Selecting the user in the Account Forest which will access the mailbox in the Resource Forest

Now, we can see the Master Account section of the wizard filled out by our last choices (Account Forest, Global Catalog in the Account Forest and finally the user of that Account Forest), click Next, as shown in Figure 11.

Figure 11: Associating a user account to the new Mailbox

In the New Mailbox section of the wizard, we will see a summary of all our choices up to now; click Next, as shown in figure 12.

Figure 12: Summary of the new Linked Mailbox

Completion. This is our last screen of the wizard, where we can see the cmdlet and all the parameters that were used to create our Link Mailbox, as shown in figure 13.

Figure 13: Final screen of the New Mailbox Wizard

Now we can see the newly created account in the Exchange Management Console. There is a specific icon for the Link, as shown in Figure14.

Figure 14: The newly linked mailbox that we have just created

We can also see the disabled account that was created in the msexchange.local, as shown in Figure 15.

Figure 15: The disabled account created for the Linked Mailbox

Finally, we can check out the account using the cmdlet get-mailbox <user> | fl *linked*, where we will see the parameters IsLinked and LinkedMasterAccount that gives us the values to see if the account is linked and who is the owner of the account, as shown in figure 16.

Figure 16: Getting information about the Linked Mailbox using get-mailbox cmdlet
Creating a Linked Mailbox using Exchange Management Shell

Especially in this kind of scenario, we can use the Exchange Management Shell to create all the users of the account forest. We are going to see how to create a single user, but if you want to create using a csv file you can check the following article: Managing mailboxes in Exchange Server 2007 (Part 1).
First of all, open the Exchange Management Shell, type in $credential = get-credential, then a dialog box will pop up (Figure 17). Fill out that dialog box with the Account Forest credentials and click on OK.

Figure 17: Typing in the credentials of the Account Forest

Now, we have the credential of the Account Forest in a variable called $credential, that is necessary to create a Linked Mailbox. The full cmdlet is shown below:
C:\>$credential = Get-Credential
Fill in the dialog box with the Account Forest credentials
C:\>New-mailbox –Name <user-name> -Alias <Alias-Name> -OrganizationalUnit <OU-path> -UserPrincipalName Name@resource.forest.domain –Database <database-name> -LinkedMasterAccount <AccountForest\UserFromAccountForest> -LinkedDomainController <AccountForestDomainController> -LinkCredential $credential
Using the above cmdlet we can create a Linked Mailbox through the Exchange Management Shell, as shown in Figure 18.

Figure 18: Creating a Linked Mailbox
Conclusion

In this second article, we have seen how to create a Linked Mailbox in an Exchange Server 2007 Resource Forest environment using either Exchange Management Console or Exchange Management Shell. In the next article we will be taking a look at the user experience in this kind of scenario