Quantcast
Channel: BatchPatch – The Ultimate Windows Update Tool
Viewing all 261 articles
Browse latest View live

The Best Windows Patching Software

$
0
0

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!

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

$
0
0

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 living on that host have completed. However, with BatchPatch this process is actually pretty simple to automate so that you can launch the process 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.

Applying Windows Security Updates to Air-Gapped Systems

$
0
0

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.

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

$
0
0

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.

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

$
0
0

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.

Clarifying the Confusion Surrounding Optional Updates for “Seekers”

$
0
0

Beginning with Windows 10 and Windows 2019 build 1809, Microsoft began pre-releasing some updates in advance of their formal release date. This has created a fair amount of confusion both for our users as well as for Windows users around the globe, so today I wanted to take a few minutes to try to clarify what’s going on.

As an example let’s look at the July 2019 cumulative update: “2019-07 Cumulative Update for Windows Server 2019 (1809) for x64-based Systems (KB4507469) (2019-07-09) – Security Updates.” This update was released on July 9, 2019, which was the Microsoft Patch Tuesday (second Tuesday) for that month. It was released in the ‘Security Updates’ classification through the normal update release channels: Windows Update, Microsoft Update, and Windows Server Update Services (WSUS). BatchPatch would find/download/install this update, as expected.

KB4507469

https://support.microsoft.com/en-us/help/4507469/windows-10-update-kb4507469

If you were to install the update (along with whatever other updates were available at the time), and then if you subsequently used BatchPatch to check for available updates again, you would find no more applicable updates available for download/install. However, if you then waited until July 22, 2019, and on that day or soon after (but prior to August 2019 Patch Tuesday) you visited the Windows Update control panel directly on the target computer and clicked on the ‘Check for updates’ you would notice that Windows would download and install a different cumulative update: “2019-07 Cumulative Update for Windows Server 2019 (1809) for x64-based Systems (KB4505658) (2019-07-22) – Updates.” This July 22 cumulative update was released *NOT* in the ‘Security Updates’ classification but rather in just the ‘Updates’ classification. Furthermore, if you used BatchPatch to scan for updates on that target system, BatchPatch wouldn’t have found the KB4505658 as applicable for installation. So, what’s the deal?


KB4505658

https://support.microsoft.com/en-us/help/4505658/windows-10-update-kb4505658

If you scrutinize the links and images above you’ll notice that the ‘Available’ and ‘Next Step’ columns of the charts that Microsoft posted are not the same for the two updates. What Microsoft is doing (and has been doing since the release of build 1809 for Windows 10/2019) is release the normal cumulative security update on Patch Tuesday of each month to all release channels, but then later in the same month they release a new cumulative non-security update, but they do not release it to the the normal release channels. Instead they only release it to those who they consider “Seekers” — people who actively go to the Windows Update control panel on a computer and click on the ‘Check for updates’ button. In this case the way it usually manifests in the GUI is that there are no available updates visible until *after* you click on the ‘Check for updates’ button. Furthermore, it seems to be the case that you need to sometimes actually click on this button more than one time before it triggers the search that finds these optional “Seeker” updates. The content of each of these optional updates gets released as part of the following month’s normal/regular cumulative update, which makes these “Seeker” updates essentially like a “Preview” update. Microsoft does not use the term “Preview” per se, but they are nevertheless a preview of what is to come in the following month’s normal Patch Tuesday update release.

With all that said we do not recommend installing these optional updates. Unless you have a specific need for one of these updates (they may contain a fix for something that you need but they will never contain security/critical updates), we generally do not recommend installing them. We believe that unless you have a specific need for a fix that is included in one of these updates, it usually makes the most sense to wait until the following month when Microsoft moves them from optional status to the normal deployment channels.

At the time of this writing (September 2019) BatchPatch does not provide a facility to find/download/install these optional updates, but in the next release of BatchPatch (coming late 2019) we do expect to include such functionality just so that it’s there if you need/want it. In the meantime if you ever have a specific need for one of these updates in between the time that they are released as optional and the time that they are published to the normal release channels (typically just a couple/few weeks later), you would need to either visit each target computer’s Windows Update control panel manually to trigger the download/installation, or you could download the update from the Windows Update catalog for deployment via BatchPatch’s deployment feature. In the next release of BatchPatch you’ll be able to use its normal Windows Update actions with a separate configuration option selected to find the optional “Seeker” updates.

How to Convert HRESULT Decimal (DEC) Values to Hexadecimal (HEX)

$
0
0

How to convert HRESULT decimal values to hexadecimal

In the Windows operating system, when an exception is generated it is delivered with an HRESULT value. The HRESULT value is essentially a “reason code” that describes the underlying cause of the exception. In BatchPatch the HRESULT values are generally included in the text of any error, but HRESULTs will be in decimal format, which is not always optimal. In order to figure out what they mean we sometimes need to convert them to hexadecimal first. It’s especially the case for google searching the HRESULT value. If you enter a DEC HRESULT into google you probably won’t find much, but if you convert it to HEX first and then search the HEX value you’ll end up with more useful results, which in turn means you’ll likely have a much higher degree of success in figuring out what it means. The easiest way to perform the DEC to HEX conversion is with your Windows calculator app. Go to ‘Start > Run‘ and type calc.exe to launch the Windows calculator application. Once it is open, switch to the ‘Programmer’ calculator by clicking the button in the upper left corner of the calculator window, and then choose ‘Programmer’ from the drop-down menu.

In the Programmer calculator select DEC by simply clicking on it. With DEC selected, copy your HRESULT value to the clipboard (CTRL-C), and then paste the value from the clipboard into the calculator (CTRL-V). Yes, you can type it manually instead of using copy/paste, but just note that the HRESULT values are negative integers. Therefore if you type a positive integer into the calculator, the conversion will be incorrect, so you must type the complete HRESULT value with the negative symbol. It’s usually easier to just copy and paste it. Once you’ve done that you can immediately then see the HEX value appear directly above the DEC value in the calculator. In this example I’ve pasted DEC value -2147012867, and we can see the HEX value is 80072EFD.

Once you have the HEX representation of the HRESULT, you can look it up here to see what it means: Windows Update Error Code List. Unfortunately that list isn’t a complete list of every possible HRESULT, so if you don’t find it in that list try entering it into a google search to see what comes up. You may also enter it into the search box in the upper right section of this page as well as in our support forum.

How to Automate Monthly Windows Patching and Updates for Numerous Computers

$
0
0

While it’s true that our favorite way to use BatchPatch is for real-time control of the Windows Update process, it also works great for automating Windows updates and everything that goes along with Windows updates like reboots etc. In fact, BatchPatch is arguably one of the most powerful tools available when it comes to automation of complex sequences, especially around patching. Let’s go through some of the ways you can automate tasks with BatchPatch.

Task Scheduler

It goes almost without saying that in BatchPatch you can schedule nearly any task that BatchPatch can run manually. So, for example, if you want to schedule your target computers to apply Windows updates and reboot at 3AM, that’s very simple to do.

  1. Select all the of the desired computers, then click ‘Actions > Task scheduler > Create/modify scheduled task‘.
  2. In the Task Scheduler window select the desired task from the drop-down menu, and then set the run time and click OK.
  3. Lastly, click the small red clock/timer icon in the upper right corner of the main BatchPatch window to enable the scheduler. If the icon has a small red X on it, it’s disabled. When you click to enable it, the red X changes to a green + sign. Scheduled tasks will only be executed if the scheduler has been enabled.

  4. Note, if you want BatchPatch to execute scheduled tasks even when the application is not open, please check out the run-as-a-service feature.

Job Queue

Not only can you set almost any task in BatchPatch to run at a scheduled day/time, but perhaps more powerfully you can also create a queue of actions to execute on each target computer, and you can optionally schedule that queue to run via the task scheduler at the set day/time. One common way that people like to use the job queue is for executing multiple Windows update + reboot cycles in a row for the situations when Windows is a bit annoying and presents a new update to install only after you have installed the existing available updates and rebooted the computer. In this way you can, if you choose, have BatchPatch automatically download and install updates, then reboot, then download and install updates, then reboot, and repeat as many times as desired.

  1. To setup something like this you would select ‘Actions > Job Queue > Create/modify job queue‘. Then in the Job Queue window you can create a job queue that looks like what I have in the screenshot below. Give it a title and use the double-right-arrow button to save it. Once it has been saved, you’ll see it appear in the drop-down menu in the Task Scheduler window, thus enabling you to schedule the job queue to execute at a specific day/time.

Advanced Multi-Row Queue Sequence

Another great option you have in BatchPatch for automation is the ‘Advanced Multi-Row Queue Sequence’. This feature doesn’t limit you to executing a set of actions on a group of target computers. Instead with the advanced sequence you can actually orchestrate an operation that involves multiple dependent systems. So for example you could have target computers A, B, and C execute a certain set of tasks such as the job queue we created above, and you can use the advanced sequence configuration to ensure that target computers C, D, and E do not start executing their job queues until after all of A, B, and C have completed their queues. And mind you, each of these systems can have its own custom job queue. They don’t need to all be running the same queue. So if you have multiple dependent systems that operate together such that only one can be offline at a time or maybe a group of hosts can be offline at one time but certain other hosts must remain online during that same time, you can use the advanced multi-row queue sequence to create an entire patching/updating/rebooting routine that can be launched with just a single click (or through the Task Scheduler) but that executes actions across multiple systems in a specific sequence. Another use case is for virtual machines when you want to have a single click sequence to download and install updates on the guest computers but wait until all guest computers have completed installing updates before you download and install updates plus reboot the virtual host. Those are just a couple of example, but there are many other potential use cases for the advanced multi row queue sequence. We have tutorials for this feature posted at the following links. Once you have a good understanding of how it works you’ll be able to see how it might help you with various tasks that are specific to your environment:

Advanced Multi Row Queue Sequence – Video Tutorial
Advanced Multi Row Queue Sequence
Virtual Machine Guest Host Update And Reboot Sequence Automation
Custom Update And Reboot Sequences For Multiple Computers


BatchPatch Host Status “LED” Indicator Image Icons

$
0
0

GREEN – online

BLUE – online after reboot (BatchPatch does its best to determine if a host was rebooted by counting the number of ping timeouts that are tracked immediately before a ping success. You can modify this setting in ‘Tools > Settings > Ping Failure Threshold‘)

ORANGE – host doesn’t exist / not found

RED – host offline / ping timed out / destination unreachable

YELLOW – BatchPatch is actively checking to see if the host is online

GRAY – no information

LIGHT PINK-GRAY – disabled from host status check thread

Host Status LED Image Usage / Behavior:

There are 2 ways that the orb icons are colored:

  1. The Host Status Check thread can be set to run in the background all the time. You simply left-click on the LED column header. You can also set it to run automatically if you want, in ‘Tools > Settings > Automatically start host status check on startup‘. However, it is not necessary to have it running all the time, unless that is your preference. See number 2.
  2. When an individual host is pinged (or when it’s rebooted and automatically pinged) by BatchPatch, BatchPatch will set the orb icon color based on the same criteria listed above. Personally, I prefer to leave the host status check disabled at all times so that the orb icon coloring is always controlled by each individual row, rather than by the Host Status Check thread, which runs independently of each row, and operates globally.

Miscellaneous:

  • The Host Status Check thread can be disabled by clicking on the orb icon column header. It can also be disabled from starting up when BatchPatch starts by unchecking the Tools > Settings > Automatically start host online/offline status check on startup.
  • You can reset all the colors by middle-clicking on the orb icon column header.
  • You can color an orb blue, manually, by shift-middle clicking an orb icon. This is handy sometimes when you want to indicate a status of “completed” for a given row, so that you know not to go back to it.
  • You can disable an individual row from the Host Status Check thread so that it will be skipped every time the check thread comes around to it, by middle-clicking the orb icon for a given row. You’ll see that the color becomes a light gray-pink.

October 2019 Version of BatchPatch Released

$
0
0

We released a new version of BatchPatch at the end of last week. Below I’ll explain some of the updates that we made.

  • Added Task Scheduler option to ‘Add/subtract days/hours/minutes to/from next scheduled run time

    We’ve had a lot of requests from users who want to more easily be able to modify existing scheduled task run-times on large numbers of hosts, particularly in cases where they simply need to push back their entire maintenance window due to a scheduling change. The challenge previously was that if they had lots of scheduled tasks configured with various different start times, if they then wanted to push the entire maintenance back by and hour or a day or whatever, there was no easy way to modify all of the different start times without dealing with each separate start time individually. Now BatchPatch includes an option that lets you select the desired hosts and just add or subtract days/hours/minutes to them, thereby enabling you to modify them all at once while still preserving the relative differences between each individual start time. You’ll find this option under ‘Actions > Task scheduler > Add/subtract days/hours/minutes to/from next scheduled run time’.

  • Added the following job queue special items:
    *Enable online cached mode (override global setting for this queue only)
    *Enable offline cached mode (override global setting for this queue only)
    *Disable cached mode (override global setting for this queue only)

    Most of our users operate BatchPatch in either the default operating mode or in offline mode. However, we do have some people using online cached mode. At some point in the not too distant past, Microsoft made a change to how the Windows Update Client works that caused the large cumulative monthly update to no longer download successfully when using online cached mode. One workaround for this problem is to use offline cached mode to install the cumulative update each month. However, for online cached mode users this creates more work because then they have to run BatchPatch on each target in both online and offline cached modes in order to get all the updates installed. By adding the ability to change the mode inside of the job queue on a per-target basis, it’s now possible to automate the process of downloading/installing updates using one mode followed by the other mode inside a single job queue.

  • Added ‘Search for only optional software updates‘ to Windows Update settings

    Microsoft made a change not too long ago that enables “seekers” (their term, not ours) to download/install updates that are not otherwise available through normal update channels. These updates would only be available when manually going into the Windows Update control panel on a given computer to click the “Check for updates” button a couple of times. However, the new version of BatchPatch now enables BatchPatch users to download/install these optional “seeker” updates using BatchPatch, if desired. Read more on this topic here. To find these optional “seeker” updates when using BatchPatch, go to ‘Tools > Settings > Windows Update‘ and tick the box for ‘Search for only optional software updates

  • Added recursive file search to BP cache folder methods for downloading and copying files so that users can re-organize previously cached files into subdirectories, if desired

    This is another commonly requested feature by people who use cached mode. A lot of folks want to be able to re-arrange the update files in the cache folder, but up until now if they were to create subfolders to organize the files, BatchPatch wouldn’t find the files because BatchPatch would only look in the defined cache folder and not in any subfolders. However, now if you want to re-arrange the update files in subfolders you may do so without issue. BatchPatch will search for available updates in the top level cache folder as well as all subfolders, recursively.

  • Added the following menu items:
    *Get list of VMs on Hyper-V host + add to grid directly under host
    *Get list of VMs on Hyper-V host + add to grid at bottom

    I know that most of you virtual machine users are probably using VMWare, not Hyper-V. However, for the Hyper-V people out there, you can now instruct BatchPatch to automatically add the guest VMs that reside on a particular VM host to the BatchPatch grid.

To view the complete list of changes/updates/fixes in the October 2019 release, check out the changelog inside the software under ‘Help > Check for updates > View changelog‘.

Explanation of ‘Reattach Orphaned Windows Update Process’ Feature

$
0
0

There is a menu item in BatchPatch under ‘Actions > Windows updates > Reattach orphaned Windows Update process‘ that contains the following sub-menu-items:

  • Reattach orphan + do not reboot / shutdown
  • Reattach orphan + reboot if required
  • Reattach orphan + reboot always
  • Reattach orphan + shutdown

What is ‘Reattach orphan’ ?

The ‘Reattach orphan’ actions in BatchPatch are for the times where you might have accidentally (or perhaps intentionally) closed the BatchPatch grid while Windows Update actions were still being executed by BatchPatch on target computers. If you are not using cached mode and you have BatchPatch performing a Windows Update action such as “Download available updates” or “Download and install updates” or “Install downloaded updates” etc on target computers… but then you inadvertently close BatchPatch or (gasp!) BatchPatch happens to crash or your computer freaks out or you reboot it or something similar… the Windows Update process will still run on the target computer(s) until it completes. If this happens to you, you can simply re-launch BatchPatch and use one of the above listed menu items to reattach to the remote orphaned process so that BatchPatch can continue to monitor its progress (assuming it has not completed prior to your attempt to reattach), and so that BatchPatch can initiate the reboot or shutdown, if that was part of your original plan.

Example of ‘Reattach orphan’ usage

For example, let’s say that I executed “Download and install updates + reboot if required” on a remote computer, using BatchPatch. Then I closed BatchPatch while it was still running. At that point I could simply re-launch BatchPatch, enter the target host name into the grid, and then I could select ‘Actions > Windows updates > Reattach orphaned Windows Update process > Reattach orphan + reboot if required‘ to continue things as if I had never closed BatchPatch in the first place. If I don’t re-attach to the orphaned process, it will still finish downloading and installing updates, but the ‘reboot if required’ portion will never occur. If I re-attach to the orphaned process, I can re-attach with any of the reboot options listed at the top of this page.

‘Reattach orphan’ is not designed for usage when BatchPatch’s ‘cached mode’ is enabled

Note, if you have cached mode enabled (this includes both online as well as offline cached mode), things work a bit differently, so re-attach orphan won’t necessarily work the same as when cached mode is disabled. The reason for this is that in normal/default online mode, each Windows Update action is a single task that executes on target computers. If you close BatchPatch and then reattach to an orphaned process that is running on the target computer(s), you essentially get to come back right where you left off. However, when cached mode is enabled each Windows Update action is generally comprised of at least two or three separate individual task actions that BatchPatch strings together automatically in a kind of “macro.” This means that if you use ‘reattach orphan’ when cached mode is enabled, the orphaned task that BatchPatch reattaches to might be task 1 of 3 or task 2 of 3, and not necessarily task 3 of 3. BatchPatch will be able to successfully monitor the particular individual task that was orphaned (assuming it is still running when you attempt to reattach to it), but BatchPatch won’t have awareness of the state of original entire macro that was executed. This means that the individual task that was running on the target computer would be able to complete, but the other components of the macro action that the BatchPatch console would normally be responsible for executing would not occur. Therefore in cases like that you would have to re-execute the cached-mode action from scratch and make sure that you leave the BatchPatch window open until the process completes.

Running the Disk Cleanup Tool (cleanmgr.exe) Remotely on Multiple Computers

$
0
0

We recently received a question about how to successfully run the Windows Disk Cleanup Tool remotely using BatchPatch. The user noted that when running cleanmgr.exe in BatchPatch on a target computer, the cleanmgr.exe would stay running indefinitely. This is essentially the same problem that we discuss in numerous places on this website when it comes to silent application deployment. If you execute a remote deployment without specifying the proper silent/quiet installation switch, the installer package attempts to run interactively, which means that it pops up dialog boxes that it expects the user to acknowledge. The problem is that when a deployment runs remotely, it is hidden. No dialog boxes will be seen, and so instead what happens is the deployment appears to hang indefinitely while the package waits for the hidden dialog boxes to be acknowledged.

In the case of cleanmgr.exe, if you run it without any consideration for the fact that it is being run hidden and remotely, its default mode will pop a dialog that will hang indefinitely since it cannot be acknowledged. However, cleanmgr.exe does have a way of executing silently/quietly without any user interaction: The /SAGERUN switch. However, you can’t simply use /SAGERUN without some setup.

https://support.microsoft.com/en-us/help/253597/automating-disk-cleanup-tool-in-windows

In the above link you can see that the cleanmgr.exe tool has two important switches: /SAGESET and /SAGERUN

The way these switches work is you manually run the following command on a particular computer at the cmd prompt:

cleanmgr.exe /SAGESET:123

Note, in the above command I specified the value 123 but you can actually use any integer from 0 to 65535. The number represents a kind of “profile”, for lack of a better term, for the cleanmgr to utilize. What happens when you run the above command is you’ll be presented with the cleanmgr.exe ‘Disk Cleanup Settings’ dialog.

This Disk Cleanup Settings dialog is where you would tick the various selections that you want the tool to clean for you. When you click OK, the tool creates some registry values that contain the settings/selections you chose. Then later if/when you run this command:

cleanmgr.exe /SAGERUN:123

The settings that you previously created for the “123” profile are used for the actual cleanup routine. So if you create multiple cleanup profiles, for example, using commands like these:

cleanmgr.exe /SAGESET:123
cleanmgr.exe /SAGESET:124
cleanmgr.exe /SAGESET:125

You can then later at any time execute a cleanup that specifies one of the previously created profiles:

cleanmgr.exe /SAGERUN:123
cleanmgr.exe /SAGERUN:124
cleanmgr.exe /SAGERUN:125

Now, the tricky part here is that if you want to run the disk cleanup tool on numerous computers, you’re not going to want to log on to each computer manually to run the SAGESET command since that defeats the purpose of using BatchPatch to execute the cleanup on numerous computers without having to log on to each computer. So the trick is that you would need to write a script to create the values that the SAGESET command would create if you were to run it for the desired cleanup operations that you select.

After I ran this command:

cleanmgr.exe /SAGESET:123

…a number of registry entries were made in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches

I’ve pasted below just a few of the keys/values, but in particular please note the StateFlags0123 REG_DWORD values that exists in the subkeys. The StateFlags0123 values were created when I ran cleanmgr.exe with the /SAGESET:123 switch. /SAGESET:124 would create registry values titled StateFlags0124.

OK, so what you can do to automate everything is run the cleanmgr tool with /SAGESET on a single computer. Then evaluate which registry values it created, and then write a script that will create the same registry values. This way you can then use a BatchPatch deployment to deploy your script, the script will create the desired StateFlagsXXXX registry values on the target computers, execute cleanmgr.exe with the appropriate SAGERUN switch to make use of the StateFlagsXXXX registry values that were set by the script, and then optionally delete the registry values it previously created.

The script below is just a sample. You should modify it for your needs. In particular please note that it actually creates a StateFlags0123 DWORD with value of 2 in *all* of the subkeys under this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches

However, this is not necessarily what you want because if you use /SAGESET:123 and you make only particular selections in that settings dialog for what you want cleaned, you’ll see the result is that only some subkeys get the StateFlags0123 DWORD with a value of 2. Other subkeys will have a value of 0. And some subkeys might have no value at all. Refer to my screenshots above of the registry where you can see that of the three subkey DWORDs I showed, only one of them had a value of 2. If you want the cleanmgr.exe to follow your settings created when you used SAGESET, then you need the registry values to match those that were created by the tool when SAGESET was used.

The script below first creates the registry values, then executes cleanmgr.exe with /SAGERUN specifying the value that corresponds to the registry values it previously created, then finally the script removes the registry values.

# Create registry values
$volumeCaches = Get-ChildItem "HKLM:\Software\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches"
foreach($key in $volumeCaches)
{
    New-ItemProperty -Path "$($key.PSPath)" -Name StateFlags0123 -Value 2 -Type DWORD -Force | Out-Null
}
 
# Execute Disk Cleanup Tool (cleanmgr.exe)
Start-Process -Wait "$env:SystemRoot\System32\cleanmgr.exe" -ArgumentList "/sagerun:123"
 
# Remove the previously created registry values
$volumeCaches = Get-ChildItem "HKLM:\Software\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches"
foreach($key in $volumeCaches)
{
    Remove-ItemProperty -Path "$($key.PSPath)" -Name StateFlags0123 -Force | Out-Null
}

If you save the above script to “cleanmgr.ps1” you can then deploy it to numerous computers using the BatchPatch deployment feature. See below for my deployment configuration. I have not made any modifications in the “Command to execute.” It’s simply the default commmand that BatchPatch generates when BatchPatch sees that I am deploying a .ps1 file, and that is all that is needed:

Using BatchPatch in Non-Domain Environments with Standalone or Workgroup Computers

$
0
0

One of the questions we are asked regularly is can BatchPatch work on computers that are *not* domain members? How does one go about making that happen?

The answer is yes, in addition to working in a domain environment BatchPatch will also work on computers that are not members of a domain but rather are either standalone computers or computers assigned to a workgroup. However, you will most likely have to make a configuration change on your target computers in order for everything to work properly. That change is described toward the bottom of this page under the Third heading.

First:

Make sure that the account that you are using to connect to target computers is a member of the local administrators group on each of the target computers.

Second:

Decide how you will execute BatchPatch in the security context of the local administrator user that you previously defined on all target computers. You have three options here:

Option A:
Create the exact same account on the computer where you are running BatchPatch that you have already created on the target computers. The username and password of this account must be identical on the BatchPatch computer and the target computers. However, while the target computers’ user account must be a member of the local administrators group on the target computers, the user account created on the BatchPatch computer does *not* need to be a member of the local administrators group on the BatchPatch computer for most operations in BatchPatch to function properly. You certainly may add it to the local admins group if desired, but it’s not an absolute requirement since BatchPatch will generally work properly when run as a standard user for almost all of its operations. The operations that require elevation will inform you if you try to use them and they need more permission.

With the exact same account created on the BatchPatch computer as on the target computers, you may then simply log on to the BatchPatch computer as that user, and then launch BatchPatch normally by double-clicking the .exe. Since the entire BatchPatch application will now be running in the context of this user, all actions in BatchPatch will automatically have the appropriate permissions on the target computers. BUT… don’t forget to review the Third heading below in order to get everything working properly. The information provided there is necessary to get everything working in the large majority of cases.

Option B:
Just as in option A, on the BatchPatch computer you have to create the same exact user account with the same exact username and password that you previously created on the target computers. However, instead of logging on to the BatchPatch computer with that username/password, you could log on to the BatchPatch computer as a different user. Then when you launch BatchPatch, right-click on the batchpatch.exe and choose the option to “run-as” a different user. The different user that you choose to run BatchPatch would have to then be the user account that you previously created… the same one that exists in the local administrators group on all target computers.

Option C:
Launch BatchPatch with any user account on the BatchPatch computer, and then inside of BatchPatch enter alternate credentials for each row that you have added to the BatchPatch grid. To do this, select the rows and click Actions > Specify alternate logon credentials. The account that you specify here must be the account that you previously created on the target computers that is also a member of the local administrators group on the target computers.

Third:

After BatchPatch is running, you’ll find that if you try to perform an action on target computers, in most cases you will still see an error message or exception similar to the following:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Whether or not you see this error message will generally depend on which operating system version is running on the target computer as well as which particular action was executed in BatchPatch.

In order to resolve the ‘Access is denied’ exception, there is a registry value that needs to be created/modified on all target computers where this exception occurs. Instructions for the registry change is described toward the bottom of this page under the section Additional BatchPatch Authentication Details: BatchPatch Authentication in Domain and Workgroup (non-domain) Environments

A Tool to Automate Offline Windows Updates and Patches

$
0
0

A common issue that a lot of organizations face is how to apply various Windows updates and patches to “offline” computers that do not have internet access. Many companies operate high-security (or at least “higher-security”) networks that are segregated from their regular networks. The higher-security networks often do not have any internet connectivity whatsoever. Sometimes these high-security networks are referred to as “air-gapped” because there is no physical network connection between them and online networks that have internet connectivity, hence there is an “air-gap” in between the networks. While this can absolutely help to prevent malicious software from infecting computers on the network, it also increases the difficulty of administering and updating those computers.

BatchPatch Online Default Mode

**Online Windows updates with no caching**
(This mode is recommended for most environments)

BatchPatch’s default operating mode works for target computers that have access to either the internet for Windows Update and Microsoft Update, or to a locally installed/managed WSUS server. In this configuration, BatchPatch instructs target computers to search for and download their own updates from the configured update service (Windows Update, Microsoft Update, or WSUS). You can read more about that here:

Tutorial: BatchPatch Online Default Mode


BatchPatch Partially Offline Cached Mode

**Offline Windows updates with caching**
(The mode is recommended for restricted environments where target computers do *not* have access to the internet or a local WSUS but *do* have network access to an internet-connected computer running BatchPatch)

In this configuration, even though target computers do not have internet access and do not have a direct connection to a local WSUS server, they do have a direct connection to the computer where BatchPatch is installed/running, and that BatchPatch computer is connected to the internet. In this case the BatchPatch computer is then able to instruct target computers to perform an offline search for applicable/available updates. BatchPatch is then able to use the internet connection on its computer to downloads all of the updates needed by the offline target computers so that it can subsequently distribute them to target computers and initiate the installation process and reboots etc.

Tutorial: BatchPatch Partially Offline Cached Mode


BatchPatch Completely Offline Cached Mode for Lower-Security Networks

**Offline Windows updates with caching**
(The mode is recommended for restricted environments where target computers are on an air-gapped/offline network that does not have connectivity to the internet and does not even have connectivity to the computer where BatchPatch is installed and running. In this situation, the administrator needs to manually copy a text file from the segregated network to an internet-connected computer via an external hard drive or USB flash drive or similar)

In this setup, since target hosts do not have direct access to Windows Update and Microsoft Update via an internet connection, and they also do not have direct network connectivity to an internet-connected computer running BatchPatch, all updating occurs in a completely offline fashion. In this configuration, the search for available updates is performed offline, and then the list of available/needed updates is manually moved to an internet-connected computer running BatchPatch where the updates are downloaded. The entire update cache is then manually moved to the segregated/offline network where BatchPatch is used to distribute them to target computers.

Tutorial: BatchPatch Completely Offline Cached Mode for Lower-Security Networks


BatchPatch Completely Offline Cached Mode for High-Security Networks

**Offline Windows updates with caching**
(The mode is recommended for the most restricted environments where target computers are on a completely segregated, offline network, without access to the internet and without network access to an internet-connected computer running BatchPatch. In this case, the strict rules created to maintain the highest security of the air-gapped network disallow any files from ever being transferred from the high-security offline network to another network. When applying updates with this method, files will only ever be transferred *to* the high-security offline network, but files will never need to be removed *from* the high security offline network)

In this configuration, since target computers do not have internet access and also do not have access to an internet-connected computer running BatchPatch, all updating occurs 100% offline. In this configuration, an internet-connected BatchPatch computer is used to pre-download all Windows updates to its local cache. The administrator then copies/moves the entire BatchPatch cache of updates to the completely offline network where BatchPatch is able to distribute the updates to all the target computers even though they do not have internet or WSUS access.

Tutorial: BatchPatch Completely Offline Cached Mode for High-Security Networks

Deploying Windows Feature Update Version 1909 (the ‘November 2019 Update’) to Numerous Remote Computers Simultaneously

$
0
0

To remotely apply Windows 10 feature update 1909 (as well as the other Windows 10 feature updates) to numerous computers using BatchPatch, you should follow the process outlined below. The built-in, default Windows update features in BatchPatch will not work to successfully deploy these feature updates in most cases, so instead you’ll need to follow the deployment steps outlined below. Also note FYI even though these are called “feature updates”, the technical Windows Update classification by the Windows Update Agent (and WSUS etc) is called “upgrades”. The particular name of the update classification is likely not all that important for the sysadmin to pay attention to in many cases, but I did just want to highlight it just so that you are aware.

  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 1909 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 directoryandLeave 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.


Say Goodbye to Remote Desktop for Patch Management

$
0
0

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.

A Utility to Schedule Windows Updates on Numerous Computers

$
0
0

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.

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

$
0
0

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.

Offline Windows Patching for Isolated or Air-Gapped Networks

$
0
0

Applying Windows security updates to a networks 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 at the following link:
Cached Mode and Offline Updates

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

Notify Users of Upcoming Reboot or other Patching Activity

$
0
0

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.
Viewing all 261 articles
Browse latest View live