As you have probably already seen in the tech news this week, all Intel CPUs have a newly discovered flaw being called ‘Meltdown‘. More information is available here.

Currently the only way to address this hardware flaw is by applying an update to the operating system. If you will be using BatchPatch to distribute the update to your computers then you have a couple of different options for making this happen.

The update has been released under the following KB IDs, which vary depending on the version of operating system that is installed on your computer. You should definitely read the KB release notes (links below) because there are important compatibility issues, particularly with anti-virus applications, to be aware of before installing the update, which are outlined on the pages linked below.

KB4056892 (applies to Windows 10 version 1709)
KB4056891 (applies to Windows 10 Version 1703)
KB4056890 (applies to Windows 10 Version 1607, Windows Server 2016)
KB4056888 (applies to Windows 10 Version 1511)
KB4056893 (applies to Windows 10 Enterprise released in July 2015)

Applying the Update to Systems that Have Access to the Internet or a WSUS

For systems that have access to the internet or a WSUS, applying the update with BatchPatch should be very straightforward. You’ll simply need to execute your normal Windows Update routine so that computers download and install the appropriate update. For most users this means you’ll execute ‘Actions > Windows updates > Download and install updates + reboot if required‘ or similar.

In the case with my lab Windows 10 Version 1607 computer, when I ran BatchPatch ‘check for available updates’ this is the result I got:

To update this computer I will simply execute ‘Download and install updates + reboot if required‘ and that should be all I need to do.

Applying the Update to Systems that Do Not Have Access to the Internet or a WSUS

Using Offline Mode to Deploy the Updates:

If you are applying this out-of-band patch to systems that do not have internet access or access to a WSUS, one option is to wait until Microsoft publishes the next WsusScn2.cab file, which they do on a monthly basis. The next release of this file *should* have the relevant updates included, which means that you will be able to follow your normal routine of applying Windows updates using ‘offline mode‘ in BatchPatch.

EDIT 20180108: Microsoft released a new WsusScn2.cab file on Jan 4, 2018 that contains the relevant updates.

Using the BatchPatch ‘Deployment’ Functionality to Deploy the Updates:

You will need to first manually download the required update from the Microsoft catalog. Links to each update (each OS version has its own update) are provided on the pages linked above for each KB ID. Once you have downloaded the relevant update for each operating system in your environment, and once you have read through the KB articles to make sure that your systems are ready to receive the update, then you may go ahead and deploy the .MSU file using BatchPatch’s standard ‘Deploy’ method for .MSU files, which is outlined here: Remotely Deploy a Standalone .MSU Update to Multiple Computers

If all applications could be removed/uninstalled with the same exact command, then it would never be a challenge, but unfortunately that’s not the case. Different applications will inevitably require different methods or commands for uninstallation. In most cases there is a lot of similarity from application to application, which makes it pretty simply to determine the proper method. However, it’s certainly always possible that an application’s silent/quiet removal needs to be performed with an out-of-the-ordinary method. In those cases it’s usually best to reach out to the vendor or search Google for proper uninstallation/removal steps.

Determining the Silent / Quiet / Unattended Software Removal Parameter

The most important part when it comes to remotely installing and removing software is understanding that software that is installed or uninstalled remotely must not require any user input during the operation. Under normal circumstances when you try to add or remove an application from Windows, you click on something (an executable or a link in the add/remove programs wizard) that initiates the process. But the first thing that happens after initiating the task is that you are prompted with a confirmation dialog of some kind. The problem is that if your attempt to remotely install or remove the application requires any user intervention, such as clicking OK to confirm removal, then the process will never complete because you will not be able to remotely click OK to a hidden dialog on a target computer. Your process will instead just appear to hang indefinitely. Before attempting any remote software install/uninstall you should read this posting: Understanding and Discovering the Silent Parameters Required to Remotely Deploy Software with BatchPatch

Removing FeedReader 3.14

Last week a user asked how to use BatchPatch to remotely remove FeedReader 3.14 from numerous target computers. He tried using BatchPatch’s ‘Execute remote process/command‘ feature to run each of the following commands on target computers:

"C:\Program Files (x86)\FeedReader30\unins000.exe"

AND

"C:\Program Files (x86)\FeedReader30\unins000.exe" /S

However, neither command was able to perform the remote software removal. Not surprisingly, if a command is not successful at the command line of the target computer *without* using BatchPatch, it will certainly never be successful when executing through BatchPatch. In order to determine the proper command for uninstallation, we noted to this user that he would need to first test at the cmd prompt of the target computer. In our lab we ran the following commands until until stumbling upon the one that would perform the software removal *without* requiring any additional user input.

"C:\Program Files (x86)\FeedReader30\unins000.exe"
"C:\Program Files (x86)\FeedReader30\unins000.exe" /S
"C:\Program Files (x86)\FeedReader30\unins000.exe" /s
"C:\Program Files (x86)\FeedReader30\unins000.exe" /Q
"C:\Program Files (x86)\FeedReader30\unins000.exe" /q
"C:\Program Files (x86)\FeedReader30\unins000.exe" /quiet
"C:\Program Files (x86)\FeedReader30\unins000.exe" /silent

It turned out in the end that the correct command for FeedReader 3.14 is:

"C:\Program Files (x86)\FeedReader30\unins000.exe" /silent

That command immediately uninstalls the application with no additional user input required, whereas all of the other commands popup a dialog (see screenshot below) asking for the user to click OK to proceed with the uninstallation.

Once the proper command is determined, only then should it be inserted it into the ‘Remote process/command‘ dialog in BatchPatch. At that point remote execution of the software removal on numerous target systems is quick and simple!

One of the questions we get sometimes is how best to get data out of a BatchPatch grid, usually to present to someone who is not a BatchPatch user. For the most part when IT admins are using BatchPatch there is little need to present information to anyone else. The goal is typically to just get machines patched and rebooted, and then make sure they are back online and functional before maintenance is over. However, for many users there is sometimes a need to present certain information either to management or perhaps to a different team. For example, maybe your manager wants to know the status of your maintenance, including which updates have been deployed to which computers, or which updates are currently available and ready to install on which computers, etc. Today I’m going to show you the best ways to accomplish these objectives.

Copy and Paste

This is not the most elegant option available, but it can still be the best option in certain situations, depending on your needs. If you want to get some data out of a BatchPatch grid, one option that’s always available is to first show/hide the desired columns (you can show/hide columns by right-clicking on any column header or by selecting ‘Tools > Customize columns‘), then use CTRL-A to select the entire grid, or simply highlight the desired rows, then use CTRL-C to copy the contents to the clipboard. Next you can use CTRL-V to paste the contents of the clipboard into your favorite spreadsheet application. From there you can format as desired. Note, if you select all rows in the grid, then when you paste the contents to another application, the header row showing column titles will be included. If you only select some rows in the grid, the header row will not be included.

HTML Grid Export

This is my favorite method for most situations. You can present the grid data in HTML format for anyone to be able to view in a way that is very similar to how the data is presented in the BatchPatch grid. Simply select ‘File > Export grid‘ and then select one of the HTML export options. If you have more than one grid open in BatchPatch you can choose to have each grid go to a separate HTML file or you can have all grids be included in the same HTML file. The grid view that is displayed in the HTML report is clickable. If you click any cell in the HTML grid, it will jump to the spot in that file where that data is expanded, so that you can easily view the complete data. You can then jump right back to the grid view, as needed.

Delimited Grid Export

Another option is to export the grid to a delimited file. This is a versatile option because the resultant delimited file can be imported into a spreadsheet or database application. To perform this kind of export, choose ‘File > Export grid > Export current grid to delimited file‘. Note, the default delimiter that BatchPatch uses is the ‘?’ character. However, you can choose any delimiter that you want, including a multi-character delimiter. One thing to be careful of is to not use a delimiter that will break your output. For example, we do not recommend using a comma ‘,’. Comma is a common delimiter in many applications, but for BatchPatch it will often produce undesirable results because a BatchPatch grid may very well contain commas in its data fields. In particular, many Windows Update titles contain commas. If there is a Windows Update title in your ‘Remote Agent Log’ column, for example, then choosing comma as a delimiter is going to be problematic.

Built-in Reports

If you specifically need to produce a report of available updates or of previously installed updates for a group of computers you might want to use one of the built-in options for these particular reports. Check ‘Actions > Windows updates > Generate consolidated report of available updates‘ and ‘Actions > Windows updates > Generate consolidated report of update history‘. Once these reports have been created in BatchPatch they can both be exported to delimited files, at which point they can be imported into your favorite spreadsheet or database application.

