MigrationOffice 365

How to migrate mailboxes from one Microsoft 365 or Office 365 organization to another


This article explains how to migrate mailboxes and service settings from one Microsoft 365 or Office 365 organization to another Microsoft 365 or Office 365 organization in a business-merger scenario. If you have more than 500 users to migrate or a large amount of SharePoint data to migrate, it’s a good idea to work with a Microsoft solution provider.

The scenario in this article is based on two fictional companies – and – using two separate Office 365 organizations. Contoso has purchased Fabrikam and is moving the Fabrikam users and data to the Office 365 organization.

Domain Tenant 1 (Target) Tenant 2 (Source)
Custom email domain:
Office 365 initial domain:

Scenario: Migrate using a third-party migration tool

This scenario assumes that user, group and other objects from the Fabrikam Company will be manually created in Office 365, imported into the portal via script, or merged into the Contoso Active Directory through Active Directory Domain Services (AD DS) consolidation.

When complete, all Fabrikam accounts will exist in the Office 365 organization, and will all use for the UPN. The final addressing scheme was chosen for simplicity and brevity but can of course be modified to meet your requirements.

How mailbox data can be moved from one Microsoft 365 or Office 365 organization to another

Planning: Two weeks before you migrate

If using a third-party migration tool to migrate your users, purchase the needed licenses for your migration.

Client considerations

For Outlook 2010 or above, you only need to remove the Outlook user profile and create it again.

For Outlook 2007 and Outlook 2010, when you are restarting the client, auto-discover will configure the client and rebuild the .OST file.

For the Skype for Business client, once migration is complete, since the process creates a new profile, you will need to add contacts.

Tenant preparation and licensing

The source tenant is the Fabrikam Office 365 organization from which you are migrating users and data. The target tenant is the Contoso Office 365 organization to which you are migrating.

  1. Increase licenses in Target Office 365 organization to accommodate all mailboxes that will be migrated from the source tenant.
  2. Create Administrator accounts in source and target tenants for use in migrating from Office 365 to another Office 365. Some migration tools may require more than one admin account in the source tenant to optimize the data throughput.

Room, resource, distribution group, and user object creation in the target tenant

To create the resources in the target (Contoso) tenant:

  1. If the Azure AD Connect tool will be used to sync all objects from the Contoso Active Directory Domain Services (AD DS), the objects from the source (Fabrikam) tenant AD DS must be created in the target tenant (Contoso) AD DS through consolidation.
    1. AD DS consolidation can be done using various AD DS tools. Consolidation can take extra time and planning depending on how many objects are being moved, so it can be completed ahead of the migration project.
    2. Verify that all new users and groups are synced to the target tenant via directory synchronization. The objects should appear as in the new tenant since the Fabrikam domain has not been moved over at this time. The primary email address for the users and groups can be updated to after the domain move is complete.
  2. If directory synchronization will not be used, or if any Rooms, Resources, Groups or Users are managed in the Microsoft 365 admin center of the source tenant; these objects must be created in the target tenant. Objects can be created manually in the Microsoft 365 admin center or for larger numbers import a CSV file by using the bulk add feature in the Microsoft 365 admin center, or by using Windows PowerShell.

End-user communications

To communicate the migration to the end users in your organization:

  1. Create a communication plan and begin to notify users of the upcoming migration and service changes.
  2. After migration, the Auto-Complete List (also known as the nickname cache) will have to be cleared on all Outlook clients. To remove all recipients from your Auto-Complete list in Outlook 2010 later, see Manage suggested recipients in the To, Cc, and Bcc boxes with Auto-Complete.
  3. Make users aware of how to connect to Outlook on the web (formerly known as Outlook Web App) with their new sign on information in case they have a problem after migration.

Preparation and pre-migration activities: Three days before you migrate

Domain preparation

To prepare the domain for migration, complete the following steps.

  1. Begin domain verification process on target (Contoso) tenant for the email domain.
  2. In the Microsoft 365 admin center, add the domain and create TXT records in Domain Name Systems (DNS) for verification.


    The verification will fail because the domain is still in use in the other tenant.

    Performing this step now will allow the DNS record time to propagate as it can take up to 72 hours. Final validation will occur later in the process.

Migration scheduling

To schedule the migration:

  1. Create master list of user mailboxes you want to migrate.
  2. Create mailbox mapping .CSV file for the third-party migration tool you are using. This mapping file will be used by the migration tool to match the source mailbox with the target tenant mailbox when migration occurs. We recommend that you use the * ‘initial’ domain for mapping the source accounts since the custom email domain will be constantly changing.

CSV file used to migrate mailbox data from one Office 365 organization to another

Mail exchanger record (MX record) time to live (TTL) test

Next, you’ll schedule the TTL test.

  1. In DNS, change the TTL value on the MX record for the primary email domain you wish to transfer to a small number (i.e. 5 minutes). If the TTL cannot be lowered to 5 minutes, make note of the lowest value. Example, if the lowest value is 4 hours, the MX record will have to be changed 4 hours before your migration begins.
  2. Mx Lookup can be used to verify MX and DNS changes.

Disable directory sync in source tenant

In the source tenant Microsoft 365 admin center, disable directory sync. This process can take 24 hours or more so it must be done ahead of the migration. Once disabled in the portal, any changes to the source tenant AD DS will no longer sync to the Office 365 organization. Adjust your existing user and group provisioning process accordingly.

Migration: The day you migrate

These are the steps you’ll need the day you perform the migration.

MX record change – Stop inbound mail flow

