There is a good variety of sessions from learning up to the expert, from VMware engineers (The guys who wrote PowerCLI) and also customers who use PowerCLI.

Personally I would like to accept all of them but hey, its down to you so go to the VMworld Voting Page sign in and vote for your top sessions.

I’m looking forward to automation and fun filled VMworld this year!

In this post I am going to show you how this can be done with a few lines of code and also share my lessons learned throughout this process. Let’s assume that you have list of VMhost IP addresses and all VMhosts have the same local administrator credentials, you want to join them to a domain and grant permissions for a domain user or group account assigning it a specific role. In the script I assume the role exists on the VMHost but later I will show you how to create a custom role.

The Set-VMHostAuthentication cmdlet is used for joining a VMhost to a domain. You should have in mind that the full domain name must be specified on the Domain parameter of the cmdlet.

Get-VMHostAuthentication -VMHost <VMHost>| Set-VMHostAuthentication -Domain <domain fullname> -User <domain user name for authentication> -Password <password for authentication> -JoinDomain -Confirm:$false

The New-VIPermssion cmdlet is used for creating permissions for a specified user. The user is obtained with the Get-VIAccount cmdlet which has the ability to retrieve Domain user or group accounts when the VMHost is joined to a domain. In contrast to Set-VMHostAuthentication the Domain parameter of Get-VIAccount expects the domain alias instead of domain full name.

You should also be aware that if you don’t specify an Id filter to the Get-VIAccount cmdlet it returns the maximum 5000 results and for domains with many accounts this could be a constraint. So it is recommended to use Id filter of the cmdlet itself instead of applying filtering over its results.

To obtain domain user accounts use –User switch.

Get-VIAccount -Domain <domain alias> -User -Id <user name filter>

To obtain domain group accounts use –Group switch.

Get-VIAccount -Domain <domain alias> -Group -Id <group name filter>

To grant permissions you should specify account to Principal parameter returned by the Get-VIAccount cmdlet, role which can be obtained by Get-VIRole or specified by name and entity which in our case will be the VM host.

New-VIPermission -Principal <VIAccount> -Role <VIRole> -Entity <VMHost>

Here is the entire script with a lot of input parameters needed by the used cmdlets in the script but the script itself is not complex:

param (

   [Parameter(Mandatory=$true, HelpMessage="List of VM host IPs")]

   [ValidateNotNull()]

   [string[]]

   $vmHostIPs,

   [Parameter(Mandatory=$true, HelpMessage="VM Host User Name")]

   [ValidateNotNull()]

   [string]

   $vmHostUserName,

   [Parameter(Mandatory=$true, HelpMessage="VM Host Password")]

   [ValidateNotNull()]

   [string]

   $vmHostPassword,

   [Parameter(Mandatory=$true,HelpMessage="Domain full name, required for joining hosts.")]

   [ValidateNotNull()]

   [string]

   $domainlFullName,

   [Parameter(Mandatory=$true,HelpMessage="Domain alias, required for retrieving domain accounts.")]

   [ValidateNotNull()]

   [string]

   $domainAlias,

   [Parameter(Mandatory=$true, HelpMessage="User name for domain authentication")]

   [ValidateNotNull()]

   [string]

   $domainUser,

   [Parameter(Mandatory=$true, HelpMessage="Password for domain authentication")]

   [ValidateNotNull()]

   [string]

   $domainPassword,

   [Parameter(Mandatory=$true, HelpMessage="Domain user name for which permissions will be granted")]

   [ValidateNotNull()]

   [string]

   $userNameToGrantPermissions,

   [Parameter(Mandatory=$true, HelpMessage="The name of the role you will assign to the user")]

   [ValidateNotNull()]

   [string]

   $roleName

)

