2. Installation and Infrastructure

Introduction

Before you can do much with Exchange, you’ll have to install it. The installation process differs slightly from Exchange 2000 to Exchange Server 2003, but they’re similar enough that we can cover them in the same set of recipes. There are also several infrastructure-related tasks that you may need to perform incident to installing Exchange, such as verifying that modifications to Active Directory (AD) have propagated to all domain controllers (DCs) in the domain and enumerating the Exchange servers and connectors that exist. One thing to remember is that Exchange 2000 Server cannot run on Windows Server 2003—and that Exchange Server 5.5 and above can all run on Windows 2000.

The Exchange installation process is fairly straightforward; it can be summarized into a few fairly simple operations:

Before Exchange can be installed into a previously Exchange-free Active Directory forest, the Active Directory schema must be extended. A standard Windows Server 2003 Active Directory schema contains around 1,200 object classes and attribute definitions; Exchange Server 2003 adds almost 1,100 more! This process of schema extension is known as forestprep , after the setup command-line switch used to trigger it. Exchange’s setup utility will automatically perform the forestprep if it’s needed (provided your account has the necessary permissions, as described in Recipe 2.6).
Each domain that will contain an Exchange server or user account used to access Exchange must likewise be prepared, a process known as domainprep . As with forestprep, Exchange Setup will do this for you if you haven’t already done it manually (provided your account has the necessary permissions, as described in Recipe 2.7).
If you’re installing the first Exchange 2000 or 2003 server in a forest, the Exchange organization object and some of its children (including the first administrative group, or AG) must be created in Active Directory. Again, this happens automatically when you run Exchange Setup.
Setup must check the Windows server you’re installing on to ensure that all the prerequisite components are there and configured, as described in Recipes Recipe 2.1 and Recipe 2.2 Recipe 1.1 Recipe 1.1. Note, however, that Setup doesn’t check to make sure those configuration settings are correct, merely that they exist. For example, if your server’s DNS configuration is wrong, Exchange may install but fail to work properly when you start the Exchange services.
You have to choose which specific Exchange components you want to install on the server. By default, you get the Exchange binaries and management tools, although you can choose to install one or the other separately.
As part of the binary installation process, Exchange Setup registers the new server in Active Directory. Obviously, you don’t want to do this if you’re recovering a crashed server, which is why you have to use the /disasterrecovery switch.

AGs are used in Exchange Server 2000 and Exchange Server 2003 Server organizations when organizations need to isolate administrative privileges for different servers. If your organization is highly distributed, and different groups of administrators are responsible for administering different servers, AGs can be useful to ensure that administrators are managing only the Exchange server computers that they are tasked with managing. Organizations with few servers, or centralized Exchange services, probably don’t need to deploy multiple AGs. The KISS (keep it simple, stupid) principle comes into play with AGs—if you don’t have a need for them, don’t make your environment more complex than it needs to be.

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-DOMExchange 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>:supportexdeployexdeploy.hta

Run the following command to launch ExDeploy from the command line:
```
                        <drive>:supportexdeployexdeploy.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 install—just 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.

2.2. Preparing a Windows 2000 Server Computer for an Exchange Installation

Problem

You want to install Exchange 2000 or Exchange Server 2003 on a computer running Windows 2000 Server or Advanced Server. You’ve already used Windows Update to ensure that the base operating system (OS) has all current security patches and service packs.

Solution

Using a graphical user interface

From the Control Panel, open the Add/Remove Programs applet.
On the left side of the Add/Remove Programs window, click the Add/Remove Windows Components icon.
When the Windows Components window appears, scroll down to Internet Information Services (IIS). Select it and click the Details button.
In the Internet Information Services (IIS) window, make sure that NNTP Service and SMTP Service are selected, then click OK.
Click Next. You may be prompted for your Windows 2000 installation CD; if needed, insert it or specify an alternate location where the install files can be found.
If the Terminal Services Setup page appears, click Next.
When installation is complete, click Finish.

Using a command-line interface

Use your favorite text editor to create a text file containing the following lines. Each line lists an IIS component that’s required for Exchange.
```
[Components]
iis_common = on
iis_inetmgr = on
iis_www = on
iis_smtp = on
iis_nntp = on
```
Save the file; the name doesn’t matter.
From a command prompt, use the sysocmgr command to tell Windows to install the components. Although sysocmgr takes several parameters, the switches we’re interested in are /i (which specifies where the system’s default component list is) and /u (which tells the utility to use the file you created to determine what to install). Here’s an example:
```
> Sysocmgr /I:%systemroot%infsysoc.inf /u:c:	empex-smtp-prep.txt
```
If you add the /q switch, sysocmgr will suppress its user interface; otherwise, you’ll see the standard Windows Component Wizard interface, but you won’t necessarily be able to click on anything to affect the installation’s progression. Note that you may still be prompted for installation media if Windows can’t find the needed files at the install source path specified by the sysoc.inf file.
Verify that the components were installed by opening the Internet Services Manager (ISM) snap-in and opening the computer. In addition to the Default Web Site and Administration Web Site items, you should also see entries for the default SMTP and NNTP virtual servers.

Discussion

Exchange has a fairly rich set of application dependencies, including two that you may not have known of. The IIS SMTP service is required because Exchange’s SMTP engine is actually a set of extensions to the IIS SMTP engine. If SMTP isn’t installed (or worse, if you remove it after installing Exchange), no SMTP mail will flow. Because Exchange 2000 and later use SMTP as the native inter-server transport, this is bad. The IIS NNTP service is required, too, for public folder management; without it, you can’t see or manage public folders using ESM. Even if you’re not using NNTP, you should leave this protocol installed (in Recipe 4.1, you’ll learn how to disable services that you’re not using without removing them). It turns out that these two services both require the Server service, which is not otherwise required for Exchange servers but will normally be enabled.

2.3. Preparing a Windows Server 2003 Computer for an Exchange Installation

Problem

You want to install Exchange Server 2003 on a computer running Windows Server 2003. You’ve already used Windows Update to ensure that the base OS has all current security patches and service packs.

Solution

Using a graphical user interface

From the Control Panel, open the Add/Remove Programs applet.
On the left side of the Add/Remove Programs window, click the Add/Remove Windows Components icon.
In the Windows Components page of the Windows Components Wizard, locate Application Server and select it, then click the Details button.
In the Application Server dialog box, ensure that ASP.NET and Internet Information Services (IIS) are checked.
Select Internet Information Services (IIS) and click the Details button.
In the Internet Information Services (IIS) dialog box, ensure that SMTP Service, NNTP Service, and World Wide Web Service are all checked, then click OK.
Click OK, and then click Next.
If prompted to do so, supply your Windows Server 2003 CD or some other kind of installation media so Windows can load the new files.

Using a command-line interface

Use your favorite text editor to create a text file containing the following lines. Each line lists an IIS component that’s required for Exchange. There are some differences between this list and the component list for IIS 5.0: ASP.NET is new in IIS 6.0, and ASP support for IIS 5.0 is always installed.
```
[Components]
iis_common = on
iis_inetmgr = on
aspnet = on
iis_asp = on
iis_www = on
iis_smtp = on
iis_nntp = on
```
Save the file; the name doesn’t matter.
From a command prompt, use the sysocmgr command to tell Windows to install the components. Although sysocmgr takes several parameters, the switches we’re interested in are /i (which specifies where the system’s default component list is) and /u (which tells the utility to use the file you created to determine what to install). Here’s an example:
```
> Sysocmgr /I:%systemroot%infsysoc.inf /u:c:	empex-smtp-prep.txt
```
If you add the /q switch, sysocmgr will suppress its user interface; otherwise, you’ll see the standard Windows Component Wizard interface, but you won’t necessarily be able to click on anything to affect the installation’s progression. Note that you may still be prompted for installation media if Windows can’t find the needed files at the install source path specified by the sysoc.inf file.
Verify that the components were installed by opening the IIS Manager (ISM) snap-in. If the installation succeeded, you’ll see the Default SMTP Virtual Server and Default for the default SMTP and NNTP virtual servers.

Discussion

As with Windows 2000, Windows Server 2003 provides several prerequisite services for Exchange Server 2003 (remember, Exchange 2000 isn’t supported on Windows Server 2003). These services have to be separately installed before Exchange itself can be installed. Exchange Setup checks for the presence of the IIS SMTP and NNTP services because the Exchange SMTP and NNTP components are actually extensions of those protocol servers.

The .NET framework, ASP.NET, and IIS (including the World Wide Web Publishing Service) must be installed and running before you can actually install Exchange Server 2003 Server on the computer. If these (and the services mentioned above) aren’t present, Setup will stop and tell you what you still need to install before Exchange Server 2003.

2.4. Preparing an Active Directory Forest for Exchange

Problem

You want to prepare an Active Directory forest for the installation of Exchange. You must do this even if you have an existing Exchange 2000 organization and are preparing to install your first Exchange Server 2003 server.

Solution

Using a graphical user interface for Exchange 2000

Log in with a domain account that is a member of the Schema Admins and Enterprise Admins group (and has local machine administrative rights, if running forestprep from a member server).
Start Exchange Setup from the product CD.
Select Exchange Server Setup from the initial splash screen.
Accept the license agreement and click Next.
Select ForestPrep.
If prompted, enter your 25-character product key. Note that you won’t see this screen in Setup—ever—if you’re installing an evaluation version or a version that contains a Microsoft Volume Licensing key, which is common at large organizations that have volume license agreements in place.
On the Component Selection page, be sure that the Action is set to ForestPrep. If it is not, select ForestPrep from the drop-down list and click Next.
In the Installation Type page, make sure that the Create a New Exchange Organization radio button is selected, then click Next.
In the Organization Name page, name your Exchange organization and select the account or security group within your organization that will be used as the first account granted Exchange administrative privileges. You should create a separate security group for this purpose before you reach this step. Don’t use the built-in administrator account. Click Next.
On the Component Summary page, click OK.
Allow the process to finish; it may take a while depending on the particulars of your network topology and domain controllers. Do not interrupt it.

Tip

When installing Exchange 2000, you can also use the /schemaonly switch for Exchange setup; that forces the schema changes but skips the other ForestPrep steps.

Using a graphical user interface for Exchange Server 2003

Log in with a domain account that is a member of the Schema Admins and Enterprise Admins group.
Start Exchange Setup from the product CD.
Select Exchange Deployment Tools.
Select ForestPrep.
Accept the license agreement, then (if prompted) enter your product key.
On the Component Selection page, be sure that the Action is set to ForestPrep. If it is not, select ForestPrep from the drop-down list and click Next.
On the Administrator Account page, provide the name of the account or security group within your organization that will be used as the first account granted Exchange administrative privileges, then click Next. You should create a separate security group for this purpose before you reach this step. Don’t use the built-in administrator account.
On the Component Summary page, click OK.
Allow the process to finish; it may take a while depending on the particulars of your network topology and domain controllers. Do not interrupt it.

Using a command-line interface with Exchange 2000 or Exchange Server 2003

Log in with a domain account that is a member of the Schema Admins and Enterprise Admins group.
Create a new temporary folder on your local hard drive.
Insert the Exchange CD-ROM and navigate to the SETUPI386EXCHANGE directory.
Copy the 10 LDIF schema files (named schema0.ldf through schema9.ldf) from this directory to your temporary folder:
```
> copy schema?.ldf 
                        c:schema-temp
```
Change to your temporary folder and concatenate all ten schema files together into one big file:
```
> copy *.ldf 
                        exchangeschema.ldf
