Unable to create or access VMMDKM

A common error message one can get during SCVMM setup is:

Unable to create or access the Active Directory container ‘CN=VMMDKM,CN=System,DC=domain,DC=local’. Access is denied. Specify the distinguished name for the container and verify that you have GenericRead|CreateChild|WriteProperty rights on the container.

Well, it took me some time to find the root cause. And as this happened twice in the last few months, I decided to write it down and share it with you.

Why do I need a DKM container?

SCVMM needs a DKM container to encrypt several data like Run As Account credentials. You can either create a new DKM container when you setup SCVMM for the first time or you use an existing DKM container if you upgrade your installation from SCVMM 2016 to 2019, for example. Some further information can be found here: https://docs.microsoft.com/en-us/system-center/vmm/plan-install?view=sc-vmm-2019#distributed-key-management

Back to troubleshooting…

So in my case, I have a highly available setup containing of 2 SCVMM nodes. The environment was initially setup with SCVMM 2016 and a legacy service account (username & password). During the upgrade from 2016 to 2019 I wanted to replace the existing service account with a gMSA account, which is supported in SCVMM 2019.

So first I double-checked permissions on the DKM container in Active Directory. Both SCVMM Service Accounts (gMSA for VMM Service and legacy service account for database connection in my case) have full control permissions on the container and also on the objects itself. But still the setup failed with error message “Access is denied”.

Applies to “This object and all descendant objects” should be selected.

I also checked that inheritance is set to ‘This object and all descendant objects’, but still I got an access denied error. VMM Setup log under C:\ProgramData\VMMLogs also wasn’t helpful at all.

After some time I realized, that Domain Admins group was set as an owner on the DKM container. After replacing it with the actual service account (the gMSA one…), the setup succeeded without an error. Please make sure to replace the owner on all descendant objects as well!

Accidentally ‘Domain Admins’ group was set as an owner
Replace owner information with actual service account

Conclusion

When facing DKM access denied issues during SCVMM setup, please make sure, that:

  • new SCVMM service account has full controll on DKM container and on all descendant objects
  • new SCVMM service account is Owner of the DKM container and its descendant objects

I hope this information is useful and safes some time during your next SCVMM setup 🙂