Month: December 2015

PowerCLI 6.0 and vCheck, Vds Module

In PowerCLI 6.x, VMware began transitioning to Modules rather than PowerShell Snapins.  Read more about it here:

Chris Wahl wrote an excellent article about the PowerCLI changes, particularly how they affect VMware.VimAutomation.Vds:

Using this information, I submitted a pull request to the vCheck GitHub repository for two network plugins that use the VMware.VimAutomation.Vds cmdlets, with my changes to support the PowerCLI 6.x approach:

My goal was to preserve the original code as much as possible, while also adding support for loading the necessary cmdlets via modules.  Therefore I took two different tactics, following the method each original author used to check for the Vds cmdlets in their plugin.

Here’s a relevant snippet, in this case I am checking the build number to see if it is newer than PowerCLI 6.0 Release 1, and if so use Get-Module and Import-Module rather than Add-PSSnapin:


VICredentialStore, and scheduling vCheck with AD user and VICredentialStore

In this blog post, I am going to show you how to setup vCheck ( to run on a schedule, using AD user credentials, without requiring passthru authentication.  To do this, I will leverage the VMware Credential Store and New-VICredentialStoreItem PowerCLI cmdlet.

You may need to do this, if you cannot use passthru authentication from your script server to your vCenter server.

In this how-to, I assume you have already run vCheck’s initial configuration.  I also assume you have already created an AD user account suitable for running the vCheck script, and assigned permissions to vCenter (preferably read-only access).


Here’s a summary of the configuration:

  • AD user account with Log On as Batch Job locally on script server
  • Create a new role for vCenter, “vCheck Admin” assign the following rights:
    • Datastore -> Browse Datastore (necessary for finding orphan VMs)
    • Host profile -> View (necessary for checking host profile compliance)
  • Run PowerCLI as the AD user
  • New-VICredentialStoreItem -Host vcenter -User “domain\user” -Password “password”
  • Scheduled task to run Powershell with vCheck.ps1 as argument, start in vCheck folder

Configuring VICredentialStoreItem

First we need to get an item in the VICredentialStore, under the user account we will be using to run the script.

Enter the AD credentials for the user, then when PowerCLI launches, use the New-VICredentialStoreItem cmdlet to add an item to the cred store.

On Windows, by default this entry is stored in %APPDATA%\Roaming\VMware\vicredentials.xml

Please note – take security into consideration here.  The vicredentials.xml password format is obfuscated, not encrypted.  Ensure you have restricted access to this file and server to only authorized users.  Also make sure the AD user specified here has the most restrictive permissions possible – such as a domain user with read-only access to vCenter.

For more details on the hash function used to obfuscate the password, see the file available in the VMware Perl SDK for vSphere.  In short, VMware creates a unique hash based on username and servername for this entry, hashes the password using this unique hash, and then base64 encodes it.  This means that anyone with the full text of your vicredentials.xml file could obtain your plain-text passwords.  Protect this file if you are going to use this method.

Configuring Windows Scheduled Task

Now create a scheduled task with the following Action:

  • Program – C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • Add Arguments – C:\Scripts\vCheck-vSphere-master\vCheck.ps1
  • Start in – C:\Scripts\vCheck-vSphere-master\


Assigning AD User Rights to Windows

Finally make sure we assign this AD user Log On as a Batch Service…


Add the user under Properties.  Very straightforward.

When we run the scheduled task, vCheck’s connection script will run as the AD user we specified.  When it attempts to connect to vCenter using Connect-VIServer, it will automatically pull credentials from the entry in the VICredentialStore for this AD user.  It does this based on matching the server name in the credential store items with the server name specified in the Connect-VIServer cmdlet.

Hope this helps!  Just keep in mind the security caveats around using the VICredentialStore.


Recent Posts



GiottoPress by Enrique Chavez