Today we’re going to look at another example of how you can integrate a custom script into BatchPatch to create an effect that you could not accomplish with the built-in actions alone.

The Goal

Using a combination of the Job Queue, a Deployment, and a custom script, instruct the target computer(s) to only install Windows Updates after successfully stopping a running service. If the target computer fails to stop the service, don’t install the Windows Updates.

Summary:

Use the BatchPatch Job Queue to execute the following steps:

1. Deploy a script to target computers that returns 0 if the specified service stops successfully.
2. Use the Job Queue feature ‘Terminate queue if previous action fails/errors’
3. Execute ‘Download and install updates + reboot if required’ (or any desired action)

How to do it:

1. I’ve created a very simple vb script that stops a specified service. If the script is successful it returns 0, otherwise it returns a non-0 value. The contents of my script are below:

   'Stops the specified service and returns 0 if successful else returns non-0 'Cocobolo Software LLC February 2018. 'Usage: cscript.exe "C:\Your Script Repository\StopService.vbs" "Your service display name goes here" 'The first argument from the command line is assigned to strServiceDisplayName strServiceDisplayName = WScript.Arguments(0)   on error resume next Err.Clear   Set objWMIService = GetObject("winmgmts:\\localhost\root\cimv2")   Set colServices = objWMIService.ExecQuery("Select * from Win32_Service where DisplayName='" & strServiceDisplayName & "'") For Each objService in colServices ReturnValue = objService.StopService() wscript.quit(ReturnValue) Next

2. Save the script. The contents of the script above need to be saved in a text file with a .vbs file extension. For the sake of this example my script is called “StopService.vbs”
3. Create a deployment. The deployment will be used to copy the vbscript to the target computers, execute it, and retrieve the exit code. To create your deployment select ‘Actions > Deploy > Create / modify.’
4. Browse to the location of your StopService.vbs file, and then give the deployment a title. Click the ‘>>’ button to save the deployment. The screenshot below shows the configured deployment. Note, the DisplayName of the desired service to be stopped is in the ‘Parameters’ field in quotes.
   
5. With your deployment created and saved you can now setup your Job Queue. Go to ‘Actions > Job Queue > Create / modify.
6. Select the desired steps of the queue. The first step executes the deployment that we created earlier. The second step tells BatchPatch to halt the queue if the previous action fails/errors (a script is considered failed/errored if it returns any non-zero value). The third and final step of the script is to execute whatever action is desired such as ‘Download and install updates.’ The screenshot below shows what your queue should look like:
   
7. All we have to do now is execute the queue. Click ‘Execute now’ (or alternatively save the queue first and then execute it directly from the BatchPatch Job Queue menu). When the queue executes, the target computer will first attempt to stop the ‘DNS Client’ service. If successful, it will then install Windows Updates. If unsuccessful then the queue will terminate without installing updates. By the way, there is no good reason that you would ever want or need to stop the ‘DNS Client’ service before installing updates. I only used this particular service in this example. You will, of course, specify the service that you desire to stop.

Notes:

What if you want to start a service instead of stop a service? In your vb script you can use

ReturnValue = objService.StartService()

instead of

ReturnValue = objService.StopService()

What if you want to change the start mode of the service from Automatic to Manual?

ReturnValue = objService.ChangeStartMode("manual")

instead of

ReturnValue = objService.StopService()

Today the goal is to tie together some concepts that I’ve written about in the past in order to demonstrate how you can use the Advanced Multi-Row Queue Sequence to execute certain actions on some hosts with a contingency that something must be true on another host before the additional hosts begin operations.

The Plan

Here is the overall picture of what we’re going to do:

Host1:
1. Check if there is enough disk space. If the available disk space is less than a desired threshold, then stop executing the multi-row queue sequence. If there is enough disk space available, then go on to the next step.

2. Stop a specific service. If this action fails, stop executing the multi-row queue sequence. If it completes, then move on to the next step.

3. Set the service to manual. If this action fails, stop executing the multi-row queue sequence. If it completes, then move on to the next step.

4. Install Windows Updates and reboot.

5. Start the stopped service. If this action fails, stop executing the multi-row queue sequence. If it completes, then move on to the next step.

6. Set the service back to automatic. If this action fails, stop executing the multi-row queue sequence. If it completes, then move on to the next step.

7. Only after all previous actions are complete should the next two hosts begin their operations.

Host2:
1. Check if there is enough disk space. If the available disk space is less than a desired threshold, terminate the queue for this host only, but still proceed with the rest of the multi-row queue sequence for Host3.

2. Deploy Firefox

Host3:
1. Run a custom script

Scripts

In all cases with these scripts we return 0 for success and a non-zero integer (1) for failure. This enables us to use the job queue special items for ‘Terminate queue if previous actions fails/errors’ and ‘Abort advanced multi-row sequence if previous action fails/errors’. If the script returns 1, then those special items will consider it failed and will abort/terminate. If the script returns 0, those items will consider it successful and move on to the next step in the queue.

GetCDriveSpace.vbs

'Gets the free space on C drive.  If free space is less than specified threshold return 1. Else return 0.  
'Cocobolo Software LLC April 2017.
 
on error resume next
Err.Clear
 
Dim freeMB
Const MBCONVERSION = 1048576
 
Set objWMIService = GetObject("winmgmts:\\localhost\root\cimv2")
 
'Get C drive space
Set colLogicalDisk = objWMIService.ExecQuery("Select * from Win32_LogicalDisk")
		For Each objLogicalDisk in colLogicalDisk
			If objLogicalDisk.DeviceId = "C:" Then					
				freeMB = objLogicalDisk.freespace/MBCONVERSION
			End If
		Next
 
If freeMB < 500 Then
	wscript.quit(1)
Else
	wscript.quit(0)
End If

StopService.vbs

'Stops the specified service and returns 0 if successful else returns non-0
'Cocobolo Software LLC February 2018.

'Usage: cscript.exe "C:\Your Script Repository\StopService.vbs" "Your service display name goes here"

'The first argument from the command line is assigned to strServiceDisplayName
strServiceDisplayName = WScript.Arguments(0)
 
on error resume next
Err.Clear
 
Set objWMIService = GetObject("winmgmts:\\localhost\root\cimv2")
 
Set colServices = objWMIService.ExecQuery("Select * from Win32_Service where DisplayName='" & strServiceDisplayName & "'")
	For Each objService in colServices
		ReturnValue = objService.StopService()
			wscript.quit(ReturnValue)			
	Next

StartService.vbs

'Starts the specified service and returns 0 if successful else returns non-0
'Cocobolo Software LLC February 2018.

'Usage: cscript.exe "C:\Your Script Repository\StartService.vbs" "Your service display name goes here"

'The first argument from the command line is assigned to strServiceDisplayName
strServiceDisplayName = WScript.Arguments(0)
 
on error resume next
Err.Clear
 
Set objWMIService = GetObject("winmgmts:\\localhost\root\cimv2")
 
Set colServices = objWMIService.ExecQuery("Select * from Win32_Service where DisplayName='" & strServiceDisplayName & "'")
	For Each objService in colServices
		ReturnValue = objService.StartService()
			wscript.quit(ReturnValue)			
	Next

SetServiceToManual.vbs

'Sets the specified service to manual and returns 0 if successful else returns non-0
'Cocobolo Software LLC February 2018.

'Usage: cscript.exe "C:\Your Script Repository\SetServiceToManual.vbs" "Your service display name goes here"

'The first argument from the command line is assigned to strServiceDisplayName
strServiceDisplayName = WScript.Arguments(0)
 
on error resume next
Err.Clear
 
Set objWMIService = GetObject("winmgmts:\\localhost\root\cimv2")
 
Set colServices = objWMIService.ExecQuery("Select * from Win32_Service where DisplayName='" & strServiceDisplayName & "'")
	For Each objService in colServices
		ReturnValue = objService.ChangeStartMode("manual")
			wscript.quit(ReturnValue)			
	Next

SetServiceToAutomatic.vbs

'Sets the specified service to automatic and returns 0 if successful else returns non-0
'Cocobolo Software LLC February 2018.

'Usage: cscript.exe "C:\Your Script Repository\SetServiceToAutomatic.vbs" "Your service display name goes here"

