none
Configuration Load Error (Settings cannot be retrieved / WinRM) in RA Management Console

    질문

  • Hi all

    Last week I discovered that I am unable to open the Remote Access Management Console (ramgmtui). Remote-Access PowerShell-Cmdlets still work as expected (e.g. Get-RemoteAccessHealth), and clients still have Connectivity.

    When opening ramgmtmui, I see the following error message:

    Configuration Load Error

    Settings for server <fqdn> cannot be retrieved. The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol.

    My first guess is WinRM-problems, but everything seems OK - WinRM server settings are configured on all servers - including DCs - via GPO, and I can access the servers with winrs -r:<servername> echo %computername%.

    Does anyone have an idea what the reason for the Management Console error might be?

    Thanks for reading

    /Maurice

    2013년 8월 5일 월요일 오전 6:40

답변

  • I opened a break/fix incident with Microsoft, but after some troubleshooting (including removing the configuration, removing the RemoteAccess-role and re-adding it) the problem persisted. Brainstorming with the MS Engineer led us to the cause: WinRM listeners were configured via GPO and bound only to selected interfaces. Once the GPO was configured with "*" (aka listen on all interfaces) for IPv4 and IPv6, the problem vanished.

    Hope this is useful to others.

    /Maurice

    2013년 8월 21일 수요일 오후 11:14

모든 응답

  • The most common causes I have seen for problems opening the console have been network related. If you lose connectivity to a domain controller it will cause all kinds of problems because much of that information gets read from the GPOs. Also, it seems to query itself based on the FQDN and so if there are any name resolution problems the console can also fail.

    If you have any firewalls on the internal part of your connection, check those carefully for blocked or failed traffic. If you are firewalling the traffic between the internal NIC of your DA server and the internal network, it is very easy for that firewall to cause these kinds of problems.

    2013년 8월 6일 화요일 오후 1:23
  • Thanks for Your input, Jordan!

    I have thought of the same and I know the ultimate cause (but no fix ...) - we had to forcibly demote a domain controller. The remaining DCs are working well, but ever since the force demote I am struggling with the above problem on both DirectAccess-servers. I checked several registry keys, but was unable to find something useful...

    Can I force the DA-server to pull the settings from AD DS GPO, overwriting local settings?

    /Maurice

    2013년 8월 6일 화요일 오후 1:51
  • I don't know about that, but I think I would start with making sure that all traces of that domain controller are removed from Active Directory and then restart the DirectAccess servers, then try again. Hopefully you can get it to recognize that the DC its trying to contact doesn't exist anymore. The console is very picky about contacting all domain controllers in an environment. I have a customer that has many DCs globally and by design their ACLs disallow contact to those DCs from machines outside of their local sites. The DirectAccess console has fits about this as well, not to the point of hanging up at least, but it has constant error messages in it and activation takes forever as it waits for every single one to timeout.

    Maybe Microsoft will listen in on this and someday make adjustments so that the console can accommodate better for environmental changes.

    2013년 8월 6일 화요일 오후 2:54
  • I opened a break/fix incident with Microsoft, but after some troubleshooting (including removing the configuration, removing the RemoteAccess-role and re-adding it) the problem persisted. Brainstorming with the MS Engineer led us to the cause: WinRM listeners were configured via GPO and bound only to selected interfaces. Once the GPO was configured with "*" (aka listen on all interfaces) for IPv4 and IPv6, the problem vanished.

    Hope this is useful to others.

    /Maurice

    2013년 8월 21일 수요일 오후 11:14