```
Use the ldifde command to import the schema changes into Active Directory, while replacing the <SchemaContainerDN> placeholder in with your actual schema container distinguished name (DN):
```
> ldifde -I -f exchangeschema.ldf -c <SchemaContainerDN> cn=Schema,
cn=Configuration,dc=<domain>,dc=<tld> -s <SchemaMasterFSMOservername>
```
At some later date, you will still need to perform a forestprep. Exchange Setup will at that time recognize the schema has already been updated and skip that task.

Discussion

ForestPrep does several things:

It creates an Exchange organization object (/o= organization name) in the forest-wide configuration naming context (NC) in Active Directory (CN=First Organization, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC= <domain>, DC= <tld>). In Exchange 2000, this organization object is immediately given the name you specify during setup; in Exchange Server 2003, the forestprep operation gives the organization object a temporary name (it’s actually a globally unique ID, or GUID) that is replaced when you install the first server. The temporary GUID of the placeholder object is {335A1087-5131-4D45-BE3E-3C6C7F76F5EC}.
It grants Exchange Full Administrator permissions on the Exchange organization object to whatever account or group you specified during step 7 of the GUI instructions above. The account or security group you name will be able to maintain all Exchange servers throughout the Active Directory forest, as well as delegate other full administrators. Choose this entity carefully. Since this group performs functionality at a forest-wide level, it needs to be a global security group. This gives the most functionality in the future, as individuals can be added or removed from this group as Exchange administration tasks require.
It extends the schema.
It turns off Outlook Mobile Access (OMA) for all users in the forest by setting the default value of the msExchOmaAdminWirelessEnable attribute on the user account to 0.

When you run forestprep against an Exchange 2000 organization to get it ready for Exchange Server 2003, an additional change takes place: the Create top level public folder permission on the Exchange organization container is removed for the Everyone and Anonymous Logon groups. No other permissions are changed.

It is much easier to allow forestprep to perform the schema upgrade along with its other tasks. However, because schema upgrades must replicate to all domain controllers in a forest, you may want to perform the schema update at some time when the replication traffic won’t be a problem. In fact, the best time to update the schema in a newly created AD forest is before you install any additional DCs, since in that case no inter-server replication is required. If you need to upgrade the schema without creating the Exchange organization object, you can use the manual procedure outlined above. If your domain controllers are still running Windows 2000, you will need to modify the registry on the domain controller that holds the Schema Master FSMO role before you can perform the schema modifications (as described in MS KB 216060). This step is not necessary on Windows 2003 domain controllers.

Because forestprep needs to contact the schema master, it needs to be run in the domain where the schema master resides; this will be the first domain controller installed in the root domain of the forest, unless you have moved the role to another domain controller. When possible, you should run forestprep on the schema master computer itself; this provides a significant speed boost because all of the schema updates can be written directly to the local disk.

The impact of Active Directory replication after forestprep is more severe in Windows 2000 Active Directory than in Windows 2003 because in Windows 2000, any change to the partial attribute set (PAS) stored on global catalog servers results in a full synchronization of all global catalog servers. Windows Server 2003 global catalog servers only replicate attributes that have changed, so the impact of the global catalog updates is lessened.

The account you use to run forestprep needs to be a member of both the Enterprise Admins and Schema Admins built-in groups. The schema changes made by Exchange Server 2003 are a superset of the changes made by Exchange 2000, so it is necessary to run the Exchange Server 2003 ForestPrep in your existing Exchange 2000 organization before installing your first Exchange Server 2003 server.

2.5. Preparing an Active Directory Domain for Exchange

Problem

You want to prepare an Active Directory domain for the installation of an Exchange server.

Solution

Using a graphical user interface

Log in with a domain account that is a member of the Domain Admins and Administrators (if running from a member server) groups.
Start Exchange Setup from the product CD.
Select Exchange Deployment Tools.
Select DomainPrep and click Next.
Accept the license agreement and, if prompted, enter your product key.
On the Component Selection page, be sure that the Action is set to DomainPrep. If it is not, select DomainPrep from the drop-down list, then click Next.
Allow the process to finish.

Discussion

Like forestprep, domainprep is normally a one-time operation performed before Exchange is installed. It performs several necessary actions:

It creates the Exchange Domain Servers global security group in the Users container. This security-sensitive group will eventually contain all of the Exchange servers in the domain and is required for the Recipient Update Service (RUS) to work because the RUS runs as a child of the System Attendant, which runs in the LocalSystem context. For the RUS to touch directory objects, this group must exist and the local machine account must be in it. However, adding an ordinary account to this group gives that account full access to Exchange 2000 mailbox data. For that reason, Exchange Server 2003 adds an explicit deny ACE on the Servers container for this group. To accomplish the same thing for Exchange 2000 servers, you’ll need to run the EDSLock script described in MS KB 313807.
It creates the Exchange Enterprise Servers local security group in the Users container. This group is used to allow Exchange services to work across multiple domains within a forest.
It nests Exchange Domain Servers inside Exchange Enterprise Servers.
It assigns permissions to these two groups on the domain object.
It creates the Microsoft Exchange System Objects container in the domain naming context.
It updates the default domain controller policy for the domain so that Exchange Enterprise Servers are granted the right to manage auditing and security logs. This is necessary to allow the information store service to read system ACLs on AD objects. If you later remove this right, you’ll have all sorts of problems as described in MS KB 314294.

Domainprep must be run after the forestprep operation has been completed—it relies on the schema updates and the existence of the Exchange organization container object. Domainprep does not need to be run in every domain in a forest; however, it must be run in:

The root domain of the forest
Any domain that will contain Exchange servers
Any domains that will contain Exchange recipients, such as users, security groups, and distribution groups
Any domains that will contain users and groups who will be managing Exchange servers

You must run domainprep top-down, starting with the root domain and working your way from parent to child domain. DomainPrep requires no Exchange permissions delegations; only Domain Admins and local machine administrator permissions are necessary. It can be run from any machine in the target domain.

2.6. Verifying That Forest and Domain Preparation Completed

Problem

You need to ensure that fore stprep and domainprep have completed successfully so you can install an Exchange server.

Solution

The solution depends on your version of Exchange. For Exchange 2000, there are two methods to validate the forest and one for the domain, while Exchange Server 2003 provides a handy tool that does both. The easiest method to validate the forest preparation on Exchange 2000 is to ensure that event ID 1575 appears in the directory event log on every domain controller that has successfully received the schema and object updates applied during forest preparation. The event message looks like this:

Event Type:    Information
Event Source:    NTDS Replication
Event Category:    Replication
Event ID:    1575
Date:        2/16/2005
Time:        3:18:42 PM
User:        Everyone
Computer:    BATMAN
Description:
One or more new attributes has been added to the partial attribute set for 
partition DC=test,DC=robichaux, 
DC=net. A full synchronization will be performed from source dbb5631d-3dfc-
41bd-b933-382f5d704aa6._msdcs.
test.robichaux.net on the next periodic synchronization.

This event actually means that the PAS (e.g., the set of attributes that are replicated to global catalog servers in the forest) has been changed; Exchange makes extensive changes to the PAS during forest preparation.

The alternative method requires the ADSI Edit MMC snap-in, which is installed as part of the Windows 2000 Support Tools:

From the Start menu, select Programs → Windows 2000 Support Tools → Tools → ADSI Edit.
Expand the Schema node and double-click the cn=ms-Exch-Schema-Version-Pt object. If it is present, the Exchange schema updates have been applied.
View the rangeUpper property. A value of 4397 corresponds to the original release version of Exchange 2000; values smaller than that are prerelease. A value of 6870 corresponds to the original release version of Exchange Server 2003.

To validate the domain preparation on Exchange 2000, use the PolicyTest utility on the domain controllers and ensure they have consistent security settings. This utility is provided as a separate utility in the Support directory of the Windows installation CD-ROM.

Using a graphical user interface for Exchange Server 2003

Start the Exchange deployment tools from the product CD.
Select Exchange Deployment Tools.
Select Deploy the first Exchange Server 2003 Server.
Select Coexistence with Exchange 5.5, if this is appropriate to the environment.
Move ahead to Phase 2, locate step 3, and enter the information. From here, you can run OrgPrepCheck.
After the tool is done, close ExDeploy and look at the ExDeploy logs, which will by default be stored in C:Exdeploy LogsExdeploy.log. The logs will tell you whether the forest and domain preparation steps worked.

Using a command-line interface for Exchange Server 2003

Insert the Exchange CD-ROM.

Run the following command:

                        <drive>:
supportexdeployexdeploy.exe /t:orgprepcheck

Look at the logs for forest and domain preparation status.

Discussion

Don’t attempt to install Exchange 2000 or 2003 until you’ve verified that both forestprep and domainprep have been run—while Setup will forestprep and domainprep your environment for you, it’s best to run both steps off-hours, as the results of these steps will need to replicate within your environment.

2.7. Installing Exchange on a Member Server

Problem

You want to install Exchange on a server that’s already joined to a domain and that has been prepared according to the requirements described earlier in the chapter.

Tip

If you’re using an Exchange 5.5 server, you can upgrade it to Exchange 2000, but not directly to Exchange Server 2003. The instructions below will work for upgrades from 5.5 to 2000 and from 2000 to 2003.

Solution

Using a graphical user interface

Log in with an account that is a member of the Exchange administrative group you specified during forestprep (see Recipe Recipe 2.4, step 9).
Back up your server using the backup utility of your choice (see Chapter 11 for some helpful hints).
Launch the Exchange setup utility from the product CD or installation point.
Click Next at the initial welcome screen.
Accept the license agreement and click Next.
If prompted for your 25-character product key, fill it in, comma and click Next.
When the Component Selection page appears, use the drop-down menus in the Action column to specify the appropriate action for each component, then click Next:
- If you’re installing Exchange Server 2003 on top of Exchange 2000, or Exchange 2000 on top of Exchange 5.5, set the Microsoft Exchange action to Upgrade.
- If you’re performing a clean installation of Exchange 2000 or Exchange Server 2003, set the Microsoft Exchange action to Install.
- If you only want to install the Exchange System Manager toolset, set the Microsoft Exchange System Management Tools action to Install.
On the Installation Summary page, verify your settings (including the installation path), then click Next.
Wait while the installation proceeds; it usually takes between 30 and 45 minutes.
Click Finish on the final setup page.
Check the application log for MSExchangeSetup event ID 1001; this event will only be posted if Setup completes successfully.
Use the Services control panel applet to verify that the Microsoft Exchange System Attendant and Microsoft Exchange Information Store services have started.
Back up your server again. Be extra-sure to keep a copy of the Exchange Server Setup Progress.log file from the root directory of your installation drive, since it contains a wealth of useful troubleshooting and progress information that you may need later.

Discussion

The mechanics of installing Exchange 2000 and 2003 are quite straightforward; the biggest requirement is that all of the prerequisites have been accomplished. That means that before you attempt to install Exchange, you should run the ExDeploy tools (which work fine for Exchange 2000 installations; just run them from the evaluation version of Exchange Server 2003) and fix any problems they report. You should also have completed the forestprep and domainprep steps (as described in Recipes Recipe 2.4 and Recipe 2.5). Recipe 1.1 Recipe 1.1Exchange setup will do these for you if it detects that they haven’t been completed before you run Setup (provided that the account you use to log on has adequate privileges), but it’s a better idea to run them first so you can ensure that they worked properly and fix any problems with replication that may occur.

2.8. Installing Exchange on a Domain Controller

Problem

You want to install Exchange on a domain controller.

Solution

There aren’t actually any technical barriers preventing you from doing this, although there are plenty of reasons why you may need to consider alternatives. The main technical issue is that when the server is rebooted or shut down, the Active Directory services stop before the Exchange services, which cause Exchange to pause while the DSAccess component waits for its AD queries to time out. This problem mainly arises when Exchange Server 2003 is installed on Windows Server 2003; the AD services on Windows 2000 don’t shut down as quickly. Of course, you shouldn’t be shutting down your servers that often. A more likely obstacle is that, depending on the size, configuration, and load on your server, you may find that performance of the combined services isn’t as good as you’d like. For organizations with limited budgets and a small number of seats, Microsoft sells the Small Business Server (SBS) product line, which combines Exchange with the DC role and several others on a single server; however, most production Exchange installations keep the roles separate.

Installing Exchange 2000 or 2003 on a DC is a supported configuration, even though most Exchange professionals will rightly tell you this is not the optimal or even recommended way to deploy Exchange. Avoid installing Exchange/DC combinations on clusters, though; this is not supported by Microsoft.

Discussion

There is at least one instance where Microsoft deploys this configuration—on a single-machine Small Business Server installation—so there is obviously no underlying concern that makes a shared Exchange/DC configuration technically invalid. There are good reasons for avoiding this configuration, however:

You lose the benefits of high-memory performance optimizations. Both services like to have a lot of system resources available and both will tend to assume that they are the sole consumer of those resources. In particular, you should not use the /3GB Windows startup option even if you have over 1 GB of RAM, to avoid the likelihood of Exchange starving out AD.
You lose the benefits of security compartmentalization. If your Exchange administrators are not also Domain Admins, you will need to grant them the Interactive Logon privilege on the shared server. Since this server is a DC—and since both Exchange and AD run as the LocalSystem account—administrators can use their local access to elevate their privileges and gain access to AD.
You lose the benefits of redundancy. The Exchange components that interact with AD will not load balance or fail over to another global catalog server if something happens to the AD services. Admittedly, if you are in a single-server configuration to begin with, losing your single DC will cripple Exchange anyway, but this is a large concern if you were considering deploying multiple Exchange/AD combos.
You make disaster recovery much more difficult. Restoring an Exchange/AD combo from bare metal is unpleasant at best and can take far longer than the combined restore times and processes for separate servers.

If you still feel that the combination configuration is useful, there are a couple of caveats to keep in mind:

The combination server must also be a global catalog server. Since you lose the load balancing and failover capabilities, AD must be able to provide all the lookups that Exchange requires. This will have an impact on your replication traffic and bandwidth usage if you are deploying this combination to a branch office in a multi-domain organization.
As previously mentioned, shutdowns and restarts will introduce a 10-minute delay on Exchange Server 2003 servers. You can either lower the default service timeout (not recommended, as it may impact the stability of the rest of the system) or ensure that your administrators manually shutdown the Exchange services before shutting down the server.

The following batch script fragment shows the necessary commands to stop the Exchange services before shutting down:

net stop "Microsoft Exchange Management" /yes
net stop "Microsoft Exchange Routing Engine" /yes
net stop "Microsoft Exchange Information Store" /yes 
net stop "Microsoft Exchange MTA Stacks" /yes
net stop "Microsoft Exchange System Attendant" /yes

There are a handful of Exchange services that will be automatically stopped as these services are stopped; the transport protocol services will be stopped when the IIS services are stopped.

2.9. Using Exchange Setup in Unattended Mode

Problem

You want to deploy multiple Exchange servers without manual intervention, or you want to automate the installation of an Exchange service pack.

Solution

Use the Exchange Setup /createunattend switch to create an unattended installation answer file. This file can then be used in conjunction with Setup’s /unattendfile option to duplicate the configuration specified in the answer file. This works both for Exchange installations and Exchange service packs.

Using a graphical user interface to create the unattended answer file

Launch the appropriate setup utility (setup.exe for Exchange installs, update.exe for service packs) with the /createunattend switch. You also have to specify the path to the answer file you want to create, like this:
```
C:	empe2k3-sp1i386update.exe /createunattend c:	empsp1-answer.udf
```
If you’re installing Exchange, click Next to dismiss the welcome screen, then accept the license agreement and click Next.
If prompted, enter your 25-character product key and click Next.
On the Component Selection page, select the components that you want to install. You can use the typical, minimum, or custom installation types for Exchange installations. For service packs, the action will default to Update; for clean installations, you’ll have to make sure that Install is selected. (Remember, you can install only the system management tools if you like).
If desired, use the Change Path button to select where the Exchange binaries (and thus the databases, by default) will be placed on the target disk.
Click Next.
On the Installation Summary page, click Next.
When setup completes, click Finish.
Optionally, open your answer file with a text editor and inspect its contents. (The unattended install white paper listed in the See Also section has a great deal of information on how these files are formatted and what their sections mean.)
Optionally, edit the answer file to specify which AG and routing group you want your servers installed in.

Using a graphical user interface to install Exchange with the unattended answer file

Launch the appropriate setup utility (setup.exe for Exchange installs, update.exe for service packs) with the /unattendfile switch. You also have to specify the path to the answer file you want to use for the install, like this:
```
d:setupi386setup.exe /unattendfile c:	emposton-answer.udf
```
By default, Setup will be completely silent; if you want to see the user interface as Setup proceeds, add the /ShowUI switch to your command line.
Wait for setup to complete and then verify that Exchange was set up properly.

Discussion

Unattended installations are a standard feature of Windows. Unattended answer files, often called .udf files because of their default extension, are a set of name-value pairs that specify the answers and options solicited by the setup process. These files provide a prepackaged set of input for the installer, removing the need to ask for them interactively. While you should use the /createunattend option to initially create a new unattend file, once you have it, you can use it as a template and manually edit it to create tuned configurations (e.g., for multiple domains).

Creating one answer file and using it to install multiple servers can be a big time saver. However, there are some significant limitations to this process.

You can perform only basic Exchange installations with this method—no disaster recoveries, forestpreps, or cluster installs allowed.
Unattended installs cannot be used to upgrade from a previous version of Exchange.
You can’t use unattended install to install the first Exchange 2000 or 2003 server in the organization.
You can’t perform unattended installs that add, remove, or re-install Exchange components.
Unattended installations require native Exchange mode, meaning that you can’t perform them in an organization that has remaining Exchange 5.5 servers. This greatly reduces the value of this option for organizations that are migrating from Exchange 5.5.

So what can you do with an unattended installation?

Add Exchange servers to an existing Exchange organization
Install the Exchange System Management Tools
Install Exchange service packs on existing Exchange servers
Prepare the domain (synonymous with the /domainprep switch)

If you have large server farms with consistent machine configurations, this option will speed up deployment of additional base servers. Any further configuration changes can then be performed manually or via the scripting techniques we demonstrate throughout the rest of the book.

2.10. Checking the Expiry Date of an Evaluation Version of Exchange

Problem

You’re using the evaluation version of Exchange and want to know how long you have before you hit the timeout period.

Solution

Using a graphical user interface

Launch the Exchange System Manager (Exchange System Manager.msc).
Expand the Administrative Groups node, then the AG that contains the server whose status you want to check.
Select the Servers container. The righthand pane contains a list of servers in that AG.
Find the target server and look at the date in its Modified column. This date indicates the last time that Exchange setup was run on the server. As long as no one has rerun setup since the original install date, adding 120 days to this date will tell you when the server will expire. This date can also be viewed by looking in the Exchange setup.log file on the root of the Exchange installation drive.

Using the command-line

Change to the root directory of the system drive; on most systems, this will be c:..
Use findstr to scan the Exchange setup log file for install operations; the example below will give you a list, with line numbers, of where the string Starting Exchange appears (the actual string will be Starting Exchange X setup on Y at DT, where X is the build number, Y is the OS build, and DT is the date and time):
```
> type "Exchange Server Setup Progress.log" | findstr /n /c:"Starting Exchange" *.log
```
Oddly, findstr doesn’t understand Unicode characters, so you’ll have to preprocess the log files by first filtering them through the built-in type utility to render them in plain ASCII. This may produce unpredictable results when run on non-English systems.
Run findstr again to look for the string “ID:62233” (the actual phrase is “This is an evaluation copy of Microsoft Exchange Server; it expires in 120 days—ID:62233”), like this:
```
> type "Exchange Server Setup Progress.log" | findstr /n /c:"ID:62233" *.log
```
Compare the line numbers from steps 3 and 4 to ensure that you get the correct start date; add 120 days to that date and you’ll know when your server is set to expire.

Discussion

Both of these solutions depend on the Exchange setup utility helpfully recording the time and type of each installation in the setup log. By checking it, you can determine when the server will expire if the setup log file hasn’t been removed. If the log file is gone, you’ll only be able to find out when the Exchange server refuses to mount databases, or you can try to deduce the installation time by looking at the time/date stamp on Exchange installation directories.

2.11. Upgrading the Evaluation Version of Exchange

Problem

You’ve installed the 120-day evaluation version of Exchange 2000 or 2003, and now you need to upgrade it to the full licensed version, but you don’t want to rebuild your server.

Solution

Using a graphical user interface

Launch the Exchange setup utility (setup.exe) from the product CD or installation point.
Click Next at the initial welcome screen.
Accept the license agreement and click Next.
If prompted for your 25-character product key, fill it in, and click Next.
When the Component Selection page appears, set the Action for the Microsoft Exchange component to Reinstall, then click Next.
Click Next on the summary screen.
Wait for the installation to complete. The Exchange services will automatically restart.
Launch the Exchange System Manager (Exchange System Manager.msc).
Select the Servers node beneath the AG that owns the target server. Check the server type shown in the righthand pane to verify that the server type no longer says Evaluation.

Discussion

Microsoft freely distributes 120-day evaluation versions of Exchange Server 2003, in both Standard and Enterprise Editions, from http://www.getexchange2003.com/dl. At the end of the evaluation period, the information store will no longer mount any databases. The files are still intact, and you can move them to another server, but it’s easier to install the licensed version of the product because doing so restores the server to full functionality. You don’t have to reboot after the upgrade, but during the upgrade itself, your users won’t be able to access their mailboxes.

2.12. Upgrading from Standard Edition to Enterprise Edition

Problem

You have a server running the Standard Edition of Exchange 2000 or 2003, and you want to upgrade it to the Enterprise Edition because your database has grown past the 16 GB limit of the Standard Edition.

Solution

Using a graphical user interface

Launch the Exchange setup utility (setup.exe) from the product CD or installation point.
Click Next at the initial welcome screen.
Accept the license agreement and click Next.
If prompted for your 25-character product key, fill it in, and click Next.
When the Component Selection page appears, set the Action for the Microsoft Exchange component to Reinstall, then click Next.
Click Next on the summary screen.
Wait for the installation to complete. The Exchange services will automatically restart.
Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, select the Servers node beneath the AG that the target server is a member of. Check the server type shown in the righthand pane to verify that the server type no longer says Standard.

Discussion

The actual product differences between the Standard and Enterprise Editions are relatively small, as shown in Table 2-1, but they vary somewhat between Exchange 2000 and 2003. In both Exchange 2000 and Exchange Server 2003, the Standard Edition software cannot be part of a Windows cluster, and it is limited to a total of two databases per server: one public database and one mailbox database, neither of which may exceed 16 GB in size. The Enterprise Edition can be clustered, and it supports up to 20 databases per server. For Exchange 2000 only, the Enterprise Edition is required if you want the server to function as a front-end; in Exchange Server 2003, Standard servers can play this role.

Table 2-1. Comparison of Standard and Enterprise Exchange editions

Feature	Exchange 2000 Standard	Exchange 2000 Enterprise	Exchange Server 2003 Standard	Exchange Server 2003 Enterprise
Clustering	No	Yes	No	Yes
# of databases per server	2 (1 public + 1 private)	20	2 (1 public + 1 private)	20
# of storage groups per server	1	4	1	4 + recovery storage group
Max database size	16 GB each	Unlimited	16 GB each	Unlimited
Max usable RAM size	4 GB	4 GB	4 GB
Can operate as front-end server	No	Yes	Yes	Yes

2.13. Enumerating All Existing Exchange Servers

Problem

As part of an installation, update, migration, or other administrative task, you might want to find out which Exchange servers already exist in an organization.

Solution

Using a graphical user interface

Launch the Exchange System Manager (Exchange System Manager.msc).
Expand the Administrative Groups node, and then expand each AG that appears below it.
Select the Servers node in each AG. The righthand pane contains the servers in that administrative group, along with their type (basic or clustered), edition (enterprise or standard), version, and modification date.

Using a command-line interface

The following command will query Active Directory to find existing Exchange servers and the version of Exchange installed.

> dsquery * "cn=microsoft exchange,cn=services,cn=configuration,<ForestRootDN>" 
  -filter "(objectCategory=msExchExchangeServer)" -scope subtree -attr name serialNumber

Using VBScript with WMI

' This code uses WMI to interrogate the Exchange routing table 
' and list all known Exchange servers.
' ------ SCRIPT CONFIGURATION ------
 strComputerName = "<ServerName>"    ' e.g., exch01
' ------ END CONFIGURATION ---------

  strE2KWMIQuery = "winmgmts://" & strComputerName &_
   "/root/cimv2/applications/exchange"
  strE2K3WMIQuery = "winmgmts://" & strComputerName &_
    "/root/MicrosoftExchangeV2"
  
' display basic attributes using Exchange 2000 WMI provider 
  set serverList = GetObject(strE2KWMIQuery).InstancesOf("ExchangeServerState")
  for each ExchangeServer in serverList
    WScript.Echo "Exchange 2000 properties---------"
    WScript.Echo "Name:    " & ExchangeServer.Name
    WScript.Echo "DN:      " & ExchangeServer.GroupDN
    WScript.Echo "Version: " & ExchangeServer.Version
  Next
  WScript.Echo ""
  
  ' display additional Exchange 2003 provider information
  ' real code should include error checking here
  Set serverList = GetObject(strE2K3WMIQuery).InstancesOf("Exchange_Server")
  
  For each Exchange_Server in serverList
     WScript.Echo "Exchange 2003 properties--------"
     WScript.Echo "Name:        " & Exchange_Server.Name
     WScript.Echo "FQDN:        " & Exchange_Server.FQDN
     WScript.Echo "Admin Group  " & Exchange_Server.AdministrativeGroup
  Next

Using VBScript and querying Active Directory

' This code searches Active Directory for Exchange servers
 ' ------ SCRIPT CONFIGURATION ------
 strBase = "<LDAP://cn=microsoft exchange,cn=services,cn=configuration,<ForestDN>>;"
 ' ------ END CONFIGURATION ---------
 
 strFilter = "(objectCategory=msExchExchangeServer);"
 strAttrs = "cn;"   ' add more attributes here if desired
 strScope = "subtree"
 
 Set objConn = CreateObject("ADODB.Connection")
 objConn.Open "Provider=ADsDSOObject;"
 
 Set objRS = objConn.Execute(strBase & strFilter & strAttrs & strScope)
 objRS.MoveFirst
 While Not objRS.EOF
   wscript.echo objRS.Fields(0).Value
   objRS.MoveNext
 Wend

Discussion

Using VBScript with WMI

The Exchange WMI providers exposes tons of information about servers in the organization, including the DN (from which you can tell which AG the server’s in), its version (“6944” is Exchange Server 2003 RTM, “61xx” is Exchange 2000), and information about which states the disk, CPU, RAM, and network connections are in. Exchange Server 2003 adds a number of other attributes to its provider, which you access with the Exchange_Server class; the code shows how to access the fully-qualified domain name and AG information.

Using VBScript and querying Active Directory

Exchange severs are represented in Active Directory as ordinary computers or domain controllers. Because an Exchange server can be in any domain of the forest, and in any organizational unit (OU) within its domain, the most reliable way to find servers is to look in the configuration naming context (NC), in particular, within the AG containers contained beneath the Microsoft Exchange services container. You can query for any attribute present on the computer object; for this example, we arbitrarily chose CN.

2.14. Enumerating All Exchange Connectors

Problem

As part of your preparation for a migration from Exchange 5.5, or an upgrade from Exchange 2000, you want to list all of the active connectors in the organization so you can identify which ones will be affected, or need to be recreated, when it’s time to decommission old servers. It’s important to be sure that your routing environment will continue to work post-migration, and by first checking which connectors are deployed on which servers, you’re covering all the bases.

Solution

Using a graphical user interface

There’s no good way to do this with the GUI. The best way is to use Exchange System Manager to poke around in the Connectors container of each routing group in your organization; when you select such a container, you’ll see a list of the connector names and types (e.g., routing group connector, X.400, etc.). This is tiresome in large organizations.

Using a command-line interface

The following command will query Active Directory to find existing Exchange connectors, the address space they serve, and their costs:

>dsquery * "cn=microsoft exchange,cn=services,cn=configuration,<ForestRootDN>" 
  -filter "(objectCategory=msExchConnector)" -scope subtree -attr name routingList

Using VBScript

' This code uses WMI to interrogate the Exchange routing table 
' and list all connectors in the Exchange organization.
' ------ SCRIPT CONFIGURATION ------
 strComputerName = "<ServerName>"   
' ------ END CONFIGURATION ---------
strWMIQuery = "winmgmts://" & strComputerName &_
   "/root/cimv2/applications/exchange"
   
set connectorList= GetObject(strWMIQuery).InstancesOf("ExchangeConnectorState")
for each ExchangeConnector in connectorList
    WScript.Echo "Name:             " & ExchangeConnector.Name
    WScript.Echo "DN:               " & ExchangeConnector.GroupDN
    WScript.Echo "Routing Group DN: " & ExchangeConnector.Version
    If (ExchangeConnector.IsUp) Then
        WScript.Echo ("Status:          : Up")
        Else
        WScript.Echo ("Status:          : Down")
    End If
Next

Discussion

Using VBScript

The ExchangeConnectorState class gives you information on connectors throughout the entire organization, since it reads connector data from the link-state routing table. You can see the name and status of individual links, but to access the queue contents you’ll need to use the Exchange link and queue objects (there are different versions for Exchange 2000 and Exchange Server 2003).

2.15. Switching Exchange from Mixed Mode to Native Mode

Problem

You have gotten rid of all of your Exchange 5.5 servers, and all legacy connectors and components have been removed from your Exchange organization. You want to switch to native mode to take advantage of the additional features offered, such as a pure SMTP routing environment and the ability to move servers between AGs.

Solution

Using a graphical user interface

Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, right-click the organization object, and select Properties.
On the General tab, click the Change Operation Mode button. Note that this change, once completed, cannot be reversed. Click Yes in the notification box to confirm you want to make the change.

Using a graphical user interface (alternative)

Open ADSI Edit (adsiedit.msc) from the Windows Support Tools.
Expand the configuration container. Drill down to the appropriate CN=Configur-ation, DC= <domain> ,DC= <tld> container for your Exchange organization.
Expand the CN=Services container and select the CN= <domain> object that matches your domain. Right-click it and select Properties.
On the Attributes tab, in the Select a property to view drop-down list, select msExchMixedMode. In the Attribute Values area, in the Edit Attribute line, type FALSE. Click the Set button, then the Apply button, then OK.

Discussion

Moving from mixed-mode operations to native mode is the final step in most migrations from Exchange 5.5 to Exchange 200x. Your organization can realize about a 15% bandwidth savings on messages that contain binary data, since the 8BITMIME SMTP verb will now be used between routing groups. Switching to native mode also means you’re rid of the Active Directory Connector and the Site Replication Service, and you can finally begin using query-based distribution groups. Table 2-2 lists the specific functionality that you gain when you switch to native mode. Some features are available only on Exchange Server 2003 servers, while others are available on Exchange 2000 as well.

Table 2-2. Native-mode-specific functionality

Functionality provided	Exchange 2000	Exchange Server 2003
Routing groups can have servers from multiple administrative groups	Yes	Yes
Servers can be moved between routing groups	Yes	Yes
SMTP becomes default routing protocol	Yes	Yes
Allows for LDAP query-based distribution groups	No	Yes
Information Store service ignores and removes zombie ACEs from tombstoned Exchange 5.5 servers	No	Yes

2.16. Creating the First Administrative Group with a Custom Name

Problem

By default, Exchange setup creates an AG named First Administrative Group when you install the first Exchange 2000 or 2003 server. As part of your initial Exchange 2000 or Exchange Server 2003 deployment, you want to create a default AG with a name you choose.

Solution

Using a graphical user interface

Launch the Exchange setup utility (setup.exe) from the product CD or installation point.
Accept the license agreement and click Next.
If prompted, enter your 25-character product key and click Next.
When the Component Selection page appears, set the Action for Microsoft Exchange System Management Tools to Install. Don’t install anything else; you’ll need to set the action for Microsoft Exchange Messaging and Collaboration Services to None.
Click Next on the summary screen.
Wait for the installation to complete.
Launch the Exchange System Manager (Exchange System Manager.msc).
Right-click the Administrative Groups node under your Exchange organization, then choose the New→ Administrative Group command.
When prompted, give your new administrative group a name, and then click OK.

Discussion

In Exchange 2000 and Exchange Server 2003, AGs are used to collect servers that should be managed together. Servers in the same administrative group can have a consistent set of Exchange system policies applied, and you can delegate control over the administrative group to an Active Directory group. However, moving servers between administrative groups isn’t officially supported by Microsoft, so you should install servers into the desired AG from the outset. If you accept the standard installation settings, you’ll end up with First Administrative Group as the default container for the first server you install.

In environments where you want to separate servers by administrative group, it’s a little clunky to have all except one of your administrative groups named after regions or business units. Although you can move some types of objects between administrative groups, you’ll be better off to create a new admin group before installing any servers. Of course, you can create all of your AGs using this trick before installing any servers. As an alternative, you can rename the first administrative group by using Exchange System Manager.

2.17. Viewing Administrative Groups in Exchange System Manager

Problem

You want to see AGs in Exchange System Manager so that you can inspect and modify them.

Solution

Using a graphical user interface

Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, right-click the Exchange organization node and select the Properties command.
Switch to the General tab.
Check the Display administrative groups checkbox. If you’ve already switched to native Exchange mode, this will already be on.
Optionally, check the Display routing groups checkbox if you want to see routing groups displayed within the AGs that contain them.
Click OK.
If Exchange System Manager warns you that you’ll have to relaunch ESM to see the changes, click OK, then quit and restart ESM.
Verify that there’s a node labeled Administrative Groups in the lefthand ESM pane. Expand it to see what administrative groups currently exist.

Discussion

What AGs you have will depend on how you installed Exchange. In a clean Exchange 2000 or Exchange Server 2003 installation, you’ll only have one: First Administrative Group. If you used the instructions in Recipe 2.16, this first group may have a different name. If you’re installing Exchange 2000 or 2003 into an existing Exchange 5.5 organization, then you’ll see each Exchange 5.5 site as a separate AG: that’s because a 5.5 site is the boundary for both message routing and administrative control. However, you won’t see any of these AGs unless you enable their display in ESM.

2.18. Creating Administrative Groups

Problem

You need to create an additional AG to group servers together into a single cohesive unit for management.

Solution

Using a graphical user interface via ESM

Launch the Exchange System Manager (Exchange System Manager.msc).
If you don’t see an Administrative Groups node in ESM’s lefthand tree pane, see Recipe 2.17.
Right-click the Administrative Groups container and choose New → Administrative Group.
On the General tab of the resulting dialog box, enter the name you want to use for this Administrative Group. Click OK.

Using a graphical user interface via ADSIEdit

Open ADSI Edit (adsiedit.msc) from the Windows Support Tools.
Expand the configuration container. Drill down to the appropriate CN=< orgName >, CN=Microsoft Exchange, CN=Services,CN=Configuration, DC= <domain >,DC=< tld> container for your Exchange organization.
Right-click the CN=Administrative Groups container and choose New → Object.
In the Select a class area, select msExchAdminGroup, and then click Next.
Type the name you want to assign to the AG in the Value text field. Click Next, then click Finish.

Discussion

AGs are used to define boundaries of administration, usually in organizations where administrative responsibilities are decentralized. For example, many companies choose to create separate AGs for each geographical region, and then they delegate administrative control over those AGs to administrators in that region. This provides a flexible way to keep all of the European servers in one group and all of the North American ones in another; it’s also common to see multiple AGs defined to match the structure of business units or divisions. Because servers and routing groups are both contained within AGs, you can group resources that should be managed by the same people together and delegate access to them.

Tip

Microsoft recommends against creating AGs from VBScript.

2.19. Removing Administrative Groups

Problem

You want to remove an AG because it is no longer needed within your Exchange organization.

Solution

Using a graphical user interface

Open ADSI Edit (adsiedit.msc) from the Windows Support Tools.
Expand the configuration container. Drill down to the appropriate CN=Configur-ation, DC= <domain> ,DC= <tld> container for your Exchange organization.
Expand the CN=Services container, then expand the CN= <Organization> object that matches your domain and the CN=Administrative Groups node it contains.
Right-click the AG you want to delete, then select Delete. Click OK twice when prompted.

Discussion

Every object in Exchange has to be owned either by a server (e.g., storage groups, databases) or by an AG (e.g., servers, connectors, and routing groups). If you delete an AG without removing the objects in it, that would leave orphaned objects, which would be bad. However, if ESM allowed you to easily remove an AG and all the objects it contains, that would be worse—imagine a single-click way to remove all of your servers, storage groups, and so on! To make it harder to delete a needed object accidentally, Microsoft blocks deleting AG objects from ESM; you must use ADSI Edit or VBScript to remove unnecessary AGs.

Tip

Microsoft recommends against deleting AGs from VBScript.

2.20. Moving Objects Between Administrative Groups

You need to move a server or routing group from one AG to another.

Solution

Using a graphical user interface

Open ADSI Edit (adsiedit.msc) from the Windows Support Tools.
Drill down through the structure, expanding the following containers: Configuration Container → CN=Configuration → CN=Services → CN=Microsoft Exchange → CN=<organization> → CN=Administrative Groups.
Highlight and expand the AG that currently hosts the object you want to move.
Highlight the container holding the object type you want to move (i.e., CN=Servers).
In the right pane, right-click the object you want to move and select the Move command.
In the Move dialog box, drill down through Services → Microsoft Exchange → <domain> → Administrative Groups and select the AG you wish to move the object to. Click OK.

Warning

Microsoft doesn’t officially support moving Exchange servers between AGs using this method. It seems to work fine, but you should thoroughly test for side effects before making the change to a production server.

Using VBScript

' This code moves a server named W2KDC1 from the First Administrative 
' Group to an  Administrative group named Test AG.
' ------ SCRIPT CONFIGURATION ------
strNewParentAG = "LDAP://CN=Servers,CN=Test AG,CN=Administrative &_
    Groups,CN=<organization>,CN=Microsoft Exchange,CN=Services,&_
    CN=Configuration,DC=<domain>,DC=com"
strCurrentAG = "LDAP://CN=W2KDC1,CN=Servers,CN=First Administrative &_
    Group,CN=Administrative Groups,CN=<organization>,CN=Microsoft &_
    Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=com"
StrObjectW2KDC1 = "CN=W2KDC1"
' ------- END CONFIGURATION --------

set objCont = GetObject(strNewParentAG)
objCont.MoveHere strCurrentAG, strObjectW2KDC1

Discussion

According to Microsoft, once you install a server into an AG, or create a routing group within an AG, it’s marooned there forever, even if you have a good reason (like site consolidation) to do away with some of your administrative groups. ESM doesn’t allow you to move servers or routing groups (RGs) between AGs, even though in early Exchange 2000 betas this feature was enabled. If you need to move a server to another AG, you must move all mailboxes and Exchange resources to another server, remove the server, and rebuild it in the target AG. Once the server has been rebuilt into the new AG, you can move the Exchange mailboxes and resources to the relocated server.

Table of Contents for 2. Installation and Infrastructure

Create new playlist

Sign In

Sign Up

Chapter 2. Installation and Infrastructure

Introduction

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

Problem

Solution

Using a graphical user interface

Using a command-line interface

Discussion

See Also

2.2. Preparing a Windows 2000 Server Computer for an Exchange Installation

Problem

Solution

Using a graphical user interface

Using a command-line interface

Discussion

See Also

2.3. Preparing a Windows Server 2003 Computer for an Exchange Installation

Problem

Solution

Using a graphical user interface

Using a command-line interface

Discussion

See Also

2.4. Preparing an Active Directory Forest for Exchange

Problem

Solution

Using a graphical user interface for Exchange 2000

Tip

Using a graphical user interface for Exchange Server 2003

Using a command-line interface with Exchange 2000 or Exchange Server 2003

Discussion

See Also

2.5. Preparing an Active Directory Domain for Exchange

Problem

Solution

Using a graphical user interface

Discussion

See Also

2.6. Verifying That Forest and Domain Preparation Completed

Problem

Solution

Using a graphical user interface for Exchange Server 2003

Using a command-line interface for Exchange Server 2003

Discussion

See Also

2.7. Installing Exchange on a Member Server

Problem

Tip

Solution

Using a graphical user interface

Discussion

See Also

2.8. Installing Exchange on a Domain Controller

Problem

Solution

Discussion

See Also

2.9. Using Exchange Setup in Unattended Mode

Problem

Solution

Using a graphical user interface to create the unattended answer file

Using a graphical user interface to install Exchange with the unattended answer file

Discussion

See Also

2.10. Checking the Expiry Date of an Evaluation Version of Exchange

Problem

Solution

Using a graphical user interface

Using the command-line

Discussion

See Also

2.11. Upgrading the Evaluation Version of Exchange

Problem

Solution

Using a graphical user interface

Discussion

Table of Contents for
2. Installation and Infrastructure