Communications

Running Exchange with Windows Server 2008

Paul Bowden

At a Glance:

• Setting up Exchange on Windows Server 2008
• Configuration tips and tricks
• Know your Exchange environment

On the Exchange development team at Microsoft, it's my job to set the schedule, rhythm, and priority for the team. Within Microsoft my role is known as Release Manager. This roughly translates to a technical project manager in other companies. As anyone who's worked

in this position knows, it takes knowledge, skill, hard work, and the respect of the team to deliver a good product on time. Working with such a smart and talented team, you don't gain that credibility overnight—it has to be earned.

One way to prove your mettle is to run your mailbox on a "dogfood" server—a production server running a prerelease version of Exchange. This is a fluid environment where we upgrade to new Exchange builds every two to three weeks. Such a setup lets us test the software in a real-world environment with real human interaction. We even run our mailboxes on the latest test builds. I've been there, and here's my story.

Getting Ready for "Longhorn"

At the end of 2006, when we had just shipped Exchange Server 2007, a new OS was on the horizon—Windows Server®, code-named "Longhorn." As we started pulling together plans for our first service pack for the new Exchange platform, it became obvious that the Exchange and Windows® schedules were on similar paths and that "Longhorn" (now called Windows Server 2008) was going to be big. It was at that moment we decided to engineer Exchange Server 2007 SP1 for both Windows Server 2003 and Windows Server 2008. There's a significant amount of coordination and planning required to support an enterprise application on multiple versions of Windows. For example, Exchange works closely with IIS, and Windows Server 2008 includes a new version, IIS 7.0.

I remember installing Windows Server 2008 for the first time in my lab in late December 2007. Two things stick in my mind about that day: first, that the install was so quick; and second, that the management tools, although very different from Windows Server 2003, were just so intuitive to use.

In our main labs, Windows Server 2008 installs in about a third of the time needed for a Windows Server 2003 installation. One of the reasons for this is that optional components, not imperative to the running of the operating system, are not configured out of the box. This is great for reducing the attack surface of the computer and keeping things as simple as possible. No one likes unnecessary clutter. The typical downside of such an installation has been that you have to insert the disk every time you want to add additional components. But with Windows Server 2008, all the files are copied to a SxS folder (pronounced side-by-side). You then use the Server Manager tool to configure the components that you need, and the operating system figures out the file copying for you.

At this point, I should mention something called Server Core. This is a mode of Windows Server 2008 where you install the absolute bare minimum operating system. In this mode, you typically interact with the server console through a command prompt; not even Explorer is installed. This mode is well-suited for infrastructure servers such as domain controllers and DNS servers. However, you can't run every type of application here. Exchange makes extensive use of managed code, and that precludes it from supporting Server Core installations.

Setting Up Exchange

I love taking the physical Windows Server 2008 and Exchange Server 2007 SP1 media and installing a machine from the ground up without any further downloads or prerequisites. The best way of configuring a Windows Server 2008 installation for Exchange is by using the ServerManagerCmd tool. I've crafted an XML answer file, shown in Figure 1, that installs just enough operating system components to allow Exchange to install and run on Windows Server 2008. Once the new operating system is installed, I just run this command to set up the system:

Figure 1 ServerManagerCmd answer file for Exchange

<!-- ServerManagerCmd Answer File compatible with Windows Server 2008        -->
<!-- Usage: ServerManagerCmd -ip Exchange.xml                                -->

<ServerManagerConfiguration
    Action="Install"
    xmlns="https://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1">

    <!-- BASE: Install PowerShell 1.0 feature -->
    <Feature Id="PowerShell"/>

    <!-- PREPARESCHEMA: Install LDIFDE and other directory tools like LDP and ADSIEdit -->
    <Feature Id="RSAT-ADDS"/>

    <!-- CAS/MBX: Install the Web Server role with additional child components -->
    <Role Id="Web-Server"/>
    <RoleService Id="Web-Metabase"/>
    <RoleService Id="Web-Lgcy-Mgmt-Console"/>
    <RoleService Id="Web-Basic-Auth"/>
    <RoleService Id="Web-Windows-Auth"/>

    <!-- CAS: Install the three authentication types for OWA, GZip compression, plus Outlook Anywhere support -->
    <RoleService Id="Web-ISAPI-Ext"/>
    <RoleService Id="Web-Digest-Auth"/>
    <RoleService Id="Web-Dyn-Compression"/>
    <Feature Id="RPC-over-HTTP-proxy"/>

    <!-- EDGE: Install Active Directory Lightweight Directory Services (previously known as ADAM) -->
    <Role Id="ADLDS"/>

    <!-- UM: Install the Windows Media Player components -->
    <Feature Id="Desktop-Experience"/>

</ServerManagerConfiguration>

ServerManagerCmd –ip Exchange.xml

