Exchange-V15 Automated Installer

Well hello there fanciful friends and lovers of all things Exchange!  Have I got a treat for you today or have I got a treat….  I have been wiling away my evenings in earnest over the last couple of days all in an effort to reduce the amount of time that I spend on doing an Exchange build, to develop a more repeatable process, and then as a result make each environment I setup a consistent and standard build.

So what is this unicorn tool that I stumbled across recently and just so happened to be as interesting to me as Ryan Gosling with his top off –

Exchange v15 Unattended Setup:

All credit for this most awesome tool goes to Michel de Rooij of whom I have just become his number 1 fan.  Alas all jokes aside and onto the serious business of how this little gem of a script works.  Michel’s post does a truly excellent job of laying out the foundations for this tool I however wanted to put something a little more descriptive together for my fellow Exchange Evangelists.

Let’s get started…  I familiarised myself with the script in a dev. environment and would highly recommend that you do the same first.  Whilst the code is excellent and has been put together very well it is still wise to understand what the tool is doing etc. before you gun-ho into a production environment.

Simplistically the script cycles through 6 phases, if you specify the -AutoPilot switch and enter in credentials the script will manage all of the reboots and once the server is back online will login and resume activities from the last phase.  It does this by writing to a state.xml file which is stored in the same install location specified when executing the script, once the script has finished executing the phase that it is currently in the results are written to that same state file each time.

Phase 1 – Install Windows Features and Operating System Prerequisites

Phase 2 – Install Exchange Prerequisites

Phase 3 – Install Exchange Prerequisites Continued

Phase 4 – Install Exchange and Prepare Schema

The script has a lot of smarts built into it, one that I particularly love is that I have the ability to run the script using the -NoSetup switch which basically means I can get all of the pre-req’s for Exchange and the OS installed including features automatically!  The script will work out the version of Exchange that I am planning to install through specifying the source directory of the installation files and from that will determine the pre-reqs and features that need to be applied.

If the script has access to the internet it will download the most recent packages etc. and save them to the specified install directory – pretty cool eh?!

Onwards, I tend to break my installations down into 3 components:

  1. Install pre-requisites, windows features and any other OS components that need to be applied or installed.
  2. Update and prepare AD – if you are a reader of my blog usually you will know that this is my most hated phase and the one that I always seem to run into trouble with!
  3. Install Exchange 2016 – YAY 🙂

Using this script I have been able to automate steps 1 and 3.  I typically, unless I am doing a brand new build of Exchange tend to do the prepare AD step manually. I do this primarily because I am a control freak and like to see what’s happening, but also because I have been scared off of this step way too many times in the past with things going wrong.

For step 1 I have adopted this process using the script (I may change this, I am a girl after all):

  1. Download and extract my Exchange setup files to C:\ExchangeSetup
  2. Download and extract (if required) any pre-requisite files to C:\Temp
  3. Copy the script to C:\Install
  4. Open a command prompt using elevated privileges aka. as an administrator / god / keeper of secrets/ commander of the universe – whatever term you like to call those with domain admin rights.
  5. Run the following from C:\Install – .\Install-Exchange15 -NoSetup -SourcePath c:\ExchangeSetup -InstallPath c:\Install -IncludeFixes -InstallFilterPack -Verbose

.\Install-Exchange15 -NoSetup -SourcePath c:\ExchangeSetup -InstallPath c:\Install -IncludeFixes -InstallFilterPack -Verbose

I’ve taken a series of screenshots of this voodoo magic in action:



As part of the prerequisites installation, there are a number of restarts that need to be completed.  The script will take care of this process if the autopilot option is enabled.  In addition if you specify credentials the script will also auto login after the reboot has completed.

After the prerequisites have installed, the script will complete running and if you haven’t chosen to use the autopilot feature which I haven’t, you will need to do a restart and then kick the script off again to move onto the subsequent phases.

