PowerShell and Migrations

“What is Microsoft PowerShell, and what does it mean to migration from Domino to Exchange Server 2007?” Well, that was the question yesterday from a partner who was reviewing our projects.

“What? not heard of PowerShell…! ” I was shocked. Well not really since it is a new techonology and I do not expect everyone/everywhere to be holding their breath on what is the next cool thing we are doing. However it is cool, especailly for admin-centric processes….um…like a migration.

So what is Powershell? Well at it’s core the name says it all. It is a powerful command shell. Unlike DOS shell, where you basically can just run applications or run crude batch files, or VBS (or some other scripting/codelanguage) where you are writing an actual application, PowerShell is a rich shell in which you not only can create and runapplications (tasks as they are called), but you have a complete shell language complete with a rich object model.

So what? How can that effect migrations? Well, quite a lot. Imagine having access to the phases of a migration (and not only the phases but the actual data in transit) and being able to control that data and process. Today you can use our migration-wizard with a CMD-LINE interface, but that only gives you control of what out of the wizard we have exposed. Powershell turns this upside-down. In PowerShell, we have created migration tasks that perform the work and expose the migration data. You have direct access to these tasks and data. Our UI (or wizard interface) will just be on top of these tasks.

>>>>

For example: Say you wanted to migrate the first 100 people from the sales department. (Both migrating the NT accounts into Active Directory, and mailboxes into Exchange Server 2007 ) here is what you could type.

MSH> $mailbox = Get-DominoMailbox –Server Server1 | where {$_.department = “Sales”}

This would use the Get-DominoMailbox task that will return a list of all mailboxes on Server1. That list would then be passed to a standard Powershell command, ‘where’, that filters down the list to just mailboxes in the sales department. You could NEVER do this in today’s migration tools because you do not have access to the actual data in the process.

MSH> $mailbox | ft Name, Office, phone

NAME OFFICE PHONE

---- ------ -----

Erik Ashby     Redmond 555-555-1212

Kim Akers New York 555-555-1212

This then would list the mailboxes in your list. You can now perform all sorts of cool stuff (well cool to admin geeks like me) with the list such as ($mailbox | sort Office) which would sort by office location, or ($mailbox | group Office) which would group by office or, ($mailbox | Out-File) that would write the objects to a file, or…well you get the idea. But let’s keep is simple and just migrate the first 100 into Active Directory.

MSH> $mailbox[0..99] | Move-DominoDirectory –OU “\Users” DomainController “RedDC-01”

This now takes the first 100 in the list and passes them to ‘Move-DominoDirectory’ This task is responsible for creating NT accounts and will perform the logic needed to match and import the accounts into Active Directory.

Finally migrate the mailboxes

MSH> $mailbox[0..99] | Move-DominoMailbox –MailboxDatabase “Sales”

There is an example of 4 simple lines to do a migration. This can actually be boiled down into a single line with ‘Move-DominoMailbox’ since that task has the logic to perform the previous tasks, but I wanted to show you how you can have very detailed/specific control over a migration and the data in a migration. And honestly this only scratches the surface of what will be exposed in Powershell. There is much more to blog about later like scripting, modification of objects or even accessing content during a move…

>>>>

Anyway, to me this is some freaking cool stuff.

Erik

Comments? please comment.

>> More links on Powershell

Powershell blog

https://blogs.msdn.com/powershell/

>> A video showing an old tool of mine in action…

>> And a couple of additional blogs showing off some Exchange commands

https://blogs.technet.com/aralves/archive/2006/06/09/434491.aspx

https://blogs.technet.com/aralves/archive/2006/06/12/435189.aspx