By now everyone is aware of the benefits of virtualization – from optimized resource utilization, higher availability of services and overall cost savings. Virtualization is a win/win proposition.
Instead of extolling the obvious benefits of virtualization, I’m going to share some insights I learned during my Exchange Server deployments – hopefully ensuring your Exchange 2007 virtualization project goes smoothly.
Exchange Server 2007 in a Hyper-V VM? Yep, it can be done.
One area where people are hesitant about shifting into the virtual world is that of database type applications - Exchange Server is an example. These applications typically perform quite a bit of disk input/output (I/O) operations. This was a problem for virtualization as previous hypervisor incarnations introduced quite a bit of disk I/O performance degradation. One exception to this is VMware’s ESX server. An outstanding virtualization product, VMware’s hypervisor implementation reduced the I/O impact to very acceptable levels. Unfortunately, the cost put it out of the reach of most small-to-medium sized businesses. With limited budget, most companies deploy Exchange natively onto hardware because other hypervisor implementations just don’t cut it (including Microsoft’s Virtual Server product). This all changed with Hyper-V. With the cost effective Hyper-V product, you can now run Exchange Server in a VM with all the benefits of virtualization and a minimal performance hit.
The Input / Output Issue
Since the area of importance with exchange is disk I/O, let’s focus on that. For Redundant Array of Inexpensive Disks (RAID), it would be great to have two separate channels of RAID 10 – one for the transaction logs and one for the database. Of course, budget is going to dictate the physical setup of your arrays, just try to follow best practices. As far as the virtual hard disk that is going to hold your exchange deployment, there are two ways you can go – Pass Through Disks and Fixed Virtual Disks. Again, budget will more than likely dictate which route you go. Pass Through Disks are essentially physical disks/LUNs that are attached to a virtual machine. These provide outstanding disk I/O operations, on par with physical disk performance. They are the “recommended best practices configuration for running exchange in a VM.” Or, if you have a san, definitely use a LUN.
But as I stated before, if you are a small-to-medium sized business, you probably don’t have a san. And more than likely you don’t have enough drives in the Hyper-V server to dedicate to Pass Through Disks. In this case, go with the second option – fixed virtual disks. In my environment I created one for the OS, application and logs and one for the databases. Each VHD was located on a separate array on a separate channel – allowing the server to work with these files simultaneously. There is a slight performance hit using fixed VHDs (some tests show between a 5 to 10% hit versus running on native hardware), but in our case of around 25 users, it’s not noticeable at all. Oh, and under no circumstance should you ever use dynamically expanding VHDs (keep these types of disk relegated to testing environments)!
Ok, now that the physical/virtual disk environment is set, you can move ahead with the actual deployment. Since the installation of exchange 2007 is pretty straightforward, I am not going to cover it here and will assume that you’ll follow best practices.
Common Issue #1
At this point you should have a fully working environment. Now here is one of those gotcha’s that I have resolved for a few clients. One feature that all clients want by default is the feature-rich version of Outlook Web Access (OWA) that comes with Exchange 2007. This updated version of OWA looks and functions almost identically as the full blown Outlook client. It is so complete that quite a few clients are now opting to no longer deploy Outlook and just use OWA from Internet Explorer. Typically you would use a certificate to secure all of your traffic between the exchange server and your OWA session. I normally use a certificate issued by a Public Certificate Authority (CA) so users don’t have to manually add it to their trusted store. By the way, this certificate is also used to secure exchange direct push communications to mobile devices. What is new in Exchange 2007 is that certificates are now used for a lot of core functionality. Out of the box, Exchange 2007 uses a self-signed certificate for these core services. The problem arises when you use a different Fully Qualified Domain Name (FQDN) in the public certificate versus the name that is used in the self signed certificate. More often than not, these will be different names as most administrators use a different domain internally versus their external presence (e.g., yourbusiness.com versus yourbusiness.local) When you add the certificate from the Public CA (as mentioned above), problems start to show. One of the more prominent errors has to do with using Outlook 2007. You immediately see an invalid certificate error when trying to connect with the full blown client. Here’s a step-by-step process concerning how to fix this certificate mismatch error.
- Create a new DNS zone on your DNS server that matches the domain specified in your certificate say: securemail.yourbusiness.com
- Then you create a Host (A) record to point to your mail server´s IP : securemail.yourbusiness.com 10.10.10.25
- Then you just change the following values thru the Exchange shell console:
a. Set-ClientAccessServer -Identity CAS_Server_Name -AutodiscoverServiceInternalUri https://securemail.yourbusiness.com/autodiscover/autodiscover.xml
b. Set-WebServicesVirtualDirectory -Identity "CAS_Server_Name\EWS (Default Web Site)" -InternalUrl securemail.yourbusiness.com /ews/exchange.asmx
c. Set-OABVirtualDirectory -Identity "CAS_Server_name\oab (Default Web Site)" -InternalUrl https:// securemail.yourbusiness.com /oab
d. Set-UMVirtualDirectory -Identity "CAS_Server_Name\unifiedmessaging (Default Web Site)" -InternalUrl https:// securemail.yourbusiness.com /unifiedmessaging/service.asmx
*please note that you must change: "CAS_Server_Name" to your exchange server name and securemail.yourbusiness.com with the correct address.
There – done.
Common Issue #2
Another issue I found due to the certificate mismatch deals with viewing user’s Free/Busy information in Outlook 2007. Again, this only occurs if you are using Outlook 2007 (which uses certificates for communication). To fix the error, perform the steps outlined in a Microsoft knowledge base article KB940881.
That’s it in a nutshell
I have found once I performed these two reconfigurations, everything worked flawlessly. OWA looks and works great, Direct Push is extremely quick (even with iPhones) and the overall system is rock solid. At this point you are now running Exchange 2007 in a VM – affording you all the benefits of Microsoft’s latest messaging platform combined with all the benefits of virtualization.
Author Kevin McGarry serves as the senior systems analyst at Eureka Software Solutions. Please contact Kevin if you have any questions about this newsletter or questions about IT service offerings. Call Kevin at 512-459-9292 ext. 291 or email him at kevinm@eurekasoft.com.