foreach ($vmHostIPin$vmHostIPs) {

    # Establish connection to a VMHost

    $vmHostConnection= Connect-VIServer-Server $vmHostIP -User $vmHostUserName -Password $vmHostPassword

      try {

            # Get VMHost instance

            $vmHost= Get-VMHost -Server $vmHostConnection

            # Join the VMHost to a domain

            Get-VMHostAuthentication -VMHost $vmHost | Set-VMHostAuthentication -Domain $domainlFullName -User $domainUser -Password $domainPassword -JoinDomain -Confirm:$false

            # Get a domain account

            $viAccount= Get-VIAccount -Domain $domainAlias -User -Id $userNameToGrantPermissions        

            if (-not $viAccount) {

                  throw “VIAccount with Id ‘$userNameToGrantPermissions’ not found in domain ‘$domainAlias’”

            }

            # Get role to assign

            $viRole= Get-VIRole -Name $roleName

            if (-not $viRole) {

                  throw “VIRole with name ‘ $viRole’ not found.”

            }

            # Add permissions on VMHost

            New-VIPermission -Principal $viAccount -Role $viRole -Entity $vmHost         

      } catch {

            Write-Error (“The following error has occurred for VMHost ‘$vmHost’: `r`n”+$_)

      } finally {

            Disconnect-VIServer $vmHostConnection -Confirm:$false

      }

}

As you can see the script opens a connection to each VMhost, joins it to the domain and creates permissions for a specific domain account. It relies on the existing role on the VMHost, but it can be easily modified to create a custom role and assign it to the obtained user.

To create a new custom role the New-VIRole cmdlet needs to be used specifying a name and list of privileges on its input. Here is an example:

New-VIRole -Name MyCustomRole -Privilege ‘Anonymous’, ‘View’, ‘Read’, ‘Power On’, ‘Power Off’

The script is calling the Get-VIAccount with a –User switch parameter which filters on domain user accounts. In order to retrieve a domain group account the –Group switch parameter should be used.

So the script looks pretty simple and straightforward but running it I’ve experienced the following problem. Sometimes Get-VIAccount failed to retrieve the domain user immediately after joining the VMhost to the domain and I received the following error “Error accessing directory: Can’t bind to LDAP server for domain: <DOMAIN>”.

It seems that synchronization with active directory needs some time after a host is joined to the domain and the problem is not 100% reproducible. So I solved it with a simple retry-wait mechanism on retrieving domain users.

# Get a domain account

$viAccount=$null

$retryCount= 5

while ((-not$viAccount) -and ($retryCount-ge 0)) {

      try {

            $viAccount= Get-VIAccount-Domain$domainAlias-User-Id$userNameToGrantPermissions

      } catch {

            Write-Error “Getting VIAccount with Id ‘$userNameToGrantPermissions’ failed with the following error: `r`n $_”

            Write-Host “Next attempt in 5 seconds”

            Start-Sleep -Seconds 5

}

$retryCount–

}

Conclusion

In conclusion here are the lessons learned from this task:

1. Get-VIAccount requires to specify the domain alias to Domain parameter
2. Get-VIAccount limits the results to 5000
3. Sometimes Get-VIAccount fails to obtain domain users immediately after a VMhost is joined to a domain.

This gives you a quick restore method in case of issues or misconfigurations and also allows you to copy the entire VDS or port group configuration to a new VDS.  This feature is detailed by this VMware KB and is available via the vSphere Web Client, below you can see how we would do this via the web client:

Exporting the configuration with PowerCLI

With the introduction of the VDS cmdlets in PowerCLI 5.1 R2 we can also automate this process using the Export-VDSwitch and

Export-VDPortGroup cmdlets, the following examples show how we might do this:

We can also choose to backup each port group configuration individually, the following example shows how to do this for a single port group:

But what if we wanted to back up all our port groups for that VDS individually, we can easily achieve this with the following:

The code used for this example is as follows:

Get-VDSwitch -Name VDS-01 | Get-VDPortgroup | Foreach {
Export-VDPortGroup -VDPortGroup $_ -Description “Backup of $($_.Name) PG” -Destination “C:\Backups\$($_.Name).Zip”
}

Importing the configuration with PowerCLI

