Introduction

Exchange Server 2003 is Microsoft's messaging and collaboration server application. It enables you to send and receive email and other interactive messages through computer networks. Exchange is designed to integrate directly with Microsoft Outlook and has a rich application programming interface (API) that can be utilized to integrate custom applications, making it a very flexible framework for business collaboration.

Although Windows Server 2003 has built-in SMTP and POP3 support, it isn't enough for serious corporate needs. If you like analogies, SMTP/POP3 services are to Exchange what the Model-T is to the modern automobile. You can certainly recognize the basic pieces, but there have been notable extensions to those pieces to make the product more flexible and powerful for today's needs. Some additional features in the product are IMAP, Web Email Support via Outlook Web Access (OWA), a robust calendaring system, advanced message routing, distribution lists, public folders, configurable spam filtering, and considerable functionality for controlling message flow and client experience.

Exchange was one of the first Active Directory-enabled applications. This is an unsurprising fact as Active Directory is based in great part on the directory technology "borrowed" from Exchange. It is probably also unsurprising that Exchange is a heavy consumer of Active Directory, for the same reason, and extremely dependent upon Active Directory functioning well. Because of this tight integration, you should try to incorporate Exchange requirements into your overall Active Directory design as early as possible. Failure to do so can have significant impact on the quality of service of both the Active Directory and Exchange. The integration of Exchange could require your Active Directory design to change considerably.

Exchange has a large feature-set, and several books have been written that cover designing, implementing, and running Exchange. What I present here is a small set of appetizer recipes covering some of the more basic functions, including installing a new instance of Exchange Server 2003 and some basic administration tasks. If you would like to get the full seven-course meal, you should consider getting the Exchange Server Cookbook from O'Reilly.

Using a Graphical User Interface

Exchange has traditionally been administrated from the GUI. There are two primary Microsoft GUI tools for administrating Exchange, both based on the Microsoft Management Console (MMC).

The first is a tool you probably already know: the Active Directory Users and Computers (ADUC) tool. Microsoft has extended the functionality of this Active Directory tool to manage many aspects of the users and groups used by Exchange. This makes sense since most Active Directory administrators are already familiar with this tool and the information being updated is primarily in Active Directory. If you are working only with managing users' Exchange information, you will most likely spend your time with this tool.

The second tool is the Exchange System Manager (ESM), which is used for configuring and monitoring the overall Exchange environment, including servers, policies, queues, routing connectors, and other configuration specific settings.

You can find these tools on any server running Exchange, and they can also be installed onto non-Exchange servers and clients for remote administration of Exchange. See Recipe 17.6 for more on this topic. All graphical solutions in this chapter require the Exchange management tools to be present on the workstation or server being used.

Using a Command-Line Interface

As previously mentioned, Exchange was traditionally managed from the GUI, so the availability of command-line tools for basic Exchange management functions isn't what you would call staggering. The primary reason for this is the complexity of the Exchange system. Simply put, Exchange can do a lot of different things and needs specific customizations for each deployment. Using custom scripts tends to be the most efficient way for most organizations to handle Exchange functions from the command line.

If you really prefer non-scripted CLI though, most of the configuration information for Exchange is kept in Active Directory. This means you can use your usual Active Directory command-line tools to query and set Exchange information. You simply have to understand what specific attributes are used to control that specific functionality in Exchange. This may be less intuitive than one would hope, but with sufficient testing and research you can do a considerable amount with Exchange via Active Directory command-line tools, such as ldifde. The general process most administrators follow when trying to work this out is to use the GUI to do something and then look at the resulting Active Directory object created or modified and then trying to duplicate it via script or CLI. Of course, you will want to do this in a test lab before utilizing your results in a production environment.

Unless otherwise noted, all command-line solutions require the Exchange management tools to be present on the workstation or server being used. See Recipe 17.6 for more on installing these tools.

Table 17-1 lists the command-line tools used in this chapter and the recipes they are used in.

Table 17-1. Command-line tools used in this chapter

Tool	Windows Server 2003	Windows 2000	Recipes
ldifde	%SystemRoot%\system32	%SystemRoot%\system32	17.9, 17.10, 17.12, 17.18-17.22, 17.24
ExchMbx	http://www.joeware.net	http://www.joeware.net	17.9-17.12, 17.16,17.18-17.20
Dsadd	%SystemRoot%\system32	N/A	17.20

Using VBScript

Through the WMI, ADSI, and CDOEXM scripting interfaces you have the capability to automate many Exchange tasks. Table 17-2 lists all WMI classes used in this chapter. Unfortunately, the CDOEXM interface isn't available by default on Windows computers, so you will need to load the Exchange management tools on computers that run any scripts using that interface.

Table 17-2. WMI classes used in this chapter

WMI class	Description	Recipes
Exchange_Mailbox	WMI class that represents Exchange mailboxes	17.13-17.15, 17.17
Exchange_DSAccessDC	WMI Class that represents DSAccess	17.26

WMI and ADSI are covered in Appendix B and Appendix C, respectively. Since CDOEXM is specific to Exchange programming, I'll cover it in more depth here. CDOEXM stands for Collaboration Data Objects for Exchange Management and is a COM library supplied by Microsoft for developing messaging and administration applications for Exchange. You can find the documentation for CDOEXM in the Microsoft Online MSDN Library and the Exchange Server 2003 Software Development Kit (SDK). There are additional WMI classes available for Exchange that are not used for recipes in this chapter (see the Exchange SDK for more information).

Notes on Managing Exchange

Managing Exchange is a little different from managing most other Microsoft applications. The computer where you run the tools or scripts must be a member of a domain in the forest where the Exchange organization resides. This is true whether you are using a script or the GUI. Exchange doesn't allow you to select other organizations to manage. This can be troublesome for someone managing multiple Exchange organizations or a mobile worker who moves between sites or companies and likes to run her workstation in workgroup mode instead of being a member of any specific domain.

Permissions are very important and often misunderstood in Exchange. Permissions can be set up very simply or in a very complicated way; it is tough to find a middle ground. The simplest method is to give your Exchange administrators Domain Admin access. This is pretty standard in small companies where the Exchange administrators are doing all aspects of administration. But this practice is usually unacceptable in larger companies where separation of duties and more security is required. See Recipe 17.7 for more discussion and details on permissions.

Finally, it is preferable to run Exchange in Active Directory native mode (for Windows 2000) or at the Windows Server 2003 forest functional level. Running Exchange in an Active Directory mixed-mode environment can be troublesome. If you must run in this mode, try to keep the timeframe as short as possible and anticipate that things will not work exactly as expected during that time.