Removing Windows Updates Remotely from Windows 10 and 2016

In BatchPatch we have a menu item ‘Actions > Windows updates > Uninstall individual update’ that you can use to easily remove a single Windows update from numerous target computers, simultaneously. This command invokes wusa.exe on target computers to uninstall the desired update. We have a tutorial posted for this feature here. The only problem is that beginning with Windows 10 and 2016, this feature no longer works. You can still use it without issue to uninstall updates on older OSes such as Windows 7, Windows 2008, and Windows 2012, but for whatever reason Microsoft removed some of the functionality from wusa.exe on newer operating systems. You can’t use wusa.exe with the /quiet parameter to remove an individual Windows update from Windows 10 or Windows 2016. We agree, this is pretty darn annoying.

In the next release of BatchPatch we will have a new macro that allows you to remove an update from Windows 10 or 2016, but in the meantime if you need to remove an update from one of these newer operating systems, here is what you need to do:

  1. Select the desired hosts in the grid and choose ‘Actions > Execute remote process/command > Create/modify remote command 1’
  2. In the remote process/command window you’ll enter the following command. Replace KB4014329 with the KB ID of the update that you would like to remove.
    cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "$SearchUpdates = dism /online /get-packages | findstr 'Package_for'; $updates = $SearchUpdates.replace('Package Identity : ', '') | findstr 'KB4014329'; DISM.exe /Online /Remove-Package /PackageName:$updates /quiet /norestart"

  3. At this point you can either click ‘Apply command to row(s) without executing’ so that you can execute it later. Or you can just click ‘Execute’ which will apply the command to the row(s) and then execute it immediately. Additionally, if you need/want to save this command for future use you can also add it to ‘Actions > Execute remote/process command > Create/modify remote commands.’ Once added there it will appear in the BatchPatch actions menu for future use.

That’s really all there is to it. As mentioned above, we will be adding a macro for this command in the next version of BatchPatch, so that you can more easily execute it by simply providing the KB ID of the update that you want to remove. However, for the time being, this is your best bet for remotely removing an update from numerous computers. Of course there is always the option of going to each computer one by one to remove the update manually, but that’s a pain, especially when dealing with numerous computers.

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

Install Patches with Multiple Automated Reboots

Today I want to take a few minutes to go over one of the core automation options that BatchPatch provides for Windows Updates. Anyone who has ever been responsible for applying Windows Updates across a network of computers has encountered the rather annoying and often frustrating situation where installing updates and then rebooting target computers isn’t enough to complete the task at hand. There are times where installing updates and rebooting simply causes Windows Update to present new, yet to be installed, updates. When you’re dealing with a tight time schedule to get updates installed and computers rebooted and verified back online, this little “gotcha” can really induce a headache. If you are expecting that Microsoft will figure out a way to prevent this scenario from ever occurring in the first place, don’t hold your breath. You’re much better off just figuring out how best to deal with when it happens. That’s where BatchPatch’s automation feature come in handy.

One of the most common uses of BatchPatch is to create a one-click cycle or queue of actions to execute on numerous target computers simultaneously. In this particular case we’ll look at how you can instruct a set of computers to download and install Windows Updates and then reboot with an automatic “lather, rinse, repeat” mode, so that if any new updates are presented by Windows Update after the first reboot, you can make sure that they get installed and the computer is rebooted a second time. You can keep this cycle going as many times as you want, though generally speaking two cycles will cover you. However, including a third cycle won’t hurt anything. If there are no updates left to install, then obviously no updates will get installed.

Using the Job Queue for Update + Reboot Cycles

  1. Create the cycle / queue that you wish to execute on target computers. Select ‘Actions > Job Queue > Create / modify job queue’
  2. Next you’ll create the queue. For my purposes it is sufficient to use a queue like the one shown in the screenshot below. In your case you might want to have something that looks a bit different or repeats the process more than two times.

    Download and install updates + reboot always
    Wait for host to go offline and come back online
    Wait 3 minutes
    Download and install updates + reboot if required

  3. Next you can save the queue by giving it a title and clicking the >> double-arrow button. And now it’s ready to be used on your target computers.
  4. Select the desired hosts and then click ‘Actions > Job queue > Execute saved job queue’ and select the title you gave to the job queue that you created in the previous steps. That’s all there is to it.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Daisy Chaining Multiple Patch and Reboot Steps for Windows Update

BatchPatch provides the IT administrator with a significant amount of flexibility when it comes to stringing together multiple update and reboot steps for a single computer or for numerous remote computers. You are not only limited to Windows Updates. You can also include third party software deployments and/or third party software updates along with your own custom scripts or commands. Additionally, BatchPatch even lets you incorporate multi-step routines that involve a group of computers, so that you can execute one or more actions in any sequence, involving as many computers as you desire. This means, for example, that you can trigger an action to execute on one computer, and when it completes it can trigger an action to execute on 4 other computers simultaneously, and when those 4 other computers all complete they can trigger actions to run on other computers, and so on.

BatchPatch Job Queue

The primary feature that you need to look at if you’re interested in basic multi-step execution that involves either one target computer or multiple target computers executing a simple sequence of steps is the BatchPatch Job Queue. The Job Queue is a straightforward tool to use when you need each computer to run its own steps, with each computer running independently of any other computers. To learn how to use the BatchPatch Job Queue, see this tutorial.

BatchPatch Advanced Multi-Row Queue Sequence

If you are interested in more advanced sequencing that involves multiple computers being linked together in a larger automated sequence that combines actions to be executed in a way that one or more computers actions might be dependent on the actions of another computer or group of computers, then you need to look at the BatchPatch Advanced Multi-Row Queue Sequence. This tool is actually quite powerful with what you can do. The three most common uses we see with the Advanced Multi-Row Queue Sequence are:

1. Virtual machine updating: You can setup a single-click automated routine that will apply Windows Updates to your virtual guests, and then when all virtual guests are updated, the virtual host is triggered to update and reboot.

2. Maintenance start/stop scripts: You can setup a single-click automated routine that will start your ‘Begin Maintenance’ script, then update all computers, then execute your ‘End Maintenance’ script.

3. Ordering updates and reboots for environments where machines have interdependencies: For example if you have a group of computers that together comprise the back-end and front-end for a particular application, you might need to update and reboot these machines in a specific order, with only certain machines being allowed to be offline at any given time.

To learn how to use the BatchPatch Advanced Multi-Row Queue Sequence, see this tutorial.

Posted in Blog, General, Tutorials | Comments closed

BatchPatch Task Scheduler Recurrence Options

Most of you are probably well aware of the fact that Microsoft releases Windows Updates on the second Tuesday of each month. This recurring Tuesday has come to be known in the industry as ‘Patch Tuesday.’ One of the things that has always been annoying to many admins is the fact that while Patch Tuesday is always the second Tuesday of the month, the Wednesday that comes the day after Patch Tuesday is not necessarily always the second Wednesday of the month! For example, if the first day of a given month is a Wednesday, then the Wednesday that comes the day after Patch Tuesday will be the third Wednesday of the month, not the second.

Why does all this matter? Well, in terms of scheduling, it can be a bit tricky. Some companies choose to apply Windows Updates almost immediately after they are released on Patch Tuesday. For some this means that the Wednesday after Patch Tuesday is server maintenance day. For others it means that the Friday or Saturday after Patch Tuesday is server maintenance day. If you are scheduling any portion of your update process to run automatically, you need a good way to define the maintenance window. If you choose to have a recurring schedule that runs on the second Wednesday of every month, you’re going to miss your target in the months where the second Wednesday is not the day that comes after the second Tuesday.

In the most recent release of BatchPatch we added a new recurrence option to the Task Scheduler. So now if you want to schedule your tasks to run on the day after Patch Tuesday, you can do it more easily. For any recurring task you can now define a run time to come X days after a reference time. In the screenshot below you can see that I’ve set recurrence to be ‘Monthly (2nd Tuesday) + 1 days’ which means that no matter how the days fall, my schedule will always run on the day after Patch Tuesday.

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

Synchronize a BatchPatch Grid with Active Directory OUs and Groups

In the new version of BatchPatch that was published yesterday we added a new feature that people have been asking about for a while. You can now “link” a grid to any number of organizational units (OUs) or security groups in Active Directory, enabling you to synchronize the list of computers in the BatchPatch grid with the list of computers in the Active Directory OUs and / or groups.

Here’s how it works:

  1. Select ‘File > Synchronize grid with directory…’

  2. In the window that appears you enter the LDAP path to an OU or security group.

  3. After you enter the desired LDAP path, click ‘Verify path and add to list.’ BatchPatch will attempt to connect to Active Directory and list the computers in the specified OU or security group.

  4. The computers contained in the specified OU or group will be listed so that you can confirm you want to include this LDAP path in your configuration. Click OK to include this LDAP path. The path will be added to this grid’s configuration.

  5. Continue adding as many LDAP paths as you want to be included. For the sake of this example, I have added two LDAP paths. In my test domain here I have all of my computers in the OUs called ‘ComputersOU’ and ‘Domain Controllers.’

  6. The LDAP paths that have been added to the configuration will now be used for synchronization. Click ‘Synchronize BatchPatch grid now’ to have BatchPatch compare the list of computers in the OUs and groups that you specified with the list of computers in your BatchPatch grid. Any computers that exist in the OUs/groups that do no currently exist in the grid will be displayed. You then have the option to either add all of them to the grid, or you may optionally remove any from the list before adding to the grid. In my case, I don’t have any computers in my BatchPatch grid, so the synchronization results show me all 4 of my computers. I click OK to add them to the grid.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Advanced Multi-Row Queue Sequence – Video Tutorial

This video tutorial demonstrates how to use the Advanced Multi Row Queue Sequence in BatchPatch.

For written tutorials, please see the following links:

Advanced Multi-Row Queue Sequence – Written Tutorial 1
Advanced Multi-Row Queue Sequence – Written Tutorial 2

Advanced Multi-Row Queue Sequence – Video Tutorial:

 

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

Virtual Machine – Create Snapshot, Apply Windows Updates, Reboot, Remove Snapshot (Basic Multi-Row Queue Sequence Example)

Recently we were asked if BatchPatch can be used to automate a process to snapshot a virtual machine, apply Windows Updates to the virtual machine, reboot it, verify the VM is back online after reboot, and then finally remove the snapshot. Something like this is actually very doable with BatchPatch. The key thing to keep in mind here is that we will execute the commands to create and remove the snapshot on the virtual machine host computer, but we will be executing the download/install/reboot process on the actual guest virtual machine. Below I will show you how we are able to link this all together into a single one-click process using the BatchPatch feature called ‘Basic Multi-Row Queue Sequence‘.

  1. Let’s start by adding the commands for both creating and removing Hyper-V virtual machine snapshots. Select ‘Actions > Execute remote process/command > Create/modify remote commands (logged output)’
  2. We are going to use the following two PowerShell commands for creating and removing the snapshot:
    checkpoint-vm -Name VMGUEST -Snapshotname MyCheckpointTest
    get-vm VMGUEST | remove-vmsnapshot -Name 'MyCheckpointTest'

    However, to execute these PowerShell command in BatchPatch we have to modify them slightly, as follows:

    cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "checkpoint-vm -Name VMGUEST -Snapshotname MyCheckpointTest"
    cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "get-vm VMGUEST | remove-vmsnapshot -Name 'MyCheckpointTest'"

    In the ‘Remote Process’ User-Defined Commands (logged output) window we add those commands. See screenshot for example. Note, the title can be whatever you want it to be, but make sure the command is formatted as shown above. However, of course you will substitute your own VM names and snapshot names. In this example my virtual machine is called VMGUEST. The snapshot will be titled MyCheckpointTest.

  3. Now that we have created the VM snapshot creation and removal commands in BatchPatch, we can go ahead and setup the queue. Let me first outline the process clearly so that you can see exactly the steps that we are going to take to make this happen. We are going to setup a basic multi-row queue sequence, which enables us to tie together multiple hosts into a single sequence. For the sake of this example our VM host will be called VMHOST. Our VM guest will be called VMGUEST. Our snapshot will be called MyCheckpointTest.
    Step 1: Execute the command to create the VM snapshot.  This command will be executed remotely on VMHOST.
    Step 2: Execute the command to download and install updates + reboot the VM guest machine.  This command will be executed remotely on VMGUEST.
    Step 3: Wait a few minutes
    Step 4: Verify that VMGUEST is online
    Step 5: Execute the command to remove the VM snapshot.  This command will be executed remotely on VMHOST.
  4. To start, I have added our VMHOST and VMGUEST computers to the BatchPatch grid. Note that I have added the VMHOST computer two times, and the order of the hosts is:
    VMHOST
    VMGUEST
    VMHOST
    

    The reason for this is because our first command will be executed on the VMHOST, our second command (or set of commands) will be executed on the VMGUEST, and our third command will be executed on the VMHOST. When using the Basic Multi-Row Queue Sequence, the order of the hosts matters. When we actually execute the sequence, it will be executed in the order that we select/highlight the hosts in the grid. So for ease of operation we put the hosts in order so that we can easily select them in order. However, if the hosts were not in the grid in the correct order, we could still execute the Basic Multi-Row Queue Sequence in the correct/desired order by first selecting them in the desired order. However, putting them in the grid in the desired order just makes it a bit simpler. Also note, you could alternatively use the Advanced Multi-Row Queue Sequence to handle this task, and in that case the ordering would matter less.

  5. Next we need to apply a Job Queue to each row in the grid. Select the first host VMHOST and click ‘Actions > Job queue > Create/modify job queue’ In the job queue window use the ‘Saved User-Defined Commands and Deployments’ grid in the lower-left to select the command we input earlier to create the VM checkpoint.

    Then click ‘Apply queue to row(s) without executing.’ What we have done here is the first entry for VMHOST now has a job queue configured with just a single command, and this command will be responsible for creating the VM snapshot of our VMGUEST. Your BatchPatch window should look like this:

  6. Next select VMGUEST in the BatchPatch grid, and then click ‘Actions > Job queue > Create/modify job queue’ For this VMGUEST we need 3 steps as shown in the screenshot below.
    Download and install updates + reboot always
    Wait 3 minutes
    Wait for host to be detected online
    

    Once again click ‘Apply queue to row(s) without executing.’ Your BatchPatch grid should now look like this:

  7. Next select the third row in the BatchPatch grid (this is the second entry for VMHOST). Then click ‘Actions > Job queue > Create/modify job queue’ For this host our job queue will again contain just a single step to execute the command to remove the snapshot that we created earlier. Then click ‘Apply queue to row(s) without executing.’
  8. At this point the BatchPatch grid is ready for final execution of the entire process. Your grid should look like mine does in the screenshot below:
  9. We’re finally read to begin execution. Select/highlight the hosts in the grid in the order that the queue is to be executed. Since we deliberately created this grid to execute in sequential order from top to bottom, make sure to select the hosts from top to bottom. Once selected, choose ‘Actions > Job queue > Execute basic multi-row queue sequence’ When you do this what will happen is as follows:
    Step 1: Execute the command to create the VM snapshot.  This command will be executed remotely on VMHOST.
    Step 2: Execute the command to download and install updates + reboot the VM guest machine.  This command will be executed remotely on VMGUEST.
    Step 3: Wait a few minutes
    Step 4: Verify that VMGUEST is online.
    Step 5: Execute the command to remove the VM snapshot.  This command will be executed remotely on VMHOST.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Perform Update and Reboot Actions Sequentially Across Numerous Hosts

