Exchange Server Cookbook | O'Reilly Media

Content preview·Buy reprint rights for this chapter

Exchange is a complex and powerful tool. Microsoft has gone to great lengths to hide much of the complexity by providing a set of graphical user interface (GUI) tools and wizards that automate many common tasks, but most administrators really want to understand how Exchange works and how to make it work well. This book is aimed squarely at the latter of those two desires: we're not going to be discussing Exchange's architecture or implementation in detail. Instead, the recipes in this book focus on laying bare some of the many features and capabilities that lie beneath the shiny GUI veneer of Exchange. This chapter will help prepare you for that exploration by presenting some basic concepts and identifying some tools and technologies that can help you with Exchange scripting.

If you've used Perl, you're probably familiar with its unofficial motto, There's More Than One Way to Do It. As you may have learned from the Active Directory Cookbook and the Windows Server Cookbook (both from O'Reilly), Windows's unofficial motto could be There Are at Least Three Ways to Do It. Many common tasks can be performed using a GUI) or wizard (such as the Active Directory Users and Computers [ADUC] snap-in or the LDP tool), from the command line (using utilities provided by Microsoft such as nltest and dsadiag), or by writing scripts that use some of the programming interfaces exposed by various parts of the operating system. Surprisingly, this motto usually (but, unfortunately, not always) holds true for Exchange tasks, too—there are usually two or more ways to accomplish a given task.

Since people have different preferences, we've tried to live the motto by presenting more than one method for performing each recipe. This isn't always possible; some tasks can't be scripted or run from the command line, while others can only be performed with a script. Wherever possible, though, we've included at least one command-line method, one GUI method, and one script for each recipe.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Exchange is a complex and powerful tool. Microsoft has gone to great lengths to hide much of the complexity by providing a set of graphical user interface (GUI) tools and wizards that automate many common tasks, but most administrators really want to understand how Exchange works and how to make it work well. This book is aimed squarely at the latter of those two desires: we're not going to be discussing Exchange's architecture or implementation in detail. Instead, the recipes in this book focus on laying bare some of the many features and capabilities that lie beneath the shiny GUI veneer of Exchange. This chapter will help prepare you for that exploration by presenting some basic concepts and identifying some tools and technologies that can help you with Exchange scripting.

If you've used Perl, you're probably familiar with its unofficial motto, There's More Than One Way to Do It. As you may have learned from the Active Directory Cookbook and the Windows Server Cookbook (both from O'Reilly), Windows's unofficial motto could be There Are at Least Three Ways to Do It. Many common tasks can be performed using a GUI) or wizard (such as the Active Directory Users and Computers [ADUC] snap-in or the LDP tool), from the command line (using utilities provided by Microsoft such as nltest and dsadiag), or by writing scripts that use some of the programming interfaces exposed by various parts of the operating system. Surprisingly, this motto usually (but, unfortunately, not always) holds true for Exchange tasks, too—there are usually two or more ways to accomplish a given task.

Since people have different preferences, we've tried to live the motto by presenting more than one method for performing each recipe. This isn't always possible; some tasks can't be scripted or run from the command line, while others can only be performed with a script. Wherever possible, though, we've included at least one command-line method, one GUI method, and one script for each recipe.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Over time, Microsoft has gotten more generous with its tools. With Exchange 5.5, there were only a few tools shipped on the product CD; most of the good stuff was available only to customers who'd purchased Premier-level support contracts, and many of those tools were officially unsupported. We made a conscious decision to steer away from those tools in this book; instead, we'll stick with tools that are available from, and supported by, Microsoft as part of its Exchange and Windows platforms (with occasional exceptions for extraordinarily useful tools that aren't officially supported). These tools come from a variety of places:

Microsoft finally has an Exchange-specific tools page at http://www.microsoft.com/exchange/tools/2003.asp. This is the best place to start, as it will always contain the latest supported build of released tools; for example, the exmerge tool is included on the product CD, but there's a newer version available from this page. Don't let the name fool you; this page contains tools that work with both Exchange 2000 and Exchange Server 2003. Microsoft periodically releases updates to these tools in packages called web releases (WRs), which are more or less like service packs for the add-on toolset. There's also an option to download All Tools, which we highly recommend, as having the tools available locally may mean you won't have to go searching for tools during a crisis.
A number of tools are available in the support\utils directory of the Exchange CD itself. If you have the Exchange Server 2003 CD, use it because many of the tools it contains are newer than the versions shipped with Exchange 2000.
The diagnostic tools used for Active Directory troubleshooting are found on the Windows 2000 and Windows Server 2003 CDs, in the support\tools directory. Besides these diagnostic tools, the support tools archive includes a wealth of other useful tools.
The Windows resource kits (see

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Because there's so much to learn about Exchange, this book alone can't possibly teach you everything you might want to know. Accordingly, you might find some of the following references useful.

Starting with Exchange Server 2003's release, Microsoft has put much more effort into building administrator-friendly supplementary documentation. The product documentation included on the CD has always been decent, but now the Exchange user education (UE) team has been tasked with producing supplementary white papers that cover selected aspects of Exchange administration in much more detail. Throughout the book, we'll refer to various white papers and how-to documents published by Exchange UE (and their Windows counterparts). The canonical source for these documents is Microsoft's Exchange library (http://www.microsoft.com/exchange/library), although many of the most useful documents are posted in various places on Microsoft TechNet (http://www.microsoft.com/technet). To be more specific, some of the papers and documents you should be familiar with include:

The Exchange Server 2003 Administration Guide (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/admingde.mspx) is a detailed guide to a number of common Exchange administrative tasks. More importantly, the guide explains why you might need to take various actions, although on its own, it's no substitute for a good understanding of how Exchange works.
The Exchange Server 2003 Security Operations Guide (http://www.microsoft.com/downloads/details.aspx?familyid=6a80711f-e5c9-4aef-9a44-504db09b9065&dis-playlang=en) describes Microsoft's recommendations for hardening Exchange Server 2003 servers in various roles. There's a corresponding guide for Exchange 2000 as well.
The Exchange Server 2003 Deployment Guide (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to install Exchange on a domain controller.

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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

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:\temp\e2k3-sp1\i386\update.exe /createunattend c:\temp\sp1-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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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

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
```

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

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.

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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

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=Adm

Table of Contents

Using a graphical user interface

Using a graphical user interface

Using a command-line interface

Using a graphical user interface

Using a command-line interface

Using a graphical user interface for Exchange 2000

Using a graphical user interface

Using a graphical user interface

Using a graphical user interface to create the unattended answer file

Using a graphical user interface

Using the command-line

Using a graphical user interface

Using a graphical user interface

Using a graphical user interface

Using a command-line interface

Using VBScript with WMI

Using a graphical user interface

Using a command-line interface

Using VBScript

Using a graphical user interface

Using a graphical user interface (alternative)

Using a graphical user interface

Using a graphical user interface

Using a graphical user interface via ESM

Using a graphical user interface via ADSIEdit