Scripting Exchange

One criticism that UNIX-based mail administrators often level at Exchange Server is that it's too difficult to automate administrative Exchange tasks by using scripts. (For a fascinating look at the cultural divide between Windows and UNIX programmers and why scripting is so important in the UNIX world, see http://www.joelonsoftware.com/articles/biculturalism.html ). This criticism isn't entirely fair because many common Exchange tasks can be scripted--if you know how. This week, let's take a look at the scripting and automation support in Windows Server 2003 and Exchange Server 2003.

First, let's dispense with the issue of languages. Too many admins still think of .bat files as the pinnacle of scripting power. Not anymore! Now we have Windows Script Host. WSH is a script language engine that lets you plug in interpreters for multiple scripting languages. You can use VBScript, JScript, Perl, and Python, among others--I think there's even a REXX port--to write scripts that run on your servers. Besides WSH, several third-party products (e.g., ActiveState Perl, KiXstart) let you write Exchange scripts.

Second, and more important, what do you do with the scripts you write? Microsoft has built a couple of powerful scripting interfaces that you can use to automate a lot of interesting tasks. Active Directory Service Interfaces (ADSI) gives you a scriptable gateway to Active Directory's (AD's) most interesting functionality. For example, ADSI lets you bind to domain controllers (DCs), create and remove user and group accounts, query for various domain- or forest-level settings, and find servers.

Exchange itself offers the Collaboration Data Objects for Exchange Management (CDOEXM) library, which offers a surprising degree of power. For example, you can use CDOEXM calls to create, mount, and dismount mailbox stores; move mailboxes; create and remove distribution groups; and do all sorts of other cool things. Microsoft Developer Network (MSDN) has tons of CDOEXM samples to help you get started; just run a query on "CDOEXM."

If you're writing applications that use the Windows .NET Framework, you might wonder whether you need to write wrappers to let you use CDOEXM from managed code. The answer, thankfully, is no. The upcoming Exchange Server Objects (XSO) framework will provide managed .NET code that gives you access to some crucial Exchange functionality. Expect more details about XSO in the future.

Of course, scriptability isn't a panacea. Unless you're a programmer, scripting won't help you much with most of your common tasks, and even if you are a programmer, some tasks are still awkward or impossible to script in Windows. Therefore, Microsoft is reengineering its scripting infrastructure through a project code-named Monad. The goal is nothing less than a revolution in how we automate and script Windows administrative tasks. The details are outside the scope of this column, but if you're interested, a Google search on "monad Windows" will turn up some mighty interesting links.

Finally, a quick update on the Blair's Death Rain potato chips I mentioned last week. Several folks wrote to ask where they could get them and whether they were any good. Mine haven't arrived yet, so I don't know exactly how hot they are, but if you want to try some for yourself, you can order them from http://www.ironq.com . Be sure to have a glass of water on hand--just in case.