Nicolas Blank  recounts his Experiences deploying Exchange 2007 SP1 on Windows Server 2008, when not everything worked out of the box as it should have. In this article Nicolas writes about the fixes to the issues he faced when installing on Server 2008.

My customer’s scenario wasn’t quite typical – he had an unstable mail server running Exchange 2003, as well as Active Directory issues, one of which included the requirement to rename the directory tree. The customer wanted a brand new environment and in order to realize the scalability and security benefits of Microsoft’s 64 bit OS decided on Windows Server 2008. This meant I was called in to perform a “Green Fields” migration, where a new target environment is built and all users, machines and mail are migrated to it. To complicate matters, the customer was on a tight hardware budget, meaning he could only afford a single large machine for a 200 user site.

Designing a solution

The design was relatively straightforward - since I only had a single machine available, I had to place the HUB, CAS and mailbox role onto that machine. Having all of the roles on one machine is well catered for in the available design guidance from the Exchange team at Microsoft. The machine had 16 GB of memory and a quad core processor. I also had enough disks to create a decent set of mirrors for the OS, page file, logs and a RAID 5 array for the Exchange Database.  SPAM handling was done at the ISP, which meant one less burden for the HUB role to handle, since the budget did not allow for additional hardware for an edge server. AV would be handled by the ISP, though this did not preclude internal attack, and I chose Forefront to handle AV on the Exchange server to scan both existing mail in the stores and transmitted mail via the HUB role.

Building a new mail server

Server 2008 is much “lighter” on a default install than Server 2003, with fewer components deployed by default. However this default install requires me to add the Roles and Features required to build a multi role Exchange Server. Instead of adding each feature through the GUI by hand, I built a batch file containing the required commands. The only reboot required would be after the installation of Active Directory Domain Services remote management tools.  From the command line I ran “ServerManagerCmd -i RSAT-ADDS” to install this service, and rebooted. After which I ran the following commands in listed order in a batch file.

Using the command line was dramatically faster than using the GUI would have been and allowed me to script all of the required prerequisites, thereby eliminating any potential mistakes installing the prerequisites. After this I invoked the Exchange installer and since all of the prerequisites were met, Exchange had no issues installing.

The problem, IPv6

The last thing I added before installing Exchange was the prerequisite for the CAS role to host Outlook Anywhere and mobile clients, namely RPC over HTTP, using this command

 I noticed that RPC over HTTP didn’t always work.  The solution lay in the limited support for the CAS role and IPv6. Running

From the command line gave the following results

If you’re familiar with IPv4, you’ll know that in the first picture the IP stack is listening on  open ports 6001, 6002 and 6004, but these ports were missing on the IPv6 stack on the same address “[::]:” . This meant that one of the core requirements for RPC over HTTP, communication with the local server, had been compromised.  At first glance, the fix seems simple, surely you just disable IPv6? Correct, but that wasn’t as easy as you might think.

First I had to unbind IPv6 from the Network Adapter, but just like Vista, Server 2008 requires a registry hack in order to disable the protocol altogether.

Using Regedit I navigated to:

                HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters

Added a DWORD32 called DisabledComponents and give it the following value: 0xff, effectively diabling all IPv6 components. See this article from the MS Exchange team for background. When installing Exchange 2007 on Server 2008, using Outlook Anywhere requires using this value, but refer to the table below for other possible values.

One final step was required, namely editing the hosts file to remove the IPv6 “localhost” equivalent. This meant commenting out the ::1 line by placing a # in front of it as well as manually adding the Netbios and FQDN names

10.41.1.243         mpmx01.ds.customerAD.com

10.41.1.243         mpmx01

127.0.0.1              localhost

# ::1                        localhost

Note that the last line comments out the IPV6 address

Note: This issue is current as of Exchange 2007 SP1 Rollup 3, though it should be resolved with Rollup 4 (if it comes out for real!). None of my Exchange customers run IPv6 ,and even with this issue resolved, I would still disable IPv6 or any other protocol not actively used in the environment. After a reboot running netstat –a –n again revealed that IPv6 was indeed gone for good.

Finishing the Org

With that out of the way, configuring Exchange was straightforward. I added the same SMTP namespace as the original org, configured a SAN certificate for the CAS role, allowing OWA and Outlook Anywhere to communicate securely and allowed anonymous mail submission to the Receive connector, thereby enabling internet mail. Final testing showed that I could communicate with Exchange both internally and externally. The migration proceeded smoothly after that, using  Quest Migration Manager (QMM)  to move both the AD user accounts, and the Exchange Mailboxes. The advantage in using this toolset over native tools, was that there was virtually no user impact, and it required no desktops visits. Depending on the timeframe required, the complexity of the migration and the amount of mail that needs to be moved, I generally prefer using third party utilities to native utilities. I have had particular success with QMM, since it supports single or many object rollback. This allowed me to build Disaster Recovery plans that fitted the overall business requirement into the migration plan. Native tools can often be “fire and forget” and you have to hope that the end result is the one you hoped for.

it was worth noting that the original Exchange server suffered massive hardware failure the day after the migration completed and was signed off. The server drive subsystem failed catastrophically, requiring a complete replacement of all drives in the array. One of the original migration drivers was to move off the old hardware platform. Had the business decided to wait to migrate any longer we might have experienced the hardware failure while migrating.

Conclusion

If you get the chance to upgrade, Windows Server 2008 offers a number of enhancements in the OS which benefit Exchange 2007 deployment and management greatly.  Security and resilience are enhanced and Windows ships with a better IP stack allowing more RPC connections, amongst other features. This “Green Fields” migration path is particularly straightforward, but even the more complex methods are well worth following if you have the budget. A few things remain incompatible, for example, Server 2008 contains no native backup utility for Exchange 2007, and Exchange 2007 does not support the new Read Only Domain Controller feature in Server 2008. The first of these at least is likely to change in the near future. IPv6 is irritating , but it is quickly disabled since it offers no value over IPv4 at this point. Server 2003 is still available at the time of writing, but I wouldn’t hesitate to deploy Server 2008, and gain advantages such as Hyper-V support or “free” geo-clustering with CCR and SCR clusters replicating over the WAN. It is worth remembering that Exchange is a large application, making every deployment worth planning for, irrespective of which operating system it is deployed against.