Office 365: Run a script connected to 2 Exchange online sessions

Have you ever wondered how you can connect to 2 Exchange Online sessions, in the same PowerShell window?

For example, if you want to run a script that connects to 2 tenants, exports all mailbox permissions from one tenant and imports them into the other. Same thing applies to Distribution groups and memberships.

With the Microsoft Tenant 2 Tenant Migrations in high demand, and because there are so much that you might want to bring from one Exchange Online to the other, I thought I should write a quick blog article on how to connect and manage 2 Exchange Online tenants in one PowerShell window, ideal for scripting.

Before you look at the code below, let me outline two key parameters, of the Import-PSSession cmdlet to achieve your goal:

  • Prefix – Specifies a prefix to the nouns in the names of imported commands.
    Use this parameter to avoid name conflicts that might occur when different commands in the session have the same name.
    For instance, if you specify the prefix Remote and then import a Get-Date cmdlet, the cmdlet is known in the session as Get-RemoteDate, and it is not confused with the original Get-Date cmdlet.
  • AllowClobber – Indicates that this cmdlet imports the specified commands, even if they have the same names as commands in the current session.
    If you import a command with the same name as a command in the current session, the imported command hides or replaces the original commands. For more information, see about_Command_Precedence.
    By default, Import-PSSession does not import commands that have the same name as commands in the current session.

Note: Both the definitions above were taken from the Import-PSSession cmdlet official Microsoft article, that you can see by clicking here.

So how does this work actually? Have a look at the code below:


Date: October 4th 2017
 Version: 1

 This lines of code will connect 2 PowerShell Exchange Online sessions to 2 different tenants. 
 By opening 2 PowerShell sessions, using the PREFIX parameter for each one of those sessions it will allow you to manage both tenants at the same time (ideal for tasks where you want to migrate configurations from one tenant to the other)

### Input source and destination credentials

$SourceCred = Get-credential -message "Please Enter your SOURCE tenant credentials"

$DestCred = Get-credential -message "Please Enter your DESTINATION tenant credentials"

### Create Source EXO Session

$SourceSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -AllowRedirection -Authentication Basic -Credential $SourceCred

$result = Import-PSSession $SourceSession -prefix SRC -AllowClobber

### Create Destination EXO Session

$DestSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -AllowRedirection -Authentication Basic -Credential $DestCred

$result = Import-PSSession $DestSession -prefix DST -AllowClobber

### Run a get-mailbox to validate connection to both tenants

Write-Host "Listing mailboxes in the source tenant" -ForegroundColor Green

Start-Sleep -s 5

Get-SRCMailbox -resultsize unlimited |ft alias, *smtp*

Write-Host "Listing mailboxes in the destination tenant" -ForegroundColor Green

Start-Sleep -s 5

Get-DSTMailbox -resultsize unlimited |ft alias, *smtp*

### Showing a count of mailboxes in source and destination

Write-Host "Counting mailboxes in the source tenant" -ForegroundColor Green

Start-Sleep -s 5

(Get-SRCMailbox -resultsize unlimited).count

Write-Host "Counting mailboxes in the destination tenant" -ForegroundColor Green

Start-Sleep -s 5

(Get-DSTMailbox -resultsize unlimited).count


Write-Host "Your list of active PS Sessions" -ForegroundColor Green

Get-PSSession |fl

Some considerations of the code above:

  • There’s no logging or error handling in the code. The purpose of the code above is to provide you the insight on how to connect to 2 sessions with the same cmdlets.
  • The code is provided as is and you should test it before you run it in production.
  • The code includes blocks to perform the following:
    • Request input for source and destination credentials
    • Create the source Exchange Online session
    • Create the destination Exchange Online session
    • Code to demonstrate how to run cmdlets in the source and destination tenant (example with get-mailbox)
    • Code to list both PS Sessions created

Now lets see the output of the code:


Simple, right? Again this can be very useful for tenant to tenant migrations.


No Outlook 2007 in Exchange Online. Be prepared with BitTitan HealthCheck for O365

I just wrote yesterday a blog post about the dead of RPC over HTTP in Exchange Online, and how that terminates Outlook 2007 as a functioning version to connect to the cloud Exchange.

In that article I briefly talked about how you can use the Exchange PowerShell and mailbox audit logging to determine the version of Outlook your users have, but that has some limitations, such as:

  • If you’re moving to 365, from a non Exchange system, or one previous to Exchange 2010, you won’t have mailbox audit logging.
  • Mailbox Audit logging is off by default and in Exchange on premises systems that are very low on resources (hence the possible move to Exchange Online), it’s something that some Exchange administrators might be reluctant to turn on (although the truth is the load is minimal).
  • The report is extensive and includes all connectivity that each user did to Exchange. Identifying the computer with the outdated Outlook in some cases might be tricky (users that have roaming profiles and log into multiple computers).

So in summary, if you are assessing your users mail clients as part of a migration or if your users use multiple workstations, the approach above is not ideal.

That being said, the solution for you is the free BitTitan HealthCheck for Office 365 module, that is part of the BitTitan Device Management Agent software.

From a technical perspective, once the DMA agent is deployed (via email or automated process such as Group Policy), the HealthCheck for Azure module will run a full assessment to the machine. It will provide much more information than just Outlook, such as:

  • Operating System
  • Disk Space, CPU and memory
  • Internet download and upload speed
  • Device specifications
  • Browsers and Outlook versions

As you can see you’ll get a very complete report and it doesn’t require any license.

As a final note the Device Management Agent also has the DeploymentPro module, that you can use to automatically reconfigure the Outlook profile, as part of your migration.


Exchange Online: The end of RPC over HTTP

And that’s it, more than 3 years after Microsoft launched MAPI over HTTP (the replacement for RPC over HTTP – aka Outlook Anywhere), now it’s time to announce that in October 31st 2017 the RPC over HTTP feature will be deprecated in Office 365.

Some of my thoughts on this, and things you should consider..

How about Exchange On-Premises?

The deprecation of RPC over HTTP is announced just for Exchange Online. What does that mean to Exchange on premises deployments? Probably that in a future Cumulative Update the feature will be discontinued, but for now, all stays the same with on-premises.

When Microsoft launched Exchange 2016 they listed the RPC over HTTP feature as de-emphasized and not discontinued.  That basically meant that it still works and it’s still supported.

That doesn’t mean that this will always be the case, and with this announcement coming now to Exchange Online, maybe a new Exchange 2016 CU will remove the RPC over HTTP feature, or maybe this is just Microsoft not publishing the rpc virtual directory anymore, in Exchange Online. I guess that at some point we will find out, but for now all supported versions of Exchange also support RPC over HTTP in an on-premises deployment.

My personal opinion is that it won’t take long for RPC over HTTP to be also deprecated i

Check the matrix below for current connectivity supportability:

Product Exchange 2016 RTM Exchange 2013 SP1 Exchange 2013 RTM Exchange 2010 SP3
Outlook 2016 RTM
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2013 SP1
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2013 RTM Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2010 SP2 and updates KB2956191 and KB2965295 (April 14, 2015)
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2010 SP2 and earlier Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2007 Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere

Any versions of Outlook being affected?

The simple answer is yes. All versions will be affected. Outlook 2007 will stop working (remember Office 2007 is out of extended support), and all other versions need to be properly updated, to the minimum versions described on the table below:

Office version Update Build number
Office 2016 The December 8, 2015 update
  • Subscription: 16.0.6568.20xx
  • MSI: 16.0.4312.1001
Office 2013 Office 2013 Service Pack 1 (SP1) and the December 8, 2015 update 15.0.4779.1002
Office 2010 Office 2010 Service Pack 2 (SP2) and the December 8, 2015 update 14.0.7164.5002

Read the Microsoft article for more details on the above.

Why MAPI over HTTP?

Let me bullet point some main reasons:

  • Better connection resiliency
  • Additional secure sign-in scenarios (multi-factor authentication)
  • Better foundation for third-party identity providers
  • Less complexity as it doesn’t depend on RPC technology
  • With less complexity the Exchange team can innovate more quickly
  • Fits into today’s reality with clients connecting from all sorts of different networks

So in a nutshell, it’s more secure, more flexible and reliable in terms of connectivity, and it’s less complex.

For more information read this amazing blog post from the Exchange product team, around MAPI over HTTP.

What should an Exchange Online administrator start doing, right now?

Identify the Microsoft Outlook versions and builds that his users have and use to connect to Exchange Online.

How? Using the PowerShell is the best method. Here’s an example command that you can run:

Get-Mailbox | Search-MailboxAuditLog -LogonTypes owner -ShowDetails | ? { $_.ClientInfoString -like “*Outlook*” } | select MailboxOwnerUPN,Operation,LogonType,LastAccessed,ClientInfoString | export-csv .\OutlookConnections.csv

I will write a blog post soon with more details, screenshots and eventually a script to gather and export all if this information.


Google Suite to Office 365: Forwarding email address options

When migrating your email from Google Suite to Office 365, or simply having mail flow coexistence between the two systems, I am usually asked the same question: Which email domains can I use as forwarding addresses in Google, to forward email to Office 365?

The answer is not very straightforward, and first and foremost it’s important to understand that in Google, per user email forwarding can be done in two ways:

For more information you can check the Google Suite Forwarding options article.

Now lets cover both options and what domains can be used.

Forwarding domain options: User Level Routing

Basically, with this option, the administrator can select whatever domain he wants to be the forwarding address. A very common scenario is to choose the address, as the example below.


Above you can see the forwarding in the Google Admin portal, to the address The SMTP envelope will remain intact and no copy will be saved in the Google mailbox.


And the user primary SMTP address on Google.


The list of SMTP addresses in Office 365, for User10.


And the email sent to, that was forwarded to Office 365.


Finally a quick look at the email headers. Some considerations on that:

  • you can see that the email is initially received by Google, coming from Office 365 (the sender is from a completely independent 365 tenant)
  • You can then see that the email is forwarded to User10 in my Office 365 test tenant. You will see it’s received in 365, coming from Google.
  • Finally a quick note on the SPF failure. It’s a soft fail and one that you can’t control. What it basically says is that Google is not a permitted sender for the senders domain.


The summary of this method is that it has no limitations, but, the catch is, stamping forwarding addresses in the Google admin console is not something that you can automate, to make it scale, i.e there’s no good method (to the best of my knowledge) to stamp addresses in 1000+ users, which is a huge manual task.

Forwarding domain options: Forward email to another account via mailbox settings

The second option can be done by the end user, but can also be automated. With this option you’re a bit more limited in terms of what domain names you can use for forwarding. Why? Let me show you.


Above you can see a forwarding set, in the tab “Forwarding and POP/IMAP” of the mailbox settings. To set the forwarding all I needed to do was add a forwarding address and select the “Forward a copy…” option. But my forwarding above is done to the domain, which is a sub-domain of a domain that my Google tenant owns. What does that mean exactly? That Google knows for a fact that if I own the domain I also own the forwarding domain, and therefore does not ask me for any validation.

Makes sense? Now lets see when I try to forward to a domain that is not on Google, nor it’s a sub-domain of one that it is.


As you can see Google is going to send a confirmation code to the destination address, in order for you to prove ownership.


And the address won’t be available until you confirm it.

Now what’s the biggest problem with this? It doesn’t scale. Which means that with this method you will need to use the sub-domain method. Automation tools to add those addresses, like the GAM tool or the BitTitan SDK, won’t work in such scenario with those forwarding email domains.


This is by far my preferred method. The only drawback with this, in my opinion, is that administrators have no visibility to the forwarding configurations, via the UI. But they can export them via the GAM tool.

Bottom line

If you are planning to configure mail flow coexistence between Google and Office 365, I’d recommend that you create a sub-domain in Office 365 (i.e – must be valid in Google), don’t forget to add all DNS records such as MX and SPF, and use that sub-domain in your forwarding addresses.

If you want to automate the configuration (and you should), you can either use the GAM tool, or even much better, use the BitTitan Management Console, part of the BitTitan SDK that comes with an option to manage forwarding addresses on Google, and you won’t have to bother learning how to use the GAM tool, that believe me it’s not easy.

I will soon be writing a blog post on how to use the GAM tool to get a list of forwarding addresses from Google.

As always if you have questions let me know.

Office 365: How to scope impersonation when migrating to and from Exchange Online

When you’re migrating to or from a Microsoft Exchange system, using an awesome tool like the BitTitan MigrationWiz, that leverages the Exchange Web Services (EWS) for the migration, you have 2 main options for administrator access to the mailboxes you’re migrating to and/or from: Impersonation and Delegation.

The best option depends on if the Exchange server is the online version (Office 365 multi tenant) or on premises. For Exchange on premises you should use delegation and for Exchange Online you should use impersonation. Why? Because you can’t create throttling policies in Exchange Online and impersonation is much less subject to throttling, when compared with delegation.

It’s important to understand that impersonation will also be subject to throttling, just not as much as delegation. When you’re migrating with delegation, all actions are done on behalf of the admin account, as opposed to when you’re migrating with impersonation, where actions are made on behalf of the account that is being migrated and impersonated.

Now that we can all agree that impersonation is the best authentication method for Exchange multi tenant systems (by the way this also applies to hosted Exchange systems outside of Office 365, but setting up impersonation on those systems might be somethings Hosters won’t do, unless they scope it, which they usually don’t), lets discuss the topic of this post: How can you scope impersonation? What exactly does that mean? And when will this be useful?

The answer for the first question is that you can scope impersonation by using management scopes and management role assignments.

As for the second question, scoping the impersonation rights means basically that the admin account will only be able to impersonate the accounts you define within that scope filter.

Finally the third question: this is useful when, for security reasons, you (or someone from the security team of the source or destination tenant) don’t want the admin account, that will perform the migration, to have access to impersonate all users in the tenant. This is a very common scenario in mergers, acquisitions and divestitures, where the admin user doesn’t need access to users that are not part of the migration.

Now lets translate all of this into a step by step guide of what you need to do, in order to scope impersonation in your Office 365 tenant.

Step 1: Create a distribution group

There are many different ways to apply a filter into a scope, and limit a management role assignment such as Application Impersonation, to a specific scope. I will teach you a simple way: via group membership.

You can create the group via the 365 management console or via the PowerShell. I recommend that you create a simple group as shown below (apologies, my current Office 365 tenant is in Portuguese, but I guess you can all recognize and understand the UI 🙂 ):


TIP: If you create this group just for the purpose of scoping impersonation, I recommend that you hide the group from the Global address list.

Now that the group is created, lets retrieve its DistinguishedName property:

Get-DistributionGroup -Identity AllowImpersonationDistributionGroup |fl name, dist*


Note: In the command above use your own Distribution group name, as you created it, or just run the Get-DistributionGroup without specifying the identity, and grab the DistinguishedName from the correct group (all will be listed).

Step 2: Create a Management Scope

Create a new management scope, use the “RecipientRestrictionFilter” parameter and the “MemberOfGroup” filter:

New-ManagementScope RestrictedMigrationScope -RecipientRestrictionFilter {MemberOfGroup -eq ‘CN=AllowImpersonationDistributionGroup,,OU=Microsoft Exchange Hosted Organizations,DC=EU


Note: To run the command above you might need to enable the Organization customization in your Office 365 tenant.

Step 3: Create the Management Role Assignment

Now that we have the scope created the last step is to create the management role assignment and associate it with the admin migration account:

New-ManagementRoleAssignment -Name:MyMigration -Role:ApplicationImpersonation -User:user10@ -CustomRecipientWriteScope:RestrictedMigrationScope


Note: In the command above use the scope name and the admin account that you are using for the migration. For my migration the admin is

And that is it, job done. Lets do some testing.

Below you can see users 1 to 5, that I will be migrating, and user10 that I will use as an admin.


Now looking at the group membership you can see that only user1, user3 and user5 are withing the scope, which means that user10 won’t be able to impersonate users 2 and 4.


Finally the result in MigrationWiz, in a project configured to use impersonation and with user10 as the source admin.


As you can see above, users 2 and 4 failed, and here’s the detailed error.


Bingo… MigrationWiz failed to impersonate at the source. Of course now that you read this that error will never happen to you!! 🙂

Happy migrations and as usual if you have any questions let me know.


Public Folders to Office 365 groups, anyone?

Just recently, the Microsoft Exchange Team reached out to the public again asking if partners or customers out there are interested in moving from the well known ancient Exchange Public Folders (and yes they can be modern or legacy) to the new Office 365 groups.

In the Microsoft Exchange Team Blog they state that the main focus will for now be to migrate mail and calendar items, but they do leave the “door open” to future support to be extended to other item types. How awesome would it be to convert Public Folder posts into OneNote in the Office 365 groups, right? 🙂

As a final note, they also state that, this will be focused in source Public Folders that can be on-premises or in Office 365.

Now before we look at all migration (and in some cases conversion) options, lets look at all the item types that you can have in when you create a Public Folder:

  • Mail and Post
  • Calendar
  • Contact
  • Note
  • Tasks
  • Journal
  • InfoPath forms
  • Documents

So what can you move to Office 365 groups and how? Ideally you would migrate mails and calendars into the Office 365 group mailbox, documents into the Office 365 group document library and Posts into OneNote. That I’d say would cover a huge percentage of the Public Folder usage we have out there today, don’t you agree? Hopefully if you’re reading this post, and thinking on doing the conversion from Public Folders to Office 365 groups, the Public Folder usage of your organization is focused in mail, calendars, contacts, posts and documents.

So now your question might be: is there any option out there that can migrate at least part of this content, from Public folders to Office 365 groups? And the answer is YES!

BitTitan MigrationWiz will help you do the following migrate from Public Folders (Exchange 2007+ on premises or Exchange Online) into Office 365 groups. Not all content will be moved, due to limitations in the EWS API, currently used by MigrationWiz to migrate Public Folders as a source, but here’s what you should expect:

  • Emails get migrated from mail enabled Public Folders into the Office 365 group mailbox. They will show in the conversation section.
  • Posts get migrated from Public Folders into the Office 365 group mailbox (attachments included). They will show in the conversation section.
  • Calendar items get migrated from the Public Folder calendar into the Office 365 group mailbox calendar.
  • Office 365 groups do not have a way of showing shared contacts and tasks, therefore you should not try and migrate them.
  • Documents do not get migrated from Public Folders to the Office 365 group SharePoint library.

Migrating data between different systems (Public Folders vs Office 365 groups) is not all about the question “Can the data be migrated or not?”. A good example is what I highlighted above about the tasks and contacts, why?

  1. MigrationWiz can migrate the tasks and the contacts
  2. The tasks and the contacts, after being migrated, will show up in the statistics of the mailbox (that you can extract via PowerShell)
  3. The design of the Office 365 groups won’t allow your users to see those tasks and contacts in any of the clients where you can use to access the groups
  4. That makes migrating contacts and tasks a pointless exercise

Finally some high level tasks on how to perform the migration:

  1. Create MigrationWiz Public Folder project
  2. Edit the advanced options a change the destination to shared mailbox
  3. add in the advanced support options: RemoveFilterBasedOnFolderType=1
  4. Add one line item per item type: One for email and one for calendars
  5. Add folder mapping to each line item to map the items into the correct folder in the destination (i.e FolderMapping=”^.*$->Calendar”)

Like stated in the disclaimer below, BitTitan does not have currently a migration guide for this scenario. If you want more detailed steps please leave a comment and I will reach out.

Disclaimer: To migrate from Public Folders to Office 365 groups I used the BitTitan feature of migration from Public Folders to Shared mailboxes. Technically an Office 365 group has a mailbox in many ways similar to a shared mailbox, but with some differences.

BitTitan does not have a migration guide nor it states (at the day and time that this blog was written) that it supports the migration from Public Folders to Office 365 groups.

This blog post was written after careful testing and verification and the migration worked without any issues. If you are interested in using MigrationWiz to migrate from Public Folders to Office 365 groups I highly recommend that you contact BitTitan and engage in a POC (proof of concept).

As always, any comments are welcomed and let me know how that migration went.

Office 365: Script to export to CSV mailboxes without the smtp address

Just recently and when helping drive a Google Suite to Office 365 e-mail migration, I was faced with a problem that affected my mail routing capabilities between the 2 systems: Not all mailboxes in Office 365 had the domain.

Now that can be a problem, specifically because in many coexistence scenarios (including the one I mentioned above), that “” or the “” address is used as the forwarding address on the e-mail system coexisting with Office 365.

Here are a couple of articles describing cases where the service or mail routing domain were missing:

“Target mailbox doesn’t have an SMTP proxy matching ‘'” error when you try to move mailboxes to Exchange Online disappeared

The main problem in this cases is that you can find that some users don’t have that address, as an additional smtp address, the hard way, which basically is getting an NDR on the source system when it tries to forward that email to Office 365. So to be on the safe side, and because this happened to me a few times, I decided to create a script that identifies all users that don’t have an address from a specific email domain.

Some bullet point instructions for the script:

  • you can download the script here
  • The file you downloaded contains 2 scripts: Export-UsersNoOnMicrosoftAddress.ps1 and Log_Functions.ps1. Copy both into the same folder
  • Open a PowerShell window and run .\Export-UsersNoOnMicrosoftAddress.ps1
  • The script will prompt you to enter your Office 365 credentials
  • The script will prompt you for an email domain (i.e
  • All users that don’t have an address with that email domain will be exported to a file called UsersNoOnmicrosoftAddress.csv located in the same folder
  • A log file called ExportUsersOnmicrosoft.log is also created in the same folder, where you can check for any errors after running the script

See screenshot below with the output of the script on the console:


Of course that, if you look at the code, you will easily realize that the script can export users that don’t have an address from any domain you chose. That being said use it as you see fit. To me it helped me a lot on detecting the users with the problem described above.

Just a quick note before I finish this post: there are 2 reasons for this script not to fix the problem, adding those addresses:

  1. AD Connect: blocks you from adding the addresses directly in 365, meaning you will need to resolve the problem on premises and force a sync of the new addresses to 365
  2. Email address policies: it’s ultimately the best way of resolving email address problems in bulk, so that’s the route you so use

As always if you have any questions let me know. Enjoy.

Office 365: Some quick notes on the end of support for Dirsync and Azure AD Sync

Earlier this week Microsoft announced the end of support for the legacy Microsoft Dirsync and Microsoft Azure AD Sync tools. Millions of customers out there use one of those two tools, or the new Microsoft Azure AD Connect, to sync their users, groups, passwords, etc, from their On-Premises Active Directory to the Azure AD.

After quite a few name changes, it looks like the Azure AD Connect major version is here to stay, and now it’s time to end support to the two older major versions, and make sure that all of them are updated and replaced with the AD Connect.

If you haven’t done it already, it’s time to read the Microsoft announcement, and to start planning that upgrade.

Now let’s take the key points of the Microsoft announcement:

  • In April 13th 2016 Microsoft announced the deprecation of both Dirsync and Azure AD Sync
  • The end of support for both versions of the sync tool was planned to be April 13th 2017. That date is now official with the announcement this week and in that day the official support to those tools is gone
  • Azure AD will stop accepting connections from both tools in December 31st 2017

The most relevant thing to take into account is that, either you upgrade those instances, or they will stop working by the end of this year.

Now that you are probably more than convinced to update your instance(s) for your customers or your infrastructure, let’s bullet point some thoughts to have into account when planning the upgrade:

  • Make sure you read the official Microsoft document to upgrade Dirsync to Azure AD Connect
  • Or make sure you read the official Microsoft document to upgrade Azure AD Sync to Azure AD Connect
  • You can only do in place upgrade from Azure AD Sync to AD Connect or from an old to a more recent version of AD Connect. In place upgrades from Dirsync are not supported
  • Microsoft describes the migration done with a parallel server, to replace the existing, as “Swing migration”
  • On a standard Dirsync or AD Sync instance, there’s nothing that you need to backup and restore in the new version. The new Azure AD Connect instance will do a fresh full sync after the installation. That full sync will bring all data from the local and the Azure AD. Replacing a Dirsync or an AD Sync instance should not require restoring data
  • The only exception to the above statement is when you have some type of filtering. Filtering can be done at the AD OU, Domain or attribute level. In those cases you need to make sure you replicate the filtering you have in place, into the new instance.
  • To learn more about Dirsync filtering click here.
  • To learn more about AD Sync and AD Connect filtering click here.
  • If you are not doing an in place upgrade, you need to be aware that the “downtime” on your sync instance has impact in creating new account and replicating changes to the existing ones (that includes password changes, if you have password sync enabled)

And that’s it. As simple as that. Start downloading the AD Connect version and it’s upgrade time! 🙂

Let me know if you have questions.

Office 365: Outbound conditional (per source domain) mail flow routing

Imagine this scenario: You have an anti-spam appliance in front of your Office 365 tenant, and you want outbound mail flow from your tenant to go via that appliance, but depending on what the email domain of the sender is. For example you have and as two vanity domains in Office 365, and you want outbound email to go via the mail appliance, but outbound email to go direct to the Internet.

The scenario above requires conditional routing, meaning the outbound mail flow path will be different depending on what the email domain of the source user (the sender) is. The example above is just one of several that might lead you to apply such configuration.

Now the important part: How do you configure it? Well, you can do it via PowerShell or via the UI, and to do the configuration you will need the following:

  • A Transport Rule
  • An Outbound Connector

Create the Outbound Connector

The first thing you need to create is the Outbound connector.

Via Exchange Online PowerShell

To create the connector via the PowerShell, connect to Exchange Online and run the following:

New-OutboundConnector -Name “To Internet Direct” -ConnectorType Partner -UseMXRecord $true -IsTransportRuleScoped $true

The command above creates a connector that goes directly to the Internet and it’s scoped to the transport rule we will create next. If you want to create a connector that goes via an appliance run the following:

New-OutboundConnector -Name “To Internet via Appliance” -ConnectorType Partner -UseMXRecord $false -SmartHosts <Appliance IP> -IsTransportRuleScoped $true

Via the Exchange Online Admin Center

Navigate to Mail Flow > Connectors and click “+”


Select Office 365 as source and Partner Organization as destination


Enter a name and description


Select “Only when I have a transport rule set up that redirects messages to this”


Select “Use MX Record” or “route email through these smart hosts” depending on if you want the email to go direct or via an appliance/smart host


Remove the always use TLS selection, unless the appliance or server your sending the email to is configured to use TLS


Confirm the settings and click next


Validate the connector and save

Create the transport rule

Once you have the outbound connector created, you can now create the transport rule.

Via Exchange Online PowerShell

To create the transport rule via the PowerShell, connect to Exchange Online and run the following:

New-TransportRule -Name “UseAppliance” -SenderDomain <Source Domain> -SentToScope NotInOrganization -RouteMessageOutboundConnector “To Internet Via Appliance”

The command above creates a transport rule, that uses the “To Internet Via appliance outbound connector, and that applies when the source domain is specific and the destination recipient is outside of the organization (very important setting).

Via the Exchange Online Admin Center

Navigate to Mail Flow > Rules and click “+ Create a New rule”


Click on more options

Give the rule a name

In the Conditions select “Apply this rule if..” > The recipient is located > Outside of the Organization

Click in Add Condition

Select “Apply this rule if..” > The Sender > Domain is > Enter the domain name of the source user

In the “Do the Following…” section select “Redirect the message to..” > The following connector. Select the outbound connector from the drop down list

Make sure the enforce rule option is selected


Now that you have both the transport rule and the outbound connector created, lets test and see if it’s being applied.

Test the routing

The first thing you should do is simple: Send an outbound email from the user that should have conditional routing applied to his domain. Make sure the email is to an external recipient.

Once you sent the email, in the Exchange Admin Center go to Mail flow > Message trace, select the sender you want to trace the message for and click on “search”


Note: It might take a few minutes after you sent the message before it shows in the message trace

Once you can see the message there, double click on it to see the details


In the details you can see if the transport rule was applied and the transport rule name


You will also be able to see if the message was delivered, is pending or has failed. This is key for you to troubleshoot the mail flow and see if the correct rules are applied and the correct outbound connectors are being used.

And that’s it. Job done! As always if you have questions let me know.

Understanding the admin authentication options when using the EWS API in your migration project

One of the major concerns of the consultant or the project manager, on a migration project, is how long will it take to migrate the mailboxes, and what timelines can they define as reasonable for the migration (or the migration batch) to be finished.

Having that in mind, the conversation around it needs to focus on two major factors:

  • What authentication method should we use
  • How can we minimize (or avoid) throttling

So let’s start by talking about the authentication method.

What are the available authentication methods?

Bittitan MigrationWiz, which of course leverages the Exchange Web Services (EWS) as the API to migrate to and from Exchange 2010+, allows you to use two type of admin authentication methods:

  • Delegation
  • Impersonation

Note: MigrationWiz also allows non admin authentication methods, which we will not discuss on this blog post.

What is delegation and how do I configure it?

Delegation is the authentication method in which the entire migration will be done from the calling account (admin account), that needs to have full access to all of the mailboxes that are being migrated. The requirements for delegation are:

  • admin account needs to be mailbox enabled
  • full access is required to all of the mailboxes being migrated (explicit permissions)
  • a throttling policy should be created and associated with the admin account

In the Bittitan community website you will be able to find instructions on how to configure delegation on the source and target Exchange systems. You can also find there how to create the throttling policy.

By default the MigrationWiz project will try and use delegation, so there’s no other change needed.

What is impersonation and how do I configure it?

Impersonation is the authentication method in which the migration will be done on behalf of the user account, that is being impersonated by the calling account (admin account). For this to happen the admin account needs to be granted rights to impersonate the user accounts being migrated. the requirements for impersonation are:

  • the admin account does not need a mailbox
  • impersonation rights need to be granted to the admin account, over all of the users being migrated
  • a throttling policy is not required but highly recommended

In the Bittitan community website, you will also find instructions on how to configure impersonation on the source and target Exchange systems. The instructions to create the throttling policy are the same you can find on the section above.

The default behavior from MigrationWiz is not to use impersonation, so please make sure you follow the MigrationWiz steps of the article above, to configure impersonation at the project level.

Should I use Delegation or Impersonation?

Now that I described what is Delegation and what is Impersonation, let’s discuss which one should you use for each scenario.

In my professional opinion, that I will detail below and explain why, this is what you should do:

  • If the Exchange system is Exchange Online (Office 365) use Impersonation
  • If the Exchange system is Hosted Exchange (online but not in Office 365) use Delegation
  • If the Exchange system is on premises use Delegation

So now let’s break it down per system.

Exchange Online (Office 365)

The main reason that you should use Impersonation when authenticating against Exchange Online is simple: You cannot create a throttling policy in Office 365 and impersonation is less subject to throttling than delegation. 

I don’t think I need to explain why you can’t create a throttling policy in Office 365, but why is impersonation less subject to throttling? Well the explanation is logic: The subscriptions will be charged against the throttling budget of the target mailbox and not the calling account (admin account), which in other words means that the admin account is doing the migration impersonating each target account and the throttling is being charged to the target accounts, making the limits much more flexible and the migration faster.

Another good thing about Exchange Online is that when you set the impersonation rights, you are of course setting them within the boundaries of your tenant, which is not necessarily true for hosted Exchange systems, as you’ll see below.

Hosted Exchange (not in Office 365)

Now when we look at a hosted Exchange and what admin authentication methods we can have, the main thing you need to keep in mind is that, we will have what the Hoster is willing to configure. And what might that be? Short answer will be Delegation.

Don’t get me wrong, if you manage to get a Hoster (or if you are part of a Hoster Exchange management team and you’re also driving the migration) to either create a throttling policy or configure impersonation associated with a management scope, then what I recommend is:

  1. If you can create a throttling policy then use Delegation and associate that throttling policy to the admin account
  2. If you can’t create a throttling policy but you can enable impersonation with a scope (explanation below) than enable and use Impersonation
  3. If none of the above is possible, then use Delegation

Note: when you set impersonation, if you don’t use a management scope, that will allow the admin account to impersonate any account on that hosted Exchange. That might (and should) be considered a security breach by the Hoster and therefore not possible to configure. Although possible, many Hosters might not be willing to configure impersonation with a management scope, or configure impersonation at all.

On Premises Exchange

Finally when the system is on premises Exchange, you will be able to do all necessary tasks, so why use delegation?

To be able to reach maximum speeds you will still have to create a throttling policy (if you can), so between impersonating and using delegation I do think that delegation and a throttling policy is the best way to go.

Remember when I said “Impersonation is the authentication method in which the migration will be done on behalf of the user account, that is being impersonated by the calling account (admin account).”? Well that’s not 100% true in all cases. Depending on your Exchange version, the subscription might be charged to the calling account, which in essence makes impersonation as effective as delegation in terms of throttling. See the table below:

Exchange version EWSMaxSubscriptions throttling budget accounting
Exchange Online Charged against the target mailbox.
Exchange 2013 Charged against the target mailbox.
Exchange 2010 SP3 Charged against the target mailbox.
Exchange 2010 SP2 Charged against the calling account. Starting with Exchange 2010 SP2 RU4, the budget is charged against the target mailbox.
Exchange 2010 SP1 Charged against the calling account.
Exchange 2010 Charged against the calling account.

Source: EWS throttling in Exchange

From the above table you will see that if you have an Exchange system older than Exchange 2010 SP2 RU4, impersonation and delegation will have the same impact from the throttling perspective. We know that Exchange Online does have a version newer than the one just mentioned, but that is not necessarily true for Hosted Exchange or Exchange On Premises, so have that in mind when planning the authentication methods.

So let me outline the reasons that should make you choose delegation when migrating from an on premises Exchange:

  • the speed of the migration will be highly dependent on the throttling policy, that you can and should create, as well as monitor the Exchange performance during the migration
  • Implementing delegation is easier, specially in cases where you want the admin account to just have rights over a subset of the mailboxes. It’s much easier to just give full access to some mailboxes when compared to give impersonation rights to just some users
  • the way throttling reacts when using impersonation and delegation is different. In my opinion when using impersonation you’re more likely face ErrorServerBusy errors (if you go over the limit of concurrent migrations) and that causes normally more migrations to fail. When using delegation the failures are more likely to happen on the accounts that caused the admin account to over the maximum subscriptions allowed

I know that the explanation above might be a little confusing, specially the last bullet point, but I do highly recommend that you read the EWS throttling in Exchange article, and if you have another idea on what method to use feel free to share it.

I do think that impersonation makes sense only on those scenarios where you cannot fully implement proper delegation, with throttling policies and processes defined to monitor the Exchange server resources during the migration window.

Some useful articles around this subject

The importance of EWS impersonation while using an application account: you will can read the author outline how impersonation is better from an application perspective, and delegation is more oriented towards user access. I also mentions that user access can be controlled and revoked by the end user, which can be true. But on a migration project MigrationWiz will use user access to get into the mailbox and move the data to a destination mailbox, which is exactly what delegation provides you. He also outlines how less complex and global the impersonation setting can be, which is true, but on a project when you only need to migrate a subset of the mailboxes, and where you don’t want to give global access, impersonation will be significantly more complex. In essence this article is a good read that outlines the positives of impersonation and why it’s a good option for application level access and not user level access.

Impersonation and EWS in Exchange: This is an excellent article and a must read, that details how application level impersonation works in Exchange.

So what is the bottom line? At the end of the day it’s still your decision of whether to use delegation or impersonation. I’d say that for some scenarios like Office 365, the decision is a no-brainer (impersonation of course), and in some other scenarios it will depend on what can you configure and what is the simpler and more effective configuration.

Like I stated above I am always more inclined to decide for delegation against Exchange on premises and hosted Exchange, and impersonation against Office 365.

As always I hope this article is helpful, and feel free to share your thoughts.