SCVMM Setup fails at post processing step: “server name could not be resolved”
Some times things go wrong and sh** hits the fan. But in my case I was pretty sure I’m doing everything correctly when installing a HA SCVMM Cluster. So almost at the end of the SCVMM Server setup process, the setup engine throw an exception and performed a full rollback.
12:36:12:VMMPostinstallProcessor threw an exception: Threw Exception.Type: Microsoft.Carmine.WSManWrappers.WSManProviderException, Exception.Message: VMM is unable to complete the requested operation because the server name scvmmcn1.domain.lab could not be resolved. Try the operation again. If the problem persists, contact your network administrator. 12:36:12:StackTrace: at Microsoft.Carmine.WSManWrappers.ErrorContextParameterHelper.ThrowTranslatedCarmineException(WsmanSoapFault fault, COMException ce) at Microsoft.Carmine.WSManWrappers.WsmanAPIWrapper.RetrieveUnderlyingWMIErrorAndThrow(SessionCacheElement sessionElement, COMException e) at Microsoft.Carmine.WSManWrappers.WsmanAPIWrapper.Invoke(String actionUri, WSManUri targetUri, Hashtable parameters, Type returnType, Boolean isCarmineMethod, Boolean forceResponseCast) at Microsoft.Carmine.WSManWrappers.WsmanAPIWrapper.Invoke(String actionUri, String url, Hashtable parameters, Type returnType, Boolean isCarmineMethod, Boolean forceResponseCast) at Microsoft.Carmine.WSManWrappers.WsmanAPIWrapper.Invoke(String actionUri, String url, Hashtable parameters, Type returnType, Boolean isCarmineMethod) at Microsoft.Carmine.WSManWrappers.AgentManagement.AssociateLibrary(WsmanAPIWrapper wsmanObject, String CertificateSubjectName, String& ExportedCertificate, ErrorInfo& ErrorInfo) at Microsoft.VirtualManager.Setup.VirtualMachineManagerHelpers.AddAgentServerAndAssociate() at Microsoft.VirtualManager.Setup.InstallItemCustomDelegates.PangaeaServerPostinstallProcessor() 12:36:12:InnerException.Type: System.Runtime.InteropServices.COMException, InnerException.Message: The WinRM client cannot process the request because the server name cannot be resolved. 12:36:12:InnerException.StackTrace: at WSManAutomation.IWSManSession.Invoke(String actionUri, Object resourceUri, String parameters, Int32 flags) at Microsoft.Carmine.WSManWrappers.MyIWSManSession.Invoke(String actionUri, Object resourceUri, String parameters, Int32 flags) at Microsoft.Carmine.WSManWrappers.WsmanAPIWrapper.Invoke(String actionUri, WSManUri targetUri, Hashtable parameters, Type returnType, Boolean isCarmineMethod, Boolean forceResponseCast)
The error message stated, that VMM setup is trying to resolve a FQDN, which did not succeed. Ok let’s prove that.
Of course the name could be resolved, so wasn’t the real issue here.
Next I checked all network interface binding and dns related configs, but everything was ok. (trust me..I’m an architect 🙂
Running ProcMon during the “hot phase” I noticed that the setup wizard tries to create a loopback WinRM Session to the host itself, where the setup currently is running on. So I tried to do that manually to check whether this could an issue or not.. and boom! This error message again, seemed weird to me, because everything was fine with Kerberos..for sure.. again trust me..I’m an architect 🙂
Ok, then again. ProcMon into PowerShell process this time.
The result was similar to this:
This gave me the hint for the root cause. The machine was configured to use a proxy server at system level. First I checked the configuration using the command:
netsh wintthp show proxy
The result was similar to this:
So what was soo wrong with the config? The main reason for the failure is, that a lot of tasks within SCVMM, even the Setup Wizard don’t resolve host names using the FQDN. So the exclusion as mentioned in the example above would not work, and the WinRM request would be forwared to the proxy. You might think..wait.. why do WinRM requests at all forward via WinHTTP? Simply because it is a SOAP based protocol, and therefore managed by the main http handlers present on the system.
So the solution to fix the issue was quite simple. I just had to reconfigure the system proxy config to include all local addresses, including the ones in the routing tables.
netsh winhttp set proxy proxy-server=”http=myproxy;https=sproxy:88″ bypass-list=”*.miru.local,