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!

Troubleshooting and Managing ADFS 3.0

The infamous words “It’s not working”, “I can’t login”, or “The page cannot be displayed.  I’d be willing to say a fair few of us have heard these lines on more then one occasion.

Like my post that I published on preparing for an O365 migration, I thought that it would be good to put something equally as helpful together to guide you the reader on where to start when troubleshooting an ADFS issue.  These little critters pop up frequently enough that they deserve their own special post, I have taken everything I have seen on other posts and my own experiences and have put them all here in one place.

Some of the links that I have put in this blog post refer to ADFS 2.0, I have put these in intentionally as the content is still relevant for 3.0 and the steps are much the same.

ADFS is used in combination with Office 365 to create a scenario in which federated identities are used, this is also known as single sign-on.  Unlike cloud identities or synchronised identities, federated identities authenticate against an on-premises Active Directory through an ADFS server infrastructure instead of Windows Azure Active directory.  This means that ends users log into Office 365 using their on-premises credentials.

ADFS provides a robust environment that requires few frequent maintenance tasks, however there is still a requirement to perform certain tasks on an as needed basis.  This guide will provide the information and instructions for performing these tasks, it will also include a troubleshooting section for some of the more common issues that arise with an ADFS implementation.

Managing ADFS Components

ADFS is made up of two primary components:

Federation Service

The Federation Service functions as a security token service and routes authentication requests from external user accounts in partner organisations and clients on the Internet.

Web Application Proxy

The Web Application Proxy (WAP) functions as a proxy for the Federation Service in a perimeter network.

Managing the Federation Server

ADFS Management Console   

The AD FS administration tool (adfs.msc) is supplied as a Microsoft Management Console (MMC) snap-in. The administration tool is used to add account and resource partners, map partner claims, add and configure account stores, and identify and configure federation-aware Web applications

  1. Go to Start, type in AD FS and click to open the ADFS management console.
  2. adfsconsole2. The AD FS Management console will open. The following figure shows the main components of the AD FS Management console.
  3. adfsconsole2

Changing the primary Federation Server

The first server that is installed in the federation farm is automatically the primary federation server.  Any subsequent federation servers that are added to the farm will poll the primary federation server for configuration changes every 5 minutes by default.  If changes are found these will be replicated to a local instance of the configuration database, this is stored in the Windows Internal Database unless SQL has been specified.

If the primary federation server fails and there are multiple federation servers in a farm although these other servers will remain operational, changes to the ADFS configuration will not be able to be made until the primary federation server has been restored or another federation server has been promoted as the primary server.

To promote a secondary federation server to primary, run the following commands from the secondary federation server:

Set-AdfsSyncProperties –Role PrimaryComputer

Once the new primary federation server has been set, any other secondary federation servers need to be configured to sync with the primary federation server.  Run the following command on the remaining member servers:

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName {FQDN of the Primary Federation Server}

ADFS Certificate Management

Token-Signing Certificate

ADFS uses a token-signing certificate to digitally sign the token that is created when the system makes an authentication request.  This token is then sent back to the source of the request, which is referred to as the relaying party.  Once an ADFS trust is created between two environments, the token-signing certificate is exchanged.

By default, ADFS uses a self-signed certificate which comes with a validity period of one year.  ADFS by default is configured to automatically generate a new certificate when it is close to expiring.  This behaviour is controlled through the AutoCertificateRollover attribute.  To verify the current ADFS property settings, run the following command:

Get-ADFSProperties | Select AutoCertificateRollOver

It is imperative that the token-signing certificate is regularly checked to ensure that it does not expire, or that there are not any issues with the auto certificate rollover service.

SSL Certificate

ADFS requires a certificate for standard Secure Sockets Layer (SSL) server authentication on each federation server in the farm.  The same certificate should be used on each federation server in the farm, and both the certificate and the private should be available.  The SSL certificate is used for securing communications between federation servers, clients, web application proxy and federation server proxy computers.

SSL certificates that have been imported can be viewed via the Certificates snap-in for the MMC.  It is imperative that the SSL certificate used in ADFS operations is valid and does not expire.

  1. Open MMC, and add the certificate snap-in
  2. Select Local Computer under the snap-in options
  3. Open Personal, this will show all of the SSL certificates that have been imported on the server.

Troubleshooting ADFS

Whilst ADFS is a robust identity management solution, there times when things can go wrong.  Please see below for a breakdown on the most common issues that occur with an ADFS deployment and ways to troubleshoot and resolve them.

Enable additional logging

Additional logging provides more information about the interactions of the ADFS farm which will assist in any troubleshooting activities.  To enable additional logging, please follow the steps outlines below:

  1. Check the current log level for ADFS by running this command:


  1. Confirm that the SuccessAudits and FailureAudits have not been configured and add these into the logging results:

Set-AdfsProperties -LogLevel ((Get-AdfsProperties).LogLevel+’SuccessAudits’,’FailureAudits’)

  1. To ensure that the audit results are visible in the event logs, enable application generated auditing:

# Verify

. $env:\systemroot\system32\AUDITPOL.exe /GET /SUBCATEGORY:”Application Generated”

# Configure

. $env:\systemroot\system32\AUDITPOL.exe /SET /SUBCATEGORY:”Application Generated” /FAILURE:ENABLE /SUCCESS:ENABLE

When an ADFS request is processed, there will be more information available in the application log which will assist in the troubleshooting process.

ADFS Diagnostics Module (Section taken from TechNet)

The ADFS diagnostics module contains commandlets to gather configuration information of an ADFS server, as well as commandlets to perform health checks to detect configuration issues based on common root causes, for example duplicate SPN’s, Certs, etc.

The tool can be downloaded from the TechNet Script Centre:

Some examples of the types of commands that can be used:

Get information about the system 


Get information about the AD FS farm deployment 


Perform health checks 

Test-AdfsServerHealth | ft Name,Result  -AutoSize

“There was a problem accessing the site.”, “The page cannot be displayed” Internal Authentication works, external does not.

Typically this issue occurs when the proxy server is unable to establish a secure communication with the ADFS server.  If authentication is working internally, but externally users are unable to authenticate, start by checking the following on the proxy server:

  1. The system clock – make sure that the time on the proxy and adfs server are the same.
  2. Service account – verify that the service account which is used by the proxy server to obtain its configuration information from the ADFS server has not been deleted, the password reset or the password has expired.
  3. Name resolution – verify by performing an NSLOOKUP on the proxy server that it is able to correctly resolve the ADFS service name and that the IP address of the ADFS server is correct.

“There was a problem accessing the site.”, “The page cannot be displayed” Both internal and external users are unable to authenticate.

Start by checking the following on the ADFS Servers, in addition to checking the points above on the Proxy Server.

  1. Certificate Expiration Date – Open the ADFS management console and browse to certificates in the left window.  If the token-signing or token-decrypting certificates have expired, refer to this link for more information:
  2. SSL Certificate Expiration Date – Open MMC, and add the certificates snap-in.  Follow the prompts to add the certificate store for the local computer and once loaded select Personal from the left navigation pane, from here you should be able to see the SSL cert and check its expiration date.
  3. ADFS & Azure AD in Sync – Confirm that the ADFS server and Azure AD are in sync, by verifying that the certificate thumbprints for each match.  Refer to this link for more information:
  4. Verify the health of the Azure AD trust – If the ADFS farm was configured using Azure AD Connect, the application can check for the current health of the AD FS and Azure ADtrust and take appropriate actions if required to repair the trust. Refer to this link for more information:
  5. Authenticate on ADFS server – After verifying that the certificates are all valid and have not expired, and that the trust is setup correctly, test authentication on the ADFS server – browse to: https://ADFS-ServiceName/adfs/ls/idpinitiatedsignon.htm.If authentication succeeds on the ADFS server, move onto trying an internal workstation, followed by an external machine if that is successful.
  6. Check Event Viewer – If authentication is still proving to be troublesome, begin reviewing the ADFS logs in the event viewer, sometimes the application and or system logs will yield results also.  If there are errors present, you can correlate the event ID’s here:

“There was a problem accessing the site.”, “The page cannot be displayed” External users are able to authenticate but internal users are unable to authenticate.

The steps for troubleshooting this particular scenario are pretty much a rinse and repeat of the steps above, with a couple of extra ones detailed below:

  1. Run Tracert – From an internal workstation, open a command prompt and run a tracert to the internal IP address of the ADFS Server.  This should provide a good indication as to where there may be an issue with communication to the ADFS server.
  2. Install Fiddler – Download and install Fiddler on a workstation that is on the internal network.  Open Fiddler and run a packet trace on the open session to determine what is happening when the request to authenticate is sent to the ADFS server.  It should be possible to see the request from the workstation hit the ADFS server, and the ADFS server then respond to the request.
  3. NSLOOKUP – Open a command prompt on the internal workstation and perform an NSLOOKUP to verify that it is able to correctly resolve the ADFS service name and that the IP address of the ADFS server is correct.

I hope to keep updating this post with more ways to troubleshoot ADFS, in the meantime if you have anything that I should add to this post please write it in the comments!




Exchange 2016 Powershell fails to open – The Module DLL E:\Program Files\Microsoft\Exchange Server\V15\Bin\kerbauth.dll failed to load. WinRM cannot complete the operation.

Moving onto my next issue with my Exchange 2016 reinstallation after a drive failure (see my previous blog post for more information), this post is about an error that I was receiving after having completed a successful install – navigating to the Exchange Management Shell, the following error occurred:

WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:1

On closer inspection of the event viewer, I noticed that this error was also quite prevalent:

The Module DLL C:\Program Files\Microsoft\Exchange Server\V15\Bin\kerbauth.dll failed to load.  The data is the error

The error it transpires was caused because I had reinstalled Exchange 2016 on a different drive.  Exchange has an IIS module that is registered in the applicationhost.config file – this model kerbauth.dll is responsible for authentication and is registered at the time of install, it was not removed during the uninstall.

To resolve, I opened the applicationhost.config file and did a find and replace on C\Program Files\Microsoft\Exchange Server\V15\Bin\kerbauth.dll updating it with the correct drive letter E:\.  Once I had updated the file I restarted IIS and everything started working as expected.

I referred to this blog post which helped me to identity the underlying cause.

Exchange 2016 Error During Install: “Database is mandatory on UserMailbox. Property Name: Database”

As part of my migration project that I am currently working on which has been the talking point of most of my blog posts of late, it seems the saga of the 2010 > 2016 migration continues.

The story begins one windy Wednesday night after a tumultuous couple of days trying to nail down prerequisites and get Exchange 2016 to install,  I was sipping champagne from a straw celebrating my triumph and preparing to move onto the next phase setting up the DAG and getting the system mailboxes etc. moved when we had a catastrophic hard drive failure.

Sadly my nights of sipping champagne came to an abrupt end and I was left with a very broken Exchange 2016 server x2.  Fast forward to today and I am eagerly anticipating the end of the work day as my celebrations have begun again in earnest, I have just fixed up the last of the issues that I experienced as a result of the drive failure for Exchange.

This blog post details the process that I followed to resolve an error that I was receiving when attempting to reinstall Exchange 2016 after the uninstallation.  I had made the assumption that the uninstaller would remove any attributes / extensions etc. that were created as part of the install. This was not the case, in fact the uninstaller is rather reminiscent of my husband just leaving trails of his clothes behind him wherever he goes.  Needless to say I had to go in and manually clean up all traces of Exchange 2016 before I could continue on with the reinstallation.

The detailed error message that I was getting is as follows:

Error: The following error was generated when “$error.Clear();
if ($RoleIsDatacenter -ne $true -and $RoleIsDatacenterDedicated -ne $true)
if (Test-ExchangeServersWriteAccess -DomainController $RoleDomainController -ErrorAction SilentlyContinue)
$sysMbx = $null;
$name = “SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}”;
$dispName = “Microsoft Exchange”;
Write-ExchangeSetupLog -Info (“Retrieving mailboxes with Name=$name.”);
$mbxs = @(Get-Mailbox -Arbitration -Filter {name -eq $name} -IgnoreDefaultScope -ResultSize 1 );
if ($mbxs.Length -eq 0)
Write-ExchangeSetupLog -Info (“Retrieving mailbox databases on Server=$RoleFqdnOrName.”);
$dbs = @(Get-MailboxDatabase -Server:$RoleFqdnOrName -DomainController $RoleDomainController);
if ($dbs.Length -ne 0)
Write-ExchangeSetupLog -Info (“Retrieving users with Name=$name.”);
$arbUsers = @(Get-User -Filter {name -eq $name} -IgnoreDefaultScope -ResultSize 1);
if ($arbUsers.Length -ne 0)
Write-ExchangeSetupLog -Info (“Enabling mailbox $name.”);
$sysMbx = Enable-Mailbox -Arbitration -Identity $arbUsers[0] -DisplayName $dispName -database $dbs[0].Identity;
if ($mbxs[0].DisplayName -ne $dispName )
Write-ExchangeSetupLog -Info (“Setting DisplayName=$dispName.”);
Set-Mailbox -Arbitration -Identity $mbxs[0] -DisplayName $dispName -Force;
$sysMbx = $mbxs[0];

# Set the Organization Capabilities needed for this mailbox
if ($sysMbx -ne $null)
# We need 1 GB for uploading large OAB files to the organization mailbox
Write-ExchangeSetupLog -Info (“Setting mailbox properties.”);
set-mailbox -Arbitration -identity $sysMbx -UMGrammar:$true -OABGen:$true -GMGen:$true -ClientExtensions:$true -MailRouting:$true -MessageTracking:$true -PstProvider:$true -MaxSendSize 1GB -Force;
Write-ExchangeSetupLog -Info (“Cannot find arbitration mailbox with name=$name.”);
Write-ExchangeSetupLog -Info “Skipping creating E15 System Mailbox because of insufficient permission.”
” was run: “Database is mandatory on UserMailbox.”.

The reason that I was receiving this particular error was because I had a previous installation of Exchange on this server and the arbitration mailboxes had become corrupted for obvious reasons (hard disk failure).   The quickest way to fix up this issue is to remove the AD accounts associated with the now broken arbitration mailboxes, and then re-run /preparead which would recreate all the required AD accounts.

This put me in somewhat of a conundrum because I had already updated the schema to support an Exchange 2016 install and as the arbitration mailboxes had been created in 2010 I couldn’t run /preparead using the 2010 setup files as the schema wouldn’t support it.  So what was I going to do…  I had to determine which of the arbitration / system mailboxes had been created as part of the 2016 /preparead as I suspected that it was these mailboxes that were causing me the grief.

To view the arbitration mailboxes I ran this command:

Set-ADServerSettings -ViewEntireForest $true

Get-mailbox -Arbitration | fl name,Database,DisplayName,ServerName

This command output a list of all of the arbitration mailboxes in the entire AD forest.  The reason for running this command is because the arbitration or system mailboxes do not appear in the Exchange Admin Centre.  Have a look at this blog post by Tony Redmond which has a really good explanation of what the arbitration mailboxes are and why they are so important.

The results that I got from the command looked a little like the below:


Except that one of my arbitration mailboxes was complaining about corruption.


What I had to do, was remove the associated user account from Active Directory.  These accounts are typically created.  Once I had removed the user accounts for the corrupted arbitration mailboxes I was able to run the Exchange 2016 setup again and this time it completed without any errors!


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 3

Welcome back!  If you have made it this far on the hybrid journey with me I am impressed!  And so we have reached almost the end of our journey.  You will recall in part 2 of this series that we now have a working Exchange 2013 server setup and as mentioned in part 1 we need to get the URL’s configured correctly, autodiscover DNS records changed over and our Office365 tenant sorted.  Soooo….. we have a lot of work to be getting on with, shall we?

First things first, we need to make sure that the cert we have applied to the Exchange 2007 server is also applied to the Exchange 2013 server.  I am not going to go step by step in how to apply a cert to the new Exchange server, there are a bunch of blogs already out there that will walk you through that component.  The only piece of advice that I will offer here is that when you add your cert make sure that you do so using the certmgr.mmc snap in first.

Next on the list, we need to update all of the virtual directories for Exchange 2013 with the right values.  We determined what those values should have been back in part 1 of this series, so it should just be a case of a copying and pasting what we have already done!  We are not going to update the 2007 URL’s until we have finalized testing and made sure that everything is working as expected.

Note: I am only doing this because we have a long term coexistence strategy, if you are doing a hybrid and intend on being off Exchange within a short space of time its not necessary to update the virtual directory URLS.



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


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

Outlook Anywhere

Set-OutlookAnywhere –Identity “Ex2013\Rpc (Default Web Site)” –InternalHostname –ExternalHostName –ExternalClientAuthenticationMethod Basic –IISAuthenticationMethods Basic,NTLM

Exchange Web Services

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


Set-ClientAccessServer –Identity Ex2013 –AutoDiscoverServiceInternalUri


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

Using some crafty host file manipulation on the Exchange 2013 server we should be able to do some testing to make sure that each of these URLS are working.  Two of my favorite testing commands are:



Both of these commands if we have manipulated the host records correctly should give us a success (I have hidden the URL values in this example as they are a customer).


Once we have successfully tested the Exchange 2013 component we can move onto updating the autodiscover record to point to the Exchange 2013 server both externally and internally.  This will require an update to the A record in the internal DNS and depending on who manages your external DNS a ticket raised to update the current autodiscover record to point to the 2007 server.

Once the autodiscover record has been changed over, it is time to update the 2007 URL’s to those that we specified above.


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


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

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


Outlook Anywhere

Set-OutlookAnywhere –Identity “Ex2007\Rpc (Default Web Site)”  –IISAuthenticationMethods Basic,NTLM

Exchange Web Services

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


Set-ClientAccessServer –Identity Ex2007 –AutoDiscoverServiceInternalUri

Ok so now that all of our virtual directories have been updated and our DNS records both internally externally, lets just recap on what those DNS records should look like now:

At this point we need to ensure that our autodiscover is working externally as expected and nothing is being blocked by firewall or otherwise.  To do this part of the testing I like to use the Remote Connectivity Analyser which is another awesome tool provided by Microsoft that helps me to my job and do it better.

There are a number of different tests that you can perform, I generally do an Outlook autodiscover and and Exchange Active Sync autodiscover test.  You can choose to do whatever is relevant to your deployment / environment.  The results of these tests are really helpful in diagnosing any potential issues should any exist.

Moving onto the hybrid components of our build.  One of the next pre-reqs that we need to do before we can start is to enable the MRS proxy service, this is the service that will perform the remote mailbox moves.

To enable the MRS service, open the EAC and navigate to Servers > Virtual directories.  Select the Client Access server, select the EWS virtual directory, and then click Edit.  Select the MRS Proxy enabled check box and click Save.

Ok so onto Office365 config!  Wow, we made it finally now we are getting to the juicy, juicy part of the blog series….

Where to start, well firstly we need to get our domain setup with Office365.  So head to the portal, get logged in and browse to Domains in the Office365 admin section.  Once there select Add Domain, you should be presented with the following window, hit Lets get Started:



The next step will ask you to verify that you do in fact own the domain, and will require you to create either a txt or mx record in your external DNS provider portal.  Once you have created either of these records, proceed with the wizard and you should see the following window once Office365 has confirmed ownership.


Select “No, I have an existing website or prefer to manage my own DNS records” when prompted on the next window.

The next steps will be configuring the advanced setup which will get Office365 setup for Hybrid.

I’ve decided to put that into another blog post as this one is already pretty late in the piece!

Planning for an O365 Migration – Assessment

I wanted to put together a post about how you actually get ready for office365, there are a few different steps that you will need to take and that’s why I am going to do this as a blog series rather than try to include everything in the one post.  This first post is going to focus on the current enviorment, the as is state if you like.

Its really important that we ensure that our current environment is as good as it can be prior to a migration to the cloud.  This is particularly important if the organisation as most do, are going to be using Azure Active Directory.  I always recommend that a customer wanting to do a move to Office365 perform an assessment of their current enviorment first.

By performing an assessment of the “as is state, we have a much better idea of the things that need to be changed, updated or removed.  I call these the remediation items and include them in any report that I prepare for the customer.  This post includes a detailed breakdown of all of the applications and scripts that I use to perform these assessment’s.

Microsoft Assessment and Planning Tool.

The Microsoft Assessment and Planning (MAP) Toolkit is an agentless inventory, assessment, and reporting tool that can securely assess IT environments for various platform migrations—including Windows 10, Windows 8.1, Windows 7, Office 2013, Office 2010, Office 365, Windows Server 2012 and Windows 2012 R2, SQL Server 2014, Hyper-V, Microsoft Private Cloud Fast Track, and Windows Azure.

One of the nice features of The Microsoft Assessment and Planning (MAP) Toolkit is that it is an agentless inventory, assessment, and reporting tool that has the ability to securely assess an environment for various platform migrations—this includes, Windows 8, Windows 7, Office 2010 and Office 365, Windows Server 2012 and Windows 2008 R2, SQL Server 2012, Hyper-V, Microsoft Private Cloud Fast Track, and Windows Azure…. Phew that’s a long list!


In a nutshell the tool provides detailed readiness assessment reports with hardware and software information, plus it also provides recommendations to help organisations with their IT infrastructure planning process.

It is an invaluable application to have in your toolkit and could be used in a number of different scenario’s. Each scenario provides detailed information and also includes the ability to generate reports which can be used to further analyse and distribute the captured information.  The scenarios that you can view are outlined below:

  • Cloud
  • Desktop
  • Server
  • Desktop Virtualisation
  • Server Virtualisation
  • Database

The tool displays the captured information in a simple yet comprehensive interface which is reminiscent of the familiar Windows 8 interface.


The cloud scenario assessment in particular offers a very detailed analysis and provides  comprehensive deployment and sizing recommendations based on the scans completed of the enviorment.

As I mentioned above, the tool provides extensive reporting capabilities including approx. 30 customer reports and proposals that are specific to the environment that the tool has inventoried.  Click here for more information on the reports and proposal that are available, this just makes my job infinitely easier!


Click here to view the MAP toolkit and download the latest version.


The backbone of every enviorment is Active Directory, without this crucial system running well the other components that make up an enviorment will typically experience a myriad of different issues.  Hence it is so important to ensure that prior to any migration, cloud or otherwise that AD is scrutinised and any issues discovered are fixed.  Microsoft have done an excellent job of providing us with a tool that will assist us in this, IDFix.

IdFix is used to perform discovery and remediation of identity objects and their attributes in an on-premises Active Directory environment in preparation for migration to Office 365. IdFix is intended for the Active Directory administrators responsible for DirSync with the Office 365 service.

This tool that will assist with preparing a Directory Synchronization deployment with Office 365. It will discover objects in Active Directory that have duplicates, invalid characters, are using a local UPN and a few other things.

One of the invaluable features of this application is that as part of the report which is generated, IDFix provides the administrator with the ability to fix up any issues discovered in the scan via the ACTION column.


Other Useful Scripts

  • Count total user, group and contact objects in Active Directory forest, this script is courtesy of Thomas Ashworth and can be downloaded here.  The results of the script will output to the PowerShell console and will be saved to a CSV file.
  • Active Directory Audit scripts, these scripts are provided courtesy of J House Consulting and there are literally too many to list here!  You can download these scripts by clicking here.  I use a few of these scripts for various things like identifying all computer objects etc.

Exchange Enviorment Report

This fantastic PowerShell script, the Exchange environment report was masterminded by Steve Goodman .  This script is my go to as a consultant, especially for Exchange Hybrid builds.  It was born out of the Exchange TAP Tool and the primary objective of the script is to generate a report which gives you a fairly granular overview of your current Exchange enviorment.  The supported versions are 2003, 2007, 2010, 2013 and 2016.  I have included an excerpt from Steve’s blog post for what the tool actually reports on:

  • Total Servers per Exchange version & service pack
  • Total Mailboxes per Exchange version & service pack, plus Office 365 remote mailboxes
  • Totals for Exchange roles across the environment
  • A site-by-site breakdown for the following:
    • Mailboxes per site
    • HTTPS FQDNs used for Internal, External and SCP URLs
    • CAS array names
    • Exchange servers, version, update rollup and version, service level, highlighted installed roles, OS version and service pack

A breakdown of each Database Availability Group including:

  • DAG name, member count and member list
  • Database information such as:
    • Name
    • Mailboxes per database and Average Size
    • Archive mailboxes per database and Average Size only shown if a DB includes Archive mailboxes
    • Database and whitespace size
    • Database and log disk free space percentage
    • Last full backup date/time (new) – only shown if at least one DAG DB has had a full backup
    • Circular Logging state (new) only shown if at least one DAG DB has circular logging enabled
    • Server hosting the active copy
    • List of servers hosting copies and copy count
    • A breakdown of Non-DAG databases including Exchange 2007 and 2003 DBs, including the database information above, along with Storage Group name (where applicable).ExchangeReport.png

Office365 Bandwidth and Network Connectivity Test

Bandwidth and network connectivity is an important consideration and often one that is overlooked by many organisations.  Unfortunately by not taking this into consideration potential problems can arise down the track when there is not enough available bandwidth for the current workload.  I use the office 365 bandwidth test and network connectivity test available here.

Note:  you will need to make sure you have the latest version of java runtime installed to see the results of the test.


So there you have it a consultants secrets revealed!  I hope that you find this post useful and that it aids you in a successful migration to Office365, I will try and keep this updated as I find new tools and develop new scripts.