When that's done and you've restarted the system, you have everything that you need to install Exchange roles such as Mailbox, Client Access, Hub Transport, Edge Transport, and Unified Messaging.

Another useful trick is to use ServerManagerCmd with the –query switch. This will enumerate the total list of roles and services, and show you which are actually configured (denoted by the green text in Figure 2).

Figure 2** Enumerating Exchange roles and services **(Click the image for a larger view)

So, back to the story. We spent those early months in 2007 in the lab, figuring out the changes required to get great performance on Windows Server 2008. If there's one thing that I've learned, it is that you can keep installing and stressing software in the lab until you're blue in the face, but the true measure of quality is in real, live deployments with real, live users. And that's exactly why we "dogfood" our products—testing them in real, daily, get-the-work-done use. The release of Windows Server 2008 Beta 3 in April 2007 was the turning point—it was time to go for it and deploy into production.

I sat there looking over the shoulder of an operations team member as we deployed the first set of Exchange servers on Windows Server 2008. The Exchange setup went smoothly, and services all started up. All we had to do now was move a mailbox and find out whether it really worked. I volunteered to check things out. I have a 2GB mailbox, and, 26 minutes later, there I was up and running, sending e-mail with Exchange on Windows Server 2008. Success!

Lessons Learned

Since that first installation on Windows Server 2008, we've been fine-tuning and making sure that we're truly ready for prime time. We did have to make some key deployment decisions along the way.

Installation You can use Exchange Server 2007 SP1 either as an upgrade to the original Exchange Server 2007 installation—what I'd call Exchange 2007 RTM (for release to manufacturing)—or you can take a fresh computer and install directly with the Exchange Server 2007 SP1 media. This is important because you can't install Exchange Server 2007 RTM on a computer that is running Windows Server 2008.

Upgrades Although you can upgrade the operating system in-place from Windows Server 2003 SP2 to Windows Server 2008, there are some components that need to be uninstalled first. One of these is Windows PowerShell™. This is at the very heart of Exchange management; even Exchange setup is based on Windows PowerShell. For this reason, we can't support in-place upgrades of the operating system when Exchange is already installed. For many, this typically means that you'll want to install Windows Server 2008 on a new computer and then install Exchange Server 2007 SP1.

IPv6 Exchange is designed to take advantage of several new features in Windows Server 2008. For example, IPv6 is installed by default, and two Exchange servers running on the new operating system will automatically use IPv6 to communicate between each other. The interfaces in the Exchange Management Console will also accept IPv6 address ranges. There is one caveat: Exchange still requires an IPv4 address to be bound to each network interface.

Read-Only Domain Controllers A somewhat radical change for Active Directory® deployments is the notion of a read-only domain controller (or global catalog server). This allows companies to deploy an Active Directory server that receives one-way replication and doesn't have the ability to back-replicate changes. This can be useful in branch or remote office situations where physical security cannot be guaranteed. Unfortunately, Exchange Server 2007 SP1 can't make use of a read-only domain controller and requires access to a regular writable partition of Active Directory.

Your Exchange Environment

Exchange and Windows Server Resources

• Windows Server 2008 TechCenter
• Exchange Server TechCenter
• TechNet Evaluation Center
• Windows Server 2008 Virtual Labs

When it comes to choosing the operating system level for your deployment, you have the flexibility of running a variety of configurations, as shown in Figure 3.

Figure 3 Exchange environment matrix

Another consideration is mixed-version deployments. You can certainly have a mixture of Exchange and Windows versions interoperating with each other. For example, you can deploy Exchange Server 2007 SP1 on Windows Server 2008 for Client Access servers and have them access Exchange Server 2007 RTM on Windows Server 2003 mailbox servers.

There are some nuances to be aware of with older versions of Exchange and Windows Server 2008 Active Directory. If you have Exchange Server 2003 SP2 and later, you can deploy and use Windows Server 2008 domain controllers in your environment. However, if you still have Exchange 2000 deployed, you'll want to either hold off on deploying Windows Server 2008 domain controllers in the Active Directory site where those Exchange servers reside or hard-code the Directory Service Access (DSAccess) settings so that Exchange 2000 doesn't attempt to use the Windows Server 2008 domain controllers.

Closing Thoughts

We've put a lot of effort into making Exchange 2007 SP1 work well on both Windows Server 2003 and Windows Server 2008 platforms. In Exchange, we strive to provide deployment flexibility and better-together scenarios. I think you'll be pleasantly surprised at the ease and sheer speed in which you can deploy Exchange on Windows Server 2008. You'll also find some subtle under-the-hood performance and scalability enhancements, such as vastly superior Client Access server scalability for Outlook Anywhere clients.

Windows Server 2008 provides the platform for future innovation in the messaging space. You won't be disappointed.

Paul Bowden is a Lead Program Manager on the Exchange Server team. He spends much of his free time reconfirming his PayPal account information upon request.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.