Skip to main content
Ports, permissions and common issues are described on the page of each scan module. Accounts, splitting jobs, schedules, timeouts and warnings in monitoring concern all scan modules alike.

​
Accounts and permissions

Use a separate account per purpose, with exactly the rights the scan module needs:
  • Linux without root: Use sudo with the rule from gensudo.sh, or sign in with a private key. The user needs a login shell.
  • The gateway’s service account: Active Directory, Windows (AD), Windows DNS, Windows DHCP, DFS, Microsoft SQL Server and Hyper-V can run without their own credentials under the gateway’s service account. That account then needs the rights. If the gateway runs under the local system account, it cannot reach shares; the folder for File Import must then be local.
  • No MFA for service accounts that scan, such as with Veeam B&R. Where MFA must stay, scan by script under the local system account.
  • User Account Control: A local administrator account other than the built-in Administrator does not get full rights remotely. Use a domain account or set LocalAccountTokenFilterPolicy—see Scanning Windows.
  • Domain accounts are entered with the domain: DOMAIN\user or user@domain.internal.
With the scan scripts that take -u and -p—Discovery-ActiveDirectory.exe, Discovery-Nutanix.exe, Discovery-Proxmox.exe, Discovery-HPE.exe—the password stands in plain text on the command line, and therefore in the scheduled task or the calling script. Use a dedicated user with read rights only, and protect the scheduled task or script from access by others. For Active Directory, use integrated sign-in where possible and omit -u and -p.
If personal data from Active Directory does not belong in Docusnap365, call Discovery-ActiveDirectory.exe with -noPersonalData.

​
Splitting jobs

  • Large Windows environments: From about 750 Windows systems, more than one recurring Windows (AD) job can pay off—such as one for servers and domain controllers and one for workstations, or one per site. In the Scan Scope step, Restrict selection… narrows the systems, with a text filter and Servers Only.
  • Sites and isolated networks: Set up a separate gateway per site or VLAN. The local gateway scans the local network; ARP, and with it MAC addresses, is only available within the gateway’s own subnet.
  • Isolated servers, such as backup servers: Install a gateway on the server itself, or scan by script.
  • Scan script in addition to scanning through the gateway: In environments from about 750 workstations, run Discovery-Windows.exe in parallel through Group Policy or software distribution.
  • DFS is better scanned by script on the namespace servers. Scanning through the gateway has limits there (double hop, replication status).

​
Schedules

  • Windows as a recurring job, such as on weekdays. A recurring Windows job almost always ends with errors because individual systems are switched off. Review the errors per system regularly nonetheless.
  • Scan scripts on servers run weekly, such as on Sunday; Discovery-Windows.exe on workstations weekly or more often.
  • Scan switches at peak times. Switches forget learned MAC addresses of inactive devices; the port assignment is complete only while the devices are running.
  • The File Import job runs after the scan scripts so that it finds fresh results. It reads all result files in the folder.
The File Import job deletes the result files after reading them. To keep copies, use the script’s -a parameter in the script’s output directory, not in the import folder.
Results of scheduled jobs appear in the inventory only with the next data refresh: every 24 hours in Pro, every 12 in Business, every 6 in Enterprise. A job with Run Immediately transfers its result at once.

​
Timeouts

  • SNMP: Timeout (ms) applies per target and defaults to 2600. Cisco devices sometimes respond late. If the scan does not find all devices, increase the value.
  • Windows over slow links: Scanning one Windows system is limited to 10 minutes. If that is not enough over a slow link, place the gateway closer to the systems or scan the system by script.

​
Warnings in monitoring

  • IP scan: An IP scan triggers warnings—through the volume of ICMP requests and through deliberately invalid packets whose responses NMAP uses to detect the operating system. The warnings do not indicate a scan error.
  • SNMP scan: An SNMP scan also triggers warnings, through the volume of requests.
  • Flooding protection and intrusion protection can drop requests. If a whole address range finds fewer systems than the individual addresses, this is usually the cause. Set up an exception for the gateway.
  • SNMP devices: Allow the gateway’s machine in the access list of the SNMP devices; otherwise they do not respond.
  • Npcap: The driver for the IP scan hooks into the network stack and can conflict with Wireshark or PRTG. Where possible, do not install the gateway on a domain controller or Exchange server.

​
Keeping scan scripts current

  • Set the storage directory. The gateway places the scan scripts there and replaces them as soon as a scan module brings a new version. Scheduled tasks that start the scan script from this directory therefore always use the current version.
  • Replace copies elsewhere manually after an update, such as in the OneDrive folder or on Linux systems.
  • Run gensudo.sh again when the Linux script changes. The command list can grow.
How to distribute scan scripts and read in their results is described in Scanning by Script. Ports, permissions and common issues per scan module are covered in pages such as Scanning Windows, Scanning Active Directory and Scanning the Network over SNMP. The data refresh per edition is described in Editions and What They Include.