Skip to main content
Installing the agent one machine at a time works fine for a handful of devices — see Installing your first agent for that. Once you’re onboarding a real fleet, Deploy to Network does it for you: pick one already-enrolled device to act as a relay, and it scans the local network and pushes the agent to everything else on it.
v1 scope: Windows-to-Windows only. Both the relay and every target device must be running Windows 10 or 11. macOS and Linux targets still need the manual install for now.

​
How it works, in one sentence

An agent you’ve already installed scans its local network, finds nearby Windows machines that don’t have AssetGullak yet, and — using credentials you provide for that one job only — copies the installer over and runs it remotely. Nothing new needs installing on the relay itself; it’s just acting as your hands on that network.

​
Before you start

The relay device needs:
  • Windows 10 or 11
  • AssetGullak already installed and showing Online
  • The same local network as your target devices
Each target device needs:
  • Windows 10 or 11, on the same network as the relay
  • Network profile set to Private (not Public)
  • File and Printer Sharing turned on
  • WinRM (Windows Remote Management) enabled
  • A local or domain account with Administrator rights and a real password set — accounts with no password can’t be used
Run once per target, in an elevated PowerShell window:
Enable-PSRemoting -Force -SkipNetworkProfileCheck
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Restart-Service LanmanServer -Force
The registry key is only required if the account you’ll use isn’t the literal built-in “Administrator” account.
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force
Restart-Service WinRM
Only needed if your targets are standalone “workgroup” machines rather than domain-joined. Using "*" trusts every host, which is fine on a private office network — for anything more exposed, scope it to your specific subnet instead.

​
Running it

From Devices → Add → Deploy to network, a 4-step wizard walks you through the whole job.
1

Pick a relay and a scan range

The relay dropdown only shows devices currently Online. Leave Auto-detect selected unless you specifically need a different subnet — it derives the relay’s own network range automatically.
2

Enter credentials for the target devices

The account needs local Administrator rights on the target machines — not necessarily your own AssetGullak login. See the security note below for what happens to this password.
3

Review what was found

The scan lists every device on that network, reachable or not, with already-enrolled devices greyed out automatically — they’re never reinstalled. Uncheck anything you don’t want touched (printers and other non-installable gear are shown but unchecked by default).
4

Watch it deploy

Each target shows installed, failed, or in-progress as the job runs. Failures show a reason (access denied, unreachable, timeout) so you know which machines to check manually — one bad target never blocks the rest.

​
About that password

Handing over a domain admin account is a reasonable thing to be cautious about, so here’s exactly what happens to it:
  • It travels directly to the relay for this one job — encrypted the entire time it’s stored, for the short window between when you submit it and when the relay picks up the job (usually seconds).
  • It’s used in memory on the relay only, for exactly as long as this job runs, and never written to disk there.
  • It’s never included in any log, on the relay or on our servers.
  • The enrollment key generated for this job is single-use and expires within the hour — it can’t be reused for anything beyond this one batch.

​
After it finishes

Successfully installed devices show up on your Devices page the same way any agent install does — from there, they behave identically to a manually installed agent. Anything that failed can be retried individually, either manually or by running the wizard again against just those IPs.

​
Troubleshooting

The scan filters out routers, printers, and other non-Windows gear automatically. If a real Windows machine is missing, check it’s reachable from the relay:
Test-NetConnection -ComputerName <target-ip> -Port 445
A failure here usually means File and Printer Sharing or the network profile isn’t set correctly yet — see the setup commands above.
The most common cause is the account having no password set — Windows won’t authenticate a passwordless account remotely. The second most common cause is the LocalAccountTokenFilterPolicy registry key (see setup above) not being set, which is required for any admin account other than the built-in “Administrator.”
Confirm WinRM is enabled on the target (Enable-PSRemoting), and that the relay trusts it (TrustedHosts, for non-domain targets — see setup above). To isolate the issue from everything else:
$cred = Get-Credential
Invoke-Command -ComputerName <target-ip> -Credential $cred -ScriptBlock { hostname }
If this returns the target’s computer name, WinRM itself is fine and the issue is specific to the deploy step.
The file copy and service creation likely worked, but something after that didn’t. On the target, confirm the service is actually running and check its config points at the right server (not localhost) — the full diagnostic steps are in the agent’s troubleshooting reference.

​
Next step

Once your fleet is enrolled, your first 10 minutes covers what you’ll see across the dashboard now that real devices are reporting in.