Modifying the Scope of Windows Firewall Rules to Allow Connections Only From Selected IP Addresses

By Scott | Published: March 25, 2022

When configuring BatchPatch to work in your environment, you might have to modify your Windows Firewall rules on target computers to enable BatchPatch to work properly. As explained in this posting, BatchPatch will require inbound allowances on all target computer firewalls for File and Printer Sharing and Windows Management Instrumentation in order for BatchPatch to be able to connect to and execute actions on target computers.

In many or perhaps most network environments these allowances will already have been granted long ago because without them it’s very difficult for IT administrators to accomplish the tasks that they regularly need to accomplish. In many/most environments the necessary rules for BatchPatch to work are the same rules that are already in place for general network and system administration, so you might not need to make any changes. In fact, if you regularly ping computers on your network and/or copy files to and from them by connecting to \\targetComputer\C$ in Explorer, then these allowances likely already exist.

In the case where you don’t already have these allowances configured but you’re considering using BatchPatch, you might be wondering how to make the necessary firewall configuration changes so that *ONLY* the computer that is running BatchPatch can take advantage of them. That is, you might want to limit the IP address scope in any firewall rules that you create so that those firewall rules only apply to a particular IP address. The effect of doing this would be that after the rules are created in all target computers’ Windows Firewalls, BatchPatch will only be able to connect to those target computers if the computer running BatchPatch has a particular IP address (or is within a certain IP address range, depending on how you configure the scope).

Applying a particular IP scope to inbound rules in Windows Firewall is simple. First, make sure you have made allowances for File and Printer Sharing and Windows Management Instrumentation as described on this page. A quick review of that process is below in the first step of the tutorial. Note, you can perform this process on an individual target computer or you can make the changes via Group Policy to apply to a large group of computers on a domain. The concept is the same in both scenarios, but please note that in this tutorial my screenshots and specific instructions are based on making these changes on just a single machine, so if you’re making the changes in Group Policy there might be slight differences as compared to my notes and screenshots below:

  1. Go to Control Panel > Windows Defender Firewall > Allow an app or feature through Windows Defender Firewall and then tick the checkboxes next to File and Printer Sharing and Windows Management Instrumentation for the firewall profile(s) that you want to modify (private/public/domain)


  2. Once the initial rules have been created, then you can modify the scope of those rules to limit which IP addresses can utilize them. Go to Control Panel > Windows Defender Firewall > Advanced settings to launch the interface for Windows Defender Firewall with Advanced Security. Click on Inbound Rules on the left-pane of this interface. In the screenshots below you can see that I’ve highlighted all of the individual inbound rules that I will be modifying.


  3. At this point you are going to need to modify every individual inbound rule for File and Printer Sharing and Windows Management Instrumentation for the firewall profile(s) that you are using (private/public/domain). In my case I’m using the private firewall profile, so I’m only modifying the entries for the private profile. However, for your environment you might need to modify the domain profile. Unfortunately this process needs to be completed on each inbound rule one at a time. It’s not possible to perform the action in bulk on all of them at the same time. So go ahead and start at the top and highlight the first rule and then right-click on it and select Properties. In the Properties window, go to the Scope tab.


  4. In the Remote IP address section at the bottom of the window, highlight where it says Local subnet, and then click Edit. Select the radio button for This IP address or subnet, and then enter the IP address of the computer that you will be using to run the BatchPatch console. In my lab here it’s 192.168.1.37, so that’s what I’ve entered.


  5. Repeat the IP scope modification on all of the applicable inbound rules. When complete, File and Printer Sharing and Windows Management Instrumentation will be accessible on the target computer(s) from *ONLY* the IP address that you specified.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Remotely Deploying Windows Feature Update Version 21H2 to Numerous Computers

By Scott | Published: March 10, 2022

Standard Deployment Method for Windows Feature Update 21H2 (and other feature updates/upgrades such as 22H2 etc) in BatchPatch

Unless you are using a version of BatchPatch that was released prior to April 2020, you can usually deploy/install feature updates like 21H2 with the normal Windows Update actions in BatchPatch under ‘Actions > Windows updates‘. However, Microsoft continues to make a lot of changes to how feature updates are handled, so there are some cases where you might have to perform the deployment using the alternate method that’s explained further down in this tutorial.

For the standard deployment method, the first requirement is that the feature update that you desire to install must be offered to the computer and show as an available update when you select ‘Actions > Windows updates > Check for available updates‘ in BatchPatch. If you see the desired feature update in that list of available updates for a given target computer or group of computers, then all you need to do to download/install the update on those computers is modify the classification filtering in ‘Tools > Settings > Windows Update‘ so that the ‘Include “Upgrades”‘ box is ticked.

After the ‘Upgrades’ classification is selected you can simply use ‘Actions > Download available updates‘ with ‘Actions > Install downloaded updates‘ or you can just use ‘Actions > Download and install updates‘. As long as you are operating in standard, non-cached mode, feature updates will install (assuming, of course, that you currently have a feature update showing in the list of available updates for a given computer).

Feature Update Deployment Considerations – Update deferral policies, and when an update is only available for “seekers”

Please note there are a couple of things to consider when installing feature updates using the standard non-cached mode BatchPatch update method.

First, as mentioned above, the target computer needs to have the desired feature update showing as one of the available updates for the computer. If you’re expecting to see it but you don’t, it could be because the update is not approved on your WSUS yet, or it could be that you have a Group Policy or Local Policy setting configured for the target computer that is set to defer the installation of feature updates for a specified amount of time. Check your Group Policy configuration for any deferral policies enabled under the following locations:

Computer Configuration > Administrative Templates > Windows Components > Windows Update

Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business

Second, depending at what stage of the rollout Microsoft currently is at the time you attempt to deploy a given feature update, they might not yet be delivering the update through the normal Windows Update channel. They typically begin the rollout with delivery only to “seekers”. This is the name they give to people who manually click on the ‘Check for updates’ button in the Windows Control panel. “Seeker” updates are visible in BatchPatch when you click on ‘Search for only optional software updates‘

Third, over the past couple/few years Microsoft has made quite a few changes to how Windows Update works, particularly with regard to how feature updates are handled. It’s possible that there is some other reason that I didn’t mention above that is the cause for why you are not seeing the feature update available for installation through the normal Windows Update methods.

Alternate Deployment of Windows Feature Update 21H2 (and other feature updates/upgrades) with BatchPatch (can be used for deployment to offline target computers)

If you need to deploy feature update version 21H2 (or any other feature update) to target computers that don’t have internet access and don’t have WSUS access and therefore cannot be targeted in standard, non-cached mode (that is to say, you are using either online cached mode or offline cached mode with those target computers, and you are not able to disable cached mode and switch to standard mode for whatever reason), then you may use the method outlined below to deploy the feature update to those computers.

  1. Download (from Microsoft) the Windows 10 Media Creation Tool. Use this link to download the media creation tool directly from Microsoft. The media creation tool web page contains two options: ‘Update now’ and ‘Download tool now’. Do NOT click on ‘Update now’ because doing so would begin the update process on your computer. Since your goal is to deploy the upgrade to remote computers, instead please click on ‘Download tool now’ to save the tool to your computer. Important: When you run the media creation tool per the next step, you will not have a choice to select which Windows 10 version is used to create the media. This means that if Microsoft releases a new version of Windows 10 when you follow this tutorial, you’ll end up with that version as opposed to the specific version 21H1 that is available today at the time of this writing. If you have another channel for obtaining media for a particular Windows 10 version, such as with a Microsoft volume licensing agreement, you may use that instead of obtaining the media through the steps outlined in this tutorial.

  2. Open the Windows 10 Media Creation Tool that you saved to your computer a moment ago. IMPORTANT: It is NOT sufficient to run the tool as administrator (using right-click, run-as) from an account that is logged on without admin privileges. For reasons that aren’t fully clear, Microsoft requires that you *must* actually be logged on to the computer with an account that is a member of the local administrators group. Otherwise the tool will not allow you to run it to completion. We don’t know why Microsoft made the tool work this way, but it’s what they did, and presumably it’s for a good reason. So go ahead and log on to your computer as a local administrator, and then launch the tool and follow the rest of this tutorial.

  3. Create installation media with the Windows 10 Media Creation tool. When the tool is running you’ll have to choose between two options to either ‘Upgrade this PC now’ or ‘Create installation media (USB flash drive, DVD, or ISO file) for another PC. Choose the option to ‘Create installation media…’ and then click ‘Next’.

  4. Choose your language / edition / architecture, and then click ‘Next’.

  5. Choose the media type. For the sake of this tutorial please select ISO as the type of media. After clicking the ‘Next’ button you will be prompted to choose a location on your computer to store the ISO file that will be downloaded/created. Select a directory/location to store the file, and then do something else until the download finishes. Depending on your connection speed it could take some time because it’s something like 4GB in size.


  6. Extract the ISO contents to a location on your local disk. After the download in the previous step is complete you’ll have to locate the file on disk and then extract the contents of the ISO to another folder. I like to use the free 7-zip for this process, but you may use whichever tool you prefer: 7-zip. After the ISO has been extracted you’ll have all of the installation files for the feature update in a single folder.

  7. Configure a deployment in BatchPatch. In BatchPatch click on Actions > Deploy > Create/modify. In the window that pops up for the Deployment configuration, click on the ‘…’ button to browse to the location where your ISO contents have been extracted to, and then choose the ‘setup.exe’ file as the file to deploy. Make sure to check the boxes for ‘Copy entire directory‘ and ‘Leave entire directory‘ . After the initial deployment phase is complete, the target Windows operating system will end up rebooting itself at least once but usually more than once while it completes the setup and installation for the feature update. As the process runs it needs to have access to all of the files that BatchPatch will deploy. Having both of the aforementioned boxes checked will ensure that when the upgrade process runs on the target computer that it has all of the files it needs for the installation. After the feature update has completed 100% you may delete the files from the target computer(s). However, please make absolutely sure that the upgrade process is 100% completed before you delete any files. In your BatchPatch deployment configuration screen you will also need to add the following parameters: 
    /auto upgrade /quiet

  8. Execute the feature upgrade deployment. In the deployment configuration that you created in the in the previous step you can execute the deployment immediately for the currently selected rows in the grid by just clicking on the ‘Execute now’ button. Alternatively you may save the deployment for future usage by clicking the double-right-arrow button ‘>>’. If you choose to save the deployment instead of executing it immediately, then when you are ready to deploy the feature update to your remote computers, you can begin the process by selecting those computers in the BatchPatch grid and then clicking on Actions > Deploy > Execute deployment, and then choose the deployment that you just created/saved.

    You should expect that the entire process will take a bit of time to complete. BatchPatch has to copy the whole installation directory to the target computer(s), which contains several gigabytes, before it can execute the upgrade process on the target(s). IMPORTANT: After the BatchPatch deployment completes for a given target computer BatchPatch will show Exit Code: 0 (SUCCESS). However, this just means that the BatchPatch deployment component is finished. The Windows feature update/upgrade process will take additional time. Please be patient and let the target computer continue upgrading and rebooting as many times as is needed. It might take a little while with multiple automatic reboots before everything is 100% finished.

    NOTE: We have had a couple of reports from users who received the following error:

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

    We don’t know the exact cause of this issue, but it seems likely to somehow be related to the way that permissions were applied or inherited during the ISO extraction process. If you encounter this error it can be resolved quickly and easily by just deleting the autorun.inf file from the source directory after extracting the ISO contents but before executing the actual deployment for any target computers. This will prevent the problematic file from ever being copied to target computers. As such, the error will not occur.

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

BatchPatch New Version Released February 2022

By Scott | Published: February 17, 2022

We published a new build last week.

Aside from a number of bug fixes and miscellaneous enhancements, the key features that we added to this build are:

  • Row filter:
    We know a lot of people have wanted this for a long time, so hopefully you’ll all get some good use out of it. In previous versions of BatchPatch you were able to use CTRL+F or Grid > Find in grid… to search either the current grid or all open grids for a particular string. This has its uses but also its limitations, especially when dealing with large grids and lots of matches for your search query. However, now in the current version of BP you can use the row filter (CTRL+H or Grid > Filter rows in grid…) to quickly hide all rows that don’t match the filter string. You can select the column that you want to filter on, and you can enter a search string. So for example, if you want to only show hosts that contain ‘5’ in the host name, you can do it like this:



    Each grid/tab has its own filter, and each grid’s filter will stay enabled until you clear it. However, filters are not saved, so they don’t persist beyond the current session. If you close a grid and then re-open it at a later date, no filter will be applied until/unless you apply a new filter string to the grid. We assume that in most cases people will filter a grid temporarily in order to select/highlight just certain rows that match their filter string, then perform an action, and then clear the filter.

  • Propagate changes made to saved job queues and deployments:
    When we originally designed BatchPatch, we felt it was important for grid files (.bps files) to be portable. The challenge in doing this is that if you save a job queue or a deployment in a scheduled task for a given host or group of hosts, the entire job queue or deployment configuration has to be saved to that grid separately from the repository of saved configurations that exist for the BatchPatch installation for that logon account. Only then could a grid be transferred to a different installation of BP without breaking. However, doing this means that if you subsequently update the configuration for a job queue or a deployment, the changes have to be applied to the grid in every place where that job queue or deployment was previously saved. Prior to the current release of BP, you had to do that manually. However, now when you make changes to a job queue or deployment configuration, you are immediately prompted to apply those changes to any grids where those job queues or deployments were previously saved. We hope this relieves a lot of pain for users who are regularly modifying the contents of their scheduled task job queues and deployments.

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

Overview for Remotely Deploying Software and Specifying Default Settings

By Scott | Published: February 2, 2022

Today I’m not going to perform a specific deployment. Instead I want to provide a conceptual overview for new users who ask us “How do I remotely install software on multiple computers and configure that software to have specific default settings for the end user?” Similarly, “How do I remotely install software to multiple computers and select or choose all of the settings/configurations that I normally do with my mouse and keyboard during an standalone software installation on a single computer?” These are two common questions that we receive in one form or another, so let me spend some time going over the basic process for deployment.

  1. Silent/quiet installation switch for command line or remote deployment:

    99.9% of software packages have the ability to be installed “silently” or “quietly.” When we talk about a ‘silent’ or ‘quiet’ installation, what we mean is that the software can be installed without any dialog boxes to click through and with no options to choose nor filepaths to specify etc. A silent/quiet installation can be run at a command prompt with a single command that launches the entire process. Once the process has been started, no interaction is needed from anyone to complete the process. You simply have to wait for it to complete, and that’s it. When you want to perform a software deployment in BatchPatch, the first thing you need to do is figure out how to execute a silent/quiet installation for the particular package that you are deploying. We have an entire posting dedicated to explaining this purpose, so please start by reading that carefully.

    2. The summary version is that you’ll check the vendor’s documentation and/or review the built-in help in the actual deployment package itself to determine what the proper silent installation switch is. In many cases it’s just a /q or /s, but every package is different, so please review the aforementioned link for instructions on discovering it for your package.

  2. Configuration or “answer” settings file for controlling the installation settings in a silent installation:

    Many software products are just a very simple, straightforward installation where all you need to do is execute them silently without worrying about anything else. They’ll install to the default location with the default settings, and you’re good to go. However, in an enterprise setting you might have the need to deploy a more complex package or a package where you need to specify non-default settings. How do you accomplish this if the software is being deployed silently, such that you can’t click through any dialog boxes to modify installation settings for the end users? The way this is typically done is through the use of a configuration file which is sometimes referred to as an answer file or an unattended setup file. Generally speaking, if a software package provides the ability for you to perform a silent installation, and if that software package has settings that a user might want or need to change, then it will also provide a way for you to modify those settings during the silent installation through an unattended setup file or similar. Consult the software vendor’s documentation to see the specifics for the package that you are deploying. Below I’ll provide a generic/conceptual overview of what it might look like.

  3. Conceptual overview for performing the silent installation with an unattended setup file:

    As mentioned previously, the most important thing you need to do before you get started is consult the vendor’s documentation for the specific software that you’re going to deploy. The way it typically works is something like this. Let’s say you have a software package called SoftwarePackage.exe. That SoftwarePackage.exe is going to have a built-in silent or quiet switch, which for the sake of this example we’ll assume is /q. If you execute a command line installation of the package you would use

    C:\PathOnYourComputerWherePackageIsLocated\SoftwarePackage.exe /q

    to perform a silent installation of the software with its default settings on the local computer. In the case where the vendor provides instructions for creating an unattended setup file so that various settings can be configured at installation time even though the installer is running silently, you’ll probably have a separate file that you have created, which for the sake of this example we’ll just call ‘UnattendedSetup.xml’. Inside of that XML file (your particular software vendor might not use XML format at all– It might be a simple text file or something else altogether) you’ll choose the desired settings per the instructions from your vendor. Furthermore, the vendor’s documentation will include instructions for how SoftwarePackage.exe is going to know about UnattendedSetup.xml. Typically it would be through the use of another command line switch. So, for example, you might find that your silent installation with unattended setup will be executed something like this:

    C:\PathOnYourComputerWherePackageIsLocated\SoftwarePackage.exe /q /u:UnattendedSetup.xml

    Remember, I am just giving you a generic example here. Assume that your software package will be different, and make sure to consult your package’s documentation. OK, once you have determined the proper syntax for executing your silent installation with unattended setup, you need to actually perform that installation from the command prompt of a test computer. You need to make sure that it works properly for your needs. When you have it working properly with the correct syntax for your package, and when you have verified that your settings are applied to the installation as needed (by launching the software after command line installation on your test computer to make sure that the software is configured in the way that you expect), ONLY THEN you should convert that command line installation into a remote deployment in BatchPatch.

  4. Performing the remote deployment in BatchPatch:

    5. Once you have tested your command line installation syntax at the command prompt of a test computer, and you have everything working so that the installation is executed with just a single command, and so that all of your settings are applied during the installation so that when the software is launched for the first time on the computer by the end user it has all of the settings configured in exactly the way that you need or want, then you’re ready to move that command line installation over to BatchPatch for remote deployment to numerous computers. Remember for the sake of this example we have the following syntax for our package to be installed silently at the command line with unattended setup:

    C:\PathOnYourComputerWherePackageIsLocated\SoftwarePackage.exe /q /u:UnattendedSetup.xml

    The way that we would then deploy this with BatchPatch is we would put both UnattendedSetup.xml and SoftwarePackage.exe into C:\PathOnYourComputerWherePackageIsLocated on the BatchPatch computer. Then in BatchPatch we would create a deployment with ‘Actions > Deploy > Create‘

    In the BatchPatch ‘Deploy’ window we would specify the path to our SoftwarePackage.exe, and in the parameters field would we add our parameters. In the screenshot below you can see that our ‘Command to execute’ is essentially the same as the command that we used when we tested the installation manually at the command prompt earlier. Also note that I have ticked the box ‘Copy entire directory‘. This is important! What this means is that BatchPatch will not only copy SoftwarePackage.exe but will also copy the entire contents of C:\PathOnYourComputerWherePackageIsLocated to the target computer, including the UnattendedSetup.xml file that’s in there. This is required so that when the command line silent installation is performed remotely on the target computer, the target computer will be able to find the UnattendedSetup.xml in the same directory as the SoftwarePackage.exe. At this point you’ll want to test your remote deployment on a single machine before you deploy it to numerous computers. You can either use the “Execute now” button or you can save the deployment with the double-right-arrow for executing at a later time.

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

Don’t Forget the Middle-Click Scroll-Wheel Button on your Mouse!

By Scott | Published: January 21, 2022

Sometimes I am reminded that we always have some users who aren’t aware of the middle-click functionality in BatchPatch. This is a bit sad because it’s probably the most clicked button by the rest of us who use BatchPatch on a regular basis. Soooooooooooo… this is just a reminder to everyone that almost every cell in BatchPatch can be middle-clicked to reveal its contents. This helps immensely to get a quick view of what’s going on with a particular target host without having to launch a whole new window.

Middle-Click (Scroll Wheel Mouse Button Click) Example:

For example, in the screenshot below I pressed the middle-click button on my mouse directly on top of the ‘All Messages’ cell in the first row of the grid (this is usually the scroll wheel on your mouse, which some people do not know is actually also a button that you can press!)

Viewing an Entire Row’s Contents:

Yes, you can also double-click a row or press the R key or click ‘Actions > Expand row(s)‘ to view its entire contents in a separate window (see below screenshot), but it’s not as quick and clean as using the middle-click in cases where you just want or need to quickly view the contents of an individual cell.

Viewing the Entire Contents of Multiple Rows:

You can alternatively select multiple rows, and then press the R key or click ‘Actions > Expand row(s)‘

OK! That’s all for today. Happy BatchPatching!

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

Deploy Microsoft Edge to Multiple Computers

By Scott | Published: January 4, 2022

The process for deploying Microsoft Edge with BatchPatch to numerous computers, simultaneously, is essentially the same as with any standard deployment. In this case we will download the Edge .MSI installer, and then create a BatchPatch deployment, and then execute it against our target computers. The process is illustrated step by step below.

  1. Download the .MSI installer file for Microsoft Edge. Choose the appropriate installer file for your needs. For this example I have downloaded the x86 installer to deploy to a Windows 2012R2 test machine in our lab. The Microsoft Edge .MSI installer file is available at this page.

  2. Create a BatchPatch deployment. Click Actions > Deploy > Create/modify deployment

  3. In your deployment window you only need to select the location of your .MSI file. No additional configuration is required. The screenshot below is what it should look like.

  4. When the deployment has been created you can use the double-right-arrow button to save it for later, or you can execute it now by clicking the Execute now button (just first make sure the desired target hosts are highlighted in your BatchPatch grid)

  5. You can see below I have deployed it successfully to my test target machine. I also verified on the target computer that it’s now installed/available.
Posted in Blog, General, Tutorials | Tagged , | Comments closed

BatchPatch is NOT Susceptible to the Log4j Vulnerability

By Scott | Published: December 27, 2021

Since we continue to get a lot of emails asking if BatchPatch is affected by the Log4j vulnerability, I wanted to just take this moment to let everyone know that BatchPatch does not use any Java whatsoever. It is not susceptible to the Log4j vulnerability.

Posted in Blog, General | Comments closed

Remote Windows Update and Reboot for Multiple Computers

By Scott | Published: December 20, 2021

In BatchPatch you can trigger the Windows Update and reboot process on numerous computers all at the same time. Select the desired target computers in the grid, and then click on ‘Actions > Windows updates > Download and install updates + reboot if required‘

If you want this to occur automatically every month at a scheduled time, you can instead create a scheduled task to do the same thing. Select Actions > Task scheduler > Create/modify scheduled task

To make the task recurring, choose the desired recurrence option. If you want to have your recurring monthly Windows Update task coincide with Microsoft’s Patch Tuesday, which is the second Tuesday of the month, then you can use the Monthly (2nd Tuesday) + X days option. If your monthly maintenance window is always scheduled for the Saturday that comes after Patch Tuesday, then you can use Monthly (2nd Tuesday) + 4 days, for example.

