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