WilliamLam.com

New Nested ESXi 6.x Content Library 

by // 16 Comments

A few years back I had showed how you could create and host your own 3rd Party vSphere Content Library which allows customers to decouple their content from the underlying vSphere environment and centralizing their content and making it available to number of vCenter Servers by simply just having an HTTP(s) endpoint. The other huge benefit is being able to take advantage of the existing web content tools for optimizing delivery or retrieval whether that is replication, caching, etc. and not relying a single vCenter Server for providing Content Library publication. In addition to showing how to create your own content libraries, I also had built my own 3rd Party vSphere Content Library which contains a variety of my Nested ESXi Templates (empty VM shells) running on Amazon S3 which can be consumed by anyone as long as you are running vCenter Server 6.0 or newer.

Although the empty Nested ESXi Templates were quite useful for myself and customers, it would have also been nice to include my pre-built Nested ESXi Virtual Appliances which I had recently updated to support vSphere 6.0 Update 3 and vSphere 6.5d (vSAN 6.6). Thanks to Dana Nourie, who runs our wildly popular VMware Flings Program, was kind enough to help me with the content hosting and now anyone can also subscribe to my Nested ESXi VA's and automatically have the content sync down using the vSphere Content Library feature.

UPDATE 1 (07/31/17) - The Nested ESXi Content Library has been updated to include the latest ESXi 6.5 Update 1 VA. If you are already subscribing to the library, it should have already pulled down the content (or at least the metadata which you can then force synchronization) or you can simply subscribe to the library and have access to the latest ESXi VA.

UPDATE 2 (05/07/18) - The Nested ESXi Content Library has been updated to include the latest ESXi 6.5 Update 2 VA. If you are already subscribing to the library, it should have already pulled down the content (or at least the metadata which you can then force synchronization) or you can simply subscribe to the library and have access to the latest ESXi VA.

To get started, just create a new vSphere Content Library and enter the following subscription URL: https://download3.vmware.com/software/vmw-tools/lib.json 


You can either download the content immediately or only when you need to use it. I recommend the former since its only two images which totals up to a whopping 1GB 😉

Once the creation of the Content Library has been completed, you should see the following two Nested ESXi VAs in the library which are now ready for deployment!


For more information about the Nested ESXi 6.0u3/6.5d VA's and how they work, please have a look at this blog post here. For more information about the Nested ESXi Templates and how to subscribe to the 3rd Party vSphere Content Library, please have a look at this blog post here.

Auditing/Logging vCenter Server authentication & authorization activities

by // 1 Comment

Recently, I have seen an increase in the number of requests from our field and customers inquiring about logging various vCenter Server authentication and authorization activities. The topics vary from identifying which log files contain which activities to to why some of this information is not available in the vCenter Server Events UI or why they are available else where. In most of these cases, customers were also looking for a way to forward these activities to their remote syslog infrastructure for auditing and tracking purposes whether that is using vRealize Log Insight (which all vSphere customers get 25 free OSI licenses!) or some other logging solution.

Having explored this topic lightly in the past and given the amount of interests, I thought I would dive a bit deeper and look at some of the common authentication and authorization workflows and provide examples of what the log entries look like and where you can find them. However, before jumping right in, I think is is worth spending a few minutes looking at the history of authentication (commonly referred to as AuthN) and authorization (commonly referred to as AuthZ) for vCenter Server and where we had started from and where we are at today to give you the full context.

UPDATE (04/08/19) - Please take a look at this blog post here for all new auditing enhancements in vSphere 6.7 Update 2 which simplifies the consumption of vCenter and vCenter SSO auditing events.

History of vCenter Server AuthN/AuthZ

Prior to vSphere 5.1, vCenter Server handled both Authentication (AuthN) and Authorization (AuthZ). As a Client, you would connect directly to vCenter Server and the AuthN service will verify who you are whether that is a local account on the OS or an Active Directory user which required vCenter Server to be joined to your AD Domain. Once you have been authenticated, the AuthZ service will then take over and verify the privileges you have been assigned to perform specific operations within vCenter Server.


In vSphere 5.1, a new service was introduced called Single Sign-On (SSO) which now takes over for AuthN services from vCenter Server. Once authenticated, it will then allow you to connect to the vCenter Server which then handles AuthZ activities


Although it may not be apparent, one major implication is where are successful and failed authentications being logged? In the past, these would reside within vCenter Server since it handled both AuthN/Authz activities, vCenter Server even included specific authentication Events that can then be seen using the UI and/or API. However, with SSO in the picture, authentication is no longer in vCenter Server but with SSO. This is why when you have a failed login using the vSphere Web Client (Flex/H5) UI it does not show up in vCenter Server and it because the logging is done but within the SSO service (which now resides in the Platform Services Controller for more recent vCenter releases).

[Read more...]

Workaround to deploy vSphere Integrated Containers 1.1 OVA using PowerCLI (SHA256 not supported)

by // 2 Comments

Last week I had noticed several folks were having issues deploying the latest vSphere Integrated Containers (vIC) 1.1 OVA using PowerCLI. The following error message was observed when using the Get-OvfConfiguration cmdlet which is needed before importing an OVF/OVA:

PowerCLI doesn't support SHA256 hash codes in OVF manifest

As you probably have guessed, the issue is that PowerCLI currently does not support the SHA256 hashing algorithm, which the latest vIC OVA was generated with. I suspect this is probably related to the change with OVFTool 4.2 which now defaults to SHA256 which also has some implications on which vSphere UI you can use to import OVF/OVAs which I had written about here. As of today, PowerCLI currently only supports SHA1 and anything greater will not work. I have already reported this to Jake Robinson who is the PM for PowerCLI and hopefully this will get addressed in a future update.

In the meantime, you can deploy vIC using either the vSphere Web Client and/or ESXi Embedded Host Client, both support SHA256. If you wish to Automate the deployment of vIC, the only option right now is to convert the OVA from SHA256 to SHA1. You can easily do this by using OVFTool which is available on all OS platforms. If you already have downloaded the vCenter Server Appliance (VCSA) ISO, you can even make use of its bundled OVFTool in case you did not want to install OVFTool (You can find it under vcsa/ovftool in extracted ISO).

To convert the hashing algorithm, we just need to pass in our desire hash to the --shaAlgorithm parameter.

ovftool.exe --shaAlgorithm=SHA1 C:\Users\primp\Desktop\vic-v1.1.1_56a309fb.ova C:\Users\primp\Desktop\vic-v1.1.1_56a309fb-SHA1.ova

Once the conversion is done, you can delete the original vIC OVA and then use PowerCLI to import the new OVA just like you would with any other OVF/OVA!