A recent survey in the Exchange and Outlook Update revealed that 16% of the respondents said that PowerShell remained a complete mystery to them no matter how hard they tried to master the topic. Hmmm… that’s not a good situation for any Exchange administrator to find themselves in because PowerShell, whether you personally think it is a good idea or not, is at the heart of all on-premises Exchange administration tools – EMC, EMS, ECP, and Setup. And the same is true if you take care of Exchange Online in Office 365.
Exchange 2010 includes three different ways for administrators to learn PowerShell from the commands that it executes to perform different tasks. You can pick up some excellent tips about the syntax and usage of commands through these sources. Even better, you can cut and paste the code to form the basis of scripts that you then use to automate common administrative processes.
First up there’s the code that EMC displays after it runs one of its many wizards. The screen below shows the code used to move a mailbox from one database to another with the New-MoveRequest cmdlet. You can see the invitation to press CTRL+C to copy the code. This facility is also available in the Exchange 2007 version of EMC.
Next, there’s the neat feature that Microsoft added to EMC in Exchange 2010. If you access the property pages of an object such as a mailbox and make a change, a little PowerShell symbol in the bottom left-hand corner of the screen lights up. If you press the symbol, another window appears to show you the code that EMC will execute if you subsequently press the OK or “Apply” buttons. In other words, this is the code that is used to make the change that you’ve just requested. In the screen below the Set-Mailbox cmdlet will be run to update some attributes of a user mailbox. Again, you can highlight the code and use CTRL+C to copy it for further use.
Last, Microsoft also added PowerShell logging to the Exchange 2010 EMC. This means that every single command executed by EMC to display and manipulate objects is captured in a log that you can scroll through (logically, the option is available from the View menu) to track all of the commands that are executed and the syntax that is used. If you know the sequence of actions that you take to perform a certain operation, you can track the commands that EMC uses to gather the relevant objects, display them, and then make whatever changes you might make. And once again, you can copy the commands from the log for further use.
I fully understand that PowerShell won’t toot everyone’s horn. But that’s no reason to avoid PowerShell and pretend that everything can be done through a GUI. For example, Office 365 administrators are usually restricted to ECP unless they run a hybrid on-premises/cloud environment. The current version of ECP isn’t as functional as EMC is (it’s also fair to note that some options – such as managing ActiveSync device policies – only appear in ECP) so it’s quite common to have to use EMS to perform certain operations to maintain an Office 365 tenant domain. When this happens you’re running raw PowerShell so you had better know what you’re doing else “unfortunate events might occur.”
Using the tools that are at our disposal to their fullest degree simply makes sense. By using the tools described above, I hope that the unfortunate 16% might find PowerShell a tad more approachable.
