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/