Files
management-scripts/README.md
T
2026-09-30 10:34:09 -04:00

4.1 KiB

Management Scripts

Most scripts here require the Tools.ps1 script. You can dot source that script like this:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
. $([Scriptblock]::Create((New-Object Net.WebClient).DownloadString('https://dev.emberkom.com/emberkom/management-scripts/raw/branch/master/Tools.ps1')))

On older Windows PowerShell/.NET configurations, select TLS 1.2 before the first HTTPS download. The TLS setting inside Tools.ps1 cannot help download Tools.ps1 itself. See Microsoft's PowerShell TLS guidance.

You can then run any of the scripts using the Run-Script function: Run-Script -LivePSScript Script-Name

If you're using an RMM tool, the scripts in the /rmm directory are all that's needed to hook the main script in this directory.

For DSA collection, paste rmm/Get-DSAManifest.ps1 into the RMM caller, preserving its configured platform variables. This caller selects TLS 1.2 before downloading, stops on bootstrap failure, and dot-sources the downloaded tools in the caller's scope. Updating the repository alone will not change an existing RMM caller.

For download failures, use the standalone Test-FileDownload.ps1 diagnostic. See the RMM caller, report guide, and shared caller audit. It compares the existing helper, BITS, and direct GET without changing production download behavior or running downloaded files.

Uploading files

After dot-sourcing Tools.ps1, scripts can upload a completed file to the Emberkom FileDrop:

Upload-File -Path 'C:\ProgramData\Emberkom\Output\report.zip'

Get-DSAManifest.ps1 uploads its completed CSV or ZIP when $Upload is enabled. If $DeleteAfterUpload is also enabled, it deletes that same local file only after a confirmed successful upload. Disabled or failed uploads retain the file. $Zip, $Upload, and $DeleteAfterUpload all accept true, $true, yes, y, or 1; false, $false, no, n, 0, or an empty value disable the option. Casing and surrounding whitespace are ignored. The notification subject identifies the computer, and its message includes the source path and collection start time (local time with UTC offset).

The default destination is https://xfer.emberkom.com/filedrop/cmd. The sender defaults to the computer's hostname plus its primary DNS suffix, followed by @ek-upload.net (for example, pc01.example.com@ek-upload.net). Without a DNS suffix, it uses the hostname. Override these with -FileDropUrl and -From; -Subject and -Message are also optional.

Upload-File uses the LiquidFiles FileDrop API to obtain a temporary token, upload the file, and submit the message that triggers FileDrop delivery and its configured email notification. It returns a receipt with the path, destination, sender, attachment ID, byte count, and server status. It retains the local file and throws on failure.

Uploads use binary chunks with a default 10 MiB buffer, so large files do not need to fit in memory. The FileDrop's size and extension restrictions are checked before upload. -ChunkSizeMB, -RetryCount, and -TimeoutSeconds control chunk size, retries, and each request's timeout; -Verbose displays transfer details.

Allow the RMM job to run for the entire upload. The function waits for completion and retries failed chunks within that run; it does not resume across process restarts. LiquidFiles tokens expire after 24 hours. Final submission is attempted once: if its response is lost, check the FileDrop before rerunning to avoid duplicate notifications.

Offline tests (no uploads or notifications):

powershell.exe -NoProfile -File .\tests\Upload-File.Tests.ps1
powershell.exe -NoProfile -File .\tests\Get-DSAManifest.Tests.ps1
powershell.exe -NoProfile -File .\tests\Download-File.Tests.ps1