What we've come up with is a framework for deploying software. This framework makes the assumption that the software can be deployed by the use of a command line with appropriate parameters. Ideally, parameters would be available to provide a silent (or at least non-interactive) installation of the software. If that isn't available at all, then you might want to rethink the deployment of that software!

This framework consists of two main scripts, both of which are based on the exact same template with one minor difference: Install.cmd and Update.cmd.

  • Install.cmd - This script (like Update.cmd) performs all of the necessary pre-system checks and looks for the software to already be installed. If it is found, but the version is older than the target version, the script will uninstall the previous version and then install the version that is part of the package. If no version is installed, this script will still install the software. The script then sets up any configuration of the software that it can and finally marks the registry so that software deployment tools know whether the installation has been run or not.
  • Update.cmd - This script (like Install.cmd) performs all of the necessary pre-system checks and looks for the software to already be installed. If it is found, but the version is older than the target version, the script will uninstall the previous version and then install the version that is part of the package. Unlike the Install.cmd script, however, if no version is installed, the script will not install the software. If the the script installed the software, it will configure it. Whether the software was installed or not, a registry key is set so that the software deployment tools know that the script has been run.

Why the two versions of the script? Generally, once software is deployed in an environment, it is desirable to maintain the software with upgrades and fixes over time. Given that software enters the environment in several ways (authorized by group via a software deployment solution, admins installing it on behalf of users, users installing it themselves), you may not always know which systems have an older version and which do not.

Therefore, it is recommended that you deploy the Update.cmd script with a target of all of the computers in your environment. If the software is found, it will be ugpraded. If it isn't installed on that computer, then the script will simply indicate that it has been run and exit with no other changes to the computer.

The Install.cmd script should be targeted at your "authorized users" groups or be the mechanism that your administrators use to manually install software on a given computer. Your operating system deployment solution should also use this script to install and configure the software on given computers.

If the installation requires elevated rights (and it probably does), because these are command scripts, in Windows, you can just right click them and click Run as Administrator.

Using the list of items on the right, the files and processes that make up the solution are listed on the right.

Generally, your package would be in a folder with the files necessary to perform the installation all together. Although not required, we would recommend that the software's files not be in a subfolder, but at the root of your package folder. If the software itself has subfolders, that's fine. This just makes referencing and dereferencing package paths a lot easier.