In the previous blog post, I tempted your imagination with an omnibus PowerCLI script with Swiss Army knife abilities. Either successful or not, I am determined to continue. As such, the time has come to see how this script can be addressed in real life.
For the record, the goal is to create a script that would be smart enough to find and load the PowerCLI objects into a regular PowerShell console or, even better, to work with the Windows PowerShell Integrated Scripting Environment (ISE). This would make scripting PowerCLI snippets an easy task. If you aren’t familiar with ISE, you can find the bare (and I mean bare) basics at https://msdn.microsoft.com/powershell/scripting/core-powershell/ise/introducing-the-windows-powershell-ise.
Once you get access to PowerCLI via ISE, we can plan the next steps — how to insert, keep and edit encrypted connection information for your VMware environment and, finally, how to add different tasks, snippets or sub-scripts able to perform, with minimal administrative effort, the variety of VMware-related tasks needed when working with Dell Data Protection | Rapid Recovery 6.0.x.
Without further ado, let’s begin!
A common sense question to ask is, “What prerequisites are needed?” The common sense answer is, obviously, PowerCLI. However, like any common sense statement, it means that a lot of groundwork was previously done.
First, you need to determine if PowerCLI is installed. For the sake of this post, we’ll suppose that you are working with PowerCLI 6.3 release 1, which is the recommended PowerCLI release and is available for download at https://code.vmware.com/tool/vsphere_powercli/6.3. This is the newest version of PowerCLI and, unlike older versions, it hosts VMware objects in modules as opposed to snap-ins.
Once the PowerCLI installation is finished, let’s see if the PowerCLI modules are available to PowerShell.
The important thing is to know that, for a 64-bit machine, the PowerCLI registry path is:
It goes without saying that no PowerCLI module is listed. Alas, there’s no direct way to access these modules straight from PowerShell.
Assuming that we intend to run PowerCLI tasks on an unfamiliar machine — a customer’s Rapid Recovery core, for instance — what is to be done to determine programmatically if PowerCLI is even installed?
The simplest way I could to think of is to check the existence of the corresponding registry key (some research was needed, but I will skip the procedure as there’s a lot more important ground to cover). From the registry key, we can determine the installation path and go from there.
If PowerCLI was installed at the default location, you’ll get the following installation path:
C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\
After a little digging through the folders available at that path, it looks like the PowerCLI modules are located in C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules.
There are quite a few of them. And attempting to load the main module (VMware.VimAutomation.Core) results in an error.
Trying a few others at random gets the same result. Looks like we’re out of luck.
Now comes the cool part. The most likely reason for the error above is that there are a few dependent sub-modules that need to be loaded, as well. You could spend the day attempting various permutations of which module to load first and you may succeed (and hope that none will change names or dependencies in the next release), but there is a better way.
PowerShell knows the location of the available modules from an environment variable called $PSModulePath, which I stumbled upon in another occasion, but it comes in handy now. To find it, just access the Env: provider.
The next question comes naturally and holds the key to the PowerCLI kingdom: What if we add the PowerCLI module path to the $PSModulePath (and remove it when it’s not needed anymore)?
Let’s do it.
Very simple indeed — just basic string manipulation.
Now, since the PSModulePath points to the location of the PowerCLI modules, we can try loading the main PowerCLI module again.
It worked. All is well now. And ISE works, as well.
Now that the groundwork has been put in place, you can take care of a few secondary, albeit important, issues.
It would be nice to access the desktop of virtual machines (VMs) without having to use the VMware client. PowerCLI introduced a commandlet, named Open-VMConsoleWindow, that is supposed to open VM desktop objects straight in your browser. However, if you try it, you are in for disappointment — this functionality is achieved via NPAPI, which is deprecated in all modern browsers.
I tried using the commandlet in Internet Explorer and Chrome to no avail. (To see what happens in Chrome, visit https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2114800.) And while I was able to use it in Firefox by using an add-on, there are little chances that will last when you take into account that Firefox is updated very often.
Even so, this feature is too cool to lose. There is a work-around, but another prerequisite — the VMware Remote Console (VMRC) — is needed. Like PowerCLI, VMRC is available for free. It allows running VM consoles without having to use the VMware client application or web GUI. Documentation is available at https://www.vmware.com/support/pubs/vmrc_pubs.html.
The logic for approaching VMRC is the same as for PowerCLI.
Returning to the script, if any of these prerequisites (PowerCLI or VMRC) are not present, you will see a menu that opens a browser at the download location. For instance, to download PowerCLI, the following code is needed:
At the end of a session, all connections should be dropped, PowerCLI modules unloaded and the PSModulePath adjusted by removing the PowerCLI modules path.
Suffice to say, all this functionality has been encapsulated into a function called start-powercli. It features a single switch parameter called unloadmodules. When used, it resets all settings as stated above.
To check how it works, load it in ISE and then run it. Enter a few VMware PowerCLI commandlets to prove that it works. Run it again (in the command line ISE console) with the unloadmodules parameter to undo all that was done!
The following image shows what it looks like when the function is running.
Please note: Registering with VMware is necessary to download VMRC, and you need to be logged in prior to attempting it. But, there is an option to download VMRC without registering at https://www.quest.com/community/
While this option exists, I would argue that, if you aren’t registered with VMware but are using their products, it is courteous to register. As such, I didn’t remove the “Register” option from the script.
Below are the various VMware web pages necessary to get the prerequisites.
If all prerequisites are present when running the start-powercli function, you’ll see the following screen.
Here, you can see a list of some VMware commandlets.
And here you see modules unloading and all settings reverting.
Next time, we will discuss how to script the VMware host connection information and use encryption to secure it.