BatchPatch Stuck ‘Attempting to initiate Windows Update’ or ‘Initiating execution…’

By Scott | Published: May 21, 2019

This posting is for you if you can’t seem to get any Windows Update, Remote Process, or Deployment actions to work in BatchPatch, and instead they all seem to just hang, indefinitely, on ‘Windows Update: Attempting to initiate Windows Update‘ or ‘Deployment: Initiating execution…‘, depending on the particular action that is being executed.

To confirm whether or not you are experiencing the particular issue that I’m describing in this posting: try to execute ‘Actions > Windows updates > Check for available updates‘ on a couple of target computers. If multiple target computers all get stuck on the same ‘Attempting to initiate Windows Update‘ message, you might be experiencing this issue.

Why is this happening?

In this particular case, the issue is that BatchPatch is launching PsExec.exe, but PsExec.exe is actually getting blocked from execution by Windows. When Windows does this it normally would pop up a dialog window of some kind notifying you that the application was downloaded from the internet and might be unsafe. It prompts you to check or uncheck a box and then click OK to proceed with execution. Normally if this happens the box only needs to be checked/unchecked once, and then the operating system stores the decision so that in the future when PsExec.exe is launched, there is no warning prompt. The problem occurs when the dialog that is being displayed by Windows cannot be seen or has been inadvertently closed or hidden by the user. One way this can happen is if you are logged on to the BatchPatch computer as UserA, but you launch BatchPatch using run-as UserB, and then when the popup is created by Windows, it is created in the context of UserB and not visible to the user who is currently logged on as UserA.

How to resolve getting stuck indefinitely on ‘Attempting to initiate Windows Update’

We are aware of just two ways that the operating system might present this issue, depending on which version of Windows is being used. If you see Windows popup a warning dialog, it might look like this screenshot, but of course it would reference the location of PsExec.exe on your computer, not File.exe like is shown in the screenshot:

If this occurs, simply UNcheck the box that says “Always ask before opening this file,” and then click ‘Run’. After doing that just one time, the issue should be resolved.

However, if you do not see the above warning appear, then you should try right-clicking on the PsExec.exe file and clicking ‘Properties’ to view the PsExec.exe properties dialog. On the ‘General’ tab, if the file is being blocked from execution by Windows you might see a security note at the bottom of the properties window that says “This file came from another computer and might be blocked to help protect this computer.” You are given a checkbox to ‘Unblock’ the file. Click on the ‘Unblock’ checkbox and then click OK. You can see what this security warning and checkbox look like in the screenshot below.

At this point you probably already resolved the issue, but if for some reason you are still having the same problem, and if you are not able to find one of the checkboxes shown in the screenshots above, another thing you should try is logging on to the computer with the same user account that you are using to launch BatchPatch. So in this case if you were logged on as UserA but you were using run-as to launch BatchPatch as UserB, try logging out as UserA and then log back on as UserB. Then launch BatchPatch (without using run-as), which will automatically run in the context of UserB. See if the warning prompt now appears. If not, try right-clicking on the PsExec.exe file and selecting ‘Properties’ from the menu now to see if you can find the security warning as noted in the above screenshot.

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

Custom Update And Reboot Sequences for Multiple Computers

By Scott | Published: May 9, 2019

Today I’d like to demonstrate how to create a complete update-plus-reboot sequence where a group of computers must be shutdown and started up in a particular order. You might work in an environment where there is at least one group of servers that are not only reliant on each other for various reasons but where the overall system or service that is provided by this group of servers might be so fragile or so complex that you want to make sure that the group is taken offline in a specific sequence and then brought back online in the opposite sequence. Many of us have worked with systems that for whatever reason aren’t happy if they come online in an unexpected order. These days it’s probably not as common as it was 10 or 20 years ago because systems are coded more robustly than they once were, but still some of us are running old services or poorly coded apps that simply are not robust enough to survive an out-of-order reboot without issues. Typically the reason for this is because one server hosts a database that another server relies upon, but if the database system is offline when the application system is rebooted, the application never runs properly until/unless its host server is rebooted again after the database server is fully online. So today we’ll look at an example of how to deal with updates and reboots for a group of computers when that group needs to be taken offline and brought online in a specific sequence. With BatchPatch you can turn this into a one-click process instead of having to manually handle each computer.

First, for this particular example I’m going to use Wake on LAN (WoL) to boot computers that are shut down. Your needs may vary, and you simply might not need to use Wake on LAN depending on exactly what your goal is, but if you have a situation where you need or want to automate the process of powering up computers that are in a shutdown or powered off state, WoL is the most realistic option in most cases. If you’re going to use WoL, then before you get started you’ll need to make sure that it has been enabled in the BIOS of the target computer as well as in the Windows operating system on that computer too. This link illustrates how to enable Wake on LAN. Once you have enabled WoL on the target systems, make sure to test it so that you know it works before you try to include those systems in a larger sequence, such as the one we are about to create below.

For this example I have host1, host2, host3, host4, and host5. My goal is to download and install Windows updates on host1, and then after updates are installed the system will be shutdown. Then updates will be downloaded and installed on host2, after which host2 will be shutdown. Then host3, host4, and host5 will each do the same, in sequence. After all 5 hosts have been updated and have been shutdown, then we’ll start them back up in the reverse order so that first host5 comes online, then host4, then host3, then host2, and finally host1. We can orchestrate this entire sequence in BatchPatch with just a single action.

  1. We’ll start by adding all of our hosts to a BatchPatch grid. Note that I have added the following: host1,host2,host3,host4,host5,host4,host3,host2,host1. Hosts 1 through 4 appear twice, while host5 appears only once. The basic idea here is that we’re going to update and shutdown host1, then update and shutdown host2, then update and shutdown host3, then update and shutdown host4, then update and reboot host5 and wait until it’s online before powering up host4. We’ll wait for host4 to be detected online before powering up host3. Then wait for host3 to be detected online before powering up host2. Then wait for host2 to be detected online before powering up host1. Then we’ll be done. IMPORTANT: We do not recommend running a sequence like this without overseeing it. If you want to run a sequence like this in the middle of the night via scheduled task while you are sleeping, that’s fine. However, it’s important to understand that if something goes wrong with one of the hosts in the sequence, it could prevent the rest of the sequence from proceeding as expected. Therefore we think sequences like this are best used while someone is still monitoring what’s going on, so that if there is an issue it can be dealt with right away.

  2. Now that we have added our hosts to the grid, let’s create the job queues needed for each row. The first four rows in the grid (host1,host2,host3,host4) will all have the following job queue:

    Download and install updates + shutdown
Wait 1 minute

    The fifth row (host5) will have the following job queue:

    Download and install updates + reboot always
Wait for host to go offline and come back online
Wait 3 minutes

    The sixth through ninth rows (host4,host3,host2,host1) will have the following job queue:

    Wake on LAN (requires MAC address)
Wait for host to be detected online

    If you’re not familiar with creating job queues, please see this tutorial before proceeding. In all cases when you create the job queues for this sequence you will need to use the option ‘Apply queue to row(s) without executing.’ When all the queues are setup, your grid should look like this. The rows only show the first line of each job queue that is assigned, so I’ve pasted three screenshots below with tooltip windows next to each different queue so that you can see the different queue contents for each row:



  3. At this point we are ready to create the actual sequence. In BatchPatch we call this an advanced multi-row queue sequence, since it is a sequence of job queues that will be executed across multiple rows. Select ‘Actions > Job Queue > Create/modify advanced multi-row queue sequence’. Then assign the same Sequence Name to each row, but set the Sequence Position Number from 1 to 9 for each row, so that the first row in the grid is set to position number 1, and then last row is set to position number 9. See the screenshots below for reference.


  4. The last thing we need to do is create a sequence execution row. This is just a “dummy” row in the grid that is used to execute the advanced multi-row queue sequence. For the sake of this tutorial I’ll actually put the name “SequenceExecutionRow” in the row’s host column, but it can be called anything. Then using the same menu item as in the previous step we just change the radio button to ‘Create Sequence Execution Row’ before we click the ‘Apply values to selected row(s)’ button.

  5. At this point everything is set up. Now all we have to do is execute the sequence. Highlight just the execution row that you just created in the previous step. Then click on ‘Actions > Job Queue > Execute advanced multi-row queue sequence’ to execute the sequence.


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

When WSUS and Group Policy (GPO) Are Not Enough

By Scott | Published: May 1, 2019

Does Everyone Need a 3rd-Party Patch Management Solution?

A very common statement that you’ll find in discussions on the web about updating Windows computers in a network environment goes something like this: “There is no need to employ a 3rd-party Windows Update management solution because Microsoft provides WSUS and Group Policy objects (GPO) for free.” One of the interesting facets of the web and of the internet, in general, is that it allows anyone, regardless of expertise, to publish statements to a massive audience, even if those statements are not actually grounded in reality. The particular statement above is a good example of that, and it’s a good indication that the author of such a statement (or a similar statement) probably has never worked in a significantly sized enterprise environment.

Now, let me start by saying that WSUS and GPO are powerful options that definitely have their places. In some environments the two together might be totally sufficient because not all environments need more than what they offer. For example, smaller environments where there simply aren’t that many servers to deal with might be able to get away with just GPO and WSUS. Or even in some larger environments if servers can be down for long periods of time without creating lots of problems, it’s possible that WSUS plus Group Policy objects might work ok enough to not invest in something more. Ultimately if you are responsible for an environment where uptime isn’t particularly important or where efficiency isn’t needed, or where there just isn’t much complexity, then you might be fine with just WSUS and GPOs.

Why WSUS and Group Policy are Not Enough in Many Environments

  • Size: The size of the environment, without taking into account any other factors, is a major aspect to consider. The more computers that you are dealing with on your network, the more likely you will find benefit in utilizing a 3rd-party patching tool. For example in an environment with just 10 servers, a single sysadmin can manually patch and reboot those 10 servers without any automation whatsoever in a very short period of time. However, as the number of servers starts increasing, the manual operation quickly becomes infeasible. Group Policy might then be able to pick up the slack if you’re dealing with a few dozen machines, but what if it’s a 100, 500, 1000, or even more computers? Things can start to get dicey pretty quickly. See below for more.

  • Uptime guarantees / Small maintenance windows: If you simply cannot afford to have servers be offline for any longer than absolutely necessary, then you need to make your update and reboot process as efficient as possible. If you are relying on just group policy to control the timing of updates and reboots, it’s very difficult, if not impossible to have visibility and/or precise control over the process, especially when machines do not complete quickly or when they encounter issues either during installation or during reboot. This leads to computers being offline when they need to be online.

  • Visibility: With just group policy configured to auto-install and/or auto-reboot servers, you have no way of knowing what the status of any given server is at a given time without manually checking. This scales horribly, as you can imagine.

  • One or more updates fail to install successfully on one or multiple computers: Installation failures are inevitable. How do you learn about them when you have zero visibility into the update process? Typically you don’t find out until your maintenance window is over. In some cases you might not know for weeks or even months. In these cases the security and reliability of your computers is at stake.

  • Computers get stuck during reboot: You need a way to discover if/when computers hang on shutdown or startup during the update and reboot process. If you are using a separate uptime monitoring tool, is it disabled during your maintenance window? Do you only learn about stuck servers at the end of the window when you re-enable your alerting system? What about in cases where the machine hangs on shutdown such that it doesn’t go offline and trigger your alerting system? Instead it just never reboots, so it hangs in limbo while Windows is trying to shut it down, but it still responds to requests during this time. Not great when you’re trying to maintain a secure and stable environment.

  • Critical services fail to start after reboot: With just group policy controlling the timing of updates and reboots, how will you learn about the services that never started on one or more machines after reboots completed?

  • Server dependencies and update/reboot timing: In many environments there will be servers which are interdependent such that some cannot be offline unless others are online. Or in some cases a particular shutdown and/or startup sequence must be executed. This can’t be accomplished with just group policy.

If you’ve realized that in your environment you need more than just group policy with WSUS to control the update and reboot process of your servers, have a look at BatchPatch. It could be just what you need.

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

Patching Automation

By Scott | Published: April 24, 2019

When we originally designed BatchPatch the primary goal was to enable administrators to have much more control over the Windows update and reboot process on numerous systems. If the entire process is left to Group Policy it can be very difficult, if not impossible, to control the *exact* timing of everything and to have visibility into exactly what is occurring and when. Of course you always have the option of manually logging on to every system and initiating the process, but this can quickly become a problem when you have a lot of systems or a short maintenance window or both. With BatchPatch the idea was to give you one central place where you could kick off the process on numerous computers, and then monitor the status of all of those computers without having to directly log on to any of them unless addressing an issue. Ultimately we wanted to make patching as efficient as possible while also keeping the process simple and easy to manage at the same time.

Now, when we talk about Windows patching automation, we could leave the discussion at just being able to trigger the update/reboot process and monitor it on numerous computers, simultaneously. However, patching automation with BatchPatch can easily be taken to new heights, and it’s worth discussing in what other ways you can automate the process. We have some customers who prefer to use scheduled tasks in BatchPatch to trigger the process on their entire network of computers. There is nothing wrong with this approach, though it’s not our favorite because we think that when you’re dealing with a lot of computers, especially if you have a limited maintenance window and uptime guarantees, it’s important to monitor the process in real-time so that you can immediately deal with any issues that might arise. Now, if you’re using scheduled task to launch update and reboot actions on target hosts, you can certainly also have BatchPatch email you a copy of the grid so that you can see what’s going on without being actively logged on. It really all depends on your desires coupled with the requirements for your organization. We have some customers who will patch all of their critical systems while sitting in front of the BatchPatch console so that they can monitor everything in real-time. And then they’ll use the task scheduler to handle less important systems in the middle of the night or early in the morning. For those less important systems if there are any issues then they can just be dealt with when arriving to work in the morning.

Another thing that I particularly like to do to increase efficiency is to setup one-click processes for systems with inter-dependencies. For example in the case of virtual machines I like to use the advanced multi row queue sequence in BatchPatch to automate the process so that I can use a single click to initiate the update and reboot process on the virtual guests, and then when they are completed, the virtual host is automatically handled by the sequence. Otherwise what ends up happening when *not* using the advanced multi row queue sequence is that after kicking off the virtual guests to update, I’m busy dealing with other items before I remember to eventually make sure that the guests are completed before starting the process on the virtual hosts. There is nothing wrong with doing this, but it’s not as efficient as using a sequence to take care of it because the sequence can be setup to start the process on one machine (or on a group of machines) at the exact moment that another machine (or group of machines) finishes its processes. The advanced multi-row queue sequence is not only good for virtual machines. It’s also great for any situation where you have some machines that can only be offline when others are online, for example.

When it comes to automation, it’s not always just about automating the actual update and reboot process on target systems. We have some customers who want to use automation to also populate the BatchPatch grid with computers in the first place. It’s actually possible to automatically synchronize a BatchPatch grid with OUs and Groups in Active Directory, so that new computers that have been added to the network can be automatically added to a BatchPatch grid. Additionally, you can use row templates to automatically apply scheduled tasks to computers when they’re added to the grid. The two of these features can be used in conjunction with one another to take your automation goals to the next level. 🙂

BatchPatch really lets you keep things as simple and straightforward as you desire. If you don’t want to deal with any automation, you don’t have to. If you want to automate everything under the sun, you can do that to. It’s up to you!

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

Windows Patch Deployment Software

By Scott | Published: April 9, 2019

If you’re new to BatchPatch you might be aware of how easily it works to download and install Windows updates across your entire network of computers, but did you know that you can also use BatchPatch to deploy third-party software packages and updates? Almost any software can be deployed by BatchPatch, but in order to do that you need to first determine the silent/quiet installation parameter(s) for the 3rd-party package that you are interested in deploying. This is really the key ingredient to successful deployments. Today I’m going to discuss this in more detail.

What is a silent deployment?

Normally when you install a software package manually you first download (or obtain through some other means) the software package in question, which typically comes in the form of a setup.exe file. The package may or may not include additional files as well. To install the software you would double-click on the setup.exe file to launch the setup package, and then it would prompt you with a series of windows where you have to make various selections including but not limited to the desired path for the installation. You have to click ‘Next’ usually at least a few times before the process will actually start. You might even be required to click on something in the middle of the installation before it will complete. It all just depends on the particular package in question. If you plan to install the software package on numerous computers, one obvious way to do it is by simply manually connecting to each target computer and then running the setup.exe, clicking ‘Next’ however many times is required, and eventually completing the installation process on each computer. However, if you want to more easily, quickly, and painlessly deploy the software to multiple computers, you need to determine how to install the package silently or quietly. Essentially a “silent” or “quiet” installation is one where after launching the process, it completes with no further interaction required. That is to say you do not need to click ‘Next’ or any other button to complete the installation. Instead, you give all of the information required for the installation up front, typically in the form of installation parameters or switches, so that the package can do its thing without any further instructions or interaction. It’s called a “silent” or “quiet” installation because the installation process runs without making “noise.” In this case the “noise” would be various dialog windows that require user input such as clicking ‘Next’ or ‘Finish’ or entering an installation path or some other information that the installer requests. When you determine how to execute a silent installation, you can simply execute a particular command from the cmd prompt, and this command will be sufficient for the installer package to run to completion with no further interaction.

How to determine the silent installation parameter for a package?

All software packages are different, so there is never a guarantee that the silent or quiet installation parameter will be the same for any given package, but for the most part there are a few different conventions that tend to be followed by software vendors, so it’s typically not a difficult process to obtain the silent installation parameter for a package. Once you have determined the silent installation parameter, it’s then easy to execute a command that includes that parameter. In the following posting I outline how to determine the silent installation parameter for any software package: Understanding and Discovering the Silent Parameters Required to Remotely Deploy Software with BatchPatch

How to execute a deployment on multiple computers with BatchPatch

Once you have determined the silent installation parameter for a given software package, it’s easy to deploy it to multiple computers with BatchPatch. We always recommend first just making sure that you have things right by performing the silent installation manually from the cmd prompt at a test computer *without* using BatchPatch. This way you are certain that it works, as desired, before you attempt to deploy it with BatchPatch to multiple computers. However, once you have tested the silent installation command manually, it’s very simple to then port it to BatchPatch for mass deployment to numerous computers. At the following page we have numerous tutorials for deploying various software packages to multiple computers with BatchPatch. You can see in the tutorials how the silent/quiet parameters can vary from one package to the next, but how the overall process for deployment in BatchPatch is still generally very quick and simple: BatchPatch Software Deployment

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

Schedule a Service to Shutdown on Multiple Computers Before Applying Updates and Rebooting

By Scott | Published: April 4, 2019

Every network environment has its own requirements that are particular to it, depending on the types of servers and services running, the service level agreements in place between companies and their customers, as well as any other factors that may influence how decisions are made about maintaining the environment and its security etc.

When it comes to automation, there are cases where an administrator might need or want to completely stop a service that is running on a particular server or group of servers before beginning the update and reboot process. And depending on how the service is configured (automatic vs manual), it might need to be manually started after the reboot completes. Today I’m going to demonstrate how you can use BatchPatch to automate this process very easily on any number of target computers. You can schedule the process to run at a specific date/time, or you could simply configure it to run on-demand with a single click trigger.

Tutorial

  1. We’ll start by creating and saving a remote command in BatchPatch that will handle stopping the desired service. Click on ‘Actions > Execute remote process/command > Create/modify remote commands‘. In the window that appears click ‘Add Row’ and then insert the following command, substituting the name of the service you want to stop. In this example I’m just going to be stopping the DNS Client to illustrate the process, though realistically the DNS Client is not a service that anyone typically needs to be messing with. You can see in the screenshot that I’ve inserted the command into the command field, and I’ve given it a title in the title field. If you intend to use BatchPatch to start the service at some point, then go ahead and also create a row with a command to start the service. In most cases administrators probably have services that need to be running set to ‘Automatic’ so that they automatically start after a reboot. If this is the case for your service, then you won’t need to create a startservice command, but of course you should do whatever is needed for your situation. Click OK when finished.

    WMIC SERVICE where caption='DNS Client' CALL stopservice
    WMIC SERVICE where caption='DNS Client' CALL startservice

  2. Now that the stop service command has been created it would be wise to take a moment to test it and make sure it works as desired/expected. To test it we can simply select a target host in the grid, and then click on ‘Actions > Execute remote/process command > Execute saved remote commands > Stop DNS Client Service’. Then make sure that the service has been stopped as desired, either by reviewing the services console manually/directly on the target computer or by using ‘Actions > Services/Processes > List all services’ from within BatchPatch. This action will give you a list of all services and their current states.

  3. Once you have verified that your command works properly, you’re ready to create a job queue. The job queue is what will handle the process of sequentially executing the stop service command followed by the update/reboot command. Select ‘Actions > Job Queue > Create/modify job queue’. In the job queue window first find the command you created in the ‘Saved User-Defined Commands and Deployment’ grid in the lower left corner of the window. Double-click on your command (or use the right-arrow button) to add it as the first item in the queue. Next, add the ‘Download and install updates + reboot always’ command from the ‘Actions’ listbox in the upper left corner of the window. Input a title for the job queue, and then click the double-right-arrow button to save it. You should have something like the screenshot below. Close the window when you’re done.

  4. That’s practically all there is to it. Now if we want to run this job queue on-demand at any time, we can simply select the desired servers in the BatchPatch grid, and then click ‘Actions > Job Queue > Execute saved job queues > Tutorial 20190404’. Of course you’ll use whatever title you gave to your queue.

Other Considerations

  • If you want to have this job queue run as a scheduled task on a specific date/time, that’s easy to do. You’ll select the desired rows, click on ‘Actions > Task scheduler > Create/modify scheduled task’, and then select your saved job queue from the list of tasks, set the run time/date, and enable the scheduler. Check out this task scheduler tutorial for more details.

  • If your service is set to automatic, make sure that you guarantee a reboot will occur. For example in your job queue if you were to choose ‘Download and install updates + reboot if required’ a reboot will not be executed if the update installation doesn’t require it to complete the process. This means that if you have stopped the service and installed updates without a subsequent reboot, your service would be in the stopped state indefinitely without manual interaction. You could use a start service command in the job queue maybe after a 5 minute wait period after the update + reboot if required command, if desired. Or you could simply use a command that guarantees a reboot after the update process. There are numerous ways that this can be handled, and it all really just depends on your needs and preferences.

  • If your service is set to manual such that you need to incorporate a start service command into your job queue, that’s fine. However, you’ll want to make sure that the computer has ample time to complete its reboot before you issue the start service command. You can use a ‘Wait’ period in the job queue to handle this. There are more details here about some of the special items in the job queue such as the various ‘Wait’ commands.
Posted in Blog, General, Tutorials | Tagged , | Comments closed

The Best Software to Automate Windows Patching

By Scott | Published: March 28, 2019

Systems administrators have quite a few options when it comes to applying Windows updates to the computers that they’re responsible for. In smaller environments with looser requirements it might be totally sufficient to just manually install updates each month by logging on to each computer with Remote Desktop or some type of KVM solution, and then initiating the download, install, reboot process, and finally making sure computers come back online properly. It’s not necessarily an efficient process, but it can be sufficient in many cases. Of course this process becomes unwieldy quite quickly when the total number of computers being managed increases over a certain threshold. If requirements continue to stay loose, it might be that the administrator can shift to using Group Policy to gain a modicum of control over the updating process, thereby alleviating some of the pain of a completely manual process. This may or may not involve installing a WSUS server to help with controlling which updates are made available to target computers. But what happens when more control is needed? Administrators of environments that have stringent uptime requirements or brief maintenance windows or a large number of servers know that relying on just Group Policy to manage the update process simply won’t cut it. It’s hard to even call it “managing” the process because there isn’t much managing going on.

Why WSUS + Group Policy Objects Might Not Be Enough In Your Environment

If you’re trying to manage Windows updates in your environment with just GPOs and WSUS, there are some very important things to consider:

  • Machines get stuck during reboot: Sometimes computers hang while shutting down or starting up. This is an inevitable fact. The more computers you’re dealing with, the more likely you are to see one or more get stuck during the reboot. If you’re relying solely on WSUS + GPO scheduled installations/reboots, it can be hard to determine that a machine got stuck if you aren’t monitoring it in real-time. If you have a different tool that alerts you of down/offline servers, that’s great, but you probably have it disabled during your maintenance window since you know computers will be going offline at that time. The result is that at the end of the maintenance window when you turn back on your alerting tool, you all of a sudden discover which servers are stuck offline, but now it’s too late to resolve the issues *before* the end of the maintenance window. In an environment with uptime guarantees you’re probably already getting calls from customers at this point asking why they can’t access X, Y, or Z.

    But what about the case where the server gets stuck during the shutdown process? You could end up in a situation where the server completed installing updates, but it gets stuck somehow such that the reboot does not occur. The server might still be online and responding to requests, so it doesn’t trigger your alert system, but the update process has not officially completed because the reboot never took place. When your maintenance window is over, you won’t discover this very easily or at all, and the machine will be in a questionable state and might still be vulnerable to whatever issues were supposed to be fixed by the updates that were installed since the installation never actually got to complete since the reboot never occurred.

  • Unexpected slow update processing causes reboots to be initiated at unexpected times: We all wish Windows updates always installed rapidly, but sometimes there are issues, and things just don’t go as quickly as we expect or need. If a scheduled update process is taking longer than expected, the reboot can occur at an unexpected time. If you aren’t monitoring the installation process in real-time then you might end up with a surprise reboot that occurs when you didn’t want it to. However, if you have a tool that provides you with real-time monitoring capability you’ll know the process is going slower than expected, and so you can make the necessary arrangements to deal with that before an unexpected reboot occurs.

  • Critical services not starting after reboot: Sometimes services fail to start after a reboot. It’s just one of those things that can happen sometimes. The more servers you’re dealing with, the greater the likelihood is that something like this could happen. The sooner you are able to discover which servers have critical services in a stopped state, the better. However, you need to be able to confirm that the reboot occurred before checking the state of services, which again is very difficult when you don’t have a real-time monitoring solution in place for the update and reboot process. It also helps significantly to have a tool that can quickly tell you which computers have automatic services in a stopped state.

  • Server dependencies create challenges for update and reboot timing: It is not uncommon for there to be dependencies in groups of servers such that one server cannot be taken offline at the same time as another, or one server can/should only be rebooted when another server is online etc. The more dependencies that exist, the more an administrator can benefit from having a tool that allows precise scheduling and/or on-demand execution as well as real-time monitoring. A tool like BatchPatch is even capable of orchestrating complex sequences to update and reboot servers in specific orders with lots of control and flexibility over exactly what happens and when, allowing you to configure one-click actions that handle the updating and rebooting of numerous computers in particular orders and with particular dependencies.

  • Virtual machines: In environments with many virtual machines it becomes important to coordinate the update and reboot timing of the guests and hosts so that host operating systems don’t reboot during or before guest update processes complete, for example.

A Better Option

If you’re at the point where manual updating or GPOs and WSUS alone aren’t cutting it anymore, BatchPatch might be the tool for you.

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

Using the Row Template Configurator to Automatically Apply Job Queues and Scheduled Tasks to New Rows When They Are Added to the Grid

By Scott | Published: March 13, 2019

BatchPatch has a very neat feature that is probably not used nearly as much as it would be used if more people realized it existed, and if they understood what it is. It’s called the ‘Row Template Configurator‘ and it can be found under ‘Grid > Row template configurator…‘ inside the software. The row template configurator enables the BatchPatch administrator to automatically apply column values to new rows when they are added to the grid. For example, if you are using the grid synchronize feature to automatically add new hosts to your BatchPatch grid on a scheduled basis, you might want those new hosts to be added to the grid with certain fields automatically applied, such as a scheduled task or job queue. Wouldn’t it be nice if you could have an almost-completely hands-off configuration, such that if you put new computers on your network and add them to Active Directory in a particular OU, and then have BatchPatch synchronize its grid with that OU on a scheduled basis, then when new rows get added to the grid (one new row per new computer in the OU), those new rows can automatically have scheduled tasks applied to deploy Windows Updates or third-party software or whatever you want. Pretty cool, I think.

Using the Row Template Configurator to Automatically Apply Values to Desired Fields

  1. The first thing that we need to do is create a standard row in BatchPatch that contains the elements we want new rows to have automatically applied. I’ve added a row to the grid, and I have applied a recurring scheduled task to “Install downloaded updates + reboot if required.” Note, you can use any host name for this step, but for the sake of this example I’ve just called my host ‘TEMPLATE’ for obvious reasons.
  2. Next click on ‘Grid > Row template configurator…‘ to launch the configurator form.
  3. Make sure the row that you created in the BP grid in the first step is selected/highlighted, and then click ‘Create/update row template based on selected row in main BatchPatch grid‘. When you do this you’ll see that the columns from the main grid, excluding the host name, are added to the row template.
  4. Now that the row template has been created for the grid (note, you can create one row template for each BatchPatch grid), if you want the template to actually be utilized when adding new hosts to the that grid, you must first enable the template, which you can do by clicking on the ‘Enabled’ radio button in the upper right corner of the ‘Row Template Configurator’ form. Then click OK.
  5. At this point the row template has been created for the BatchPatch grid, and it’s currently enabled. Now if you add a new row to the grid either manually or automatically through the grid synchronize feature, that new row will automatically receive the row template fields, which in this case is a recurring scheduled task to “Install downloaded updates + reboot if required” every Saturday night. In the screenshot below you can see that I’ve removed the row that we used to create the template, and then I’ve added five hosts, each of which automatically received the template values.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Remotely Patch and Reboot Multiple Computers

By Scott | Published: March 5, 2019

If you’ve stumbled upon this page, it’s probably because you are looking for a simple method to remotely apply Windows updates to multiple computers on your network, simultaneously. Not only that but you also want to be able to have the entire patch and reboot process automated so that you can pretty much just press a button and watch your target computers update and reboot themselves with as little interaction as possible. Well, you came to the right place!

BatchPatch is a tool designed for systems administrators to remotely manage Windows updates as well as third-party software on their network of computers. Configuration is simple, and there is no remote agent installation to perform. You pretty much just configure your network to work with BatchPatch, and then you can start patching right away.

Features:

Some of the primary features of BatchPatch include the following. However, for a more complete list check out the home page:

Additional capabilities:

In reality the capabilities of BatchPatch are relatively limitless when it comes to Windows networks. Almost anything that isn’t already built-in to the software can still usually be accomplished with some amount of customization. The application can work with WSUS or without it, in domain environments or in standalone or workgroup settings, and it can even be used to apply Windows updates to computers on so-called “air-gapped” high-security networks that are completely segregated from internet-connected computers.

Download:

We encourage you to download the free evaluation version of BatchPatch so that you can try it out for yourself in your environment. Our website has many dozens of tutorials on virtually every possible topic and use case for the software, so please do check those out.

Contact us:

If you encounter any problems or if you have any questions that do not appear to be answered on the website, please feel free to reach out to us to discuss.

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

When ‘Uninstall individual update Windows 10/2016’ in BatchPatch Fails to Remove an Update

By Scott | Published: February 28, 2019

Unfortunately there are cases where remotely removing an update from numerous computers can prove to be more challenging than it seems like it ought to be, especially when you have a great tool like BatchPatch at your disposal. BatchPatch has a built-in feature Actions > Windows updates > Uninstall individual update (requires KB ID) – Windows 10/2016 for uninstalling individual updates from Windows 10 and Windows 2016 target computers, but it is not always successful. Today I’m going to describe why it doesn’t work 100% of the time, and I’m going to show you how you can complete the task of removing an update from multiple Windows 10 or Windows 2016 computers, using BatchPatch, when the BatchPatch built-in feature for this purpose fails.

For the sake of this tutorial we are going to remove KB4487006 from a single Windows 2016 computer in our lab, but of course you can use this same method to remove an update from numerous remote computers, simultaneously, simply by selecting multiple computers in your BatchPatch grid when you execute the action.

Demonstrating the failure to remove an update using the built-in option in BatchPatch:

First let’s try to remove the update using the built-in function in BatchPatch. I know in advance that it will fail, but I want to show you what the failure looks like. I’m going to select Actions > Windows updates > Uninstall individual update (requires KB ID) – Windows 10/2016, and then I’ll enter the KB ID into the form that is presented before clicking OK. The screenshots below illustrate this process.

In the screenshot below you can see that the command took only 15 seconds to run before returning ‘Exit Code: 1’. Not surprisingly, it’s also the case that the update was not actually removed from the target computer.

Why the built-in removal method did not work:

The first question we need to answer is why was the update not removed? Here is a copy of the actual command that BatchPatch executed on the target computer:

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

Essentially what the command above does is identify the update’s package identity in Windows, using DISM.exe and findstr. The way that we discover the package identity is by searching for the string ‘KB4487006’ in a list of all of the packages that have been installed. After the package identity has been discovered, DISM.exe is used once again but this time to remove the update by passing the package identity of the update to the DISM /remove-package command. This works great when the package identity contains the KB ID. The problem, unfortunately, is that the package identity will not always include the KB ID. It’s almost as if Microsoft’s goal was to make this as difficult as possible for us!

In the screenshot below I have executed the following command at the PowerShell prompt of the target computer in order to view the list of all packages, including their package identities, that have been installed:

dism /online /get-packages /format:table

We can further refine the list of packages to only include packages for Windows updates because all of the updates begin with the text Package_for. We use the findstr command for that purpose, as you can see in the command and screenshot below.

dism /online /get-packages | findstr 'Package_for'

You can see in the screenshot above that not all of the updates contain the KB ID, and in particular the KB4487006 that we are trying to remove is not identifiable by KB ID in that list. This is why the BatchPatch built-in function ‘Uninstall individual update Windows 10/2016’ fails to remove update KB4487006. It can’t find it!

One other important consideration is the display language setting in your operating system. For example, if Windows is configured to display in German instead of English, then instead of Package Identity the DISM results will display Paketidentität and Paketidentit?t like in the screenshots below. Since the DISM commands that we are using for update removal rely on the PowerShell findstr command and .Replace() method, if there is a language mismatch in the search string as compared to the OS display language, the command will fail.

How to remove the update using BatchPatch with a custom command:

Unfortunately in order for us to be able to remotely remove the desired update from our target computers using BatchPatch, we have to first identify the package identity for KB4487006. This requires some manual effort. We start by listing out all of the installed update package identities on a target computer where KB4487006 is known to be installed. We use the following command to do that:

dism /online /get-packages | findstr 'Package_for'

We know that KB4487006 is installed on the computer, and so we can deduce that its package identity must be one of the ones that begins with ‘Package_for_RollupFix‘. Furthermore, it happens to be the case that these rollups supersede previously installed rollups, so if you are trying to remove the most recently installed rollup due to the fact that after you installed it recently it started causing problems for you, you can use the ‘State’ column in the table in the screenshot below to see that of the four rollups listed, three of them are showing the state value as ‘Superseded‘ while just one is showing ‘Installed‘. In this case since I know the most recent rollup is the one that I’m trying to remove, I already know that the one showing ‘Installed‘ is the KB4487006.

dism /online /get-packages /format:table

However, to further confirm/verify that the KB4487006 is Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.2828.1.11, let’s check out the KB4487006 page on Microsoft’s website. You can simply google KB4487006 to find this page:

https://support.microsoft.com/en-us/help/4487006/windows-10-update-kb4487006

At the top of the page we can see Build 14393.2828:


So now we have confirmation that KB4487006 is Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.2828.1.11 Just in case you missed it, the reason is because the package identity contains the build number 14393.2828.

So now if we want to remove this update from multiple target computers using BatchPatch, we can do it by executing a remote command in BatchPatch with the following syntax. Note the command below is identical to the command that BatchPatch’s built-in function runs with one exception, which is that instead of using KB4487006 as our search string, we substitute it with 14393.2828:

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

NOTE: The command above contains /norestart, which will prevent the target computer from restarting after the command executes. For most updates a reboot will be required to complete the uninstallation, so if you use the /norestart switch you will need to issue a reboot command after it finishes. Alternatively you may remove /norestart from the command so that the target computer reboots itself to complete the uninstallation process.

ALSO NOTE: As described earlier in this posting, if you’re using a different OS display language, you’ll have to modify your command accordingly. For example, if the display language is German, the above command would have to be changed to this instead (we replaced Package Identity with Paketidentit?t) :

powershell.exe -ExecutionPolicy Bypass -command "$SearchUpdates = dism /online /get-packages | findstr 'Package_for'; $updates = $SearchUpdates.replace('Paketidentit?t : ', '') | findstr '14393.2828'; DISM.exe /Online /Remove-Package /PackageName:$updates /quiet /norestart"

To execute the command in BatchPatch select ‘Actions > Execute remote process/command > Create/modify remote command 1‘. Then enter the command and click ‘Execute’ to execute it on the selected rows.

Note, this command seems to always return Exit Code: 1, even when it completes successfully. Also note, removing update rollups like this one can take a long time for processing to complete *after* the command executes. That is to say that if you execute the command without /norestart, the computer will automatically reboot, but it might not be accessible after that for a couple of minutes while it goes through the typical “configuring updates – don’t turn off your computer” screen. One thing to consider doing is issue a ping command in BatchPatch before you execute the uninstallation command. This would enable you to easily see when the computer goes offline and comes back online. Alternatively if you issue the command with the /norestart switch, you could put it in a job queue and have the job queue execute a reboot when the command completes.

Also note, if you attempt to execute this command directly on a selected computer at the command line, as opposed to running it in BatchPatch, you will need to run the command in a cmd prompt, not in a powershell prompt. The syntax provided above for running it in BatchPatch is the same syntax that can be used to run it in a cmd prompt, but to run it in a powershell prompt you would need to modify it slightly, otherwise it will fail. You are certainly welcomed to modify it as you see fit, but I just wanted to make sure that you’re aware that it will not work as-is in a powershell prompt.

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