Service user accounts are necessary for agentless scanning. They need to be configured to use WinRM to avoid Access Denied related scan error messages. They also need sufficient permission to scan a Windows node. To completely scan a Windows node, the service user account should be a local administrator on the target node, or a domain administrator.

Service User

By default, the UpGuard Windows service runs using the Local System user. The Local System user on the server hosting the UpGuard service will not have any permissions on remote systems, so creating an UpGuard service user is required.


Give the service user security descriptor access

  1. The following command can be run in a PowerShell command prompt to give the service user WinRM execute/invoke permissions:

    Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI

  2. In the popup that appears, ensure that the service user is added with the Execute (Invoke) permission.



  3. Click Yes in the following dialog box to restart the WinRM (Microsoft.Powershell) service.


Adding the service user to the root\cimv2 namespace

  1. For Windows 2008, open Server Manager and expand Configuration. For Windows 2012, open Server Manager click Tools and then click Computer Management. Then expand Services and Applications.
  2. Right click on WMI Control and click Properties.
  3. Click the Advanced tab and confirm that the default namespace for scripting is “root\cimv2”.


  4. Once confirmed, click the Security tab and expand the Root namespace.
  5. Click the CIMV2 namespace and click Security.


  6. Add the service account and under Permissions for Service Account check the Remote Enable (Allow) checkbox. Click Apply and OK.


Adding the service user to Service Control Manager

  1. Click Start, Run, type “cmd” and then click OK.
  2. Type the following command at the command prompt, and then press enter:

Deploying service user permissions to target nodes

Using the script available here, the simplest way to deploy the permissions described in this article is via a Group Policy enforced script. This can be realized through several mechanisms:

  • As a logon script: the script will be run and the settings applied as soon as an administrator logs into the target machine.
  • As a scheduled task that runs once, immediately: the script will be run via a scheduled task, which will be subsequently deleted on completion. The task is created as soon as the Group Policy is applied.
  • As a recurring scheduled task: the script will be run continuously as long as the Group Policy is in place. This can be useful in environments containing ephemeral nodes that may undergo drastic changes on a frequent basis.
  • As a boot script: The script will be executed when the machine is restarted after application of the Group Policy.

Information regarding the setup of any of these methods can be found here.

Alternatively, any existing orchestration tools that can leverage PowerShell scripts should be able to deploy the script to similar effect, as long as they execute in a sufficiently elevated context.