E12 and Monad (MSH)

Over the past four days I have been presenting the E12 Ignite training in the UK with a few other colleagues from the UK. The sessions obivously prompted more questions than answers as we went through what’s what in E12 Beta 1.

A lot of discussion was centred around MONAD (MSH) – for those that don’t know, the scriptable interface for E12. The following should help in order to make sure that nothing goes awry when running scripts.

Consider the following question: Can we test a monad script before actually running the script?

For instance, before moving mailboxes by script, customers would like to test if the script works well or not.

Simple test to see what would happen: 
            get-Mailbox *Brettjo* | set-mailbox -prohibitsendquota 50MB
Well since you’re doing bulk management, you want to see what things will be effected. So you do: 
            get-Mailbox *Brettjo* | set-mailbox -prohibitsendquota 50MB -whatif
That will show you which users are going to be changed as a consequence of the command.

The -WhatIf parameters allow a second-level check when you’re performing an operation that may change the system state.

The –Confirm parameter will present a query to ensure that you want to proceed with the operation
The more complicated cmdlets, specifically move-mailbox, provide something called -validate, which will do more checks as needed: 
            get-mailbox *Brettjo* | move-mailbox -targetdatabase mySG\myDB -validate   

In general, the approach for scripters should be:

• Use the shell to try out cmds on test objects before running a script, this lets you experiment and tweak things before putting them in a “final” script. The shell is your friend–use it as an interactive scripting environment
• If you want to see what a script is doing while its running, do set-mshdebug -trace 2 before you run the script
• use Whatif to see what users / items / objects are affected by a cmd, whatif will be available on all cmds except get-* cmds
• for move-mailbox use -validate
• for step by step execution of a script use set-mshdebug -step (turn it off by doing set-mshdebu -setup $false)

There is also some documentation / tricks here on a “breakpoint” style function that you can define to further help your script creation experience

— Thanks to Vivek for the go ahead on this blog.

Comments (2)

  1. Anonymous says:

    So my roving reporter, Mark is over at the Windows Connections 2006 event in Disney World (don’t ask). …