Blog | BatchPatch - The Ultimate Windows Update Tool

Remotely Installing Adobe Air on Multiple Computers

By Scott | Published: December 28, 2015

Today I’d like to demonstrate how to deploy Adobe Air to your entire network of computers in just a few clicks.

Obtain the offline installation media for Adobe Air. At the time of this writing, the offline installation media file is posted at the following location: Adobe AIR Offline Installer. Note, you may be required to have a valid Adobe AIR Runtime Distribution License Agreement in place before you proceed with an installation. Please review Adobe’s documentation before proceeding: https://www.adobe.com/products/air/runtime-distribution3.html

Determine the silent installation parameter. At the time of this writing, Adobe has documentation posted here that describes the command line options available for the Adobe AIR installation media. We will use the -silent parameter so that BatchPatch can deploy the application. If you do not specify at least the silent installation parameter, then when you try to deploy via BatchPatch, the deployment will either hang indefinitely, or it will simply throw an error.

Test your installation parameters at the command line! We always recommend that before deploying an application silently with BatchPatch that you first test your syntax at the command line of a computer without using BatchPatch. Once your command line installation is working on a single computer, you can move it into BatchPatch so that you can deploy the program to numerous computers, simultaneously.

Select the desired hosts in your BatchPatch grid, and then select ‘Actions > Deploy > Create/modify deployment.’ In the deployment window that appears, browse to the offline installer executable, and add the -silent parameter, as illustrated in the screenshot below.

Execute the deployment with the ‘Execute now’ button. In the screenshot below you can see that I chose to deploy the application to only my ‘Win10’ machine (it’s the only one turned on at the moment). Success is indicated by the blue coloring and the “Exit Code: 0” printout in the log. That’s all there is to it! If I check the ‘Win10’ computer manually, I can see that Adobe AIR is, in fact, installed.

Posted in Blog, General, Tutorials | Tagged Remote Installation, remote software deployment, remote software installation, software deployment | Comments closed

Reattach Orphaned Remote Windows Update Processes

By Scott | Published: December 15, 2015

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.

Posted in Blog, General, Tutorials | Tagged remote windows update | Comments closed

Notifying Logged-On Users of Impending Reboot or Shutdown

By Scott | Published: December 8, 2015

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:

Initiating a reboot (or shutdown) with user notification:

When you want to initiate a reboot of a group of target computers, you would simply highlight all of the desired computers in your BatchPatch grid, and then you would select ‘Actions > Reboot > Advanced reboot with user-notification.’
In the ‘Advanced reboot‘ window that appears, select the checkbox to “Warn users of the action.” This checkbox is what controls whether or not the logged-on users will see a notification, so make sure it’s checked if you intend to let them know that the computer will be rebooted soon. In the ‘Comment’ field, type the desired note that you wish to be displayed. And then of course also make sure to set the time to the number of seconds you want the warning to be displayed before the reboot will occur. In the screenshot below I’ve set it to 300 seconds (5 minutes). If the user kills the notification by clicking the red X button, the reboot will still occur at the end of the 300 second countdown unless you abort it (see below for abort instructions).
After clicking OK, the reboot command and notification are sent to the target computers. Logged-on users will see a notification like this:
If for some reason you need to abort the impending reboot (or shutdown), you can use ‘Actions > Reboot > Abort impending reboot/shutdown countdown.’ This is the same as executing ‘shutdown.exe /a’ at the console of the computer.

Posted in Blog, General, Tutorials | Tagged reboot notification, shutdown notification | Comments closed

Protecting Sensitive Passwords in Saved BatchPatch Grid Files (.bps / .bpt)

By Scott | Published: December 1, 2015

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.’

Posted in Blog, General, Tutorials | Tagged encryption, password protection | Comments closed

Remotely Remove a Problematic Windows Update from Multiple Computers

By Scott | Published: November 18, 2015

It seems to be happening more and more frequently these days. Microsoft releases a Windows Update that causes some type of problem for users, and even though you are a stellar sysadmin with a solid process in place for testing Windows Updates before deploying them to your general user population, your thorough testing process somehow doesn’t reveal the issue. As such, you end up deploying the problematic update to all of your users’ computers, and now you want to remove / uninstall it as quickly as possible while you wait for Microsoft to publish a new, fixed version of the update. Don’t fret! With BatchPatch you can rectify the issue easily and quickly.

Uninstall individual Windows Updates from Newer Operating Systems (Windows Vista/7/8/10/2008/2012):

The process is actually very simple. Highlight the desired hosts in the grid and select ‘Actions > Windows Updates > Uninstall individual update’
In the dialog that is presented, enter the KB number of the update you want to uninstall. Then click OK.
On the confirmation dialog that appears, click ‘OK’ to execute the update removal process. That’s all there is to it.

Uninstall individual Windows Updates from Older Operating Systems (Windows XP/2003):

On Windows XP and 2003 we have to use a different method because they do not support WUSA.exe. Highlight hosts in the grid and then select ‘Actions > Execute remote process/command > Create/modify remote command 1’
Input the following command, but substitute your KB ID number for the one used in the code line below:
C:\WINDOWS\$NtUninstallKB123456$\spuninst\spuninst.exe /quiet /norestart
At this point simply click ‘Execute’ to initiate the Windows Update removal process.

Posted in Blog, General, Tutorials | Tagged remote windows update, remotely remove windows updates, remove windows update, uninstall windows update | Comments closed

Initiating Tasks on Computers that are Frequently Offline

By Scott | Published: November 11, 2015

One of the challenges that administrators often face is getting things done on user computers that rarely connect to the network. For example, part of your job might be to update Java, Adobe Flash, or Adobe Reader on all of your users’ computers. Inevitably it seems that you are able to get 90% done immediately while the other 10% take many days or even weeks (sometimes months!) simply because the users aren’t in the office frequently. And then when they are in the office, you don’t learn about it quickly enough to perform the update, so they’re back on the road before you get it done! Wouldn’t it be nice if you could just setup a job that would automatically run the update the moment the traveling users come back to the office and attach their computers to the network? Fortunately with BatchPatch this is actually very easy to accomplish.

In the BatchPatch task scheduler there is an option to “Run task immediately upon detecting target computer online.”

This scheduled task option works exactly as it sounds. It’s as simple as selecting any BatchPatch task such as downloading/installing Windows updates, deploying software, or executing a custom script or job queue, and then ticking the box to “Run task immediately upon detecting computer online.” BatchPatch will constantly monitor the network for the desired computer. As soon as BatchPatch detects that the computer is online, the task is executed. Below is a step-by-step tutorial.

Select the desired hosts in the BatchPatch grid, and then select ‘Actions > Task Scheduler > Create/modify scheduled task.’
In the task scheduler window select from the drop-down menu the desired task. In this case I’m going to choose a previously saved software deployment task that installs 7-zip (any deployment that you create in the ‘Actions > Deploy > Create/modify deployment’ window can be saved in that same interface).
Make sure that you have ticked the “Run task immediately upon detecting computer online” checkbox. Then click OK.
Lastly, make sure you enable the scheduler if it isn’t already running. Do this by clicking on the smaller clock icon in the upper right portion of the BatchPatch window.
That’s all there is to it! At this point you can simply go on about your other regular duties and just check back every now and again to see which computers have come online and received the update. Or if you prefer to receive an email notification each time a machine is updated, then instead of executing the software deployment directly from the task scheduler, setup a two-step job queue with the software deployment as the first step, and an email notification as the second step. Then from the task scheduler you can just execute that job queue with the same “Run task immediately upon detecting computer online” checkbox!

Posted in Blog, General, Tutorials | Tagged disconnected, offline, software deployment | Comments closed

Install Adobe Reader Remotely to Multiple Computers

By Scott | Published: November 3, 2015

In this tutorial I will demonstrate how to deploy Adobe Reader to multiple computers on your network, simultaneously, in just a few clicks. After the installation is complete, I will then execute a remote uninstallation.

Obtain the Adobe Reader offline installer package. At the time of this writing, the following link contains the offline installer downloads. For this example I downloaded the ‘Adobe Reader 11.0 – Multilingual (MUI) installer package.’ Adobe Reader Offline Installer Download
After downloading the .zip file, extract it. In the screenshot below you can see that I’ve extracted it to AdbeRdr11000_mui_Std.

