Introduction

You can deploy the Level agent to domain-joined Windows devices using Group Policy. There are two approaches: importing a pre-built automation from Level that handles GPO creation automatically, or setting up the GPO manually.

Which method should you use?

Method	What it requires	What you get
Automated setup (Method 1)	An Active Directory account that can create GPOs, and — on a domain with more than one domain controller — running it on the PDC Emulator.	Level creates and links the GPO for you. The installer it writes also logs install activity to the Windows event log on each client, which helps when you need to troubleshoot a failed install.
Manual setup (Method 2)	A domain admin to create the GPO by hand in Group Policy Management.	Full control over which OU you target, and nothing to create or read back in Active Directory. This is the most reliable option on domains with several domain controllers, but it does not add client-side event logging.

⚙️ PREREQUISITES

Active Directory domain with Group Policy Management
A domain controller accessible from Level
A Level account with permission to add devices
For the automated setup: an Active Directory account that can create GPOs (see Before you run the automation below)

ℹ️ NOTE: This deployment method is provided as a convenience. GPO behavior varies across Active Directory environments — test before deploying to production.

Install via Group Policy

Method 1: Automated Setup

Level provides a pre-built automation that creates and links the GPO for you. It runs on a single domain controller and propagates the agent install to all clients via scheduled task.

Before you run the automation

⚠️ WARNING: Two environment requirements decide whether this automation succeeds: the account it runs as has to be able to create GPOs, and on a domain with more than one domain controller it has to run on the PDC Emulator. Check both before you run it.

Run it as an account that can create GPOs

By default the automation’s script step runs as Local system, which is the domain controller’s own SYSTEM account. In most Active Directory environments SYSTEM is not a member of Group Policy Creator Owners, so Active Directory refuses to create the GPO and the run stops with New-GPO : Access is denied.

To run it under an account that has the rights:

Open the imported automation and select the script step.
Set Run as to Current user.
Sign in to the console of the domain controller you assigned, using an account that is a Domain Admin or a member of Group Policy Creator Owners.
Run the automation while that account is signed in.

the automation editor with a Shell script step open and the Run as dropdown expanded showing the Local system and Current user options

ℹ️ NOTE: Changing Run as only affects this one-time setup script on the domain controller. The GPO it creates always installs the agent on client devices as SYSTEM, and that does not change.

On a multi-DC domain, run it on the PDC Emulator

The setup script creates the GPO on the domain controller that holds the PDC Emulator role, then reads it back from the domain controller it is running on. When those are two different controllers, the brand-new GPO may not have replicated yet and the run stops with Get-ADObject : Directory object not found. Running the automation on the PDC Emulator keeps both steps on the same controller.

To find which controller holds the role, run netdom query fsmo from an elevated prompt on any domain controller, or open Active Directory Users and Computers, right-click the domain, choose Operations Masters and check the PDC tab. If your domain has a single domain controller, this does not apply to you.

Step 1: Import the GPO Automation

Import the automation into your Level account: Import Level GPO Automation

Click Import automation to add it to your account.

Step 2: Get Your Install Key

In Level, open the Device Listing and click Add new device.
Select Windows from the OS selector.
Optionally select a device group — the install key will include the group ID if one is selected.
Copy the install key from the modal.

the Add new device panel open over the Device Listing with Windows selected in the OS selector and the install command visible

Step 3: Configure Automation Variables

Open the imported automation and select the Variables tab.
Paste your install key into the LEVEL_API_KEY variable.
If you selected a group, paste the group ID into the group ID variable.

Step 4: Assign to a Domain Controller

Add a single domain controller as the target device for this automation. On a domain with more than one domain controller, pick the one holding the PDC Emulator role (netdom query fsmo).

the automation editor with the Add a device panel open and a domain controller being added as the automation's target

⚠️ WARNING: Only assign this automation to one domain controller. The automation creates a GPO at the domain root — running it on multiple controllers will cause conflicts.

Step 5: Approve and Run

The automation’s first step is an admin approval gate. Review and click Approve to proceed.

The second step runs a script that creates a new GPO called “Install Level Agent” and links it to the root of the domain. The GPO creates a scheduled task on all Active Directory clients that immediately runs the Level install script.

ℹ️ NOTE: The automated setup drops Windows Event Log messages on client machines when the installer script runs. They land in the Application log under the source Level, with event IDs 100 to 104 covering installed, already installed, install may have failed, and service start results. These are useful for troubleshooting failed installs.

⚠️ WARNING: The run log prints the install key it passes to the installer. Treat that log as sensitive — if you share it, remove the key first, and if a key has been exposed, generate a new one and update the LEVEL_API_KEY variable.

Troubleshooting the automated setup

Error in the run output	What it means	What to do
`New-GPO : Access is denied`	The account the script ran as cannot create GPOs. This is normal when the step runs as Local system, because SYSTEM is usually not in Group Policy Creator Owners.	Set the script step’s Run as to Current user and run the automation while a Domain Admin is signed in to the domain controller’s console. See Before you run the automation.
`Get-ADObject : Directory object not found`, right after “Created GPO” and “Linked GPO to domain root”	The GPO was created, but the script read it back from a domain controller that had not received it yet. The object ID in the error is the GPO it just created, so nothing is misconfigured — the two controllers are out of sync for a moment.	Run the automation on the domain controller holding the PDC Emulator role, or wait for replication and run it again. Use the manual setup instead if you would rather not depend on replication timing.
The run finished, but no devices appear in Level	The GPO is in place, but the install did not complete on the clients.	Check the Application event log on a client for messages from the source Level, then see the FAQ below.

You do not need to delete the GPO before trying again. If an Install Level Agent GPO already exists, the script reuses it, clears the scheduled task it wrote previously, and continues. A run that stopped early leaves a GPO that does nothing on clients, because the script had not yet registered the scheduled task with Group Policy.

Method 2: Manual Setup

If you prefer to configure the GPO yourself, use an immediate scheduled task. Nothing here depends on Active Directory replication or on the account’s GPO-creation rights beyond what a domain admin already has, so this is the most reliable option on domains with several domain controllers.

Step 1: Create and Link the GPO

Open Group Policy Management.
Create a new GPO and link it to the appropriate OU in Active Directory.

Step 2: Configure the Scheduled Task

Edit the GPO and navigate to Computer Configuration → Preferences → Control Panel Settings → Scheduled Tasks.

Right-click and select New → Immediate Task (At least Windows 7).

General tab:

Setting	Value
Name	Install Level Agent
User	SYSTEM
Run whether user is logged on or not	Enabled
Run with highest privileges	Enabled
Configure for	Windows 7, Windows Server 2008 R2

Actions tab:

Click New and configure the action:

Field	Value
Program/script	`c:\windows\system32\windowspowershell\v1.0\powershell.exe`
Add arguments	See below

In the Add arguments field, paste the following. Replace PUT_YOUR_LEVEL_KEY_HERE with your install key:

-ExecutionPolicy Bypass; $env:LEVEL_API_KEY = 'PUT_YOUR_LEVEL_KEY_HERE'; Set-ExecutionPolicy RemoteSigned -Scope Process -Force; [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; iwr -useb https://downloads.level.io/install_windows.ps1 | iex

Click OK to close the action, then OK again to close the task properties.

Step 3: Wait for Policy Refresh

On the next Group Policy refresh, the scheduled task runs and the Level agent is installed on domain-joined devices in the linked OU. Devices appear in Level within seconds of the install completing.

ℹ️ NOTE: Manual GPO setup doesn’t generate Windows Event Log messages on client machines. Use the automated method if you need install activity logging for troubleshooting.

FAQ

The GPO ran but devices aren’t showing up in Level — what happened? First, check the Windows Event Log on affected clients for messages from the Level install script (automated method only — they appear in the Application log under the source Level). Common causes: the PowerShell script was blocked by an execution policy, an AV/EDR tool quarantined the download, or the device couldn’t reach downloads.level.io. See AV/EDR False Detections and Offline Troubleshooting.
Can I target a specific OU instead of the whole domain? For the automated method, the script links the GPO at the domain root. If you need OU-level targeting, use the manual method and link the GPO to the specific OU.
Do I need to update the GPO if my install key changes? Yes. Update the LEVEL_API_KEY value in the automation variables (automated method) or in the scheduled task arguments (manual method).
Who can run the automated GPO setup? Two separate permissions are involved. In Level, any technician with permission to run automations on the domain controller can start it, and the admin approval step gives you a review gate before the script runs. In Active Directory, the account the script runs as has to be able to create GPOs — a Domain Admin or a member of Group Policy Creator Owners. The script step’s default of Local system usually cannot, which is why the setup can fail with New-GPO : Access is denied even though the automation itself ran fine. See Before you run the automation.
The automated setup failed partway through. Do I need to delete the GPO before retrying? No. If an Install Level Agent GPO already exists, the script reuses it and clears the scheduled task it wrote previously. Until a run completes, the GPO does not install anything on clients, so a partial run is harmless. If the failure was Get-ADObject : Directory object not found, run the automation from the PDC Emulator so the create and read-back happen on the same domain controller.
Does the automation change how the agent installs on client devices? No. The GPO it creates always runs the install as SYSTEM with highest privileges. The Run as setting on the automation’s script step only controls the account used for the one-time GPO setup on the domain controller.