One of the more powerful features that BatchPatch offers is the ability to automate basic or advanced sequences of actions across multiple target computers. For example, if you have a group of computers that have certain online/offline dependencies, such that they cannot all be rebooted at the same time, or maybe they have to be rebooted in a certain order, you could setup an automation sequence in BatchPatch to handle this process with just a single click. Or let’s say that you want download and install Windows Updates and reboot a total of 10 different target computers. However, the 10 different computers are configured in such a way where you only want to have one of those 10 computers be offline at any given time. Again, you could create an automation sequence in BatchPatch to handle this entire situation with a single click. Or what if you have many Hyper-V hosts, each containing numerous virtual machines guests. You are looking for a way to easily apply updates to all of the virtual guests, and then only after the guests are updated on a given host, you then want to apply updates to the virtual machine host and reboot it along with all the virtual machine guests. You don’t want to have to launch the process manually on every guest and host involved. Instead you want to create a way to automate the process with BatchPatch so that it can be boiled down to a single click action. You can do all this, and more, with the multi-row sequencing features in BatchPatch.

Basic Multi-Row Queue Sequence

The Basic Multi-Row Queue Sequence allows you to string together a sequence across multiple target computers such that each target computer executes a custom job queue one a time. The key with the Basic Multi-Row Queue Sequence is that only one host will process its actions at a given time.

Example:
Host1 is configured to download and install updates plus reboot.
Host2 is configured to deploy Firefox.
Host3 is configured to run a custom script.

If these three hosts are configured in a Basic Multi-Row Queue Sequence, then Host1 will perform its actions. Only when all actions for Host1 are completed will Host2 begin processing its actions. And only when Host2’s actions are completed will Host3 begin processing its actions.

For a detailed tutorial on using the ‘Basic Multi-Row Queue Sequence’ please follow this link: Using the Basic Multi-Row Queue Sequence

Advanced Multi-Row Queue Sequence

The Advanced Multi-Row Queue Sequence differs from the Basic Multi-Row Queue Sequence primarily in that it allows a sequence to process multiple hosts’ queues simultaneously, while still allowing those hosts to participate in a larger sequence with other hosts.

Example:
Host1 is configured to download and install updates plus reboot.
Host2 is configured to deploy Firefox.
Host3 is configured to run a custom script.
Host4 is configured to download and install updates plus reboot.
Host5 is configured to download and install updates plus reboot.
Host6 is configured to import a registry key.

With the Advanced Multi-Row Queue Sequence you can customize it completely. You could set it so that Host1 and Host2 perform their actions. Then when both Host1 and Host2 are complete, only then will Host3 and Host4 perform their actions. And only when they are both complete will Host5 and Host6 perform their actions. ALTERNATIVELY… since the Advanced Multi-Row Queue Sequence options are not limited you could instead configure it to execute Host1 at the same time as Host2, Host3, and Host4. Then when all four of the hosts are completed, only then would Host5 and Host6 begin execution. There is no limitation to the number of hosts that can participate in a sequence, and there is no limit to the number of hosts that can be active for any given step in the sequence. It is completely customizable and amazingly powerful.

For a detailed tutorial on using the ‘Advanced Multi-Row Queue Sequence’ please follow this link: Using the Advanced Multi-Row Queue Sequence

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

Deploying a Script with Relative Instead of Absolute Paths

In order for a custom deployment to be successful, you might not be able to use absolute paths inside of a script where those paths point to a location on a remote server. This is dependent upon the particular situation, but if you’re having problems successfully deploying a script that makes calls to other scripts or executables stored on a remote server, below I will show you how to ensure success.

Example:

Imagine you have a remote server folder:

\\RemoteServer\SharedFolder\Example

The folder contains two files – MyCustomExecutable.exe and MyCustomScript.cmd:

The contents of the script are as follows. Note, the script makes a call to execute the MyCustomExecutable.exe using an absolute path to the server location where the exe file currently resides:

@ECHO OFF
ECHO *** Executing My Custom Script With Remote Server Absolute Paths ***
"\\RemoteServer\SharedFolder\Example\MyCustomExecutable.exe"

You are attempting to deploy the script using the configuration in the screenshot below, but you are not having success:

If you are having problems getting the deployment to run successfully, you have a couple of options to try:

  1. You might be able to get the deployment to execute successfully simply by modifying the ‘Remote Execution Context’ settings. In the screenshot below you can see that I have launched the ‘Remote Execution Context’ settings window directly from the deployment configuration screen. However, you can also get to the ‘Remote Execution Context’ settings by clicking ‘Tools > Settings > Remote Execution.’

    The default configuration is set to use the SYSTEM account for remote execution. This is usually the best for most situations, but one drawback to this setup is that the SYSTEM account does not have access to network resources. Since the script that gets executed on the target system is currently set to make a call to a remote server location (“\\RemoteServer\SharedFolder\Example\MyCustomExecutable.exe”), the deployment will fail because the SYSTEM account on the target computer will not be able to reach that network resource. Try running your deployment with ‘Elevated token’ or ‘Normal’ and see if you have success. If not, set the Remote Execution Context setting back to ‘SYSTEM’ and go to the next step.
  2. With a simple adjustment to your script and your BP deployment configuration you can remove any network calls so that the entire deployment executes locally on the target system.

    A. Modify your script to remove the absolute path. See below for example:

    @ECHO OFF
    ECHO *** Executing My Custom Script WITHOUT Remote Server Absolute Paths ***
    "MyCustomExecutable.exe"

    B. Modify your deployment configuration by ticking the box that says “Copy entire directory contents in addition to the specified file”

    C. Now when you execute the deployment, the entire folder contents of (\\RemoteServer\SharedFolder\Example) will be copied to the target systems. Then when the script is executed, since it now contains a relative path to the MyCustomExecutable.exe, it will find that file in the same temp deployment directory as the script is being executed from. The deployment will complete successfully (unless, of course, the reason for it failing in the first place was due to some other unrelated issue).

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

Remotely Install Greenshot 1.2.9.104 on Many Computers Simultaneously

Today let’s have a look at deploying Greenshot screen capture software to numerous computers simultaneously. The process is no different from other remote installations with BatchPatch. We will start by determining the appropriate installation parameters to use in order to trigger a “silent” or “quiet” installation on target computers. Next we will create the actual deployment in BatchPatch. Lastly we will execute the deployment.

  1. Download the version of Greenshot that you intend to install. In this case we are installing the latest version 1.2.9.104, downloaded from http://getgreenshot.org/downloads/
  2. As is the case with any remote software installation, the installation must be triggered to run without any user interaction required on the target computer. The reason for this is because if the installation package pops up a window on the target system, asking the user to select configuration options such as installation directory, that popup window will be hidden from the administrator on the BatchPatch computer, and the deployment will consequently hang indefinitely without ever completing. So, before we deploy Greenshot we have to determine the appropriate switch to use in our deployment configuration to make sure that the installation occurs without any user interaction. This is known as a “silent” or “quiet” installation.

    To determine the correct silent parameter, we execute the installer package at the cmd prompt with the /? switch. See screenshot below for illustration.
  3. Running the command above causes the installation package to pop up the messagebox shown in the screenshot below. We are going to use the /VERSILENT and /NORESTART parameters for our deployment.
  4. To create the deployment in BatchPatch, select the target hosts that will receive the deployment, and then select ‘Actions > Deploy > Create modify deployment’
  5. In the Deployment form, click the browse button to browse to the Greenshot-INSTALLER-1.2.9.104-RELEASE.exe that you downloaded earlier. Then type /VERYSILENT /NORESTART into the ‘Parameters’ field, just as I have done in the screenshot below. Optionally give your deployment a title and save it using the >> button.
  6. At this point you can either execute the deployment now or close the window and execute it later. I’m going to simply click the ‘Execute now’ button.
  7. Exit code 0 indicates success. Greenshot is now installed on the target system(s).

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