This is another question that came up many times during TechEd.

It was usually phrased, "Why would I go with Windows Server 2008 over Windows Server 2003 when deploying my Exchange Server 2007 environment next month?" Sometimes they also threw in that they were going to to CCR.

My point, which actually seemed to please some of the people is that we, as administrators, should try to avoid NT 4.0 situations that we are still paying for today.

What does that mean? Well, think about it, in 2000, we were deploying new servers. The options were to deploy NT 4.0 or Windows 2000. Windows 2000 was still new and there was fear about using it for critical environments. So, NT 4.0 was used. In 2003, the hardware reached the end of its warranty. So, we paid for an extended warranty for a year, or more, until it got too costly. So, last year, we had an OS that was 11 years old running critical systems.

Take it forward today. I deploy a new and extremely critical email environment that is supposed to last me between 4 to 5 years. So, if I use Windows Server 2003, I will find myself running Windows Server 2003 in 2013. Sound familiar?

I am willing to bet you money that not a single person will be wanting to upgrade the OS to Windows Server 2008 when the application and the OS are still working properly. We, as IT people, do not mess with what is working. So, we don't upgrade and we end up in a bad position where we are way past the end of life on the operating system on a critical server environment. This is especially true if we are deploying a high availability environment to support the application. You don't mess with it.

I am a big proponent of aligning application and hardware refreshes because it just makes sense. What we end up with is a cycle of every 3-5 years, we replace our out of warranty equipment with new equipment running the latest OS and the latest application version just so that when we hit the end of our planned life cycle, we are not in an unsupported state and trying to remember how to manage an OS and an application that we haven't touched in years because we are constantly moving forward.

Something else to consider. Let's say it is the year 2010, and you call Microsoft for support for your Windows Server 2003 environment. Who do you think you will get to help you? Well, the very best people have already moved on to the other teams. They are working on the 2008 platform, or they are working on Win 7 (whatever its real name will be then). The best support guys will not be stuck working on the 2003 team. 

I hope that is enough reason for you to do your best to convince management that it is better to go with Windows Server 2008.

During my booth duty at the Failover Clustering booth, I must have heard questions regarding this topic about once per hour if not more.

The official stance: Microsoft does not support the virtualization of Exchange Server 2007 roles at this time. Why not? Well, Microsoft does not have a virtualization platform capable of supporting 64-bit virtual machines at this time. Hyper-V is not an RTM product. Whether Microsoft will change the stance once Hyper-V RTMs is another question, and I don't have an answer. Also, keep in mind, Microsoft is not about to support a third party's virtualization platform because they don't have the control over it to properly support it and fix problems that might be discovered.

My point of view: Why would you ever want to do that anyways? Exchange and SQL are two services that really do require top-notch resources and sharing them on a server with other virtualized servers just seems counter productive to providing the best performance possible for two key business services.

OK, now that I am off my soap box, can you virtualize Exchange Server 2007? Yes, you can. It make perfect sense to me for development and testing environments. It makes perfect sense for a proof of concept, too. It even make perfect sense in small organizations that won't push their Exchange implementation very hard.

Recently, I worked with a client that has a nice virtualization platform running Hyper-V RC1. They hosted mailbox servers, hub transport servers, and client access servers for their test environment. It ran wonderfully. They are considering doing it when Hyper-V RTMs because their expected load for 35 users isn't very large. 

UPDATED: Scott Schnoll posted the official stance in his blog post, Exchange Server 2007 and Hyper-V.

This is becoming a pretty common question in my Exchange classes. Which should I use? Why one over the other?

My current recommendation is to use CCR whenever possible vs. SCC. Why? I am glad you asked that question.

High Availability, see my definition here, is all about risk mitigation. What we should be doing is identifying risks to our important/critical applications and finding ways to eliminate or at least mitigate the risks where economically feasible.

One of the major risks that I see with Exchange Server 2007, as well as previous versions of Exchange, is losing my production database because of a disk failure or my database becoming corrupted. In the case of a disk failure, I would normally restore my database, but that takes time, and very few people want to run a dial tone database while they recover. So, two Exchange Server 2007 technologies provide some protection against a lost database drive or a corrupted database. One is Local Continuous Replication (LCR). LCR, however, is a single server technology and does not provide the risk mitigation against an entire server loss that a cluster can provide. The second technology is to use Cluster Continuous Replication (CCR). CCR provides the one extra piece that a Single Copy Cluster (SCC) does not: it provides for loss of the database disk or corruption of the database.

Since CCR does not do a block by block copy like a SAN replication utility might, the likelihood of corruption passing from the production database to the passive copy is extremely low. Remember, the passive copy is receiving transactions and having them applied to the database much like the production database. Corruption is not copied in such an environment.

Of course, we can't forget that by using CCR, we also can eliminate the need for a SAN, which is a huge cost savings.

So, add the increased risk mitigation and elimination of the SAN requirement for high availability and you can see that CCR is a vast improvement over SCC.

I want to end the work day on a positive note. Yes, there are a couple of things about Exchange Server 2007 that tick me off, but overall, I love the product.

I just wanted to take a couple of minutes to mention some of my favorite features.

• Databases - The change to a single database is a big plus in my mind. Also, I love that we can now have up to 50 Storage Groups and up to 50 Databases when using Enterprise Edition. With the larger number of databases, we can now have smaller and faster databases. We can also have an extremely large number of spindles to provide even more disk I/O. Of course, being able to have a single transaction log disk per database also is a nice change which will lead to better performance as well as easier database recovery.
• OWA - Wow, lots of great changes here (except for the issue of Public Folder support which will be added back with SP1). I love that it is so much easier to select recipients without having to do a search. The vast number of new options is also a big plus.
• Mobile - Being able to allow users to wipe their own lost/stolen mobile devices is nice as well as being able to allow users to setup their own devices. The updated Exchange Active Sync is fantastic.
• OOF - Out of office messages are now much more granular. It is possible to configure them in a number of ways so that we can control the OOFs differently based on whether it is an internal sender vs. an external sender and even to the point of controlling OOFs to partners where we have SMTP connections setup directly with them.
• Transport Rules - I can't say enough about all of the fantastic things we can now do using transport rules. I could go on for hours about the many new options we have as administrators including simple things like being able to add disclaimers to all outbound email.
• UM - Unified messaging with the Outlook Voice Access capabilites are fantastic. I am having a blast playing with this new functionality.

If you have looked into Exchange Server 2007, I highly recommend downloading an evaluation version, taking a class, and seeing just how it can improve messaging in your company. The changes I have listed above are just the tip of the ice berg. There are many more new features that I am sure your company can use today.

I have been thinking about this a great deal lately. I, as I said in my previous blog post, I am pretty concerned at the way a CCR implementation is supposed to be moved using the Exchange Management Shell (EMS).

Scott Schnoll, somebody I respect greatly, posted on the Exchange Team blog that it is recommended to always use EMS to move the clustered mailbox server from one node to another. He says that you can use the Cluster Administrator tool, but that using Cluster Administrator is not recommended because: 

Scott Schnoll posted on the Microsoft Exchange Team Blog the other day regarding the proper tools to use when managing an Exchange Server 2007 Cluster.

Yes, there is some confusion. If you research the topic on Microsoft's website, documentation clearly says to use the Move-ClusteredMailboxServer cmdlet. Most of us in the industry just took that and ran with it. But, there is a problem here. Every other single application that runs on Windows Server 2003 server clustering can be fully managed using the Cluster Administrator tool or the cluster.exe command line. Exchange Server 2007 is a bit different when dealing with Clustered Continuous Replication (CCR).

Using the Cluster Administrator MMC, it is easy to properly delegate permissions so that operators and other non-administrators can perform basic tasks when managing clustered applications. The Exchange Server 2007 Management Shell (EMS), does not provide that ease of delegation. I can honestly say that I sure don't want to be giving Exchange Administrator permissions to non-Exchange administrators. That is opening up a can of worms and it would be impossible to get them all back in again.

Please take a few minutes and read Scott's blog. It is extremely helpful, but at the same time, it really underlines a serious management problem. He states, "One of the reasons we recommend using Exchange tools to manage clustered mailbox servers is that, while Exchange is cluster-aware, the cluster tools are not Exchange-aware." I see a potential problem here for many organizations. There really isn't a good way to delegate permissions to an operations type of team to allow them to do Exchange Server 2007 clustered mailbox moves without giving them too many other permissions in the Exchange environment. 

 Right now, I have to say that I am a bit peeved. OK, maybe that is too strong, but I am extremely concerned about how this should be best handled.

In order to keep the number of servers down in a high availability environment, administrators have been looking at using Network Load Balancing (NLB) for CAS and then co-locating the HT role on each node of the NLB cluster to also provide high availability for the HT role.

This configuration can work, and it really is not too difficult to configure. It is extremely important to note that using NLB to load balance the default SMTP receive connectors (using port 25) is not supported and is completely unnecessary since they are load balanced for all intra-Exchange communications like HT to HT communications. However, using NLB to provide redundancy and load balancing for connections to  HTs that are hosting Client SMTP receive connectors (using port 587) is fully supported and may be desireable if you have a large number of external SMTP/POP and SMTP/IMAP clients that need to connect to this receive connector.

The steps that you need are to:

1. Setup two servers running Windows Server 2003 with two NICs in each server
2. Install Exchange Server2007 Hub Transport and Client Access Service (CAS) on each server
3. Configure one NIC for the Network Load Balance cluster and setup the other NIC in a separate network so it can be managed through that IP address
4. Configure NLB with Unicast and even load balancing
5. Setup the port rules:
   • Port 25 to 25 for both TCP and UDP and select the radio button to disable this port range (this will exclude port 25 from being listed to using the virtual IP address of the NLB cluster, but still allow the individual server IPs to still listen to port 25)
   • Port 465 to 465 for both TCP and UDP and selected the radio button to disable this port range
   • Port 80 to 80 for both TCP and UDP and set affinity to none (I recommend "none" so you can easily test and verify that it works)
   • Port 587 to 587 for both TCP and UDP, affinity none (this is for the client SMTP receive connector)
   • Port 443 to 443 for both TCP and UDP, affinity none
   • Port 110 to 110 for both TCP and UDP, affinity none
   • Port 993 to 993 for both TCP and UDP, affinity none
   • Port 143 to 143 for both TCP and UDP, affinity none
   • Port 995 to 995 for both TCP and UDP, affinity none
6. With affinity set to none, you can more readily test the CAS (after updating the web pages to show which server is actually responding) and verify that the load is being shared. You can also test to make sure the NLB cluster does not respond to SMTP on port 25, which it shouldn't if you set it right, and verify that each server does respond to SMTP as an individual server name.
7. You can configure protocol logging for the other protocols and telnet to the ports using the NLB IP address to see if they are loading balancing like they should. You can also use the NLB IP for the testing by sending and receiving messages and checking the message tracking logs to see that the traffic was being balanced. It all worked.

NOTE: You may want to change affinity to either single (especially if it is being used internally) or Class C (especially if it is accessible from the Internet) once your testing is done.

Good luck, and have lots of fun!

Time for some fun. The following are my links and favorite sources of information for Exchange Server 2003 mobility.

First, one of my favorite sites is Eileen Brown's Blog. The following are some fantastic articles on Mobility that she has on her blog.

• Eileen Brown's Blog on Active sync web administration tool
• Eileen Brown's Blog on Exchange mobility resources
• Eileen Brown's Blog on Security on Your Mobile Device
• Eileen Brown's Blog on Setting up Windows mobile 5.0 devices with policies
• Eileen Brown's Blog on Windows Mobile 5.0 and Persistent Storage
• Eileen Brown's Blog on Windows Mobile Device center

Maintaining ActiveSync access to Exchange 2003 mailboxes after deployment of Exchange Server 2007 CAS role

Great Windows Mobile 5.0 Utilities

Yes, of course you can use Microsoft clustering to provide a highly available platform for Exchange Server 2007. In fact, there are two ways to do it.

• First there is the technology known as Single Copy Clusters(SCC). This is basically the same kind of server clustering we bet with Exchange Server 2003 Enterprise. You need to have a storage solution that will allow all nodes to access the disks and it will host the Quorum and the Physical Disk resources needed to cluster the databases and transaction logs.
• Second, there is the technology known as Clustered Continuous Replication (CCR) which has some really wonderful capabilities not found in basic Server Clustering.

The real fun comes in with CCR. Now, there is no need for high cost storage devices. You can use nice and fast direct attached storage (DAS) to meet the storage requirements. OK, somebody just said, "Whoa, what about the quorum, and how does this work when everyone says you need shared storage media for server clustering." Let's address this right now.

Quorum - For server clustering, we had the choice of using a quorum hosted in the shared storage media (i.e. Fibre SAN or iSCSI SAN) or using Majority Node Set (MNS) for the quorum. MNS keeps a local copy on each node of the cluster and so long as there is a majority, the cluster will run. So, with a two node cluster, having two nodes running MNS does not allow for a failure. One out of two is not a majority. So, to make MNS work, we need at least three nodes. Wait... If you remember, we talked about the new File Share Witness (FSW) before. If we use the FSW along with MNS, we can get a third (non-cluster node) server involved to help us out. What we do with FSW is we install the hotfix on both cluster nodes and create a share on another server to host a third copy of the quorum information. Microsoft recommends that we use a Hub Transport server for the file share in this case. OK, so our quorum is taken care of by using two nodes and a File Share Witness.

Data Storage - Normally the stores and the transaction logs are maintained in a SAN to allow access to all nodes of a cluster for Exchange Server. With CCR, we can host the databases locally to each node. CCR uses a form of log shipping to copy transactions from the active node to the passive node. In the event of failover, the passive node will run Exchange. Yep, I hear you. "Wow, that sounds great, but won't there be lost transactions if the active node did not completely replicate to the last second?" Yep, you would be right if you asked that one. This mis-matched state is known as a lossy failover. To resolve this issue, Exchange Server 2007 uses the Transport Dumpster. Basically, what happens is that the newly active node (formerly passive node) that has less information than the previous active node (now dead or now passive) because the logs were not fully shipped over to it. The replication service can request that transactions be replayed by the other servers (in particular the Hub Transport server) to the newly active server to get it up to date. Yes, it is still possible that some data will be lost (such as marking messages read/unread, moving messages between folders, and accepting/rejecting meeting requests), but it is minimal and should not involve any lost mail.

With CCR, the costs of clustering Exchange mailbox servers is greatly reduced because of the improvements in technology allowing us to get rid of extremely expensive SANs and use of less expensive DAS.

Clustering of Exchange just got a great deal more fun!

It appears that the rumors of the demise of Public Folders has been greatly exaggerated. Per the Exchange Team Blog, Exchange 12 (Exchange 2007) will continue to support public folders and will actually improve manageability.

Personally, I recommend using SharePoint Services (Windows SharePoint Services - WSS) and SharePoint Portal Server (SPS) for collaborate application development for all future in-house initiatives and strongly suggest moving any public folder applications that you might have to WSS or SPS in the near future.

The writing is on the wall that WSS and SPS are the way to do this in the future.

This topic kind of caught me off guard a couple of weeks ago. I remember hearing very clearly (OK, I read it from several very reputably sources) that Exchange 12 would only be offered in 64 bit. I also remember hearing that Vista would be available in both 32 bit and 64 bit. The one that was fuzzy to me is regarding Longhorn server. I have heard that it would only be offered in 64 bit, but that was semi-wrong.

OK, so, to set it straight as of today:

1. Longhorn Server will be offered in 32 bit and 64 bit when it first releases. The R2 version will be 64 bit only.
2. Exchange 12 will be offered in 32 bit for demonstration, evaluation, and educational purposes. It will be fully featured.
3. Exchange 12 will be offered in 64 bit for production environments and will be the only version fully supported for production.

OK, that is very odd to me. Why would Microsoft bring out 32 bit versions of Longhorn and Exchange 12 when it would mean an extra investment in maintenance of code bases and extra development efforts? The issue seems to be based on virtual machines.

Virtual Server 2005 and Virtual Server 2005 R2 can be run on 64 bit hardware, but they can only emulate 32 bit guest environments. So, after pushing organizations to use virtualization for testing, and after a significant investment in virtualization for training purposes, we have a problem. Well, Microsoft has a problem.

Until Virtual Server is able to run 64 bit guests, there appears to be a big road block.

Stay tuned for the next change. :)