The AdbeRdr11000_mui_Std contains the following items:
Now that we have the installation files, we’re ready to create the deployment in BatchPatch. Launch BatchPatch and highlight the desired hosts that will receive the deployment. Then select ‘Actions > Deploy > Create/modify deployment.’ The deployment window will appear.
In the deployment window, type a title (if you wish to save the deployment for future use), and browse to the .msi in the AdbeRdr11000_mui_Std folder that you created earlier. Also make sure to tick the option to ‘Copy entire directory contents in addition to the specified file.’
Now that we’ve selected our deployment options, we are ready to execute the remote software installation. Click ‘Execute Now,’ and then click ‘OK’ to confirm that you want to continue.
20 seconds later we see Deployment: Exit Code: 0 (SUCCESS). That’s all there is to it!
The process for uninstalling / removing Adobe Reader is almost identical as the installation process. For the uninstallation we have to change just a single parameter in the deployment configuration to select ‘uninstall’ instead of ‘install.’
We can then execute the uninstallation, if needed. Again, I’ll just click the ‘Execute Now’ button and wait. After 14 seconds, Adobe Reader has been uninstalled from the target computer. Once again we see Deployment: Exit Code: 0 (SUCCESS).

Posted in Blog, General, Tutorials | Tagged Remote Installation, remote software deployment, remote software installation, software deployment | Comments closed

Uninstall Adobe Flash Player from Multiple Computers

By Scott | Published: October 21, 2015

In a previous posting I demonstrated how to install Adobe Flash on numerous computers, simultaneously. In this posting I will demonstrate how to remove (uninstall) Adobe Flash from numerous computers, simultaneously.

Obtain the installation media. In this example we’re going to use the .msi installer file for Flash player version 19 for plugin-based browsers that Adobe makes available because it seems to be the simplest to use. Adobe has a specific distribution license agreement, so you should review that before you proceed with deploying Adobe Flash in your environment to make sure that you are complying with their rules. The following link has more information about that: Adobe Flash Player Distribution.

Once you have saved the installation media to your computer, you’re ready to proceed. I’ve put the ‘install_flash_player_19_plugin.msi’ file in my E:\temp directory on the computer that is running BatchPatch. Add the desired host(s) to the grid, and then select ‘Actions > Deploy > Create/modify deployment.’

In the Deployment window that appears, browse to the .msi file to select it. Then select the radio button option for ‘uninstall.’ Optionally give the deployment a title so that you can save it for future use. That’s all there is to the setup/configuration. Pretty simple, right?

To perform the actual removal/uninstallation task, you may select ‘Execute now’ to immediately initiate the removal for all highlighted hosts in the grid. Or if you prefer, give the Deployment a title, and then save it using the ‘>>‘ button, and then close the Deployment window so that you may execute the uninstallation later. For the sake of demonstration, I’ll show you what it looks like when we save it and execute it later.

After saving the deployment and closing the Deployment window, I’m now left with my normal grid view. I select the host(s), and choose ‘Actions > Deploy > Execute saved deployments > Remove Adobe Flash 19 for Plugin-based Browsers,’ because that’s the title I gave it in the previous step. When I mouse over the saved deployment, BatchPatch displays the deployment’s configuration in a tooltip, so that I can quickly confirm that I’m selecting the desired one.

When I click ‘OK’ I am prompted with a confirmation dialog that also displays the configuration of the deployment to be executed. The key part of the configuration (see the screenshot below) is the command:
msiexec.exe /x "install_flash_player_19_plugin.msi" /q
The /x is the removal parameter for .msi packages.

I click OK to proceed with the uninstallation of Adobe Flash Player from the selected computers.

After waiting a few seconds, the deployment is complete, and the Adobe Flash Player has been removed from the selected computer(s). We see Exit Code: 0 (SUCCESS), and we know that it’s done. We can also then confirm on the target computer that the Flash Player is gone.

Posted in Blog, General, Tutorials | Tagged remove adobe flash, uninstall adobe flash | Comments closed

Remote Software Installation with BatchPatch

By Scott | Published: October 12, 2015

Today I’d like to demonstrate a silent remote software installation with BatchPatch. We’ll deploy 7-zip to the computers in our lab. Once deployed, we’ll then go ahead and remotely uninstall it too.

Remote Software Installation – Deploying 7-zip to remote computers

Select the desired target host(s) in the BatchPatch grid, and then choose ‘Actions > Deploy > Create/modify deployment’
In the ‘Deploy’ window, browse to the 7-zip installer that you previously downloaded from 7-zip.org. I did a google search to see what the silent installation parameter is for the 7-zip 32-bit .exe installer, and it’s just a /S (case-sensitive). So, you can see in the ‘Deploy’ window screenshot above, I’ve browsed to the location of the 7z920.exe, and I’ve added the /S parameter.
All we have to do is execute the deployment now by clicking the ‘Execute now’ button. BatchPatch prompts us to confirm the deployment. Click OK to proceed.
A few seconds later the ‘All Messages’ column reports ‘Deployment: Exit Code: 0 (SUCCESS),’ and we’re all done! In the screenshow below I’ve expanded the ‘All Messages’ contents so that you can see exactly what BatchPatch did.

Remote Software Installation – Uninstalling 7-zip from remote computers

For the removal / uninstallation, we don’t need to deploy any files to target computers. Instead we simply need to execute a command. In the case of a default installation, the 7-zip files will be stored in “C:\Program Files\7-zip.” Make sure you identify the correct directory in your environment. Then highlight the host and select ‘Actions > Execute remote process/command > Create/modify remote command.’
In the ‘Remote process/command’ window, add the uninstallation command exactly as follows:
"C:\Program Files\7-Zip\Uninstall.exe" /S
Click ‘Execute’ to initiate the uninstallation. Then click ‘OK’ to confirm that you want to proceed.
After a few seconds we see ‘Remote Command: Exit Code: 0 (SUCCESS)‘ to indicate that the command has been executed. We can now check the target machine to confirm that the software has been removed.

Posted in Blog, General, Tutorials | Tagged remote software installation, software depoyment | Comments closed

Configure Computers to Automatically Logon after Reboot

By Scott | Published: October 5, 2015

Windows provides a feature that enables it to automatically logon after reboot, which can sometimes be very handy in certain environments. The configuration is applied through a series of registry values, which isn’t particularly convenient to enable manually. However, BatchPatch provides a quick way to apply the settings to target computers when you want to set them to automatically logon after reboot.

The most important thing to know about the automatic logon feature in Windows is that it creates a security vulnerability. In order to automatically logon after reboot, the computer stores the username and password in the registry in plain text. In some environments, this may be an acceptable risk, especially if the logon account being used does not have access to anything that wouldn’t be publicly accessible already. In environments where the risk is not acceptable, automatic logon probably should not be used at all. However, there is also always the possibility of inserting the appropriate username and password registry values, rebooting the computer and letting it automatically logon, and then finally removing the registry values that were previously inserted.

To use BatchPatch to insert the autologon registry entries in target systems, highlight the desired host(s) and select ‘Actions > Reboot > Configure autologon > Insert autologon registry values’
The ‘Auto Logon Credentials’ window appears. Input the username and password that you want to use to automatically logon the target system(s). In the ‘Domain’ field either enter the domain name where the user account resides, or if it’s a local computer account simply untick the ‘Domain’ checkbox, and you’ll see that it will be automatically filled in with $computer. Lastly, input a value for the ‘AutoLogonCount’ field.

Note: The ‘AutoLogonCount’ value controls how many times the machine can be auto-logged-on after reboot before Windows automatically purges the username and password from the registry to prevent further automatic logons. With each restart, Windows decrements the value by 1 until it reaches 0. Note, if you set the ‘AutoLogonCount’ to 1, it will actually take 2 restarts before the credentials are automatically removed by Windows. On the first restart, Windows will automatically logon with the specified credentials. On the second reboot, Windows will remove the saved credentials from the registry and not automatically logon again. For the sake of maximum security, if you set the AutoLogonCount to 1, then you should still plan to remove the entries yourself after reboot by selecting the ‘Remove autologon registry values’ menu item in BatchPatch, unless you are OK with the username and password being stored in the registry in plain text until the following reboot. If you want the system(s) to automatically logon indefinitely, and if you aren’t concerned about the username and password being stored in plain text in the registry, then you can simply choose a very high number for the ‘AutoLogonCount’ field.
Finally, to actually insert the necessary registry values, click OK.
Once the registry values have been successfully inserted you can go ahead and initiate the reboot. You’ll see that unless you entered invalid credentials, the computer will automatically logon after the reboot completes. As mentioned above, you might now choose to remove the previously inserted registry values so that the username and password are not left stored in plain text in the target computers’ registries. To do this, highlight the computers and select ‘Actions > Reboot > Configure autologon > Remove autologon registry values’

Posted in Blog, General, Tutorials | Tagged autologon, automatic logon | Comments closed