Prepare your Windows PCs for agentless inventory

NetBlade reads a Windows PC over the network, with Windows’ own management interfaces, and installs nothing on it. In return, each PC must accept an administrator login from the PC running NetBlade and let that traffic through its firewall. This article explains exactly what is needed, how it differs between a domain and a workgroup, what NetBlade’s enable script changes and how to undo it, and how to prove it all on one PC before touching the rest.

Before you start

NetBlade installed and a first scan done, so the PCs are in Devices (Get started).
An administrator account for the PCs you want to read: a domain account that is a local administrator, or a local administrator account on each PC.
Physical or remote access to one PC to use as a pilot, where you can run something as administrator.
The IP address of the PC running NetBlade. It should not change: if it comes from DHCP, give it a reservation on your DHCP server (see step 7 for why).

1. Know what a read uses

A read of a Windows PC (Deep scan on a device card, or Deep inventory on the device list) goes through Windows management, and NetBlade asks for file sharing to be open towards it as well:

What	Port	What it is for
Windows management (WMI)	TCP 135 plus the dynamic RPC ports of the WMI service	The read itself: hardware, system, updates, services, defences
File sharing (SMB)	TCP 445	Opened alongside WMI; also the way in for PsExec
WinRM	TCP 5985	Remote actions only, not the read

It also needs a Windows administrator credential for that PC. BitLocker and TPM in particular can only be read by an administrator; without one the card says an administrator is needed.

With that, NetBlade reads name, domain, operating system and build, manufacturer, model and serial, processor, memory, signed-in user, drives and physical disks, network adapters, monitors, printers, battery, faulty devices and USB, installed updates, services started automatically, programs that start with Windows, optional features, profiles, local administrators and accounts, open sessions, shared folders and who can write to them, installed programs, and the defences: antivirus, firewall per profile, BitLocker, TPM, Secure Boot, UAC, Remote Desktop, SMBv1 and pending restart.

Note: The PC running NetBlade reads itself without any credential or preparation.

2. Domain or workgroup: what changes

	In a domain	In a workgroup
Account	A domain account that is local administrator of the PCs	A local administrator account on each PC
Remote UAC	Not an issue for domain accounts	Must be relaxed for local accounts (step 5)
WinRM for remote actions	Kerberos, nothing extra on this PC	This PC must list the target in TrustedHosts

In a domain there is one more convenience: when no stored credential gets in, NetBlade tries the Windows account it is running under. If you sign in to the NetBlade PC with a domain account that is local administrator on the PCs, those PCs can be read with no credential filed. For a clean setup, file a dedicated account anyway (see Credentials the right way).

3. Choose and file the account

Decide which account NetBlade will use. In a domain, a dedicated IT account that is a member of the local Administrators group on the workstations is the usual choice. In a workgroup, the local administrator account of each PC.
In NetBlade, open Credentials and press Add….
Set Protocol to Windows (WMI) and type the Username in the form the app shows: DOMAIN\user for a domain account, or .\Administrator for a local one.
Type the password, choose Where it applies (for now, One site or One device for the pilot PC) and add a label.
Press File.

4. Try one pilot PC

Do not prepare twenty PCs and then find out the account was wrong. Pick one.

On the Credentials page, type the pilot PC’s address in Machine to try and press Test. The LAST TEST column says «Works» or «Failed».
Open the pilot PC’s card from Devices and press Deep scan.
Look at the read status just under the device name. «Read … via …» means it worked. «Never read» or «Read failed» opens a panel with the reason and what to do.

If it worked, jump to step 7. If the panel says the firewall blocks reading, for example «It is a Windows PC, but its firewall blocks reading: it only answers on ports …», continue with step 5.

5. Open the PC with the enable script

When a Windows PC cannot be read, its card offers a script that opens exactly what NetBlade needs, only towards the PC running NetBlade.

On the pilot PC’s card, click the read status (Never read or Read failed).
Press Download the enable script and save the file.
In the same panel, also save Script to undo the changes now, and keep it with the other one.
Copy the enable script to the pilot PC and double-click it. It is a .cmd file: it asks for administrator rights by itself and says what it does, line by line.
Back in NetBlade, press Read again now.

Warning: The enable and undo buttons appear on the card only while the PC has not been read successfully. Once the read works they disappear, so save the undo script at the same time as the enable script.

What the script changes on that PC:

Adds firewall rules, allowed only from the NetBlade PC’s IPv4 address, named NetBlade - WMI (135), NetBlade - WMI (RPC), NetBlade - Services (RPC), NetBlade - SMB (445) and NetBlade - WinRM (5985). The Services rule opens remote service management, so that PsExec starts at once instead of waiting.
Sets the WMI service to start automatically and starts it.
Turns on WinRM with Enable-PSRemoting -Force -SkipNetworkProfileCheck, for remote actions.
Only if the PC is not in a domain, sets LocalAccountTokenFilterPolicy to 1 (step 6 explains why).

Running it twice is harmless: it removes its own rules first, so you end up with one set.

6. Understand remote UAC and LocalAccountTokenFilterPolicy

By default, when a local administrator connects to a PC over the network, Windows strips the administrator rights from that login. This is User Account Control’s remote restriction. The result is confusing: the ports are open, the password is right, and the read is still refused with «WMI: access denied (0x80070005)».

The registry value LocalAccountTokenFilterPolicy, set to 1 under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, lifts that restriction so a local administrator keeps its rights remotely. The enable script sets it only on PCs outside a domain, because domain accounts are not filtered this way.

If you prepare a PC by hand instead, the remote actions guide in the app gives this command, to run in PowerShell as administrator on that PC:

New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name LocalAccountTokenFilterPolicy -Value 1 -PropertyType DWord -Force

Warning: This lowers that PC’s protection a little: any local administrator account can now be used over the network. Use it only where you need it, with a strong, unique local administrator password on each PC. The undo script removes it, and so does the remote action «Restore UAC remote restrictions».

7. Roll out to the other PCs

Once the pilot reads correctly, repeat for the others.

Per PC, with the script. Download the enable script from each PC’s card and run it there. The script is built for the NetBlade PC’s current IP address. This is why that address must not change: if it does, the firewall rules no longer match and reads stop until you run a fresh script.
In a domain, with Group Policy. NetBlade does not generate policies, but the same result can be obtained centrally. For WinRM, the app itself points to: Computer Configuration › Administrative Templates › Windows Components › Windows Remote Management › WinRM Service › «Allow remote server management». For WMI and SMB, the usual approach is inbound firewall rules for TCP 135, the WMI service’s RPC ports and TCP 445, restricted to the NetBlade PC’s address. This is general Windows administration, so test it on one PC first.
Widen the credential. When the pilot works, open Credentials, press Where it applies… on the credential and extend it to One site or Anywhere.

Then read them all: Devices, Deep inventory, or Sites, Read every device. The site reports how many were read and how many had no credential that applies.

8. Prepare remote actions too (optional)

Reading does not use WinRM, but remote actions do. If you plan to use them, open Remote actions on a card and expand What the remote machine needs. The app lists, in the order they are usually missing:

An administrator account on that machine, saved in Credentials.
WinRM on, on the remote machine: Enable-PSRemoting -Force -SkipNetworkProfileCheck.
A private or domain network, not a public one. On the remote machine, as administrator:

Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private

Outside a domain, trust the machine from this PC (put its IP in place of the example):

Set-Item WSMan:\localhost\Client\TrustedHosts -Value '192.168.1.50' -Concatenate -Force

Outside a domain with a local account, the LocalAccountTokenFilterPolicy key from step 6.
PsExec, when there is no WinRM: port 445 open on the remote machine and the ADMIN$ share on. To open 445:

Enable-NetFirewallRule -Name 'FPS-SMB-In-TCP'

The details are in Remote actions, safely.

9. How to undo everything

On any PC you prepared with the script, run the Script to undo the changes you saved. It removes NetBlade’s firewall rules and the remote administrative access for local accounts. It leaves WinRM on; if you do not need it, turn it off in PowerShell as administrator:

Disable-PSRemoting

If you did not keep the undo script, the same results are available as remote actions from a working NetBlade: «Restore UAC remote restrictions», «Delete a firewall rule» for each of the NetBlade - … rules listed in step 5, and «Disable WinRM». They travel through the very access you are removing, so keep «Restore UAC remote restrictions» for last. Keeping the undo script is simpler.

Check that it worked

The card’s read status says «Read … via …», and the Hardware, Software, System and Security tabs are filled in.
The Security tab shows BitLocker and TPM states instead of «needs administrator».
On the Dashboard, Machines read goes up and the coverage line says how many devices are read in depth.

If something goes wrong

«WMI: access denied (0x80070005)». The account is not authorised. With a local or Microsoft account, LocalAccountTokenFilterPolicy must be on (the enable script does it). In a domain, check that the account is in the PC’s local Administrators group.
«WMI: logon failure (0x8007052E)». Wrong username or password. Check the form: DOMAIN\user or .\Administrator.
«WMI: access denied (0x80041003)». The account lacks rights on the WMI namespace. Use an administrator account.
«WMI: logon type not granted (0x80070569)». A local security policy on that PC denies the logon type. Check that PC’s local security policy.
«no answer from WMI (firewall, or not Windows)». The firewall blocks WMI or the device is not Windows. Run the enable script.
«no credential applies to this device». No Windows credential covers it. File one for the device, the site or everywhere.
«the saved password cannot be read on this account». The credential was filed by another Windows user on this PC. File it again while signed in as the user who runs NetBlade.
It worked, then stopped on every PC at once. The NetBlade PC’s IP address probably changed, so the rules no longer match. Reserve its address and run fresh scripts.
A remote action took over half a minute. That PC’s firewall blocks remote service management and PsExec waits before falling back. Download the enable script again and run it: the current version opens that too, still only for this PC.

With the PCs readable, set up your accounts properly: Credentials the right way. Then read your network gear with SNMP.

← All how-to guides Feature guide → The product: NetBlade Windows →