Using VMware PowerCLI with Self-Signed TLS/SSL Certificates on vCenter

PowerCLI is one of the more popular scripting environments for VMware administrators and architects around the world, with good reason. It’s also something that newcomers to VMware environments often shy away from when errors are encountered.

Hoping to save you some time and a few clicks by sharing the most common first error that admins may bump into.  Many VMware vCenter environments are using self-signed TLS (aka SSL) certificates.  This is very common, especially with home labs.

My PowerCLI Won’t Connect to vCenter!!

The default configuration for PowerCLI is to require the use of a secure channel and to verify the certificate chain.  When first connecting to your vCenter without a certificate, or with a self-signed certificate, the command is super simple:

Connect-VIServer -Server YOURSERVERFQDN

Here is what happens:

The clear error condition shows that states “Could not establish trust relationship for the SSL/TLS secure channel with authority” for the FQDN (Fully Qualified Domain Name) of my vCenter server.

There is a simple fix for this.  The caveat with this fix is that you must be aware that you are enabling connections from PowerCLI to unsigned certificates.  As long as you are able to trust the target environments, this setting should be agreeable.  It must be noted just for the sake of proper security practices which should require the use of publicly signed or internally signed and validated TLS certificates.

Fixing TLS Errors for PowerCLI with the Ignore InvalidCertificateAction option

The configuration that needs to be set is the InvalidCertificateAction parameter.  When set to the default it will deny access.  The parameter must be changed by setting InvalidCertificateAction to Ignore which does not do a certificate check before performing actions using TLS.

The command is as follows:

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -confirm:$false

The resulting table shows the new parameter set as Ignore and now the Connect-VIServer will succeed even with our self-signed or invalid TLS certificate in place:

Hopefully this saves you some difficulty if the issue has stopped your PowerCLI from working as expected.

vSphere Announcement:  Goodbye C#, Hello HTML5 Client

No more C# client. It’s a new world where HTML 5 is the way to go. This is a very exciting announcement as we look towards the new iteration of VMware vSphere as it begins to trickle into the roadmap in the coming months. The web client has been something that has been a big push as a target for the day-to-day management of your VMware infrastructure.

The challenge is that a few people have one thing to say about this based on some experience in using the current iteration of the Flash based web UI…

But, I like the C# Client…

The real question is “why do we like it?”

– Performance – Let’s face it, we have seen some massive increase in speed when using the web client, but it is still not as quick as the native client. This is a reality that we will face, but I believe there will be additional improvements.
– Reliability – The Flash UI of the current web client has been know to be slow, and to fail altogether when used regularly.
– OVF imports work – the vSphere Client Plugin needed for the current web client will be retired as we move into the next HTML5 interface, so this will be addressed as a long-standing issue with the web client and common functionality.
– User Experience – we have grown used to the workflows and task flow as we do a lot of traditional administrative functions. This is less about it being “right” today, and more about what folks are just used to.

The reason that the new HTML5 client will be an advantage is that all of the features within the current Flash client will be available, as well as some of the legacy features that were left behind in the full, or what is often called the C# (C-sharp) client.

Remember that UI and UX are Two Different Things

This is the sticking point that people forget sometimes. UI is a view, whereas UX is literally user experience. That is the difference from what you see on the screen, to how you perform tasks within that screen. It is also notable that there are more than just VMware engineers who build features for the vCenter client. External partners have been asked repeatedly about making it easier to consume their platforms within the same UI as the day-to-day vCenter tasks.

There will be some challenges for external partners to make sure that they are all fully ready for the new HTML5 only interface. We have seen a lot of partner technologies ignore client integration altogether in order to avoid compatibility issues. That breaks from the elusive (aka unreachable) goal of the Single Pane of Glass.

What will it look like?

There has been the HTML5 vSphere Host Client fling available for a while (, so it isn’t difficult to see how the move is going to go. In fact, the fling is now a part of the general availability product now and is included in the core platform for vSphere 6.x from now forward. I’m a fan, but we also know that using multiple interfaces to achieve certain admin functions is a pain in the backside.


Image source:

Features are separated by client today. VSAN can only be managed by the web client. vSphere replication can only be affected by the web client. vFlash Read Cache can only be handled in the web client. You get where we are going. New features will only be developed towards the web client, and the transition of the last stragglers (SRM and some others) will be completed by the next iteration of vSphere.

Looking forward to the updated client that can be used across all browsers, and all devices. I’m a Mac user most of the time, and the current Flash UI plugin does not work on OSX with Chrome unless you literally open up the rights to give the browser complete root access…which nobody in their right, security-oriented mind would ever do.

Let’s see what the next few weeks brings as we prepare for the inevitable launch, or at least the announcement, of the newest vSphere product line at VMworld in Las Vegas.

Using PowerCLI to synchronize vCenter Notes with Active Directory description fields

Recently one of our awesome community members posed a question for a PowerCLI script to pull some information from Active Directory to update VMware vCenter guest attributes.

This is the fun of our scripting community because we can save a lot of time by asking the question among members and often they have saved some serious time by putting a script together already.

It is really great when I get to work among really great folks like the one and only @ExchangeGoddess who is a contributing author to the Petri IT Knowledgebase ( so this was particularly cool to be able to help out.

What are we trying to do?

Many admins who like to update our Active Directory computer objects with a description field so that we know exactly what our servers or workstations are used for. If you don’t already do this, I highly recommend it.


What we want to do is get this information into our vCenter guests though because that is where a significant amount of our administration happens. Once the object is created we don’t go back to Active Directory Users and Computers (ADUC) as much. This is where we can use our Annotations field in vCenter. As you can see, it starts off empty:


How will we do it?

Luckily the content that we are looking for is easily accessible from the properties of the guest objects in both AD and vCenter. We want to go through our vCenter to find VMs, then query Active Directory for the object. From there we query the AD object for a Description field and then feed that content back to the VM guest into the Notes area as the Description field there.

Let’s get to the script!

SPECIAL THANK YOU: Thanks to Stevo (see comments section) for adding to the script to fix up issues where I wasn’t clearing the variable which could cause some problems.

Our script is pretty simple, but has a few prerequisites needed in order to run. For our environment, we need:

Once we meet those needs, create a .PS1 file using the following code:

# Import the Active Directory module for Get-ADComputer CmdLet
Import-Module ActiveDirectory
# Connect to vCenter
# Pull your VMs into an array
$Guests = Get-VM
# Loop through the array to read the AD Description field to set the Annotation in vCenter
ForEach ($Guest in $Guests) {
# Clear the variable just in case there is no match. It may keep the previous value.
Clear-Variable Description
Clear-Variable ADComputer
  $ADComputer = Get-ADComputer “$Guest” -Properties Description
  $Description = $ADComputer.Description
  Set-VM -VM $Guest -Notes $Description -Confirm:$false

A quick note about this script is that it requires that your VM object name is the same as the computer name in Active Directory. Secondly, we are doing no error handling in the script, but if the machine isn’t found in AD it just errors out and moves to the next object.

Once we run the script, you can check your vCenter object on the Summary tab and as if by magic, there it is:


So now that we have the script, we should take the next step and configure this process to run regularly. I’m all about automation wherever possible, and this is a perfect candidate for a batch process.

Running PowerCLI as a Scheduled Task

Because PowerCLI requires loading PowerShell with some environment wrapped around it we can’t just load the modules using Import-Module like we can with the RSAT extensions.

While I could write about how to do this, this is a great way to promote some more awesome content, so head on over to view Magnus Andersson’s post on doing just what we want to do:

So now you will have a nightly load of your Active Directory computer object content into your vCenter. You can adjust the machines that are being queried in the vCenter environment by adding some parameters to your Get-VM query. It’s just that easy 🙂

Thanks to Phoummala for the inspiration, and to Magnus (@magander3) for the great post on Windows Scheduled Tasks using PowerCLI. I hope that you all find this helpful!


Appliances and OVF: The packaged approach to deployment

Appliances are a great way to approach system deployments for your VMware environment. We are seeing more and more of this method of delivery of application environments, and with the increased number of vendors jumping on board, this is a sign that something is being done right.

What is an Appliance?

The appliance in a VMware sense is a packaged server with a pre-installed application environment that is provided in OVF format which we can deploy directly into our vSphere environment without having to build the base machine and do all of the installation process ourselves.

Using appliances is much like the physical, black-box approach which can ease the pain of getting a new application environment up and running. Configuration is done minimally through the console, and a web application is almost always the way to complete additional customization and configuration.

Using the OVF Format

OVF, or Open Virtualization Format, is an industry standard for packaging defined by the DMTF (Distributed Management Task Force) to provide vendors and software providers with a supportable and standards based delivery format. Details on the OVF standard can be found here:

A virtual appliance will come with a pre-configured virtual disk file and a configuration file to provide the vSphere with what is required to craft together the virtual machine including any additional hardware items such as network cards, drive controllers and anything that can be delivered as virtual hardware via the vSphere platform.

What wizardry is this?

The OVF deployment wizard in vSphere walks you through the configuration of specific virtual hardware including the selection of disk type, location, network type and location, IP configuration and also the VM location including resource pool, cluster and folder.

Very simply, you open the vSphere Client and under the File menu, select Deploy OVF Template. This will bring up the deployment wizard as you can see below.

The end result of the wizard is a fully functioning virtual guest. It doesn’t get much simpler than that.

Why OVF?

A question that people may ask is “why use an OVF instead of just a VMDK and VMX file?”. The reason for the use of an OVF is to apply standardized deployment techniques to allow the deployer to make the choice about hardware specifics within their own environment.

Another clear reason is that the OVF standard is defined for open use across hypervisors. Yup, some people use other ones 😉

Using OVF makes the build and deployment of virtual appliances a snap, and for any vendor, enabling their customers is key when getting products to market.

What is the difference between OVF and a virtual appliance?

OVF is a virtual machine packaging method. The virtual appliance is the product itself. It is typically a blackbox type of build which would be not much different than a 1U server that you would have put into your physical network rack.

Using VMware Studio ( you can build your appliance using a supported operating system (Supported OS list here) and package your application build.

You can also deploy a vApp with an OVF so you are not limited to a single machine deployment. Using the first-boot configuration script you  have plenty of options for post deployment configuration. There are also a lot of great resources for building your OVF so getting help is just a few clicks away.

Should OVF replace my VM Templates?

Unless you have a lot of pre-defined applications and packaged builds, you probably won’t see the benefit of using OVF machines for your corporate environment. What you should concentrate on is the automation of your builds with other great tools like vCenter Orchestrator.

There may be some cases in your corporate environment where OVF is appropriate so perhaps you could give it a try and the worst case scenario is that you will become more familiar with build automation and deployment scripting, and nobody will lose in that scenario 🙂

What about upgrades?

The upgrade process can be scary with any environment. Many virtual appliance vendors will provide a simple configuration backup process (export to file, FTP etc…) and you can simply deploy an upgrade in place. It is even possible to use Update Manager to upgrade your virtual appliances.

The long and the short of it is that virtual appliances are fast becoming a part of many production environments and it may be a great way for you to speed deployment and ease the installation process for products. Anything to reduce the workload is definitely a positive step in my opinion.

The VMware Appliance Marketplace

Now that you are ready to take a look, there is no better place to begin than the VMware Virtual Appliance Marketplace. Through the marketplace site you can search for various application solutions from the VMware Certified vendors and from other supported parters who provide appliance based solutions.

So have a look around, and happy deploying!