Justin Brant posed a question on Twitter that I tend to hear from a fair bit of folks at VMware User Groups (VMUGs), PowerShell User Groups (PUGs), and other events.

Here’s my attempt to dive into the answer in a bit longer format.

Simple, Functional Tasks

When getting to know any scripting language, I find it’s best to start by doing things you already know. In this case, using PowerCLI to perform simple tasks that you do on a regular basis. You do a lot of repetitive tasks every day, and building small, repeatable scripts to do these tasks is the key to freeing up your time so that you can dive deeper into automation. It’s a bit cyclical.

Think about a workflow that you have to execute regularly. What does that workflow look like? Can you map out all of the steps using a white board, Visio, or something similar? Try to break it down into the most basic steps possible.

For example, most of my scripts utilizing PowerCLI are focused on provisioning new servers. This usually encompasses creating a virtual machine from a master or template, customizing the personality of that virtual machine, and then placing it somewhere with the appropriate tags. Think about every step that is needed to do the workflow, and then sit down and see what you can do in PowerShell to utilize PowerCLI for each step.

[symple_box color=”blue” fade_in=”false” float=”center” text_align=”left” width=””]For a bit of nostalgia, you can also read my Tips for Getting Started with PowerCLI post, published back in February of 2012. Keep in mind that most of those instructions are horribly out of date, but the principles in the Scripting Exercises section still carry some merit.[/symple_box]

For now, don’t worry about making these tasks look pretty, although I recommend avoiding the “giant wall of text” by splitting up each task into it’s own bit of code. This can be done by using PowerShell functions (recommended) or, if you’re feeling lazy, just isolating each bit of code into an individual PS1 file.

Some other suggestions:

• Never insert values directly into your code, such as IP addresses, passwords, server information, and so forth. Learn to use Parameter inputs.
• Functions are your friend.
• Assume nothing. Always tell PowerShell what your variables should be, such as string, int, float, bool, etc.
• Be kind to yourself. Your first attempts are going to be ugly. I have some fairly ugly old code to prove it.

Learning Materials

With some goals in mind, it may be necessary to figure out the finer points of writing PowerShell code. For this, I suggest:

1. VMware vSphere PowerCLI Reference: Automating vSphere Administration (2nd Edition) – Luc Dekens, Jonathan Medd, Glenn Sizemore, Brian Graf, Andrew Sullivan, and Matt Boren
2. PowerCLI Cookbook – Phillip Sellers
3. Learning PowerCLI (Second Edition) – Robert van den Nieuwendijk

All of these are books that I’ve read and used in the past, and both offer some good primers on PowerShell, PowerCLI, and various recommended recopies for building code. Depending on your financial situation, you may want to pick up Robert’s book first (since it is the newest) and, as you progress further into the world of PowerCLI for automation, pick up the other two. With that said, that’s only a minor suggestion – all of the content is really good. In fact, I wrote a review of Phillip’s book back in 2015.

If you prefer something a bit more visual, Aaron Rosemund has a snazzy course over on Pluralsight entitled Getting Started with VMware PowerCLI and Automation. I haven’t watched it because, well, I haven’t had need of an introductory course, but he has high marks and the course materials is relatively fresh (2017). There are several other courses on there that you might also want to poke your head into, along with courses that focus on PowerCLI as part of their course, rather than all of it.

]This may also be a good place to point out that my 5 hour course Upgrading Your vSphere Environment is still available on Pluralsight as well. 🙂

Putting Tasks Together

Once you have written out the code to perform the individual tasks for your workflow, the next steps should focus on how to chain all of the tasks together. In my previous example, that would mean cloning a virtual machine, and then upon the success of that cloning operation, moving the virtual machine to the correct hierarchy location and perhaps powering it on. This is the very essence of orchestration and requires learning about passing along the results from one function (the outputs) as information for the next function (the inputs) in the form of parameters.

This is just a basic conceptual model that I’ve found to help folks who are looking to start learning PowerCLI. I get it – there’s a vast world of things that can be done, and the The Paradox of Choice is a real kick in the pants. Having goals in mind, especially when they relate to work you’re already doing, is almost always a great idea.

Once you’ve made your functions talk to one another without exploding, take a moment to bask in your awesomeness. Automating workflows is extremely gratifying. At this point, I’d suggest creating a GitHub account and posting your code online – just make sure there’s nothing sensitive in there (if you’re using parameters for input, there shouldn’t be).

Refactor, Learn, Improve

Now, refactor your code. This is a fancy way of saying “write it again, but make it more efficient and improve upon the logic.” It’s quite unheard of to get the code “right” the first time through, even if the execution of that code ends up working. This is doubly true when you give your scripts to someone else to execute. It teaches you how to handle errors, express your ideas clearly, and deal with all the crazy things do when they interact with your script. 🙂

Hope this helps!