It just occurred to me that a very useful feature of PowerCLI never got the introduction it deserves. The feature is the Credential Store and as the name suggests its job is to store credentials. As a result:

1. Credentials are kept securely (no need to hard code passwords along with scripts)
2. You type less (no need to specify user and password to Connect-VIServer)

So, how does it work in practice?

Say I connect to my VC like this:

Connect-VIServer 192.168.10.10 –User Andrey –Password “my favorite password”

To use the credential store, I do the following:

New-VICredentialStoreItem -Host 192.168.10.10 -User "Andrey" -Password "my favorite password"

Now I can type just:

Connect-VIServer 192.168.10.10

When I don’t specify user and/or password, Connect-VIServer checks the credential store, finds my newly stored credential and uses it.

By default the credential store file is stored under the user profile directory. It is encrypted. If I got you interested, check “help *VICredentialStoreItem” for details.

Andrey Anastasov,

PowerCLI Architect

The new PowerCLI 4.1.1 has improved compatibility with scripts written for PowerCLI 4.0.1 and earlier.

PowerCLI 4.1 moved cmdlet output types to new namespaces. This introduced incompatibility with scripts which depend on output types’ full namespace path. To negate the impact of the change and to enable a transition period in which scripts can use full references to both old and new namespaces, PowerCLI 4.1.1 includes additional set of types which reside in the old namespaces (“the old types”) and are implemented by types in the new namespaces.

In practice, this means that code like:
function BackupVM ([VMware.VimAutomation.Types.VirtualMachine] $myVM) { … }
and
function BackupVM ([VMware.VimAutomation.Client20.VirtualMachineImpl] $myVM) { … }
works with PowerCLI 4.1.1 even though the correct (new) types are:
function BackupVM ([VMware.VimAutomation.ViCore.Types.V1.Inventory.VirtualMachine] $myVM) { … }
and
function BackupVM ([VMware.VimAutomation.ViCore.Impl.V1.Inventory.VirtualMachineImpl] $myVM) { … }

IMPORTANT: The described compatibility support is temporary. We plan to remove the old types in the release following 4.1.1. This means that no new scripts should be written based on the old types and legacy scripts should be updated to remove dependencies on the old types.

As always, it is advisable to avoid full namespace references where possible, and to reference types in the *.Types assemblies instead of their *.Impl counterparts.

Andrey Anastasov,
PowerCLI architect

Tonight we released PowerCLI 4.1.1.

Feature Highlights:

• ESXCLI functionality is now available directly through a new Get-EsxCli cmdlet
• Esxtop statistics through a Get-EsxTop cmdlet
• Enhanced vDS support
• Support for vCenter Server alarms
• Various host storage enhancements
• Encrypted credential store

The complete change log is available here.

In the next few weeks we’ll present the most exciting new features with specific posts so stay tuned. In the meantime don’t forget to download and try the new release.

In PowerCLI 4.1 we changed the namespaces in which output types live. This was done to improve the internal structure and enable other VMware teams to write cmdlets for the products they develop.

While the types remain the same (save for new features), the namespaces have changed and this affects scripts which use full namespace paths, for example:

if ($myObject -isnot VMware.VimAutomation.Client20.VirtualMachineImpl)

If you have scripts which quote full namespace paths, you need to replace the old namespace with the new one. A full listing of the changes is available in this file:
Download TypeMapping – PowerCLI 4.0.1 to 4.1

Here are few examples to give you an idea of what’s in the file:

VMware.VimAutomation.Types.VirtualMachine -> VMware.VimAutomation.ViCore.Types.V1.Inventory.VirtualMachine
VMware.VimAutomation.Types.VMHost -> VMware.VimAutomation.ViCore.Types.V1.Inventory.VMHost
VMware.VimAutomation.Client20.VirtualMachineImpl -> VMware.VimAutomation.ViCore.Impl.V1.Inventory.VirtualMachineImpl
VMware.VimAutomation.Client20.VMHostImpl -> VMware.VimAutomation.ViCore.Impl.V1.Inventory.VMHostImpl

You can always check for incompatible types with a simple script:

A substantial portion of PowerCLI 4.0 U1 users report extremely slow startup. On affected systems PowerCLI takes very long (sometimes up to 5 minutes) to start. Standard PowerShell window opens as usual.

The problem appears when a machine does not have Internet access. The cause is a security feature of Windows – checking for revocation of software publisher's certificate. The problem is not specific to PowerCLI. Other applications on the same machine which use certificates are affected as well.

To avoid the delay, disable the following option:
Windows > Control Panel > Internet Options > Advanced > Security > Check for publisher's certificate revocation

For details, the original discussion in the forums is:
http://communities.vmware.com/message/1438321

We did two live demos as part of VI Toolkit’s breakout session at VMworld Europe 2009. A while ago, I made a post about the network monitoring demo. As LucD politely reminded me : ) it’s time to finish the job with a post on the second demo. In it, PowerShell scripts were sending mouse and button clicks to a virtual machine’s guest OS to automate installer which otherwise does not support unattended installation…

Every once in a while I find myself in a situation where I can save tons of work with a very simple UI automation. In this specific case, I’m upgrading the VMware Tools on my VMs. The Update-Tools cmdlet is the right tool for the job. There’s a small problem in my case though…

The new version of VMware Tools I’m installing is still a beta and hasn’t passed Microsoft’s driver quality tests. So when Update-Tools runs the installer, Windows pops “unsigned driver” confirmation dialog and blocks the installation. In result, Update-Tools blocks on the first VM. That’s where UI automation comes into play. I need a script which goes inside the VM’s guest OS and clicks on the confirmation button.

Windows Automation Snapin for PowerShell (or WASP) is a set of cmdlets for UI interaction. UI interaction includes stuff like finding windows and controls and sending them mouse clicks, keyboard input, etc. Sounds like the right tool for my task. I’ll need to run it not on my machine but inside each individual VM. VI Toolkit’s cmdlet for in-guest execution is Invoke-VMScript.

Finally, below is the script. Two notes:

–       You need to be connected before you run it.

–       For simplicity’s sake (this was a VMworld demo), the script only operates on a single machine. Extending it to work on a set of VMs is pretty straightforward.

We did two live demos as part of VI Toolkit’s breakout session at VMworld Europe 2009. This post is about the first demo which featured some network configuration monitoring and Carter’s cell phone beeping loudly when he received the alert emails…

So, you’re a VI system administrator and you have a policy that no VM can be simultaneously connected to the Intranet and the DMZ. With all the configuration changes going on, it would be nice if a script could monitor the network and drop you an email when some change breaks the policy.

With VI Toolkit stuff like this is pretty easy. How about getting all VMs and then examining each one’s network configuration? Sounds about right but it could be a bit slow if you have a large number of VMs. Let’s tweak it a bit by first looking at the Virtual Center’s even log. Filter only events which show that a VM’s network was reconfigured. Then go check only those VMs.

You want a script which runs the check repeatedly until you stop it. So, each time, it needs to look only at the events, created since the last check. And with PowerShell’s native access to .Net library, sending email is a piece of cake.

Finally, here’s the script itself (you need to be connected before you run it):