> ## 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 by Script > Let systems the gateway cannot reach scan themselves with a scan script, and read in the results with File Import. 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: | Part | What happens | | - | - | | Provide the scan scripts | The gateway places them in the *Storage Directory*. | | Run the scan scripts | manually, as a scheduled task, through Group Policy, software distribution or a logon script; the result file goes to a shared folder | | Read in the results | A job with *File Import* reads the folder. | ## 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](/docs/en/scan/gateway-storage-directory). ## Scan scripts | File | Scan module | Used for | Result file | | - | - | - | - | | `Discovery-ActiveDirectory.exe` | *Active Directory* | Active Directory, locally on a domain controller | `.dsi` | | `Discovery-DFS.exe` | *DFS* | DFS, locally on the namespace servers, without a double hop | `.dsi` | | `Discovery-DHCP.exe` | *Windows DHCP* | DHCP data, locally on the DHCP server | `.dsi` | | `Discovery-DNS.exe` | *Windows DNS* | DNS data, locally on the DNS server | `.dsi` | | `Discovery-HPE.exe` | *Storage* | HPE 3PAR, Alletra, Primera without a firewall rule | `.dsi` | | `Discovery-HyperV.exe` | *Hyper-V* | Hyper-V host, locally | `.dsi` | | `Discovery-Linux` | *Linux* | Linux, 64-bit, without SSH or without `root`/`sudo` | freely named `.xml` | | `Discovery-Linux-Legacy` | *Linux* | Linux, 32-bit | freely named `.xml` | | `Discovery-Nutanix.exe` | *Nutanix* | Nutanix cluster without a firewall rule | `.dsi` | | `Discovery-Proxmox.exe` | *Proxmox* | Proxmox cluster without a firewall rule | `.dsi` | | `Discovery-VeeamBR.exe` | *Veeam B\&R* | Veeam Backup & Replication 13 | `.dsi` | | `Discovery-VeeamBR-Legacy.exe` | *Veeam B\&R* | Veeam Backup & Replication 12 | `.dsi` | | `Discovery-Windows.exe` | *Windows (AD)*, *Windows (IP)* | Windows systems without direct access | `.dsi` | | `gensudo.sh` | *Linux* | prints the `sudo` rule for the scan user | – | ### 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: | Parameter | Effect | | - | - | | `-h` | Help | | `-o ` | Output directory of the result file, such as a share; the running account needs write permission there | | `-n ` | Name of the result file (`.dsi`) | | `-a ` | Number of older results kept, default 4 | | `-l ` | Log level: `Debug`, `Information`, `Warning`, `Error`, `Critical`, `None`; default `None`, `-l` without a value means `Debug` | | `-w ` | Working directory for temporary data | The help of `Discovery-Windows.exe` appears as a window, not in the console. ### Parameters per script | Script | Own parameters | | - | - | | `Discovery-ActiveDirectory.exe` | `-domain `—without it: the machine's domain · `-u `—without it: integrated sign-in · `-p ` · `-noExtendedAttributes`—extended and custom attributes of the objects are not captured · `-noPersonalData`—personal data is not captured · `-syncParallel `—number of parallel secondary domain controllers, default 8 | | `Discovery-DFS.exe`, `Discovery-DHCP.exe`, `Discovery-DNS.exe`, `Discovery-HyperV.exe` | none—they run on the server itself, with the identity they are started under | | `Discovery-Nutanix.exe` | `-t ` · `-u ` · `-p ` | | `Discovery-Proxmox.exe` | `-t ` · `-u ` with realm, such as `docusnap@pam` · `-p ` | | `Discovery-HPE.exe` | `-t `, also as a URL with port, such as `https://storage.example.com:8080` · `-u ` · `-p ` | | `Discovery-VeeamBR.exe`, `Discovery-VeeamBR-Legacy.exe` | `-MaxHistoryInDays `—days of backup history, default 42, at most 999 | | `Discovery-Windows.exe` | none—only the common ones | Without `-noExtendedAttributes` and `-noPersonalData`, `Discovery-ActiveDirectory.exe` captures both kinds of data. Example from the help: ``` Discovery-ActiveDirectory.exe -domain example.com -u user -p password -noExtendedAttributes -noPersonalData -syncParallel 4 ``` 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: ``` ./Discovery-Linux > /path/result.xml ``` 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: | Folder | Example | Permission for the systems | | - | - | - | | Scan scripts—also the storage directory | `C:\DocusnapScript\Scripts`, shared as `\\\DocusnapScript$\Scripts` | Read | | Results, one per organization or domain | `\\\DocusnapScript$\#` | Modify | 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*: | Tab | Setting | | - | - | | *General* | as the account, the local system account `NT AUTHORITY\SYSTEM` (recommended) or an account with local administrator rights; *Run whether user is logged on or not*; *Run with highest privileges*; *Configure for* the matching operating system | | *Triggers* | on a schedule, such as weekly on Monday at 10:00; more often for more current data | | *Actions* | *Start a program* with `\\\DocusnapScript$\Scripts\Discovery-Windows.exe` and the argument `-o "\\\DocusnapScript$\#"` | | *Settings* | *Allow task to be run on demand*; *Run task as soon as possible after a scheduled start is missed*; *Stop the task if it runs longer than* 1 day | 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 `\\\SYSVOL\\Policies\\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. | Tab | Setting | | - | - | | *Triggers* | *On an event*, log *Microsoft-Windows-NetworkProfile/Operational*, source *NetworkProfile*, event ID *10000* | | *Actions* | *Start a program* with the UNC path to `Discovery-Windows.exe` and `-o` pointing to the results folder | | *Conditions* | optionally restricted to a specific network | ### 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. ## Related The *File Import* scan module with its permissions and prerequisites is described in [Capturing Files via File Import](/docs/en/scan/file-import). You set up the directory for the scan scripts in [Setting the Storage Directory](/docs/en/scan/gateway-storage-directory). Schedules and account choice across all scan modules are covered in [Scanning Best Practices](/docs/en/scan/best-practices). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.