Hi folks, this is Vladimir from the VMM team and today I want to discuss an issue with System Center 2012 Virtual Machine Manager (VMM 2012) and VMware vCenter 4.1 that I saw few weeks ago. The summary of the issue is this: A VMM 2012 Self-Service user receives the following error when trying to connect via console to a VM running on a VMware cluster of two ESX 4.1 hosts either from the VMM Self-Service Portal, the VMM console, or System Center 2012 AppController:
VMConsoleParamsFetchFailure (20700) Could not retrieve console parameters for virtual machine %VMName;. Ensure that the virtual machine exists and that the host %VMHostName; can be contacted, and then try the operation again.
The VMM 2012 Administrator is able to connect via the console to the same VM without any issues. My initial thought was that this is related to the permissions issue somewhere between VMM and vCenter, and my guess ended up being correct. A VMM trace showed the following:
GetVmConsoleParameters.cs,126,0x00000000,Trying to get run as account with username SCVMM.vm-41 and associated with vm 247ac427-fa90-4522-9a28-77903973aea7
ClientConnection.cs,267,0x00000000,Exception during context of an indigo call; carmine error code returned 20700 ClientConnection.cs,267,0x00000000,Microsoft.VirtualManager.Utils.CarmineException: Could not retrieve console parameters for virtual machine <VM_NAME>.
at Microsoft.VirtualManager.Engine.VmOperations.VMConsoleOperations.GetConsoleParameters(Guid vmObjectId; ConnectionProperties connProperties) at Microsoft.VirtualManager.Engine.Remoting.ClientConnection.GetVMConsoleParameters(Guid vmObjectId) at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance; Object inputs; Object& outputs) at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc) at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet) *** Carmine error was: VMConsoleParamsFetchFailure (20700)
I have two environments. One where the issue is occurring and one where the Self-Service users are able to connect via console to VMs, so I started comparing them.
After some troubleshooting I was able to understand what is causing this. In short, when we add vCenter to VMM 2012, we have to use an account that is a local administrator on the Windows server where vCenter server is running. That account needs to be a vCenter Administrator as well. The reason why we experienced error 20700 is because VMM 2012 was not able to create and configure the required users, user roles, and permission on the vCenter server. The account used to add vCenter to VMM2012 possibly did not have all the rights that VMM needs. When the account has enough permissions, this is what VMM 2012 does on vCenter to enable VMM Self-Service users to connect via the console to VMs on the ESX hosts:
1. VMM creates a run-as account (SCVMM.vm-xx) that it uses to enable Self-Service users to connect to vCenter. It also specifies for which VMs this run-as account should be used.
2. Then on the Windows machine where vCenter server is running, VMM creates a local user account with the same name as the run-as account created above.
3. In vCenter, VMM creates two user roles (SCVMMSelfServiceUser and SCVMMConsoleUser), gives those user roles Console Interaction permission, adds local account SCVMM.vm-xx to the SCVMMConsoleUser role and then assigns SCVMM.vm-xx permission to the VM to which the VMM Self-Service user has access to.
NOTE Most of these users, user roles, and permissions are created/configured when the VMM Self-Service user tries to connect to a VM via console from the Self-Service Portal, VMM console, or System Center 2012 AppController.
In my case, we resolved this issue by removing vCenter server from VMM and then adding it back using a domain account that was a local Administrator on Windows machine where vCenter running and also a vCenter Administrator. In theory, you can use a local account too, but for some reason using the local account in one of the environments caused this issue. The steps to add a vCenter server to VMM are described here: http://technet.microsoft.com/en-us/library/gg610681
I hope you found this post interesting and helpful. See you soon!
Vladimir Petrosyan | Support Engineer | Management and Security Division
Get the latest System Center news on Facebook and Twitter:
App-V Team blog: http://blogs.technet.com/appv/ ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ DPM Team blog: http://blogs.technet.com/dpm/ MED-V Team blog: http://blogs.technet.com/medv/ Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ Operations Manager Team blog: http://blogs.technet.com/momteam/ SCVMM Team blog: http://blogs.technet.com/scvmm Server App-V Team blog: http://blogs.technet.com/b/serverappv Service Manager Team blog: http://blogs.technet.com/b/servicemanager System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials WSUS Support Team blog: http://blogs.technet.com/sus/
The Forefront Server Protection blog: http://blogs.technet.com/b/fss/ The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/ The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity- support/ The Forefront TMG blog: http://blogs.technet.com/b/isablog/ The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
Your solution works for vCenter 5.1 and below but not for vCenter 5.5. I have a situation where the vCenter SSO component is on a different server than vCenter as well, so the local accounts it created on the vCenter server don't apply and cannot be applied to permissions within vCenter. As of 5.5 and SSO, you can no longer add local server accounts to vCenter permissions. Any thoughts?
Resubmitting as my Live ID, so I get email updates.
I've tried your solution against an VSphere 5.1 but even with local administrators membership and VSphere administrator right the SCVMMConsoleUser and the service accounts are never generated by SCVMM...
The run-as account exists in VMM but is never created by VMM on the VCenter.
I've found another possible root cause linked to the same problem: You are NOT using the Administrator account to access the VCenter but another account member of the BUILTIN\Administrators account.
In this case you have to do the following to use this "service account":
1. Run cmd as an administrator and issue "reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f"
2. Run cmd as an administrator and run WINRM QUICKCONFIG
By default other members of the BUILTIN\Administrator are not autorized to use WINRS/WINRM...