'The first argument from the command line is assigned to strServiceDisplayName
strServiceDisplayName = WScript.Arguments(0)
 
on error resume next
Err.Clear
 
Set objWMIService = GetObject("winmgmts:\\localhost\root\cimv2")
 
Set colServices = objWMIService.ExecQuery("Select * from Win32_Service where DisplayName='" & strServiceDisplayName & "'")
	For Each objService in colServices
		ReturnValue = objService.ChangeStartMode("automatic")
			wscript.quit(ReturnValue)			
	Next

Create Custom Script Deployments

For each script file we need to create a deployment in BatchPatch. I have all of my scripts in a single folder on my BatchPatch computer.

Select ‘Actions > Deploy > Create/modify’, and then for each script create a deployment that looks like the following screenshots, and save those deployments using the double-right-arrow button. Note, the DiskCheck.vbs deployment has no parameters, but each of the other deployments has the desired service name as its only parameter:

Create Job Queue For Each Host

Before we create the Advanced Multi-Row Queue Sequence we have to create a job queue for each host. The job queue will be the step by step list of operations that we want each host to execute inside of the advanced multi-row queue sequence.

Select ‘Actions > Job Queue > Create / modify’ and then create the following job queues for each host. You can ‘apply queue’ to each host/row accordingly:

Host1

Host2

Host3

Note, for the places where we want to abort the entire multi-row queue sequence if the previous action fails/errors, we always add that special item right before the ‘terminate queue if previous action fails/errors’ because if we terminated the queue first, then the queu would not be running and could therefore not execute the command to abort the entire multi row queue sequence. However, in the case of Host2, we want to *only* terminate the queue if the previous action fails/errors, but we do not want to abort the entire multi-row queue sequence.

Assembling the Advanced Multi-Row Queue Sequence

Finally we will create our sequence. I’ve gone ahead and added a new row to the grid called ‘SequenceExecutionRow’ which is essentially a dummy row that is used just for the multi-row queue sequence.

1. With that special row selected, choose ‘Actions > Job Queue > Create / modify advanced multi-row queue sequence’
2. In the window that appears enter a Sequence Name and select the radio button for ‘Create Sequence Execution Row’, and apply it to the SequenceExecutionRow
   
3. Next highlight Host1 and choose the radio button ‘Set Sequence Position Number’ with a value of 1.
   
4. Do the same with Host2 and Host3.
   
5. Finally we are ready to execute the sequence. Highlight the SequenceExecutionRow and select ‘Actions > Job Queue > Execute advanced multi-row queue sequence.
   

The ‘feature upgrades’ to Windows 10 (1607, 1703, 1709 etc) cannot be installed with the normal Windows Update actions in BatchPatch. Instead we have to use an alternate method to get these updates on to target computers. Below I’ll demonstrate how that’s accomplished.

1. Use the Windows 10 Media Creation Tool to obtain the ISO installation media for the version of Windows 10 that you want to deploy. You can download the Windows 10 Media Creation Tooldirectly from Microsoft at this link. It will enable you to obtain the most recent version of Windows 10, which at this time is version 1709. You cannot use this tool to obtain anything other than the current/latest version, so if you are needing an older version then you would have to obtain it through some other means, such as through a volume licensing agreement with Microsoft.
2. Run the media creation tool. When you run the media creation tool you *must* be logged on to the computer as a local administrator. It is *not* sufficient to use ‘run as’ to run the tool with elevation as an administrator. You must actually be logged-on to the computer as the administrator before you run the media creation tool, otherwise the tool will not let you proceed.
3. Create installation media. When you run the media creation tool you will have the option to either Upgrade this PC now or Create installation media (USB flash drive, DVD, or ISO file) for another PC. Select the option to Create installation media, and then click Next.
   
4. Choose the language, the edition, and the architecture when prompted, and then click Next again.
   
5. Select destination media type. The media creation tool gives you the option of putting the installation files on a USB flash drive or into a single ISO file. For this tutorial please choose ISO, and then click Next. You will be prompted for a location on disk to save the ISO file. Choose a file destination and wait for the download to complete.
   
6. Extract ISO contents. After the ISO download has completed, extract the contents of the ISO file to a new directory on your computer. While you can use almost any extraction tool for this process, I prefer and recommend 7-zip, which is available for free. After the extraction is complete you will have a folder that contains all of the required installation files.
   
7. Create the BatchPatch deployment. Select Actions > Deploy > Create/modify. In the Deployment interface, select the setup.exe (from the extracted contents of the ISO) as the file to deploy, and make sure to check the ‘Copy entire directory‘ box and the ‘Leave entire directory‘ box, so that when the target computer is rebooted multiple times during the upgrade/installation, it still has access to all of the files required for the upgrade. Additionally, you need to add the following parameters:

   /auto upgrade /quiet

8. Execute the deployment. When you are ready you can either save the deployment to execute later by using the double-right-arrow ‘>>’ button, or you can execute the deployment now for the currently selected rows in the BatchPatch grid by clicking the Execute now button. The deployment will take some time because BatchPatch has to copy multiple GBs of data to the target computers before it can execute the upgrade. When BatchPatch shows Exit Code: 0 (SUCCESS) for a given target computer you should expect that the target will still be working and will still reboot at least one time but possibly multiple times while Windows is upgraded and configured on the target, so be patient and let it do its thing!

   NOTE: We have had two reports where a user received the following error:

   Deployment: Error: Access to the path '\\TargetComputer\C$\Program Files\BatchPatch\deployment\autorun.inf' is denied.

   It’s unclear why these two users experienced this error while many others, including us, have executed the deployment successfully without encountering the error. My guess is it might have something to do with the application used to extract the .ISO file. Nonetheless, if you encounter the error it can be resolved by simply deleting the autorun.inf file from the source directory before beginning the deployment.

Today I’m going to talk about the Task Scheduler, recurrence, and the alternative options available to BatchPatch users needing to create tasks that execute more than just one time.

Let’s start with the standard recurrence options available in the Task Scheduler options.

Scheduled Tasks with Standard Recurrence (Daily, Weekly, Monthly)

1. To create a standard recurring scheduled task, highlight the desired rows/hosts in the BatchPatch grid, and then select ‘Actions > Task scheduler > Create/modify scheduled task.’
2. In the window that appears you must select the desired task to be executed from the Task drop-down list. Then set the reference time. NOTE: When you modify the reference time, the run time automatically changes accordingly. For all scheduled tasks that have no recurrence option set, the run time will be the same as the reference time. Also when any standard recurrence option is set (daily, weekly, monthly), the run time will be the same as the reference time. However, when you create a recurring task with one of the recurrence options that says “+ X days” you’ll see that the reference time and the run time will differ by the X value, in days. We’ll get into more detail with that option later on in this posting.
3. Finally, choose your recurrence option – daily, weekly, or monthly. Then click OK to apply the scheduled task to the highlighted rows. Make sure the scheduler is running/enabled, by clicking the clock icon in the upper right corner of the BatchPatch window. When it’s green the scheduler is running/enabled.

Scheduled Tasks with Advanced Recurrence (+ X days)

When it comes to Windows Updates, as patching administrators we all know that Microsoft generally releases updates on the 2nd Tuesday of each month. This day has become known as “Patch Tuesday.” Wouldn’t it be convenient if you could just set a schedule to automatically download and install updates at some time/day that is always X days after Patch Tuesday?

While we do not recommend installing Windows Updates *immediately* after Patch Tuesday, we *do* recommend installing the updates within a couple of weeks of Patch Tuesday. The idea here is all about mitigating risk. There is a real risk involved in installing updates, particularly on production servers, *immediately* after they are released. This is because Windows updates can and sometimes do actually break things. On the flip side, if you wait months to install updates, you leave your machines exposed to vulnerabilities that would be fixed by applying the updates in question. We tend to think the sweet spot for installing updates is usually some time between 4 days and 2 weeks after the updates have been released by Microsoft. This gives ample time for those updates to be tested in your lab instead of in your production environment, and it also gives time for other people around the world to report any issues that they encounter, while still getting the updates applied somewhat soon after they are initially released, thereby protecting your machines from being exposed for any longer than necessary.

So, let’s say your scheduled maintenance window occurs on the first Saturday after Patch Tuesday. While Patch Tuesday is always the 2nd Tuesday of the month, the Saturday that comes after is not necessarily the 2nd Saturday of the month. For example, in the current month (March 2018) the Saturday that comes after the 2nd Tuesday of the month is actually the 3rd Saturday of the month. So if we want to reliably have a scheduled task that always recurs on the Saturday that comes after the 2nd Tuesday, we need to be able to schedule it for “Monthly (2nd Tuesday) + 4 days.” If we instead scheduled it for every 2nd Saturday, we’d encounter many months where we’d end up running the task on the Saturday *before* instead of the Saturday *after* Patch Tuesday. This would obviously be unacceptable. Hence why the BatchPatch recurrence options include functionality for ‘Monthly recurrence + X days’. When you select this option from the ‘Recurrence’ drop-down menu in the BatchPatch Task Scheduler, you’ll notice that the run time is no longer the same as the reference time. The reference time gets set to the actual 2nd Tuesday of the month, while the run time is set to the following Saturday. In each month no matter which day the 2nd Tuesday lands on, with this setting your scheduled task will always end up recurring on the 1st Saturday following the 2nd Tuesday. Pretty cool, right?

Scheduled Tasks with Multiple Tasks Scheduler

If for any reason the recurrence options do not suit your needs or desires, you may always just use the ‘Multiple Tasks Scheduler.’ This feature enables you to set a specific task to run at specific days/times for a given host. For this you would just click the button ‘Create Multiple Scheduled Tasks‘ and then set your desired tasks accordingly. In the screenshot below you can see that I have 3 different run dates and times set for a task. I could populate as many different run dates and times as I want, effectively allowing full customization of the schedule.

Scheduled Tasks with Multiple Rows Per Host in the Grid

The other option that’s always available instead of using the built-in recurrence options and instead of using the built-in ‘Multiple Tasks Scheduler’ is to simply populate the grid with multiple rows for each host. So if you want to set 3 different scheduled tasks for a given host, you can add that host to the grid 3 times. Then in each row you could create a different scheduled tasks, as illustrated in the screenshot below.

We have never previously posted any specific information about the type of hardware required to run BatchPatch because the reality is that BatchPatch should run fine on almost any modern Windows computer. We have run it without issue on systems with very limited hardware capabilities, but there are still a handful of things worth considering with regard to performance expectations.

• RAM: We suggest having at least 2MB of free RAM available on the BatchPatch computer for each simultaneous target computer that you plan to patch. This means if you want to patch 100 target computers all at the same time, then you would need to have at least 200MB of free RAM.
• CPU: Generally speaking we have found that on most modern computers it shouldn’t be a problem to patch at least a few hundred target computers at the same time. We have many customers who do more and many who do less. A faster CPU can help with grid performance when patching a very large number of computers, simultaneously. A particularly slow CPU would likely cause noticeable stuttering when trying to patch a large number of computers, so we don’t recommend running BatchPatch on a device with an ultra-low voltage CPU, such as the Atom processor, for example.
• Network Interface: BatchPatch has to maintain communication with every target computer during the operation, so it’s a good idea to have a gigabit network connection on the BatchPatch computer, though it’s not absolutely required.
• WSUS: If you are using a WSUS, please note that if you instruct a large number of target computers to search for and/or download updates from your WSUS all at the same time, the WSUS computer would need to be able to support all of those connections. WSUS does not have significant hardware requirements, so it’s not necessarily going to be a problem. I only mention it as something to be aware of. We like to use GPO to pre-download the updates to target computers so that when the server maintenance window begins, the updates may be installed immediately on target computers without having to wait for download to complete and without any potential, albeit unlikely, bottleneck at the WSUS. More here.
• Maximum Hosts: BatchPatch does not impose any limit to the number of computers that may be added to the grid. However, if you were to add 10,000 target computers to a grid and if you were to try to install Windows updates on all of those computers simultaneously, I can pretty much guarantee that the user interface is going to lock up, even if you are running BatchPatch on a very powerful computer. Our general philosophy has always been to provide the sysadmin with as much flexibility as possible without placing any artificial or seemingly arbitrary restraints on the software as far as performance is concerned. Essentially, we don’t prevent the administrator from shooting him/herself in the foot. However, BatchPatch does provide a couple of performance settings that can be used to make sure something like this does not happen. Under ‘Tools > Settings > General‘ you will find ‘Concurrent Thread Maximum‘ and ‘Concurrent File-Copy Operations Maximum‘.
  
  The Concurrent Thread Maximum setting enables the administrator to specify a maximum number of simultaneous operations that will be allowed in the grid. For example, if this value is set to 100 (default), then if you launch an action on 500 computers all at the same time, the first 100 will begin processing while the other 400 will queue until threads become available from the first 100 as they complete their operations. You can set this value to 0 to remove the cap and allow unlimited simultaneous actions. However, please be mindful that you could cause the GUI to lock up if you try to handle too many actions at once. Though also please note that if the GUI *does* lock up in this case because you tried to process too many simultaneous hosts, usually it will unlock eventually as actions are processed. It is best to leave it alone until it finishes (be patient) rather than forcibly closing the application. I am reminded of one customer who mentioned that he patches approximately 5000 computers simultaneously in one BatchPatch grid. He knows that when he launches the operation that it’s going to cause the GUI to freeze/hang, but he simply leaves it for 45 minutes. When he comes back to it, all 5000 computers have been patched, and the GUI is no longer frozen.
  
  The Concurrent File-Copy Operations Maximum setting enables the administrator to specify a maximum number of simultaneous file copies that the BatchPatch computer will perform when copying files to target computers. This is not limited to files that are copied via ‘Actions > Copy file/folder‘. It also includes files that are copied to targets during Windows Update, such as when cached mode is enabled. The default value is set to 6, which we find to be a good number for most situations. However, there is no problem with increasing this value, if you so desire. It’s hard to know what the best balance is between total number of concurrent copies allowed vs speed of each individual copy. At some point when increasing this value there will likely be diminishing returns.

Although we tend to think that BatchPatch really shines when used to execute and monitor patching operations in real-time on numerous remote computers, we have many customers who use BatchPatch to schedule various actions to occur in an automated fashion without any administrator involvement. We don’t recommend this for critical server patching because usually those servers have a very specific up-time requirement, and they need to be patched in real-time with administrator oversight, so that up-time requirements are not violated. But for all of the other times when the target computers can be patched without real-time monitoring, the BatchPatch scheduler is a great way to get things accomplished in the middle of the night without having to be awake while everything is taking place.

Now, the thing with applying Windows updates or deploying software or rebooting many computers via an automated job, whether that be in the middle of the night or on a weekend or some other time altogether, is that the administrator generally always still wants (and needs) to be able to know the status of all the jobs that are being performed without having to actually monitor the process in real-time. For this we recommend using the task scheduler to not only launch the deployments, update jobs, reboots, scripts etc, but also to send email status updates to the administrator, so that he/she can review everything without accessing the BatchPatch console. For the 3AM automated patching windows, wouldn’t it be convenient to wake up in the morning and simply check your email on your mobile phone while still lying in bed in order to determine if all 3AM operations completed without issues?

This link demonstrates the different ways you can send email notifications in BatchPatch, but below I’m going to focus on the specific case of sending a single automated email message to provide status information about all of the hosts in the grid (or about all computers in all of the grids open in the BatchPatch instance).

Configure Default Email Notification Settings

If you have not ever sent email notifications in BatchPatch before, the first thing you need to do is set your defaults.

1. Select ‘Tools > Settings > Email notifications‘
   
2. Fill out all of the fields and use the ‘Send test email’ button to confirm that everything is working.
3. For this example we are using $grid as our body text. What that means is that when BatchPatch sends the email it will include a copy of the current BatchPatch grid. If you use $allgrids instead of $grid, the email will include a copy of all of the open grids in the BatchPatch instance. Since our goal in this tutorial is to have a single email provide the status of all computers in the grid, we use $grid. If you want your email to only include the status of the single host/row that is being used to send the email, then you could use $row instead.
   • $row: If you specify “$row” in the body, the entire contents of the BatchPatch row that initiates the email notification will be included with any email notification that is sent.
   • $grid: If you specify “$grid” in the body, the entire contents of the grid that contains the row that initiates the email notification will be included with any email notification that is sent
   • $allgrids: If you specify “$allgrids” in the body, the entire contents of the all the grids in the entire BatchPatch instance that contains the row that initiates the email notification will be included with any email notification that is sent.

Now, let’s say that you have a BatchPatch grid where all hosts are scheduled to be updated and rebooted at 3AM. And let’s assume that you expect all operations to be completed with all hosts back online by 3:30AM. Well, you could then choose to send an email notification at 3:30AM or 4AM (or whenever makes sense for your situation) that includes a copy of the entire grid as an HTML attachment to the email message. This way you can review if your patching was successful or not and if all computers have come back online or not yet etc.

Sending an HTML copy of the entire BatchPatch grid via email

1. Create a new row in your BatchPatch grid. The host name does not really matter since it will be used strictly for sending an email notification. You could even have the host name as ‘EMAILER’ or similar, like in the screenshot below.
   
2. Select the ‘EMAILER’ row and choose ‘Actions > Task scheduler > Create/modify’. Then set the task to ‘Send email notification’ for the desired time, which in this case is 03:30. Then click OK to apply that task schedule to the ‘EMAILER’ row.
   
   
3. Lastly, make sure to enable the task scheduler by clicking on the small clock icon in the upper right corner of the BatchPatch grid. If this icon is red, the task schedule is disabled. When the icon is green it means the task scheduler is enabled/running. A scheduled task will only ever be executed if the task scheduler itself is active/enabled/running.

At 3:30AM when the task is executed it will send an email notification using the default settings that you filled out earlier under ‘Tools > Settings > Email notifications.’ This means that an HTML copy of the entire grid will be sent to the email address(es) configured in that screen. Remember we used the $grid variable to specify that we want the entire grid emailed. If you have multiple tabs/grids open in BatchPatch you might instead prefer to use $allgrids.

If you want to have BatchPatch automatically synchronize a grid with certain Active Directory organizational units (OUs) and groups at a scheduled time, you can do this now using the Task Scheduler in BatchPatch.

The idea here is that instead of manually adding and/or removing computers from your BatchPatch grid, you can link a grid with any number of Active Directory OUs and groups. Then if you add or remove computers from the Active Directory OUs or groups that are linked to a grid, you can update the grid with the AD changes by simply synchronizing the grid with the linkes OUs and groups. We have a tutorial that demonstrates the basic synchronization functionality here, but today I’m going to show you how to synchronize the grid with a scheduled task instead of kicking it off manually.

1. The first thing you need to do is link your grid to the desired OUs and/or groups in Active Directory. To do this select ‘File > Synchronize grid with directory‘
   

2. In the window that appears enter a single LDAP path to a security group or an organizational unit.

3. If the logon account that you are using to run BatchPatch is not on the domain of the OU/group that you are adding or simply does not have the required permissions to view the directory, then you’ll need to specify credentials, which you can see I’ve done in the screenshot above. You also have the option to check the ‘Recurse sub-OUs‘ box. This means that the search for computers will include not only the computers in the specified LDAP path but will also contain computers in any sub-OUs in that same path. After you have entered the desired LDAP path, click the button to ‘Verify path and add to list.’ BatchPatch will attempt to connect to your Active Directory at the specified LDAP path. If successful it will list the computers in the specified OU or security group.

4. The computers contained in the specified OU or group will be listed. This simply helps you verify that you have entered the correct path information to the desired security group or OU. Click OK to include this LDAP path. You’ll see that the path will be added to the list below.

5. You may link a single BatchPatch grid to any number of OUs and/or security groups. In the screenshot below you can see that I have my grid linked to two different OUs.

6. At this point if you want to complete a manual synchronization you could simply click the button ‘Synchronize BatchPatch grid now.’ Doing so would initiate a search for all computers in the specified OUs and security groups. You would then be prompted to add those computers to the grid, or if any computers were found in the grid that were not found in the OUs and groups, you would be provided the option to remove those computers from the grid too.

7. However, for the sake of this tutorial we are not going to complete the synchronization right now. Instead, cancel the Synchronization Results window and instead just click OK on the Synchronization Settings window. Now your LDAP paths are linked to the grid, which means you can initiate the synchronization via scheduled task.
8. At this point I’m going to select any row in the grid. You could even create a “dummy” row that is expressly for the purpose of synchronizing your grid to AD. To synchronize the entire grid you only need to create a scheduled task for a single row. With the desired row selected, click ‘Actions > Task scheduler > Create/modify scheduled task’.
9. In the Task Scheduler window that appears choose a synchronization task from the Task drop-down menu. Choose either ‘Synchronize grid with directory (add hosts only)‘ or ‘Synchronize grid with directory (add and remove hosts)‘. Then set a task time/day, and click OK. Make sure to enable the task scheduler by clicking the small clock icon in the upper right corner of the BatchPatch window. Green is enabled. Red is disabled. If the scheduler is disabled, no scheduled tasks will be executed.

10. I have selected the ‘add and remove hosts’ option so that when the grid synchronization completes, not only will hosts that exist in the OUs/groups be added to the grid if they are not already in the grid, but also any hosts that appear in the grid that do not exist in the linked OUs/groups will be removed from the BatchPatch grid. Note, the row that initiates the synchronization will not be removed from the grid even if it does not exist in the linked OUs/groups. Also note, if BatchPatch fails to connect to one or more of the linked OUs/groups, no host removal will occur. In that case only host addition will occur. BatchPatch errs on he side of caution in this case to prevent erroneous removal because if a linked OU or group cannot be searched for whatever reason, BatchPatch does not know if that OU or group would contain hosts that might otherwise be removed from the grid, so BatchPatch simply leaves them as-is and does not remove them from the grid.
    
    When the task is executed the hosts that exist in the OUs and groups that do not already exist in the grid will be added to the grid. The hosts that exist in the grid that do not exist in the OUs and groups will be removed from the grid, with the exception of the host/row that executed the scheduled task, as mentioned above.

Running batch files on target computers is actually a very easy process using BatchPatch. You can execute the same .bat or .cmd file on numerous remote computers simultaneously with just a few clicks. Perhaps the only confusing aspect of this process is that we won’t use the ‘Remote process / command’ action in BatchPatch to perform this task. It may seem like the intuitive choice to use ‘Remote process / command’, but instead it’s actually much simpler to use the BatchPatch ‘Deployment’ feature to accomplish our goal here. We tend to think of deployments as being specific to installing or deploying a package on target computers, but it’s actually the simplest way to run batch files remotely too. This is because a BatchPatch deployment works by having BatchPatch first copy the desired file or files to the target computer(s), and then once the file or files have been copied, BatchPatch executes the deployment, which in the case of a .bat of .cmd means that BatchPatch will run the batch file using cmd.exe on each of the desired target computers.

1. In your BatchPatch grid highlight the rows for the desired target computers (this can be any number of rows/hosts), then click ‘Actions > Deploy > Create / modify deployment’
   
2. In the ‘Deploy’ window that appears click the triple-dot (…) button to select the batch file to deploy. The file extension of your batch file should be .cmd or .bat
   
3. We are going to be deploying a single batch file, so we select the ‘Normal (singular) deployment’ radio button option and then click OK to browse to the location of our batch file. Note, the ‘Multiple update file deployment’ option is only allowed for .msu, .msi, and .msp package deployments.
4. In the ‘Deploy’ screen you’ll see that the filepath of the .cmd or .bat file is now displayed in the corresponding field. For the sake of this example the only text inside my .cmd file is an ‘IPCONFIG’ command, so I’m going to tick the box to ‘Retrieve console output.’ However, note that the ‘Retrieve console output’ checkbox is not compatible with all deployments, and in some cases ticking this box will cause the deployment to fail outright.
   
5. At this point the deployment configuration is complete. It’s really *that* simple. I’m going to click ‘Execute now’ to execute the deployment for the selected row(s) in the grid, but you may optionally save the deployment for future execution by using the double-right-arrow button, or you may apply the deployment to the selected rows without actually executing it by clicking on the ‘Apply deployment…’ button.
6. Since my batch file contained just a single simple command it executed almost instantly. We see the ‘Deployment: Exit Code: 0’ in blue, and the output of the IPCONFIG command can be viewed in the ‘Deployment Output Log’ column. That’s all there is to it.
   

BatchPatch Error: -102 is one of the most common errors that users experience. In general, it indicates that the target computer had some type of problem connecting to the update server, which can be either your local WSUS (Windows Server Update Services) server or Microsoft’s public Windows Update or Microsoft Update server.

