Recipe2.1.Verifying Your Current Infrastructure Is Ready for Exchange Server 2003

Recipe 2.1. Verifying Your Current Infrastructure Is Ready for Exchange Server 2003

Problem

You want to use the Exchange Server 2003 Deployment Tools (ExDeploy ) to help ensure that your existing Active Directory and DNS infrastructure is properly configured and ready for your Exchange Server 2003 deployment.

Solution

Using a graphical user interface

Double-click the Exchange Setup utility (setup.exe) on the product CD.
Click Exchange Deployment Tools.
Select what tools you want to run by clicking on the appropriate link:
- Click on Deploy the first Exchange Server 2003 server if you're preparing to install the first Exchange Server 2003 server in an existing 5.5 organization.
- Click on Install Exchange Server 2003 on additional servers if you're upgrading Exchange 2000 servers or installing additional Exchange Server 2003 servers into an existing Exchange 5.5 or Exchange 2000 organization.
- Click on Perform post-installation steps to see a list of checklists for useful post-installation actions you can take (including moving mailboxes and public folders, running the Internet Mail Wizard, and setting up spam filtering).
- Click on Install Exchange System Management Tools Only if all you want to do is install ESM on a workstation or server. The resulting checklist will tell you exactly what prerequisite services are required to get ESM running on Windows XP (SP1 and SP2), Windows Server 2003, and various versions of Windows 2000.
- Click on Consolidate Sites in Exchange Mixed Mode if you want to consolidate multiple sites into a smaller number of Exchange Server 2003 sites. This option is added when invoking the deployment tools from Exchange Server 2003 SP1.
Follow the checklist for the toolset you've chosen. In some cases, such as installing into a mixed-mode organization, you'll need to supply some information (like the name of an Exchange 5.5 server). Anywhere you see a text field, you'll find a corresponding command-line argument that you can use to run the tool directly. Most of the tools run without any intervention from you.

When the tools have finished running, review the results, which by default will go in the ExDeploy Logs directory under the root of the system drive. The log files are quite detailed; for example, here's the log entry from just the policy checking tool, which clearly explains what the tool's doing and what it discovered:

[16:18:58] #*** Policy Check began: 03/26/2004 16:18:58 ***# [16:19:28] Entering HrMapFileHandle [16:19:28] Leaving HrMapFileHandle [16:19:28] PolicyTest.exe results: This tool will check every domain controller in the local domain to see if the "Manage auditing and security logs" privilege granted to the "Exchange Enterprise Servers" group by DomainPrep has replicated to that DC.  If the policy change has not yet replicated to all DCs, then you should avoid making policy changes on any DC that has not received those changes yet. You must have Domain Admin rights to run this tool successfully.  If you see an error that says:   !! LsaEnumerateAccountRights returned error 5 !! then you don't have permission to open the LSA on the given DC. =============================================== Local domain is "robichaux.local" (ROBICHAUX-DOM) Account is "ROBICHAUX-DOM\Exchange Enterprise Servers" ========================   DC      = "HURRICANE"   In site = "Default-First-Site-Name"   !! LsaOpenPolicy returned error 1722 !! ========================   DC      = "CYCLONE"   In site = "Default-First-Site-Name"   Right found:  "SeSecurityPrivilege" ========================   DC      = "VMHOST3"   In site = "Default-First-Site-Name"   Right found:  "SeSecurityPrivilege" [16:19:28] Entering HrFindPrintErrorMessage [16:19:28] Leaving HrFindPrintErrorMessage [16:19:28] PolCheck completed successfully. [16:19:28] #*** Policy Check finished:  ***#

Using a command-line interface

Insert the Exchange CD-ROM.
Run the following command to start the wizard-based interface:
```
<drive>:\support\exdeploy\exdeploy.hta
```
Run the following command to launch ExDeploy from the command line:
```
<drive>:\support\exdeploy\exdeploy.exe 
```
There are several switches you can use to control ExDeploy's behavior. You can get a complete list of command-line parameters by using the /? switch. For our purposes, the most interesting switches are /p:<logFilePath> (which you use to specify where you want the logs written) and /t:<toolSpec>, which specifies which tool or toolset you want to run.
After the tools you specified finish running, examine the log files to see what needs to be fixed.

Discussion

One common complaint about Exchange 2000 was that there were few tools to help assess the state of existing Exchange 5.5 organizations to see what needed to be changed or fixed before deploying the new version. Microsoft listened carefully to customers, partners, and MVPs, and the result was the release of the ExDeploy toolset. It's actually not a toolset as much as it is a process checklist; most of the tools included in ExDeploy have been available separately for a while. What's new is the way they're tied together so that, with minimal effort, you can get a detailed report telling you what components of your network and directory need attention before your migration.

Even seasoned Exchange admins should take a few minutes to step through ExDeploy to get familiar with it. Running these tools isn't mandatory, but it's a really good idea, especially if you're installing Exchange Server 2003 into an Exchange 5.5 organization. For that reason, you should plan on running the tools before you install Exchange Server 2003 into a mixed Exchange organization. As with all utilities that make changes to the Active Directory schema, these tools should be run in a lab environment to verify their functionality within your environment.

The ExDeploy tools will be updated on a regular basis as part of the normal Exchange development cycle, so it is always a good idea to download the latest version from Microsoft's Exchange download site (http://www.microsoft.com/exchange/downloads/).

Microsoft documentation does not provide an exhaustive list of the various tasks and tools you can use through ExDeploy. The tools are run in sequence, with the core OS requirement and configuration checks first and the more esoteric Exchange checks later. The ExDeploy tools can be broadly divided into six categories or phases.

Phase 1: Sanity checking

The tools in the first phase (collectively referred to as the DSScopeScan tools) are designed to perform some basic sanity checks on your existing environment. You should run them while planning your deployment (in other words, before installing anything!) To run them, you must run ExDeploy with an account that has Exchange administrator permission on the Exchange 5.5 organization and directory. The tools in this phase report back the number of Exchange 5.5 sites and servers, the number of directory objects (including public folders, mailboxes, and contacts/custom recipients), and the number of user objects. These tools also check to make sure that your Exchange 5.5 servers are at the appropriate revision level (SP3 or later).

Once these checks are complete, the DSScopeScan phase installs the Windows Support Tools, including DCDiag and NetDiag. These tools are used in later parts of the ExDeploy checklist; you can manually install them if you prefer. Once they're installed, ExDeploy will run NetDiag to verify that the server's DNS and TCP/IP configurations are correct and DCDiag to verify the AD configuration and reachability. This phase includes the DSConfigSum, DSObjectSum, UserCount, VerCheck, OrgReport, and GCVerCheck tools.

Phase 2: Preparing for AD replication

In the second phase (which Microsoft calls UserPrep), the ExDeploy tools give you a preview of what's going to happen when you install the Active Directory Connector (ADC) and enable it to synchronize Active Directory with your Exchange 5.5 directory. This phase includes four tools. ADCUserCheck recommends connection agreements and tells you if there are any objects in the 5.5 directory that don't exist in Active Directory; you should run it both before and after installing the ADC. NTDSNoMatch looks for Exchange 5.5 mailboxes (and NT 4.0 accounts) that don't have a 1:1 correspondence. VerCheck checks to make sure that there's at least one up-to-date (meaning SP3 or later) 5.5 server in the site you're installing Exchange Server 2003 into, and OrgNameCheck validates the Exchange 5.5 organization and domain names for RFC compliance. This is necessary because Exchange 5.5 would happily let you create organization names with characters (notably the ampersand) that aren't legal in X.500 distinguished names and thus can't be used in Active Directory.

To run these tools, the account you use must have Domain Admins permission in your AD domain; it must also have Exchange 5.5 administrative permissions.

Phase 3: Replicating and checking data

In phase 3, which Microsoft calls the ADCCheck phase, you're checking to ensure that the ADC is correctly installed and that replication is working. This begins when you rerun ADCUserCheck after replication has started (as described above). There are two additional tools in this phase: ADCObjectCheck checks to make sure that public folders, distribution lists, and custom recipients in the 5.5 directory were properly replicated; ADUserScan performs the same kind of checks for mail-enabled objects. In both cases, these tools will recommend appropriate ADC-connection agreements if necessary.

Phase 4: Preparing the domain and forest

Phase 4 encompasses a number of critical steps:

Run Exchange Setup with the /forestprep switch to prepare the AD forest by extending the schema. There's a button in the ExDeploy tools page that will do this for you. As described in Recipe 2.5, you should verify that forest preparation worked properly before proceeding with the other steps in this phase.
Run Exchange Setup with the /domainprep switch to prepare the AD domain into which you're installing Exchange. ExDeploy will do this for you if you like.
Create public folder connection agreements (which you must do manually).
Run the PolCheck tool to validate the security changes made by the /domainprep step.
Run the OrgCheck tool to validate the schema and domain preparation; in particular, OrgCheck checks for the presence of the Exchange Domain Servers and Exchange Enterprise Servers security groups, that the forest-level Exchange configuration container exists and is populated, and that at least one global catalog server exists in a domain that was domain prepped.
Run the NetDiag tool, which checks the server's DNS configuration to make sure it can see the DC and Global Catalog (GC) for the selected domain.
Run the PubFoldCheck tool, which verifies that all Exchange 5.5 public folders have matching entries in the information store and the directory. If inconsistencies exist (for example, if there's a folder in the store that doesn't have a directory entry), PubFoldCheck will fix them; it also filters the public folder access control lists (ACL) to remove entries for accounts that no longer exist.

Phase 5: Installing the bits: Microsoft calls this "the easiest of the six phases." Compared to what happens in some of the other phases, it might well be right! In this phase, the only thing that happens is that Exchange is installed on the target server. ExDeploy can automate this process somewhat, but you'll probably need to sit in front of the machine and watch the installjust in case.
Phase 6: Out with the old...: In the final ExDeploy phase, you move user mailboxes from the 5.5 server to the new server, eventually decommissioning the old server. Before you do these things, there are some tools you should run. The ADCConfigCheck tool scans for 5.5 configuration objects (including data managed by the knowledge consistency checker, or KCC) to ensure that they all made it to the AD. The ConfigDSInteg tool performs a consistency check on the Exchange configuration container and its objects, and the RecipientDSInteg tool performs a similar test on the recipient objects created by your migration. After you run these tools, you can move mailboxes (as described in Recipe 6.9) from the old server to the new one, then remove the old one.