Like this:

There have been a lot of blog posts around warning us that starting from vSphere 5.5 Update2d (build 2403361) TPS will be basically turned off.

Besides comments about the why and how to partially re-enable inter-VM TPS I just think in most cases it might make sense to restore the original behaviour; I have been in the process of upgrading an infrastructure where the RAM contrain represented a much bigger concearn than the specific security reason why TPS has been turned off so I decided to take a look at the shared memory metrics in vCenter just to find out that post-upgrade situation wouldn’t be exactly heavenly if all the shared memory pages would be translated into unique pages.

I found this arcicle KB2097593 where it explains the various status of the settings you can apply and one of them basically disables the new behaviour restoring the old fashion TPS:

In other words setting the value “ShareForceSalting” to 0 will bring things back in time.

Like this:

Recently I’ve been fighting with a vSphere environment and CA certificates and I thought a lot about certificate management and lifecycle in a VMware vSphere environment after that and how much it needs improvement. With the SSL Certificate Automation Tool VMware made a step in the right direction and even if the tools itself is sometimes a little buggy it is still very handy in automating a long and error prone process. In vSphere 6 VMware is taking another step in the right direction to help us create, apply and manage SSL certificates in a vSphere environment, but before talking about this we need to talk a bit about what’s new in SSO and vCenter architecture in vSphere 6. Since the introduction of SSO VMware changed its architecture in every major release, starting from 5.1 to 5.5 and now to 6.0 so let’s make a little bit of history:

The new vSphere 6 management architecture introduces two main roles that you can deploy, these are the Management Node and the Platform Service Controller (PSC); the reason behind this separation is to have a logical entity that will take care of the main management features while another entity will hold the core and security features of the solution. What is nice about this separation is that you don’t need a 1:1 ratio between Management Nodes and PSCs so you can install PSC on separate boxes and replicate between them and then have as many Management nodes as you need (as long as you are within the same SSO domain)

For HA scenario if you install PSC on separate boxes you will still need a load balancer. Supported solutions are Big-IP F5 and NetScaler so far.

You can obviously still install everything in one box:

You might have noticed that the HA model for SSO was active/passive in 5.1, then active/active in 5.5 and now is active/passive again; this is due to the re-engineering of the Secure Token Service (STS) which is moving to a new and more robust method of STS (known as WebSSO) which is the same already used by vCAC (or vRealize Automation if you will) and that will be used from now forward instead of the old 5.5 method (WS-Trust). Let’s see how services are spread out on each role:

Let’s take a look to the services within the Management Node and the PSC:

In the Management Node we can find services and features that every vSphere Admin feels very comfortable and familiar with such as vCenter Server, vSphere Web Client, Syslog Collector, etc., but two of them deserve a few words:

Virtual Datacenter Service: this service is new and it has been introduced to help mitigate the limitation connected with the Datacenter object in vCenter as a Management boundary.

(Optional) vPostgres: This component is obviously referring to the vCenter Appliance (thus optional) but I believe more and more new deployments or upgrades deserve to be considered a good fit for vCSA since VMware announced complete equality of features between vCenter installed on Windows and vCSA; leave alone the fuss of dedicating Windows licenses for vCenter which might not be a huge problem I just find the process of patching ad upgrading a vCSA simply amazing and it’s not a secret that products like EVO:RAIL make extensive use of vCSA. VMware wants to move all their services deployment model towards Virtual Appliances, this is not a secret and we need to get used to it, the sooner the better, but I’m digressing…

In the Platform Service Controller or PSC we find our old friend SSO (we have had a rough past but now we are on better terms) and quite a few new services:

VMware Single Sign-On

Secure Token Service (STS)

Identity Management Service (IdM)

Directory Service (VMDir)

VMware Certificate Authority (VMCA)

VMware Endpoint Certificate Store (VECS)

VMware Licensing Service

Authentication Framework Daemon (AFD)

Component Manager Service (CM)

HTTP Reverse Proxy

Describing all these services is out of the scope of this post but as you probably guess two of them will be our focus: the VMware Certificate Authority (or VMCA) and the VMware Endpoint Certificate Store (or VECS). But what are the roles of VMCA and VECS? The VMCA is no more or less than a CA, so you can:

Generate Certificates

Generate CRLs

Use the UI

Use the Command Line Interface to replace certificates

The VECS is where all certificates within the PSC are stored, with the only exception of the ESXi certificates that are stored locally on vSphere hosts, so here you can:

Store certificates and keys

Sync trusted certificates

Sync CRLs

Use the UI

Use the CLI to perform various actions

Since VMCA and VECS are part of the PSC, they will take advantage of the Multi-Master Replication Model which is offered by the Directory Service (VMDir) in order to achieve HA. In the past every service had its own user and required its own certificate but this is not the case anymore since we now have Solution Users (SU); since the number of services has increased significantly it would be impractical to manage the lifecycle of this many certificates so now we have 4 main SU that will hold the certificate used for a number of services.

What about use cases/scenarios in which I can implement VMCA? In what ways you can use this new tool?

Scenario 1 and 2 are similar: the VMCA is the CA that releases certificates for all Solution Users (SU), the only difference is that in scenario 1 the VMCA is the root CA and you will need to distribute the Root CA Certificate so that all corporate browsers will trust it, while in scenario 2 the VMCA becomes part of an existing PKI as a subordinate CA and you certificate trust.

In scenario 3 VMCA is installed but not used, CSRs are created and submitted to an external CA and VECS will be used to store certificates in PEM format.

My favorite is scenario 2 because most enterprises I see already have a PKI (Microsoft CA usually) and all clients already trust the CA certificates, so adding the VMCA as s subordinate is a non disruptive process with a very low maintenance impact on the PKI itself, it protects investments already made to implement the current PKI and preserves the knowledge to run the PKI.

Replacing certificates is still a CLI task (looks like Powershell will be involved) but VMCA and VECS are a very promising step toward the right direction for simplifying certificate lifecycle management in a vSphere environment.

Like this:

If you happen to run NetScaler and upgrade to build 2143827 of vSphere 5.5 you will run in very nasty issues.

Specifically, your NetScaler will go bonkers if you enter in the management web interface or even via SSH; in general all things that start a network increase in term of traffic directed to the NetScaler will make it crash.

When it doesn’t crash you will still experience network communication drops, hangs, connectivity issues and such and in a very random fashion too (just to add some fun).

Fortunately VMware gave us a workaround.

To work around this issue, add the line hw.em.txd=512 in loader.conf file.

Note: There are two loader.conf files. The two files are ./flash/boot/defaults/loader.conf and ./flash/boot/loader.conf.
Modify the first one and ensure to take a backup of the file prior to making the changes.

Like this:

I don’t know about you but I found it to be a little weird that there is not way to tell Mirage to move NTUSER.DAT and UsrClass.DAT when performing an hardware migration.

Considering Mirage uses USMT to migrate the user state mean that this is a precise choice from VMware and not a technological limitation.

Those two files include two pretty important user settings: the user portion of the registry and the user class of the registry.

If you want to have the migrated workstation to have exactly the same look and feel, including the customization of the single applications settings, icon positioning on the desktop and so on you definitely want to apply NTUSER.DAT and UsrClass.DAT as well; I am sure there are scenarios where you don’t want this but there are also scenarios but if you want you should be able to do it.

In the Factory Defaults this is explicitly forbidden, so if you want to apply NTUSER.DAT and UsrClass.DAT too you need to follow this procedure: