It is encouraged to run the UpGuard connection manager service under a service user account that is not in an Administrators group. Service user accounts will need to configured to use WinRM to avoid Access Denied related scan error messages.

Service User

By default, the UpGuard Windows service runs using the Local System user. Creating an UpGuard service user is recommended as the Local System user may not have sufficient privileges to scan your entire node successfully. To use WinRM, a level of administrative access is still required for the service user.

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 realised 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.