Deploy to Network — Requirements & Troubleshooting

Everything you need to know before running Discover Network or Bulk Install — what your devices need, and how to fix the most common issues yourself using built-in Windows tools.

What this feature does

Discover Network scans your local network from an already-enrolled device (the relay) and finds other devices on the same network that don’t have AssetGullak installed yet. Bulk Install then pushes the AssetGullak agent to selected devices (targets) over your local network — no need to log into each machine individually. Two devices are involved in every deployment:

Relay — an AssetGullak device you already have installed and running. It does the scanning and pushes the installer to other machines.
Target — the device you want to install AssetGullak onto.

v1 scope

This feature currently supports Windows-to-Windows deployment only:

	Supported
Relay running Windows	✅
Target running Windows	✅
Relay running macOS/Linux	❌ (not yet)
Target running macOS/Linux	❌ (not yet — install manually for now)

If you need to deploy to a Mac or Linux machine, use the standard manual install for now (Devices → Add → Install agent manually).

Requirements

On the relay device

Windows 10 or 11
AssetGullak agent already installed and showing Online
Connected to the same local network as your target devices

On the target device

Windows 10 or 11
Connected to the same local network as the relay
Network profile set to Private (not Public)
File and Printer Sharing turned on
A local (or domain) account with Administrator rights, with a real password set (accounts with no password cannot be used)
WinRM (Windows Remote Management) enabled

Account requirements (the credentials you provide during Bulk Install)

Must be a real account on the target device, not your own computer
Must have local Administrator rights on the target
Must not be a Microsoft account (outlook.com / hotmail.com / live.com sign-in) — use a local Windows account instead
If the target is not part of a company domain (a standalone “workgroup” machine), leave the domain field blank — the system will automatically figure out the right format for you

Setup checklist (run once per target device)

Run these on the target device, in an elevated (Run as Administrator) PowerShell window:

# 1. Turn on Windows Remote Management
Enable-PSRemoting -Force -SkipNetworkProfileCheck

# 2. Confirm your network profile is Private
Get-NetConnectionProfile
# Look at "NetworkCategory" in the output — should say "Private"
# If it says "Public", fix it via:
#   Settings > Network & Internet > (your network) > Network profile type

# 3. Confirm File and Printer Sharing is on
Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" |
    Where-Object { $_.Enabled -eq "True" -and $_.Profile -match "Private" }
# Should return several rules. If empty, turn it on via:
#   Settings > Network & Internet > Advanced network settings >
#   Advanced sharing settings > Private > File and printer sharing > On

# 4. Required if your admin account is NOT the built-in "Administrator" account
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" `
    /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Restart-Service LanmanServer -Force

Then, on the relay device, trust the target for remote management (only needed for non-domain / “workgroup” targets):

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force
Restart-Service WinRM

Using "*" trusts all hosts, which is fine for testing on a private network. For a production office network, replace "*" with your specific target IP or subnet.

Troubleshooting

”Device not appearing in Discover Network results”

The scan only shows devices that look like valid Windows install targets — routers, printers, and other network gear are filtered out automatically. Run on the target:

# Confirm it's reachable and looks like a Windows machine
ipconfig
# Note the IPv4 address, then from the RELAY, run:
Test-NetConnection -ComputerName <target-ip> -Port 445

If this fails or times out, File and Printer Sharing / network profile likely isn’t configured correctly yet — see the setup checklist above.

”SMB auth failed” / “Access is denied”

This means the connection reached the target, but the username/password was rejected. Most common cause: the account has no password set.

# On the target — check via Settings > Accounts > Sign-in options > Password
# If there's no password, add one before continuing.

Second most common cause: the LocalAccountTokenFilterPolicy registry key (see setup checklist, step 4) hasn’t been set on the target. This is required for any admin account other than the literal built-in “Administrator” account. To test manually and see the exact Windows error message:

# On the relay — replace with your real target IP, password, and account
net use \\<target-ip>\C$ "yourpassword" /user:<TargetComputerName>\<username>

A specific error here (rather than our generic message) tells you exactly what Windows is rejecting.

”unreachable_port_445” or connection times out

Port 445 (used for file sharing) isn’t reachable on the target.

# From the relay:
Test-NetConnection -ComputerName <target-ip> -Port 445

If this fails:

Confirm the target’s network profile is Private, not Public
Confirm File and Printer Sharing is turned on (see setup checklist)
Confirm both devices are actually on the same network/subnet
Check for third-party antivirus/firewall software that may be blocking the connection independently of Windows’ own firewall

Install reports success, but the device never shows up in your dashboard

This usually means the install itself worked, but something after that didn’t complete. Check the target directly:

# From the relay, reconnect to the target first:
net use \\<target-ip>\IPC$ "yourpassword" /user:<TargetComputerName>\<username>

# 1. Is the service actually running?
sc \\<target-ip> query AssetGullak
# Look for "STATE : 4 RUNNING". If it says STOPPED, something failed on startup.

# 2. Check the config that got installed
type "\\<target-ip>\C$\ProgramData\AssetGullak\config.toml"
# Confirm base_url points to the correct server — not "localhost"

# 3. Check the agent's own logs for the real error
dir "\\<target-ip>\C$\ProgramData\AssetGullak\logs"
type "\\<target-ip>\C$\ProgramData\AssetGullak\logs\agent.log.<todays-date>"

WinRM / remote execution errors

Symptom: errors mentioning “WinRM,” “the client cannot connect,” or “the WinRM client cannot process the request.” Enable WinRM on the target if you haven’t already:

Enable-PSRemoting -Force -SkipNetworkProfileCheck

Trust the target from the relay (required for non-domain machines):

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force
Restart-Service WinRM

Test the connection directly, isolating WinRM from everything else:

$cred = Get-Credential   # enter the TARGET's admin username + password
Invoke-Command -ComputerName <target-ip> -Credential $cred -ScriptBlock { hostname }

If this returns the target’s computer name, WinRM itself is working correctly and any remaining issue is specific to the deployment step — contact support with this test’s result.

Antivirus blocking the install

Some antivirus software may flag or quarantine the installer, since it’s a new executable being copied over the network and used to create a system service — a pattern antivirus tools watch closely. If a device shows the file was copied but the service was never created:

Check Windows Security → Virus & threat protection → Protection history on the target for a blocked/quarantined item around the time of install
If found, add an exclusion for C:\Program Files\AssetGullak\ or contact your IT/security team to allowlist the AssetGullak installer

Quick reference — all commands in one place

Run on the target (once, before first deployment):

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

Run on the relay (once, before first deployment):

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force
Restart-Service WinRM

Diagnostic commands (run on the relay, pointed at the target’s IP):

Test-NetConnection -ComputerName <target-ip> -Port 445
net use \\<target-ip>\C$ "password" /user:<ComputerName>\<username>
sc \\<target-ip> query AssetGullak
$cred = Get-Credential
Invoke-Command -ComputerName <target-ip> -Credential $cred -ScriptBlock { hostname }

Still stuck? Contact support with the output of whichever diagnostic command above matches your issue — it’ll help us resolve it much faster.

​What this feature does

​v1 scope

​Requirements

​On the relay device

​On the target device

​Account requirements (the credentials you provide during Bulk Install)

​Setup checklist (run once per target device)

​Troubleshooting

​”Device not appearing in Discover Network results”

​”SMB auth failed” / “Access is denied”

​”unreachable_port_445” or connection times out

​Install reports success, but the device never shows up in your dashboard

​WinRM / remote execution errors

​Antivirus blocking the install

​Quick reference — all commands in one place