Well! After a short introduction a month a go its been a fairly busy 5 or so weeks! What with Christmas and New Years happening I haven’t had much of an opportunity to take to my blog and chat about some stuff.
Without further ado though lets talk about a subject that’s fairly close to my heart and one I particularly enjoy – Exchange Hybrid! Yes you heard me right, I have done a few of these builds now and I wanted to put together something that would get all of the goodness together in one place. This blog post is part 1 of a 3 part series, this first part will talk about the pre-reqs, the tools to get you started and the things that are most commonly overlooked.
First things first lets talk version’s, this post is all about 2013 hybrid we have done away with the days of Exchange 2010 hybrid and vast improvements have been made to the somewhat complex undertaking of the hybrid wizard for 2010. It is definitely the way to go, its fully supported by Exchange 2007 and 2010 so unless you are running 2003 (tell me you aren’t right?!) then its a no brainer.
Lets talk about the pre-reqs, what do we need to get it going…..
If you are running Exchange 2007 you will need to make sure that the servers are patched to Service Pack 3 RU10. If it’s 2010 then you will need to make sure that your servers have been updated to Service Pack 3.
Now as with all things Exchange, I turn to my trusty friend the Exchange Deployment Assistant. The Exchange Server Deployment Assistant is a web-based tool that asks you a few questions about your current environment and then generates a custom step-by-step checklist that will help you deploy different versions of Exchange Server for different types of scenarios. This little known tool is a god send and I would highly recommend that prior to undertaking any type of Exchange deployment that you take a long, loving look at this little sweetheart.
After plugging your scenario into the Deployment Assistant, you will be presented with a deployment report which includes step by step instructions, you even have the option of printing out the report in a Microsoft Word format. There are a couple of hybrid scenarios that we could cover, this blog post is going to be focusing on getting Exchange 2007 setup in a hybrid topology with Exchange 2013 acting as the hybrid transport role.
The first steps to any deployment or migration is planning! Generally I like to take stock of the current environment and work out what I have and where we are up to with the build levels, how many mailboxes I have etc. To do this, I run a power shell script which was created by the clever Steve Goodman. His script, inspired by the output of an Exchange TAP tool, aims to automatically generate a report that gives you an overview of your environment, Exchange 2003, 2007, 2010, 2013 and 2016 servers and database availability groups. To learn more about this tool and to download it head over to his blog post.
Once we have our environment report, we are able to determine whether any service packs or patches need to be applied to any of the servers in preparation for Exchange 2013. At this stage in the game I would recommend that you plan an outage window and get those servers patched if need be.
This report should also give us a good indication as to who is a a bit of a hoarder when it comes to their emails (a few friends spring to mind here, one in fact who will no doubt be reading this and nodding his head in agreement), and those who like to get organised and stay organised with our nice compact, ‘couple a hundred’ MB mailboxes. The sizing is a good thing to be aware of because its going to give us a good benchmark to work out how long its going to take to move mailboxes online.
I have a particular nifty little calculator that I use to estimate the throughput of a mailbox migration, this little nugget of goodness will allow me to work out the time of a single mailbox migration or the time taken for simultaneous mailbox moves. I simply plug in my speeds and the average mailbox size and it should give me the estimate in hours.
Something that may help you get into the mindset of adopting a hybrid approach is to understand that the hybrid component is really a very small part of the entire process. We effectively have to stand Exchange 2013 up in “coexistence” with Exchange 2007 before we can even begin to get mailboxes online.
Note: if you are running Exchange 2007 on a Windows server that is running 2008 make sure that you disable IPV6 as it can cause some connection issues between the 2 versions of Exchange. Refer to this blog here for good instructions on how to do it and check that its been done.
Introducing Exchange 2013 into an Exchange 2007 environment is a fairly straightforward task. However that being said, generally speaking one of the most overlooked, and least documented topics is the proper configuration of URLs for Proxy and Redirection.
A good place to start is with this blog post by Michael Van Horenbeeck. This article explains when Exchange 2013 will proxy connections to Exchange 2007 and when it will redirect the connection. This is a worthwhile read as most instances of coexistence fall into the trap of not setting up the legacy namespaces, I suggest setting these namespaces up even if you are doing a hybrid build as it keeps things nice and neat.
It is worth noting however that this isn’t always applicable to everyone’s environment. For example if we were to setup a hybrid environment which was only going to be used for a short period of time it would be preferable to use hybrid.domain.com.au for the URL’s for the Exchange 2013 server, and keep the existing 2007 URL’s in place changing only the autodiscover URL to point to the 2013 CAS.
In our scenario we have a very simple setup. We have a single Exchange 2007 server and a single Exchange 2013 server. Hybrid is likely to be in operation for a period of time whilst mailboxes are migrated over in batches to Exchange online so therefore I have chosen to update the 2007 URL’s to use the legacy namespace.
Prior to Exchange 2013 being introduced, our 2007 URLs were configured as follows:
Our DNS was configured as follows:
mail.domain.com.au – 192.168.100.11
autodiscover.domain.com.au – 192.168.100.11
The default internalURL and AutoDiscoverServiceInternalURI values are derived from the server FQDN, but these have since been changed. Your configuration may be different depending on how it was setup.
Likewise, when Exchange 2013 is introduced into the environment, the default values are derived from the server FQDN.
For Coexistence and interoperability between Exchange 2013 and 2007, these values all need to be changed. The first step in the migration process is to update these values so that all users connect to OWA, EAS, and OA via Exchange 2013. The details of why can be found in Michael Van Horenbeeck’s blog post, essentially Exchange 2013 can proxy and redirect back to 2007, but 2007 cannot proxy forward to Exchange 2013.
Before we can change over any of these URL’s we need to test thoroughly and we need to make sure that the SAN cert which we have for Exchange has been updated with the new legacy.domain.com.au namespace. For my particular scenario the customer decided to use a wildcard cert, this option is usually cheaper than other types of certificates, and they make some Exchange Server configurations easier to manage.
The security question which I know you want to ask, is also relatively easy to answer. There is a common assumption that wildcard certs are less secure than other certs, say for example the commonly used SAN cert.
Microsoft’s own documentation even has to references “the security implications”.
…many customers are uncomfortable with the security implications of maintaining a certificate that can be used for any sub-domain.
Symantec or Verisign as most know them details some of those implications here:
- Security: If one server or sub-domain is compromised, all sub-domains may be compromised.
- Management: If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.
If however, like in our scenario we are using a wildcard cert to secure a single internet facing CAS server then the above issues do not cause me or the customer too much concern. If however you are planning on deploying a large Exchange organisation with multiple geographic entry points for various services, or those services spread over many services, then those issues are of greater concern.
If I am in a production scenario I generally like to test everything that I can before making any changes to the already configured Exchange 2007 server. Usually I will set up some fake URL’s on the 2013 server and using host file manipulation test all of the connections to make sure that the proxying and redirecting is working prior to cutting things over to the new URL’s.
After the testing has been completed. It is time to update the Exchange 2013 and 2007 URLs. Once complete the new URL’s should look a little like this:
Our DNS will now look like this:
Let’s take a closer look at some of the configuration.
OWA – Redirect. When a user whose mailbox still resides on 2007, accesses OWA via the 2013 CAS, they will be redirected back to 2007 via externalURL value: https://legacy.domain.com.au/owa
ActiveSync – Proxy. I would recommend that as a best practice we setup ActiveSync to proxy from 2013 to 2007 as some ActiveSync devices do not handle the redirect correctly. I have seen this occur with some Apple devices running older versions of IOS.
In order to force a proxy scenario, the externalURL value for 2007 is set to $null. The internalURL on 2007 should be configured with https://legacy.domain.com.au/Microsoft-Server-ActiveSync
Set-ActiveSyncVirtualDirectory –Identity “Ex2013\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL https://mail.domain.com..au/Microsoft-Server-ActiveSync –ExternalURL https://mail.domain.com.au/Microsoft-Server-ActiveSync
Set-ActiveSyncVirtualDirectory –Identity “Ex2007\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL https://legacy.domain.com.au/Microsoft-Server-ActiveSync –ExternalURL $null
Outlook Anywhere – Proxy. All OA connections, both 2007 mailboxes and 2013 mailboxes will now connect via the 2013 CAS. 2013 will proxy connections back to 2007 for legacy mailboxes.
The externalHostName for 2013 and 2007 should be the same, (mail.domain.com.au).
Note: Exchange 2007 does not support “Negotiate” authentication (refer to image below). This means that the externalClientAuthenticationMethods should be configured to match whatever is configured for 2007, which is either Basic or NTLM. For Outlook Anywhere to proxy from 2013 to 2007, the IISAuthenticationMethods on 2007 will need to be reconfigured to support both Basic and NTLM. By default, Exchange 2007 IISAuthenticationMethods is set to just Basic. NTLM must be added for the proxy to work.
Set-OutlookAnywhere –Identity “Ex2013\Rpc (Default Web Site)” –InternalHostname mail.domain.com.au –ExternalHostName mail.domain.com.au –ExternalClientAuthenticationMethod Basic –IISAuthenticationMethods Basic,NTLM
Set-OutlookAnywhere –Identity “Ex2007\Rpc (Default Web Site)” –IISAuthenticationMethods Basic,NTLM
Exchange Web Services – (AutoDiscover) Autodiscover is used to retrieve the Exchange Web Services configuration for the 2007 users. Refer to another of my posts on how autodiscover works.
AutoDiscover – Both the 2007 and 2013 Service Connection Point (SCP) locator can be configured to point to the Autodiscover URL https://autodiscover.domain.com.au/Autodiscover/Autodiscover.xml.
Make sure that the the internal and external DNS is updated so that the A record for the autodiscover.domain resolves to the Exchange 2013 Client access server.
Set-ClientAccessServer –Identity Ex2013 –AutoDiscoverServiceInternalUri https://autodiscover.domain.com.au/Autodiscover/Autodiscover.xml
ECP – Exchange 2007 did not have an ECP virtual directory. Therefore only the 2013 ECP virtual directory needs to be configured.
That’s it for now, part 2 is on the horizon and will be coming shortly!