none
RemoteAccess Mgmt Console - wrong services state RRS feed

  • Question

  • Hi!

    I have fresh DirectAccess deployed on 2012R2 server.
    Its config: 2 interfaces with ip-https only (only tcp443 is open on public), client configured for split tunneling, check DA work on Win7 notebook.
    Client can connect to intranet resources over DA, so ip-https, ipsec tunnels (infra and corp), dns etc. are working fine.

    But server side Remote Access Management Console shows "Critical" services state for IP-HTTPS, 6To4, Network Security and Services, and claims system services iphlpsvc,mpssvc,bfe,ikeext should be started.
    But all these services are running and obviously working well as client can connect to intranet thru DA.

    So the question is why mgmt console shows incorrect states and how to fix it?
    Friday, September 29, 2017 3:45 PM

All replies

  • Is it possible that WinRM is somehow being blocked on your DA server? This could cause it to have trouble "talking to itself". When you open the Remote Access Management Console you would think that the console should have immediate access to everything that it needs because it is running on the same server where those services are running, but in actuality the Remote Access Management Console is just a shell that is reaching out to grab all of the information that it shows you. It uses network channels to do this. So even though you are running it right on your DA server, if WinRM is having trouble or if you don't have access to the domain in order to read the GPOs where the DA settings are sitting, any kind of interruption of information in those channels will cause problems for the RAMC.
    Monday, October 2, 2017 12:20 PM
  • Hi Jordan!

    Yes I have GPO configuring WinRM in our domain and it prevented to configure DA from the very beginning.
    That GPO have been changed then (enabling filter for ipv6) and DA was configured successfully but console at once showed wrong statuses.
    I tried to reinstall the role isolating server from all group policies except DA (placed server account to OU with blocked inheritance) - with the same success.
    Have given full control to admin (and server) accounts to GPO - but nothing changed.
    I dunno what else to do about it?
    Monday, October 2, 2017 1:34 PM
  • Well, I tried all I could:
    - reinstall Remote Access Role
    - block all domain policies for server
    - remove antivirus software (MS endpoint protection)
    - reinstalled server from the clean image (first incarnation was deployed from prepared image through SCCM)
    - recreated DA config after each change
    - changed NICs for server (it's virtual under vmware) from E1000 to VMXNET3 (smb noted about problems with DA when on e1000)
    - found out that both console and powershell to get haelth state make calls to WMI namespace root\Microsoft\Windows\RemoteAccess\Server class PS_RemoteAccessHealthLocal (implemented in RAMgmtPSProvider)
    - explored logs: RaMgmtUIMon.log, RemoteAccess-MgmtClient, RemoteAccess-RemoteAccessServer, WMI-Activity/Operational, Trace and Debug logs
    - tried to find something with procmon
    - ...

    Nothing of that changed false "critical" status of DA componets.

    Eventually I revealed that the problem is in insuffisient permissions of "NETWORK SERVICE" account which runs the "Remote Access Management service (RaMgmtSvc)".
    After I've changed service account to "Local System" (or leave "Network Service" for RaMgmtSvc, but include it to local administrators) - RA Management console shows now all components in healthy state.
    By now the question remains unanswered - what permissions and to what resources should have "NETWORK SERVICE" for RAMC to work properly? 
    Or what could be wrong with my environment as RAMC works wrong out of box (seems nobody faced such a problem as I couldnt find any mentions in internet about it) ?


    Friday, October 6, 2017 9:05 AM