Automate Windows Update Installations for Multiple Remote Computers

One of the common reasons that IT administrators use BatchPatch is to help automate processes, which in turn leads to less time spent dealing with patch management. As any patching administrator has seen before, there are times when installing Windows updates on a computer and then rebooting the computer seems to only lead to more updates becoming available for installation. The annoying thing is that in these cases you are not able to simply install *all* available updates with just a single reboot. Instead what happens is you install available updates and reboot, but then new updates become available only *after* the previous installation and reboot has completed. There may even be rare cases where three complete cycles must be completed to get every applicable update applied.

If you are performing Windows updates through a manual process where you log on to each computer and initiate the download/installation/reboot process, you can imagine how unwieldy it becomes when you have numerous computers to manage and when those computers each require two complete download/install/reboot cycles before all updates have been applied. BatchPatch can dramatically reduce the pain involved in this process by providing automation capability so that the administrator, with just a few clicks, can launch the update and reboot process on numerous remote computers, simultaneously, including as many lather, rinse, repeat cycles as needed.

I have discussed the BatchPatch ‘Job Queue’ in other postings before, but today I’m going to focus on the process of using the job queue to initiate multiple update and reboot cycles on multiple target computers, so that you can quite literally sit back, relax, and just watch your computers as they download, install, reboot, wait until back online, then download, install, reboot a second time.

  1. Let’s start by selecting the desired computers in the BatchPatch grid to be patched, and then select ‘Actions > Job queue > Create/modify job queue’
  2. In the ‘Job Queue’ window all we have to do is double-click items on the left side of the window to be included in our queue. A multi-cycle update/reboot process can be handled in a number of different ways, so you do not have to use the exact job queue steps that I have selected here. However, the steps that I have selected should at least give you an idea of one possible way to perform such a cycle in BatchPatch. As you can see in the screenshot below, I have created a queue with the following steps:
    1
    2
    3
    4
    5
    6
    
    Download and install updates + reboot always
    Wait 10 minutes
    Wait for host to be detected online
    Check for available updates
    Terminate queue if previous 'Check for available updates' finds 0 updates
    Download and install updates + reboot if required


    This particular queue works well because after the first update and reboot process, it waits 10 minutes to give the computer ample time to reboot, and then it uses ‘Wait for host to be detected online’ just to make sure that the next step does not begin until after the host is up. Once it’s up, the next cycle begins, but not until after we first do a check for available updates. In this way we can use ‘Terminate queue if previous ‘Check for available updates finds 0 updates.’ This is a really nice little feature because that way we don’t continue to execute processes on the target host for no reason if there are no available updates to be installed.

  3. At this point we can simply click ‘Execute now’ to execute the queue on our selected hosts. Or we could alternatively save the queue for future use by clicking the double-right-arrow ‘>>’ button. That’s really all there is to it!
Posted in Blog, General, Tutorials | Tagged , , , , | Comments closed

Windows Patch Management Made Easy

We’re biased, of course, but we really do believe that you’re not going to find a better value than BatchPatch when it comes to patch management applications for Windows. With BatchPatch you get a very streamlined application without the clunkiness that so many modern software packages deliver… you get a lot of features and functionality for Windows patch management and related systems administration… and perhaps most importantly you get it all for a very modest price.

Patch Management:

From a patch management perspective you get standard Windows Update management that makes it extremely simple and painless to rapidly apply Windows Updates to numerous remote computers with real-time monitoring and automated reboots. You also get additional functionality for deploying standalone patches, updates, and third party software installations. In addition to standard Windows Update management you also get full capabilities for offline patch management, so that you can apply security updates to computers that do not have internet access and do not have access to a WSUS. BatchPatch’s offline mode enables you to apply Windows security updates to entire networks of computers that are completely isolated or air-gapped from the rest of the world.

Systems Administration:

As a systems administration and computer management toolset you get functionality for deploying scripts, registry keys, and other files to remote computers. You can initiate reboots, shutdowns, as well as wake on LAN (WoL). You can send messages to logged-on users, you can run custom commands, and you can even grow fruits and vegetables! OK, I’m just kidding about the fruits and vegetables, but there’s still a lot of other cool stuff you can do with BatchPatch, such as check online status of target computers or inventory hardware and software components of multiple computers, for example. The list goes on.

Automation and Sequences:

Perhaps one of the coolest and most powerful aspects of BatchPatch is the automation capability. One of the under-addressed challenges that exists in virtually all modern networks concerns the management of multi-system dependencies when dealing with updates, reboots, and other maintenance procedures frequently associated with patch management. For example, if you have 10 computers that have interdependent processes such that you have to shut them down and/or start them up in a particular sequence, it can be challenging to handle such a process efficiently, especially when you have a limited time window for maintenance. Worse yet is if you have numerous groups of interdependent systems. It’s one thing to worry about reboot and shutdown sequencing for 10 interdependent systems, but what if you have 10 separate groups of interdependent systems, with each group of systems containing several or more computers? To manually manage the process of taking them offline, applying updates, and bringing them back online in a specific sequence, is not just tedious but is also very time consuming and horribly inefficient. Maintenance routines for these kinds of interdependent systems typically require entire teams of sysadmins to be on-hand. Wouldn’t it be nice if you could automate these sequences so that fewer people can accomplish more in a shorter period of time?

Download and Evaluate:

If any or all of this sounds interesting to you or helpful for your network environment, I would encourage you to try out our free evaluation software. Download it and start patching! You might be amazed at just how much time it can save you. If you have any questions, please feel free to reach out to us at any time.

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

Batch Install Windows Updates

No doubt you have arrived here because you need or want to install Windows Updates on a batch of computers, and you want to do it as quickly and painlessly as possible. You’ve come to the right place. After all, we didn’t name the software ‘BatchPatch’ for no reason!

BatchPatch enables the administrator to perform virtually any action, remotely, on numerous target computers at the same time. So if you have 100 computers that all need Windows Updates, one of the things that you can use BatchPatch for is to trigger the download and installation of those updates on all 100 computers, simultaneously. You can even include automated reboots with real-time monitoring of the process so that you can keep track of when the computers have completed the process. The entire operation can be performed with just a few clicks, and there are a lot of other things that BatchPatch can do too. For a more complete list of features, please review the home page.

Below I will outline the process so that you can see just how simple it actually is. I would encourage you to download the free evaluation version to test it for yourself in your own environment. You can download it from here. On that same page you will find all the necessary information about prerequisites and getting started with the application in your network.

  1. Start by adding all of your desired target computers to the grid. You can do this by selecing ‘File > Add hosts.’ Or if you already have your list of computers in a text file, you can just drag and drop the text file onto the grid (or use ‘File > Open’ to open the text file in the grid).

  2. Once the host names or IP addresses have been added to the grid, all actions are performed by first selecting/highlighting the desired rows. Highlight each row that contains a host that you want to be included in the particular action that you’re about to execute. In this case we are going to select all of the hosts in the grid, and then I’m going to select ‘Actions > Windows Updates > Download and install updates + reboot if required’

  3. At this point you can just sit back and watch until all computers have been updated and rebooted. You will see each row show the status of the particular host. The process will start by searching for available updates. Once the available updates have been determined, BatchPatch will instruct the target to download and then install the updates. If you need to filter which updates are included or excluded by BatchPatch, that’s very easy to do, and this link explains exactly how to do that.

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

BatchPatch Audit Logging

Yesterday we published a new build of BatchPatch that includes a new ‘Audit Logging’ feature. The purpose of this new Audit Logging feature is to help with keeping track of who has executed actions on target computers, and which actions they have executed.

To provide access to this new feature there is now a new tab under ‘Tools > Settings > Audit Logging’

To enable audit logging simply choose a directory for the log files to be stored, and choose a file name. Then click ‘Enable audit logging.’ When audit logging is enabled or disabled, ‘enabled‘ or ‘disabled‘ stamps will get written to the log file so that for the sake of compliance you can keep track of not only actions that are executed on target computers but also if a user disables audit logging.

