> ## Documentation Index
> Fetch the complete documentation index at: https://www.docusnap.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Scanning Best Practices

> Choose accounts with the least privilege, split jobs, set schedules and timeouts, and classify warnings in your monitoring.

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:

| Scan module | What is enough |
| - | - |
| *Active Directory* | a domain user, as long as Active Directory has a standard configuration; domain administrator only for the configuration partition and BitLocker keys, or a delegation for these |
| *Windows DHCP* | local administrator on the DHCP servers |
| *Nutanix* | a user without a role—this results in view permission |
| *VMware* | role ReadOnly |
| *Proxmox* | read rights on the cluster, user with realm |
| *Storage* | role Browse |
| *Cisco Meraki* | API key with organization-wide read rights |
| *Oracle Database* | `CREATE SESSION` and `SELECT ANY DICTIONARY` |
| *Microsoft SQL Server* | without sysadmin, a restricted scan |
| *Microsoft 365*, *Microsoft Intune* | Global Administrator only to create the app; the app only reads |
| *Linux* | a user with `sudo` for exactly the commands from `gensudo.sh`, instead of `root` |

* **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](/docs/en/scan/windows#common-issues).
* **Domain accounts** are entered with the domain: `DOMAIN\user` or
  `user@domain.internal`.

<Warning>
  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`.
</Warning>

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.

<Warning>
  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.
</Warning>

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.

## Related

How to distribute scan scripts and read in their results is described in
[Scanning by Script](/docs/en/scan/scan-by-script). Ports, permissions and common
issues per scan module are covered in pages such as
[Scanning Windows](/docs/en/scan/windows),
[Scanning Active Directory](/docs/en/scan/active-directory) and
[Scanning the Network over SNMP](/docs/en/scan/snmp). The data refresh per edition is
described in [Editions and What They Include](/docs/en/settings/editions).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.