Section 1.1. Cooking with Exchange

1.1. Cooking with Exchange

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.

At Least Three Ways to Do It

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, toothere 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.

2000 Versus 2003, Times Two

Exchange 2000 and 2003 depend on Active Directory, which is implemented in both Windows 2000 and Windows Server 2003. That presents a bit of difficulty, since there are several possible combinations of these products:

• Exchange 2000 running on Windows 2000 is the baseline; this combination has been around for a few years and is stable and widely deployed.

• Exchange Server 2003 running on Windows 2000 offers many of Exchange Server 2003's cool new features (like the improved Outlook Web Access interface, better spam filtering, and so on) while still using the base AD services from Windows 2000.

• Exchange Server 2003 running on Windows Server 2003 in a Windows Server 2003 forest provides the full range of new capabilities, including Remote Procedure Call (RPC)-over-HTTP tunneling, access to the Volume Shadow Copy Service (VSS) for making point-in-time "snapshot" backups, and so on.

Even though Exchange Server 2003 is newer and more capable than its predecessor, Exchange 2000 and Exchange Server 2003 are similar in many important respects; the same is pretty much true for the two Windows variants. However, since Exchange Server 2003 running on Windows 2003 provides the most functionality, that's the target for the recipes here. Most of the recipes will work with Exchange 2000 and/or Windows 2000, and some only work with those products. To make it perfectly clear which is which, we've noted version-specific recipes where they occur. (We haven't tested any of these recipes with any version of Microsoft Small Business [SBS] server, but it's fairly safe to assume that they should work on SBS as well. Please test thoroughly, though, as we're not available to help you fix anything that may get broken.)

The Exchange GUI Interface

One complaint administrators had with Windows NT administration was that ordinary tasks required too many different tools. Microsoft attempted to fix this situation by introducing the Microsoft Management Console (MMC), which allows you to build your own customized administration consoles by loading combinations of modules called snap-ins. The bulk of an Exchange administrator's tasks are usually done through the Exchange System Manager (ESM) management console snap-in (Exchange System Manager.msc). ESM enables administrators to perform hundreds of tasks, to view numerous settings, and to see a visual representation of their environment. User and group management requires the ADUC snap-in (dsa.msc); other Windows components, like the DNS and DHCP servers and the Windows Certificate Services tools, have their own dedicated snap-ins. Just to confuse things a little, the Exchange setup program also installs its own version of ADUC (users and computers.msc). We've never fully understood why Microsoft chose to do this. For example, if you install the adminpak.msi on a computer, the dsa.msc snap-in will still show the Exchange properties on objects, as long as the Exchange Admin tools are also installed.

ESM follows the basic MMC interface paradigm: a tree view on the left side that shows one or more nodes (some with child nodes, some without), plus a large pane on the right side that displays subordinate nodes or settings for whatever's selected in the left pane. This doesn't sound like too much to master; the real trick with ESM is learning which settings are in which property pages, because there certainly are a lot of both around. It's also important to understand the versions of ESM and what they can do:

• The Exchange 2000 ESM is what we think of as the "classic" version. It can be used to manage Exchange 5.5 and Exchange 2000 servers, and to view (but not change) the properties of Exchange Server 2003 machines. However, you only get the functionality that was available when Exchange 2000 shipped. That means that mailbox moves are single-threaded; there's no Mailbox Recovery Center, and the queue viewing and management tools are feature-poor.

• The Exchange Server 2003 RTM version of ESM mostly looks like the Exchange 2000 version; the important differences are all under the hood. The biggest change for most administrators is that the Exchange Task Wizard's mailbox moving code is multi-threaded, so you can move up to four mailboxes concurrently (and you can run multiple instances as well). This makes mailbox moves much, much faster under most circumstances, although you have to perform an Exchange Server 2003 forestprep in your Exchange organization to make this work. In addition, there are improvements in how monitoring and status information is displayed, a new, better-organized tool for viewing message tracking data, the Mailbox Recovery Center (described in more detail in Recipe 11.10), and a vastly improved interface for viewing and controlling message queues. Exchange Server 2003's ESM also includes the Internet Mail Wizard for quickly setting up SMTP mail interchange with Internet hosts. These new features come with a tradeoff: you can't configure Exchange 2000-only features like the Key Management Service (KMS), the Exchange Instant Messaging service, or the old-school MSMail, cc:Mail, and Schedule+ connectors.

• Exchange Server 2003 SP1 adds a few new features to ESM, including the ability to set up RPC-over-HTTP connections with a simple property sheet instead of the morass of registry keys and fiddling required with the Release to Manufacturing (RTM) version. (Although for organizations with a single Exchange server, some feel it is simper to use the manual methods.)

You can use all three versions of ESM in the same Exchange organization, whether or not you actually have the corresponding version of Exchange installed. However, Microsoft doesn't support installing the Exchange 2000 version of ESM on an Exchange Server 2003 server (not that you'd want to anyway). One thing it does support is installing and using ESM from other Windows 2000, Windows Server 2003, and Windows XP computers in the same forest (see Recipe 4.1). Note that you can only run ESM from a computer in the same forest as your Exchange servers. If you want to run it on a laptop, home computer, or other machine that's not a member of a domain in your Exchange forest, you'll probably need to use Terminal Services to remotely log on to a machine in the forest.

Exchange System Manager, in most cases, does not provide a useful way to make the same change to multiple objects at once, and there are some things it can't do (such as change user properties) or doesn't do well. If you need to change the area code for hundreds of users, it is much more efficient not to do this manually through the GUI.

Exchange's Scripting Interfaces

In the Unix world, almost every mail administrator knows how to write scripts. This is a self-defense thing: a mail administrator who can't script will end up spending lots of quality time with picky command-line utilities, doing the same thing over and over and over.

In the Exchange world, most administrators can get along perfectly fine without scripting. However, Microsoft has been steadily improving the scriptability (yes, that's a real word) of both Windows and Exchange, to the point where you can do a surprisingly large number of tasks from script.

That raises the thorny question of which programming model and scripting language to use. A very wise computer science professor once taught one of the authors a useful analogy: programming languages are like the saws in a carpenter's toolbox. Knowing which saw to use, and when, is very important, since picking a suboptimal tool can make the job take much longer than it needs to. For simplicity, we've chosen to use VBScript in this book: it's already supported by the Windows Scripting Host (WSH), and there are lots of examples at Microsoft's site, and elsewhere, that use it. However, if you prefer another language, don't despair; it's easy to convert the examples to other languages. Samples of these scripts in other languages aren't provided, however the Perl development kit (http://www.activestate.com/Products/Perl_Dev_Kit/) includes tools to convert VBScript to Perl (and vice-versa). Now, let's review the interfaces that we can use to write our scripts:

Collaboration Data Objects (CDO) 1.2.1

CDO is a wrapper around MAPI and is still shipped with Outlook 2003. However, CDO isn't often used because its functionality has been superseded by other libraries, so we won't refer to it further.

Collaboration Data Objects 2.0 (CDOSYS)

CDOSYS (cdosys.dll) is designed to let you build applications that create and send messages using the Windows 2000 (or later) SMTP service, or its Exchange equivalent. CDOSYS makes it easy to build properly formatted plain-text or HTML mail messages, so we'll be using it in some of our recipes to allow scripts to generate and send messages quickly without having to implement their own transport mechanism. Every Windows 2000, Windows XP Professional, and Windows Server 2003 computer includes CDOSYS.

Collaboration Data Objects for Exchange (CDOEX)

CDOEX is designed specifically to allow access to items in the Exchange store. For example, CDOEX provides COM classes for Appointment, Message, CalendarMessage, and Folder objects (among others); the properties and interfaces exposed on these objects allow you to manipulate directly most data items kept in mailbox stores. Normally, you'll use CDOEX only when you need to create or manipulate items that live in folders within mailboxes (or the folders themselves). CDOEX ships with Exchange 2000 and Exchange Server 2003; if you want to use CDOEX-based programs or scripts, you'll need to install ESM on the computer you run them from.

Collaboration Data Objects for Exchange Management (CDOEXM)

In Exchange 2000, Microsoft made the wise decision to split management tasks (such as creating new mailbox databases) from tasks involving items in the mail store. So, we got CDOEXM, which is the core set of classes for manipulating Exchange objects like servers, storage groups, and mailbox databases. CDOEXM provides functionality for creating, removing, mounting, dismounting, and setting properties on these objects, so we'll call on it for those tasks. As with CDOEX, the CDOEXM library is only found on Exchange servers and computers where the Exchange System Manager has been installed.

Active Directory Services Interface (ADSI)

ADSI is designed to provide a set of interfaces for connecting to Active Directory domain controllers, reading data stored in the domain or configuration naming contexts, and modifying itall with appropriate access controls. Exchange stores all of its configuration information in Active Directory, and all user account data lives there as well, so being able to access the directory will be critical to scripting most common tasks. ADSI scripting is covered in great detail in O'Reilly's Active Directory, Second Edition, so if you're interested in a deeper understanding of it (as opposed to the strictly functional approach we'll take here) that's a good place to start.

Windows Management Instrumentation (WMI)

WMI is the name given to a broad range of COM classes used to monitor and control various parts of Windows. WMI classes can expose performance data, provide read-only or read/write access to various properties of system objects, and allow those objects to be created or destroyed. Exchange 2000 and Exchange Server 2003 both provide WMI classes for specific Exchange objects, but there are many more of them in Exchange Server 2003, including classes for links, queues, folder trees, logons, and mailboxes.

Active Data Objects (ADO)

ADO is a set of interfaces that expose structured data (normally, from a database like Access or SQL Server) to programs and scripts. In our case, ADO gives us a straightforward way to iterate through collections of users and groups, as well as other Active Directory objects. Normally, ADO code will be used in conjunction with WMI, ADSI, or the CDOEX and CDOEXM libraries.