System Center Virtual Machine Manager 2012 SP1: Prepare Installation

Last Update: Sep 24, 2024 | Published: Jun 24, 2013

SHARE ARTICLE

This blog post will describe how to prepare your environment for a SCVMM 2012 SP1 installation. Be sure to check out these other articles in the series:

VMM Service Account

The default option in the setup wizard for authenticating and authorizing the VMM service is to use Local System. In the real world, you should create one service account for each VMM server/cluster that you plan to deploy. The requirements of this account are:

  • It is a domain-based user account
  • The user should not be a domain admin
  • Grant local admin rights on the VMM server to the service account
  • The account is used for nothing else

Distributed Key Management

The VMM database is going to store some sensitive information, including product keys and administrative credentials for managed systems/services. This data is encrypted by VMM. You can choose to store the key for access this data in a dedicated and secured container in Active Directory (it’s not a default option in the setup wizard). This is referred to as Distributed Key Management (DKM). You should choose to implement this for two reasons.

1. Create a VMM Cluster

The VMM service can be made highly available using an active/passive Windows Server failover cluster. This is important for environments where the VMM service becomes mission critical, such as a cloud where self-service has value to the business. This means that both nodes require a trusted, secure, and shared location to store the keys to access the sensitive data in the SQL database (on another server/cluster).

Don’t exclude this scenario straight away – you may deploy VMM on a single server today, but the business might require you to migrate the service to a highly available cluster at a later time. Using DKM when you deploy the first VMM server allows an easy migration.

2. VMM Migration

If you migrate your VMM service from one server to another, then you will lose access to your VMM encrypted data if you have not used Distributed Key Management. Using DKM allows you to permit the new server access to the keys, and therefore allows you to migrate your VMM service to other machines. For example, if you prefer to deploy new versions of Windows Server instead of upgrading.

Implementing DKM takes only a couple of minutes, and it provides you with a lot of flexibility. You should strongly consider using this feature.

Preparing for DKM

You will need to create a container in Active Directory using ADSIEDIT.MSC. This container can be called anything and stored anywhere, but the norm is to create a container called VMMDKM in the root of the domain; this aligns with most documentation and makes the container easy to find for new engineers and visiting consultants.
Do the following to prepare for DKM:

  1. Log into the domain as the same user that you plan to use when installing VMM.
  2. Create a security group for your VMM server(s). For example: VMM Servers.
  3. Add the planned VMM servers to this security group. Reboot these servers if Windows has already been installed to pick up the new group membership.
  4. Open up ADSIEDIT.MSC and connect to the domain partition of the Active Directory domain. Now create a container in the domain. This might be CN=VMMDKM, DC=demo, DC=internal, where you create a container called VMMDKM in the in the root of the domain called demo.internal.
  5. Edit the settings and advanced security of this new container in ADSIEDIT.MSC. Add your VMM servers security group as a new principal, and grant full control over this object and all descendant objects. This means that all VMM servers will be able store and manage their encryption keys in this container.

Setting permissions on the DKM container
Setting permissions on the DKM container.

 
Record the name and location of the DKM container for when you are installing VMM. You can use this container for all of your VMM servers in this domain.

SHARE ARTICLE