FYI – There is a new FAQ posted here: BatchPatch – Frequently Asked Questions (FAQ)
We will be adding more to it in the coming weeks.
The Best Windows Patch Management Software & WSUS Tools
FYI – There is a new FAQ posted here: BatchPatch – Frequently Asked Questions (FAQ)
We will be adding more to it in the coming weeks.
It seems like in the past year or so there has been a pretty significant need to remotely uninstall Windows Updates after discovering that a particular update has caused a problem in one’s environment. Unfortunately it’s often the case that even after testing updates in a lab environment, upon final deployment to production there are unexpected issues that can occur. Inevitably, at one point or another, most systems administrators end up having to remove updates that have been previously installed. While this isn’t necessarily always a huge deal, the reality is a problematic Windows Update can wreak havoc in certain situations. When it’s discovered that a particular update is causing major problems, usually it needs to be removed as quickly as possible. Sure, it’s easy enough to manual remove an update from each computer one at a time, but who has time for that, especially when management is breathing down your neck to rectify a major problem rapidly? That’s where BatchPatch comes in.
I’ve posted a handful of deployment tutorials in recent months, but I’ve never demonstrated how to remotely install one of the most popular web browsers — Google Chrome. Today I’ll show you how to use BatchPatch to deploy Chrome to many remote computers in just a few clicks.
Exit Code: 0 (SUCCESS)
One of the questions we regularly receive from users is “What is the best way to use BatchPatch as an alternative to WSUS?” Even though WSUS is free, lightweight, and relatively easy to install and manage, there are certainly cases where administrators don’t already have it and don’t want to deal with installing or managing it. After all, it *is* yet another thing to manage. Or perhaps there just isn’t any spare equipment to install it on. Whatever the reason, no matter. Below I describe how to get the most out of BatchPatch as a WSUS alternative.

We are going to uninstall Skype remotely in almost exactly the same way that we installed Skype remotely.

Installing Skype remotely isn’t much different than installing other applications remotely. Here’s how it goes:
If you need to uninstall Skype remotely, please follow the instructions at this link.
Today I’d like to demonstrate how to deploy Adobe Air to your entire network of computers in just a few clicks.

In the most recent release of BatchPatch there is a new menu option: Actions > Windows Updates > Reattach orphaned Windows Update process. I want to take a few minutes today to explain exactly what this is and when to use it.
As you probably already know, BatchPatch is “agentless” in the sense that it does not install a permanent remote agent service on target computers. Instead, all target computer actions are initiated by BatchPatch in a non-permanent fashion, which we call “agentless,” even though technically BatchPatch does still execute various remote processes or “agents.” The primary distinction is that BatchPatch does not install anything permanent on target computers to perform its duties.
Since the BatchPatch target computer executes Windows Updates actions in an “agentless” fashion, you might wonder what happens if your main BatchPatch console becomes disconnected from a target computer’s BatchPatch process. First, I should note that this is not something that would generally happen accidentally. When you execute a remote Windows Update action through BatchPatch, the BatchPatch console will display the progress of that remote action until the process completes. However, what if you accidentally or intentionally close the BatchPatch console while target computers are still processing Windows Updates actions that you initiated before closing the application? The Windows update download/install operation will continue to run on the target computers, but upon completion no reboot or shutdown will be executed because reboot/shutdown is triggered by the BatchPatch console, and it can only happen if the console is still connected to the target computer’s running Windows update process at the time the process completes its operations. This is where the new ‘Reattach orphaned Windows Update process’ comes in handy. The feature enables you to re-connect to the target computer’s BatchPatch process to continue monitoring remote Windows Update actions that you initiated prior to closing the application.
To use it you would simply reload your list of computers that are currently executing remote Windows Update processes, and then you would select the desired action. If you had previously selected one of the Windows Update actions that includes an automatic reboot at the end, then you would probably want to choose the corresponding reboot option when re-attaching the orphaned process, so that your reboot still occurs. If you want to continue monitoring the progress of the orphaned Windows Update action, but you do not want BatchPatch to automatically reboot when the updates finish installation, then choose the “no reboot/no shutdown” option for re-attaching.
That’s all there is to it. After executing the desired option, BatchPatch will re-establish connectivity with the target computer’s executing action so that it can continue to display progress updates in the main BatchPatch console, and can continue to process automatic reboots, if desired.
One of the more frequently requested features from our customers has been to provide the ability to notify the logged-on users of an impending reboot or shutdown. BatchPatch has provided the ability to send notifications to logged-on users for a long time through the ‘Actions > Send message to logged-on users‘ feature. However, in the most recent release we have also now integrated user notifications into the advanced reboot and shutdown commands, so that an administrator can more easily notify users in a single action, with no need anymore to execute multiple actions to accomplish the same task.
Windows has a built-in tool for executing a reboot/shutdown of a remote computer with built-in user-notification and event logging. This tool is accessible by typing shutdown.exe /i at the command line:
In the most recent release of BatchPatch we have provided a similar dialog:
In the November 2015 release of BatchPatch one of the cool new features is password protection with 256-bit AES encryption for your saved .bps / .bpt files. What does this mean? The contents of a .bps / .bpt file can be password encrypted such that after you have applied a password to a particular grid, when you save that grid, the contents will be encrypted on disk. Then later when you load the saved grid file into an instance of BatchPatch you will be prompted to enter the password to unlock/decrypt the file contents to be displayed in the grid.
Why might an administrator want to use this feature? In particular, if you are storing sensitive passwords in any of your .bps / .bpt grid files, this feature might be important to you. In BatchPatch if you’re using ‘Integrated Security,’ which means that you are launching the BatchPatch.exe in the context of a user that has been granted local administrator privileges on target computers, then you probably do not have any passwords stored in a grid or a saved .bps / .bpt file. However, for those of you who are using ‘Alternate Credentials’ in BatchPatch, which means that you have specified particular logon credentials for a given row/host or set of row(s)/host(s), this new feature might be just what you were looking for to increase overall security.
To add password protection to a grid simply click on ‘File > Password protect .bps/.bpt file contents…’ You will be presented with a dialog that enables you to apply a password to that grid, and then you’ll be prompted to save the grid.
To maximize security we recommend an absolute minimum of 12 characters for your password, though even longer is better! A good password should also contain a mix of uppercase letters, lowercase letters, numbers, and non-alphanumeric characters. A long, non-dictionary, high-entropy password is of paramount importance to prevent a brute-force (password-guessing) attack from being successful. Even though the encryption itself can’t be “cracked” per se, your password *can* be guessed, especially when it’s short and low-entropy. And when you’re using one password to protect a file that contains many other passwords, we strongly recommend using a very long, unpredictable password.
To further increase security and make a brute-force (password-guessing) attack even more difficult and time consuming, you may modify/increase the number of iterations used during key derivation (PBKDF2) under ‘Tools > Settings > PBKDF2 iterations.’