The next few phases are the actual installation of Exchange 2016, again this script makes it effortless all I had to do was make myself a cuppa and watch the magic happen!  This is the command that I used to do the install:

 .\Install-Exchange15.ps1 -InstallMailbox -SourcePath C:\ExchangeSetup -TargetPath $path -InstallPath c:\Temp -MDBName DB1 -MDBDBPath E:\ExData\DB1 -MDBLogPath E:\EXLogs\DB1 -DisableSSL3 -IncludeFixes -SCP https://ServerName/Autodiscover/Autodiscover.xml -Verbose

As I was running an Exchange 2016 installation in coexistence with Exchange 2010 I chose to use the -SCP switch to set the Service Connection Point to the same as Exchange 2010 so as to eliminate any potential cert errors with Outlook from popping up.  As you can see, the script offers the flexibility to create the DB’s as part of the installation and specify the location of those and the log files. It also provides the ability to disable SSL3 and install any fixes that may be applicable all as part of the install process.

I chose to use the -Verbose switch for the entire process as I am again a control freak and like to have the visibility over what the script is doing at each step, it’s also quite helpful if things don’t go according to plan and you need to see at which step the failure occurred.  This helps as I could then go back to the script and work out what function we were up to when the failure happened and what I needed to do to get it past that point.


Overall I am really impressed with this tool, the attention to detail and what it actually does for me as a consultant makes it an invaluable tool to have in the back pocket.  I also hope that it will be something that I will continue to use and may inspire others to have a go with.

Happy Exchange installing!


Exchange 2010 & SP3 Install Issues

Well it’s been an experience, installing Exchange Service Pack 3 that is.  Cutting a long, long story short I have had a bit of a run in with my usual crowd pleaser Exchange.

Cutting to the chase and for those of you who need to get on with your job, modify the reg key for the site that the Exchange server sits in to be the same site as the Schema Master. If you are interested in why, read on to see an explanation and detailed instructions.

I have project that I am working on at the moment which is to install Exchange 2016, implement a hybrid Exchange scenario and begin using Exchange Online.  As a prerequisite for installing 2016 into an existing Exchange 2010 environment I needed to apply Service Pack 3 and RU13 – sounds fairly straightforward doesn’t it!

Straightforward it was not, I had so many errors trying to the get the install of SP3 to even start.  I resorted to using some trickery and learned some things along the way to defeat Exchange, not a term I am overly familiar with as Exchange and I usually play quite nicely together.

First things first, the environment that I am working within consists of a top level domain and then subsequent child domains which house the resources required, things such as Exchange, SQL etc.  It is not an uncommon scenario and many organisations adopt this topology so I was somewhat perplexed to discover that Exchange in this instance did not do do so well.

As part of the service pack install a number of changes need to be made in the Active Directory schema and so the account that you are using to install the service pack or Exchange for that matter should be a member of the Schema Admins, Org Management and Enterprise Admins group.  You should also and this I did not know and was the cause of a lot of my issues is ensure that a domain controller in the domain that Exchange is a member server of is a Schema Master.  The reason for this is simple, Exchange as mentioned above needs to be make a number of changes to the AD Schema and as such must be able to contact the Schema master to make these changes.

As I pointed out above, one of the issues that I had when applying the service pack was that the Exchange server was not in the same site as the Schema Master.  This prevented the install from completing successfully, this prevented the install from even beginning it basically failed at the prerequisites.

The types of errors that I was getting were as follows:


The Active Directory schema isn’t up-to-date, and this user account isn’t a member of the ‘Schema Admins’ and/or ‘Enterprise Admins’ groups.


Global updates need to be made to Active Directory, and this user account isn’t a member of the ‘Enterprise Admins’ group.


The local domain needs to be updated. You must be a member of the ‘Domain Admins’ group and ‘Organization Management’ role group, or ‘Enterprise Admins’ group to continue.


You must be a member of the ‘Organization Management’ role group or a member of the ‘Enterprise Admins’ group to continue.


You must use an account that’s a member of the Organization Management role group to install or upgrade the first Mailbox server role in the topology.


You must use an account that’s a member of the Organization Management role group to install the first Client Access server role in the topology.


You must use an account that’s a member of the Organization Management role group to install the first Client Access server role in the topology.


You must use an account that’s a member of the Organization Management role group to install or upgrade the first Mailbox server role in the topology.


Setup encountered a problem while validating the state of Active Directory: Exchange organization-level objects have not been created, and setup cannot create them because the local computer is not in the same domain and site as the schema master.  Run setup with the /prepareAD parameter on a computer in the domain vinnies.local and site State Support Office, and wait for replication to complete.


Either Active Directory doesn’t exist, or it can’t be contacted.

I confirmed way before I initiated the install that my account had the appropriate memberships and I performed some basic networking tests to determine that I could in fact contact the domain controllers etc.

What it came down to in the end and this I discovered in part through trawling through the exchange setup logs was that the exchange server was unable to contact the Schema Master.  I admit that the method I used to fix this up and get the install to begin and complete successfully is not one that I would typically recommend and is definitely not best practice!  However it was something that I could remove once the install had completed.

Modify the SiteName key in the registry of the Exchange Server –


Add the SiteName of the server that has the Schema Master role, close the registry, restart the server, and rerun the install.  This fixed up all of the errors for me during the prerequisites steps.  After the install completed successfully I removed the SiteName value and restarted the server, no harm done.

Eh voila!  Not the cleanest way of getting around this issue but this worked for me, and just to call out I did try and use the -domaincontroller switch to force the Exchange Server to communicate with the right DC which unfortunately did not work for me however it may work for you before you try this.



In at the deep end – Exchange Hybrid Goodness Part 2

So…. we move onto the illustrious part 2 of our Exchange Hybrid blog goodness.  In part 1 we covered the versions, pre-reqs, useful tools and some of the more finer points that tend to get overlooked as part of a hybrid build.

In part 2 we are actually going to get onto the build phase of Exchange, hold onto your hats this is going to get a little fun!

I am making an assumption that as per part 1 of this series you have reviewed your current environment and have patched your Exchange 2007 servers to the latest required patch levels.  We should now be raring to go and ready to install our first Exchange 2013 server.

Installing Exchange 2013 is actually pretty straight forward and doesn’t need any sort of technical kung fu to get going….. Did I just say straight forward, haha I was joking! Generally speaking its straight forward, there are a couple of pre-installation tasks that we need to complete before we can kick the install off.

In my scenario I am going to be installing Exchange 2013 on a Windows server 2012 machine, there are a few things that we need to be aware of before we jump in and start the install, these are;

  • The Active Directory forest functional level should be at the very minimum Windows Server 2003
  • At least one of the domain controller’s should be running Windows Server 2008
  • As in other versions prior to 2013 the best practice advice is to deploy Exchange 2013 as a member server

In my particular scenario the Exchange Server 2013 that I am building is going to be a multi role server so it will be my Client Access Server (CAS) and my Mailbox (MBX) server.  There is a little tidbit of information here that I think it is worth mentioning as it is not something that a lot of people are aware of when they begin considering adopting a hybrid approach for their organisation.  This little bit of information is that, Microsoft to encourage businesses to adopt a hybrid approach and ultimately move their mail off of on-prem servers to Exchange online offers what is known as a hybrid Exchange product key.

What this license entitles you to is an install of Exchange Server 2013 with both the MBX and CAS roles installed acting solely as the hybrid server.  This license is only free for as long as you are not hosting mailboxes on the server, the moment that you begin creating or migrating mailboxes is when you are in breach of the licensing terms.  You can get a hybrid license by clicking on this link, you will be taken to the page below:


If you select “Get Key” the next page will ask you to specify what version of on-premises Exchange hybrid servers you have installed or that you plan to install.  The wizard will then verify the eligibility of your Office365 subscription and if successful will give you a license to be used with your hybrid build..


Now that we have a license key to use, we move onto installing the pre-reqs for Windows 2012.  Now this is a straightforward task, simply copy the few lines of powershell I have below and windows installer will take care of the rest for you.

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

Once all of these windows features have been installed you will need to reboot the server. Its now time to install the last few applications which I have listed below with links to the download locations:

Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit

Microsoft Office 2010 Filter Pack 64 bit

Microsoft Office 2010 Filter Pack SP1 64 bit

