Using the Job Queue to Clear ‘All Messages’ Before Executing a New Action

By Scott | Published: April 23, 2020

Some of our users launch a fresh instance of BatchPatch each time they use it, and they start with a brand new grid (or a set of grids) each time. They load their hosts and then begin patching. However, some of our users prefer to re-use the same grid file (.bps) over and over and over, so that each time they start patching, it’s really more like a continuation of the previous week or month. One downside to this approach is that the log data, particular in the ‘All Messages’ column, can become overwhelmingly large as it grows with each action that is executed. This is especially an issue for users who are automating virtually everything in BatchPatch. They often don’t even really want to interact with the application except to create new jobs, so at some point it makes sense to clear out the excess data that is no longer needed, but in such a way that requires no extra work from the administrator. To be clear, it’s not a lot of “work” by any means because it only takes a couple/few clicks, but for many sysadmins everything is all about automation. Today I’ll show you how to setup your scheduled tasks to execute a job queue, where the job queue’s first step is to clear column log data. The subsequent steps in the job queue can be whatever you need or want, but presumably they will involve actually patching the target computers or running scripts etc.

Create a Custom Command for Clearing Data in Desired Columns

  1. First let’s setup the selection list for which columns will be emptied. Click on ‘Actions > Clear column contents > Create/modify selections‘. You could choose to clear all columns (except for the Hosts column), or you could just selectively clear a couple/few columns. For this example let’s just setup an entry to clear only the ‘All Messages’ column. You can see in the screenshot below that I have selected the ‘All Messages’ column, and I have saved the entry by using the double-right-arrow button.

  2. With the entry you created above now saved, if you flip over to the Job Queue window (Actions > Job Queue > Create/modify job queue), you can see in the lower-left grid, titled ‘Saved User-Defined Commands and Deployments‘, that the entry you created a moment ago now appears.

  3. You can add that entry as the first step in a job queue. This way when the job queue is executed, the first thing it will do is clear out the ‘All Messages’ column. Then you can have it do whatever else you need or want, such as initiating Windows Update on target hosts. Then you can save the Job Queue by using the double-right arrow.

  4. With your job queue now created, you can setup a scheduled task for any target host that will execute the job queue. Click on ‘Actions > Task Scheduler > Create / modify scheduled task‘. In the Task Scheduler window, from the task drop-down menu, select the title of the Job Queue that you just created. Set a run date and time, and then click OK. Then make sure the scheduler is enabled by clicking the small red clock/timer icon in the upper right corner of the main BatchPatch window so that it turns from red to green.

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

Preventing Particular Updates from Installing on Target Computers

By Scott | Published: April 10, 2020

Under normal circumstances BatchPatch is used to initiate the download and/or installation of updates on a group of target computers. So long as you have setup your environment to work with BatchPatch as far as permissions and firewall settings are concerned, then BatchPatch can, if desired, be used without altering your existing Windows Update settings. That is to say that if you have your target computers configured to automatically install updates at a particular time each week, if you were to use BatchPatch at some other time in the week, BatchPatch would download/install updates at that time, assuming there were available updates to download/install at that time. However, most of the time when administrators are using BatchPatch, they want to use BatchPatch exclusively for the Windows update process, so they definitely do not want their computers to be automatically installing updates at other times. They essentially want to only ever have target computers download/install updates when they have initiated the process from within the BatchPatch console (either on-demand or via BatchPatch scheduled task). In this case, target computers must be configured to not automatically download/install updates on their own schedules.

Now, in BatchPatch it’s easy to choose to install only specific/particular updates, or to install certain categories of updates (such as ‘Security Updates’ or ‘Critical Updates’ etc), but how does one make sure that the target computers do not automatically install updates on their own at other times? And how does the administrator ensure that only the updates that he/she chooses to install via BatchPatch are the only updates that are installed on the target computers? There are a few things to consider. Let’s review them below.

First, if you’re going to be using BatchPatch as your primary method for initiating the update process on target computers, then it makes sense to start by telling target computers to *not* automatically install updates on their own schedules. There is a group policy object that you can enable on target computers that will instruct those computers to *not* download and *not* install updates on their own schedules. If you don’t know what group policy is, it’s essentially a mechanism that is built-in to Windows for controlling all sorts of settings for how Windows behaves in a domain environment. If your computers are not domain members but instead are running standalone or in a workgroup, you’ll still have access to all those same group policy settings, only instead of being able to control them from a single/central location in group policy (on the domain controller) you would instead control them individually on each target computer using the local policy editor. Local policy and group policy can be viewed as essentially the same things, except that group policy settings will control a group of computers, and is set on the domain controller for those member computers, whereas local policy settings are the same settings simply controlled and set on an individual per-machine basis.

The behavior of the following setting varies slightly depending on which operating system is running, but no matter which OS you are using you would want to open the group policy editor (or the local policy editor) and find the setting for Configure Automatic Updates which is available under Computer Configuration > Administrative Templates > Windows Components > Windows Update. Setting the value to either 2 Notify for download and notify for install or 3 Auto download and notify for install will prevent updates from installing on their own. This way you can instead initiate the installation process from the central BatchPatch console. If you want BatchPatch to perform both the download and installation, then set the value to 2. If you want the computers to auto-download the updates on their own but then use BatchPatch for the installation portion of the process, then set the value to 3. In either case, once this is set, the computer will no longer install updates on its own automatic schedule.

OK, so if you configure your target computers, via group policy or local policy, to *not* ever automatically install updates on their own, then effectively speaking if you only use BatchPatch to initiate the installation of desired/selected updates, you’re going to end up with only the updates that you want installed on those target computers. In a certain sense I think it’s fair to say that you have then also prevented the particular updates from installing that you never opted to install. However, in this case if you had, for example, a list of 100 available updates, and you chose to install 90 of those 100 updates, then you would still be left with 10 available updates on the target computers. The act of *not* installing them but still leaving them there in the “available updates” queue is not identical, conceptually, to actually preventing them somehow from ever being installed. So… what if you want to actually prevent them from ever installing? To be clear, if you set things up in the way that I described above, those updates would never install unless you chose to install them through BatchPatch, but it’s conceivable that you could forget that you didn’t want to install them, and then maybe at one point you would inadvertently choose to install all of the available updates on target computers instead of only a limited subset of the available updates, thereby causing those 10 leftover updates to get installed. Maybe you would want to do everything in your power to prevent such a situation from being able to occur in the first place… What are your options for actually *preventing* those 10 updates from ever being installed? You have two basic options…

Hiding Updates on Target Computers

If you’re using BatchPatch standalone without any WSUS server involved, then you can use the ‘Hide Updates‘ feature in BatchPatch. What this action enables you to do is tell a target computer (or a group of target computers) to take an update (or group of updates) that is currently showing as available for installation, and to then effectively “hide” it so that it no longer even appears as available for the computer. In the example that I gave above with 100 updates, if you install 90 of them, you could then hide the remaining 10. Once hidden, if you were to then initiate a “check for available updates” or “download updates” or “install updates” action, the hidden updates would be excluded altogether, as if they never existed. This option is simple and quick to use, but it does come with one drawback, unfortunately. Let’s say that on January 1, 2020 Microsoft published update KB1234567. Then in the middle of January or at some point after that you decided to hide the update on the target computers so that it no longer appeared available. The problem is that Microsoft is capable of re-publishing that same update ID KB1234567 at a later date. If they do that, then KB1234567 will all of a sudden show up again in the list of available updates. However, note that just because Microsoft publishes the same update KB ID again in the future does not necessarily mean that the update is identical to what it was when you first hid it. In fact, it’s probably the case the update is definitely not the same as it was. So in a sense you could view it as Microsoft updating the update, so that the update itself functions better or behaves a bit differently or what have you, and in that case even though the update is being published under the same KB ID, in a certain sense it really wouldn’t be much different from Microsoft publishing the same update or ever-so-slightly different update under a different KB ID. The truth is that at any time Microsoft publishes a new update (or re-publishes and old update) the administrator should be evaluating from scratch if that update is one that he/she wants to install. So realistically the fact that Microsoft might sometimes re-publish a previously hidden update, such that the hidden update becomes unhidden and moved back to a status of “available” really shouldn’t be a major drawback for the administrator. It probably makes more sense for the administrator to simply view it as he/she would view a new update, and then simply decide if it is an update that he/she wants to install. If not, then it can just be hidden again.

Using a WSUS Server to Control Which Updates are Presented to Target Computers

The other option you have is to use WSUS to control which updates are ever even presented as “available” on target computers. In this case instead of using BatchPatch as a standalone tool, you would instead use BatchPatch in conjunction with WSUS. I should note that WSUS is free and simple to install and use, so it’s certainly a good option for many administrators. To see how to configure BatchPatch to work in conjunction with WSUS, check out this link: BatchPatch Integration with WSUS and Group Policy.

Once you have configured your target computers to work with the WSUS and BatchPatch, then instead of relying solely on BatchPatch to control which updates you install on target computers, you get an additional layer of control. Inside of WSUS you can configure it so that no updates are ever approved for distribution until you have gone into the console and selected them for approval. So, each month when Microsoft releases new updates, after your WSUS synchronizes with Microsoft’s public servers, you would then go to your WSUS and choose which of the available updates you would want to approve for distribution to your target computers. The target computers are configured to retrieve their updates from your WSUS instead of directly from Microsoft (as described previously), and this way the target computers only ever even know about the updates that you have first selected for approval on the WSUS. If you want to prevent a particular update from being able to be installed on the target computers, don’t ever approve it in the WSUS. In fact, you can actually use the “decline” option in WSUS so that not only is it not approved but actually it is officially declined for installation at that point. Target computers that are pointed at the WSUS (via Group Policy, as explained in the link above), will only ever “see” updates that have been approved. When you then use BatchPatch to download/install updates on those target computers, BatchPatch will only ever be able to install those approved updates… UNLESS you were to configure BatchPatch to bypass your WSUS and pull updates directly from Windows Update or Microsoft Update. If you wanted to do that, in BatchPatch you’d go to ‘Tools > Settings > Windows Update > Server Selection’, and then you would change the setting from ‘Default/managed’ to ‘Windows Update’ or ‘Microsoft Update’ instead.

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

Incorporating Custom Scripts in BatchPatch – Get Local Administrators Group Membership

By Scott | Published: March 19, 2020

Let’s have a look at how to incorporate a custom script into BatchPatch. In this case we’ll use BatchPatch to run a script that will retrieve the list of users who are members of the local administrators group on each target computer, and then optionally write it all to a text file.

If you would instead like to modify group members of a local group on target computers, or if you want a quick way to retrieve group membership on target computers without using a custom script and without being able to write the results to a file, take a look at this posting: Using BatchPatch to Modify Local Group Membership on Multiple Remote Computers

I’m not going to get into the details of the actual script that we’re going to use for this tutorial since this posting is not intended to be a scripting lesson but rather is meant to demonstrate one possible way to incorporate a custom script into BatchPatch. There are also other custom scripting examples on our website, if you’re interested, that you can find by searching ‘script’ in the search box on the upper right area of this page.

Here is the script:

Dim strFilePath, strComputer
strComputer = WScript.Arguments(0)
strFilepath = "C:\Temp\results.txt"
 
Sub GetAdministrators(strComputer)
    Dim objWMIService, strQuery, colItems, Path, strMembers
    Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
    strQuery = "select * from Win32_GroupUser where GroupComponent = " & chr(34) & "Win32_Group.Domain='" & strComputer & "',Name='Administrators'" & Chr(34)
    Set ColItems = objWMIService.ExecQuery(strQuery)
    strMembers = ""
    For Each Path In ColItems
        Dim strMemberName, NamesArray, strDomainName, DomainNameArray
        NamesArray = Split(Path.PartComponent,",")
        strMemberName = Replace(Replace(NamesArray(1),Chr(34),""),"Name=","")
        DomainNameArray = Split(NamesArray(0),"=")
        strDomainName = Replace(DomainNameArray(1),Chr(34),"")
        If strDomainName <> strComputer Then
            strMemberName = strDomainName & "\" & strMemberName
        End If
	WScript.Echo strMemberName
        Set oFSO = CreateObject("Scripting.FileSystemObject")	
	If oFSO.FileExists(strFilepath) Then
	    oFSO.OpenTextFile(strFilepath,8).WriteLine(strComputer & ": " & strMemberName)
	Else 
	    oFSO.CreateTextFile(strFilepath).WriteLine(strComputer & ": " & strMemberName)
	End If
    Next
End Sub
 
GetAdministrators strComputer
  1. The first order of business is to copy the script text into notepad. Modify the filepath in the third line of the script to point to whatever location you want to use to save the results. Then save the script to somewhere on your computer as GetLocalAdmins.vbs

  2. If you only want to get the group membership and don’t care to log the results to a file, then you may delete or comment out the following section. In that case BatchPatch will just get the group membership so that you can view the result for each target computer inside the BatchPatch grid. However, if you really just want to get group membership without logging to a file, then you can use a simpler method that doesn’t involve incorporating a custom script. See the link provided near the top of this posting for details on that method. That said, if you are going to be using the script method that I’m demonstrating in this tutorial but you don’t want to log the results to a text file, then you should delete this section from the script:

    '
'Set oFSO = CreateObject("Scripting.FileSystemObject")	
'If oFSO.FileExists(strFilepath) Then
'    oFSO.OpenTextFile(strFilepath,8).WriteLine(strComputer & ": " & strMemberName)
'Else 
'    oFSO.CreateTextFile(strFilepath).WriteLine(strComputer & ": " & strMemberName)
'End If
'

  3. If you want to run this script one-off to get group membership on a target, just copy and paste the following syntax, modifying the path as needed to match wherever you have the script stored, into a BatchPatch local command under ‘Actions > Execute local process/command > Create/modify local commands‘. Then after you have clicked OK to save the command, you’ll see that it appears in the menu. See screnshots below for reference: 
    cscript "C:\SomeFolder\GetLocalAdmins.vbs" $computer

    IMPORTANT:
    There is a key element that we need to address. If you are going to use the script as-is and have it write the results from all target computers to a single file, you need to pay attention to thread synchronization issues. The specific problem here is that if you execute the script on numerous targets simultaneously, BatchPatch will launch a separate thread for each target, and each of those threads will try to write to the same text file at the same time. This is a problem that could result either in missing data or an error being thrown, so we need to set things up so that each row runs one at a time, sequentially, instead of having all rows run at the same time, simultaneously. This way only one BatchPatch thread at any given time will be accessing the text file and writing results to it. Note, if you have removed the section of code from the script that writes the results to a file, then you don’t need to worry about this issue at all.

  4. To resolve the threading issue we’re going to use the Basic Multi-Row Queue Sequence. This feature will enable us to force each BatchPatch row to execute sequentially, one at a time, until all rows have executed. First, select all rows in the grid and then click on ‘Actions > Job queue > Create/modify job queue‘

  5. In the Job Queue window, find the Local command that you created earlier in the lower left grid for ‘Saved User-Defined Commands and Deployments‘. The ‘Type’ will be shown as ‘Local’ with whatever title you gave to your command. Double-click it to add it as the only step in your job queue. Then click ‘Apply queue to row(s) without executing‘. See the following screenshots for reference:

  6. Now we’re ready to execute. With all rows selected, click on ‘Actions > Job Queue > Execute basic multi-row queue sequence‘ What this will do is instruct BatchPatch to launch the job queue in each row, one at a time, in the order that the rows were selected. As soon as one row finishes running the script and writing the results to the text file, the next row will commence, and so on until all rows have executed the script and written to the file. The results will also be displayed for each row in the ‘Local Command Output Log’ column.
Posted in Blog, General, Tutorials | Tagged , , , , | Comments closed

Remotely Uninstalling Windows Updates

By Scott | Published: March 10, 2020

Let’s face it… even though we all wish Microsoft’s quality assurance and testing was better, it really seems to have gotten worse in recent years… significantly worse. There are a few primary ways that systems administrators can reduce the likelihood of encountering problems after installing Windows updates each month. First, have a testing lab setup with machines that largely resemble production computers, so that updates can be deployed into the testing environment before they are deployed to the production environment. If the testing environment’s computers are actually prepared with similar applications and services as production computers, then there is a good chance that the testing environment will reveal any major issues with Windows updates *before* those updates are ever deployed to production machines. However, it’s often difficult or even impossible to accurately configure testing servers to resemble the production servers closely enough to guarantee that update issues will be discovered in testing before they are deployed to production, so this isn’t the only step that should be taken. We also recommend designating certain production machines to be the first to receive updates, so that if any problems are identified, they can be addressed before deploying the same updates to an entire production network. Additionally, we think it’s important in most cases to *not* install updates within the first few days of their release. We believe that most organizations should be waiting at least a week after Patch Tuesday before they deploy new updates to production systems. This gives the rest of the world a chance to test the updates and report any problems, so that you can then decide if you need to postpone a maintenance window until Microsoft re-issues a fixed version of the update, or to perhaps do additional testing in your environment to confirm whether or not you might be affected by any problems that have been reported with the updates. However, while we do think that waiting a week or so is a great idea for most organizations, you shouldn’t wait too long, especially in cases where the updates to be installed are fixing critical issues that are actively being exploited in the wild. A balance will need to be struck, depending on the details, setup, and requirements of each particular environment, so that updates can be installed soon enough to protect computers while also waiting long enough to minimize any potential problems that might be encountered by installing a problematic update.

What happens if you install an update that is causing problems on your computers?

It’s going to depend on the nature of the problem, of course, because if the update is so destructive that computers won’t even boot, then you’re obviously going to have to manually address each affected computer in order to resolve the problems. However, in most cases when a problematic update has been deployed, simply uninstalling it is sufficient to make the problem go away until a fixed version of the update is published by Microsoft. If you find yourself in a situation where you need to remove a Windows update that you previously installed on numerous computers, you can use BatchPatch to execute the removal/uninstallation process.

Using BatchPatch to Execute the Update Removal/Uninstallation Command

First, note that there are two different commands built-in to BatchPatch for removing Windows updates. You’ll need to execute the command that corresponds to the particular operating system that you will be removing the update from. In BatchPatch you can see the two different menu items in the screenshot below:

  1. Highlight the rows in the grid for the computers that have the update installed that you want or need to remove/uninstall.

  2. Click on the relevant menu item, depending on which OS is installed on your target computers… either ‘Actions > Windows updates > Uninstall individual update (requires KB ID) – Windows 7/2008/2012‘ or ‘Actions > Windows updates > Uninstall individual update (requires KB ID) – Windows 10/2016/2019‘

  3. Enter the KB ID of the update that you want to remove, and tick or untick the ‘/norestart’ option, depending on whether you want the command to prevent the update process from rebooting the computer or not. If the computer needs to be rebooted in order to complete the update removal, and if you tick the ‘/norestart’ option, you’ll need to execute the reboot separately in order for the update removal process to be completed. We generally prefer to check ‘/norestart’ and then separately initiate the reboot in BatchPatch. In this way BatchPatch can monitor the reboot through its normal process. If the removal command itself performs the reboot (this happens if /norestart is un-ticked and the update removal process requires a reboot), BatchPatch won’t monitor it. Note, the command to execute is different, depending on which menu item you selected in the previous step. The screenshots below show the difference:

    wusa.exe /uninstall /KB:1234567 /quiet /norestart


    cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "$SearchUpdates = dism /online /get-packages | findstr 'Package_for'; $updates = $SearchUpdates.replace('Package Identity : ', '') | findstr 'KB1234567'; DISM.exe /Online /Remove-Package /PackageName:$updates /quiet /norestart"

  4. Lastly, click OK to execute the process.
