In VMM2012, sensitive data like RunAs Account passwords are encrypted using the configured encryption technology.
There are two options for which technology to use for encryption key management. These are:
1. DPAPI: This is the default. All previous VMM versions use this. Encryption keys are stored on the VMM server.
2. Distributed Key Management: Encryption keys are stored in Active Directory. For Highly Available VMM installations, this is the only option for storing encryption keys.
Option 2 might have an initial configuration overhead; however, the encryption keys will still be on AD if the VMM server machine is lost, which aides in a quicker restoration. Especially, in the scenarios like formatting the VMM server machine, disk drive failure or reinstalling your VMM server on another machine, the keys will still be there. With Option1 you will need to redefine all your sensitive data like RunAs account passwords for these scenarios.
We will focus on Option 2 (Distributed Key Management) for this blog post.
In order to configure Distributed Key Management, during setup, you will be asked to enter the location in AD that you would like to use for storing your encryption keys. The location is the distinguished name of the container.
The prerequisite of Option 2 is that the user running VMM server setup needs to have the following access rights on the location that you specify during setup.
· Generic Read,
· Generic Write
· Create Child
Definition of these rights in AD:
Here is how you specify the AD location during VMM Server setup.
If the user running setup has the right to create container in AD (under Container1 or VMMDKM), nothing else is necessary. Here is what happens in detail.
1. VMM Setup checks if there is a VMMDKM container under Container1. If there is VMMDKM container already created in AD,
2. VMM Setup creates a new container under VMMDKM and gives necessary permissions to the VMM Service account for this new container. Note that the VMM Service account is also selected in this wizard page. For HA VMM installations Local System account is disabled.
3. If VMMDKM container does not exist in AD, setup tries to create that container first and then goes ahead with Step 2.
Below is how container looks like after setup;
I hope this information was informative and helpful. Please refer to our TechNet Library for more details on VMM 2012 setup.
Gokcen Iskender – Software Development Engineer
If you are going to have multiple different SCVMM 2012 HA installs, such as different groups running their own instance in a large company, do the SCVMM 2012 HA instances share the same root container where they create their own sub-containers, or do we need to create a separate VMMDKM for each one? We can't find the documentation to this anywhere.
Also can we create the VKDMM container down deep inside an OU path that one of those different groups might have? Such as: company.com/OU=Groups/OU=Engineering/CN=VMMDKM?