Hi all

I have a problem with the SCVMM 2012 console. When I start the console I select the "Specify credentials" option and then I enter my admin credentials. Afterward the console opens and everything works except the "Connect via Console" function.

When I try to connect to a VM I get the following message:
Virtual Machine Manager lost the connection to the virtual machine for one of the following reasons: Another connection was established to the console of this machine. The virtual machine has been shut down or put into the saved state. The user credentials provided do not have the necessary privilege to connect (0x0003, 0x0300)

It seems that the Virtual Machine Viewer runs not under the admin credentials which I enter at the beginning and therefore the console cannot connect.

Has someone the same issue ? Is it by design that the console connection does not work with specified credentials or is a sort of a bug or error ?

Thx

J0fe

Hi J0fe,

Did you log in with your domain admin account used to install SCVMM 2012 ? Did you create an other administrator profile in VMM ?

Hi David

The account which I use to login to SCVMM was not ued to install SCVMM. But it's a domain account (Domain Admin) and it's a member of the predefined "Administrator" User Role in SCVMM. But I have the same issue when I login with the account which was used to install SCVMM....

Any update on this?   I'm having the same problem.

Hello,

we had the same issue after installing SCVMM 2012 on a server which earlier uses SCVMM 2008R2. The reason was that the VMs had no owner. After defining the owner everything worked fine.

Dirk

Are there any updates on this microsoft!?

I've just installed a new scvmm 2012 SP1 server. I installed the VMM console on my local machine (windows 7). I connect to the server using specified credentials (my domain admin account). Everything seems to work fine except for 'connect via console'. If I rdp to the VMM server using the same domain admin account and use the VMM console on the server then 'connect via console' works.

It seems the new window that is launch is not launched with the same admin credentials. UAC issue I presume.

Right click the Console and click "Run as Administrator".  Then you will be able to connect to the console, you also no longer need to specify your credentials.  You can also set this option in the shortcut to the VMM Console by right clicking the shortcut icon -> Properties -> "Change Settings for all users" then select the check box for "Run this program as an administrator".

Hi All,

I have faced  the same issue.

i Solved with the help of mentioned Permissions in Hyper-V Server to that user

http://blogs.msdn.com/b/virtual_pc_guy/archive/2008/01/17/allowing-non-administrators-to-control-hyper-v.aspx

Via Azman.msc in hyper-v , we can define Permissions to self service users

This does work but is not a good solution.........you will have to assign a "Self service owner" for each and every VM

no, it does not work.

Being new to SCVMM, I've just come across this issue myself, though I came to a different (not necessarily better, but good enough for me) resolution.

I have a somewhat convoluted but not abnormal configuration where the SCVMM server lives in a separate untrusted forest to that which the Hyper-V Server hosts live.

As people have noted in this and other threads, the VirtualMachineViewer.exe process launches in the same security context with which you logged onto your pc. While the VmmAdminUI.exe process also runs in the same security context, the network logon it issues makes use of the credentials provided at the SCVMM MMC's logon screen, which VirtualMachineViewer.exe does not.

I elected to use Credential Manager to resolve this issue.

In Credential Manager, I created a "Windows Credential" entry where the hostname matched the FQDN of the hostname that appears within SCVMM as the virtual host entry. Using an IP does not match if you've used an FQDN in the SCVMM registration, and vice versa. If you used an IP for the host in SCVMM, then you need to supply that IP as the hostname in Credential Manager, and likewise if you used a FQDN.

This solution isn't perfect as it requires you to manage numerous Credential Manager entries (one per host), but that still appealed to me far more than one per guest. If I had a larger environment, I'd script the account configuration given it only needs to happen once per host, rather than on an ongoing basis of once per guest as some of the above approaches would require.

I haven't tested the different combinations to verify the least permissions required. For the time being I've gone with the model of using a non-privileged domain user account (to avoid managing multiple identities and passwords) which I added to the local Administrators group of each Hyper-V Server host. This stuck me as being a sound enough compromise between rigid security and ease-of-administration (given the per host arrangement in Credential Manager).

With the account correctly specified in Credential Manager, I'm able to move on past the 0x0003 error and successfully use the remote function.

If I was to point out an upside to this, it would be that this approach would allow me to remote Hyper-V servers in untrusted forests (including workgroups), which is something I couldn't do if the VirtualMachineViewer.exe process did in fact use my SCVMM credentials alone. Ultimately, that's something you have to come to terms with yourself, though.

Cheers,
Lain

Being new to SCVMM, I've just come across this issue myself, though I came to a different (not necessarily better, but good enough for me) resolution.

I have a somewhat convoluted but not abnormal configuration where the SCVMM server lives in a separate untrusted forest to that which the Hyper-V Server hosts live.

As people have noted in this and other threads, the VirtualMachineViewer.exe process launches in the same security context with which you logged onto your pc. While the VmmAdminUI.exe process also runs in the same security context, the network logon it issues makes use of the credentials provided at the SCVMM MMC's logon screen, which VirtualMachineViewer.exe does not.

I elected to use Credential Manager to resolve this issue.

In Credential Manager, I created a "Windows Credential" entry where the hostname matched the FQDN of the hostname that appears within SCVMM as the virtual host entry. Using an IP does not match if you've used an FQDN in the SCVMM registration, and vice versa. If you used an IP for the host in SCVMM, then you need to supply that IP as the hostname in Credential Manager, and likewise if you used a FQDN.

This solution isn't perfect as it requires you to manage numerous Credential Manager entries (one per host), but that still appealed to me far more than one per guest. If I had a larger environment, I'd script the account configuration given it only needs to happen once per host, rather than on an ongoing basis of once per guest as some of the above approaches would require.

I haven't tested the different combinations to verify the least permissions required. For the time being I've gone with the model of using a non-privileged domain user account (to avoid managing multiple identities and passwords) which I added to the local Administrators group of each Hyper-V Server host. This stuck me as being a sound enough compromise between rigid security and ease-of-administration (given the per host arrangement in Credential Manager).

With the account correctly specified in Credential Manager, I'm able to move on past the 0x0003 error and successfully use the remote function.

If I was to point out an upside to this, it would be that this approach would allow me to remote Hyper-V servers in untrusted forests (including workgroups), which is something I couldn't do if the VirtualMachineViewer.exe process did in fact use my SCVMM credentials alone. Ultimately, that's something you have to come to terms with yourself, though.

Cheers,
Lain

Thanks a bunch Lain, this helped! I'd still consider this a bug, however, and not a workable solution for a large number of servers/admins... But for now this does the trick, thanks!

I found easier workaround:

Launch the console by right clicking while holding the shift key and select "Run as different user". Enter your admin credentials. Then, in the "Connect to server" dialog, enter the Server name and the admin credentials again.

After that, you'll be able to connect to any console where you have permissions.

EDIT: Eventually, you can bypass the first step by changing the shortcut to:

C:\Windows\System32\cmd.exe /s /c "runas /savecred /user:<your admin account> "C:\Program Files\Microsoft System Center 2012\Virtual Machine Manager\bin\VmmAdminUI.exe"

None of the supplied solutions are suitable for myself.

I have SCVMM 2012 SP1 setup for my developers and can't/won't give them full admin access to the setups so doing a runas isn't suitable.

Also, its works perfect for some people and not at all for others. MS needs to address this BUG.

I also just started getting this error message.

Adding the user to the Hyper-V Administrators group gives them access, which is not a fix.

I also just started getting this error message.

Adding the user to the Hyper-V Administrators group gives them access, which is not a fix.

I agree. I can't do this as I use the system for a large group of developers with many hosts in many host groups. I need a resolution that allows each user console access with out being an Administrator.