Change your primary MX record from Office 365 to domain that is not reachable, i.e. “”. Internet mail servers attempting to deliver new mail will queue the mail and attempt redelivery for 24 hours. Using this method, some email may return a non-delivery report (NDR) depending on the server attempting to deliver the email. If this is a problem use an MX record backup service. There are many third-party services that will queue your email for days or weeks. Once your migration is complete, these services will deliver the queued mail to your new Office 365 organization.


If your TTL is short, for example, five minutes, this step can be done at the end of the work day to cause less disruption. If you have a larger TTL, you must change the MX record ahead of time to allow the TTL to expire. Example, a four hour TTL must be changed before 2 PM if you plan to begin migrations at 6 PM.

Verify your MX and DNS changes if necessary. Nslookup or a service like MxToolbox can be used to verify MX and DNS changes.

Source tenant preparation

The primary email domain,, must be removed from all objects in the source tenant before the domain can be moved to the target tenant.

  1. If you had also set up your domain with a SharePoint Online public website, then before you can remove the domain, you first have to set the website’s URL back to the initial domain.
  2. Remove all Lync licenses from the users in the source tenant using Lync admin portal. This will remove the Lync Sip address connected to
  3. Reset default email addresses on Office 365 source mailboxes to the initial domain (
  4. Reset default email addresses on all Distribution Lists, Rooms and Resources to the initial domain ( in source tenant.
  5. Remove all secondary email (proxy addresses) from user objects that are still using
  6. Set default domain in source tenant to routing domain (in the admin portal, click your company name in the upper right corner).
  7. Use Windows PowerShell command Get-MsolUser -DomainName to retrieve a list of all objects that are still using the domain and blocking removal.
  8. For common domain removal issues, see You get an error message when you try to remove a domain from Office 365.

Target tenant preparation

Complete the verification of the domain in the tenant. You may have to wait one hour after removing the domain from the old tenant.

  1. Configure auto-discover CNAME (internal/External) optional.
  2. If you are using AD FS, configure the new domain in target tenant for AD FS.
  3. Begin mailbox activation in the tenant > Assign licenses to all of the new user accounts.
  4. Set the email domain as the primary address on the new users. This can be done by selecting/editing multiple unlicensed users in the portal or by using Windows PowerShell.
  5. If you are not using the password hash sync feature, pass-through authentication or AD FS, set password on all mailboxes in the target (Contoso) tenant. If you are not using a common password, notify users of the new password.
  6. Once mailboxes are licensed and active, transition the mail routing. Point the Fabrikam MX record to Office 365 target (Contoso) tenant. When the MX TTL expires, mail will begin to flow into the new empty mailboxes. If you are using an MX backup service, you can release the email to the new mailboxes.
  7. Perform verification testing of mail flow to/from new mailboxes in the target tenant.
  8. If you are using Exchange Online Protection (EOP): In the target tenant recreate mail flow rules (also known as transport rules), connectors, block lists, allow lists, etc. from source tenant.

Begin migration

To minimize downtime and user inconvenience, determine the best method for migration.

  • Migration for 500 users or less: Migrate Mail Calendar and contact data to target tenant mailboxes. Limit mail migration by date if possible; for example, the last 6 months of data.
  • Migration for more than 500 users: Use a multi-pass approach where you migrate contacts, calendars and only 1 week of email for all users, then on succeeding days or weeks, do multiple passes to fill in the mailboxes with older email data.

Start your mail migration via the third-party migration tool.

  1. Monitor migration progress with the tools provided by the vendor. Send out periodic progress reports during migration to management and migration team.
  2. Do second or third pass migrations, optional after all migrations are complete.

At the end of migration, Outlook 2007 and 2010 will sync the entire mailbox for each user, consuming considerable bandwidth depending on how much data you migrated into each mailbox. Outlook 2013 will only cache 12 months of data by default. This setting can be configured to more or less data, for example, only 3 months of data, which can lighten bandwidth usage.

Post migration: Cleanup

User may receive NDRs when replying to migrated email messages. The Outlook Auto-Complete List (also known as the nickname cache) needs to be cleared. To remove all recipients from your Auto-Complete list in Outlook 2010 later, see Manage suggested recipients in the To, Cc, and Bcc boxes with Auto-Complete. Alternatively, add the old legacy DN as an x.500 proxy address to all users.

Sample Windows PowerShell scripts

Use the following sample Windows PowerShell scripts as a starting point for creating your own scripts.

Office 365 bulk password reset

  1. Create a CSV file named password.csv.
  2. Insert “upn” and “newpassword” columns in this file (Example:,Password1)
  3. Use the Windows PowerShell command:
  1. Import-Csv password.csv|%{Set-MsolUserPassword -userPrincipalName $_.upn -NewPassword $_.newpassword -ForceChangePassword $false}

Copy all Office 365 accounts with a specific proxy address into a CSV file


# Script: showproxies.ps1
# Copies all accounts in Microsoft 365 that contain/don't contain a specific
# proxyaddress to a .CSV file (addresses.csv)
# Change the following variable to the proxy address string you want to find:
# $proxyaddr = ""
$proxyaddr = ""
# Create an object to hold the results
$addresses = @()
# Get every mailbox in the Exchange Organization
$Mailboxes = Get-Mailbox -ResultSize Unlimited
# Loop through the mailboxes
ForEach ($mbx in $Mailboxes) {
    # Loop through every address assigned to the mailbox
    Foreach ($address in $mbx.EmailAddresses) {
       # If it contains XXX,  Record it
        if ($address.ToString().ToLower().contains($proxyaddr)) {
            # This is an email address. Add it to the list
            $obj = "" | Select-Object Alias,EmailAddress
            $obj.Alias = $mbx.Alias
            $obj.EmailAddress = $address.ToString() #.SubString(10)
            $addresses += $obj
# Export the final object to a csv in the working directory

$addresses | Export-Csv addresses.csv -NoTypeInformation
# Open the csv with the default handler
Invoke-Item addresses.csv


Bulk Create room mailboxes in Microsoft 365


  • Before you run the following script, you need to install the Exchange Online PowerShell V2 module. For instructions, see Install and maintain the EXO V2 module. The EXO V2 module uses modern authentication.
  • Typically, you can use the script as-is if your organization is Microsoft 365 or Microsoft 365 GCC. If your organization is Office 365 Germany, Microsoft 365 GCC High, or Microsoft 365 DoD, you need to edit the Connect-ExchangeOnline line in the script. Specifically, you need to use the ExchangeEnvironmentName parameter and the appropriate value for your organization type. For more information, see the examples in Connect to Exchange Online PowerShell.

# Script: create-rooms.ps1
# This script creates room mailboxes in Microsoft 365.
# Syntax:Create-Rooms.ps1 -InputFile "file name.csv"
# Dependencies: Input file should contain 3 columns: RoomName, RoomSMTPAddress, RoomCapacity
param( $inputFile )
Function Usage
$strScriptFileName = ($MyInvocation.ScriptName).substring(($MyInvocation.ScriptName).lastindexofany("\") + 1).ToString()
C:\PS> .\$strScriptFileName -InputFile `"file name.csv`"
If (-not $InputFile) {Usage;Exit}

If ($ExchRemoteCmdlets.State -ne "Opened")
Write-Host Connecting to Exchange Online PowerShell...
Import-Module ExchangeOnlineManagement
$Global:ExchRemoteCmdlets = Get-PSSession -Name ExchangeOnlineInternalSession*
# Import the CSV file
$csv = Import-CSV $inputfile
# Create Rooms contained in the CSV file
$csv | foreach-object{
New-Mailbox -Name $_.RoomName -Room -PrimarySmtpAddress $_.RoomSMTPAddress -ResourceCapacity $_.RoomCapacity

Bulk remove secondary email address from mailboxes


  • Before you run the following script, you need to install the Exchange Online PowerShell V2 module. For instructions, see Install and maintain the EXO V2 module. The EXO V2 module uses modern authentication.
  • Typically, you can use the script as-is if your organization is Microsoft 365 or Microsoft 365 GCC. If your organization is Office 365 Germany, Microsoft 365 GCC High, or Microsoft 365 DoD, you need to edit the Connect-ExchangeOnline line in the script. Specifically, you need to use the ExchangeEnvironmentName parameter and the appropriate value for your organization type. For more information, see the examples in Connect to Exchange Online PowerShell.

#      Script:  remove-proxy.ps1
# This script will remove a secondary email address from many users
# Syntax:remove-proxy.ps1 -InputFile "filename.csv"
# Dependencies:Input file should contain 2 columns: Username, Emailsuffix
#               Example:  Username=tim,
# Script will remove the address from the mailbox for Tim.
# NOTE: Address must be secondary; it will not remove primary email address.
param( $inputFile )
Function Usage
$strScriptFileName = ($MyInvocation.ScriptName).substring(($MyInvocation.ScriptName).lastindexofany
("\") + 1).ToString()
C:\PS> .\$strScriptFileName -inputfile `"file name.csv`"
If (-not $inputFile) {Usage;Exit}

If ($ExchRemoteCmdlets.State -ne "Opened")
Write-Host Connecting to Exchange Online PowerShell...
Import-Module ExchangeOnlineManagement
$Global:ExchRemoteCmdlets = Get-PSSession -Name ExchangeOnlineInternalSession*
# Import the CSV file and change primary smtp address
$csv = Import-CSV $inputfile
$csv | foreach-object{
# Set variable for email address to remove
$removeaddr = $_.username + "@" + $_.emailsuffix
Write-Host ("Processing User: " + $_.UserName +" - Removing " + $removeaddr)
Set-Mailbox $_.Username -EmailAddresses @{Remove=$removeaddr}


Source Microsoft365

read more

Microsoft Edge Overtake Mozilla Firefox in Browser Market

chromium-edge-release-696×391 (1)

When Microsoft Edge was launched alongside Windows 10 in 2015, it was a web browser that looked like it was rushed out before it was ready. Certainly, it lacked the features of Google Chrome and Mozilla Firefox. Since then, Edge has come a long way and its growth has been cemented by NetMarketShare.

Microsoft Edge is now the second most popular web browser in terms of market share. According to the March 2020 report from NetMarketShare, Edge has surpassed Firefox.

Again, looking back it is amazing Microsoft Edge has come this far. Microsoft has fleshed out the feature set of the browser, but it still feels like the last year has been the catalyst for the new growth.

At the end of 2018, Microsoft announced it would be removing Edge from its EDGEHTML rendering and moving it to Google’s Chromium engine. This is the same underpinning framework that Google builds Chrome on.

Chromium Push

Since moving to Chromium (in preview through 2019 and launched fully in January), Edge has shared features with Chrome. While many questioned Microsoft’s decision, including Mozilla, it seems to have paid off.

NetMarketShare shows Microsoft Edge took 7.59% of the market while Firefox had 7.19%. As for Chrome, Google’s browser remains the runaway dominant service with 68.50% of the market.

Of course, Chrome’s dominance is unlikely to be challenged anytime soon. However, Microsoft will argue by moving to Chromium, it is providing a genuine alternative to Chrome that has near feature parity.

NetMarketShare does not offer any insight about whether Edge’s growth came at the expense of Firefox. While the browser claimed more market share, it is unclear if this meant people switched from Firefox to Edge.

Source Winbuzzer

read more

Microsoft Extends Smart Fabric Tech to a Patented Smart Glove


Back in November, Microsoft made steps into smart fabric development with a patent for electronically functional yarn. Essentially, the technology bakes computational power into woven fabric. In a new patent, Microsoft has taken its smart fabric idea a step further with a smart glove idea.

Published by USPTO, the patent describes an electronically functional fabric glove. It uses motion-restricting mechanisms to provide vibrational output through multiple haptic output devices.

In the patent, Microsoft discusses a smart glove that has areas of differing stiffness. This allows the smart fabric to host an input and output device. The wearable will allow users to connect devices such as touch screens, game controllers, and keyboards.
Here’s how Microsoft describes the technology in a patent:
“In some embodiments, the input subsystem may comprise or interface with selected natural user input (NUI) componentry. Such componentry may be integrated or peripheral, and the transduction and/or processing of input actions may be handled on- or off-board.
Example NUI componentry may include a microphone for speech and/or voice recognition; an infrared, color, stereoscopic, and/or depth camera for machine vision and/or gesture recognition; a head tracker, eye tracker, accelerometer, and/or gyroscope for motion detection and/or intent recognition; as well as electric-field sensing componentry for assessing brain activity.”
Smart Fabric Development
Tech companies not associated with fashion or clothes are already on the smart fabric train, including Samsung, Apple, and Google. Microsoft too is laying the groundwork for its own solutions.
Microsoft shows how the textile structure will be comprised of parallel weft yarns alongside parallel non-functional warp yarns. Researchers would be able to include electronic functionality distributed across the non-functional yarn.

Source Wimbuzzer

read more

Google Photos May Have Accidentally Sent Your Private Videos to Strangers


There are few things more personal than your private videos, but it seems a Google Photos slip-up sent some user’s clips to the wrong person. An email shared by Duo security CTO Jon Oberheide explains that users who exported their photos via Takeout between 21-25 November 2019 may have received someone else’s videos.

A bug in the exporting process caused some user’s content to be included in other’s archives. According to 9to5 Google, the company confirmed the issue and said it affected less than 0.01% of users attempting takeouts.

However, Alphabet Inc. has been unable to provide users with the specific videos that were shared or even how many were sent to strangers. The number of impacted users is small, but that content could be incredibly compromising. Oberheide’s request for more clarification was met with no new information and the following apology:
“We apologize for this inconvenience. Rest assured that the software bug that led to these technical issues has been identified and resolved.”

Source Winbuzzer

read more

Top tips for syncing on-premise Active Directory objects to multiple tenants


Hearing that an organization is migrating from their on-premises to one Office 365 tenant is a business case study we’re all familiar with now. And although this is becoming standard practice for businesses wanting to become more cost-effective, secure and flexible there are still implications to consider with this move. For example, in my line of work, I often come across situations where a local Active Directory object should be migrated to different Office 365 tenants and I’ll explain the multiple reasons why this occurs.
Firstly, a common reason for this is that the organization has subsidiaries who still want to share the on-premise service, but also want to be independent of the cloud services.
Another scenario I’ve come across is when an association wants to migrate an Active Directory object to multiple tenants. For example, if you think about a sports association, these often contain multiple sports federations and only some of these have the rights to use Microsoft non-profit subscriptions. In the case I’m referring to, it makes perfect sense to have a dedicated Office 365 tenant.

However, this is from a cloud perspective, in the on-premise site, all the federations are still in the same Active Directory, in one forest, divided into different OU’s.
Our third reason is that a global organization has some local legal specifications. It could be that users and/or services from one destination cannot be used from the same side as another local destination (country)
These three examples all have one thing in common: they require you to synchronize one AD Forest into multiple tenants. As per Microsoft’s requirements, only one AD object can be synchronized to one tenant at a time. Which we can execute by using Organization Unit (OU) segregation in Azure AD Connect which I’ll delve deeper into in this article.
Active Directory
The first step to fixing this request is preparing the on-premise Active Directory. At this stage, you don’t need to focus on the forest functional level, the requirements for this task can be found here. Instead, your focus should be on having a detailed concept of which OU needs to be synced to which tenant as this is required for the configuration of the Azure AD connect later. As I mentioned previously, the reason for this is that we’re only supported to synchronize one AD object (user, group) into one tenant at a time, so we have to the objects to satisfy this requirement.
In the next picture, I’ve provided an example of how our Active Directory structure should look:

Active Directory structure

In this example, you can see a part of the Contoso on-premises Active Directory, and also two Destination OU’s “Switzerland” and Austria”. Each of these OUs contains sub-OUs with Users, Groups, etc. Here, we want to sync Users and Groups from the OU “Switzerland” to Office 365 Tenant 1 and Users and Groups from the OU “Austria” to Tenant 2.
Option one: Password Hash Synchronization (PHS) or Pass-through Authentication (PTA)
The supported solutions available to us are either Password Hash Synchronization (PHS) or Pass-through Authentication (PTA). To use either of these, you need to configure Azure AD Connect (AAD) in that way, so both tenants and the local Active Directory can be served from AAD servers. Later in this article, you’ll see how to configure the sync part of the local Active Directory OUs for each tenant. In the picture below, I’ve demonstrated how the design should look:

Active Directory configuration

However, there is one very important point you must consider for this solution. If you use PHS or PTA, you’ll only be able to use SSO (seamless sign-on) for one of the two tenants. This means that you or the company must decide if Switzerland or Austria will be able to use SSO because whichever Destination OU SSO you don’t choose won’t be working. The reason behind this is the Kerberos Key exchange for the computer object AZUREADSSOACC can only be written for one tenant during the configuration of the SSO. However, if SSO is a must-have for both tenants, there is another solution to how this can be implemented.

Option two: PHS/PTA or Active Directory Federation Services (ADFS)

We discussed that there is an option to configure multiple Tenants with SSO on both sides. A supported solution for that request is to use it for one of the two sites PHS or PTA as described in the previous chapter, combined with SSO, and for the other Tenant an ADFS installation with or without PHS. This configuration structure will look like the picture below:

Option two: PHS/PTA or Active Directory Federation Services (ADFS)

In the solution shown in the above diagram, Contoso has decided to configure the tenant for the Destination OU “Switzerland” with PHS or PTA with SSO and the Destination OU “Austria” with ADFS.  In this case, Contoso can use SSO for both Tenants. The solution with ADFS needs a higher financial investment because you’ll need to install at least two ADFS and two Web Application Proxy (WAP) servers, two times load balancing, and certificates.

Of course, there is also a solution with DNS load balancing, but in this case, I want to show you the most foolproof solution because I don’t recommend DNS load balancing.

So, what do I mean by the “chance” being higher when using third-party services? Well, if you look at the two main OU’s in this article, I’ve written about “Destination OU’s”, however they can vary based on your scenario. For example, you could have one tenant for administration, office and back office materials, and the second tenant for trading.

Trading departments are known for needing at recurring intervals a very high calculation power. Using a third-party cloud solution would enable you to fulfill that need and it makes sense for the trading tenant to be configured the SSO with ADFS.

Exchange Online and Teams Implications

The two options we’ve discussed, PHS/PTA or ADFS, are the preferred solutions. However, there is a crucial point that we need to contemplate here. If the association in question uses Exchange Online, it will only be available for one of the tenants. Microsoft currently doesn’t have a solution to create an Exchange Hybrid to multiple Office 365 tenants. It also looks like there is a similar case with Microsoft Teams at the time of writing, the main difference here is if the association is using different namespaces, then all tenants are able to use Microsoft Teams.

Azure AD Connect

When you start the configuration of AAD, one of the first points during the Wizard is to choose the sign-in method for your Users. As you can see, the first three options are the ones, that I described in this article:

Azure AD Connect

To be more precise, if you choose PHS that means users can sign in to Microsoft cloud services, such as Office 365, using the same password as their on-premises network. The user’s passwords are synchronized to Azure AD as a password hash and authentication occurs in the cloud.

If you decide to use PTA, users can sign in to Microsoft’s cloud services, like Office 365, using the same password they use in their on-premises network. The user’s password is passed through to the on-premises Active Directory domain controller to be validated.

In this article, we’ve also discussed the third option using ADFS where users can sign in to Microsoft cloud services, such as Office 365, using the same password they use for their on-premises network. The users are redirected to their on-premises AD FS instance to sign in and authentication occurs on-premises. In this case, PHS can also be used in combination as a backup solution and for credential leakage detection in Azure AD Premium.

During the AAD configuration you will arrive at Domain and OU filtering, at this point you need to decide which OU’s need to be synced to which Tenant, which we described earlier in this article in the Active Directory section.

Source – Practical365

read more

Migrating Azure AD Connect to a New Server


For organizations that are using synchronized identities for Office 365, the directory synchronization tool of choice these days is Azure AD Connect. To keep AAD Connect running you may eventually have the need to move it to another server. There are a variety of scenarios where this need arises, for example migrating to a new server provides the opportunity to safely upgrade to a newer underlying operating system without the risk of a lengthy outage.

For this demonstration, I’ll be migrating Azure AD Connect from a Windows Server 2012 R2 server to a newly installed Windows Server 2016 server. The new server has been configured with an IP address on the network, joined to the domain, updated from Windows Update, and is ready to go. Although it is supported to migrate between AAD Connect instances that are not the exact same build, it is recommended to use the same build on both servers so that the same features and options are available on both instances. In my case, the latest available build is already running on the source server.

The steps to migrate Azure AD Connect to a new server are:

  1. Review the configuration of the existing Azure AD Connect instance
  2. Install the new Azure AD Connect instance in staging mode
  3. Compare configurations of the old and new servers
  4. Swtich-over synchronization to the new server
  5. Decommission the old server

Reviewing the Configuration of the Existing AAD Connect Instance

Ideally you will already have a documented configuration for your AAD Connect instance. If you don’t, then you can use the AADConnectConfigDocumenter tool from MIcrosoft to create a HTML document of your existing configuration. Download their latest release and follow the instructions to generate the report.

If you prefer something simpler to look at, open Azure Active Directory Connect on your existing server, and from the Tasks list select View current configuration. This won’t tell you absolutely everything about the server configuration, but it’s a start. You can also choose Customize synchronization options from the Tasks list to see things like the OU filtering that is configured.

Personally, I prefer the HTML report as it contains everything, it’s just a little harder to read.

Install the New AAD Connect Instance in Staging Mode

On the new server that will be hosting the AADConnect instance, download the latest build of the AADConnect installer and launch it to begin the installation process.

At the Express Settings dialog, choose Customize so that you can fully customize the AADConnect install.

As you step through the custom setup you’ll be able to choose the same configuration options as your existing AADConnect instance. At the final stage, check the box to enable staging mode.

Compare Configurations of the Old and New Servers

The AADConnectConfigDocumenter script can compare configuration information from two different AADConnect instances so that you can find any differences and correct them. The documentation explains how to do it, which I’ll briefly summarize here as well.

First, on the old server I run Get-ADSyncServerConfiguration to export the server’s configuration. I’m placing the export files in the \Data\ESPNET\S1DC1 folder (ESPNET is the NETBIOS name of my domain, and S1DC1 is the old server’s name).

Next, I copy the files to the new server, which is named AAD01, and run Get-ADSyncServerConfiguration again, this time placing the export files in the \Data\ESPNET\AAD01 folder.

Next, I edit the AzureADConnectSyncDocumenter.cmd file that is provided with the script, and supply the folder names of the two configurations that I want to compare.

Save the changes and run the file. It takes a few moments to analyze the data.

After the script has finished running, you’ll find the HTML report in the \Report folder. Open the report in a web browser and review it for any differences between the two configurations, which will be highlighted like the examples below.

Correct any configuration differences (other than obvious ones like staging mode being enabled/disabled), then you’ll be ready to switch-over synchronization duties to the new AADConnect instance.

Switch-Over Synchronization to the New AADConnect Server

Currently the demonstration environment has the following servers installed with AADConnect:

  • S1DC1 (old server) – Synchronization enabled, staging mode disabled
  • AAD01 (new server) – Synchronization enabled, staging mode enabled

While the two servers are in this state, the new server AAD01 will stay up to date with the latest changes in the on-premises Active Directory and Azure AD. However, it will not export any changes to the directories until staging mode is disabled. Before taking the new server out of staging mode, we first need to place the old server into staging mode so that we don’t have two servers trying to export changes to the directories.

During the switch-over, which is a pretty quick process, there’ll be no synchronization of changes between directories. This might mean a delay in the synchronization of a recent change that one of your administrators made (e.g. a group’s membership) or synchronization of a changed password. Keep in mind though that most changes have a synchronization delay anyway, since the sync schedule runs every 30 minutes. Password changes sync nearly instantaneous though, so that’s got a slightly higher risk of being impacted. To reduce the likelihood of the switch-over impacting someone or something important, you might prefer to schedule the change to occur during a period of low usage in your environment, such as an evening or weekend.

On the old server, launch Azure AD Connect and choose Configure, then from the Tasks list choose Configure staging mode. Click Next, and follow the wizard to authenticate and configure staging mode to be enabled. At the final step you can decide whether to keep synchronization enabled or not, depending on whether you think you might need to switch back to this server again (e.g. if the switch-over is only for DR, testing or site maintenance purposes).

On the new server, launch Azure AD Connect and choose Configure, and again from the Tasks list choose Configure staging mode. Follow the same wizard as before to disable staging mode on the new server, and make sure to start the synchronization process.

Decommission the Old AADConnect Server

When you’re satisfied that the new AADConnect instance is successfully synchronizing your directories, you can decommission the old instance of AADConnect if you no longer have a need for it. The uninstall process can be initiated from the Control Panel in Programs and Features.

When you start the uninstall of Microsoft Azure AD Connect you’ll be prompted to also remove the additional components that were installed on the server for AADConnect, such as SQL instance and the Microsoft Online Services Sign-In Assistant. You can remove them if you no longer have a need for them (e.g. the sign-on assistant is still needed by some PowerShell modules, so if you’re going to keep using the server for admin tasks or scripts, either leave that component alone or reinstall it afterwards).

After the uninstall has finished you can go ahead with any server decommission tasks you need to complete for your environment.

read more

Migrate Home Drives to OneDrive for Business


Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

One of the wins for Office 365 customers who have OneDrive for Business included in their licensing is to migrate users’ personal files to OneDrive.

For files that are stored in home drives on traditional file servers, the reduction in server and storage costs is a benefit. For other personal files stored on local computers, moving the files to OneDrive so that they are safely stored in the cloud is also a benefit.

Generally speaking, OneDrive for Business works well for:

  • “My documents” scenarios
  • Simple sharing of documents between small groups of collaborators
  • Storing data in the cloud where compliance and security can be enforced
  • Syncing files to mobile computers and devices for working offline or remotely

The OneDrive sync client can also synchronize files from SharePoint libraries for offline access to team files. So having it configure and ready to go is useful to end users who travel or work in places with poor connectivity.

In this article I’m going to demonstrate a simple migration scenario for migrating home drives to OneDrive for Business. For the purposes of this demonstration the environment consists of:

  • Office 365 E3 licensed users.
  • Office 2016 (via Office 365 ProPlus) client installations on Windows 10 computers.
  • The “Next Gen Sync Client” (NGSC), also generally referred to as OneDrive.exe, as opposed to the old Groove.exe sync client that has fewer features, slower performance, and less reliability.
  • User home drives located on a file server
  • Folder redirection for Documents and other well known folders to the home drives
Update, June 2018: Known folder moves for OneDrive are now available, starting with Targeted Release customers and rolling out to all customers over the coming months. This capability allows you to move known folders (Documents, Desktop, Pictures, etc)  from users’ computers to OneDrive without using the method demonstrated below.

Reviewing Home Drive Data

OneDrive for Business has some limitations for synchronizing files, which includes things like:

  • Invalid characters in file names (e.g. *, :, ?)
  • Specific strings of characters in file names (e.g. COM1)
  • Specific strings in folder names
  • Maximum of number of documents per library
  • 15GB file size limit
  • Files names or paths with more than 400 characters

Those limitations may change over time, so my list above could be out of date. You should always review the latest information on Microsoft’s support site. There’s a variety of other limits and user experience caveats to be aware of as well.

But for the file limitations, an analysis of the data your planning to migrate would be advisable. This could be as simple as a PowerShell script that recursively scans the file server to look for the issues above. If you qualify for FastTrack support from Microsoft, that service includes analysis and remediation as part of the process (and you can use them for the entire migration, so you don’t need to read this article at all if you don’t want to).

Reviewing OneDrive for Business Admin Settings

The OneDrive for Business Admin portal allows you to control a variety of settings for OneDrive users, such as whether they are able to share content external to the organization, sync with non-domain joined computers, how files can be used from mobile devices, DLP policies, and more. Before you proceed with your OneDrive migration, it’s worth reviewing the settings to make sure they align with your expectations and security policies.

For example, you might consider it necessary to disable sharing of SharePoint and OneDrive content with external users, or limit syncing of files to domain-joined computers only.

Configuring a Group Policy

OneDrive has a Group Policy template available from Microsoft. At one time the GPO template could be downloaded from Microsoft, but right now it is only available by navigating to the %localappdata%\Microsoft\OneDrive\BuildNumber\adm\ folder on a computer that has OneDrive installed. An up to date Windows 10 PC should be sufficient. It’s a bit awkward not being able to simply download the latest GPO directly from Microsoft. Perhaps in future they will add it back to the download center.

The OneDrive GPO can be used to set the default location for the OneDrive folder, among other useful settings. That particular setting, in combination with a standard folder redirection policy, is how I’ll be handling the migration in this environment.

The objective of the Group Policy is to:

  • Create an environment variable representing the OneDrive sync location, so that the variable can be used in the Group Policy folder redirection settings. I’ve used Microsoft’s guidance here. The variable in this example is set to “%userprofile%\OneDrive – Exchange Server Pro”, matching the default path that OneDrive will sync to on the local PC.
  • Create a new folder in the %OneDriveSync% location. This can be achieved with a Group Policy preference.
  • Preventing users from choosing a different OneDrive location on the user’s computer. In previous versions of the GPO template this requires editing the Group Policy template (ADMX file) in the Central Store with your tenant ID. Now the setting can be configured through the Group Policy Management console instead.
  • Apply a new folder redirection policy that directs Documents and other folders to the %OneDriveSync% location instead of the home drive on the file server (the policy will move existing files as well).

When you create a policy and look at the OneDrive settings, nothing is configured by default.

To prevent users from changing the location of their OneDrive, you need to know the tenant ID for your Office 365 tenant. To retrieve your tenant ID, connect to Azure AD with PowerShell and run the Get-AzureADTenantDetail cmdlet.

Once you have the tenant ID you can configure the GPO to prevent users changing the OneDrive sync location on their local PC. Add one or more tenant IDs, and set the value to 1 to prevent the sync location from being changed.

For this environment I’ve placed the OneDrive GPO as a higher priority than the existing folder redirection GPO. I’ve also scoped the OneDrive GPO only to members of the “OneDrive for Business Users” security group, and denied the “Apply” permission for the previous folder redirection GPO for the “OneDrive for Business Users” group. Note that after removing Authenticated Users from the scope of the new policy, you then need to go to the Delegation tab and delegate the “Read” permission for the GPO to Authenticated Users, or you may find it does not process at all.

So in effect this all means I can roll out OneDrive to users by adding them to that security group. There is also some end user communication involved in the whole process. You’ll want to make sure your users are expecting the change so there’s no surprises or confusion.

Something to be aware of is that the folder redirection will overwrite any existing data in the destination location that has the same file name and path. If any of your users have already begun using OneDrive and storing files, you should manually deal with those to avoid conflicts. You can find active OneDrive users in the usage reports in the Office 365 admin portal.

Configuring the OneDrive for Business Sync Client

After the GPO has applied, when the user signs in to OneDrive, it will begin syncing that existing data in the local path to the cloud. For environments without any SCCM or other systems in place to initiate a program running in the context of the user, a workaround is to email the user a link to odopen://, which will trigger the OneDrive client to launch. Since you likely want to send them some login instructions and other general adoption advice for OneDrive, you can simply bundle all that up into a single email.

When the user opens OneDrive they’ll be able to walk through the setup process. You should ensure that the instructions you provide are clear about what they should do at each step of the initial configuration wizard.

Monitoring the Deployment

The initial synchronization of files to OneDrive may have a detrimental impact on your network performance. Monitor your network utilization so that you don’t roll out too many users simultaneously.

You can continue to use the OneDrive usage reports in the Office 365 admin portal to track the adoption of OneDrive by your users.

It’s also possible to quickly pull a report of OneDrive usage by using PowerShell.


Completing the Migration

Once you’re satisfied that user home drives have been migrated to OneDrive for Business, you can do a scan of your file server to confirm that the home drives for users are empty, and then start decommissioning those shares so that the storage can be reclaimed. For any users who have not logged on and completed their migration you can manually assist them, or back up their home drive files elsewhere, or even upload the files to their OneDrive in the cloud yourself so that they’re waiting for initial sync to the client.

read more

PowerShell One-Liner: Summary of Mailbox Move Request Status


When you’ve got a lot of mailbox move requests running during an Exchange migration, it’s useful to be able to pull a quick summary of how they’re all going. You can achieve this by piping the Get-MoveRequest cmdlet to the Group-Object cmdlet.

read more

Methods for Migrating to Office 365


This article is an excerpt from the book “Office 365 for Exchange Professionals”.

Office 365 supports a variety of migration methods that customers can use. The choice of migration method can be influenced by a wide range of factors such as the number of objects involved in the migration, the amount of data to be moved to Office 365, the version of Exchange Server (if any) running on-premises, long-term migration or co-existence requirements, whether the organization uses non-Exchange email servers, and even the budget available to spend on the migration project.

The migration methods that are available are:

  • Cutover migration
  • Staged migration
  • Hybrid configuration
  • IMAP migration
  • Third party migration tools

The best place to start is with the business requirements of the migration project. The business requirements should include factors such as the need to complete the migration by a particular date, whether a back-out option for the migration needs to be included, or whether some email resources will remain on-premises. As you will see when you read through this chapter, each migration method has different benefits and constraints, and they may not all suit the business requirements of the project.

The next items to consider are the technical requirements, as they will often quickly eliminate some of the migration methods and allow the organization to zero in on the approaches that are actually possible for them to use. The diagram below provides an example of the decision making process you can work through based on your technical requirements to understand the available migration methods for your scenario.

Figure 3-1 Deciding what migration method to use

The decision making process begins by asking whether the on-premises environment runs Exchange Server 2003 or 2007. For those environments the next decision point is whether there are more than 2000 mailboxes. Organizations with fewer than 2000 mailboxes are supported for cutover, staged and hybrid migrations, whereas more than 2000 mailboxes are only supported for staged or hybrid migrations.

Real World: Although 2000 mailboxes is the threshold specified by Microsoft in terms of support for cutover migrations, it doesn’t mean that organizations with up to 2000 mailboxes should only consider a cutover migration. The logistics involved in handling an outage for a large number of users, as well as the desk-side support needed to assist with reconfiguring Outlook profiles and mobile devices after the cutover, may simply make a cutover migration too risky and complex for the organization. In fact, many experienced Office 365 consultants consider the practical limits of both the cutover and staged migration methods to be more like 150 mailboxes. Organizations larger than 150 mailboxes should give strong consideration to using a hybrid migration instead of a cutover or staged migration.

The 2000 mailbox limit doesn’t mean that organizations with less than 2000 mailboxes should automatically choose a cutover migration. For example, if the organization wants to migrate their users in smaller batches instead of one big batch then a cutover migration would not be suitable.

When cutover is either not possible or not desirable for an Exchange Server 2003/2007 organization the remaining options are staged and hybrid migrations. For an Exchange Server 2003 environment a migration to Exchange Server 2010 needs to be completed first. For an Exchange Server 2007 environment at least one Exchange Server 2010 or 2013 server must be installed in the organization to provide the hybrid functionality. Both options require directory synchronization to be implemented. Without directory synchronization, your migration options are limited to third party tools.

An organization running Exchange 2007 or higher can choose to take advantage of the free “Hybrid Edition” license available from Microsoft. This allows an Exchange Server 2013 or Exchange Server 2010 SP3 server to be deployed in the organization to host a hybrid connection with Office 365. The Hybrid Edition license can’t be used for a server that hosts mailboxes, but the server can be used during the migration to Office 365 and retained afterwards for managing the Exchange attributes of the on-premises Active Directory objects, and can also be used as an SMTP relay server for applications or devices on the corporate network.

If the implementation of a Hybrid Edition server is not possible, for example due to server capacity constraints, then a staged migration is the way forward.

The staged migration method is not available for organizations that run Exchange Server 2010 or 2013. The same 2000 mailbox support limit exists for cutover migrations, so smaller Exchange Server 2010/2013 environments can still choose to perform a cutover migration. However as we’ve already discussed, large cutover migration projects can be logistically very difficult to perform.

Given that Exchange Server 2010 and 2013 are both capable of hybrid configuration with Office 365 you should give strong consideration to hybrid instead of staged or cutover. Although this is the most complex of all of the migration options, it also delivers the best user experience. Hybrid configurations allow the on-premises Exchange organization and Office 365 to function as though they are the same environment with seamless mail flow, a shared address book and calendar free/busy federation. In fact, most users would not even be aware that they are working in a hybrid configuration with mailboxes deployed in both on-premises and Office 365. A hybrid configuration is also the only option that allows mailboxes to be off-boarded from Office 365 to Exchange on-premises without using third party migration tools.

Hybrid configurations rely on directory synchronization. If for some reason the organization can’t implement directory synchronization then the choices are limited to third party migration tools.

Finally, businesses using non-Exchange email platforms can’t use the cutover, staged or hybrid options. For those businesses Microsoft provides an IMAP migration option for moving mailboxes to Office 365, or alternatively a third party migration tool can be used.

As you can see, the decision making process requires careful consideration even just for the technical requirements. Beyond that there are also other factors such as whether the migration project will be handled in-house or by an external consultant, whether extra training is required for IT staff to understand new features such as hybrid configurations, and whether funding is available to pay for third party migration tools if native migration options can’t be used.

Note: Before you finalise your decision on which migration method to use it is strongly recommended that you read through the example migrations in this book from start to finish so that you can learn about any risks or timing issues that you need to be prepared for. Do not start a migration before you have read through the process from start to finish at least once. You should also consider creating a test environment and signing up for a separate Office 365 trial tenant so that you can perform a hands-on test run of your chosen migration method.

read more