How do you plan and execute a successful Public Folder migration?

From all the years as a consultant, and now directly in the migration business, helping partners successfully plan and execute migrations, Public Folders as always been the one of the most challenging workloads I had to deal with.

There’s always a lot of questions when you have to execute such migrations, so I decided to write a blog post about it, where I am going to try and address as much as possible.

To try and keep it as organized as possible, and because there are so many different scenarios, I will divide this post into three main sections: General migration considerations, Migrating Hybrid Public Folders and Migrating Public Folders cross organization.

We will then also discuss some more generic questions, such as why use a third party tool vs the Microsoft native tool.

General migration considerations

This blog post is focused both on Hybrid and cross organization Public Folder migrations. Some steps however are exactly the same, regardless of what the migration scenario is. Those steps are described below. After reading this section you can then focus on your specific scenario in the sections that follow.

Prepare your On Premises Environment

One of the first things you need to look at is to the On Premises Public folder structure, to check if there’s any inconsistencies or invalid folders. The best way to that is of course via scripting, and you should use this excellent script from Aaron @Microsoft, called IDFix for Public Folders. Download it, run it and fix everything that the script highlights as needing to be fixed.

You should also make sure you create a report with all mail enabled Public Folders and address, and to do so you can leverage the Get-MailPublicFolder cmdlet.

How to migrate Public Folder access permissions, as well as Send-As and Send-on-behalf rights

Public Folder permissions should be migrated by the migration tool, provided of course identities match between on premises and Exchange Online (which should of course be true for Hybrid scenarios), or between premises  in cross organization migrations.

As for the Send-As and Send-on-behalf rights, the best option is to export them from the source system and import them into the destination system, once the migration is completed. Since this is not PowerShell code I’ve focused on recently, I did a quick research online and found this article online where you can find the code to export and import those access rights.

Note: I am not the author of the code below and I am only putting it directly in my blog post just so it’s easier for you to locate it and copy it. The code was taken from the article mentioned in the line above, written by Aaron Guilmette.

Export Send-As

Get-MailPublicFolder -ResultSize Unlimited | Get-ADPermission | ? {($_.ExtendedRights -Like "Send-As") -and ($_.IsInherited -eq $False) -and -not ($_.User -like "*S-1-5-21-*")} | Select Identity,User | Export-Csv Send_As.csv -NoTypeInformation

Export Send-on-behalf

Get-MailPublicFolder | Select Alias,PrimarySmtpAddress,@{N="GrantSendOnBehalfTo";E={$_.GrantSendOnBehalfTo -join "|"}} | Export-Csv GrantSendOnBehalfTo.csv -NoTypeInformation

$File = Import-Csv .\GrantSendOnBehalfTo.csv
$Data = @()
Foreach ($line in $File)
    {
    If ($line.GrantSendOnBehalfTo)
        {
        Write-Host -ForegroundColor Green "Processing Public Folder $($line.Alias)"
        [array]$LineRecipients = $line.GrantSendOnBehalfTo.Split("|")
        Foreach ($Recipient in $LineRecipients)
            {
            Write-Host -ForegroundColor DarkGreen "     $($Recipient)"
            $GrantSendOnBehalfTo = (Get-Recipient $Recipient).PrimarySmtpAddress
            $LineData = New-Object PSCustomObject
            $LineData | Add-Member -Type NoteProperty -Name Alias -Value $line.Alias
            $LineData | Add-Member -Type NoteProperty -Name PrimarySmtpAddress -Value $line.PrimarySmtpAddress
            $LineData | Add-Member -Type NoteProperty -Name GrantSendOnBehalfTo -Value $GrantSendOnBehalfTo
            $Data += $LineData
            }
         }
    }
$Data | Export-Csv .\GrantSendOnBehalfTo-Resolved.csv -NoTypeInformation

Import Send-As

$SendAs = Import-Csv .\SendAs.csv
$i=1
foreach ($obj in $SendAs) 
    { 
    write-host "$($i)/$($SendAs.Count) adding $($obj.User) to $($obj.Identity)"
    Add-RecipientPermission -Identity $obj.Identity.Split("/")[2] -Trustee $obj.User.Split("\")[1] -AccessRights SendAs -confirm:$false; $i++
    }

Import Send-on-behalf

$GrantSendOnBehalfTo = Import-Csv .\GrantSendOnBehalfTo-Resolved.csv
$i=1
Foreach ($obj in $GrantSendOnBehalfTo)
    {
    Write-host "$($i)/$($grantsendonbehalfto.count) Granting $($obj.GrantSendOnBehalfTo) Send-On-Behalf to folder $($obj.PrimarySmtpAddress)"
    Set-MailPublicFolder -Identity $obj.PrimarySmtpAddress -GrantSendOnBehalfTo $obj.GrantSendOnBehalfTo
    $i++ 
    }

Migrating Hybrid Public Folders

This scenario, when compared to the cross organization migration, is far more complex, because besides moving the data you will also have to worry about things like mail flow, user public folder access, etc. But lets address one thing at the time.

Microsoft Official guidance to configure Hybrid Public Folders

If you’re reading this article because you’re planning to migrate your Hybrid Public folders, chances are you already read and executed the Microsoft guidance to make your on premises Public Folders available to Exchange Online users, under a Hybrid deployment. Configure legacy on-premises Public Folders for a Hybrid Deployment is the article for legacy public folders and Configure Exchange Server Public Folders for a Hybrid Deployment is the one for modern Public Folders.

Both articles are focused on the hybrid coexistence and not the migration planning of the Public Folders, but they are important to mention as they impact the migration planning, based on what type of coexistence you configured and steps you followed.

Public Folder end user access in the context of a hybrid migration

When planning a Public Folder migration, under a hybrid scenario, one of the most important things you need to consider is, end user access. With that in mind, consider the following:

  • On premises users cannot access Exchange Online Public Folders
  • Exchange Online users can access on premises public folders and/or Exchange Online Public folders, although you cannot configure a single user to access both, you can configure some users to have access to on premises folders and some to see them locally, in Exchange Online.

Have the two principles in mind, during your planning. The Public Folder access for Exchange Online users is complex and by itself worthy of a dedicated blog post.

The Microsoft official guidance, mentioned in the previous section, explains how you configure Exchange Online users to access on premises Public Folders.

The bottom line of this section is, make sure you move all users to Exchange Online, before you consider moving the Public Folders, and if you don’t, make sure that the users left on premises do not require any Public Folder access.

Public Folder mail flow coexistence before, during and after the migration. How do you handle mail enabled Public Folders.

Another very important component of your Public Folder migration is the mail flow coexistence, or to be more precise, the way you deal with the mail enabled Public Folders.

Mail Enabled Public Folders before the migration

When you follow the guidance provided by Microsoft, you will be asked to execute the Sync-MailPublicFolders script.

This script enables Exchange Online users to send emails to on premises mail enabled Public Folders, by creating mail objects in Exchange Online with the primary and all other SMTP addresses that those folders have on premises. This objects are not actual Exchange Online Public Folder nor they are visible in the Exchange Online Public Folder tree. They also allow those on premises Public Folders to be present in the Exchange Online GAL (Global Address List), and once a user in Exchange Online emails that folder, the email gets forwarded to Exchange On Premises.

Mail Enabled Public Folders during the migration

During the Public Folder migration, whether it’s a single or multiple pass (with pre-stage + full migration) migration strategy, you should not change the Public Folder mail flow. That means that you should not mail enable the Public Folders in Exchange Online (chose a tool that gives you that option). Actually as you will see below, there are things that you need to do in Exchange Online, before mail enabling the Public Folders.

Mail Enabled Public Folders after the migration

Once your migration (or the pre-stage) is completed, you should transition the Public Folder mail flow to Exchange Online. To do so, you should follow these steps:

  1. Start the pre-stage or full migration and wait for it to be completed
  2. Once the migration pass is done, go to Exchange Online and delete all mail objects created by the Sync-MailPublicFolders script (NOTE: this will temporarily break mail flow between Exchange Online users and mail enabled Public Folders, online or on premises)
  3. Mail enable the Exchange Online Public Folders, either via a script or using the migration tool. Make sure you add all addresses from the on premises to the online Public Folders
  4. Run a full migration pass if in step 1 the pass that you ran was a pre-stage

To elaborate a little bit more in step 2, the reason that you need to delete those objects is because you need to avoid conflicting addresses, when enabling the mail enabled Public Folders in Exchange Online, and those objects are not associated with the new EXO Public Folders.

Migrating Public Folders cross Organization

Migrating Public Folders cross organization is not as complex, and you’ll see why in the sections below. This scenario can include migrations such as:

  • Exchange Online to Exchange Online
  • Hosted Exchange to Exchange on premises or Exchange Online
  • Exchange on premises to Exchange on premises

When to migrate users and Public Folders

Usually this Public Folder migrations cross organization come as an additional step to a migration that also includes mailboxes.

Although there’s no 100% correct answer, when it comes to the question of what should be migrated first, mailboxes or Public Folders, in this cases normally the best option is to migrate mailboxes first and Public Folders last. The main reason for that is because you should migrate the Public Folders when they’re not being used anymore, allowing you to do a clean single pass migration of all the data.

Public Folder end user access and mail flow coexistence

This is where things gets simple, for this type of scenarios. There’s no Public Folder access cross organization (unless the user is using the credentials for the 2 systems) and although technically you can configure mail flow between any two email systems, it’s not something you should consider for the majority of the cases.

Mail enabled Public Folders can and should be created at the destination during the folder hierarchy creation.

Why use a third party tool to migrate Public Folders

That’s probably the question I get the most, working for a third party migration tool company, that has an amazing Public Folder migration tool, BitTitan. And here is a list of reasons:

  • Migrate large volumes of data: Migrating 2, 5 or 10GB is easy with any tool, but not all tools can deal with Terabytes of Public Folder data.
  • Migrate parts of the structure or prioritize data: Either by targeting just specific parts of the Public Folder hierarchy or by using folder filtering. This is a very commonly used feature in tools like BitTitan MigrationWiz.
  • Flexibility on handling mail enabled Public Folders: As explained in the Hybrid mail flow section of this posts, you might need some flexibility on how to handle mail enabled Public Folders during the migration. MigrationWiz will mail enable in the destination all Public Folders that are mail enabled at the source, but you can also suppress that option, and should in some scenarios.
  • Data transformation: While planning a migration of Public Folders, some customers want to take that opportunity to also move that data into a different structure, which can be shared or resource mailboxes, office 365 groups, etc. That is something that can be successfully done with tools that are flexible enough to perform that transformation (i.e in many cases requires recipient mapping, folder mapping, folder filtering, etc), like MigrationWiz.
  • Supported sources and destinations: Exchange 2007+ to Exchange 2007+, including of course Exchange Online and hosted as source and/or destination – this is the answer most customers want to hear from the support ability stand point of a third party tool, to migrate their Public Folders, and that is something they won’t get with the native tool.

The bottom line

While reading this post, before publishing it, I always get the feeling that there’s so many other things that I could mention and talk about, but I do think that it addresses the core concerns of most Public Folder migrations, and hopefully it addresses yours.

Nevertheless, if you do have any questions don’t hesitate to reach out.

 

 

 

Advertisements

Exchange 2013: When your Load Balancer marks your Client Access Server as offline.. and all services are up and running

Just recently, I was asked to help with an issue in an Exchange 2013 Organization. The problem was that the KEMP Load Balancer, that balances requests for multiple Exchange protocols, between several Exchange 2013 servers, was marking one of the CAS servers as being offline.

The server was not being marked as offline for all services, it was just for one, Outlook Web Access (OWA).

Before I go into server details, let me give you a visual representation of what the above means. In my case we had a KEMP Load Balancer, but this can apply to any load balancer.

mon2

What you can see above is the KEMP admin portal. On the left hand side if you go to Virtual Services and click “View/Modify Services”, you’ll see a table (that I conveniently don’t show, just so I don’t have to cover all information in it anyway). In that table you will have, per server, one or more “Real Servers”, and when that real server health cannot be verified, it will show in red.

What that means from an operational perspective, is that no request from that protocol (https/smtp/sip etc) will be sent to that server, meaning you can be in a situation of single point of failure and you won’t know it.

Now lets have a look at how those real servers health is checked.

mon3

If you click to modify the virtual service, in the “Real Servers” section you will see the check parameters. Basically what KEMP does is to get an https request to https://server/owa/healthcheck.htm

If that request fails, you should see a page not found and the server is marked as being offline. The below is the result you should expect from a healthy server.

mon4

In the URL above, you should see the server name. Below the 200 OK you should see the server FQDN.

Now that I explained, very high level, how the process works, lets drill down to the problem that I had.

Before detailing the problem that I had, I just want to point out that there are many reasons for a server to be marked as offline by a load balancer, and that you should check the obvious ones first, such as if all services are running, if Exchange is coming back as healthy when using tools such as the Get-ServerHealth or Exchange cmdlet, System Center Operations Manager (SCOM) if you have it, etc.

In my case there were no obvious reasons, plus I found it strange that only the https protocol was having issues, so this is what I did:

1 – I browsed to the https website that KEMP uses and noticed that I was getting page not found, which explains KEMP marking the server as not available

2- I then used another very handy Exchange PowerShell cmdlet, the Get-ServerComponent, to check which components were in an Active or Inactive state

See below an example of a good output for the server components, with all of the relevant ones being active.

mon5

But what I was getting was not what you see above. I was seeing the “OwaProxy” component as inactive, and that was a problem.

3- So what I did next was to look at the Exchange 2013 Health Mailboxes, searching for inconsistencies

And I found them…

mon1

When I ran a Get-Mailbox -Monitoring, to list all Health mailboxes, I found that some were corrupt, due to being associated with missing databases or missing mailbox servers.

This Exchange Organization has been downsized for the past year and during that cleanup those mailboxes were forgotten. If you have the same issue, don’t worry. Although it’s important to keep those mailboxes in a good state, you can easily recreate them, and that leads me to my next step.

4- Recreate the health mailboxes

So instead of me doing a lot of copy past into my blog post, check this Exchange 2013/2016 Monitor mailboxes article, from the product group blog, that not only has a lot of information about those mailboxes, but also has a perfect step by step at the bottom, on how exactly you recreate them.

And that’s what I did, recreate them, re-tested the URL https://server/owa/healthcheck.htm, which now worked perfectly and my load balancer was no longer marking my CAS server as unavailable in my https virtual service.

Hopefully this article can help you resolve your issue!

 

What does it really mean to be in the last year of support for Microsoft Exchange 2010?

The Microsoft Exchange product team, sent out a reminder on January 14th 2019, regarding the end of support for Exchange 2010. It will happen in 1 year! Don’t think one year is a long time, read the below to have my perspective of what this means to Microsoft but more importantly what this means to you, and start planning and executing the best roadmap for you. Check here what the Microsoft recommended roadmap is.

Let me start by outlining the simple reasons (in my perspective, of course) of why Exchange 2010 is going out of support:

  • Age and Versions – Believe it or not, Exchange 2010 RTM was launched in November 2009, almost 10 years ago. To add to that, we had 3 new versions being launched since: 2013, 2016 and 2019.
  • Office 365 and Hybrid compatibility – Exchange online servers get upgraded and the same compatibility standards apply. This means that it makes perfect sense that, as Exchange Online versions evolve, On Premises supported versions tend to be raised as well. Today, if you look at the Hybrid Deployment Prerequisites official information, you’ll see that Exchange 2010 based hybrid deployment is still supported, but I am sure that this won’t last long, and being in a Hybrid deployment will require at least one Exchange 2013, very soon. Logic says that once you start the On Premises upgrade path, by installing higher versions, you should be ready as well to move services to the higher versions and think about decommissioning the lower ones.

Moving on, what exactly does this announcement means, from the Microsoft perspective?

  • No more support, bug or security fixes or time zone updates – Basically Microsoft here tells you that you’re on your own, should you choose to keep Exchange 2010 in your Exchange Organization.
  • Move to Office 365, move to Office 365 (that’s actually not a typo or duplicate, it’s to show how determined Microsoft is to have you move to Exchange online) or upgrade your Exchange Servers On Premises to a newer version (Exchange 2013+) and decommission all Exchange 2010 servers from your Organization – It’s no secret that for Microsoft, the best option for most organizations, is to move to Exchange Online. Making a product with 10 years and 3 newer versions end of support, is not a consequence of that, but they do take the opportunity to call out those companies, that still have Exchange 2010 or older versions, and tell them to move to the cloud. I do agree that this will be the best option for most of the organizations out there, just not the best option for all, and the reasons are so vast that I could write an dedicated and extremely long blog post about it. In summary probably 95%+ of the organizations, are a perfect fit for Exchange Online.
  • If you need help, use the Microsoft FastTrack (did I mentioned that they highly recommend that you go to Exchange Online? 🙂 ), or search for a partner here – This part of the article, the “What if I need help?” section, is actually interesting because they don’t even mention anything directly for if you need help to upgrade your On Premises servers. They basically say that, if you need help, the FastTrack can help you or you can hire a partner, again very Office 365 focused (and I can’t stress this enough: I agree that moving to Office 365 is the best move for most organizations). You can however use the partner search link to, if you choose to, hire one of many great partners out there that will upgrade your Exchange On Premises, if they feel that you’re not the best fit for online, or give you a migration path to Exchange Online and Office 365, better than the FastTrack can provide, if they identify that is the case, by using a third party tool.

And finally, what is probably the most important part, what exactly does this mean to you and your Exchange Organization?

  • You don’t have to upgrade, or take any action for that matter, but you should – Your current Exchange 2010 servers will not stop working, and believe me I’ve recently seen Exchange 2003 or older versions still sending and receiving emails, but you should start planning now to either upgrade and/or decommission your Exchange 2010 servers. Do not go into an unsupported scenario, with a service as critical as email should be for your organization. 
  • It doesn’t matter if your Exchange 2010 servers aren’t hosting mailboxes and/or processing Client Access Services  – This can affect you because you have servers with mailboxes and active CAS services, but that’s not the only scenario. If you have some old Exchange 2010 Servers, as part of an Exchange 2013 or Exchange 2016 organization, you just recently had one reason to remove them – Exchange 2019 – and now consider this as one more. Don’t keep non supported servers in your Organization. If it’s because of that printer or app using the server to relay email, or because of an old backup or email signature software that lets you stuck to 2010, upgrade that as well or get rid of it.
  • It’s not only about if you’re planning to go to Office 365, it’s also if you’re already there and under a Hybrid – If you’re planning to go to Office 365, getting rid of the Exchange 2010 in the process is a good idea, but what if you’re already there and under a Hybrid deployment? If that’s your case, plan and execute. The ideal scenario is always towards having Exchange 2019 (the latest available version) Hybrid servers, and that won’t happen before you remove those 2010. If your Hybrid is a 2010 based hybrid than the urgency is even bigger: Don’t wait!

Hopefully all of the above makes sense. If not, please reach out to me. It’s time to move on from Exchange 2010. Time to upgrade or migrate, whatever suits best your needs.

Populate Exchange mailboxes using Exchange Web Services

I just came across a very nice and handy script, that allows you to quickly populate your Exchange mailbox with test data, leveraging EWS.

Being in the migration business and having to do all sorts of tests and demos all the time, this to me is a very useful script, and I am assuming if you’re reading this post, there’s a chance that you also need it.

So this PowerShell script to generate mailbox test data over a period of time, when compared to other methods that leverage SMTP, is great because you can actually populate the mailbox with “old” data.

The parameters you can specify can also be found in the page of the author of the script. You can specify the target mailbox, number of days to fill the mailbox with, messages per day and message size, EWS endpoint or to use autodiscover and some EWS API specific parameters.

EWS1

Above you can see and example of the script execution.

EWS2

And this is how it’s going to look, as it executes.

The script should work perfectly both in Exchange Online and On Premises, as long as it’s a version that supports EWS.

Disclaimer: Unlike many other scripts I blog about, I am not the author of this script. I’ve seen it in the Technet Gallery, used it, and though I should blog about the experience. If you have any issues and/or recommendations or evens kudos to sent, refer to the author, identified in the Technet gallery page.

 

The differences in quotas and how to handle Public Folder migrations to Exchange 2013+ On premises vs Exchange Online

When we talk about migrating Public Folders, and believe me I talk about that a lot, the usual assumption is that the migration is to Exchange Online. That is true most of the times, but not all.

BitTitan MigrationWiz is a tool that adapts to all sorts of scenarios, the rule being if you have an Exchange 2007+ in the source and destination, and that of course includes Exchange Online, that MigrationWiz will be able to migrate your Public Folders. That being said I find myself discussing scenarios such as migrating Public Folders from Exchange on premises or Exchange Online, to a destination Exchange On Premises.

For those used to migrate Public Folders into Exchange Online, you would know that one of the main things to take into account is the volume of data to be migrated and how to make that work seamlessly, since the Public Folder mailboxes in Exchange Online have quotas you can’t change, as you can see here.

One of the things that makes MigrationWiz such a good tool to migrate large volume of Public Folder data, into Exchange Online, is that we will automatically split the Public Folder data into multiple mailboxes, therefore preventing a migrate failure and delay if one of the mailboxes gets full during the migration. This is done via support and explained in all the relevant migration guides, such as this one.

So the question now is, would this process be necessary when the destination are Exchange On Premises 2013+?

Answer: No. You can’t change Public Folder mailbox quotas in Exchange Online, but you can change them in Exchange On premises, so you don’t need to automatically split the data into multiple destination mailboxes.

And should I use a single On Premises mailbox for a large volume of data?

Answer: You can, but you shouldn’t. If you have 100, 150 or 200GB of Public Folder data, then yes a single mailbox approach seems reasonable, but if you have more than that you should think about having multiple mailboxes, for reasons like backup and restore management, among others. Another reason for having multiple Public Folder mailboxes might be if you have a multi region Exchange Organization and you want to provide localized access to Public Folders.

Why do you reference the destination as being Exchange 2013+?

Answer: Because this blog post focuses specifically in modern public folders (mailbox vs database).

Now lets have a look at a Public Folder mailbox in Office 365:

PFMBX1

As you can see above the quotas are well defined and cannot be changed.

How does that look in Exchange On premises?

PFMBX2

Above you can see 2 Public Folder mailboxes. One comes with the quota set to unlimited, which is the default when you create a new Public Folder mailbox in Exchange 2013, and for the other one I’ve set the limits to 150GB, with the following command:

Set-Mailbox -PublicFolder <mailboxname> -ProhibitSendReceiveQuota 150GB -ProhibitSendQuota 150GB -IssueWarningQuota 150GB -UseDatabaseQuotaDefaults $false

Note: Don’t forget to set the database quota defaults to false, if you want the new quotas to apply at the mailbox level.

As you can see above there are differences between Exchange Online and On Premises, and the control you have over both. Consider them when planning your migration.

 

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.

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.

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.

 

The complete journey from Google to Exchange Online with Free/Busy rich coexistence

When questioned by partners, on what is the best approach to plan and execute a move of a customer’s email system, from G-Suite to Exchange Online in Office 365, the first questions that I ask are:

How many users do you have to migrate?

Are you going to do a migration in batches (Staged) or cut over all users at the same time?

Usually when there’s a large number of users, the migration in batches is the preferred option. At that point you should consider two things:

  • How can I automate the mail flow changes
  • How can I have free/busy coexistence between G-Suite and Office 365

The answer to both questions above is simple: You can automate the mail flow and have free/busy coexistence if you use BitTitan MigrationWiz to move the mailboxes, and the BitTitan automation processes to help you with the changes you need to do per migration batch.

In the past I wrote an article on how to configure mail flow coexistence between Google Apps and Office 365, that can help you understand the configurations you need to do.

BitTitan also has a very good article on how you can automate the mail flow changes, on a mail migration from Google to Office 365, as well as the entire migration guide.

But I want to focus this article more on the free/busy rich coexistence, between Google and Office 365, the value that it brings to your migration and your customer, a technical overview on how it works, and of course how you can configure it.

What is the value on having free/busy coexistence between G-Suite mail and Office 365 Exchange online

User experience. It’s all about the user experience!!! If you are moving a 20k users company from Google to Office 365, you often get questioned about what the migration journey will mean for the end users, in terms of end user experience. When you provide your customer and their end users the ability to have not only mail flow coexistence (that one is mandatory of course) but also calendar free/busy lookup capabilities, you’re giving them the best experience they can have.

I have also seen more and more companies using the BitTitan Google coexistence tool for permanent free/busy coexistence between G-Suite and Exchange Online, so don’t think about it just like an add-on to a migration project, it can be much more than that.

How can I achieve that with BitTitan

Currently BitTitan will allow you to use the Google coexistence tool for free during 3 months, if you use BitTitan MigrationWiz to move all of the mailboxes. If you want coexistence for more than 3 months, or if you’re not using MigrationWiz, you will be quoted a price per user per month.

Note: The statement above was true when I wrote this article. There no guarantee that will be true when you read it so please contNact BitTitan for more information.

Why do I need a free/busy coexistence tool between Google and Office 365

The answer to this is short and simple: the Google Calendar Interop, which is the tool that you need to configure on your Google tenant to query free/busy from Exchange mail systems, cannot query free/busy information, from an Exchange Online mailbox, via the Exchange Web Services API and the Availability Service. Instead it will try and query free/busy information from an Exchange Public folder. The problem is that the newer versions of Exchange don’t support that method anymore.

So in essence, because the Google Calendar Interop hasn’t evolved to match the changes that the Microsoft Exchange product group implemented in the way the free/busy is queried, specifically on the transition from Exchange 2010 to Exchange 2013, you need a translation tool between Google and Office 365. That translation tool is the BitTitan Google Coexistence tool.

How do I configure the BitTitan Google coexistence tool

The answer is, you don’t. You configure the Google Calendar Interop and Exchange Online by creating an Organization Relationship, both to point to the BitTitan Coexistence service, and you also create a MigrationWiz project in the BitTitan portal, so that you can obtain your authentication token from the BitTitan Support (support@bittitan.com). See here the coexistence setup guide.

This is how the Google calendar interop should look like:

1

And to configure the calendar interop:

  1. login to https://admin.google.com
  2. Go to Apps > G Suite > Calendar > Calendar Interop Management
  3. Enter all the information as per the coexistence setup guide

This is how the Exchange Online Organization Relationship should look like:

2

And to configure the Organization Relationship:

  1. Download the Coexistence script from the BitTitan setup guide
  2. Add the details to the script as per instructions on the setup guide
  3. Open an Exchange Online PowerShell session
  4. run the script
  5. Verify if the Organization Relationship was properly created by running: Get-OrganizationRelationship |fl

Do I need contacts in each organization for the free/busy to work

No, you don’t need a contact in Google for each user from Exchange Online that you want to query the free/busy, nor you need them in Office 365 for each Google user. You should have contacts in both sides, but to make sure you have a unified Global Address list.

To be clear on this:

  • Peter@domain.com is a Google mailbox
  • John@domain.com is an Office 365 mailbox
  • You don’t need to create peter@domain.com as an Office 365 mail contact
  • You don’t need to create john@domain.com as a Google mail contact

But again.. you should.. having a unified GAL is usually mandatory and for sure highly recommended.

How do users query the free/busy information

As they do for any other internal user. They open their calendar app and enter the email address of the user on the other system or search for his contact created on the GAL if it exists.

To wrap this up, and please stay tuned for more blog post on this subject coming soon, the rich coexistence (mail flow and free busy) experience, when you’re migrating your customer from Google to Office 365, is very important and also very easy to achieve.

If you have any questions please feel free to reach out. I can help you understand it better as well as configure it.

As always I hope this post was helpful.

PS- The BitTitan coexistence tool also works between Google and Exchange 2010 Sp2+ on premises.

 

 

 

 

Understand and script the Get-MailboxFolderStatistics cmdlet

This blog post is going to give you some insight on how you can script the Get-MailboxFolderStatistics cmdlet, but also how to understand it’s output, as well as how is it important to plan a mailbox migration project.

Why are the mailbox folder statistics important to plan a migration project?

That is indeed the first thing you need to consider: Why do I need those statistics? To better answer that let me start by showing you an output of the command.

1

What you see above is the output of a mailbox, where I filtered the Folder Path, the number of items in the folder and sub folders, as well as the size of each folder. So let me bullet point why is this important for a migration project planning:

  • It will give you item counts per user and per item type (Mail, calendar, contacts). Those numbers are important, specially if extremely large, to estimate migration timelines when using the Bittitan MigrationWiz mailbox migration.
  • It will show you the size of every folder as well as the entire mailbox size. This is important to identify which folders are larger on a very big mailbox. I’ve seen examples of some of those folder being considered irrelevant for a migration (i.e deleted items, sent items) and with a flexible tool like the Bittitan MigrationWiz you can filter them out.
  • It will show you not only the folders visible to the end user, but also the recoverable deleted items folder. This might be very important in scenarios where you have in place hold active. It will give you the exact estimate of how many items are under in place hold on the recoverable items, that you will eventually need to move to the same folder on the destination mailbox.

So in summary, and giving a quick example, if you’re moving 1000 mailbox from Exchange Online tenantA to tenantB, you should use the Bittitan MigrationWiz tool, that will be not only fast but also flexible on what you can include and exclude in the migration, leveraging the Exchange Web Services API. To do that the insight of what’s in the mailbox is fundamental to plan the entire migration. You can plan the timelines and how long it will take, what type of licensing you will need at the destination tenant and many other important variables for the project.

How can I filter the output per item type?

When running the cmdlet you need to use the “-FolderScope” parameter to filter the output per item type. That parameter allows you to enter many different folder scope types, the most common being:

  • All
  • Calendar
  • Contacts
  • RSSSubscriptions
  • RecoverableItems

See the entire list in the official Technet article of the Get-MailboxFolderStatistics cmdlet.

Some cmdlet examples

See below some examples on how to obtain specific data:

Get total number of items in the mailbox (does not include recoverable deleted items):

Get-MailboxFolderStatistics user@domain.com | Where-Object {$_.foldertype -eq ‘root’} |ft folderpath, itemsinfolderandsubfolders, folderandsubfoldersize

2

Get total number of contacts in the mailbox:

Get-MailboxFolderStatistics user@domain.com -FolderScope Contacts |ft folderpath, items*, folderandsubfoldersize

3

Note: the above will work for calendar items if you change the folder scope from “Contacts” to “Calendar”

Get total number of items in the Recoverable deleted items folders:

Get-MailboxFolderStatistics user@domain.com| where {$_.FolderType -eq ‘RecoverableItemsRoot’}|ft folderpath, itemsinfolderandsubfolders, folderandsubfoldersize

4

And finally… the script that exports all of this to a csv:

Now that we discussed how important it is to get the statistics, and I gave you same examples on how to run some one line commands to get some insight on the mailbox, I will share with you a script that was done by me and my colleague and friend Alberto Nunes.

Below are the details of what the script does:

  • The script will run the statistics against a list of users that needs to be specified on a file called users.csv (see csv format below). The file needs to be on the same folder as the script.
  • The script runs Exchange PowerShell commands, so make sure you’re connected to the Exchange PowerShell (online or on premises)
  • The script will export the results to a file statistics.csv
  • The script will ask you for a source or destination parameter. The statistics for the recoverable deleted items folders will only be included if you select Destination.
  • This script is provided as is and there’s no guarantee that it will work in your environment.

The Users.csv file:

5

Note: Make sure you name the column A “EmailAddress”

The Script:

Copy the text below (in red) to a notepad. Save it as .ps1 and run it from a PowerShell session connected to Exchange.

#Start Script
Param
(
[Parameter(Position=0,Mandatory = $true)][ValidateSet(‘Source’,’Destination’,’MigrationWiz’)][String]$Location,
[Parameter(Mandatory = $false)][String]$Folder = “.”,
[Parameter(Mandatory = $false)][String]$UsersCSV = “Users.csv”,
[Parameter(Mandatory = $false)][String]$OutputCSV = “Statistics.csv”
)
Get-Date
$ErrorActionPreference = “SilentlyContinue”
$SourceFile = $Folder + “\” + $UsersCSV
$OutputFile = $Folder + “\” + $OutputCSV
$mailboxes = Import-Csv -Path “$SourceFile”
$CSV = @()
Foreach ($mailbox in $mailboxes)
{
Write-Host “Working on $($mailbox.EmailAddress)”

$AllStats = Get-MailboxFolderStatistics $($mailbox.EmailAddress)| Where-Object {$_.foldertype -eq ‘root’}

$ContactStats = Get-MailboxFolderStatistics $($mailbox.EmailAddress) -FolderScope Contacts
$TotalContactsItems = ($ContactStats | select -expand ItemsInFolder |Measure-Object -Sum).Sum

$CalendarStats = Get-MailboxFolderStatistics $($mailbox.EmailAddress) -FolderScope Calendar
$TotalCalendarItems = ($CalendarStats | select -expand ItemsInFolder |Measure-Object -Sum).Sum

$RSSFeeds = Get-MailboxFolderStatistics $($mailbox.EmailAddress) -FolderScope RssSubscriptions -ErrorAction SilentlyContinue
If ($RSSFeeds)
{
$TotalRSSFeeds = ($RSSFeeds | select -expand ItemsInFolder | Measure-Object -Sum).Sum
}
Else
{
$TotalRSSFeeds = 0
}

# In the source, we don’t need to know the Size of the RecovableItems
If ($Location -eq “Destination”)
{
$recoverableItems = Get-MailboxFolderStatistics $($mailbox.EmailAddress)| where {$_.FolderType -eq ‘RecoverableItemsRoot’}
[double]$recoverableSize = $recoverableItems.FolderAndSubfolderSize.TrimEnd(” bytes)”).Split(“(“)[1].replace(‘,’,”) |%{“{0:N2}” -f ($_ /1mb)}
}

$TotalMailItems = $AllStats.ItemsInFolderAndSubfolders – $TotalContactsItems – $TotalCalendarItems – $TotalRSSFeeds

$ISSize = $AllStats.FolderAndSubfolderSize.tostring()
[double]$ISSize =$ISSize.TrimEnd(” bytes)”).Split(“(“)[1].replace(‘,’,”) |%{“{0:N2}” -f ($_ /1mb)}

$Output = New-Object PSObject
$Output | Add-Member -MemberType NoteProperty -Name “User” -Value $mailbox.EmailAddress
$Output | Add-Member -MemberType NoteProperty -Name “Location” -Value $Location
$Output | Add-Member -MemberType NoteProperty -Name “TotalItems” -Value $AllStats.ItemsInFolderAndSubfolders
$Output | Add-Member -MemberType NoteProperty -Name “MailboxSize MB” -Value $ISSize
$Output | Add-Member -MemberType NoteProperty -Name “TotalContactItems” -Value $TotalContactsItems
$Output | Add-Member -MemberType NoteProperty -Name “TotalCalendarItems” -Value $TotalCalendarItems
$Output | Add-Member -MemberType NoteProperty -Name “TotalMailItems” -Value $TotalMailItems
$Output | Add-Member -MemberType NoteProperty -Name “TotalRSSFeeds” -Value $TotalRSSFeeds
If ($Location -eq “Destination”)
{
$Output | Add-Member -MemberType NoteProperty -Name “RecovableSize in MB” -Value $recoverableSize
$Output | Add-Member -MemberType NoteProperty -Name “RecovableItems” -Value $recoverableItems.ItemsInFolderAndSubfolders
$Output | Add-Member -MemberType NoteProperty -Name “Total Mailbox Size including Recovable” -Value $($ISSize + $recoverableSize)
$Output | Add-Member -MemberType NoteProperty -Name “Total Mailbox Count including Recovable” -Value $($AllStats.ItemsInFolderAndSubfolders + $recoverableItems.ItemsInFolderAndSubfolders)
}
$CSV += $Output
Write-Host “Completed $($mailbox.EmailAddress)” -ForegroundColor Green
}

$CSV | export-CSV “$OutputCSV” -NoTypeInformation
#End Script

To run the script you need to specify the location parameter:

.\MailboxFolderStats.ps1 -Location Source

.\MailboxFolderStats.ps1 -Location Destination (includes recoverable deleted items statistics)

As always I hope the above is helpful. Thanks for reading.