Windows DriveStrike Mass Deployment Guide
DriveStrike can be deployed by IT administrators via mass deployment mechanisms (e.g., via Active Directory GPOs, or via a third-party asset management system). This document details the steps required to deploy DriveStrike via these mechanisms.
Step 1: Obtain a mass deployment token
Since mass deploying DriveStrike has the potential to impact a large number of devices, we currently require IT administrators to call the DriveStrike support line to authorize mass deployments on their accounts. This process is very simple, and can be completed in just a few minutes.
When mass deployments have been enabled on your account, your DriveStrike support agent will provide you with a mass deployment token, which is simply an alphanumeric string. It is important to safeguard this token, since anyone who has this token can register an unlimited number of machines on your DriveStrike account.
The mass deployment token will not expire, so you can use it to deploy DriveStrike to machines in the future as well. If you ever find that this token has become compromised, please contact DriveStrike support to obtain a new token.
Step 2: Configure your deployment mechanism
You will need to configure your deployment mechanism to run the DriveStrike installer with these custom parameters:
- /massDeployEmail=[device owner email]
Note that the massDeployEmail parameter is not required to be an actual email address. This value is used to group devices presented on the drivestrike.com Dashboard view, and is even editable on that page.
Assuming you were issued a mass deploy token of abc123, here are some examples for various deployment scenarios:
# Example #1: Register all deployed machines under the email email@example.com.
# On the drivestrike.com Dashboard page, all machines would be grouped under the
# firstname.lastname@example.org group.
setup.exe /massDeployToken=abc123 /massDeployEmailemail@example.com /verysilent
# Example #2: Register machines by department. On the drivestrike.com Dashboard page,
# machines would be grouped under “Accounting” and “Sales”.
# Push this command to all machines in the Accounting department
setup.exe /massDeployToken=abc123 /massDeployEmail=Accounting /verysilent
# Push this command to all machines in the Sales department
setup.exe /massDeployToken=abc123 /massDeployEmail=Sales /verysilent
# Example #3: Register each machine individually. On the drivestrike.com Dashboard
# page, there would be many groupings, each containing a single machine.
setup.exe /massDeployToken=abc123 /massDeployEmail=%COMPUTERNAME% /verysilent
Step 3: Test your deployment
To confirm you have the proper mass deployment token, use a test machine (or VM) and run the DriveStrike installer and provide the mass deployment parameters mentioned in the previous section. Since no UI will be displayed, you can use the Windows Task Manager to monitor the state of the setup.exe process. Once the setup.exe process completes, log into the drivestrike.com website, navigate to the Dashboard page, and confirm that you see the expected device owner, with a device that shows up in the “Ready” state.
After you confirm the machine installed correctly, you can uninstall DriveStrike from the machine and delete the device and device owner objects from the DriveStrike website.
Next, you may wish to push the DriveStrike installer to a test machine (or VM) via your preferred application deployment mechanism, to confirm the software delivery channel.
Step 4: Deploy to production machines
When you deploy to production machines, you can always monitor the status of your deployment through the drivestrike.com Dashboard page. Machines to which DriveStrike has been deployed successfully will be visible in the Dashboard and show a status of “Ready.”
Appendix A – Deploying via GPO or SCCM
IT administrators may choose to deploy DriveStrike via Active Directory / GPO, or using a centralized management system such as Windows SCCM or LanDESK.
To deploy via these mechanisms, it may be necessary to first wrap the DriveStrike setup executable in an .msi installer. Not only does this allow encoding the required command-line parameters into an installable package, but it is also a requirement when deploying via GPO and SCCM.
An easy (and free) tool for wrapping an executable in an .msi package is MSI Wrapper, available from https://exemsi.com. To use this tool, first install DriveStrike manually on a target computer. Then install MSI Wrapper on that same computer (to let MSI Wrapper look up DriveStrike registry information). The screenshots below illustrate the process of running the MSI Wrapper tool.
First, select the setup executable downloaded from the DriveStrike website, and provide an output location for the .msi:
These defaults are all OK, so simply hit [Next].
When prompted for the application ID, click the [Look up] button and select DriveStrike. If DriveStrike is not shown on the list, install DriveStrike manually on the computer and then re-run the MSI Wrapper tool. For the upgrade code, click the [Create New] button to populate a default GUID.
The MSI Wrapper tool will populate the product name and related information.
These values can all be left blank.
On the Parameters screen, make sure you enter the required parameters for running the setup executable (see the section named Step 2: Configure your deployment mechanism above):
The Before Install and After Install commands may be left blank as well.
On the final screen, hit [Build] to generate the .msi.
Appendix B – Installation Notes
The DriveStrike installer depends on the .Net runtime version 4.6.2 or later. When the installer is launched, it first queries the .Net runtime versions present on the machine, and then downloads and installs an appropriate .Net version if necessary. Note that this requires that target machines have internet access.
If mass deployment parameters are passed to the DriveStrike installer, the .Net installer is launched in a “quiet” mode that shows no UI.
Silent Installers and the UAC
The /verysilent flag passed to the DriveStrike installer is appropriate for unattended installations, as long as the installer process is launched with appropriate admin privileges. The installer requires elevated permissions, and will query the user for such if it was not launched with elevated privileges.