Using Searches to find Computers without Software Installed in ConnectWise Automate (LabTech)

ConnectWise Automate is really good at finding computers WITH software currently installed, but there isn’t a good way to find software that is NOT installed. I was in dire need of a way to track the successful deployment of a new antivirus software (Bitdefender). Unfortunately, when you look for installed software that does not equal “Bitdefender Endpoint Security Tools”, you will receive a record of every piece of software installed. Not very helpful. However, it is very easy to search based on EDF values!

The above graphic depicts our final search query…pretty simple, right? Before creating the search, however, we need to make an EDF.

Step One (EDF)

Head over to System > Configuration > Dashboard > Config > Configurations > Additional Fields. From here, you can rename your Field and Tab, but I recommend keeping the ToolTip and you MUST keep the Data Screen to Computers. The Data Screen dropdown specifies which type of asset the EDF is applied to and it is awful hard to search for a Ticket’s installed software…

Field Name: BitdefenderInstalled
Field Type: Text (checkbox “should” have the same affect, but I ran into issues with the search)
Tab: Software
Data Screen: Computers
ToolTip: 1 = Installed; 0 = Not Installed.

In case I didn’t want to have the automation install Bitdefender, I also added a field for ExcludedInstallation, which serves the same purpose. 1 = Excluded, 0 = Active. I set a catch in the scripting that exited if the ExcludedInstallation field was set to 1.

Step Two (AutoJoin Search)

We need to take the search (shown above) and assign it to an auto-join group. This will make it very easy to determine which computers have not yet received the software installation and take actions upon those computers. Add a group and use the AutoJoin Searches to both ‘Limit to Search’ and set the group to grayed master.

Now that we have our group in place, we can start our automation or manual process to install the software, keeping in mind that we will need to run some sort of script to resend software inventory, then check that inventory for our software. Based on the results of that check, we will need to write to our EDF either a 1 or 0. I included these components in my installation script, which was applied as a scheduled script against the computers in the Auto-Join search.

Step Three (Script)

Whether you are running full automation or manually, keep these items in mind for the information pulled into the AutoJoin search to be accurate.

  • Resend Inventory
  • Set EDF to 1 if inventory contains software
  • Don’t install twice (add proper logical flow with your resend inventory)
  • If you plan on having an Exclusion catch, make sure your AutoJoin search contains a NOT EQUAL.
  • How are you dealing with offline computers?

For reference, this is the exact script I used to install Bitdefender. This will, of course, change for every software. Once I set this live, it deployed to several hundred PCs nearly flawlessly – just be careful as to how much traffic you may be pushing over the network. I spread my scripts out across several hours to decrease bandwidth consumption.

Note: This general framework is missing several pieces of information that       one might need to install software. It is not intended as a step-by-step tutorial, but rather as a guide from which the proper techniques can be  developed on a per software  basis.  Software  is too convoluted  to have  a  single solution. 

Disclaimer: As a human, I will inevitably make mistakes and get things wrong. If you  notice an error, or have a better solution, please let me know!

PC Deployments

Over the past couple of weeks I’ve been working on a PC deployment script using PowerShell – the goal is to run the script, walk away, then come back and the computer should be completely set up.

My original version included a lot of proprietary/confidential information as the commands were hard-coded into the script. Obviously, that’s not very good for distribution or customization internally. Thus began the effort to make the script entirely customizable through XML and CSV files.

The basic premise is that there are three stages of deployment – with a reboot in-between each one. This allows changes, such as computer name, domain join, windows updates, etc. to be applied. However, as the PC reboots, it needs to re-initialize the script and resume from where it left off. I ran into a few struggles with the re-initialization/persistent powershell scripts on my virtual machine which were solved through this post ( So, the deployment might look something like this:

Stage One: Create user accounts, install software, reboot.

Stage Two: Windows Updates, set computer name, domain join, reboot.

Stage Three: Windows Updates (yes, again!), set power configuration, re-apply the license key (dell manufacturing line issues), copy files from a network share, reboot.

The current version of the script can be found on Github. Right now, I’m debugging the script (there are definitely kinks to be worked out), but the proof of concept is enough to be considered viable.

Disclaimer: As a human, I will inevitably make mistakes and get things wrong. If you  notice an error, or have a better solution, please let me know!

Out of Space on Windows? Updates At Fault.

It seems like each time a client comes to me complaining that their hard drive is full it’s for one of two reasons.

  1. Their hard drive is 40GB.
  2. Windows Update creates unnecessary ‘cab’ files and clutters up the Temp directory.

Of course, this is by no means an exhaustive list. However, it just seems to happen most of the time. When you run WinDirStat (Site/Direct Download v1.1.2) the folder with the most content is C:\Windows\Temp. Oftentimes, I see this location taking up >50-100GB of space. Luckily, the fix is very easy. Delete all the cab files in the C:\Windows\Temp folder.

The data isn’t important and can safely be removed. For one, its in a Temp folder. Also, the cab files are just Windows Update download files…so if they really need to be on the system…they will re-download. Only the hope is that next time Windows actually installs them.

I wrote a Powershell script that is meant to be run on a weekly basis and clears up all of the cab files that have an age greater than 1 week. It’s up to you whether to use an RMM or Task Scheduler, or simply run it once.┬áHere’s the one-liner.

Get-ChildItem -Path "C:\Windows\Temp" -Filter "cab*" | Where-Object {$_.CreationTime -lt ((Get-Date).AddDays(-7)) } | Remove-Item -Force

Disclaimer: As a human, I will inevitably make mistakes and get things wrong. If you  notice an error, or have a better solution, please let me know!