When you have set your task to do what you want (in my example I’ve again chosen the standard Windows Update option to Download and install updates + reboot if required, you’ll need to enable the scheduler by clicking on the red clock/timer icon in the upper right corner of the BatchPatch window. It will turn green when it’s clicked on, indicating that it’s enabled.

Now, what if you want the task to be able to run even if the computer is not logged on and BatchPatch is not open and visible? For that you’ll need to enable the BatchPatch run-as-service feature. Click on Tools > Run BatchPatch as a service. You can then install the BatchPatch service, which will run always when the computer is on. Any grids that you create can then be sent to run in the service instance so that your scheduled tasks in those grids will be executed regardless of whether or not someone is actually logged on and looking at the BatchPatch console.

And what if you want to do more than just run a standard Windows Update download/install/reboot operation? What if you want to have that actually execute a few times to ensure that after the reboot occurs that no additional updates are waiting to be installed? (We’ve all seen times where in Windows, after you install Windows updates and reboot, all of a sudden more/new updates are available for installation. For that you can use the BatchPatch Job Queue. The job queue enables you to execute multiple actions in a row on a target computer. To launch the job queue, select your desired target hosts in the grid, and then choose Actions > Job Queue > Create/modify job queue. You can then choose a set of steps that you want each host to execute. In this case I’ve added the following steps to my job queue:

Download and install updates + reboot always
Wait 10 minutes
Wait for host to be detected online
Download and install updates + reboot if required

You can then save the job queue by using the double right arrow button (>>). Once it has been saved, it can be executed as a scheduled task, so you can just go back to your scheduled task window and change the drop-down menu to point to the job queue that you just created. In my case I titled the queue Update + reboot cycle, so I see it listed in the drop-down menu under “Job queue (Update + reboot cycle)”

Of course the job queue can be something much more complex, if desired, because maybe you need to execute a certain script before or after the Windows Update process, or perhaps you need to perform a software deployment, or maybe something else altogether. Nearly anything you can think of can probably be included in the job queue, and it can also do branching and looping, or terminate based on specified conditions. There are lots of options.

What if you want to orchestrate an entire sequence where numerous computers are involved, but where maybe certain computers execute certain tasks, other computers execute various other tasks, and there are uptime/downtime dependencies such that some computers have to be online while other computers are offline. Maybe, for example, you can only have a single computer be offline at any given time in a sequence that involves numerous computers, and you need to be able to trigger the Windows update and reboot process on all machines, in an automated fashion? You can use the Advanced Multi-Row Queue Sequence for that. Check out some tutorials here:

Orchestrating Complex Update And Reboot Sequences Involving Multiple Target Computers

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

Advanced Multi-Row Queue Sequence – Staggering Updates and Reboots in a Group of Computers

By Scott | Published: November 30, 2021

One of the most common uses of the BatchPatch ‘Advanced Multi-Row Queue Sequence‘ functionality is to stagger the updates and reboots in a group of computers so that only a single computer or a subset of computers in the group will perform their updates and reboots at any given time. That is, administrators often need to update and reboot machines in a particular order, allowing only certain machines to be updated or go offline at any one time. Today I’m going to illustrate how that is accomplished in a BatchPatch multi-row queue sequence.

For the sake of this example, let’s assume that you have 9 total target computers, and the goal is to update and reboot 3 at a time. The first group of 3 will update and reboot, but the second group of 3 will not be allowed to begin until after all of the first 3 machines have completed their updates and reboots, and are back online. The third group of 3 will not be allowed to begin their process until after the second group of 3 has completely finished and all machines have come back online.

  1. Create the job queue that you want each target computer to execute when its turn comes in the sequence. For the sake of this example I am going to apply the same job queue to each target computer, but you may configure an individual queue for each target, if desired. It’s completely up to you.

    Here is what my job queue looks like. I’m going to use the ‘Apply queue to row(s) without executing‘ button to apply this queue to all of the selected rows in my BatchPatch grid. Since the goal in this example is to make sure that each subset of 3 computers will be back online before the next subset begins processing, I’ve ended the queue with ‘Wait for host to be detected online‘. This means that the queue won’t be complete for any given target until the target is confirmed to be online after its update and reboot steps.

  2. Now that our queues are configured for each target host, we’ll setup the advanced multi-row queue sequence. First, I’ve added a sequence execution row to the grid. This is a special row that we create for the sole purpose of being able to execute/begin the sequence. The host name for the execution row can be whatever you want. For this example I’ve simply entered a new host called ‘ExecRow’ which will serve as the execution row for my sequence. I don’t have any computers here called ‘ExecRow’. This row is strictly for BatchPatch to use for the advanced multi-row queue sequence.

  3. Now I’ll select my ‘ExecRow’ and click ‘Actions > Job Queue > Create/modify advanced multi-row queue sequence‘. I’ve titled my sequence “NovemberTutorial”. I use the ‘Create Sequence Execution Row‘ option for my ‘ExecRow’. Then I click “Apply values to selected row(s)“.

  4. For the 9 hosts that will be members in this sequence, now I just need to apply the sequence position number to each of them. The sequence name must be the same as what I used for the execution row. It’s the sequence name that tells BatchPatch which execution row applies to which target computers, so you must apply the same sequence name to all target hosts that you want to be part of the same sequence. In the screenshot below you can see that I have applied the sequence name “NovemberTutorial” to all of the rows. I have set a sequence position number 1 to host1, host2, host3. I have set the sequence position number 2 to host4, host5, host6. And I have set the sequence position number 3 to host7, host8, host9.

  5. Now all we have to do is execute the sequence. To execute the sequence on-demand, simply select the ‘ExecRow’ and use ‘Actions > Job Queue > Execute advanced multi-row queue sequence‘. However, if you want to setup the sequence to run as a scheduled task, simply select the ‘ExecRow’ and use ‘Actions > Task Scheduler > Create/modify scheduled task‘. Then in the task drop-down menu use ‘Execute advanced multi-row queue sequence‘. And of course make sure to enable the scheduled using the timer/clock icon in the upper right corner of the BatchPatch window (green is enabled, red is disabled).

    6. When the sequence executes, first host1, host2, and host3 will begin their patch and reboot process. After all three machines have completed their job queues and come back online after the wait period we specified in the job queue, host4, host5, and host6 will begin processing. When those three complete and are all back online, then finally host7, host8, and host9 will begin processing.

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

Excluding Specific Dates or Date Ranges from Recurring Scheduled Tasks

By Scott | Published: November 11, 2021

We recently received a question from a user who has scheduled tasks configured in BatchPatch to run with recurrence set to ‘Monthly (2nd Tuesday) + 4 days‘. He asked how he can effectively exclude the entire month of December so that none of the recurring scheduled tasks run in December.

Now, of course if you don’t want your recurring scheduled tasks to run during December you can simply disable the scheduler, or if you’re running grids inside the BatchPatch service instance then you can remove grids from the service instance altogether during December. However, there’s another option to accomplish the same goal that enables you to add exclusion dates or date ranges to your job queues. Effectively speaking your scheduled tasks will still run, but they can be configured to execute job queues that will terminate or branch based on DateTime.

For example, let’s say that your existing recurring scheduled task executes a job queue with the following steps:

1. Label:BEGIN
2. Check for available updates (with filters applied)
3. If most recent 'Check for available updates (with filters applied)' found 0 updates, terminate queue
4. Download and install updates + reboot always
5. Wait 10 minutes
6. Wait for host to be detected online
7. Goto label:BEGIN

And let’s say you want to modify the job queue so that no updates are ever installed during December 2021. You could change it to the following steps, where you terminate the queue if the queue runs during December:

1. Label:BEGIN
2. If this step is executed between DateTimeBEGIN <Wednesday - 12/01/21 - 00:00> and DateTimeEND <Friday - 12/31/21 - 23:59>, terminate queue
3. Check for available updates (with filters applied)
4. If most recent 'Check for available updates (with filters applied)' found 0 updates, terminate queue
5. Download and install updates + reboot always
6. Wait 10 minutes
7. Wait for host to be detected online
8. Goto label:BEGIN

Or alternatively you could do something like this instead, where instead of terminating the queue if it runs in December you have the queue goto:DECEMBER, so that you can perform whatever actions you want to perform if the queue runs in December:

1. Label:BEGIN
2. If this step is executed between DateTimeBEGIN <Wednesday - 12/01/21 - 00:00> and DateTimeEND <Friday - 12/31/21 - 23:59>, goto label:DECEMBER
3. Check for available updates (with filters applied)
4. If most recent 'Check for available updates (with filters applied)' found 0 updates, terminate queue
5. Download and install updates + reboot always
6. Wait 10 minutes
7. Wait for host to be detected online
8. Goto label:BEGIN
9. Label:DECEMBER
10. <Insert desired December actions here>

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