Once enabled, the audit log will display a copy of everything that is logged to the ‘All Messages’ column in BatchPatch, along with the timestamp of execution, the current user, the target host name, and the target user. The ‘current user’ is the name of the logon account that was used to launch/run batchpatch.exe. The ‘target user’ is the user that was specified in the ‘Alternate Credentials’ column for a given row to execute remote actions on the target host. If no alternate credentials were specified for a row, then the ‘target user’ will be written as ‘Integrated Security,’ in the audit log, which means the target user impersonated the current user for that action. The screenshot below shows a sample of what the log looks like.

If you have any comments, questions, or other feedback about this feature or any other aspects of BatchPatch, please do not hesitate to reach out to us.

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

Windows Patch Automation

We regularly receive questions from IT administrators who desire to have more control over their patch management processes as well as better automation for their patching systems. One of the phrases that we have begun to hear more and more frequently is “patch fatigue” and how it’s affecting so many organizations all over the world. Not surprisingly, patch fatigue seems to be one of the elements that drives admins to find patching solutions like BatchPatch.

When it comes to patch automation, in particular, there is a kind-of critical threshold that must be carefully assessed. Some automation is a good thing, but too much automation could actually be a bad thing if it comes at the cost of control over the entire process. If you have everything setup to run automatically without the administrator even having to monitor everything, that sounds very nice! But just because you have setup everything to run automatically does not mean that forgoing monitoring of the entire process is necessarily a good idea. And in many cases I would argue that it’s a horrible idea, but this really depends on the particular environment’s needs, service level agreements, etc. When it comes to automation we have some users who are *truly* obsessed with automating everything. Sometimes they even want to automate all the way to the point that they have automated processes setup with the sole purpose of configuring their automation for other processes, like some sort of meta-automation, if you will. 🙂

However, I would argue that there is a point where too far is too far. Ideally, the administrator really should be monitoring his/her patching processes, even if the processes themselves are launched by automated tasks. If you are able to get away without real-time monitoring, that’s all well and good, and I’m happy for you that your environment allows for that level of flexibility. You may very well not even need a third-party patch management tool. People often say things like “There is no need to use third-party patch management tools when you can just use WSUS and group policy.” This is definitely true for some environments, but generally people who make these blanket statements fail to realize that this is simply not an option in many environments, especially in environments where uptime is critical or where maintenance windows are small, or where the number of systems being patched is large. And so when I see someone make a statement like this I immediately know that one of a few things is true about his/her environment. He/she is likely dealing with a more casual environment where patches can be installed in large time window, reboots can be done without concern for exactly when those reboots occur, and perhaps also the number of computers involved is not all that high. In these cases, the administrator can develop processes that rely on automation while sacrificing precision, control, and real-time monitoring, and so WSUS and group policy alone might be sufficient in these cases. But for the rest of us who need to control precisely when our machines download and install updates or precisely when our machines reboot, and we need to monitor to make sure they are back online by a certain time and that various services are up and running after the machines are online, that’s where third party patching applications like BatchPatch come in to play. And for those of us who like to automate while still maintaining a high degree of precision and control over the whole process, BatchPatch has more advanced features like the ‘Job Queue‘ and the ‘Advanced Multi-Row Queue Sequence‘ that can be used in conjunction with the ‘Task Scheduler‘ for all of your automation desires.

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

Using BatchPatch to Modify Local Group Membership on Multiple Remote Computers

Today I’m going to demonstrate how to use BatchPatch to perform a routine task that administrators have to complete periodically, which is to edit the group membership of a particular local group on multiple computers. The cool thing with BatchPatch is that you can do all of the computers in a single shot.

