Microsoft Virtual Machine Manager 2012 setup creates a logon for the Virtual Machine Manager (VMM) service account and adds it to the db_owner (DBO) role in the VMM database. Membership in the DBO role is required for the VMM service account. Removing the account from the DBO role triggers logon failures for end-users.
Assigning any combination of roles with lesser permissions and individual permissions instead of DBO for the VMM service account is not supported.
When a user connects to VMM through the console or a command shell, the VMM service dynamically adds the user to the VMM database. When the user disconnects, the VMM service automatically removes the user from the VMM database.
As a connected user performs actions, the VMM service runs EXECUTE AS statements to run database stored procedures on the user's behalf. For this to work, the VMM service account must have the IMPERSONATE permission on the user. Non-DBO users do not have this permission.
You cannot work around this limitation by explicitly granting the IMPERSONATE permission to a non-DBO service account because you can grant IMPERSONATE only on an existing principal. Because the VMM service dynamically adds and removes database users, you cannot grant IMPERSONATE permissions on them ahead of time. The user must exist at the time you grant permissions.
The SQL Server Language Reference specifically documents the requirement that a principal must exist when the IMPERSONATE permission is granted to him. The following is from the EXECUTE AS reference:
The user or login name specified in EXECUTE AS <context_specification> must exist as a principal in sys.database_principals or sys.server_principals, respectively, or the EXECUTE AS statement fails. Additionally, IMPERSONATE permissions must be granted on the principal. Unless the caller is the database owner, or is a member of the sysadmin fixed server role, the principal must exist even when the user is accessing the database or instance of SQL Server through a Windows group membership. For example, assume the following conditions:
CompanyDomain\SQLUsers group has access to the Sales database.
CompanyDomain\SqlUser1 is a member of SQLUsers and, therefore, has implicit access to the Sales database.
Although CompanyDomain\SqlUser1 has access to the database through membership in the SQLUsers group, the statement EXECUTE AS USER = 'CompanyDomain\SqlUser1' fails because CompanyDomain\SqlUser1 does not exist as a principal in the database.