Remote Access (DirectAccess) monitoring

The Windows Server 2012 R2 Remote Access (7.1.10181.1) management pack contains a bug that prevents any discovery from taking place with the default configuration. There are also unusual permission requirements.

The bug is that, by default, the discovery runs using the default run-as account for the server, which is usually NT Authority\System, and no run-as profile exists to override this. Given that the discovery process must read GPOs, which are stored on network shares, this will always fail. It’s possible to change the default account for individual servers, but this would affect all the other workflows on that server. A workaround can be put in place by creating a new management pack that disables the default discovery, Remote Access Server PS Discovery, and adds an identical discovery from the Microsoft management pack, but with the addition of a run-as profile, which can then be set to use a domain account. None of the monitors need to run in the context of a domain account, so the run-as profile need only be applied to the discovery.

The following permissions are required by the account used for discovery:

  1. Administrator on every Remote Access/DirectAccess server. This is required to read from the SQL Server (WID) instance, and can be achieved by creating a GPO to assign this permission to the OU that contains the servers.
  2. Edit access to the client settings GPO. Read access, contrary to the documentation, is insufficient.
  3. Edit access to the server settings GPOs. Read access, again contrary to the documentation, is insufficient.

The above permissions should be provided by creating a (domain-local) group that contains the monitoring account, and assigning permissions to the group.

The final step is to distribute the run-as account to the servers that are to be monitored.