Remote .MSI (or .MSU / .MSP) Package Deployment to Multiple Target Computers

By Scott | Published: August 26, 2019

If you have a .MSI package that you need to deploy to numerous computers, it’s very easy to accomplish this with BatchPatch. The great thing is that not only does it only take a moment to create the deployment, when you are ready to execute the process you can do it for as many target computers as needed, all at the same time.

  1. Start by adding the target computers to your BatchPatch grid. You can drag and drop a list of computers onto the grid to populate it, or you can use one of the ‘Grid > Add hosts‘ options to get the host names into the grid by whichever method works best for you. This includes the ability to synchronize your grid with Active Directory organization units or security groups.

  2. With the computers added to the BatchPatch grid you may now create the deployment. Note you could also create the deployment before adding the computers, and then just save the deployment for later. It doesn’t make a difference. In this case though we’ll highlight the targets in the grid and then click on ‘Actions > Deploy > Create/modify deployment‘
  3. In the Deployment window you’ll need to click on the browse button (…) to locate the .MSI file on your computer. If the .MSI file is a standalone package that does not require any additional files, then there is no need to tick the checkbox for ‘Copy entire directory contents‘. However, if the .MSI package comes in a folder with various other files that are required by the installer during the installation process, then in order to get all of those files to the target computer, use the ‘Copy entire directory contents‘ checkbox. The idea here is that you’ll put the .MSI file and all required files in a single folder. Select the .MSI in the ‘Exe,msi,cmd,etc‘ field, and then check the ‘Copy entire directory…‘ box. When the deployment is executed BatchPatch will copy the entire folder, including the .MSI file and everything else contained in the same folder. This way all of the files will be available on the target computer when the execution of the installation occurs. If the installer might trigger a restart, consider checking the ‘/norestart‘ checkbox if you need to prevent that from happening. And of course you can certainly always initiate a reboot from within BatchPatch at a later time, if needed or desired.
  4. We’re nearly done already. Pretty quick and simple, right? At this point if you want to save the deployment for future / later usage, just click on the double-arrow ‘>>‘ button. You’ll see an entry appear in the ‘Saved Deployments’ grid on the right side of the window. Alternatively you can choose ‘Execute now‘ which will start the deployment for all of the currently selected computers in the grid. Or you can choose ‘Apply deployment to row(s) without executing‘, which will put the deployment configuration options into the corresponding fields for each selected/highlighted row. This essentially just gives you another way to execute the deployment later or as part of a job queue without saving the deployment to the ‘Saved Deployments’ grid.

    NOTE: We always recommend testing a deployment on a single computer before trying it out on many computers.
Posted in Blog, General, Tutorials | Tagged , , , , , | Comments closed

Windows Update: Error 1611/1620: -1073741502. Failure

By Scott | Published: August 14, 2019

A BatchPatch user recently reported a new error that we had never encountered before. It comes in two flavors, depending on whether the action was executed with integrated security or alternate logon credentials:

Windows Update: Error 1611: -1073741502. Failure
Windows Update: Error 1620: -1073741502. Failure

You may also see something like this screenshot, likely with a corresponding entry in the Windows application event log, though not necessarily.

Note, to review the event log on the BatchPatch computer click on ‘Start > Run‘ and then type ‘eventvwr‘ without the quotes.

Then in the left-side pane of the Event Viewer window, expand Windows Logs and then select Application to view the application event log.

What does this error mean?

HRESULT -1073741502 C0000142 STATUS_DLL_INIT_FAILED

When it comes to memory allocation in Windows, there is a system heap for all system processes, a desktop heap for all user processes running under a particular interactive logon session, and then there is also non-interactive desktop heap for processes that run in a non-interactive session. The interactive session is the logon session that you are literally interacting with when you are using your computer– the session where you have applications visible in front of you. Non-interactive sessions are for processes that run outside of the interactive session, like the BatchPatch service instance. It may be possible under certain circumstances to exhaust the available heap memory, particularly in a non-interactive session, which subsequently may cause the aforementioned error to occur.

While this error is exceedingly rare (we have only ever had a single report of it), if you encounter this error it is most likely going to be due to a resource allocation limitation on the BatchPatch server at the time of execution. Specifically it’s likely to be caused by not enough allocated non-interactive heap memory. As a consequence of the resource limitation, at least one DLL required for the application (in this case PsExec) to run fails to initialize. It’s likely that you would only ever encounter this error when running BatchPatch as a service because the default interactive heap size is significantly larger than the default non-interactive heap size. The non-interactive heap, which is used by the BatchPatch service instance, is therefore much more likely to run out of space. To be clear, the issue is not likely to be caused by there not being enough physical RAM in the system. Rather, the issue appears to occur because of how Windows is configured by default to allocate the heap memory.

Resolution steps:

There is a registry value that controls how much memory is allocated to each of the three heaps in Windows. More details here: “Out of Memory” error message appears when you have a large number of programs running

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

The registry value above contains a parameter for SharedSection that will look something like this: SharedSection=1024,20480,768

The numerical values 1024,20480,768 define the memory, in KB, that Windows allocates for the system, desktop, and non-interactive heaps, respectively: SharedSection=[system],[desktop],[non-interactive]

If you encounter the error mentioned in the title of this posting while running BatchPatch as a service, try increasing the size of the non-interactive heap in Windows. I wouldn’t suggest increasing it to an arbitrarily determined very large number. Instead try increasing it enough to resolve the issue without going way overboard. On my system if this were occurring, as a first test I would probably try changing it from 768KB to 2048KB (SharedSection=1024,20480,768 to SharedSection=1024,20480,2048) and then see how it goes.

Posted in Blog, General | Tagged | Comments closed

Applying Windows Security Updates to Air-Gapped Systems

By Scott | Published: July 31, 2019

BatchPatch provides two basic methods for applying updates to so-called “air-gapped” systems that are isolated from the rest of the world. Patching systems in isolated networks has always been both a challenge and a pain because you can’t simply follow your normal/typical procedures to get updates applied to these systems. Air-gapped systems virtually always have stricter security in place and more rules setup to prevent unauthorized access. Additionally, the systems themselves often tend to be the operating backbone of various other high-security systems or services, so they have an especially critical role just by virtue of what they do. The irony here is that the computers on these air-gapped networks are isolated specifically to create and facilitate a higher level of security, but at the same time the fact that they are isolated on a segregated network makes them harder to keep updated… and keeping systems updated is of paramount importance to keeping them as secure as possible. It’s a bit of a catch-22. You isolate the systems to make them harder to penetrate and more secure, but in isolating them you also make them harder to update… but keeping them updated is something that helps keep them secure.

All of the BatchPatch cached mode and offline update options are described in more detail here: Cached Mode and Offline Updates

2016-10-11-15_54_31

In the case where you have to apply Windows security updates to systems that are not connected to the internet or a WSUS your two options for using BatchPatch to complete this task can be broken down as follows:

Method A: Determine which updates are needed by the target computers, and then download just those particular updates on an internet-connected computer. Then transfer the cache of downloaded updates to the offline / air-gapped network. Then apply the updates to the target computers.

Step-by-step tutorial for option A: Patching an air-gapped environment with less stringent security rules

Method B: Without first determining which particular updates are needed by the target computers, use an internet-connected computer to download *all* possible updates that could be needed. Then transfer the cache of downloaded updates to the offline / air-gapped network. Then apply the needed updates to the target computers.

Step-by-step tutorial for option B: Patching an air-gapped environment with strict security rules

Why two different methods?

Method A requires first scanning the offline computers to discover which updates they need installed. When this operation is performed BatchPatch will produce a list of updates and URLs. That list has to then be moved to a computer that has internet access so that BatchPatch can process the list and download all of the needed updates. Once the updates have been downloaded they can then be moved to the offline network for consumption by target computers. The problem with this approach is that in some cases the security rules for the isolated network prevent/disallow people from taking *anything* from the isolated network to a different network, even if it’s just a text file list of updates and URLs. In other cases the rules might allow for such a file to be removed from the offline network, but doing this would require a whole change management process to be initiated, and the bureaucratic overhead of this option might simply make it more of a pain than anyone wants to deal with, especially if it needs to be done on a regular basis every month or two or three.

Method B does not require for any files to be taken from the air-gapped network, so it can be more convenient. However, the downside of method B is that since you don’t determine in advance which updates are needed by the air-gapped systems, you have to download *all* of the possible updates that could be needed. Since this could end up being quite a few updates it will take more time, more bandwidth, and more storage space.

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

Single-Click Update Plus Reboot of All Virtual Machine Guests and the VM Host They Reside On

By Scott | Published: July 22, 2019

It seems that everyone always wants to automate everything these days. Sometimes it almost feels like sysadmins think that their credibility hinges on their ability to automate something. However, in reality I think there are times when more automation makes sense, but there are also times where automating something isn’t the best idea or isn’t worth the initial effort required to get something running smoothly via automation. It all depends on the particular situation, so I make no judgement today about whether or not you should be automating any particular processes in your environment. Instead let’s just talk about one very specific situation where I think automation can be nice, can save some time, and can be easy and quick to setup.

If you are responsible for applying Windows Updates to numerous virtual machine guests and hosts, you have probably dealt with the annoyance of trying to coordinate the updating of the guests with the hosts. The thing with updating VMs is that while there is nothing special or different that goes into applying updates to and rebooting VM guests, when it comes to updating and rebooting the VM host computers you have to be careful that you don’t initiate a reboot of the host while guest VMs are still working on their updates in one way or another.

Optimally you would first update all guest VMs, and then when they are all complete only then would you begin the process of updating and rebooting the host computer. However, if you are dealing with many hosts, each of which contains numerous guests, and if you’re dealing with a small maintenance window, it can be very difficult to stay on top of everything so that you can initiate a host update + reboot process as soon as possible after all guests running on that host have completed. However, with BatchPatch this process is actually pretty simple to automate so that you can launch it with a single click on numerous guests and hosts. Wouldn’t it be nice if you could, in a single click, launch the update and reboot process on numerous guest VMs AND their host operating systems too?

There is more than one way to do what I’m about to describe, but the way that I’ll demonstrate now is my favorite method for this particular situation. Obviously you don’t have to follow this exact method if you have a modified version that works better for you in your environment. In this case we’re going to configure a BatchPatch advanced multi-row queue sequence, which is basically an orchestration tool that enables us to execute actions on multiple inter-dependent computers. And we can trigger different computers in the group to perform various actions based on the completion of actions that run on other computers in the group. The goal here is going to be to create a single-click action that will launch the Windows Update process on all VM guests that reside on a single VM host, and then when the guests are done updating, the VM host will update and reboot. When the VM host reboots, guests are configured to automatically shutdown on physical host shutdown, and then startup again automatically on physical host startup.

  1. For this tutorial we will configure the VM guests in question to automatically shutdown when the physical VM host shuts down. Similarly we’ll configure the VM guests to automatically start when the physical VM host starts up. In your VM settings you can either do the same thing, or if you don’t want your VM guests to have these settings, then you would need to modify the tutorial steps accordingly to create your own single-click method for accomplishing the same end result. In Hyper-V you can modify an individual VM guest’s startup and shutdown settings in the settings titled “Automatic start action” and “Automatic stop action.” For this tutorial we want our VMs to be shut down when the physical computer shuts down, and we want the same VMs to start automatically when the physical computer starts. So we configure the two aforementioned settings accordingly.
  2. After you have configured your VM guest settings to automatically shut down and startup when the physical host OS shuts down and starts up, then you can create your BatchPatch advanced multi-row queue sequence. In BatchPatch select the guest VM rows and apply a regular job queue with just one step to ‘Download and install updates’. Then select the host VM row and apply a regular job queue with just one step to ‘Download and install updates + reboot always’. See screenshot below for reference. You can follow this tutorial for creating job queues. In this case you’ll just need to use the option in the Job Queue creation process to ‘Apply queue to row(s) without executing’.
  3. Next highlight the VM guest rows in the grid and select ‘Actions > Job Queue > Create/modify advanced multi-row queue sequence’. Give your sequence a name, and then set the sequence position number of all the VM guests on a particular VM host as position number 1.
  4. Next set the sequence position number of the VM host machine’s row in the grid to position number 2.
  5. Lastly add a new row to the grid to serve as the ‘Execution row’ for the sequence. This new row can be a “dummy” because it’s only purpose will be to act as a sequence execution row. The important part with all of these Advanced multi-row queue sequence settings is that each sequence has to have a unique name. It’s the name that makes different rows in the grid participate in the same sequence. And since we want this sequence to operate on the guest VMs and how computer, we set each row to have the same sequence name. And the same goes for the execution row that we create. In order for our execution row to operate on our sequence, it has to have the same sequence name as the rows that will be included in execution of this sequence. I have used the name ‘TutorialSequence1’.
  6. That’s actually all there is to the creation/configuration part. Now you can execute the sequence on-demand (or via scheduled task). To execute the task on-demand simply highlight the execution row and select ‘Actions > Job Queue > Execute advanced multi-row queue sequence’. Doing this will instruct BatchPatch to do the following:

    Download and install updates on all guest VMs, simultaneously. These three guest VMs were assigned sequence position number 1. All hosts in sequence position number 1 will execute their assigned job queue steps. Then only when *all* of the hosts in sequence position number 1 have completed their job queues will sequence position number 2 begin, which in this case is the update + reboot of the physical VM host computer. The host will apply Windows updates and then reboot. And since our guest VMs have been configured to shutdown when the host shutsdown and to startup when the host starts up, once the host has come back online, all of the guests will also come back online. All guests and hosts will have applied their Windows Updates and rebooted, and the entire action was triggered with just a single-click in BatchPatch. And of course the single click can even be scheduled via the Task Scheduler.
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

The Best Windows Patching Software

By Scott | Published: July 16, 2019

When it comes to patching and updating the Windows operating system in a business environment, there are a lot of options to choose from. Regardless of whether you have a smaller business with fewer computers to manage or larger business with hundreds or thousands of machines, you still need a good solution to help keep your computers up to date without costing you too much time or pain (or money!).

Why BatchPatch?

  • Lightweight: BatchPatch does not require a lot of resources to run. It’s a stream-lined application that enables you to just get things done quickly, easily, and painlessly.
  • Easy setup/configuration: In many environments it’s as simple as just launching the app and patching target computers. However, in other environments some configuration may be required to allow BatchPatch to do its thing. In either case it’s very easy and straightforward to configure your environment to work with BatchPatch.
  • Simple to use: Ease of use is a major factor that should be considered when selecting an application for any situation. If the application has a steep learning curve or is generally complicated to operate, the time and cost to get the most out of it will be increased. We intentionally designed BatchPatch to function intuitively so that it doesn’t require hours or days or weeks to learn and get used to. Most BatchPatch users will find that they automatically understand how to operate it almost instantly. Even for the features that require a bit more effort to learn, they are still very simple to use overall, and we have numerous tutorials on our website to guide you.
  • Powerful: It doesn’t matter how simple an application is to use if it’s not powerful enough to do what you need it to do. BatchPatch has all the patching power you need whether you’re responsible for 50 computers or 1000+ computers.

The Best Windows Patching Software

BatchPatch core features and functionality

  • Initiate the download and / or installation of Windows updates with real-time monitoring on target computers– standalone, in a workgroup, or domain members, including options for computers that have access to a WSUS, the internet, or for computers that are completely offline without access to either. Standard mode tutorial. Offline mode.
  • Deploy third-party software / updates to target computers
  • Execute scripts remotely on target computers
  • Reboot, shutdown, wake on LAN functionality
  • Job queues for executing multiple tasks sequentially on hosts
  • Advanced sequences for orchestrating complex dependent operations across multiple targets
  • Scheduled tasks as well as on-demand operation
  • Retrieve inventory information from targets
  • AND MUCH MORE!
Posted in Blog, General, Topics | Tagged , , , | Comments closed

Using BatchPatch to Deploy Software to Multiple Remote Computers

By Scott | Published: July 2, 2019

In addition to being a great tool for initiating Windows update processes on remote computers, BatchPatch can also simplify the task of deploying / installing third-party software on numerous target computers. The process is generally very simple with three basic steps:

  1. Identify the silent / quiet parameter for the installer package that you plan to deploy. In order to perform a remote installation, you need to determine the proper command for making that installation occur without any user interaction. These types of installations are generally called silent or quiet because the user doesn’t get prompted to respond to any dialog windows. Instead, the administrator is able to execute a command to install the software without any additional interaction. We have more details and information at the following link about silent parameters for software deployments and how to determine what the silent parameter is for a given software installer package.

    Understanding and Discovering the Silent Parameters Required to Remotely Deploy Software with BatchPatch

  2. Create your deployment configuration in BatchPatch. At the following link you’ll find numerous tutorials that demonstrate how to create and execute BatchPatch software deployments. Regardless of whether your installer setup package is in the form of .exe, .msi, .msp., .msu, or some other format, we’ve got you covered. You can use BatchPatch to deploy software like Firefox, Chrome, Adobe Flash or Reader, Skype, Notepad++, 7-zip, and virtually any other application. You can even use BatchPatch to deploy and execute scripts on remote computers or apply registry keys or retrieve system information as well as perform numerous other tasks.

    Software Deployment with BatchPatch

  3. Execute your deployment. After you create the deployment configuration in BatchPatch all you really need to do is select the desired target computers, and then execute the installation. Each of the tutorials listed in this link includes complete instructions for creating and executing a deployment. We also have a video tutorial that demonstrates creating and executing a deployment in BatchPatch.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Remotely Installing Windows Feature Update Version 1903 (the ‘May 2019 Update’)

By Scott | Published: June 25, 2019

To install Windows 10 feature update 1903 (as well as the other Windows 10 feature updates) remotely using BatchPatch, you should follow the process outlined below. The standard, built-in Windows update actions in BatchPatch will not work to install these feature updates. Also note FYI even though these are “feature updates” they are actually technically classified as “upgrades” by the Windows Update Agent. The update classification is probably not relevant for the administrator to be aware of in most situations, but I did just want to highlight that in case it comes up when you are researching. EDIT: Starting with the April 2020 release of BatchPatch, feature updates can also now also be installed using the normal Windows update actions, though cached mode must be disabled in order for that to be successful.

  1. Download (from Microsoft) the Windows 10 Media Creation Tool. Use this link to download the media creation tool directly from Microsoft. At the time of this writing 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 1903 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 from an account that is logged on without admin privileges. For whatever reason, 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 have no idea why Microsoft made the tool work this way, but it’s what they did. 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. Since you are following this tutorial with the intention of learning how to to use BatchPatch to update other PCs, 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 a little while because it’s in the range of 4GB.

  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

An Alternate Way to Deploy a Registry Value to Remote Computers

By Scott | Published: June 17, 2019

In the past I demonstrated how to use BatchPatch to deploy registry changes to multiple remote computers. For your reference those tutorials are available at the following links:

Remote Registry Updates with BatchPatch

Deploy Registry Keys to Multiple Computers Using BatchPatch

Deploying a Registry Key / Value to HKEY_CURRENT_USER (HKCU) or All Users in HKEY_USERS (HKU)

Today I’m going to show you another simple way that you can use to create or modify the registry on multiple remote target computers, using BatchPatch. This method is very simple. Essentially we are just going to use the ‘REG ADD‘ functionality that exists in Windows, but we are going to use BatchPatch to remotely execute that functionality on the desired target computers. Microsoft has documentation for ‘REG ADD’ at this link. If you plan to use this method, you’ll almost definitely want to read through that documentation before you begin. You’ll use the instructions in the documentation to create the actual string that you’ll input into BatchPatch for remote execution. In this example the REG ADD command does all the work of creating/modifying the desired registry key/value. BatchPatch in this case is simply providing you with a simple method for remotely executing the command on numerous remote computers.

For this tutorial we are going to set the value of the ‘Start’ DWORD under HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR to 3. The REG ADD command to accomplish this is:

REG ADD HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR /v Start /t REG_DWORD /d 3 /f

IMPORTANT: Aside from making sure that you create the correct syntax for the desired registry key/value to be applied to target computers, the most important component of the command above for running remotely from inside of BatchPatch is the ‘/f’ parameter. The reason for this is because the /f instructs the target computer to skip any confirmation prompts that would otherwise popup invisibly and prevent the command from completing. Under normal circumstances if you were to execute the REG ADD command at the cmd prompt of a given computer, it would prompt you to confirm that you want to proceed. However, if you run the same command remotely with BatchPatch, the confirmation prompt will not be visible. This will cause the command to hang indefinitely without ever completing. So, in order to ensure that the command proceeds without any kind of confirmation prompt, you need to add /f to the end of it.

  1. The most important step of this process is to make sure that your command does what you want it to do without actually using BatchPatch. That is to say that you need to run the command at the cmd prompt of a test computer to make sure that it inserts the desired registry key/value, and make sure that it does not prompt for confirmation after it is executed. Once you confirm that the command does what you want it to do, then you are ready to insert that command into BatchPatch for remote execution on numerous systems.

  2. At this point you should have already tested your REG ADD command at the cmd prompt of a test computer. Now that it works as desired, all you need to do is add it to BatchPatch. For this we’ll use a BatchPatch remote command. Highlight the desired target computers in your BatchPatch grid, and then select ‘Actions > Execute remote process/command > Create/modify remote command 1’. You can actually use any of the remote commands 1, 2, 3, or 4 to accomplish this, but for this tutorial we’re just using 1.
  3. Copy and paste your command into the BatchPatch remote command window.
  4. The last thing to do is execute the command. When you do this BatchPatch will connect to all of the highlighted target computers in the grid, and it will submit this command to be executed on all of those machines. That’s all there is to it.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Orchestrating Complex Update And Reboot Sequences Involving Multiple Target Computers

By Scott | Published: June 4, 2019

BatchPatch has a unique capability that we call the ‘Advanced multi-row queue sequence‘. Admittedly the name of this functionality isn’t its best feature, but we chose to name it for exactly what it is and what it does rather than a fancier name that would be less descriptive. 🙂

The advanced multi-row queue sequence is essentially an orchestration feature that enables you to have an unlimited number of distinct computers participate in a singular sequence such that you can control the update and reboot process (or any custom script execution or deployment etc) so that a particular order of events is preserved across all of the systems that are included in the sequence.

Let’s break this down a bit. BatchPatch has a more basic automation functionality called the ‘Job Queue‘. The job queue in BatchPatch enables the administrator to execute a queue of different tasks on a given target computer (or on a group of target computers). So for example with the job queue you might instruct a target computer (or a group of computers) to download and install updates, then reboot, then wait 10 minutes, then make sure that the computer is online, then execute a custom script, then initiate another reboot. The job queue enables you to create a single-click task that executes the entire queue on the desired computers. However, what if you have multiple computers, and each computer has its own customized job queue, and you want to create a sequence that instructs each target computer to execute its own custom job queue in a particular sequence such that certain computers execute their assigned queues first, followed by a second set of computers executing their assigned queues, followed by a third set of computers executing their assigned queues, and so on. This is where the advanced multi-row queue sequence comes in to play. While a job queue applies to each independent computer separately, the advanced multi-row queue sequence enables you to orchestrate a process that involves each computer executing its own custom job queue within a larger multi-computer sequence.

Job Queue Example:

Instruct computer1, computer2, and computer3 to each execute the following list of actions:

  • Download and install updates + reboot
  • Wait 10 minutes
  • Wait for host to be detected online
  • Download and install updates + reboot

Advanced Multi-Row Queue Sequence Example:

Instruct computer1, computer2, and computer3 to each execute the following list of actions:

  • Download and install updates + reboot
  • Wait 10 minutes
  • Wait for host to be detected online
  • Download and install updates + reboot

Then when all actions have completed for computer1, computer2, and computer3, instruct computer4, computer5, and computer6 to each execute the following list of actions:

  • Execute a custom script
  • Wait 10 minutes
  • Download and install updates + reboot
  • Wait 10 minutes
  • Wait for host to be detected online
  • Execute a custom script

Then when all actions have completed for computer4, computer5, and computer6, instruct computer7 to execute the following list of actions:

  • Reboot
  • Execute a custom script

Summary and Tutorials:

So, while the job queue enables you to execute a set of actions on a target host (or multiple target hosts), the advanced multi-row queue sequence enables you to orchestrate a group of target computers to each execute a defined queue of actions (each computer can have its own separate queue of actions to execute) within a larger sequence, allowing you to control the ordering of which target computers execute their queues in which position of the overall sequence.

We have a number of tutorials that demonstrate various uses of the advanced multi-row queue sequence, including a video tutorial to help you better understand how it all works and when you might want to use it:

Advanced Multi-Row Queue Sequence – Video Tutorial

Virtual Machine Guest + Host Update and Reboot Sequence Automation

Custom Update And Reboot Sequences for Multiple Computers

Advanced Multi-Row Queue Sequence – Contingent Operations with Custom Scripts

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

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

Using BatchPatch Standalone Without WSUS

By Scott | Published: May 28, 2019

If you are using BatchPatch in a standalone configuration without a WSUS server, there are a few things to be aware of.

  1. The first order of business is to configure your environment to work with BatchPatch. Please review the Getting Started page. Make sure that you can successfully run the BatchPatch action ‘Windows updates > Check for available updates’ on target computers. Generally if that action is functioning properly, all other actions in BatchPatch should also function properly.

  2. If your goal is to use BatchPatch to handle the process of downloading and/or installing updates on your computers, you’ll want to configure those computers to *not* automatically download and/or install updates on their own. There is a group policy that you should set on those computers if they are part of a domain. If they are running standalone (not part of a domain) then you’ll want to set the same local policy on each target computer. The behavior of this setting varies slightly depending on which operating system is running, but regardless 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 them from installing on their own so that you can instead trigger the install from BatchPatch. 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 but use BatchPatch for the installation, then set the value to 3.

  3. Next you’ll need to decide the source for the Windows updates. Since you aren’t using a WSUS as the source, your source is going to be either ‘Windows Update’ or ‘Microsoft Update.’ The default behavior in Windows is to use ‘Windows Update’ as the source. However, if you go into the Windows Update settings in the control panel of a target computer you can see there is an option that says something like this, depending on the OS: ‘Give me updates for other Microsoft products when I update Windows’. If you tick that box, then you are enabling ‘Microsoft Update’ on that computer. Windows Update provides updates for just Windows operating systems, while Microsoft Update provides updates for Windows operating systems PLUS updates for other Microsoft applications.

    In BatchPatch under Tools > Settings > Server selection you’ll see three different options:

    Default / Managed: Uses the target computer’s existing configuration to determine where to search for updates. If you leave BatchPatch set to ‘Default / Managed’ then it will use whichever setting is applied on the target computers for the update source. If the update source is *not* set in Group Policy to a local WSUS, then the update source will be ‘Microsoft Update’ if on the target computer you have ticked the ‘Give me updates for other Microsoft products when I update Windows’ box. If you leave that box unticked then the update source will be ‘Windows Update’.

    Windows Update: Bypasses the target computer’s configuration and searches for updates on Microsoft’s public server. Includes only Windows updates.

    Microsoft Update: Bypasses the target computer’s configuration and searches for updates on Microsoft’s public server. Includes Windows updates AND updates for other Microsoft products. Before using Microsoft Update, target servers must be opted-in to the service. If you have ticked the box ‘Give me updates for other Microsoft products when I update Windows’ then you have opted-in that target computer. If you do not tick that box individually on each target computer, then you may use BatchPatch to remotely tick that box on each target by executing ‘Actions > Windows Updates > Opt-in…’ one time.

  4. If you will be applying updates to computers that do not have internet access, please review the various options that BatchPatch provides for cached mode and offline updates.

Additional Tutorials for Using BatchPatch without a WSUS

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