Has anyone seen this?

From within the SCVMM 2012 R2 UR7 console, while attempting to add a new Hyper-V host to VMM it fails. There are 2 other Hyper-V hosts currently being managed by the VMM. You receive the following:

 

 

Error (2912)

An internal error has occurred trying to contact the spock.jctech.local server: : .

 

WinRM: URL: [http:// server1.contoso.local:5985], Verb: [INVOKE], Method: [Associate], Resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/scvmm/AgentManagement]

 

No mapping between account names and security IDs was done (0x80070534)

 

Recommended Action

Check that WS-Management service is installed and running on server spock.jctech.local. For more information, use the command "winrm helpmsg hresult". If spock.jctech.local is a host/library/update server or a PXE server role then ensure that VMM agent is installed and running. Refer to http://support.microsoft.com/kb/2742275 for more details

 

On the Hyper-V host the %SYSTEMDRIVE%\ProgramData\VMMLogs\VmmAgent.msi_<date> log indicate the VMM agent installed properly. In the control panel the VMM agent is listed.

JC

For the first issue :

What is the error message you receiving while installing the agent ?

For your second issue :

Di you updated the Agents on the existing hosts ?

Go to Fabric, Servers, click on the servers name, look if their state is good, and look if VMM asks you to update the agents.

Hi Sir,

>>An internal error has occurred trying to contact the spock.jctech.local server: : .

WinRM: URL: [http:// server1.contoso.local:5985], Verb: [INVOKE], Method: [Associate], Resource:

 

Please detail the server " spock.jctech.local " and " server1.contoso.local " .

I assume that " spock.jctech.local " is the host which is needed to be added into SCVMM .

 

According to the FQDN , it seems that they are in different domain .

If the two domain are not trusted , you may need to add it using " ... in an untrusted active directory domain  " .

 

First , please shutdown the firewall for test .

Please follow the article regarding troubleshooting issue of adding hosts :

https://support.microsoft.com/en-us/kb/2742275

Also please run command below to check the winrm configration (if it is possible you may post the result here ):

winrm g winrm/config

winrm e winrm/conifg/listener

Best Regards,

Elton Ji

The error message I get is the one posted....

All the other agent status is Green which is good...

Thanks for the reply Elton,

The server name is "spock.jctech.local"(New Hyper-V server) ... my find and replace didn't do a great job:)

The winrm command you referenced...is this ran on the VMM server or the Hyper-V server? Or both?

John

The WinRM command should be run on the Hyper-V server. To look if the server WinRM config is good.

Also check the firewall settings between VMM and the Hyper-V server. Is there a firewall between them ?

I've tried turning off the firewall on both system...same error...

Running winrm g winrm/config:

 

I compared the new Hyper-V host setting to the other Hyper-V host and heres the only differences:

 

Existing Hyper-V Host set to Client-CredSSP = False

 

New Hyper-V host set to Client-CredSSP = true

 

Running the winrm e winrm/config/listener on the Hyper-V host gets error:

 

The WS-Management service cannot process the request.  The resource URi does not support the Enumerate operation

 

Also noticed on the VMM server the MaxTimeoutms = 1800000, Hyper-V host set to 600000

john

Hi John,

So , the hyper-v host resides in another domain ?

Did you check the input command ?

Did you try to run this command on other computer to check the output ?

(because , misspelling URI " winrm/config/listener " may cause that error )

If the command is correct , please check if the registry entry exists in hyper-v host :

"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Listener\"

In addition , I would suggest you to put the hyper-v host into a new OU and " block inheritance " to narrow it down .

Best Regards,

Elton Ji

I figured it out...this is one of the strangest one I've run into...the issue was the SQL login account name which is the same account used as the VMM service account some how was different. Meaning the VMM service account included 2 dashes in its name and the account in SQL only included one. There was no signs in AD that the account was renamed...Not sure how the account got in SQL (because it was not present in AD ) or how VMM was working prior to this...

The fix was just renaming the account in SQL to match the real VMM service account and everything worked... (Note renamed vs replaced) ... thanks for all the help..

John

• Marked as answer by JohnC_Live 6 hours 34 minutes ago