Posted in Blog, General, Tutorials | Tagged , | Comments closed

Using the Job Queue to Execute an Ordered List of Actions on Target Computers

By Scott | Published: February 26, 2020

One of the most commonly used features in BatchPatch is the Job Queue. The Job Queue enables you to execute a series of actions, sequentially, on target hosts. Just about any action that BatchPatch can perform through manual execution can also be added to a job queue.

One of the most common reasons people use the job queue is to perform multiple update and reboot cycles on target computers– a kind of “lather, rinse, repeat” option for Windows Updates. Historically, Windows has sometimes behaved in such a way where after applying Windows updates and rebooting, subsequently doing a fresh scan for available updates would sometimes yield more updates to install. So it’s convenient to be able to automate the process whereby you can download and install updates, reboot, wait for the computer to come back online, then download and install updates, reboot, wait, and so on until no more updates are found. With the most recent versions of Windows (10/2019) we have not really seen this behavior occur as frequently as it once did with previous versions of Windows, but it’s still something that can happen, and it’s nice to be able to automate the “lather, rinse, repeat” process in order to save time and effort.

A Few Ways The Job Queue Can Help

Beyond doing an update and reboot cycle, there are many other reasons why one might want or need to be able to execute a series of actions, step by step, on a group of computers. For example, sometimes you might need to run a script or a command that disables a service or stops a process before or after you begin the normal Windows update and reboot process. In other cases you might need to pop a notification to the currently logged-on end user of the target computer before you proceed with any download or installation of updates. Or perhaps you need to install a third party application before or after the Windows update process completes. There are many reasons why using a job queue can be beneficial, so today I’m going to show you how to use it.

What About A Job Queue That Links Multiple Independent Systems Together Into A Larger Sequence?

Note, the BatchPatch Job Queue enables you to create a sequence of actions to run on a target computer or group of target computers. You can create a separate queue for each target, or you can execute the same queue on all targets. There is a lot of flexibility in what you can do, and even if you need to coordinate the actions of multiple different computers, such that one computer (or a group of computers) executes its job queue, and when it completes it triggers another computer (or group of computers) to execute its job queue, and so on… you can do that with the job queue too! However, note that to perform this kind of more complex queue you actually would use the Advanced Multi-Row Queue Sequence, which is a feature that works in conjunction with the standard job queue to effectively link different hosts together into one larger sequence, which can be very powerful for automation of many different tasks so that you can, for example, create a one-click process to execute updates and reboots on machines with interdependencies. And of course in BatchPatch you can also always schedule these job queues or advanced sequences to be executed at a specific datetime if you don’t want to manually launch them.

How To Create And Launch A Job Queue

  1. To create a job queue, select the desired rows in the grid, and then click on ‘Actions > Job queue > Create/modify job queue‘
  2. In the Job Queue window, create the desired queue. On the left side of the window you can select from available actions, and then either double-click or use the arrow button to add the selected item to the queue. The lower-left grid contains all of the custom commands, deployments, notifications etc that you have previously created and saved in BatchPatch.
  3. Select ‘Execute now’ to launch the queue on the highlighted hosts in the grid. Or if you want to save the queue to be executed at a later time, simply give it a title and click on the double-right-arrow button to save it. Queues that have been saved can be launched either from the Job Queue window or by simply selecting the saved queue from the Actions menu under ‘Actions > Job Queue > Execute saved job queues‘. Saved queues can also be launched via the Task Scheduler so that you don’t have to be there to kick them off.
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

Notify Users of Upcoming Reboot or other Patching Activity

By Scott | Published: February 19, 2020

When a systems administrator is performing a maintenance operation on end-user computers, one of the things that can really help significantly is being able to notify any currently logged-on users of any impending actions that are about to occur. Even if it’s a late-night or early-morning maintenance window, you never really know who might actually be working on the computer at any given time, and even though you likely would have already sent numerous emails during the days/weeks leading up to the maintenance to notify the users of the upcoming maintenance window, inevitably the end-users either disregard these emails in the first place, or they forget about them until it’s too late. They end up finding that their computer is updating and/or rebooting right before their eyes, unexpectedly, while they are working on a very important document.

BatchPatch provides a couple of basic ways to notify logged-on users of impending actions to their computers. Below I’ll show you how to use these to make sure your end-users don’t get surprised when you reboot their machines.

Method 1: Send message to logged-on users

  1. This method actually utilizes the Windows built-in MSG command to send any message to the logged-on users of target computers. The only limitation here is that the message cannot exceed 255 characters. Highlight the target hosts in the grid, then select ‘Actions > Send message to logged-on users > Create/modify messages‘

  2. In the window that appears (see screenshot above), enter your message text, and optionally if you want the message to automatically close after X seconds, you can tick the appropriate box and specify a value for X. However, for most situations it’s usually best to leave the message on the screen. This way the end user will be more likely to see the message without missing it. When the logged-on user of the target computers sees the message, he/she will be able to close it.

  3. If you want to save the message for repeat usage at a later time/date, or if you want to incorporate the notification into a BatchPatch job queue, so that you can automate a sequence of events that includes an end-user notification, then make sure to fill in the ‘Title’ field, and then click on the double-right-arrow button to save the message for future use.

  4. At this point you’re ready to send the message. If you want to send it now, click on ‘Send message now‘. However, if you want to send it later, make sure it has been added to the ‘Saved Messages’ grid on the right, and then close the window. Once you’ve done that you can send the message at any time by selecting it from the Actions menu, as illustrated in the screenshot below.

  5. If you want to add your saved message to a job queue at some point, you can do that by selecting it from the ‘Saved User-Defined Command and Deployments’ grid that appears in the lower-left portion of the job queue window. It will be listed as ‘Type’ ‘Send message’.

  6. When the message is actually sent, it will appear on the target computer to the logged-on users as shown in the screenshot below.

Method 2: Advanced reboot with user-notification

  1. The other option you have for notifying logged-on users is built-in to the ‘Advanced reboot‘ and ‘Advanced shutdown‘ methods in BatchPatch. We’ll just look at the ‘Advanced reboot’ method for the sake of this example. Highlight the target hosts in the grid, and then select ‘Actions > Reboot > Advanced reboot with user-notification‘

  2. In the window that appears you have the ability to tick a box to ‘Warn users of the action‘. Then you can enter the desired message that you want the users to see in the ‘Comment’ field at the bottom of the window. When you use this operation, the comment will also be printed to the event log on the target computer, so this option for notifying end-users of an impending action might be less favorable in many cases.

  3. After you enter something in the comment field, you’ll be able to click OK to execute the reboot action, which will pop a message to logged-on users of the selected targets computers as well as create an entry in the event log on those computers with that same message/comment text.
Posted in Blog, General, Tutorials | Tagged , | Comments closed

Offline Windows Patching for Isolated or Air-Gapped Networks

By Scott | Published: February 4, 2020

Applying Windows security updates to a network that is isolated from or completely air-gapped from the primary network can be a challenge and a pain. At the very least it means that you, the sysadmin, have to devise a patching plan for multiple networks. However, it also means that you need a way to figure out which updates the computers on the isolated network need installed, and you need to figure out how to get those updates to that network. One of the most frustrating parts of this process is that frequently when a network is isolated or completely air-gapped, getting files onto or off of that network brings with it additional bureaucratic, or even political, challenges inside the organization that go beyond any existing technical challenge. If a company has taken the precaution of isolating an entire network of computers, they usually will also have very specific processes in place for change management to prevent unauthorized files from getting onto or being taken from the network in question. If the air-gapped network is housing high security computers or data, which is usually why a network would be air-gapped in the first place, then there will typically be very stringent rules that govern when and how files may be removed from that network or brought onto that network.

Offline Updates / Offline Patching:

BatchPatch provides several different modes of operation. You’ll want to select which mode of operation you use, depending on the configuration and rules in your particular environment. All of the different modes are described at the following link, but for users who will be patching isolated / offline / air-gapped networks, you’re likely going to be looking at scenario 3, scenario 4, and scenario 5

Offline Updates with Scenario 3:
In scenario 3 the isolated network is *not* air-gapped but rather is firewalled carefully such that you can setup BatchPatch on a computer that has internet access as well as access to the isolated network, even though the computers on the isolated network do not otherwise have direct access to the internet. In this scenario WSUS may or may not be involved. Involving WSUS would depend primarily on whether or not you already have one in place or whether or not you want to setup a new one. For most users who are reading this now, you’re probably here because you do not already have WSUS and/or do not want to use WSUS. More details here: Cached Mode and Offline Updates

Offline Updates with Scenario 4:
In scenario 4, the isolated network may or may not be air-gapped, but it assumes that you are not allowed/able to simply setup BatchPatch on an internet-connected computer that also has direct access to the isolated network. However, in this scenario you *are* allowed to remove files from the isolated network, which you can use to your advantage with BatchPatch to figure out which updates BatchPatch needs to download from Microsoft by first doing a BatchPatch scan on the isolated network, and then taking the results list to an internet-connected network. The downloading of updates would occur on the separate internet-connected network. More details here: Cached Mode and Offline Updates

Offline Updates with Scenario 5:
In scenario 5 you’re dealing with the highest level of security, in which you are not even allowed to remove any files from the isolated network, or perhaps too much paperwork is required for it to be a viable option that is easily repeated every single month. In this case you would use BatchPatch on an internet connected computer to download all possible updates that could ever be required by computers on the isolated network. In this way you don’t ever perform a scan on the isolated network, so therefore you don’t have to remove the scan results list. Instead you just go directly to the internet connected network to download all possible updates, and then you bring that entire repository to the offline network. More details here: Cached Mode and Offline Updates

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

Automatically Trigger an Email Notification for an Entire Grid Only After All Targets’ Actions Have Completed

By Scott | Published: January 28, 2020

There are different ways to utilize email notifications in BatchPatch. For example this link illustrates how to schedule email notifications or include them inside job queues. Additionally we have a couple of other tutorials on email notifications here and here.

Today I would like to address a particular scenario for triggering email notifications that some BatchPatch users like to use. In this example I’ll demonstrate how you can configure an email notification to be sent that includes the status of the entire grid but is only sent after all of the desired actions for all of the desired hosts are fully complete. In this case we’ll make sure that every row in the grid is configured to complete its actions before the email notification is triggered. This way when you get the email, which will include an HTML representation of the grid, it will include all of the rows’ activities that have completed prior to the email being sent.

There are essentially two things that we need to do in order to make this work. First, we need to create a job queue for each row/host in the grid. The job queue will contain all of the actions for each host that we want to execute. Second, we’ll configure an advanced multi-row queue sequence to be responsible for making sure the email notification is sent immediately after all of the other rows’ job queues have completed.

  1. The first thing I’ll do is select all of the hosts in the grid, and then click on ‘Actions > Job Queue > Create/modify job queue‘
  2. In the Job Queue window that appears I will simply create the desired queue that I want each target host to execute, and then I’ll use the ‘Apply queue to row(s)‘ button to apply the job queue to each of the selected rows in the grid *without* executing the queue (execution will come later). Note, there is no requirement to assign the same job queue to each host. In fact, each host can have its own unique job queue, if desired, but in this particular example I have applied the same job queue to each target host simply because I need/want them all to perform the same update download/installation task.

  3. Once the desired job queues have been configured for the selected rows, we can go ahead and setup the advanced multi-row queue sequence. What the sequence will enable us to do is tell BatchPatch to first execute the job queue for all of the target hosts that we choose, and then only after all of those rows have completed their job queues BatchPatch is instructed to send an email notification that includes a HTML representation of the entire grid. You’ll notice that I have a row in the grid called “emailer” that currently has nothing configured. This is the row that we’ll use to actually send the email. I’m going to create a job queue for this row that has only one step, which is to send an email notification.

  4. If you have not previously configured your email notification settings, you’ll need to do that. You can see my settings in the screenshow below. The most important component for the sake of this example is that I have set the HTML attachment content (and the body content) to $grid. This will instruct BatchPatch to include a copy of the entire grid in the email notification. Note, if you have a situation where you need some rows to send email notifications that only include the content of their rows instead of the entire grid contents, you can certainly override the global settings on a per-row basis, if desired. This way you can have the global setting configured for $grid, with particular rows configured for $row, if needed. See ‘Actions > Email notifications > Override‘ if you need to have individual rows configured differently from the global configuration. For this tutorial we have the global setting set to $grid so that our email notification includes the entire grid. If we needed to keep the global setting as $row then we would just override the email notification row’s setting to be $grid.
  5. Now we can configure the advanced multi-row queue sequence. Select ‘Actions > Job Queue > Create/modify advanced multi-row queue sequence‘. We use the window that appears to set the ‘Sequence Name’ and ‘Sequence Position Number’ for each row. In this case we want all of the hosts to execute their job queues at the same time in position number 1. When all of position number 1 rows complete, position number 2, the email notification row, will be executed. Select all hosts in the grid and set them to sequence position number 1. Choose a name for the sequence because all of the rows that will participate in the sequence must have the same sequence name. Set the email notification row to position number 2 with the same sequence name as used for the hosts in position number 1.


  6. At this point we are nearly done. All of the hosts are set for position 1, and the email notification row is set for position 2. The last thing that we need to do before we can execute the sequence is create a sequence execution row. Add another row to the grid.
  7. In the advanced multi-row queue sequence, set that new row to be the execution row as illustrated in the screenshot below. Make sure to use the same exact sequence name as before.
  8. The last thing to do is simply execute the sequence. You can execute it manually or you can create a scheduled task to launch it on a particular time/day. To execute it manually, highlight the SequenceExecution row that you created in the previous step, and then select ‘Actions > Job Queue > Execute advanced multi-row queue sequence‘. Alternatively, setup a scheduled task on that same SequenceExecution row by selecting the row and choosing ‘Actions > Task Scheduler / Create/modify scheduled task‘. More on scheduled tasks is available here.
Posted in Blog, General, Tutorials | Tagged , | Comments closed

A Utility to Schedule Windows Updates on Numerous Computers

By Scott | Published: January 14, 2020

When we first created BatchPatch it was intended to be used primarily as a real-time utility, where an administrator could initiate the download and installation process for Windows Updates on many target computers at the same time, while also being able to monitor the progress of each action on every computer all the way through to completion, including through the reboot process. However, of course there are times when the sysadmin simply cannot be in front of the BatchPatch console at the desired time of execution. For those times we provide the BatchPatch Task Scheduler. As systems administrators we frequently have to patch computers in the middle of the night or in the early morning or over a weekend, and it’s nice to be able to schedule these actions to run at a desired time on a particular day rather than having to actually be sitting in front of the computer while they run.

We always recommend that if you are going to be patching a large number of computers, it’s best to be monitoring the entire process in real-time all the way through to completion. This way if any computers fail to apply updates or perhaps get stuck during reboot or maybe don’t start up all of their services upon reboot, typically you’re going to want to be aware of these issues as quickly as possible so that they can be rectified or otherwise dealt with right away before they turn into big problems. If you’re lying in bed fast asleep while hundreds or thousands of computers are being updated, you’re asking for trouble when you wake up. That said, there are certainly many times where scheduling Windows Updates makes plenty of sense. Whether it’s for a one-off computer here or there in the middle of the night, or if you are doing a large number of non-critical machines, those might be times where a scheduling utility could come in handy. And of course even though we don’t particularly recommend scheduling a lot of computers, especially critical ones, we certainly have many customers who always schedule all of their updates without ever handling the process in real-time. Clearly it’s something that is going to be up to the individual administrator to decide upon, depending on the particulars in his/her environment we well as uptime requirements etc.

To schedule a group of computers to perform an action (or a set of actions) at a specific time/day, it’s simple. Select the group of computers in the BatchPatch grid, and then click on ‘Actions > Task Scheduler > Create/modify scheduled task‘. The action can be an individual action such as ‘Download and install updates + reboot if required‘ or one of many other possible commands that are built-in or that you have created in BatchPatch, or it can be a BatchPatch Job Queue that you previously created to execute a group of actions, sequentially, on each target computer.

After you have applied the desired task to each row/target, you then just need to enable the task scheduler by clicking on the small red clock/timer icon in the upper right corner of the BatchPatch window. The red changes to green once the scheduler has been enabled.

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

Say Goodbye to Remote Desktop for Patch Management

By Scott | Published: January 8, 2020

Sometimes I forget just how many systems administrators are still using Remote Desktop to connect individually and manually to each and every computer on their network via Remote Desktop in order to manually install Windows Updates or third party software applications. The process often goes something like this:

Sample Manual Update Process

::Maintenance window begins

::Sysadmin starts launching remote desktop connections to each computer on the network. You’d think that this would only occur in organizations with very few computers, but you’d be surprised. I know of one guy who would spend an entire week each month connecting to hundreds of target computer via remote desktop just for patch management.

::Sysadmin starts running the desired/needed update commands or GUIs on each remote desktop connection

::Sysadmin then starts pulling out his/her hair as s/he proceeds to switch between all the different remote desktop windows in order to monitor the status of each update session

::As update installations complete on each machine, the sysadmin then begins the reboot process on an individual, as-needed basis

::As soon as the reboot process begins, thus begins the process of launching numerous command prompt cmd.exe windows with ‘ping -t ComputerName’ commands, so that the target computers can be monitored make sure they go offline and then come back online.

It Really Doesn’t Have To Be This Way

For anyone who has ever performed a manual patch management maintenance like this, you know what I’m talking about. For those of you who believe that no one does this or would ever do this, be thankful that you’ve never had to do it. It’s shockingly common not only at very small organizations but even at medium and sometimes even larger ones. One of the reasons this happens at larger organizations is because at some point the organization spent many tens of thousands of dollars on a behemoth patch management solution, but it’s so clunky and such a nightmare to operate that the admins find it more efficient and/or just easier to avoid altogether.

For anyone who is still using Remote Desktop to every target computer for manual patch management, maybe it’s time to re-think your process. BatchPatch is truly one of the easiest applications to setup and use, and it’s also one of the least expensive options you’ll find. It was designed very specifically with the systems administrator in mind, and with the goal of having the app work intuitively and simply. You can just launch the app, add a list of computers, select them and choose your patching action.

Simple, Intuitive, Inexpensive Patch Management, Windows Updates, Software Deployments, and Much More with BatchPatch

We offer a free evaluation version for you to get the software up and running in your environment so that you can figure out if you want to buy licenses or not. If you have any questions, don’t hesitate to reach out.

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