Best Practices for Multi-site Software Deployments – Part 2

3 min. read
By Nils Macharis

My name is Tom, I work for Webb Yates Engineers who have offices in London, Birmingham, Bristol, and Dubai. As a one-man IT department, working across these offices intelligently and remotely is key to provide the best value to the company.

I’ve used Lansweeper at a couple of previous organizations, however, it is here at this company that I’m heavily using the deployment module to improve the efficiency of the IT function. Over a three-part series, I will outline some top tips that I have found most useful when setting up Lansweeper to deploy across multiple offices. In my first post, I talked about the importance of a Distributed Filing System for deployments and installation shares.

Patching Actively Running Applications

When pushing out applications across the network using Lansweeper I found that when patching one specific software, the installation package didn’t check if the application was running at the time and would just kill the process without notification or alert. This was down to the vendor’s installation process, however, I thought it better to account for this in my deployment packages to prevent unhappy users.

This is the one line command that I used to understand if the application is running:
Tasklist /FI “imagename eq notepad.exe” | find /I “notepad” > nul

Let’s break this command down into manageable chunks:

  • Tasklist is a built-in windows command that displays a list of currently running processes on either a local or remote machine.
  • /fi Displays a set of tasks that match given criteria specified by the filter. This uses a simple syntax that is outlined by the command tasklist /?
  • In this case, my filter is imagename eq notepad.exe”. It finds all processes that have the image name “notepad.exe”.
  • Find is another built in windows command that searches for a text string in a file or files.
  • I’m using the /i denotes to ignore the case of the text.
  • In this case, I’m piping the results of tasklist directly into find.
  • The Find command by default returns exit codes if it can find the text specified or not. So, in this command, if the “notepad” is found in the output of tasklist, the exit code is 0. If it is not found, then the exit code is 1.
  • >nul Redirects the output to Null, as to suppress the output from the display.

We can see what return codes are generated from the command by looking at the %errorlevel% environment variable. Almost all applications and utilities will set an exit code when they complete or terminate. You can test this in the command prompt to check the correct exit codes: In this example, I’ve used a fictitious program to emulate that my program is not running:

Command Promp CDM Active Running Applications

Once satisfied, put it into the Lansweeper deployment module before the installation command as shown. In this example, if “gsa.exe” is running, an error code of 0 is reported, which does not match the defined “success codes”, therefore the deployment process should follow “Action on Failure”. Be sure to adjust your Success Codes and actions accordingly.

In the next and final part of this series, I’ll cover how I automatically download and deploy the Microsoft Azure Recovery Service Agent in my network. If you haven’t already, start your free Lansweeper trial and make time for what you do best.


Ready to get started?
You’ll be up and running in no time.

Explore all our features, free for 14 days.