A couple of weeks ago i came across a weird issue what a VMM environment that was running fine.. until then.
When users started the VMM console and logged in, they got a the following error message:
“The SQL Server service account does not have permission to access Active Directory Domain Services (AD DS). Ensure that the SQL Server service is running under a domain account or a computer account that has permission to access AD DS”
The VMM Service was running fine it seemed, users just couldn’t log on. In this case it was a VMM HA Setup, even when failing over the role it still started and was running fine.
When Looking at the VMM error logs in C:\ProgramData\VMMLogs i got a more detailed error message:
“System.AggregateException: One or more errors occurred. Microsoft.VirtualManager.DB.CarmineSqlException:The SQL Server service account does not have permission to access Active Directory Domain Services (AD DS). Ensure that the SQL Server service is running under a domain account or a computer account that has permission to access AD DS.
System.Data.SqlClient.SqlException: Could not obtain information about Windows NT group/user ‘DOMAIN\username’, error code 0x534.”
In this case, the username was the username of the admin account of my colleague that installed the environment but left for another project. The IT Team deleted his admin account. VMM and SQL were all running with their own service accounts and they were al there. After some digging arround it turns out that the user that installed VMM is DBO on the VMM database. When that user account is deleted you get this error message.
How to Fix
This one is easy to fix, fortunately. Open the SQL Management Studio and open the new Query window and run it against the VirtualManagerDB Database. Excecute the command bellow to change the DBOwner from the deleted account to SA.
ALTER AUTHORIZATION ON DATABASE::[VirtualManagerDB] TO [sa];
After that you should be able to open the VMM console, login an run business as usual.
I personally work with over 40 VMM environments and did never encounter this one. I am not sure if this also triggered in a single node with SQL VMM environment or only in a HA VMM and HA SQL environment which is was in this case. But if you get this error with an HA VMM 2019 and HA SQL 2019 setup, there is a good change this fix helps you getting things up and running again.