If you missed the other parts in this article series please read:
- A Closer Look at Preparing Active Directory for Exchange 2007 (Part 2)
- A Closer Look at Preparing Active Directory for Exchange 2007 (Part 3)
- A Closer Look at Preparing Active Directory for Exchange 2007 (Part 4)
- A Closer Look at Preparing Active Directory for Exchange 2007 (Part 5)
Introduction
Before you dive in and start installing Exchange 2007, you should take the time to understand the steps required to prepare your Active Directory environment to receive Exchange 2007. In this four-part article I will be taking a more in-depth look at what these preparatory steps are and, perhaps more importantly, what tools and processes you can use to determine whether they have completed successfully or not.
Before we get going there are one or two important things to discuss first. One statement that I’m sure you must have heard by now is that Exchange 2007 is only supported on 64-bit hardware. You are probably also aware that there is a 32-bit version of Exchange 2007 available for non-production scenarios such as training and lab environments. As you will see later in this article, some of the commands required to prepare Active Directory for Exchange 2007 must be run on specific servers that aren’t typically Exchange 2007 servers and could therefore be running on 32-bit hardware. If that’s the case and it’s known that Exchange 2007 isn’t supported on 32-bit hardware, how can these commands be performed with full support from Microsoft? In these cases, you should be aware that Microsoft does support the use of the 32-bit version of Exchange 2007 for performing specific Active Directory preparation tasks, such as extending the schema. With that in mind, make sure you have a copy of the 32-bit version of Exchange 2007 handy if you know that you have, say, only 32-bit domain controllers throughout your environment.
You will note throughout the steps in this article that it’s possible to have the process you are currently running perform the previous processes if they have been omitted. For example, if you forget to prepare the legacy permissions first, this step will be automatically performed when the schema is updated. You might wonder, then, if it’s better to just perform as few steps as possible rather than do each step individually. Personally I prefer to perform each step individually, based largely on the notion that I can check each step along the way, confirming that each process has completed correctly and resolving any errors as I go. Additionally, since some of the steps require different permissions levels, it’s possible to perform each step with the minimum permissions required, something that can be useful in larger and more secure environments.
Let’s look at the sample environment that I’ve constructed for this article. The environment consists of an empty forest root domain, neilhobson.com, and a single child domain, sales.neilhobson.com. The child domain contains an Exchange 2003 server and the associated user accounts that have mailboxes on this Exchange 2003 server. A new Windows 2003 server has been deployed into the child domain and will become the first Exchange 2007 server installed into this particular organization.
Preparation Commands
If you need to confirm the various setup parameters at any time, just run the following command from your Exchange source files:
setup.com /help:PrepareTopology
You can see the output in Figure 1; these are the commands that we will be covering within this article. Note the option for all switches to use a specific domain controller if required.
Figure 1: Setup.com Switches for Preparing Active Directory
With the commands in mind, let’s get going and look at them in detail.
Preparing Legacy Permissions
The first step to consider is whether your Exchange 2007 infrastructure is being installed into an existing Exchange 2000 or Exchange 2003 organization. If it is, you need to prepare legacy permissions. The reason for this centers largely around the Recipient Update Service (RUS) used in Exchange 2000 and Exchange 2003. I’m sure you know what the RUS does and so I won’t go into detail here, but if you don’t happen to know then you can check out Mark Fugatt’s or Rodney Buike’s articles on the subject. Due to a change in Exchange 2007, the RUS does not have the correct permissions to update email attributes belonging to users and therefore the process of preparing legacy permissions described in this section addresses this issue.
To prepare the legacy permissions you need to use the following command:
setup /PrepareLegacyExchangePermissions
That’s quite a lot of typing and the potential is there for you to input a few typing mistakes. Fortunately you can achieve the same result with a shorter command. I don’t know about you but if I can shorten my time at the keyboard and remove the potential for typing mistakes then that’s what I’ll do. Therefore, I’ll be using the shortened version within this article. It is:
setup /pl
Running this command will attempt to update all the domains in your forest. If you only have a single domain or if you want to prepare the legacy permissions in a specific domain, then the command to use is:
setup /pl:<FQDN of domain>
For example, if I want to update the sales.neilhobson.com domain only, then I’d use this command:
setup /pl:sales.neilhobson.com
If you are updating a single domain, then the account you use to run this command must be a member of Domain Admins in the relevant domain and must also have been delegated the Exchange Full Administrator role. For those of you with multiple domains containing legacy Exchange servers, there are additional areas to consider and watch out for. If you have multiple domains containing Exchange 2000 or Exchange 2003 servers, you will have previously run the Exchange 2000 or Exchange 2003 DomainPrep process in each of these domains. It’s in these domains that the legacy permissions process must do its work and therefore the server on which you run the setup /pl command must be able to contact each of these domains. To run correctly in a multiple domain scenario, the account you use must be a member of the Enterprise Admins group.
In my example environment, I’m going to run the setup /pl command from my newly installed member server AD-CHE2K7. You can see the result of doing this in Figure 2.
Figure 2: Setup /pl Organization Checks
As you can see above in Figure 2, organization checks are performed first before the actual permissions are set. These checks ensure that the setting of the permissions can proceed and anything preventing this will be indicated to you on screen. You can see from Figure 2 that there are three issues highlighted:
- There is a recommendation that .NET Framework 2.0 SP1 is installed; this is a recommendation only and you can therefore proceed without implementing it. However, you really should be following Microsoft recommendations such as this.
- The legacy Exchange organization is not in native mode, something that prevents the setting of the legacy Exchange permissions. This is one of the main requirements of your legacy Exchange environment before introducing Exchange 2007, so make sure that you’ve made the switch to native mode before attempting to set the legacy permissions.
- Finally note the information stating that the account Iam using is not a member of the Enterprise Admins group, which is a requirement in this case since I indicated that I wished to update all domains and not any specific domain.
Summary
That is it for the first part of this article. Here I have covered the background requirements for running the command that prepares the legacy Exchange permissions and we have seen a few common issues crop up. In part two, I will complete the look at preparing legacy permissions including examining the setup logs and also how you can determine whether this process ran successfully other than just relying on the setup logs.
If you missed the other parts in this article series please read:
