Individual installs work well on a computer, and perfectly acceptable on a few computers, but somewhere between three and twenty, individual installs just aren’t an answer. Like all commonly-encountered technical problems, the market offers a vast sea of vendors with solutions, all with their own spin on right way to solve it. Push out an installer to a thousand machines? No problem!
Quietly installing the Backblaze backup client presents two challenges. The Backblaze installer needs four credentials, three of which are mandatory. The first is userPassword, the new password for the user’s Backblaze account. Although some administrators prefer to dole out these passwords individually, most prefer to set the password to none. This forces the user to reset the password on their first visit to Backblaze web site to manage the account.
Of the remaining three, two of them are easy (the groupID and groupToken, to identify the group to join, and the permission needed to join it) and a group administrator can get them directly from our site in the group management section.
The final credential, userEmail, is the email address used as the Backblaze account identifier. Some administrators prefer to back up all machines under a single account, but this means all requests to retrieve data must go through the system administrators. This both imposes additional work on the administrator and renders the backup less valuable (since it is slower for an end-user to access). Ideally, each user will back their system up to their own nice, safe, sandboxed account (This data can either be restricted to access only by the end-user, or by both the end-user and the group administrator as a group-wide policy). The only downside is that this requires the end-user’s email address, and deriving the primary user’s email from the hostName is harder to automate. Email addresses are not always stored as part of the primary user information, and even mapping from a physical computer to a primary user can present obstacles.
In any particular environment, however, there is always some way to get the data. Rather than ask the administrator to customize any particular part of script, however, it seemed more useful to ask something a little simpler of the administrator: a comma-separated-value (.csv) file that includes the hostName and userEmail. With that, and this instbb.ps1 powershell script, a mass windows deploy from any management system should be simple. Every serious deployment system for Windows supports running a powershell script on a remote system.
instb.ps1 is a straightforward script. Once it is pushed to the remote machine, it determines what parameters it needs, finds them, copies a directory containing the Backblaze backup client installer from its origin, and runs it. Along the way, it checks to make sure that it has the parameters it needs, that the files and locations it assumes are present actually are present, and that the installation works smoothly. Any error is a fatal one, and the script will terminate by throwing an error (with a helpful message).
Script Functional Flow
The script is conceptually straightforward:
- It identifies the parameters, and validates them to the extent possible
- It creates a temporary directory in the Windows temporary directory for this account
- If the script was not given a userEmail to use, it uses the computer’s hostname to find the correct email address from the specified.csv (comma separated value) file
- It copies the backblaze_install.exe file (and any other support files) into the new directory
- It stores the location of the current working directory
- It changes the working directory to the temporary directory
- It runs the installer, which unpacks files into the temporary directory
- It returns to its original working directory
- It deletes the temporary directory and its contents, cleaning up the installation
What becomes problematic is, as always in dealing with computers, the exception handling. Each step has its own way of going wrong, from missing or incorrect parameters to errors based on actual hardware or configuration failure.
Additionally, a system administrator may need to make changes. For example, the sysadmin might be able to query Active Directory directly rather than relying on a csv file. Setting the internal $debug flag to $true enables some additional verbose output.
The script design allows parameters to be hardcoded or passed in directly; hardcoding parameters will override any parameters passed into the script. For the most part, the variables share their name with the parameter flag: for a parameter -groupId, the internal variable is groupId. For this script, the location of the backblaze client install directory ($BACKBLAZE_INSTALL_DIR) must be hardcoded. Any of the other parameters might vary in an installation, as different users might be placed into different groups. The install directory, on the other hand, does not vary. Hardcoded settings take precedence over things passed via command line. To have overridable defaults, add the desired defaults as defaults rather than hard-coding in the value.
This is the ID of the group which manages the individual users. Although some enterprises divide users into multiple groups, most companies find they only need a single group. This information is available from the Backblaze website by logging into the account that manages the group (or groups). The groupID is a short hexadecimal identifier string such as: c9455aff3b26.
If not hardcoded into the script, it can be passed in as a parameter:
This is an authorization token (similar to an account password) that provides permission to join the group; the token is the same for all users, and is found similarly to the way the groupID is located. However, the groupToken can be reset at any time, rendering old tokens useless whereas the groupID never changes. The groupToken is a hexadecimal identifier string such as: 0d134e976e3f3508ba267f12c317efa3483842e7b2.
If not hardcoded into the script, it can be passed in as a parameter:
This is the email of the user responsible for managing the backup data. If present, the script will use it rather than looking the value up in a .csv file (even if that file is provided or hardcoded into the script). If not present, then the script will default to looking up the name in the provided .csv file by machine hostname.
Some installations want to assign a password, and the password may be specified here. If no password is specified, the special value none is used in the installer, and the user will have to reset her password on the Backblaze web site before she can log in.
Either this must be specified, or the userEmail must be specified; the installer has to get the email address to associate with the account somewhere. Alternately, it can be hardcoded in the script. This file must contain a CSV file (with headers) that includes the machine hostname and email address, preferably as Hostname and Email, respectively (the script defaults to looking for those headers).
data\ backblaze\ commaseparatedfile.csv
When reading from a csv file, the script uses this parameter to identify the user email. If not specified, it defaults to Email. If the header were PrimaryEmail, for example, the parameter would be set as:
When reading from a csv file, the script uses this parameter to identify the header for machine’s hostname. If not specified, it defaults to Hostname. If the header were machineName, for example, the parameter would be set as:
Creating a directory for the Backblaze installer and then copying the entire directory over (rather than just the installer) simplifies both the installation and cleanup of the installation. This directory can be hardcoded into the script, or passed as a parameter.
data\ backblaze\ installDir
A gist containing the powershell script can be found here: