I've been busy with a small Exchange 2007 to Exchange 2010 engagement the last few days and we decided to go with Windows Server 2012 for the base operating system. Luckily for us Exchange 2010 SP3 has been released and I was very excited to deploy on a new Windows Server 2012 OS.
I thought it would be a good idea to share my experiences as I picked up some issues during the deployment specifically the configuration of the Database Availability Groups.
I’m not going to cover the actual migration, just the Windows Server 2012 part and the issues I picked up during the Database Availability Group configuration. There are many great TechNet articles that cover the coexistence:
http://technet.microsoft.com/en-us/library/dd638158(v=exchg.141).aspx
First things first – let’s read the release notes on Exchange 2010 SP3:
http://technet.microsoft.com/en-us/library/jj965774(v=exchg.141).aspx
Two important points:
- Schema updates are required.
- A database availability group (DAG) member that’s running an older version of Exchange 2010 can move its active databases to a DAG member running a newer version of Exchange 2010, but can’t do the reverse. After a DAG member has been upgraded to a newer Exchange 2010 service pack, its active database copies can't be moved to another DAG member that’s running Exchange 2010 RTM or to a service pack that's older than the service pack installed on the DAG member.
There are also some minor changes in the prerequisites for Windows Server 2012.
Dot Net Framework 3.5 and Windows Powershell 2.0 needs the Windows Server 2012 image mounted as the side by side store (sxs) source files are not available locally after install – you only need to use the source files if you don’t have internet access to Windows Updates from your box – which was the case for me. You don’t have to uninstall Dot Net Framework 4.5 or Windows PowerShell 3.0.
To install Dot Net Framework 3.5 and Windows Powershell 2.0 via PowerShell using SXS source files:
Import-Module ServerManager
Install-WindowsFeature NET-Framework-Core,PowerShell-V2 –Source E:\Sources\sxs
Where E:\ is the drive where you mounted the Windows Server 2012 image file.
The rest of the MultiRole prerequisites (I install telnet client additionally for troubleshooting purposes):
Install-WindowsFeature Telnet-Client,RSAT-ADDS, RSAT-Clustering,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Request-Monitor,Web-Static-Content,Web-Mgmt-Console,Web-Lgcy-Mgmt-Console,Web-WMI,WAS-Process-Model,Web-Asp-Net,Web-Client-Auth,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing Web-Digest-Auth,Web-Dir-Browsing,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy –Restart
Install the Office 2010 Filter Packs found here: http://www.microsoft.com/en-us/download/details.aspx?id=17062
Install Office 2010 Filter Pack Service Pack 1 found here: http://www.microsoft.com/en-us/download/details.aspx?id=26604
The next step is the actual install – which I won’t cover as there are tons of content on the web around that.
After my brand spanking new multirole servers were deployed and base configuration completed it was time for the DAG configuration.
The first thing to know when creating the DAG on Windows Server 2012 is that your cluster name object (CNO) needs to be pre-staged, because of the permission changes in Windows Server 2012 with regards to computer objects.
- CNO enhancements in Windows Server 2012:
http://blogs.technet.com/b/wincat/archive/2012/08/29/windows-server-2012-failover-cluster-enhanced-integration-with-active-directory-ad.aspx
- The CNO pre-staging steps are outlined in this article:
http://technet.microsoft.com/en-us/library/ff367878(v=exchg.141).aspx
It’s important to ensure the above CNO pre-staging is correct as the cluster is only formed once you add the first mailbox server to the DAG. This is where my second issue popped up.
I noticed that during Add-DatabaseAvailabilityGroupServer the process got stuck at installing the Failover Cluster Components. I’m not entirely sure if this is Windows Server 2012 related or only happened to me on that day (it has never happened on Windows Server 2008 R2), but I killed the process and noticed that the components were indeed installed on the server. When I reran Add-DatabaseAvailabilityGroupServer itfinished successfully and the cluster was created.
I don’t like processes getting stuck and then killed in mid configuration, so before my second Add-DatabaseAvailabilityGroupServer I pre-installed the Failover Cluster components by using the following PowerShell cmdlet:
Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools
At this stage I encountered my third issue (yeah it was a tough day at work :-) ):
When the second server is added to the cluster, the cluster is changed to Node and File Share majority – thus using the predefined File Share Witness server (FSW) and Witness directory that you specified in New-DatabaseAvailabilityGroup.
For some reason my FSW cluster resource would just not go online with an error message 0x8007052e: "unknown user name or bad password".
- I confirmed all connectivity, permissions and firewall settings on my FSW and everything looked fine.
- Deleted and recreated the FSW manually – still no go.
Trying to avoid unnecessary time wasting I decided to just remove the cluster completely and start again (luckily PowerShell makes this very easy):
- Removed the nodes from the cluster: Remove-DatabaseAvailabilityGroupServer for both nodes.
- Removed the DAG configuration in Exchange: Remove-DatabaseAvailabilityGroup
- Checked the cluster to ensure the cluster is removed.
- Removed the Cluster Name Object.
- Pre-staged new CNO and reran New-DatabaseAvailabilityGroup and Add-DatabaseAvailabilityGroupServer
- Happy days! The FSW cluster resource came online.
Moral of the story: Sometimes it’s better and faster to start again than to troubleshoot for hours on end. I might have been able to get the FSW online with a little digging in the cluster logs, I have feeling that the CNO had some problem in AD, but with minimal deployment time I decided to reconfigure and luckily it worked out with minimal troubleshooting this time around.
The rest of the deployment went without a hitch, I’ll be migrating mailboxes soon and hopefully I don’t pick up any other anomalies along the way (if I do I’ll definitely add it as a blog post :-) ).
Hopefully someone will find the information above helpful when they deploy on Windows Server 2012!
Until next time.
Michael