Uninstall Windows Updates Remotely

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.

  1. Identify the KB number of the update that you want to remove. For this example we will uninstall KB3078405
  2. In BatchPatch highlight all of the computers that need to have the update removed, and then select ‘Actions > Windows Updates > Uninstall individual update.’
    2016-02-04 15_04_13-
  3. In the form that appears, enter the KB number for the update you wish to remove. Optionally uncheck the “norestart” checkbox. In general I prefer to leave “norestart” checked. Then after the update has been removed BatchPatch will report if it requires a restart, and then I can use BatchPatch to initiate the restart and monitor the computers as they go offline and come back online. If “norestart” is unchecked, then the target computers will be able to reboot themselves at the end of the uninstallation, rather than BatchPatch initiating the reboot. Having BatchPatch initiate the reboot at the moment I give the command allows me to have a bit more control over the exact timing of the process, making it easier to monitor and confirm completion.
    2016-02-04 15_07_02-
  4. In this case the update uninstallation completed successfully, but the exit code indicates that a reboot IS required. And so now we can simply initiate a reboot within BatchPatch (‘Actions > Reboot > Reboot (force, if required)’).
    2016-02-04 15_24_09-
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

Remotely Deploy Google Chrome to Numerous Computers

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.

  1. When performing software deployments, I like to see if a .MSI installer package is available first. While there is nothing inherently wrong with using a .EXE for a deployment, the reason that .MSI packages are nice is because then we don’t have to go searching for the proper silent installation parameters to use with the .EXE. In the case of Chrome, Google does make available a .MSI installation package that we can easily use with BatchPatch for remotely installing Chrome on our network of computers. Start by downloading the .MSI from https://www.google.com/work/chrome/browser/
  2. Select the hosts that you wish to include in the deployment. Then select ‘Actions > Deploy software > Create/modify deployment.’ In the deployment window, browse to the .MSI file that you saved in the previous step, and then make sure the “install” radio button is selected.
    2016-01-27 14_19_43-Store
  3. To execute the deployment, simply click on the ‘Execute now’ button. Alternatively, if you want to save the deployment for executing later, you can click on the >> double-arrow button.
  4. Once the deployment execution has begun, you can sit back and wait until it completes. Generally this should only be a minute or two, depending on network conditions and how long it takes for BatchPatch to copy the .MSI file to the target computers. Note, you can modify the number of simultaneous file-copy operations allowed in BatchPatch under ‘Tools > Settings > Concurrent file-copy operations maximum.’ When the remote installation is complete, BatchPatch will display:

    Exit Code: 0 (SUCCESS)

    2016-01-27 14_27_57-new 1 - BatchPatch X1

Posted in Blog, General, Tutorials | Tagged , , , , | Comments closed

Using BatchPatch as a WSUS Alternative

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.

  1. First, follow the steps outlined on this page to configure your environment to work with BatchPatch: Getting Started with BatchPatch
  2. Next, decide where you want to retrieve updates from. Since you are not using WSUS, your options are to use either ‘Windows Update’ or ‘Microsoft Update.’ ‘Windows Update’ provides updates for just Windows operating systems, while ‘Microsoft Update’ provides updates for Windows operating systems PLUS updates for other Microsoft applications. You can easily switch between the two at any time, so there is no problem starting with ‘Windows Update’ and switching later. If you have decided to use ‘Microsoft Update’ then in BatchPatch you can configure target computers to use ‘Microsoft Update’ by first opting-in to the service on those computers. Highlight the computers in your BatchPatch grid, and then select ‘Actions > Windows Updates > Opt-in.’ After the computers are opted-in to the service, set BatchPatch to use it under ‘Tools > Settings > Server selection > Microsoft Update.’
    2016-01-14 20_27_27-
    2016-01-14 20_25_56-Program Manager
  3. At this point, you’re ready to start updating your computers without a WSUS. Highlight the desired computers in the BatchPatch grid, and then select ‘Actions > Windows Update > Download and install updates’ (or whichever action you prefer). The configuration described above is the easiest way to use BatchPatch. However, in this configuration each computer will download its own set of updates from Microsoft. Some administrators might want to prevent all the computers from reaching out to Microsoft, and instead they want to use BatchPatch to centrally download the updates on just one computer to then distribute to all of the target computers. We have a page dedicated to this type of usage, which you can see here: Cached Mode and Offline Updates
  4. IMPORTANT: If you want to prevent your Windows 10 computers from automatically installing updates you may use the Group Policy (or local policy) ‘Configure Automatic Updates‘ which is available under ‘Computer Configuration > Administrative Templates > Windows Components > Windows Update‘. Setting the value to either ‘2 – Notify for download and notify for install’ or ‘3 – Auto download and notify for install’ will prevent them from installing on their own so that you can instead trigger the install from BatchPatch.

Additional Tutorials for Using BatchPatch as a WSUS Alternative

Posted in Blog, General, Tutorials | Tagged | Comments closed

Uninstall Skype Remotely

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

  1. Obtain the .msi installer package from http://www.skype.com/go/getskype-msi.
  2. In BatchPatch select ‘Actions > Deploy > Create/modify deployment.’ Then choose the deployment options just like my screenshot below. Notice that I have selected the path to the .msi installer, and then I have checked the ‘uninstall’ radio button along with the ‘norestart’ option.
    2016-01-07 13_52_11-Deploy .msi .msp .msu .exe .reg .vbs .bat .cmd .ps1 etc
  3. Next, we can simply choose ‘Execute now’ to uninstall Skype from the hosts that are currently selected in the BatchPatch grid. Click OK to confirm the deployment.
    2016-01-07 14_09_01-new 1 - BatchPatch X3
  4. The remote uninstallation has completed. Exit Code: 0 (SUCCESS), indicates that we are done and the uninstallation was successful.
    2016-01-07 14_12_09-new 1 - BatchPatch X3
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Remotely Installing Skype on Many Computers

Installing Skype remotely isn’t much different than installing other applications remotely. Here’s how it goes:

  1. Obtain the Skype .msi installer from http://www.skype.com/go/getskype-msi. If you just go to skype.com and choose the “download” option, you will end up with the .exe version of the installer, not the .msi version. And while the .exe version does apparently support silent installation, since Microsoft also makes available a .msi version, I selected the .msi version for ease of operation. The reason for this is because with the .msi there is no need for me to find the proper silent installation switches that are available in the .exe version.
  2. Now that I’ve saved the .msi installer to my computer, I’m ready to configure the deployment. Select your target hosts in the BatchPatch grid, and then choose ‘Actions > Deploy > Create/modify deployment.’
  3. In the Deployment window that appears, select the location of the .msi file, and check the desired Windows Installer Options. In this case I’ve selected ‘install’ and ‘norestart’ to make sure that if a restart is required by the installer, it won’t happen automatically and catch me off guard. It turns out that the Skype installer generally should not require a restart, but it’s always a good safety precaution to use the ‘norestart’ switch just in case. If the installation completes and says that it needs a restart, I can always then initiate the restart using BatchPatch. In the screenshot below you can see that I’ve setup the deployment, and it’s ready to be executed. If you want to save the deployment configuration for future use, simply click the double-arrow >> button to add the deployment to the ‘Saved Deployments’ grid.
    2016-01-07 13_32_08-Deploy .msi .msp .msu .exe .reg .vbs .bat .cmd .ps1 etc
  4. The last step is to execute the deployment. You can do this directly from the Deployment window with the ‘Execute now’ button, or if you saved the deployment configuration, you could do this from the BatchPatch Actions menu. For the sake of this example, I’ll go ahead and execute it from the Actions menu since I did already save the configuration. I highlighted the target that I want to deploy to, and I selected ‘Actions > Deploy > Execute saved deployments > Skype Install.’
    2016-01-07 13_38_03-
  5. Click OK to confirm the deployment execution.
    2016-01-07 13_40_05-new 1 - BatchPatch X3
  6. That’s all there is to it. We can see the Exit Code: 0 (SUCCESS), which indicates that we are done!
    2016-01-07 13_42_39-new 1 - BatchPatch X3

If you need to uninstall Skype remotely, please follow the instructions at this link.

Posted in Blog, General, Tutorials | Tagged , , , , | Comments closed

Remotely Installing Adobe Air on Multiple Computers

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

  1. 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
  2.  

  3. 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.
  4.  

  5. 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.
    2015-12-28 17_31_12-C__Windows_system32_cmd.exe
  6.  

  7. 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.
    2015-12-28 17_36_14-Deploy .msi .msp .msu .exe .reg .vbs .bat .cmd .ps1 etc
  8.  

  9. 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.
    2015-12-28 17_40_13-new 1 - BatchPatch X5
     
    2015-12-28 17_43_49-Win10 (Snapshot 1) [Running] - Oracle VM VirtualBox
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Reattach Orphaned Remote Windows Update Processes

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.

2015-12-15 15_23_23-Program Manager

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.

2015-12-15 15_28_49-

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 | Comments closed

Notifying Logged-On Users of Impending Reboot or Shutdown

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:

2015-12-08 16_27_59-Remote Shutdown Dialog

In the most recent release of BatchPatch we have provided a similar dialog:

2015-12-08 16_30_56-Advanced reboot

Initiating a reboot (or shutdown) with user notification:

  1. 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.’
  2. 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).
    2015-12-08 16_45_14-Advanced reboot
  3. After clicking OK, the reboot command and notification are sent to the target computers. Logged-on users will see a notification like this:
    2015-12-08 17_33_52-cocolicense - Remote Desktop Connection
  4. 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 , | Comments closed

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

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

2015-12-01 16_53_52-new 1 - BatchPatch X100

2015-12-01 16_54_57-new 1.bps - BatchPatch

Posted in Blog, General, Tutorials | Tagged , | Comments closed

Remotely Remove a Problematic Windows Update from Multiple Computers

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):

  1. The process is actually very simple. Highlight the desired hosts in the grid and select ‘Actions > Windows Updates > Uninstall individual update’
    UninstallIndividualUpdateA
  2. In the dialog that is presented, enter the KB number of the update you want to uninstall. Then click OK.
    UninstallIndividualUpdateB
  3. 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):

  1. 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’
    UninstallIndividualUpdateRemoteCommandA
  2. 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
    UninstallIndividualUpdateRemoteCommandB
  3. At this point simply click ‘Execute’ to initiate the Windows Update removal process.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed