Migrating G-Suite Mailboxes to Exchange Online

Well hello there!  Its been a while hasn’t it, ok its been bloody ages since I last added a new post.  What can I say I have been busy living!

So all Exchange and Exchange Online lovers, I feel like I should extend this greeting to Exchange Online lovers!  Todays blog post is all about migrating G-Suite mailboxes to Exchange Online.

Let me tell you that Google are not keen for you to move a mailbox to Exchange Online, nope not keen at all.  In fact under the guise of increased security they actually make it a little challenging, not because of the technical complexities of how to perform the migration but more around how well it is documented.

Did I say documented?  That’s basically a lie because whilst there are some articles that provide some trinkets of information there isn’t, not that I have been able to find a definitive approach to migrating mailboxes away from Gmail.  The instructions provided by Microsoft are fairly good but don’t really cover all of the steps required.

Lets make a start.  The migration that I am performing is for a very small number of users and so therefore we will not be using any custom tools.  It’s worth pointing out that should you be looking at undertaking a migration of this type on a larger scale that it would be well worth investing in some third party tools to assist you with the process.

Add User

The first step in the G-Suite migration is to ensure that the user has been setup in the on-premises domain controller.

Once the new user has been configured, the account will be synced up to Azure AD via the Azure Active Directory Connect application.

 Check User Account, License & verify Email Addresses

  1. Open the Office365 portal using a Global Administrators account credential.
  2. Browse to the Users menu, select Active Users.AddUser
  3. Locate the new user created in the section above, and click on the account to make changes.
  4. Next to Product Licenses, select Edit to apply a license to the new user.
  5. Choose location as Australia, and turn the Office 365 Business Premium slide switch to on. Doing this will license the user and begin the provisioning process for an Exchange online mailbox.


G-Suite Preparation

There are multiple steps that need to be completed prior to performing a migration to Exchange Online.

There are 3 primary configuration changes that need to be applied:

  1. Less Secure Apps needs to be enabled from a Domain Administration level, this setting is enabled tenant wide. – This only needs to be changed once.
  2. 2 factor authentication needs to be setup for each user being migrated to Exchange Online.  Keep in mind this will send ALOT of text messages to whichever number you plug in, you might want to use your own phone first.
  3. An App password is required to enable O365 to open the contents of the Gmail mailbox and begin the syncing process.

Enable Less Secure Apps

  1. Browse to the G-Suite Admin portal page, open Security.  You will need to make sure that this is the administrator account, you cannot turn on secure apps without this account as its a change that is made tenant wide.Gmail
  2. Browse down to the bottom of the Security settings section and select Less Secure Apps.
  3. Choose Turn on in the options page.

Less Secure Apps

Enable 2-factor Authentication

  1. Open Gmail for the user being migrated.
  2. Select My Account from the menu in the top-right corner.
  3. Choose the Sign-in & Security menu, browse to the Signing in to Google section, and select 2-Step Verification.2FactorAuth
  4. Choose Get started in the following window. Google will prompt for the password to the account again before opening the 2-step Verification wizard.
  5. Enter the phone number to be used with the account, and select Next.
  6. Google will process the provided mobile number, and will send a verification code which will need to be entered into the next window. Choose Next.
  7. On completion Google will advise that it worked and will prompt to Turn on 2-Step Verification. Choose Turn On to complete the wizard.

Setup an App Password

The final step is to setup an app password. This password will be recorded in the CSV file detailing all of the users to be migrated to Exchange Online, and will enable O365 to securely connect to the G-Suite Mailbox.

DO NOT skip this step even if you think you can get away with just specifying the users password in the CSV file!

  1. After enabling 2-Step Verification, google will redirect back to the security settings page. Scroll down the page and select App Passwords.
  2. Google may (will) require you to authenticate again by typing in your password and selecting Sign In.
  3. Choose Select App, and from the available option select Custom.AppPassword
  4. Type in Office365 in the description and choose Generate.
  5. Copy the generated app password and store it in a safe location.

Creating the Migration Batches

The final step is to prepare the migration batches and start the sync process. This is broken down into three separate steps:

  • Create CSV file for batches
  • Connect Office 365 to Gmail
  • Create a migration batch and start migrating Gmail mailboxes

 Create CSV file for batches

  1. Open Microsoft Excel and add the following headings, EmailAddress UserName Password save the excel file as a .csv file.
  2. Sign in to the G Suite admin console using your administrator username and password.
  3. Choose Users, select each user and copy the email address to the UserName column in the CSV. UserName is the sign-in name for the users Gmail Mailbox.
  4. Populate the EmailAddress column with the user’s new email address that has been setup in Office 365. This will be firstname.lastname@domain.com.au.
  5. Populate the Password column with the generated App Passwords for each Gmail Mailbox.
  6. The completed CSV file should look like this:


 Connect Office 365 to Gmail

To migrate Gmail mailboxes successfully, Office 365 needs to connect and communicate with Gmail. To do this, Office 365 uses a migration endpoint.

  1. Go to the Exchange admin center.
  2. In the EAC, go to Recipients > Migration > More > Migration endpoints.MirgationEndpoint
  3. Click New to create a new migration endpoint.
  4. On the Select the migration endpoint type page, choose IMAP.newMigration
  5. On the IMAP migration configuration page, set IMAP server to imap.gmail.com and keep the default settings the same.
  6. Click Next. The migration service uses the settings to test the connection to Gmail system. If the connection works, the Enter general information page opens.
  7. On the Enter general information page, type a Migration endpoint name, for example, Test5-endpoint. Leave the other two boxes blank to use the default values.
  8. Click New to create the migration endpoint.

Create a migration batch and start migrating Gmail mailboxes

  1. In the Office 365 admin centre, navigate to Admin centres > Exchange.
  2. In the Exchange admin center, go to Recipients > Migration.
  3. Click New > Migrate to Exchange Online.
  4. Choose IMAP migration > Next.
  5. On the Select the users page, click Browse to specify the migration file you created.
  6. After Office 365 validates the migration file, it displays the number of users listed in the file as the number of Gmail mailboxes to migrate.MigrateUsers
  7. Click Next.
  8. On the Set the migration endpoint page, select the migration endpoint that you created in the previous step, and click Next.
  9. On the IMAP migration configuration page, accept the default values, and click Next.
  10. On the Move configuration page, type the name (no spaces or special characters) of the migration batch in the box—for example, Test5-migration.
  11. Click Next
  12. On the Start the batch page, do the following:
  13. Choose Browse to send a copy of the migration reports to other users. By default, migration reports are emailed to you. You can also access the migration reports from the properties page of the migration batch.
  14. Choose Automatically start the batch > new. The migration starts immediately with the status Syncing.


Once completed, Exchange Online will continue to sync all of the migration batches once a day until the batch is completed.  Once you have cut MX records etc. over you can complete the migration batch and life should be swimmingly awesome in Office 365 land!

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: https://eightwone.com/2013/02/18/exchange-2013-unattended-installation-script/.

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: https://gallery.technet.microsoft.com/scriptcenter/AD-FS-Diagnostics-Module-8269de31

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: https://nikpatel.net/2014/12/22/renew-expired-adfs-token-certificates-for-adfs-2-0-and-sharepoint-2013-on-premises/
  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: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-o365-certs/#manualrenew
  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: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-federation-management/#repairing-the-trust
  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: http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-certificate-problems(v=ws.10).aspx

“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)” –InternalUrlhttps://mail.domain.com.au/owa –ExternalURLhttps://mail.domain.com.au/owa


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

Outlook Anywhere

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

Exchange Web Services

Set-WebServicesVirtualDirectory –Identity “Ex2013\EWS (Default Web Site)” –InternalURL https://mail.domain.com.au/EWS/Exchange.asmx –ExternalURLhttps://mail.domain.com.au/EWS/Exchange.asmx


Set-ClientAccessServer –Identity Ex2013 –AutoDiscoverServiceInternalUrihttps://autodiscover.domain.com.au/Autodiscover/Autodiscover.xml


Set-EcpVirtualDirectory –Identity “Ex2013\ecp (Default Web Site)” –InternalURLhttps://mail.domain.com.au/ecp –ExternalURLhttps://mail.domain.com.au/ecp

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)” –InternalUrlhttps://legacy.domain.com.au/owa –ExternalURLhttps://legacy.domain.com.au/owa


Set-ActiveSyncVirtualDirectory –Identity “Ex2007\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL https://legacy.domain.com.au/Microsoft-Server-ActiveSync –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 https://legacy.domain.com.au/EWS/Exchange.asmx –ExternalURLhttps://legacy.domain.com.au/EWS/Exchange.asmx


Set-ClientAccessServer –Identity Ex2007 –AutoDiscoverServiceInternalUrihttps://autodiscover.domain.com.au/Autodiscover/Autodiscover.xml

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!