How to leverage (multiple) migration endpoints to speed up migrations to Exchange Online

Last week, at Microsoft’s Tech Summit in Amsterdam, I gave a talk about running Exchange Hybrid connections over the long term. In that session, I talked about securing a hybrid deployment and – somewhat related – how to best and securely publish migration endpoints to the Internet.

Following that session, someone reached out to me asking me for more guidance on the topic. Except from what I have written about migration endpoints in the Office 365 for IT Pros e-book, I couldn’t find much else on the topic, so I figured I might elaborate on it a bit further. You can read more about it over on the blog of the ENow folks.

This being said, additional information beyond what’s described in this article can be found in the Office 365 for IT Pros e-book, which you can get here, if you’d like.


Blog Office 365

Exchange 2010 Service Pack 3 has been released!

Microsoft just released the long-anticipated release of Service Pack 3 for Exchange 2010. Many of you have been waiting impatiently for this Service Pack as it brings you one step closer to deploying Exchange 2013!

Yes, you read it well: one step closer. As a matter of fact. Exchange 2010 SP3 will allow you to coexist with Exchange 2013 Cummulative Update 1. Given that CU1 isn’t available just yet, you’ll have to be a little more patient… If you want more information, have a look at this article for the Exchange Product Group >

You can download the Service Pack from here:

A word of caution!

It seems that Service Pack 3 will also update the database schema of your databases. Once a database schema has been updated to SP3 you can no longer mount them on a pre-SP3 Mailbox Server. This means that you have to be particularly careful when updating Mailbox server that are part of a Database Availability Group!

Make sure to review the release notes before upgrading in your production environment:

If you’re looking for more information on what’s new in Service Pack 3, have a look here:

Have fun!


Exchange 2013

Using New-Migrationbatch to perform local mailbox moves in Exchange Server 2013

Along with a whole bunch of other improvements and new features, New-Migrationbatch is one of my favorite new additions to the Management Shell.

Prior, if you were moving mailboxes between mailbox servers in e.g. Exchange 2010, you had to use New-MoveRequest to start/request a mailbox move from one database/server to the other. If you had multiple mailboxes you wanted to move at once, you had several options:

    • Use Get-Mailbox and pipe the results along to New-Moverequest
    • Import a CSV-file and pipe the results along to New-Moverequest
    • Create an individual move request for each users

While these options are still valid in Exchange Server 2013, you now also have the ability to create a migration batch using the New-MigrationBatch cmdlet.

This cmdlet will allow you to submit new move requests for a batch of users between two Exchange servers, local or remote (other forest) and on-prem or in the cloud (on-boarding/off-boarding). If you have been performing migrations to Office 365, this cmdlet shouldn’t be new to you as it was already available there.

The nice thing about migration batches is that you can easily create them, without having to start or complete them immediately. Although with a little effort you could’ve also done this using New-Moverequest, it’s not only greatly simplified, the use of migraiton batches also gives you additional benefits like:

  • Automatic Reporting/Notifications
  • Endpoint validation
  • Incremental Syncs
  • Pre-staging of data

Just as in Exchange Server 2010, the switchover from one database to the other is performed during the “completion phase” of the move. During this process, the remainder of items that haven’t been copied from the source mailbox to the target mailbox before are copied over after which the user is redirected to his “new” mailbox on the target database. (for purpose of staying on track with this article, I’ve oversimplified the explanation of what happens during the “completion” phase)

Creating a migration batch

To create a migration batch, you’ll need to have a CSV-file that contains the email addresses of the mailboxes you are going to move. These can be any of the email addresses that are assigned to the mailbox. There is – to my knowledge – no requirement to use the user’s primary email address.

Also, the file should have a ‘heading’ called “EmailAddress”:


Next, open the Exchange Management Shell and run the following cmdlet:
[sourcecode language=”powershell”]New-MigrationBatch –Name <name> –CSVData ([System.IO.File]::ReadAllBytes(“<full path to file>”)) –Local –TargetDatabase <dbname>[/sourcecode]
Running this cmdlet will start a local mailbox move between two Exchange server in the same forest. However, it will not automatically start moving the mailboxes as we haven’t used the –Autostart parameter. Furthermore, the moves won’t be completed automatically either because the –AutoComplete parameter wasn’t used either.

Note   It’s important that you specify the full path to where the csv-file is stored (e.g. C:\Files\Batch1.csv). Otherwise the cmdlet will fail because it will search for the file in the sytem32-folder by default.

Once the batch is created (and you didn’t use the –AutoStart parameter), you can launch the moves by running the following cmdlet:
[sourcecode language=”powershell”]Get-Migrationbatch | Start-MigrationBatch[/sourcecode]
Please note that if you have multiple migration batches, this cmdlet will start all of them.

Polling for the status of a migration

You can query the current status of a migration on a per-mailbox basis using the Get-MigrationUserStatistics cmdlet. The cmdlet will return the current status of the mailbox being moved and the amount of items that have been synced/skipped so far.
[sourcecode language=”powershell”]Get-MigrationUser | Get-MigrationUserStatistics[/sourcecode]

Note   Alternatively, you can also use the –NotificationEmails parameter during the creation of the migration batch. This parameter will allow you to specify an admin’s email address to which a status report is automatically sent. If you don’t use this parameter, no report is created/sent.

Completing the migration

If you didn’t specify the –AutoComplete parameter while creating the migration batch, you will have to manually start the “completion phase”. This can easily be done using the Complete-MigrationBatch cmdlet.
[sourcecode language=”powershell”]Get-MigrationBatch | Complete-MigrationBatch[/sourcecode]
When you take a look at the migration statistics, you’ll see that the status will be “Completing”:


Once mailbox moves have been completed successfully, the status will change to “Completed”Confused smile


As you can see, the New-Migrationbatch will certainly prove useful (e.g. if you want to pre-stage data without performing the actual switchover). Of course, there are other use cases as well: it’s the perfect companion to use for cross-forest moves and moves to/from Office 365 as  it contains numerous parameters that can be used to make your life easier. For instance the Test-MigrationEndpoint cmdlet can be used to verify if the remote host (to/from which you are migrating) is available and working correctly. This is especially useful in remote mailbox moves (cross-forest) or between on-prem/cloud.

If you want to find out more about the cmdlet, go and have a look at the following page:

Alternatively, you could also run Get-Help Get-NewMigrationBatch –Online from the Exchange Management Shell which will take you to the same page!

Until later!


Exchange 2013 How-To's PowerShell

The philosophy behind a migration from Lotus Notes (Domino) to Exchange…

Let me first start by stating that this article is in no way intended to convince you to move from Lotus Notes to Exchange. I’m well aware that the world is divided into two (equal?) camps: one for Lotus Notes and the other for Exchange. And it seems that they’re continuously fighting each other trying to prove that their respective platform is better than the other. Just Google (or Bing) for “Lotus Notes vs. Exchange”. You’ll be surprised of some of the rubbish you might find out there…!

This article is none of that (or at least as little as possible). In fact, as an Exchange-minded person; let me start by telling you some things I like about Lotus Notes: it’s flexible. Over the years, I have seen some pretty nice solutions that were built with (and around) Lotus Notes. As far as my experience goes, there’s not much that it won’t allow you to customize (or overwrite). It also has got some features like recurring meetings with alternating dates (a feature that I would very much like to see integrated in Outlook!). And in some wicked way, I like the simplicity and flexibility of the file structure: each mailbox is a database in its own right and represented by a single file (nsf) that you can place pretty much anywhere you want: including NAS storage.

On the other hand, I’ve also seen some nice solutions built with (and around) Exchange. Going from workflows in Exchange Server 2003 (using CDO for Workflow) to some pretty nifty things with SharePoint.

My point here is that both systems have their qualities and unique selling points. Don’t try to compare them: it can’t be done.

Why do people migrate?

I cannot ignore the fact that over the past few years I’ve seen my share of migrations to Microsoft Exchange. Why is that?

As a consultant, you hear the wildest stories. Sometimes it seems that any excuses is good to move away from Lotus Notes: “Cost”, “Interoperability”, “Manageability”, “Following the market”, “the CEO doesn’t like the client” and my favorite “I want my new mail to appear on top”. From the aforementioned reasons, I believe “Manageability” to be the root of all evil (from IBM’s point-of-view at least). I don’t know the numbers, but the amount of knowledgeable Lotus Notes admins must have been declining (rapidly!)…

All in all, every migration starts with a reason. There has to be a reason. If you can’t find a reason to migrate then don’t. Simple!

In my personal opinion, there are several reasons why a lot of companies are moving away from Lotus Notes (to Exchange). First of all, Lotus Notes is not a messaging platform. It’s a application/development platform that offers mail capabilities. And although Lotus Notes does a pretty good job at handling mail. Exchange (in my opinion) simply does it better.

Lotus Notes, however, can do some nice tricks with regards to applications that Exchange simply cannot. And while that might speak in favor of Lotus Notes, this is the area where Exchange (actually the customer) usually relies on external platforms like SharePoint.

And while it’s said: SharePoint is probably another reason why people are moving away from Lotus Notes. Let’s face it, more and more (obviously not all) companies are embracing the capabilities of SharePoint. The fact that it integrates nicely with all other (Microsoft) applications you’re already using, is probably a huge selling point over Lotus Notes. I like to compare it a bit with the discussion of iPhone versus Windows Phone. Although both platforms are good (great?), Apple has the benefit of the nr of Apps and that’s why it’s so popular. SharePoint has more 3rd-party apps, plugins and cool stuff than Lotus Notes. It used to be different though…The difference here is that Microsoft is really trying to do something about it, whereas in the Lotus Notes vs. Exchange case I got the feeling that IBM acquiesces in the way things seem to go. Perhaps my perception is a little off: I don’t follow up Lotus Notes as closely as I do for Exchange. But in quite a lot of the cases, perception is reality….

As you can see, the reason to move away from Lotus Notes is rarely only because of email. Most of the time, it are the applications that inflict a migration.

About migrations

Now, let me move on and tell you a bit of my experiences in such migrations. If you already made the decision to move from Lotus Notes to Exchange, the following part is definitely something for you!

Know that Lotus Notes and Exchange are two totally different platforms. Other than the fact that they both offer you “mail-alike-capabilities” they have very little in common. Having two totally different systems inflict problems of their own.

You could compare it to two people talking a totally different language: English and Chinese. If you want to make them understand each other you either make them learn the language (that’s what standards are for!) or you use an interpreter.

A migration is very much the same: you usually need (3rd party) tools to help you get from one side to the other. Of course, you could make an attempt of ‘forcing’ both systems to speak to one another (like using sign language in the English~Chinese example); but then you’ll have to settle for limited functionality.

Let me clarify by using a quite common scenario. Office 365 offers a so-called IMAP migration which you could use to move email from Lotus Notes to Exchange. It works fine but you’d have to settle with some limitations (no PABs, no Archives, …) very much like the sign-language scenario.

Or you could use a tool (Quest, Migration Wiz, Binary Tree,…) to help you migrate. The tool is the interpreter. They offer more flexibility and a better experience (you can move PAB’s, Archives, etc.…) but there’s an additional cost.

The key difference between a human interpreter and the software-version (migration tool), apart from the one being alive and the other just some code, is that you still need a whole lot of planning before you can actually think of migrating. Every migration requires planning, you all know that. But as I see it, migrations from Lotus Notes to Exchange require that little extra: you have to take into account the key differences in how both platforms work. Server- and client side!

  • On the server side, you might have a Domino running on top of AS/400. The mail files might be fragmented all over your network, the approach to security is different, you might have unique (custom) functions that you require and you need to find an appropriate solution for (usually 3rd party), …
  • The client side might even be a greater challenge: mail file encryption (which is btw ridiculously easy!), multiple personal address books, multiple archives (in different locations) and an end-user’s experience (read: end-user’s expectations).

While the technical differences between both platforms might imply changes in architecture or a change in the way you manage your environment, the changes in the user-interface might require you to start worrying about your productivity: think about the impact a change in the client might have for your end-users! Outlook doesn’t offer itself a a UI refresh compared to Lotus Notes. It’s a total overhaul of your end user’s workplace!

It’s very likely that Lotus Notes and Outlook are the two tools that are most used throughout the day. If your users are accustomed to working with Lotus Notes it might be wise of you to train them on Outlook. Hell! It’s almost mandatory. I’ve seen some pretty weird things happen on a day after a migrations with bad- or under-trained end users…On the positive side: your users are probably already working with Outlook at home!

Manage the expectations!

Outlook just isn’t the same. It offers great value, but you (and your users) must face the fact that some things just aren’t possible anymore.

Expect to lose some data. In every migration, there’s always that one (or more) message(s) that have been sitting in the user’s mailbox for ages without being touched; corrupted for whatever reason. Even though the user has already long forgotten about the message, chances are they will make your life difficult. Be sure that you’re prepared for such situation. And above all, explain them the item was corrupted to start with 🙂

Do I discourage moving to Exchange/Outlook? No. On the contrary! Although it’s likely that your productivity will suffer the first couple of days after the migration; we usually see a (huge) increase afterwards with a lot of happy faces as a result (both CxO-level and end-users).

To coexist or not?

Absolutely not! (Unless you have a compelling reason to do otherwise, of course.) Anything other than mail flow between both systems should be avoided at all cost! If you do opt for coexistence, it will cost you money. And it will complicate things. That’s something you don’t want: adding complexity to something that’s already complex.

There are some beautiful solutions out there: Quest Coexistence Manager for Notes (CMN) for example. Nonetheless, the extra effort (setup, testing, managing) and – in my opinion – limited added functionality really make coexistence a last resort.

Most of the time, we only see coexistence deployed in scenario’s where the old (Lotus Notes) environment continues to live on for a while (perhaps waiting for it’s applications to get translated into SharePoint, who knows?)


Am I saying you should use a tool? Yes. If you’re looking for a ‘quick and dirty’ way to move from one side to the other, I’m pretty sure you’ll find a way without using additional tooling. But if you want to do things right: you’ll need a tool. Period.


In this (rather long) article, I’ve only scratched the surface of what a migration entails. I haven’t talked about all details nor have I talked about all the different options and tools. But I hope that – for those thinking to migrate or already having made the decision – the article can provide some insights and refreshing thoughts.

Rest assured: I see a lot of these migrations come to an happy ending; usually the ones where a lot of time was spent on analyzing, planning and validating… 😉

Just remember: changing from Lotus Notes to Exchange is more than only changing a system. Try to look at it in a holistic way:  it’s also about changing your operations, even more important: your mindset.