To perform the actual group membership change we’re going to use the ‘Net localgroup‘ command that’s built in to Windows. However, we’ll use BatchPatch to execute the required commands, which enables us to target numerous remote computers at one time. For reference we will be using some of the commands outlined here.

  1. First let’s make a quick configuration change. Under ‘Tools > Settings Remote Execution’ let’s change the ‘Remote execution context’ to ‘Elevated token’ for ‘Remote process/command (logged output).’ The default configuration is set to use SYSTEM, which works best for most situations, but there are some situations that could require a different execution context, and this is one of those times. If you try to execute a ‘Net localgroup’ command under the SYSTEM context, it may work or you may get an error, depending on the account that is being used and the target system configuration. However, using ‘Elevated token’ should work for all scenarios (unless, of course, the account you are using simply does not have the necessary permissions needed to change the group membership on the target computer).
  2. net localgroup GroupName displays a list of users or global groups in a local group, so let’s start by listing out the users/groups contained in our local administrators group on the target computers. To do that I clicked on ‘Actions > Execute remote process/command > Create/modify remote command 3 (logged output)’. In the remote process window I typed ‘net localgroup administrators’ and then clicked ‘Execute’ so that the command would run on the highlighted computers in the grid.

  3. If we want to remove ‘johndoe’ from the administrators group, we can run ‘net localgroup administrators johndoe /delete’


  4. Similarly, if we want to add an account or global group to the local group, we do it with ‘net localgroup administrators johndoe /add’


  5. That’s all there is to it. If you want to execute this on many computers, simultaneously, all you have to do is highlight the desired rows in your BatchPatch grid before clicking the ‘Execute’ button!
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

Remote Windows Update Script

Many sysadmins love to write scripts to solve the problems that exist in their environments. This is something we understand very well. 🙂 If you’re reading this right now then one major problem that you probably face is having to regularly ensure that your computers are completely up to date. However, some problems either aren’t so easily solved by a simple script, or are a huge time-drain to get up an running in a way that is useful enough to deploy in a production environment. When it comes to Windows Updates, in particular, frequently it’s not sufficient to simply deploy a script to remotely initiate Windows Update. As an IT administrator you often need more control. After all, if something doesn’t work right or if you can’t efficiently monitor the process, things can quickly become unwieldy, particularly when you’re working with a limited time window with critical servers that absolutely have to be online outside of maintenance periods. BatchPatch was created with the goal of helping to ease the patch management burden on systems administrators. After all, they don’t call it ‘patch installations’ for a reason. It’s a process… it’s something that, unfortunately, really has to be managed! Hence the term ‘patch management.’

In the most basic configuration for the simplest environments the goal might just be to download and install Windows Updates on all networked computers and then trigger them to reboot. Even in this seemingly straightforward process there’s actually a lot that can go wrong, especially when you are dealing with a lot of computers, and especially when there is a time crunch. And as you surely already know, there is virtually *always* a time crunch. How does the saying go? “Too much to do, too little time!” For example, what happens if a couple of computers don’t come back online after they are rebooted? If you don’t have a system that monitors uptime, how do you discover that these computers never came back online? If you do have a system that monitors uptime, usually it’s going to be disabled during the maintenance window so that it doesn’t buzz away with false alarms for every single rebooted computer. The problem here is that you won’t find out which computers haven’t come back online until *after* you’ve re-enabled your monitoring service *after* the maintenance has ended, which is too little too late!

In many environments there is a much higher degree of complexity, so the goal can’t always be as simple as downloading and installing Windows Updates on all networked computers and then triggering them to reboot. Sometimes, for example, there are dependencies across multiple computers. Maybe one computer can’t be offline unless another computer is online, and vice versa. Or maybe there are services on certain machines that have to be stopped before applying updates, and then those same services have to be re-started after the updates have been applied, with verification that the services are running properly. You might realistically want or need to execute a series of actions, in sequence, across numerous computers. And with all of this you still have the most basic requirement of needing to be able to monitor the process in real-time to make sure that when the maintenance window ends you have actually completed the entire process with all servers and services verified as being back online and performing their normal duties. Without a tool dedicated to help you with this process you’d be looking at spending practically all your working hours on patch management, which simply isn’t realistic in the IT industry. You are always going to have too much to do with too little time to do it, so choose wisely to help save yourself time and energy!

Posted in Blog, General | Tagged , | Comments closed

An Alternate Way to Check if Computers Have a Particular Windows Update Installed

BatchPatch provides a way for you to generate an update history report for all of your computers to see which computers have installed or have not installed particular updates. There is a tutorial that illustrates this method for update history reporting here: Create a Consolidated Report of Windows Update History

However, there is another way to accomplish this task that I’d like to share with you here. If you have any issues with the other method or if that method isn’t providing the information to you in a way that suits your needs, you could try this alternate method to figure out if a particular Windows Update has been or has not been installed on target systems. Depending on the situation you might find one method more suitable or desirable than the other.

Let’s say for the sake of this example that the update you want to check your computers for is KB3150513. We can use a WMIC command to ask Windows if this update is already installed or not. The command line syntax would be:

WMIC QFE WHERE HotFixID='KB3150513' GET HotFixID

Another way to write this command is:

WMIC PATH Win32_QuickFixEngineering WHERE HotFixID='KB3150513' GET HotFixID

And if you want to look for more than one update, you can also structure your command as follows:

WMIC QFE WHERE (HotFixID='KB3150513' or HotFixID='KB4015217' or HotFixID='KB4015438' or HotFixID='KB4014329' or HotFixID='KB4013418') get HotFixID

If you were to run one of the above commands at the command prompt of a given computer, you would see something like this. Note that in the second command only 2 of the specified KB IDs were found, so only 2 were printed in the result list:

However, it’s not all that practical to log on to every single target computer just to run the command above. After all, that’s why you have BatchPatch in the first place– so that you can execute commands and retrieve information from numerous computers, simultaneously. To execute one of these commands from BatchPatch on numerous target computers you can simply use the ‘Remote command (logged output)’ feature in BatchPatch.

  1. Go to ‘Actions > Execute remote process / command > Create / modify remote commands (logged output)’
  2. In the window that appears we need to add a new row and insert our command, as shown in the screenshot below:
  3. After clicking OK to the ‘remote commands (logged output)’ window we can now simply select the desired rows in the grid (I only have one computer available for testing at the moment), and then select ‘Actions > Execute remote process / command > Execute saved remote commands (logged output)’ and then click on the desired command that we just created a moment ago.
  4. When the query completes, if it finds the specified update has been installed, then it will display just like my screenshot below. If the update is not found, then the result will be empty instead.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Deploy a Specific Windows Update KB ID

Today I want to spend some time clarifying the answer to a question that we commonly receive. Some BatchPatch users want to simply deploy a particular Windows KB update to target computers. They essentially want to be able to just enter a KB ID number into the BatchPatch GUI, with BatchPatch then handling the rest of the process. However, this is not quite how it works. Below I will explain your options for deploying a specific Windows KB update.

Why Can’t I Simply Enter a KB ID Number and Have BatchPatch Handle the Rest?

Well, actually you *can* enter a KB ID directly into BatchPatch, but you need to first understand what this accomplishes in the software so that you are not confused if/when the update KB ID that you specified does not get installed.

If you use BatchPatch to initiate a Windows Update action on target hosts, BatchPatch first has to initiate a scan for available updates, and then once it finds updates that are available to the particular computer, it will download and install those updates based on any preferences and filters that you have previously configured in BatchPatch.

That said, BatchPatch allows you to enter a filter list of KB ID numbers that you want to be included during the download/install process. When the ‘include’ filter list is utilized, only updates that are on that list will be installed. Any other update that BatchPatch finds as “available” that is *not* also on the ‘include’ filter list will simply not be downloaded/installed. However, it’s also the case that if a KB ID is on the ‘include’ list but that KB ID is not found as “available” to the computer, then that KB update will *not* be installed.

The primary issue that users are sometimes confused by is that they expect if they enter a particular KB ID into the ‘include’ filter list that it will automatically always be installed. However, that is simply not the case. The ‘include’ filter list lets the administrator filter the list of “available” updates so that only a subset of those available updates are installed. If an update is not available to the computer then it does not matter if it’s in the filter list or not, it cannot and will not be installed via this method.

We demonstrate how to use the filter lists in this tutorial: Remotely Install Only a Subset of Available Windows Updates

Is It Possible to Directly Install a Specific KB ID Without First Scanning for Available Updates

