Skip to main content
Some systems are out of the gateway’s reach: the firewall does not allow access, the path is a double hop, the device is mobile or in a home office, or the backup server is isolated. Such a system scans itself with a scan script and writes a result file. A job with the File Import scan module then reads the result files into the inventory through the gateway. Scanning by script has three parts:

Storage directory

In the gateway’s window, you set the Storage Directory in the Settings tab. Whenever the scan modules are updated, the gateway updates the scan scripts there automatically. The gateway’s service account needs full access to the directory—see Setting the Storage Directory.

Scan scripts

Where the scan scripts run

  • Copy Discovery-ActiveDirectory.exe, Discovery-DFS.exe, Discovery-DHCP.exe, Discovery-DNS.exe, Discovery-HyperV.exe and the Veeam scripts to the respective server and run them there.
  • Discovery-Nutanix.exe, Discovery-Proxmox.exe and Discovery-HPE.exe run on any machine that can reach the target system.
  • Discovery-Windows.exe runs on the system it scans. User rights are enough for the local system. It needs administrator rights for BitLocker, antivirus, power options, BIOS type, Secure Boot, TPM and user profiles.

Parameters of all Windows scripts

Every Windows script (Discovery-….exe) writes a .dsi file and accepts these parameters:
The help of Discovery-Windows.exe appears as a window, not in the console.

Parameters per script

Without -noExtendedAttributes and -noPersonalData, Discovery-ActiveDirectory.exe captures both kinds of data. Example from the help:
With -u and -p, 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 Discovery-ActiveDirectory.exe, use integrated sign-in where possible and omit -u and -p.

Linux

Transfer Discovery-Linux or Discovery-Linux-Legacy to the system, make it executable with chmod +x and start it as root. Redirect the output to a file:
Without the redirection, the result appears only on the console. Copy gensudo.sh to the Linux system, make it executable with chmod +x gensudo.sh and start it with ./gensudo.sh. It prints a line for the sudoers file: yourusername ALL = NOPASSWD: followed by every command the scan runs as root. Replace yourusername with the scan user and add the line to the end of the sudoers file with visudo.
The command list changes with new versions. Always use the output of the current gensudo.sh.

Storing scan scripts and results

A hidden share on the gateway’s machine with two folders is recommended: For the permissions, Microsoft’s approach is recommended: Everyone with full control on the share, and through NTFS permissions only the groups Domain Computers and Domain Controllers with Modify. The results folder is also the Folder Path of the File Import job. The gateway’s service account needs read and write access to it. If the gateway runs under the local system account, the folder must be local on the gateway’s machine; for a share, the gateway needs a domain account with access to it.

Automating the run

Scheduled task through Group Policy

For Windows systems in a domain, above all for Discovery-Windows.exe on many machines, create a task in a Group Policy under Computer Configuration › Preferences › Control Panel Settings › Scheduled Tasks:
The name of the local system account depends on the language. With domain controllers in different languages, after creating the task, replace every account name in the runAs attribute in the file \\<domain>\SYSVOL\<domain>\Policies\<policy GUID>\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml with the SID of the local system account, S-1-5-18.

Scheduled task on the server

For the scan scripts that run on a single server—domain controllers, DFS, DNS, DHCP and Veeam servers—create a task in the server’s Task Scheduler, such as weekly on Sunday. It runs under an account with the rights of the respective service or under the local system account, with Run whether user is logged on or not and Run with highest privileges. The action starts the scan script from the share with -o pointing to the results folder.

Software distribution and logon script

Any software distribution tool can start the scan scripts as well. On Linux systems, a Bash script that runs at logon or an entry in crontab starts the scan script.

Mobile devices and home office

Scanning through the gateway often does not reach mobile Windows systems. Two approaches keep them current regardless. Both distribute a scheduled task through Group Policy or software distribution. The Group Policy applies once the user has signed in at the office at least once.

Over VPN

The task starts Discovery-Windows.exe only when the VPN connection is up. Users often establish the connection only after signing in.

Over OneDrive

This approach needs only an internet connection and a dedicated OneDrive account that all mobile workstations share. Other cloud storage works the same way.
  • Add the account on each device with its own folder, such as C:\Docusnap, and turn off the backup of your folders during setup.
  • The Script folder holds the current Discovery-Windows.exe.
  • The task runs under the local system account, with the trigger At log on for any user, and writes with -o to a folder in the OneDrive directory. OneDrive may not be connected yet at sign-in; allow several retries after a failure in the task’s settings.
  • Set up the same OneDrive account on the gateway’s machine. The File Import job reads the results folder from there.

Reading in the results

Create a job with the File Import scan module and, in the Path Selection step, enter the results folder as an absolute path under Folder Path, such as C:\Import\ or \\Server\Share\. The job reads all result files in the folder, whichever scan script wrote them. As a recurring job, it collects the results of the scheduled scan scripts regularly.
The job deletes the result files after reading them. To keep copies, use the script’s -a parameter in its output directory, not in the import folder.
The File Import scan module with its permissions and prerequisites is described in Capturing Files via File Import. You set up the directory for the scan scripts in Setting the Storage Directory. Schedules and account choice across all scan modules are covered in Scanning Best Practices.