Now we have the exported configuration the next step is to look at how we could import these files again back into vCenter if an issue happened.  Of course each file could be imported from the vSphere web client individually but this post will show you how to do this with PowerCLI.

The code used in this example is as follows:

Get-ChildItem “C:\Backups\PG” | Foreach {
New-VDPortgroup -VDSwitch NewVDS -Name “New$($_.BaseName)” -BackupPath $_.FullName
}

As you can see from the below, we now have two DVS which have the same configuration:

Conclusion

Backing up the VDS and port group configuration can not only give you a backup in case of emergency but can also be useful for creating new switches with the same configuration, one use case for example is moving the VDS configuration between vCenters, like test & dev to Production.  The above examples show you how to automate this process with PowerCLI.

Don’t forget, the backup script could easily be scheduled to export on a weekly basis so that you have the latest configuration and multiple points in time to go back to.

Check out other new features in PowerCLI 5.1 R2 here

One of the most popular labs at VMworld is always the PowerCLI Lab, this was no exception in 2012, every year the PowerCLI team does a great job of adding new features to the latest version of PowerCLI and this is always a great way to check those features out in a test environment.

There has always been one issue with the HOL though, once you leave VMware you say goodbye to the HOL as access was previously at the event only….. Until Now.

There is now a public beta of the HOL Online, this gives you access to a number of different HOL Online for you to take at your own leisure and sat at the comfort of your own desk.

How do I sign up?

To sign up simply go to http://hol.vmware.com and click on the link as highlighted below:

Once you have filled out a few questions you will need to wait for your account to be activated (I have been assured this will be fairly quick).  Once activated you will be able to click on the “VMware Hands-on Labs Online” link as above and access a number of different labs, complete with their own isolated environment and full step by step documentation to run through the lab chosen.

How do I find the PowerCLI Lab?

Once you have gained access to the HOL and signed in use the left hand menu to select “Cloud Infrastructure”

Now scroll down the list on the right until you see the PowerCLI Lab, then click Enroll.

Once you have done this the selected Lab will be added to “My Enrollments” where you will be able to click the “Start this LAB” button to launch the lab as below:

The LAB will now start and you will have access as seen below:

Recently I had the pleasure of being interviewed on the PowerScripting Podcast by Hal and Jonathan, we talked about what was new with PowerCLI, what was cool in the world of PowerShell and also what I would do on a trip to Mars (I know – Random!).

For more information and ways to download the podcast visit their site here: http://powerscripting.wordpress.com/2013/03/13/episode-219-alan-renouf-from-vmware-on-powercli/

For more information on what’s new in PowerCLI 5.1 R2 make sure you check out this blog post: http://blogs.vmware.com/vipowershell/2013/02/powercli-5-1-release-2-now-available.html

After looking through the REST API Reference Documentation –> User Operations I found an entry for the VM VirtualHardwareSection  and specifically the disks which can be found as can be seen here: GET /vApp/{id}/virtualHardwareSection/disks

The virtualhardwaresection is easily accessed via PowerCLI using the extensiondata property which allows access to the back end API, I could then find my disk properties by filtering on the description of Hard Disk as in the example below:

(Get-VM MyCloudVM).ExtensionData.getvirtualhardwaresection().Item | Where { $_.Description -like “Hard Disk”}

Now I had the hard disk I noticed that part of the information was the capacity as highlighted below:

With this information I could then find the capacity of the disk and add the information I needed into more of a friendly PowerShell property to the Hard Disk object.

So tying this all back together we could easily use the .ExtensionData reference to create our own Advanced PowerShell function to return the hard disk information for any CIVM.

Example

The following shows an example of how to use this new function and the output, this of course can also be used to export into CSV/HTML/Text or any other format PowerShell can be used with, it is also great for reporting on where the disk space in your cloud is being used!

The Code

Function Get-CIVMHardDisk {
Param (
[Parameter(Mandatory=$True,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)]
$CIVM
)
Process {
$AllHDD = $CIVM.ExtensionData.getvirtualhardwaresection().Item | Where { $_.Description -like “Hard Disk”}
$HDInfo = @()
Foreach ($HD in $AllHDD) {
$HD | Add-Member -MemberType NoteProperty -Name “Capacity” -Value $HD.HostResource[0].AnyAttr[0].”#text”
$HD | Add-Member -MemberType NoteProperty -Name “VMName” -Value $CIVM.Name
$HDInfo += $HD
}
$HDInfo
}

}

Yes, PowerCLI can be used to connect to both vCenter and also the vSphere host independently, of course not all the cmdlets will be relevant if you connect to just the host but still, this can be useful during the initial setup or automated deployments of the complete infrastructure.

How to connect

If you are connecting to either a vCenter server or a vSphere Host the cmdlet is the same, you can use the Connect-VIServer cmdlet to connect to both of these (even at the same time), lets take a look at an example:

C:\PS>Connect-VIServer -Server vcenter01 -User admin -Password pass

In the above example you can see we are connecting to our vCenter server called “vcenter01” with a username and password to gain access to the vCenter server, we did not specify a protocol or port, by default HTTPS and port 443 is assumed which is the same as the vSphere Client or Web Client, unless you specify a –port or –protocol parameter for the cmdlet.

Credentials

In the example above we used the –User and –Password parameters to pass through the credentials but this might not always be what you want to do, especially as PowerShell files are plain text!  There are multiple ways in which we can specify the credentials or store the credentials, its really up to you which you use and which is best suited for your situation.

Pass-through

C:\PS>Connect-VIServer -Server vcenter01

If we do not enter a username or password parameter and just use the cmdlet like the above example then the credentials of the current user are passed through to the vCenter or vSphere host and used to try and authenticate the connection.  This is great if your environment is setup in the same domain as your vCenter box or your specific user account has been given access to vCenter or the host.  One thing to watch out for here is this may work whilst you are logged in but if you have a script which runs as a scheduled task or is to be run as another user then you will need to make sure the account running the scheduled task or as the other user also has vCenter access.

As a note, the Connect-VIServer cmdlet first tries Kerberos authentication, if this does not work it then tries NTLM authentication.
Kerberos should work for Windows based vCenters, the vCenter Virtual Appliance (VCVA) and ESXi when they are connected to Active Directory.

NTLM works only for the Windows vCenter.

To monitor the authentication and diagnose which is being used we can use the –verbose parameter with Connect-VIServer as below:

In the above case my pass-through authentication failed and I was prompted for credentials to the host.

VICredentialStore

With PowerCLI we have the ability to store credentials for connections to different vCenter Servers or vSphere hosts and it can  also be used to store credentials for vCloud Director when using the Connect-CIServer cmdlet, this feature is called the VICredentialStore, this becomes useful when we want to connect but do not always want to specify the username and password to use, the cmdlets we provide are listed below:

Get-VICredentialStoreItem    This cmdlet retrieves the credential store items available on a vCenter Server system.
New-VICredentialStoreItem    This cmdlet creates a new entry in the credential store.
Remove-VICredentialStoreItem    This cmdlet removes the specified credential store items.

The New-VICredentialStoreItem cmdlet creates a new entry in the credential store and encrypts the password. If there is an existing entry for the specified host and user, it is overwritten.  If the credential store file does not exist, it is created (along with its directory if needed).

If no file is specified, the item is created in the default credential store file %APPDATA%\VMware\credstore\vicredentials.xml.

Credential store items for vCloud Director servers must contain user name and organization in the following format: user_name:organization_name, where both names are lower-cased.

An example of this command is shown below:

C:\PS>New-VICredentialStoreItem -Host vCenter01 -User Admin -Password pass

Once this has been added to the VICredentialStore we are able to connect to vcenter01 without using the –User or –Password parameters.

A key thing to remember when using the Connect-VIServer cmdlet is that in a case where we did not provide a username/password parameter we first check the VICredentialStore. If the credential store doesn’t have the connection information for the requested server we try passthrough authentication. In a case where the credential store does contains connection information, but we fail to connect for some other reason (e.g. network connectivity) we don’t try pass-through and just show the error.

If a username/password parameter is used in the cmdlet then the VICredentialStore is ignored and the parameters are used for credentials.

Recently Connected Servers

Another nice parameter in the Connect-VIServer cmdlet is the –Menu parameter.  If you use the –Menu parameter it Indicates that you want to select a connection server from a list of recently connected servers. If Menu is set to $true, the cmdlet retrieves a list of the last visited servers and enters a nested command prompt, so that you can select a server from the list.

An example of this is shown below, this can be great if you connect to multiple vCenter servers as you don’t always have to remember or retype the names!

Connection Information

Now you are connected to the vCenter you can access a global variable which stores the connection information, this is the $defaultVIServer variable and contains the connection information:

If you connect to more than one vCenter or vSphere Host you will see that a new variable is created called $defaultVIServers this stores the connection information for all connected entities where as the $defaultVIServer will only be the most recent connection.

These variables can be used to check your connection has been successful and also used for further reference later on in our scripts.

Now you have learned how to connect to your vCenter or vSphere host and a few more tricks why not start trying out some of the other cmdlets!

VDS Cmdlets

Whenever I would ask the question at VMUG’s or VMWorld, “What would you like to see next from PowerCLI” I would always get the same answer “Support for Virtual Distributed Switches!”.

Previously there has been a fling available and also some work created by community member “Luc Dekens” to use VDS, this was a great start but in some cases was not a sustainable solution as it was either not supported or more complicated to maintain or use.

I am now pleased to tell you that PowerCLI has a new snapin, this snapin is called VMware.VimAutomation.VDS and is for managing Virtual Distributed Switches.

Introduced are 14 new cmdlets which will allow you to perform actions against your VDS configuration, we can use the Get-VdsCommand cmdlet to list the new cmdlets.

An overview of these are below:

Remember each of these cmdlets has help built in, to access the help including examples of how you might use these cmdlets use the following:

Get-Help cmdletname –full

PowerShell v3 Support

As well as the new cmdlets for working with Distributed switches and all the other great enhancements in PowerCLI 5.1 Release 2 we made sure we listened to our customers and with the release of PowerShell version 3 it seams that a lot of people are already making use or planning to install PowerShell v3.

You will be happy to know that PowerCLI now supports PowerShell v3, this not only gives you support from VMware but also we are now able to take advantage of some of the great enhancements which PowerShell v3 brings.

Some PowerShell v3 examples…

Simplified Syntax… Making PowerShell and therefore PowerCLI easier to read and quicker to type we can use simplified syntax to give us even more English like statements, before we would have needed to use the {} brackets to compare a property, now we are able to type it the same way we would think it…

The above simple example shows all virtual machines which are powered on.

vCloud Director 5.1 Support

With PowerCLI 5.1 R2 we have also added support for vCloud Director 5.1, you can now automate the latest version of vCloud director using both PowerCLI and PowerCLI for tenants in a vCloud Director 5.1 environment.

• Download

  Don’t delay, you can now download PowerCLI 5.1 Release 2 for admins and tenants here and continue the automation of your VMware environment, also check out the change log and online cmdlet reference for more information.

This blog post is not about how New-VIProperty works. There are several great blog posts on the internet which already explain how the cmdlet works and what its benefits are. Some of them are:

• LucD’s blog: Introduction to New-VIProperty – http://www.lucd.info/2010/07/13/powercli-4-1-brings-the-new-viproperty-cmdlet/
• Arnim van Lieshout’s blog: A great blog post about the performance of custom properties created with New-VIProperty – http://www.van-lieshout.com/2010/09/why-new-viproperty-matters/
• Jonathan Medd’s blog: A blog post about New-VIProperty and LucD’s VIProperty module – http://www.jonathanmedd.net/2011/08/using-powercli-viproperties-and-the-viproperty-module.html
• The PowerCLI blog: A blog post which explains in detail what happens under the hood of custom properties – http://blogs.vmware.com/vipowershell/2011/08/ability-to-customize-vi-objects.html
• LucD’s blog (again): A list of useful VI properties (downloadable as a PS module) http://www.lucd.info/viproperties/

We understand that using New-VIProperty is not that easy. There are a lot of things that should be considered when you create a property – the name of the type you want to customize, the name of the API property, etc.

This blog post includes a PS module whose purpose is to make the use of New-VIProperty easier, the module can be downloaded from here.

Once you import this module into your PowerCLI session, you will be able to:

• Benefit from tab-completion for the New-VIProperty cmdlet
• Inspect which types are customizable with New-VIProperty
• Inspect the properties of a particular customizable type in depth

Let’s take a look at the tab-completion feature

We can start creating a new property by entering “New-VIProperty –ObjectType“. Then, if we press the Tab key, we will iterate through the valid values for the ObjectType parameter.

Of course, when we know the first letters of the type we want to customize, we can enter them before pressing the Tab key. In this case, pressing the Tab key will iterate only through the types whose names start with the provided letters.

In the screen above, pressing the Tab key will show types like VirtualMachine, VirtualPortgroup, VirtualSwitch, etc.

If we are creating a value-based property, after the type has been defined, we should specify the API property with the –ValueFromExtensionProperty parameter. Now this is much easier using tab-completion.

So the type is VirtualMachine, and let’s say we want to add ToolsVersion. It is part of the Guest API property. So we can just enter “G” and then press Tab key. This time the tab-completion feature will search for all properties starting with “G” within the VirtualMachine backing API type. The first match is “Guest”.

After that we should add a dot and start pressing Tab until the desired property appears.

The Guest property has several sub-properties and after several hits on the Tab key we will reach the “ToolsVersion” property. The only thing left to do is give our new property a name. We will do this manually.

Tab-completion also works for the –BasedOnExtensionProperty parameter when you are creating a script-based property.

The second enhancement is the ability to retrieve the list of customizable types

The provided PS module exports the Get-VIPropertyValidTypeNames function. By default, it returns the complete list of types which we can customize using New-VIProperty.

Each type is represented by a PSObject with the following properties:

• TypeName – represents the string that New-VIProperty accepts through the ObjectType parameter
• IsManaged – indicates whether the backing API type is managed or not. For more information about managed and data object types, see the vSphere API SDK documentation
• VimTypes – a list of the backing API types. Knowing which is the backing type of a cmdlet type could be useful; for example, we can refer to the vSphere API SDK documentation for a more detailed description of the API type.

The function provides three filter parameters which let you reduce the list of types. Run “Get-Help Get-VIPropertyValidTypeNames” for more information.

The last enhancement is another function named Get-VIPropertyHelperObject.

This function accepts the name of a customizable type and returns a helper PSObject which could be used for:

• Inspecting the backing API type
• Searching API type properties by name
• Creating VI properties easily

Let’s see this in action. Let’s pass VMHost to the function and save the result in the $helper variable.

The structure of the helper object is based on the backing API object. It has the same set of properties, but their purpose is informative. The output of this object looks like this:

At the top we can see the cmdlet type –VMHost – and the backing API type – HostSystem.

The list of all API type properties follows. For each property, the type is also displayed.

A plus symbol in front of the property indicates that it has sub-properties and it is browsable. For example, if you write $helper.Config, you will see all the properties of Config.

The helper object also has a method named SearchProperties. It searches all properties and sub-properties by name.

Let’s assume that we want to add a property to all VMHosts which shows the vendor of the hardware box. We also know that there is a ‘Vendor’ property in the API object, but we are not sure where it is defined, so we can call $helper.SearchProperties(‘Vendor’).

The output contains all properties whose names contain ‘Vendor’. The last one is the property that we’re looking for.

