We already know that Monad is as powerful (or more) than some programming languages. But is it required to do complex scripting in Monad to do simple things? Do you have to learn all the knob and switches in order to use it to manage Exchange? When we started designing the Exchange cmdline and scripting interface, we made absolutely sure that 80% of our customers, who normally have little or no scripting experience, can still use Monad/Exchange cmdline to auotmate or perform their tasks. Eileen has a similar question on her weblog as well. Let me give some examples (these are all public already so you'll have to wait for new stuff later on, sorry!):
get-mailbox -server LAServer |
move-mailbox -targetdatabase OaklandSG\OaklandMDB
What is this line doing? It looks cryptic as the syntax is new and there's the new operator "|" in the middle of the sentence. The "|" character should already be familar to the unix folks, and is possibly the first (and only?) concept that you have to learn to get some good mileage out of the Exchange cmdline. What it means is: take the results of the operation on the left hand side and pass those results to the operation on the right hand side. Like this:
a | b | c
First "a" runs, and the results are passed to "b", which then consumes those results and then passes them to "c". Think of it as a pipeline of workers in a car plant. The first worker creates a car specification:
make-carspecification -output "new Car Spec"
Then the second worker takes the specification and creates a working model out of it:
make-carmodel -fromspecification "new Car Spec" -output "new Car Model"
Then the third worker takes the model and produces the actual car:
make-car -frommodel "new Car Model" -output "new Car"
Expressed as a pipeline (remember: in a pipeline results from the first operation are passed to the second and so on), this simply becomes:
make-carspecification | make-carmodel | make-car -output "new Car"
As you can see, the pipeline operator takes care of the hard work of specifying the inputs and outputs everytime (you could do that if you wanted to manually). In the last operation (make-car -output "new Car"), we don't have any body to take the new car and do something with it, so we simply output it directly. In the future if we add a sales force to our Car pipeline, we could do:
make-carspecification | make-carmodel |
make-car | sell-car -tocustomer "Roy's Honda Dealership"
So the pipeline concept is really powerful as it allows you to bind together many interesting operations together to do something meaningful. Let's go back to the Exchange example:
get-mailbox -server LAServer
This statement says: "return all the mailboxes that are on server LAServer". So the full statement (remember: the output of the first command is consumed by the second command to do something interesting):
get-mailbox -server LAServer |
move-mailbox -targetdatabase OaklandSG\OaklandMDB
says: "return all the mailboxes that are on server SvcServer and move them to the database OaklandSG\OaklandMDB". In a real world situation, this one line will move all the users that are in a server in LA to a mailbox database in Oakland. Imagine your company changed offices and during the office move weekend, the Exchange administrator needs to move all the mailboxes from a server in LA to a server in Oakland... well they could do it one by one or do it in bulk using the cmdline. The point is that you don't have to write "scripts" to get some serious mileage out of the cmdline.
Right about now, I usually get the question, so what if I messed up? What if I'm not sure what the cmdline is going to do? Well for that scenario we offer the following:
get-mailbox -server LAServer |
move-mailbox -targetdatabase OaklandSG\OaklandMDB -whatif
That will actually run the command without doing anything intrusive... basically its a way to "mock" what the command will do. In this particular case it will have output like this:
Whatif: Moving mailbox for "John Doe" to database
"OaklandSG\OaklandMDB"
And just in case you wanted to be absolutely sure you were doing the right thing, the system will automatically ask for confirmation for destructive operations. That means there is a safety cushion built in, out of the box, for cmdline users.
So I hope that was a helpful introduction to the world of one-liners and why they really express the true power of Monad and Exchange cmdline / scripting experience. You can write lots of complicated scripts, but the majority of time, you simply have to construct a one or two line pipeline.