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.

License

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:

CSV

 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.

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!

Advertisements

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;
}
}
}
else
{
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;
}
else
{
Write-ExchangeSetupLog -Info (“Cannot find arbitration mailbox with name=$name.”);
}
}
else
{
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:

arbitrationmailboxes.png

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

Corruption.png

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:

Error:

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.

Error:

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

Error:

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.

Error:

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

Error:

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.

Error:

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.

Error:

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.

Error:

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.

Error:

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.

Error:

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 –

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\SiteName

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.

URLs2

OWA

Set-OwaVirtualDirectory –Identity “ex2013\owa (Default Web Site)” –InternalUrlhttps://mail.domain.com.au/owa –ExternalURLhttps://mail.domain.com.au/owa

ActiveSync

Set-ActiveSyncVirtualDirectory –Identity “Ex2013\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL https://mail.domain.com..au/Microsoft-Server-ActiveSync –ExternalURL https://mail.domain.com.au/Microsoft-Server-ActiveSync

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

AutoDiscover

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

ECP

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:

test-outlookconnectivity

test-outlookwebservices

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).

TestOutlook

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.

OWA

Set-OwaVirtualDirectory –Identity “ex2007\owa (Default Web Site)” –InternalUrlhttps://legacy.domain.com.au/owa –ExternalURLhttps://legacy.domain.com.au/owa

ActiveSync

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.

image

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

AutoDiscover

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:

legacy.domain.com.au 192.168.100.11

mail.domain.com.au 192.168.100.22

autodiscover.domain.com.au 192.168.100.22

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.

 https://testconnectivity.microsoft.com/

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:

AddingADomain

EnterDomainName

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.

Verification

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!

Exporting SharePoint 2013 Search Customisations

​I had a client the other day who have a production enviorment and have just created a development enviorment.  This particular client have a LOT of search customisations and more than a handful of result types, result sources, etc.  Unfortunately when the content DB which was a copy of the prod enviorment was restored to the dev enviorment, it did not include any of these customisations.

With the help of a good colleague of mine we put together some PowerShell functions that will enable you to export the search customisations from the UI and the import them to the destination site using 1 line of PowerShell.

Open powershell and paste the following lines of code:

[reflection.assembly]::LoadWithPartialName(“Microsoft.SharePoint.Client”) | Out-Null
[reflection.assembly]::LoadWithPartialName(“Microsoft.SharePoint.Client.search”) | Out-Null

function Export-SPEnterpriseSearchSettings($siteUrl, $settingsFile=”SearchSchema.xml”, $exportLevel=[Microsoft.SharePoint.Client.Search.Administration.SearchObjectLevel]::SPSite){
$context = New-Object Microsoft.SharePoint.Client.ClientContext($siteUrl)
$searchConfigurationPortability = New-Object Microsoft.SharePoint.Client.Search.Portability.SearchConfigurationPortability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.SearchObjectowner($context,$exportLevel)
$value = $searchConfigurationPortability.ExportSearchConfiguration($owner)
$context.ExecuteQuery()
[xml]$schema = $value.Value
$schema.OuterXml | Out-File $settingsFile -Encoding UTF8
}

function Import-SPEnterpriseSearchSettings($siteUrl, $settingsFile=”SearchSchema.xml”, $exportLevel=[Microsoft.SharePoint.Client.Search.Administration.SearchObjectLevel]::SPSite){

$context = New-Object Microsoft.SharePoint.Client.ClientContext($siteUrl)
$searchConfigurationPortability = New-Object Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,$exportLevel)
[xml]$schema = [xml](gc $settingsFile)
$searchConfigurationPortability.ImportSearchConfiguration($owner,$schema.OuterXml)
$context.ExecuteQuery()
}

Then type the following powershell command: Import-SPEnterpriseSearchSettings –siteUrl http://mysiteurl –settingsFile “C:\temp\SearchConfiguration.xml”

I have been asked about how to do this a few time’s so thought that this would be a good, quick post to write up.  Enjoy!

 

In at the deep end – Exchange Hybrid Goodness Part 1

Well!  After a short introduction a month a go its been a fairly busy 5 or so weeks!  What with Christmas and New Years happening I haven’t had much of an opportunity to take to my blog and chat about some stuff.

Without further ado though lets talk about a subject that’s fairly close to my heart and one I particularly enjoy – Exchange Hybrid!  Yes you heard me right, I have done a few of these builds now and I wanted to put together something that would get all of the goodness together in one place.  This blog post is part 1 of a 3 part series, this first part will talk about the pre-reqs, the tools to get you started and the things that are most commonly overlooked.

First things first lets talk version’s, this post is all about 2013 hybrid we have done away with the days of Exchange 2010 hybrid and vast improvements have been made to the somewhat complex undertaking of the hybrid wizard for 2010.  It is definitely the way to go, its fully supported by Exchange 2007 and 2010 so unless you are running 2003 (tell me you aren’t right?!) then its a no brainer.

Lets talk about the pre-reqs, what do we need to get it going…..

If you are running Exchange 2007 you will need to make sure that the servers are patched to Service Pack 3 RU10.  If it’s 2010 then you will need to make sure that your servers have been updated to Service Pack 3.

Now as with all things Exchange, I turn to my trusty friend the Exchange Deployment Assistant.  The Exchange Server Deployment Assistant is a web-based tool that asks you a few questions about your current environment and then generates a custom step-by-step checklist that will help you deploy different versions of Exchange Server for different types of scenarios.  This little known tool is a god send and I would highly recommend that prior to undertaking any type of Exchange deployment that you take a long, loving look at this little sweetheart.

ExchangeDeploymentAssistant

After plugging your scenario into the Deployment Assistant, you will be presented with a deployment report which includes step by step instructions, you even have the option of printing out the report in a Microsoft Word format. There are a couple of hybrid scenarios that we could cover, this blog post is going to be focusing on getting Exchange 2007 setup in a hybrid topology with Exchange 2013 acting as the hybrid transport role.

The first steps to any deployment or migration is planning!  Generally I like to take stock of the current environment and work out what I have and where we are up to with the build levels, how many mailboxes I have etc.  To do this, I run a power shell script which was created by the clever Steve Goodman.  His script, inspired by the output of an Exchange TAP tool, aims to automatically generate a report that gives you an overview of your environment, Exchange 2003, 2007, 2010, 2013 and 2016 servers and database availability groups.  To learn more about this tool and to download it head over to his blog post.

ExchangeReport

Once we have our environment report, we are able to determine whether any service packs or patches need to be applied to any of the servers in preparation for Exchange 2013.  At this stage in the game I would recommend that you plan an outage window and get those servers patched if need be.

This report should also give us a good indication as to who is a a bit of a hoarder when it comes to their emails (a few friends spring to mind here, one in fact who will no doubt be reading this and nodding his head in agreement), and those who like to get organised and stay organised with our nice compact, ‘couple a hundred’ MB mailboxes.  The sizing is a good thing to be aware of because its going to give us a good benchmark to work out how long its going to take to move mailboxes online.

I have a particular nifty little calculator that I use to estimate the throughput of a mailbox migration, this little nugget of goodness will allow me to work out the time of a single mailbox migration or the time taken for simultaneous mailbox moves.  I simply plug in my speeds and the average mailbox size and it should give me the estimate in hours.

Migration

Something that may help you get into the mindset of adopting a hybrid approach is to understand that the hybrid component is really a very small part of the entire process.  We effectively have to stand Exchange 2013 up in “coexistence” with Exchange 2007 before we can even begin to get mailboxes online.

Note: if you are running Exchange 2007 on a Windows server that is running 2008 make sure that you disable IPV6 as it can cause some connection issues between the 2 versions of Exchange.  Refer to this blog here for good instructions on how to do it and check that its been done.

Introducing Exchange 2013 into an Exchange 2007 environment is a fairly straightforward task. However that being said, generally speaking one of the most overlooked, and least documented topics is the proper configuration of URLs for Proxy and Redirection.

A good place to start is with this blog post by Michael Van Horenbeeck. This article explains when Exchange 2013 will proxy connections to Exchange 2007 and when it will redirect the connection.  This is a worthwhile read as most instances of coexistence fall into the trap of not setting up the legacy namespaces, I suggest setting these namespaces up even if you are doing a hybrid build as it keeps things nice and neat.

It is worth noting however that this isn’t always applicable to everyone’s environment. For example if we were to setup a hybrid environment which was only going to be used for a short period of time it would be preferable to use hybrid.domain.com.au for the URL’s for the Exchange 2013 server, and keep the existing 2007 URL’s in place changing only the autodiscover URL to point to the 2013 CAS.

In our scenario we have a very simple setup.  We have a single Exchange 2007 server and a single Exchange 2013 server.  Hybrid is likely to be in operation for a period of time whilst mailboxes are migrated over in batches to Exchange online so therefore I have chosen to update the 2007 URL’s to use the legacy namespace.

Prior to Exchange 2013 being introduced, our 2007 URLs were configured as follows:

URLS
Our DNS was configured as follows:

mail.domain.com.au – 192.168.100.11

autodiscover.domain.com.au – 192.168.100.11

The default internalURL and AutoDiscoverServiceInternalURI values are derived from the server FQDN, but these have since been changed.  Your configuration may be different depending on how it was setup.

Likewise, when Exchange 2013 is introduced into the environment, the default values are derived from the server FQDN.