The next step is creating a property and this is really easy with the helper object. The only thing that we have to do is to call this line: $helper.Summary.Hardware.Vendor.CreateValueProperty()

The helper object provides an identical method for each property within the whole structure. This method creates a VI property using the New-VIProperty cmdlet.

We can see that the method first shows the New-VIProperty expression which will be executed. Below this line, you can see the result of running the New-VIProperty cmdlet.

Let’s see the result of our actions:

This method is really useful for an interactive PowerCLI session, but what about if we want to create a VI property within a script. The helper object provides two methods named GetValuePropertyCreationCode and GetScriptPropertyCreationCode.

Both methods build and return a New-VIProperty expression which you can copy, paste and modify in your script.

Three of the methods have a parameter which accepts the name of the new VI property. If it is not specified (as it is not in the examples), a name will be selected automatically.

Summary

In conclusion, this module allows you to:

• Inspect API types easily and search their properties by name
• Create VI properties or generate New-VIProperty expressions to use in a script
• Retrieve the list of customizable types
• Use tab-completion within the New-VIProperty cmdlet

Finally, let’s see where New-VIProperty is applicable and why it is better to use:

• If you have a Select expression using hash table syntax
  • Get-X | Select-Object -Property Name,@{Name=”NestedPropertyName”;Expression={<some expression over $_>}}
• If your script needs data from the ExtensionData/View
  • foreach ($vm in $vms) { ….. $foo = $vm.ExtensionData.foo …..}
• The code look better
• The scripts are faster

Download

Download the module from here and import it into your session.

What Next?

If you find this module helpful or have any other comments on this feature we would love to hear them, the PowerCLI team at VMware constantly tries to make PowerCLI a better product and a product which is easy to use, let us know what you think of this and if you would like to see things like this backed into the release of PowerCLI.

Q.  “Does PowerCLI work with the vCenter Server Appliance?”

A. Yes it does, PowerCLI uses the vCenter APIs, in fact the best place to install PowerCLI is the same place that you would use the vSphere Client from, this is normally the vSphere admins workstation or a windows machine used solely for scheduled tasks.  PowerCLI connects to the vCenter APIs and therefore both Windows and the appliance versions of vCenter work with PowerCLI 5.1.

Q. “Does PowerCLI work with the vSphere Web Client?”

A.  A common question and yet in reality you do not need the C# vSphere Client or the vSphere Web Client in order for PowerCLI to work, everything you need is inside the installer for PowerCLI, just install it (instructions here) and your set.

Q. “With VMware releasing more and more Linux related appliances what does this mean for PowerCLI?”

A. PowerCLI is one of VMware’s most successful and well loved automation and troubleshooting tools by vSphere and vCloud Director Admins, as I said in the answer to a previous question, it connects directly to the vSphere APIs, it doesn’t care what is hosting them.

Whilst I can not discuss the roadmap for PowerCLI I can certainly say its as strong as ever and we will continue to wow the users of PowerCLI with the latest features and updates.

Q. “Does Onyx work with vSphere 5.1?”

A. For those of you who are not aware of what Onyx is, it’s a VMware Fling which sits in-between your vCenter and your vCenter Client, it intercepts the traffic and translates it into PowerShell code, not nicely formatted PowerCLI type cmdlets but still a great place to look if you need to find a way to do something quickly.

You hit play on the Onyx client and the fun begins, anything you do in the vSphere client from then on is captured and represented as code, and not just PowerShell code but also C#, vCO JavaScript and  Raw SOAP messages.

So does it work with 5.1 ?  Yes of course it does, but only when using the C# client, obviously the vSphere Web Client works differently and therefore Onyx is unable to capture the actions you take in the web client and turn them into code, as this is a fling I can not make any promises of if or when this will be updated to work with the web client but obviously the challenges are different.  In the meantime make sure you use the C# client when you want to capture the code.

Hopefully this will help eliminate any questions about PowerCLI and how it works with 5.1 and the future, if you have any further questions please add a comment to this post and we will do our best to answer them.