You may, in fact, do a direct KB update deployment, if you desire. However, in this case you would then have to make sure that you not only have the correct update file for the target computer’s operating system, but you would also have to make sure that the target computer actually needs the update. If it does not need the update or if it’s the wrong OS, the deployment will fail. To deploy a standalone KB update file you would first need to download the update file from Microsoft. Usually the standalone updates come in the .MSU flavor, but they could also be packaged as .EXE, .MSI, or .MSP in some cases. You might even occasionally find a different package type altogether.

Once you have downloaded the desired KB update, you may follow the tutorial at the following link to deploy it directly to target computers:
Remote Script Deployment – Install Multiple .MSU Files in a Single Action on Remote Computers

2015-01-08 14_15_12-new 1 - BatchPatch X6

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

Protecting Your Machines from the WannaCry Malware

By now most of you have surely read about the new WannaCry ransomware malware that has recently been disabling computers and networks all over the planet. Protecting your computers is very easy, but you have to care enough to make sure that you’ve done what needs to be done!

Deploying the WannaCry Patch to Current / Supported Operating Systems

In March Microsoft released a Windows update to fix the file-sharing vulnerability that WannaCry utilizes to install itself in systems. If you have been regularly installing Windows updates on your computers then you should already be safe. Make sure that you have the March updates installed, but also use this time to evaluate your entire patching policy. Do you patch semi-annually or quarterly? It is my opinion that if you are not patching every single month to apply the latest Windows updates, then you are inviting malware into your network. In 2017 if you want to keep your computers and network virus-free, the absolute number one most important and simplest thing that you should be doing is applying Windows updates relatively soon after they are released by Microsoft.

Yes, it’s true that when Microsoft releases updates they can sometimes cause problems or wreak havoc on systems, so we do *not* advocate installing Windows updates on production computers on the same day that they are released. We believe the best option 99% of the time is to wait approximately 1 week after Windows updates are released before you deploy them to all of your systems. However, you *should* deploy them to your test lab on the day they are initially released, or the day after. Then wait a week to see if you have any problems in your lab and to see if any problems are reported by other users across the internet. If any patches are determined to cause problems, do your research to make the determination whether or not you should install the patches or wait for a re-release from Microsoft.

The following links demonstrate how to keep your computers up to date with BatchPatch. You may use any of these tutorials to make sure that you are protected from WannaCry:

https://batchpatch.com/using-batchpatch-to-remotely-install-windows-updates
https://batchpatch.com/remotely-install-only-a-subset-of-available-windows-updates
https://batchpatch.com/remotely-installing-windows-updates

The following link demonstrates how to see which updates have already been installed on target systems:

https://batchpatch.com/create-a-consolidated-report-of-windows-update-history

Deploying the WannaCry Patch to Unsupported / Old Operating Systems (Windows XP, Windows 2003, Windows 8)

With regard to WannaCry and older operating systems… up until a couple of days ago no patch existed for unsupported operating systems such as Windows XP, 2003, and 8. If you are still using one of these unsupported operating systems in your company, then you need to seriously consider why that’s the case. At this point in 2017 there is really almost no good reason to still be running one of these OSes, and even if you have a good reason for running one of these OSes in a corporate environment, you should still be looking to move away from them ASAP. If you’re a home user and you never got off of XP or 8, this should be a wake-up call. Your personal computer is just as vulnerable to WannaCry as any corporate machine.

If you are trying to deploy the WannaCry fix to your XP, 2003, or 8 computers, you have two options. You can use BatchPatch to apply the available Windows Updates using one of the methods outlined below in the following tutorials:

https://batchpatch.com/using-batchpatch-to-remotely-install-windows-updates
https://batchpatch.com/remotely-install-only-a-subset-of-available-windows-updates
https://batchpatch.com/remotely-installing-windows-updates

Alternatively you may deploy the standalone offline patch installer file to your target computers using the BatchPatch ‘deployment’ feature. The patch for each of the above-mentioned unsupported operating systems is linked off the bottom of this page: https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/

Instructions for deploying standalone exe, msi, msu, and msp files can be found at https://batchpatch.com/software-deployment but don’t forget about the silent /quiet installation parameter! More on that here: https://batchpatch.com/understanding-and-discovering-the-silent-parameters-required-to-remotely-deploy-software-with-batchpatch

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