For Coexistence and interoperability between Exchange 2013 and 2007, these values all need to be changed.  The first step in the migration process is to update these values so that all users connect to OWA, EAS, and OA via Exchange 2013.  The details of why can be found in Michael Van Horenbeeck’s blog post, essentially Exchange 2013 can proxy and redirect back to 2007, but 2007 cannot proxy forward to Exchange 2013.

Before we can change over any of these URL’s we need to test thoroughly and we need to make sure that the SAN cert which we have for Exchange has been updated with the new legacy.domain.com.au namespace.  For my particular scenario the customer decided to use a wildcard cert, this option is usually cheaper than other types of certificates, and they make some Exchange Server configurations easier to manage.

The security question which I know you want to ask, is also relatively easy to answer. There is a common assumption that wildcard certs are less secure than other certs, say for example the commonly used SAN cert.

Microsoft’s own documentation even has to references “the security implications”.

…many customers are uncomfortable with the security implications of maintaining a certificate that can be used for any sub-domain.

Symantec or Verisign as most know them details some of those implications here:

  • Security: If one server or sub-domain is compromised, all sub-domains may be compromised.
  • Management: If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.

If however, like in our scenario we are using a wildcard cert to secure a single internet facing CAS server then the above issues do not cause me or the customer too much concern.  If however you are planning on deploying a large Exchange organisation with multiple geographic entry points for various services, or those services spread over many services, then those issues are of greater concern.

If I am in a production scenario I generally like to test everything that I can before making any changes to the already configured Exchange 2007 server.  Usually I will set up some fake URL’s on the 2013 server and using host file manipulation test all of the connections to make sure that the proxying and redirecting is working prior to cutting things over to the new URL’s.

After the testing has been completed.  It is time to update the Exchange 2013 and 2007 URLs.  Once complete the new URL’s should look a little like this:

URLs2
Our DNS will now look like this:

legacy.domain.com.au 192.168.100.11

mail.domain.com.au 192.168.100.22

autodiscover.domain.com.au 192.168.100.22

Let’s take a closer look at some of the configuration.

OWA – Redirect.  When a user whose mailbox still resides on 2007, accesses OWA via the 2013 CAS, they will be redirected back to 2007 via externalURL value: https://legacy.domain.com.au/owa

Set-OwaVirtualDirectory –Identity “ex2013\owa (Default Web Site)” –InternalUrl https://mail.domain.com.au/owa –ExternalURL https://mail.domain.com.au/owa

Set-OwaVirtualDirectory –Identity “ex2007\owa (Default Web Site)” –InternalUrl https://legacy.domain.com.au/owa –ExternalURL https://legacy.domain.com.au/owa

ActiveSync – Proxy. I would recommend that as a best practice we setup ActiveSync to proxy from 2013 to 2007 as some ActiveSync devices do not handle the redirect correctly.  I have seen this occur with some Apple devices running older versions of IOS.

In order to force a proxy scenario, the externalURL value for 2007 is set to $null.  The internalURL on 2007 should be configured with https://legacy.domain.com.au/Microsoft-Server-ActiveSync

Set-ActiveSyncVirtualDirectory –Identity “Ex2013\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL https://mail.domain.com..au/Microsoft-Server-ActiveSync –ExternalURL https://mail.domain.com.au/Microsoft-Server-ActiveSync

Set-ActiveSyncVirtualDirectory –Identity “Ex2007\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL https://legacy.domain.com.au/Microsoft-Server-ActiveSync –ExternalURL $null

Outlook Anywhere – Proxy. All OA connections, both 2007 mailboxes and 2013 mailboxes will now connect via the 2013 CAS.  2013 will proxy connections back to 2007 for legacy mailboxes.

The externalHostName for 2013 and 2007 should be the same, (mail.domain.com.au).

Note: Exchange 2007 does not support “Negotiate” authentication (refer to image below).  This means that the externalClientAuthenticationMethods should be configured to match whatever is configured for 2007, which is either Basic or NTLM.  For Outlook Anywhere to proxy from 2013 to 2007, the IISAuthenticationMethods on 2007 will need to be reconfigured to support both Basic and NTLM.  By default, Exchange 2007 IISAuthenticationMethods is set to just Basic.  NTLM must be added for the proxy to work.

image

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

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

Exchange Web Services – (AutoDiscover) Autodiscover is used to retrieve the Exchange Web Services configuration for the 2007 users.  Refer to another of my posts on how autodiscover works.

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

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

AutoDiscover – Both the 2007 and 2013 Service Connection Point (SCP) locator can be configured to point to the Autodiscover URL https://autodiscover.domain.com.au/Autodiscover/Autodiscover.xml.

Make sure that the the internal and external DNS is updated so that the A record for the autodiscover.domain resolves to the Exchange 2013 Client access server.

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

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

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

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