Exchange & Outlook Pro VIP reader Christopher Wallick has been graciously keeping me posted on the progress of his company’s upgrade to Exchange Server 2007. If you’re planning to migrate to Exchange 2007 soon or are in the process of migrating now, you’ll probably find Christopher’s insights valuable. I’ll post Christopher’s updates as I get them.
February 2007
I am the design engineer behind our organization’s Exchange and messaging infrastructure. We chose to upgrade this year due to the fact that our servers have reached their end of life and it makes more sense fiscally to invest in hardware that will support Exchange 2007. Initially, we were going to upgrade the hardware but keep Exchange Server 2003, but the more we looked at the design differences from a four-node Exchange cluster to the two node cluster continuous replication (CCR) clusterlets in Exchange 2007, we knew that we would have to completely redesign our infrastructure if we decided to upgrade later. So, for us it made financial sense to do the redesign one time and go with the upgrade now. We are taking a slow approach to the upgrade, however, and working with Microsoft to ensure that as we move forward we do so carefully and methodically.
We’ve been planning this since last year. We have already done a proof of concept, which is to say that we brought up a pristine Active Directory (AD) test environment and then installed the Beta 2. From there, we had to wait for the RTM for volume license customers, then downloaded the 64-bit version from Microsoft. We’re moving through step by step, documenting the process and vetting it through our change-control board. As the pilot will reside within our production AD structure and interface with Exchange 2003, we’re trying to be as methodical as possible. It’s a miracle that our senior management bought off on the whole project as it is, so we don't want to cause any harm along the way.
We will be bringing up the Exchange 2007 pilot next week. From there, we will slowly move a small group of users onto the new CCR cluster. Our primary goal is to provide for an improved user experience and to facilitate better administration and management of the data that flows within our messaging infrastructure. Ultimately we will begin replacing server role components (i.e., current front-end servers to Client Access servers, bridgehead servers to Hub Transport servers, etc.), then retire the Exchange 2003 counterpart as per Microsoft documentation on coexistence. Our Gantt chart has the project ending by February 2008. As an insurance company, we’re bound by both HIPAA and SOX compliance issues, and we intend to use the new features of Exchange to improve our ability to manage our corporate compliance.
March 2007
We have moved passed our proof-of concept-phase and have brought up the server infrastructure needed for our pilot to begin. Our goal is that once the pilot is complete, we will use the same infrastructure for our production needs. The first node built was the Client Access server, which also holds the Hub Transport role. We’re very heavily leveraged in VMware, and with the upgrade of our VMware infrastructure to the latest version, we’re able to host 64-bit OSs and applications that wouldn’t normally perform well in a virtual environment. The CAS/HTS server was a prime candidate, and we found that Exchange 2007 performs very well on this platform.
The next step was to build out our first CCR clusterlet. For this we used two HP DL585 G2s. Each server has dual-core quad processors, 8GB of RAM, and 1TB of attached DMX SAN storage. Microsoft has very good sizing documentation, and this server configuration is one step above where Microsoft recommends for given our configuration requirements.
I found that setting up the majority node set cluster with file share witness was not an easy thing. There is a great deal that is counterintuitive to the process. I was working with Microsoft Premier Support, and they were very helpful. It was rather like we were working together, as this technology is very new to everyone and MSPS segregates its support staff into application-specific groups. When I originally called them, the support case was sent to the Exchange group. When the support engineer found that I hadn't even installed Exchange on the server yet, he transferred me over to the clustering group.
The MSCS group was great as well, but the CCR cluster is built a bit differently than a true “majority node set with file share witness” cluster. When building a CCR cluster, there is dedicated storage on both nodes rather than the traditional shared storage, which is “owned” by the active node. This caused a bit of consternation on their part, but we were able to work through it. A lesson I learned was that the default configuration of a resource group is for both nodes to be possible owners. This should be changed to only the A node. If the resource group is failed over with the default configuration, the group will fail and go offline. How can the B node take ownership of a disk array that it isn’t connected to? It can’t. Additionally, if you reboot the A node, the resource groups will all fail at startup. The thing to understand is that once you install Exchange, it will handle the failover from one node to the other. Exchange handles replication, failover, and recovery. We haven’t tested that yet, but that is our next step. We now have a fully functional Exchange 2007 organization and have moved over test accounts and sent mail to and from that account.
We’ve been working very closely with Microsoft on this project, and they will be coming out for an onsite visit in May to assess and validate our infrastructure build-out. From there, our next step is to begin the pilot by moving over a very small number of users who will participate in the test scenarios and provide feedback by way of a template form on the project portal.
I’ll write again soon to detail our process for the creation of test cases and how we will be setting up our pilot.
—Christopher Wallick
End of Article
Register