In your ‘Remote Agent Log’ column you will see the full error, which always includes a HRESULT value. If you closed BatchPatch without saving the HRESULT code, you can still view this in the target computer’s BatchPatch.log and/or BatchPatchError.log, which will both be stored in the remote working directory. The default location is C:\Program Files\BatchPatch unless you have modified the ‘Remote working directory’ location under Tools > Settings > General.

You can think of the HRESULT value as a sort-of ‘reason code’ for the issue. So the -102 value simply means that there was a problem with the target computer’s ability to communicate with or connect to the update server. The HRESULT value will be the reason why there was a problem. Below are most of the HRESULT values that have ever been reported to us, as well as possible explanations for why they might occur.

Note, the HRESULT value is reported in decimal format, but it’s helpful to convert it to hex for the sake of google searching for a solution. The hex value is much more likely to turn up helpful search results in comparison to the decimal value. Please see the bottom of this page for a description of how to convert decimal values to hex. Once you have the hex representation of the HRESULT, you can look it up here to see what it means: Windows Update Error Code List

Various HRESULT values that might be seen with a -102 error

Error -102: Failed to execute the search. HRESULT: -2147012866

0x80072EFE -2147012866 ERROR_INTERNET_CONNECTION_ABORTED
The connection with the server has been terminated.

This error could indicate a proxy configuration problem. For more details on using BatchPatch with an enterprise proxy, please see: using-batchpatch-with-an-enterprise-web-proxy

Alternatively, it’s possible that this error could be caused by any type of application running on the target computer that could sever a network connection. For example, a Host Intrusion Protection/Prevention (HIPS) application, an anti-virus application, or a similar security suite.

Error -102: Failed to execute the search. HRESULT: -2145124322

0x8024001E -2145124322 WU_E_SERVICE_STOP
call was aborted due to service stop or system shut down

This error would usually occur if the Windows Update service on the target computer was in the process of stopping, or if the computer was in the process of rebooting. Make sure the target computer is online and its Windows Update service is started/running.

Error -102: Failed to execute the search. HRESULT: -2145107934

0x80244022 -2145107934 SUS_E_PT_HTTP_STATUS_SERVICE_UNAVAIL
Http status 503 - temporarily overloaded

This likely indicates an issue with your WSUS server. It could be a transient load problem or it could indicate that the server needs a reboot or that the web service is not responding properly.

Error -102: Failed to execute the search. HRESULT: -2145107924

0x8024402c -2145107924 WU_E_PT_WINHTTP_NAME_NOT_RESOLVED
Winhttp SendRequest/ReceiveResponse failed with 0x2ee7 error. Either the proxy server or target server name can not be resolved. Corresponding to ERROR_WINHTTP_NAME_NOT_RESOLVED. Stop/Restart service or reboot the machine if you see this error frequently.

This is the error that we would expect to see if your WSUS were offline or if there were a DNS or proxy problem preventing the target computer from establishing a connection with the WSUS.

Error -102: Failed to execute the search. HRESULT: -2147023838

0x80070422 -2147023838 ERROR_SERVICE_DISABLED
The service cannot be started. If BITS service is disabled by the Administrator, then this error will be seen.

Make sure the Windows Update service and the Background Intelligent Transfer Service (BITS) are started on the target computer.

Error -102: Failed to execute the search. HRESULT: -2147012867

0x80072EFD -2147012867 ERROR_INTERNET_CANNOT_CONNECT
The attempt to connect to the server failed.

Make sure that the target computer actually has access to the internet. If you have a proxy in your environment, this error could indicate a proxy configuration problem. For more details on using BatchPatch with an enterprise proxy, please see: using-batchpatch-with-an-enterprise-web-proxy

Error -102: Failed to execute the search. HRESULT: -2147012894

0x80072EE2 -2147012894 ERROR_INTERNET_TIMEOUT
The request has timed out.

Make sure that the target computer actually has access to the internet. If you have a proxy in your environment, this error could indicate a proxy configuration problem. For more details on using BatchPatch with an enterprise proxy, please see: using-batchpatch-with-an-enterprise-web-proxy

Error -102: Failed to execute the search. HRESULT: -2145124306

0x8024002E -2145124306 SUS_E_WU_DISABLED
non managed server access is disallowed

We have seen this occur when in Group Policy or Local Policy the following setting is enabled Computer Configuration\Administrative Templates\System\Internet Communications Management\Internet Communication settings\Turn off access to all Windows Update features

Error -102: Failed to execute the search. HRESULT: -2145103860

0X8024500C -2145103860

We have seen this occur when in Group Policy or Local Policy the following setting is enabled ‘Computer Configuration\Administrative Templates\Windows Components\Windows Update\Do not connect to any Windows Update Internet locations’

Error -102: Failed to execute the search. HRESULT: -2145123272

0X80240438 -2145123272

We have seen this occur when the WSUS server is offline or non-existent

How to convert HRESULT decimal values to hex

HRESULT codes will be in decimal format, but we usually need to convert them to hex in order to figure out what they mean. The easiest way to do that is with your Windows calculator. Launch calc.exe and switch to the ‘Programmer’ calculator by clicking the button in the upper left corner of the calculator window.

In the Programmer calculator select DEC and paste in your HRESULT value. You can then see the HEX value. In this example I’ve pasted -2147012867, and we can see the HEX value is 80072EFD.

Once you have the hex representation of the HRESULT, you can look it up here to see what it means: Windows Update Error Code List

Beginning with the March 2018 version of BatchPatch we improved the functionality for clearing specific grid contents. In the past there were a handful of pre-defined methods hard-coded into the BatchPatch menu that one could use to clear the contents of a group of columns. However, we would regularly receive requests from our users to add new custom selections. For example maybe John would want to be able to clear columns A, B, and C, but Jill would want to be able to clear columns B, C, and D, and then Mike would come along and want to clear columns C, D, and E. It was always possible to clear a specific set of desired columns, but it was not possible to save a selection list so that you could quickly clear the contents of a custom, pre-defined group of columns over and over and over without having to re-select the group. You would have to either use one of the pre-defined lists that we coded into the app, or you could manually select the list of columns that you would want to clear each and every time you would want to clear them, which was a tedious process.

In the March 2018 version we updated the functionality so that now you can easily select a group of columns that you want to clear, and you can then save that group for easy future clearing. The process is outlined below.

Create Custom Selections Lists for Clearing Column / Grid Contents

1. Select ‘Actions > Clear column contents > Create/modify selections‘
2. In the window that appears, select the columns that you want to clear. You could simply click ‘Clear contents of selected columns now‘, which would perform the operation on the currently highlighted rows in the grid, but if you instead specify a title for the selections list, you can then save the list using the double-arrow button. You can see in the screenshot that I have saved a few different entries.

3. After you save the desired selections and close the window you will now be able to clear columns of the selected rows on-demand very quickly by selecting ‘Actions > Clear column contents > Execute saved selections‘

4. Additionally, once you have saved a selection list it will appear in the Job Queue window and Scheduled Task window so that you can clear column/grid contents from inside a job queue or scheduled task.

Removing Firefox from numerous computers does not have to be a tedious process. While you could certainly use remote desktop to connect to each target computer and then manually launch the add/remove programs applet, this would take a very long time if you had to perform the task on dozens or perhaps hundreds or even thousands of computers. Alternatively you could just use BatchPatch to perform this task on all of your remote computers at the same time, enabling you to effectively uninstall Firefox from your entire network of computers in under a minute. The process if very straightforward and simple.

First you’ll just need to identify the installation directory on your computers. For example, on my lab computers Firefox is installed in either “C:\Program Files\Mozilla Firefox” or “C:\Program Files (x86)\Mozilla Firefox”. If your computers have Firefox installed in a different directory then just make sure you substitute your installation directory in the command instead of using the one in my command.

In order to remove Firefox from numerous computers using BatchPatch, we first have to be able to successfully uninstall it from a single computer at the command prompt with no user interaction. We need the process to execute “silently” or “quietly” so that it simply runs to completion without needing any additional interaction from the user or administrator to complete the process. We don’t want a situation where we have to click “yes” or confirm in some other way to proceed with the uninstallation. We just want the process to run on its own after we launch it. So first to confirm that we are able to successfully remove the software from just one computer using the command prompt rather than BatchPatch, we execute the following command in a cmd.exe window.

The x64 version of Firefox default setup uninstall command:

"C:\Program Files\Mozilla Firefox\uninstall\helper.exe" /S

The x86 version of Firefox default uninstall command:

"C:\Program Files (x86)\Mozilla Firefox\uninstall\helper.exe" /S

Run the command and make sure that it successfully removes Firefox. If the command does not successfully remove Firefox on your computer at the command prompt, then there’s no way that BatchPatch will be able to remotely execute the same command with success. However, the command should work for you just as it did for me to completely remove Firefox. Once confirmed, we can then run the same command in BatchPatch to target numerous remote computers, simultaneously.

We highlight the desired target computers in our BatchPatch grid and then select ‘Actions > Execute remote process/command > Create/modify remote command 1’

In the command window you may insert the removal command just as I have done here:

Click ‘Execute’ to launch the command on all of the selected/highlighted hosts in the BatchPatch grid. In my lab the entire process completes in just a handful of seconds. Firefox is removed, and I can go on about my other business.

Today I’d like to go through all the ways that BatchPatch can be used to automate your software and operating system patch management.

Standard BatchPatch Actions:

If you log on to a computer locally to apply updates and reboot, it’s a multi-step process. First you have to use remote desktop to connect to the desired computer, then you have to logon, then you have to launch the Windows Update control panel, then you have to download and install the available updates. At this point you’d have to wait usually at least a few minutes, but sometimes much longer while the download and update process completes. And even after the updates have been installed you still then have to manually initiate a reboot and monitor the computer with a ping command or a monitoring tool while the reboot is taking place, so that you can confirm that the computer is back online after the reboot. This process could easily take 30 minutes per computer, which is fine if you just have a few, but what if you have dozens or hundreds or even thousands of computers to manage?

With BatchPatch you can add all of the desired computers to a grid, and then select the entire lot to ‘Download and install updates + reboot if required.’ Instead of having to individually log on to each computer to perform the action, BatchPatch will remotely connect to every computer at the same time to initiate and monitor the whole process. You can have the entire fleet of computers updated and rebooted within a matter of minutes. How’s that for automation! BatchPatch can perform almost any action that you would ever need to perform on remote computers, and it can do all of the remote computers simultaneously. This is great for deploying software or updates, or for executing remote commands or scripts, or for retrieving information or updating registry values etc.

Example:
batch-install-windows-updates

Scheduled Tasks:

Ok, so you’ve been using BatchPatch to manage updates, but what if you don’t even want to touch the BatchPatch console? You could further automate your updating process by scheduling task to occur at a desired date/time, so that when that time arrives BatchPatch will automatically launch the tasks that you scheduled across whichever target computers you created the schedule for. You can even have it email you a copy of the BatchPatch grid for review so that you don’t have to touch the BatchPatch console during the maintenance window, if so desired.

Another automation option for scheduled tasks is the facility in the scheduler to ‘Run task immediately upon detecting target computer online’. This option let’s you configure a scheduled task to run as soon as BatchPatch detects the target computer on the network, rather than having to wait for a specific scheduled date/time for the task to run. This way if you have computers that are frequently pulled off the network, instead of scheduling an update process to occur at a date/time, since you don’t know if the computer will be connected to the network at that time, it’s often easier to just have BatchPatch run the task as soon as the computer is detected online.

Example:
using-the-task-scheduler-in-batchpatch

Job Queues:

If you need to run multiple different tasks in a specific sequence so that you can start and stop scripts before and after patching, or execute multiple patch and reboot cycles with a single click, or any number of other things, check out the Job Queue feature.

Example:
using-the-job-queue-in-batchpatch-for-multi-step-execution

Multi-Row Sequences:

What about the case where you have multiple computers that are all dependent on one another in some way, such that you want to make sure that only one of them is taken offline at any given time. Or perhaps you want/need to apply updates and reboot these computers in a specific order. Or maybe it’s a virtual machine host with a number of virtual machine guests on it, and you want to apply updates to all guests first, and then when the guests are complete you want to update and reboot the host. Well, you could certainly oversee this process manually. You could make sure to be careful about which machines you update and in which order and when. However, wouldn’t it be nice if you could kick off these entire sequences with a single click rather than having to manually manage the whole process? BatchPatch has a feature called “Advanced multi-row queue sequence” that enables the administrator to construct sequences of actions across multiple computers for maximum automation and control.

Example:
advanced-multi-row-queue-sequence

For those of you who already use BatchPatch, you’ve probably experimented with the built-in options it has for checking the disk space on remote computers. These options are pretty straightforward, and I will go over them in a moment. However, what I’d also like to address is the question of not just how do you check for disk space on remote computers, but how do you quickly and easily confirm that many remote computers have enough disk space available before you begin a patching operation? What I mean to say here is that while you can easily check for the available disk space on many remote computers using BatchPatch, how would you go about actually reviewing the results to make a quick determination that you have enough space on your target computers? If you have 100 or 1000 computers or more computers, it could take a long time to carefully review results. Of course you could write a custom script to handle this, but let me show you two very quick ways to accomplish this in BatchPatch with no custom scripting required.

Checking for Available Disk Space

• Actions > Get information > Get disk space (% with graph)

• Actions > Get information > Get disk space (available MB)

• Actions > Get information > Get disk space (available MB) > All disks

Reviewing Disk Space Results Quickly

If you look at the screenshots above you can see the three primary ways that disk space info can be retrieved and displayed in BatchPatch. In the case of method 3 where we check for the disk space on all disks for a single computer, the results cannot be quickly reviewed for many computers, so let’s focus on the first two methods.

In method 2 where we get the available disk space in MB, we can quickly sort the rows by available MB, which gives us an immediate way of knowing which targets might be running tight on disk space. We can just look at the top of the grid (or bottom, depending on direction of sorting) to see the targets that have less available space on the scanned drive.

Unfortunately for method 1 the sorting option doesn’t give us great results because it will sort based on percentage used rather than actual available MB free. Percentage isn’t particularly useful if you really just want to make sure that each computer has, say, 1000MB free for Windows Updates to be applied since the percentage depends on the overall amount of disk space available.

However, we do actually have another facility that makes method 1 a more viable option for quickly determining if there is enough disk space. Under ‘Tools > Settings > General‘ there is a setting called ‘Low Disk Space Warning Threshold (MB)’ for which the default value is 500. For the sake of this example I’m going to set it to 50,000. Note, this is not a practical value to set, but I’m using it in this example just to illustrate what it does. A more practical value might be something like 1500MB or 2000MB, depending on your preference for how much free space should trigger the warning.

Notice that when I re-check the disk space %, now each target that has less than 50,000MB available on the scanned disk will show the bar in red instead of purple, so unless you are color-blind, this could be another method for quickly confirming available disk space is above a desired threshold on numerous computers.

BatchPatch has a feature ‘Send message to logged-on users’ that enables the administrator to quickly and easily produce a pop-up message on the interactive desktop of target computers, so that a logged-on user will see the message. The message text is completely customizable, and the message can even be set to go away after X seconds. Used in conjunction with BatchPatch job queues and/or scheduled tasks means that you can setup a routine where at a scheduled time BatchPatch will automatically notify end-users with a pop-up message on their computers that in X seconds or minutes their computers will be updated and rebooted. Let’s go over how to set this up.

1. Create a message to send to logged-on users. Go to ‘Actions > Send message to logged-on users > Create/modify messages’. In the window that appears, create a message, give it a title, and optionally set the message to auto-close after X seconds. Then click the double-right-arrow button (>>) to save the message.
   
2. Create a job queue. The purpose of this job queue will be to send the message that was created in the previous step to target computers, then wait 5 minutes, then initiate an update/reboot task. Go to ‘Actions > Job Queue > Create / modify’. In the window that appears we’ll create a job queue with those steps. Note, since we saved our message to logged-on users, it now appears in the ‘Saved User-Defined Commands and Deployments’ grid in the lower-left portion of the job queue window. Give the job queue a title, and click the double-right-arrow (>>) button to save the queue.
   
3. Create a scheduled task. Now that we have a job queue saved, we can set it to be executed by the BatchPatch task scheduler at a desired time on a desired day. Highlight the desired rows/targets in your BatchPatch grid, and then select ‘Actions > Task scheduler > Create / modify scheduled task’. From the drop-down menu select the job queue that you created in the previous step. Then set a day/time for the task to be executed.
   
4. Enable the task scheduler. Now that the scheduled task has been created, the last thing that needs to be done is to enable the scheduler, which by default is not running. Click on the small red clock icon in the upper right corner of the screen. Upon clicking it will turn from red to green, indicating that the scheduler has been enabled.
   
   

If the software or update that you want to deploy to computers on your network is formatted as a .MSI file, here is how to use BatchPatch to deploy it to any number of computers at one time.

1. Add the desired target computers to the BatchPatch grid. BatchPatch provides numerous ways to add hosts to a grid, so just pick your desired method. You can import a text file list of computers using ‘File > Open…‘ or by just dragging and dropping the text file onto the BatchPatch window (unless you have launched BatchPatch as administrator, in which case drag-drop functionality will be disabled). Alternatively you could manually type or paste a list of computers into the ‘Add hosts‘ dialog under ‘File > Add hosts…‘, or if you are working in a domain environment you could add hosts from an Active Directory organizational unit (OU) or security group by selecting ‘File > Add hosts from directory…‘
   
   
   
2. Now that you have your desired hosts added to the grid, highlight them, and then select ‘Actions > Deploy software/patch/script/regkey etc > Create/modify deployment…‘
   
   
3. In the deployment window that appears, select the .MSI file that you plan to deploy. Note, some .MSI packages will initiate a reboot of the target computer, so if you want to prevent that from happening, then make sure to check the /norestart button. After installation you can then initiate the reboot yourself through BatchPatch under ‘Actions > Reboot…‘ so that you can more easily monitor what’s going on. Also, if the .MSI package has additional files that are required by it for it to run to completion, then you need to make sure to have those files in the same folder as the .MSI file, and then check the box ‘Copy entire directory contents in addition to the specified file‘. This way all of the required files will be copied to the target computer. Then when the .MSI file is executed, it will be able to find the other files that it needs to complete its work.
   
   
4. At this point we are ready to execute the deployment. If you want to save the deployment for execution at a later time, add a title in the ‘Deployment Title‘ field, and then save the deployment by clicking the double-right-arrow button. However, if you are ready to deploy the .MSI to your targets now, then just make sure they are all highlighted in the grid, and then click ‘Execute now‘. As always, we recommend testing any deployment on a single computer before attempting a larger deployment to many computers.

One of the common questions we regularly receive is will BatchPatch be able to work over a VPN? BatchPatch *can* work over a VPN connection, but the real question is will BatchPatch work over *your* VPN connection? It really depends on how your VPN and VPN firewall are configured, not on how BatchPatch is configured.

In corporate environments we usually see two ways that VPNs are deployed. In one configuration a site-to-site VPN configuration might be used to effectively connect a remote office to a corporate headquarters in order for the users in the remote office to be able to connect to all the resources in the corporate headquarters just as if those users were connected directly to the LAN in the headquarters office. Typically in this kind of site-to-site VPN configuration there is little to no firewalling between the two offices, because the goal is for the remote office users to have an identical experience to the users who are directly connected to the main LAN back at headquarters. When a firewall is used to block ports or services between sites, the experience for remote users is quickly degraded because they don’t get the same unfettered access to resources that users in headquarters get. This diminished experience in turn makes it harder, sometimes, for remote users to complete their duties. Similarly, if there is significant firewalling of ports or services between the two offices, IT administrators who work in the main office might not be able to perform all of the duties that they need to perform on remote office computers. Furthermore, in the typical site-to-site VPN setup, users do not have to run special VPN client software on their computers. In fact, when they are plugged into the LAN in the remote office, they should have a seamless experience in which they cannot even tell that there is any difference to be connected to the main office. Plugging a computer into either the home office or the remote office should yield the same experience for the end user.

In the second type of configuration, instead of setting up a complete site-to-site VPN with little to no restrictions between the two sites, remote users might install a VPN client software on their computers. Whenever they want or need to connect to services in the main corporate headquarters they simply launch the VPN client software, click the ‘connect’ button, and then the VPN software establishes a tunnel to the corporate LAN. Once connected, the users are able to access various services that have been pre-configured by the IT department. In this case where VPN client software is used, it seems to be much more common in corporate environments for firewall configurations to be more tightly locked down such that only designated sites and services are made available to the end users who connect through the VPN. Frequently in this type of VPN configuration, if an application has not bee pre-approved and pre-configured to work across the tunnel, it won’t. And similarly, IT staff frequently are not able to connect from the main office to the VPN-connected client computers in order to manage them in the same way that they would be able to manage the computers that are directly connected to the corporate LAN. But again, it all depends on how the firewalls are configured.

So, when it comes to BatchPatch, if you’re not sure if it will work over your VPN, here is what I would suggest:

1. Download the free evaluation version of BatchPatch from https://batchpatch.com/download

2. Test BatchPatch on your main LAN without involving any VPNs. After all, if you can’t get BatchPatch working without using the VPN, then you’re certainly not going to get it working over the VPN. Please carefully review the ‘Getting Started‘ page to learn how to configure your environment to work with BatchPatch.

3. Once you have BatchPatch working on your main LAN, then go ahead and test it over the VPN. If it doesn’t work, visit the administrator or engineer who controls the VPN and firewall devices in your environment, and work with him or her to get everything configured for BatchPatch to function properly. In some cases if corporate policy prevents them from modifying the existing VPN to allow BatchPatch to function, they might still be willing or able to configure a specially permissioned VPN that is strictly for IT staff and that has less restrictions in place so that software like BatchPatch can be allowed to work over it.

I have posted articles and tutorials in the past on the BatchPatch feature known as the ‘Advanced multi-row queue sequence.‘ In fact there is a really thorough tutorial here that demonstrates how to integrate custom scripts into your job queues and multi-row queue sequences, which essentially enables the administrator to incorporate features/functionality into BatchPatch that might not exist already in a single-click menu item.

Today I’d like to discuss a bit more some thoughts on what an ‘Advanced multi-row queue sequence’ might look like in a different environment. For example, let’s say that you want to have one computer check for available updates and install them if there are any, but if there aren’t any, then you want the next server in the queue to do the same. Furthermore, if there *are* updates available for installation, you want to download and install them and reboot the computer, and then you want the computer to check again to see if after reboot any new updates became available. And again you want to then install any available updates, but if there are none available you want the next host in the advanced multi-row queue sequence to begin working. Additionally, if updates are available and installed and the host is then rebooted, you want to perform a verification check on that server to make sure that it is functioning properly before moving on to the next host in the sequence. There are surely multiple ways to accomplish something like this, but below I’m going to provide one possible way to accomplish this.

First, if you are not familiar with ‘Advanced multi-row queue sequence’ execution, please review the following links, which all demonstrate how to use it.

Advanced Multi Row Queue Sequence Video Tutorial

Virtual Machine Guest Host Update and Reboot Sequence Automation

Advanced Multi Row Queue Sequence Contingent Operations with Custom Scripts

Now, what if we apply the following job queue to each of the hosts in our advanced multi-row queue sequence? This allows us to have each host do multiple cycles of ‘download/install/reboot’ along with running a custom script to verify that our target is functioning in the way that we want … i.e. in addition to being online, which BatchPatch checks for, the custom script can check to see that the server is providing whatever service it provides. If the verification script finds that it is providing the service, the script returns 0. If the verification script finds that it is not providing the service, the script returns a non-0 integer. This enables us to use the two following special job queue items:

Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors

So, if we apply the queue below to three hosts in the BatchPatch grid, for example. And if include those three hosts in the advanced multi-row queue sequence, such that each host represents one sequence position, which means that each host will execute the complete job queue below in sequence, so that no host goes offline at the same time, and so that if one host fails the verification script, then no other hosts will be acted upon in any way, then we can accomplish a pretty solid automation routine.

Check for available updates
Terminate queue if previous 'Check for available updates' finds 0 updates
Download and install updates + reboot if required
Wait 10 minutes
Wait for host to be detected online
*Run a custom remote verification script/deployment that returns 0 if successful/OK, non-0 if unsuccessful/notOK
Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors
Check for available updates
Terminate queue if previous 'Check for available updates' finds 0 updates
Download and install updates + reboot if required
Wait 10 minutes
Wait for host to be detected online
*Run a custom remote verification script/deployment that returns 0 if successful/OK, non-0 if unsuccessful/notOK
Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors
Check for available updates
Terminate queue if previous 'Check for available updates' finds 0 updates
Download and install updates + reboot if required
Wait 10 minutes
Wait for host to be detected online
*Run a custom remote verification script/deployment that returns 0 if successful/OK, non-0 if unsuccessful/notOK
Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors