you're reading...
Blogging, Domino, Exchange

Exchange Migrations Made Simple – Even for a Domino Admin

With a background based solidly in Domino, and having developed and administered Domino for over fifteen years, I have finally had the experience of looking at Exchange and what is different regarding upgrading to new versions. Let’s start with Domino, it’s pretty simple, insert the CD and upgrade the version. However, this is not always the simple case. I’ve had many different cases where the installer chokes on a file and ends. You have to open the folder and rename the file to *.old or something. Then restart the upgrade again. Still this is not that big of an issue. With that being said the upgrade process is a process driven entirely by the Administrator. The server upgrade is simple but the upgrade of the mail files is a process that is not included and can be done via console commands.

Now proper standards and best practices dictate you do this first on a test box, in a separate domain to ensure sterility of the production environment. Once this is done you test and validate your applications. All good and done.

However Exchange upgrades are not an upgrade but a move to a new server. This is due in large part to the different architecture and standards introduced in the new version Exchange. So typically you can address this in one of several different ways. The first is to do a simple PowerShell Command such as:

Get-Mailbox ay* | .\MoveMailbox.ps1 -DatabaseMap @{“DB1″=”DBA”;”DB2″=”DBB”}

and let Exchange do the work for you. Where this is a problem is that you need to do this while the user is out of the office, or during off hours and the user must be out of the mail file. Where this is an issue is that it limits migrations to after hours or weekends. What about notifications? Well, you need to compile a list of the users moving that night, and send it to them manually. Another major issue with this is that you need to manually manage and schedule the users. And perhaps the third issue is the reporting of how many users and data was moved. So when you look at the standard process surrounding these migrations, it is a cumbersome process. There are a lot of different parts that need to be managed, tracked, reported on and it is all manual. Any Exchange Administrator who has done this once or twice can appreciate the complexity surrounding it.

Of course there are third party tools that help with pieces of this, but often they are based upon older versions of Exchange and do not move the data but rather read it, save it and then write it to the new server.

There is one solution however that is much easier. The MoveMailbox command with PowerShell is actually very easy but when you have to spend a week to build an script based upon thousands of users. This is a time consuming process and make one small error, and you have to find it. As a Domino Administrator and Developer I can appreciate a missed character can mean the difference of successful agent or a complete mistake that can end badly.

I had the chance to work with E2E Complete from Binary Tree over the last month. Let me tell you this, that as an individual with very limited Exchange skills, I was able to be migrate users between different forests in AD, as well as within an single forest, within an hour and half of getting the software. What really makes this solution powerful is the backend data store; it is SQL.

So first lets cover the requirements, it requires a single server, running Windows Server 2008, IIS, SQL 2008, and the Silverlight Client for the Admin Portal. The backend data is all stored in SQL. With this as a storage medium, it allows the solution to track the data migrated in relation to the time taken. With a few migrations, perhaps six to seven, it is able to accurately determine any size mail file and the associated time to migrate this data. So what is the big deal with this, imagine being able to accurately schedule these moves down to a matter of seconds? Well you can. In fact after just a few migrations you can add all users to the queue and know exactly how long this migration will take.

Well lets discuss a few of the options in this software then, what if you could define times that you will not migrate users? Remember uses have to be out of the mail file to move them. Well what if you could define times where you would not do any migrations? Because we know how long each mail file will take to move, we can schedule users in those time-frames so that we do not affect user access to mail files during this “blackout” times. Any user who will not complete before the blackout window is moved to the end of the blackout window and any user(s) that will fill the left over time are then moved.

Another really great feature is the ability to notify users. So the solution reads the Active Directory entries for users, gets their Exchange Database and mail file information from AD. It also has the user’s email address. Well when a user(s) is added to the migration queue, they are automatically sent an notification to a Self-Service portal. In this portal the user can receive notifications to an SMS device and/or any secondary email. In addition, as the people doing the migrations won’t always know a users role, the user can set personal blackout dates that they do not want their mail file moved.

So that covers two of the main issues surrounding Exchange Migrations, the scheduling/management of the migration and the user communications. Well with the metrics to predict the mail file moves, the SQL database is also used to track what has been completed. This means that the E2E Complete solution can used this data for reporting purposes. No more need to track these metrics in an Excel (or other form) spreadsheet. It is built into the tool.

With this E2E solution all of the manual steps surround the Microsoft Recommended approach of the MoveMailbox command are included; the user notifications, the scheduling and management, as well as the reporting. No more need to do it manually.

So the just of this is that even for Mail Administrators who have a limited knowledge of Exchange, the moves and migrations to IntraOrg or InterOrg migrations, the recommended Microsoft solution is in place with the PowerShell commands and letting the Exchange Server do all of the work but the solution is built to manage, notify and report on the process.

I am impressed!


About pwhiltz

I am a Domino Administrator and Developer who has been working with IBM Domino solutions since 1997. I work for an Enterprise Email Migration company and am delving into the realm of Microsoft Exchange now.


No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: