Mastering PowerShell commands for Exchange by the book

The key to manage Exchange Server 2016 is to master PowerShell commands for Exchange.

With this latest version of Exchange, IT administrators must learn how to manage Exchange 2016 mailbox and client access and troubleshoot issues with the edge transport server, which routes email online and protects the system from malware and spam. Part of the difficulty of managing Exchange Server is learning how to use PowerShell, as the web-based Exchange admin center cannot handle every issue.

The book Practical PowerShell Exchange Server 2016: Second Edition by Damian Scoles and Dave Stork, teaches administrators with little PowerShell experience how to use the scripting language to ease configuration jobs or handle tasks with automation.

For experienced PowerShell users, this book shares ways to improve existing scripts. Administrators can learn how to use PowerShell commands for Exchange to customize their servers, manage mailboxes and mobile devices, and create reports.

From migrating to Exchange 2016 to taking advantage of its new functions, this book walks administrators through common tasks with PowerShell commands for Exchange.

From migrating to Exchange 2016 to taking advantage of its new functions, this book walks administrators through common tasks with PowerShell commands for Exchange. This excerpt from chapter 14 explains why mailbox migrations work better with PowerShell commands for Exchange:

It's very unlikely that there is no Exchange admin that has not or will not have to move one or more mailboxes from one Exchange database to another. While some scenarios are quite easy, there are some scenarios that require some more planning, reporting and so on.

With the introduction of Exchange 2010, Microsoft also improved the one element that would grow into an almost impossible task: Mailbox moves. The revolutionary change in Exchange 2010 made it possible to move mailbox data while the user still could access and modify his/her data: Online Mailbox Move. New incoming mail is queued in mail queues until the mailbox is available again (i.e. when it's successfully moved or has failed).

With the trend of growing average mailbox sizes, this was a necessary step. Otherwise it could mean that a migration would take too long to perform in a single big bang, meaning that you have to migrate mailboxes in stages and maintain a coexistence environment until the last mailbox has been moved. It was also a major step towards making Office 365 more accessible to migrate to and more flexible for Microsoft on managing servers and databases. Just consider moving mailboxes like in Exchange 2003, hoping that every mailbox has moved before your maintenance window closes... <shivers>.

Luckily this has changed, and as Exchange 2016 can only coexist with Exchange 2010 and 2013, earlier versions of Exchange won't be an issue. However, the option is still there with the -ForceOffline switch in the New-MoveRequest cmdlet. You shouldn't have to use it under normal conditions, however from time to time a mailbox is fickle and can only move via an Offline move.

Now, most of the move mailbox options are available from within the Exchange Admin Center in one way or another. But in our experience, EAC is probably fine for simple migrations or the incidental move of one mailbox. If you migrate your server environment from one major build to another, it's almost impossible to ignore PowerShell. Those migrations are far more complex and full of caveats, that it mostly always requires the use of custom PowerShell cmdlets and scripts

Editor's note: This excerpt is from Practical PowerShell Exchange Server 2016: Second Edition, authored by Damian Scoles and Dave Stork, published by Practical PowerShell Press, 2017.