While having Public Folder access in 365 set as remote in the Organization Config, point some users to the Exchange Online Public Folders

Some key things you should have in mind, when you’re moving your Exchange Organization from On Premises to Office 365, and Public Folders are in scope:

  • Before moving the Public Folders to Exchange Online, you need to move all of your users (at least you should move all of the ones that require Public Folder access). Users in Exchange On Premises cannot access Public Folders in Exchange Online.
  • You need to follow the Microsoft Official guidance to configure legacy on premises Public Folders under a hybrid deployment.
  • You can (and should in some scenarios) point some mailboxes to the online Public Folders and that’s what this blog post is all about

Now lets look at how a Hybrid Public Folder Organization Config looks like:

PFOrg1

As you can see above, the Public Folders in 365 are configured as remote (step 5 in the guide mentioned above), and an on premises public folder mailbox is defined as their mailbox (created in step 2 of the guide).

What this does is very simple: at the mailbox level, for each mailbox, it will set the parameter “EffectivePublicFolderMailbox” to the mailbox “OnPremPFMBX”, which is a synced mailbox object from on premises, as you can see below:

PFOrg2

And how do we change this, per user?

The answer is simple, you run a set-mailbox cmdlet, to one or multiple users, and you define the -defaultpublicfoldermailbox parameter, to a 365 Public Folder mailbox, that you of course need to have created before hand.

set-mailbox <Mailbox> -DefaultPublicFolderMailbox 365PFMBX

The command above is what you need to run, and you can adapt if to multiple users. Let me know if you need help with that.

Before closing this blog post lets just discuss one last thing: creating the Office 365 Public Folder mailbox.

A Public folder mailbox created under a Hybrid scenario, where public folder access is set to remote, will be set by default to a HoldForMigration state. Follow this excellent BitTitan article to understand why and resolve that issue. You need to resolve it before you can create new public folders in Exchange Online.

And while doing that don’t forget that, the best tool out there to migrate your Public Folders is the BitTitan MigrationWiz tool, so while you’re in our help center go ahead and read our migration guides and ask for a quote from our sales team.

Advertisements

[Updated Version] Office 365: Script to bulk change the UserPrincipalName to match the Email Address

As I was seeing a lot of feedback in my original post, regarding how the scripts below had issues, I decided to post this new updated version. I will underline the updates  to be easier to follow, but if you never read the original post, please try not to skip any parts in this one.

When you are preparing your local Active Directory, to be synced with Office 365, one of the things you should consider is to make the UserPrincipalName of each user you are syncing to match the user’s email address. Why? Because that is going to be his UserPrincipalName and his primary SMTP address on Office 365.

So there are different ways of achieving this, some more manual than others. The procedure I am going to outline today on this blog post is a two step procedure:

Step 1: Export all UserPrincipalNames and Email Addresses from the local AD to a CSV File.

Step 2: Use that CSV file to bulk change the UserPrincipalNames to match those Email Addresses.

Like I said there are different ways of doing this, and I will probably develop a more elaborated script that can do this in a single step. The reason I went for this two step process is because most of the times customers want to check the CSV generated on step 1, and remove all the users that they don’t want to change the UPN, because those users will not be synced to Office 365.

Before we detail the steps above, make sure that you’ve added additional UPN domain suffixes for all the primary SMTP domains that you will have. See the article “How to add UPN suffixes to a forest” for more information.

Also have a detailed read on the article “Prepare to provision users through Directory Synchronization to Office 365”, to fully understand all the tasks you have to do to prepare your local Active Directory.

Making the UPN’s match the email addresses and have a domain that is validated on Office 365 is just one of the several tasks you have to do.

Now back to the two step process to change those UPN’s.

Step 1:

On step one all you have to do is open a PowerShell module on your local AD, and run the cmdlet below.

#If needed Import the Active Directory Module into your PowerShell session before you run the cmdlet

Import-Module ActiveDirectory

#Run the cmdlet to export all the users to a CSV. Change the CSV name and path as appropriate

Get-AdUser -Filter * -Properties UserPrincipalName, Name, EmailAddress | ? {$_.UserPrincipalName -notlike "DiscoverySearchMailbox*" -and $_.UserPrincipalName -notlike "HealthMailbox*" -and $_.UserPrincipalName -notlike "SystemMailbox*" -and $_.UserPrincipalName -ne $null} | Select-Object UserPrincipalName, Name, EmailAddress | Export-CSV -Path C:\MyADUsers.csv -NoTypeInformation
UPDATE: I’ve added some additional filtering in this cmdlet, specifically to filter out users that don’t have a UserPrincipalName, or users for some types of Exchange system mailboxes such as the discovery search or health mailboxes. You do not want to run the script to change UPNs for system users or any user which is not a regular user that will be syncing up to Office 365. Make sure you filter the output file appropriately before you use it to change the UPNs. Below some example of users that you might still need to filter out from the output CSV.
UPNUpdate1

After you run the cmdlet you should get a CSV like the one shown below:

ChangeUPN1

On the example above you can see that the UserPrincipalName does not match the user’s email address, and therefore needs to be changed.

Once you get the CSV check all users that you want to change and remove from that CSV the ones that you don’t.

Step 2:

Now that you have the CSV with all the users you want to change, all you have to do on step 2 is run the script below. The script will change all the UPN’s to match the email address, based on the CSV file you will use.

#Script to Change the UPN on the Active Directory

#This script should run from an Active Directory Module for Windows PowerShell

#Version 2.0 - 06/22/2018

#Author: Antonio Vargas - antonio.vargas@myexchangeltd.co.uk

#Disclaimer: All scripts and other powershell references on this blog are offered "as is" with no warranty. While these scripts are tested and working in my environment, it is recommended that you test these scripts in a test environment before using in your production environment.

#Import the AD Module

Import-Module ActiveDirectory

#Static properties (change where needed)

$CSVPath = "C:\MyADUsers.csv"

#Count variables

$usersprocessed = 0

$userswitherrors = 0

$usersskipped = 0

#Import CSV

Try {

$CSV=Import-Csv-Path $CSVPath-ErrorAction Stop

}

Catch {

Write-Host"ERROR: Cannot import the CSV file. The script will abort. '$($Error[0].Exception.Message)'"-foregroundcolor Red

Exit

}

Write-Host "INFORMATION: The CSV was imported and you have '$($CSV.count)' users to be processed." -foregroundcolor Green

ForEach ($line in $CSV) {

$UPN=$line.UserPrincipalName

$Email=$line.EmailAddress

if($UPN-eq$Email) {

Write-host"SKIPPING: The UPN '$($UPN)' matches the email address"-foregroundcolor Yellow

$usersskipped++

}

Else {

try {

$ADUser=Get-ADUser-Filter {UserPrincipalName -eq$UPN-and Enabled -eq$true} -ErrorAction Stop

If($ADUser-eq$null) {

write-host"SKIPPING: The user '$($UPN)' is disabled or cannot be found."-foregroundcolor Yellow

$usersskipped++

}

Else {

Write-Host"Working on User '$($AdUser.UserPrincipalName)'"-foregroundcolor Yellow

try {

$result=Set-ADUser-Identity $ADUser.SamAccountName-Userprincipalname $Email-ErrorAction Stop

$usersprocessed++

Write-Host"SUCCESS: UPN Changed from '$($AdUser.UserPrincipalName)' to '$($Email)'."-foregroundcolor Green

}

catch {

Write-Host"ERROR: Cannot change the UPN of the user '$($AdUser.UserPrincipalName)'. '$($Error[0].Exception.Message)'."-foregroundcolor Red

$userswitherrors++

}

}

}

Catch {

Write-Host"ERROR: Cannot retrieve user '$($UPN)'. '$($Error[0].Exception.Message)'."-foregroundcolor Red

$userswitherrors++

}

}

}

write-host "`n"

write-host "############################# REPORTS ####################################" -foregroundcolor Green

Write-Host "REPORT: Total number of users processed with success '$($usersprocessed)'" -foregroundcolor Green

Write-Host "REPORT: Total number of users that were skipped for not meeting the criteria '$($usersskipped)'" -foregroundcolor Yellow

Write-Host "REPORT: Total number of users that failed to process '$($userswitherrors)'" -foregroundcolor Red

Copy the entire content above into a notepad, and save it as a .ps1 file.

Some changes done to the script from the original blog post:

  • Error handling added
  • the script imports the Active Directory module
  • added count for users done with success, skipped or failed
  • small report at the end
  • the entire logic of the code on when to process users was changed 

Disclaimer: All scripts and other PowerShell references on this blog are offered “as is” with no warranty. While these scripts are tested and working in my environment, it is recommended that you test these scripts in a test environment before using in your production environment.

I highly recommend running the script first against a small group of up to 5 users, and then make sure that the changes were applied successfully. Also you need to take into account that you are changing the UserPrincipalName of the user on your local Active Directory, so make sure to test the access to all internal systems that rely on AD for authentication, before you replicate the change to all of your users.

For large environments, if you want a version of the script that exports to CSV all the user results (i.e changed, skipped, failed) feel free to send me an email via the blog.

Go ahead and test the script with its new changes and let me know how that goes.

As always, if you have any questions please let me know.

Exchange Public Folders: Export item count, per item type, of your public folder structure

Just recently, I was asked to help investigate which Exchange cmdlets would help a partner the I work with, do an item count in an on premises Exchange Public folder structure. Their specific ask was to get, per folder, the number of contact items.

So starting with the best command to do this, it’s easy to get to the conclusion that it will be the Get-PublicFolderItemStatistics, and the first thing that you need to know about that cmdlet is that it’s only available in Exchange 2010+.

The second thing you need to focus on is, in which folders do you want to run the count on? All of them? And if not all, do you want to run the count based on folder type? i.e do you want to just count calendar items on folders of type calendar? How can we achieve this?

Lets break this down:

  • To be able to select the folders you want to count the items for, you need of course to start with the Get-PublicFolder cmdlet
  • If you want to filter just one or multiple folder type (i.e Calendar, Contacts, etc) you need to do it using the “FolderClass” attribute.

Note: The “FolderClass” attribute doesn’t exist in all versions of Exchange. I haven’t checked in detail but at least apparently in Exchange 2010 you won’t be able to leverage this attribute to filter just the folders you want. Worst case scenario you can always run a count against all folders. Also note that as you can see below, not all folders have a “FolderClass”.

PFCount1

And finally the code to grab all the folders you want.

With the FolderClass attribute filtering:

#Get all folders
$folders = get-publicfolder \ -recurse -resultsize unlimited | ? {$_.FolderClass -like “IPF.Contact”}
And without:
#Get all folders
$folders = get-publicfolder \ -recurse -resultsize unlimited

 

Note: The Where-Object filtering (? sign in the command above) in PowerShell caches all its results into memory, so if you have a very large public folder structure you might want to have that in mind and run the commands in a machine with enough resources.

Now that we know how to grab all the folders we need, lets look at how to do the folder count:

  • The command used to do the folder count is, as mentioned above in this post, the Get-PublicFolderItemStatistics
  • Because all you want to do is count items of a certain type, you will leverage the “ItemType” attribute in your filtering
  • Don’t forget that the Get-PublicFolderItemStatistics is an Exchange 2010+ cmdlet

Below see the output of an item count of a specific folder.

PFCount2

Now, finally, the entire script (in bold the item count):

PFCount4

(and the copy/paste version)
#Get all folders
$folders = get-publicfolder \ -recurse -resultsize unlimited | ? {$_.FolderClass -like “IPF.Contact”}
#Process All folders
Foreach ($folder in $folders){
$ContactCount = 0
$Contacts = get-publicfolderitemstatistics $Folder.Identity|? {$_.ItemType -like “IPM.Contact”}
If($Contacts -eq $null){
Write-Host”The folder ‘$($Folder.Identity)’ has 0 Contacts”
}
Else{
foreach($Contact in $Contacts){
$ContactCount++
}
Write-Host”The folder ‘$($Folder.Identity)’ has $($ContactCount) Contacts”
}
}
Lets break down the script above:
  • we start by getting all folders of class contact. Again you can do this filtering or not, depending on the Exchange version and what you need exactly.
  • we then enter a loop where, for each folder, we will grab all items of type contact and count them
  • once that is done we write the output into the console

This script is very simple and doesn’t have error handling, logging and output to CSV. If you want those features feel free to contact me via the blog and I can build you a very complete version of the script.

Running the simple version of the script in a large environment can make the results difficult or impossible to analyse, however, with the code above gives you an insight in how to filter and count Public folders, by type and class.

As always I hope this is helpful.

Azure AD Connect: A quick way to check (online) the last time the sync ran

I was just doing some work in a devops work tenant, that usually has a Hybrid setup created and Azure AD Connect installed and running, and I realized that I needed to check when was the last time that:

  • the Directory synchronized successfully
  • Passwords synchronized successfully

As this is a very simple process I thought I should write a 5min blog post about it.

All you have to do is connect to the Azure Active Directory of your tenant and execute the Get-MSOLCompanyInformation.

ADConnectSyncTime

The 3 parameters that you want to look at are:

  • DirectorySynchronizationEnabled (this one is not mentioned above. It shows if the tenant has the synchronization enabled or not)
  • LastDirSyncTime
  • LastPasswordSyncTime

Hope that this information is helpful.

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:

<#
.NOTES
 Author: antonio.vargas@myexchangeltd.co,uk

Date: October 4th 2017
 Version: 1

.SYNOPSIS
 This lines of code will connect 2 PowerShell Exchange Online sessions to 2 different tenants. 
.DESCRIPTION
 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 https://ps.outlook.com/powershell -AllowRedirection -Authentication Basic -Credential $SourceCred

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

### Create Destination EXO Session

$DestSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -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

### LISTING PS SESSIONS

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:

2sessions

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 onmicrosoft.com address, as the example below.

Google1

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

Google2

And the user primary SMTP address on Google.

Google3

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

Google4.JPG

And the email sent to User10@myexchlab.com, that was forwarded to Office 365.

Google5

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.

Summary:

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.

google6

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 O365.myexchlab.com 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 myexchlab.com I also own the forwarding domain O365.myexchlab.com, 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.

google7

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

google8

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.

Summary:

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 O365.mydomain.com – mydomain.com 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 @tenantname.onmicrosoft.com group as shown below (apologies, my current Office 365 tenant is in Portuguese, but I guess you can all recognize and understand the UI 🙂 ):

Group1

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*

group2

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=tenantname.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EU
RP193A002,DC=PROD,DC=OUTLOOK,DC=COM’}

group3

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@
myexchlab.com -CustomRecipientWriteScope:RestrictedMigrationScope

group4.JPG

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 user10@myexchlab.com

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.

group5

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.

group6

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

group7

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

group8

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.