To start the Exchange install you need to make sure that the account you are using has the appropriate rights to Active Directory this is because as part of the install Exchange will make changes / update the Schema.  The account either needs to be added to the Schema admins or the Organisation Management group, generally speaking I usually add my account to both and make sure that it is running as a domain admin and local admin on the server aswell.

I am not going to take you step by step through the Exchange install as it is fairly straight forward, just make sure that you select the Mailbox and Client Access roles on the Server Role Selection window.


After you have made all of your selections, the setup will start.  At this point I would strongly recommend that you either feed yourself or top up on your caffeine quota for the day as the install generally takes quite a bit of time to complete.


Once completed restart the server.

As I am sure that you are aware the Exchange Management Console (EMC) and the Exchange Control Panel (ECP) are no longer in this version of Exchange and both tools have been replaced by the Exchange Admin Center (EAC).  This is a web-based management console which has been specifically optimised for on-premises, online, and hybrid Exchange deployments, in other words its pretty hot property!

There are several advantages to using the web based EAC, one is that you can partition Internet and intranet access from within the ECP IIS virtual directory. With this functionality, you can control whether users are allowed to have Internet access to the EAC from outside of your organization, while still allowing an end user to access Outlook Web App Options.  Pretty cool right?!

Because the EAC is now a web-based management console, you’ll need to use the ECP virtual directory URL to access the console from your web browser. In most cases the EAC’s URL will look similar to the following:

  • Internal URL: https://<CASServerName>/ecp   The internal URL is used to access the EAC from within your organization’s firewall.
  • External URL:   The external URL is used to access the EAC from outside of your organization’s firewall. Some organizations may want to turn off external access to the EAC.

See Turn off access to the Exchange admin center for instructions on how to do this

In our particular scenario as I mentioned in part 1 we are installing Exchange 2013 in a coexistence scenario where we are still running Exchange 2007, and my mailbox is still housed on the Exchange 2007 mailbox server.  What this means is that the browser will default to the Exchange 2007 ECP.

You can access the EAC by adding the Exchange version to the URL. For example, to access the EAC whose virtual directory is hosted on the Client Access server MBX-13, use the following URL: https://MBX-13/ecp/?ExchClientVer=15.

Conversely, if you want to access the Exchange 2007 ECP and your mailbox resides on an Exchange 2013 Mailbox server, use the following URL: https://MBX-07/ecp/?ExchClientVer=14.

Its now time to install the latest CU, CU10 is available.  I would strongly recommend that you buck tradition and install the latest CU that you are able to get your hands on.  There are several reasons that I suggest this, primarily though its because any changes / updates that are made to the hybrid wizard will be better catered for in an up to date on-prem Exchange server.

Now that we have Exchange installed, we can move onto the hybrid aspects of this blog series which is really what we have been building upto!  Stay tuned for part 3 🙂

In at the deep end – Exchange Hybrid Goodness Part 1

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 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: – –

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 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:

Set-OwaVirtualDirectory –Identity “ex2013\owa (Default Web Site)” –InternalUrl –ExternalURL

Set-OwaVirtualDirectory –Identity “ex2007\owa (Default Web Site)” –InternalUrl –ExternalURL

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

Set-ActiveSyncVirtualDirectory –Identity “Ex2013\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL –ExternalURL

Set-ActiveSyncVirtualDirectory –Identity “Ex2007\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL –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, (

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 –ExternalHostName –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.

Set-WebServicesVirtualDirectory –Identity “Ex2013\EWS (Default Web Site)” –InternalURL –ExternalURL

Set-WebServicesVirtualDirectory –Identity “Ex2007\EWS (Default Web Site)” –InternalURL –ExternalURL

AutoDiscover – Both the 2007 and 2013 Service Connection Point (SCP) locator can be configured to point to the Autodiscover URL

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

ECP –  Exchange 2007 did not have an ECP virtual directory.  Therefore only the 2013 ECP virtual directory needs to be configured.

Set-EcpVirtualDirectory –Identity “Ex2013\ecp (Default Web Site)” –InternalURL –ExternalURL

That’s it for now, part 2 is on the horizon and will be coming shortly!