We all know that keeping servers up to date is one of the most important aspects of keeping a secure environment. At one point or another every systems administrator is faced with the challenge of having to apply updates to numerous remote servers on a network. We have all been through the tedious process of manually connecting on an individual basis to each target computer, then applying updates or configuration changes, rebooting the computer, waiting 10 minutes, then checking to verify the computer did in fact reboot and that it did come back online after reboot. Multiply this process by a dozen or a hundred or even one thousand target computers, and all of a sudden the process becomes unwieldy, time-consuming, and downright stressful. The more computers that one is managing, the more quickly it becomes difficult to successfully keep track of the status of each target computer during such a process. Wouldn’t it be easier if we could just have a single console to manage all of the target computers, regardless of whether it’s 10, 20, 50, or 1000 machines?

BatchPatch was designed to make life easy for the systems administrators and engineers of the world. It enables the administrator to apply updates or make settings changes or to run scripts or applications remotely to numerous computers, simultaneously. No longer do you have to keep track of each machine individually with numerous remote desktop windows and ping windows etc. Instead you can just launch BatchPatch, add the desired target computers, select the desired action, and then just sit back and watch all target computers perform the specified action. You can install Windows Updates, deploy third party software or updates, deploy registry keys, run custom scripts, gather information for inventory or other purposes, etc. Or you can string together numerous actions into complete ‘job queues’ for single-click automation efforts.

In addition to the standard features mentioned above, BatchPatch also has unique sequencing functionality that enables the administrator to be able to create complex sequences of updates, reboots and deployments that involve numerous computers. Computers can be triggered by order in the sequence so that only certain machines are offline at any given time. The automation options are very cool, and they allow you to choreograph a “dance” of reboots and updates unlike anything you have seen before. With BatchPatch there is a surprising amount of functionality packaged into a very small executable. To read about all of the features that BatchPatch has to offer, please have a look at BatchPatch Home Page

This is one of those situations where something that seems like it ought to be very quick and simple is unfortunately not so quick and not so simple. The good news it’s also not *that* difficult, but there’s no question that it’s a pain and it takes a bit of effort.

It used to be the case that if you needed to remove a Microsoft Office Update such as KBXXXXXX that you could remove it just like you can remove any other Windows Update. In BatchPatch we have a couple of built-in options for executing the update removal process of a particular Windows Update that you can access under ‘Actions > Windows Updates > Uninstall individual update…‘ To use those menu items all you need is the KB number of the update that you want to remove.

Unfortunately for a while now the above-mentioned built-in commands for removing individual updates is only successful for standard Windows operating system updates. Microsoft Office updates, on the other hand, require a different removal command that unfortunately involves some manual digging.

The command line syntax options for removing a MSOffice update are as follows, but you have to substitute the correct Office GUID and Patch GUID values into your command, and this is what makes the process frustrating/tedious:

msiexec.exe /package {Office GUID} /uninstall {Patch GUID} /QN

msiexec.exe /package {Office GUID} /uninstall {Patch GUID} /QN REBOOT=REALLYSUPPRESS

This Microsoft Blog article explains the process for locating the correct GUIDs in the registry for the patch that you wish to uninstall.

After you find the appropriate GUIDs, you can form the actual command to use to remove the update. So, for example, the following command is an example of what your command will actually look like, as I have inserted actual GUID values, but as previously mentioned, you’ll need to find the GUIDs for the product and patch that you are removing.

c:\windows\system32\msiexec.exe /package {90140000-0012-0000-1000-0000000FF1CE} /uninstall {B23AAF3E-F931-4C72-8D96-7E58363A3D12} /qn

Once you have determined the proper syntax and have run it successfully on your test computer, you may insert it into a ‘Remote Command’ in BatchPatch. Highlight the desired target computer rows in the BatchPatch grid. Then select ‘Actions > Execute remote process/command > Create/modify remote command 1‘

Paste your command into the field, as illustrated in the screenshot above. Then either ‘Execute’ the command immediately or choose ‘Apply…’ to execute it later. Another option for executing at a later time/date is to hard-code the command into the BatchPatch menu by using ‘Actions > Execute remote process/command > Create/modify remote commands‘ In this case I have used ‘Apply…’ to apply the commands to each of the highlighted rows, which you can see in the screenshot below.

Now I can execute the applied command for each/every row by just selecting the rows that I want to include, and then clicking ‘Actions > Execute remote process/command > Execute remote command 1‘

When you are working in a network environment without a domain– that is to say there are no domain controllers and no member servers because all computers are simply part of a workgroup, authentication can be a challenge when trying to perform operations remotely. Generally speaking, if you have a network with enough computers where there is a need to perform any tasks remotely, you should ask yourself “Why is there no domain established yet?” because realistically there probably ought to be one. However, let’s assume that for whatever reason there is not already a domain and there is not going to be a domain, but you have tasks to perform on remote computers, then what?

OK, so the main issue you need to be aware of when dealing with remote WMI connections is User Account Control (UAC). In a workgroup/non-domain environment there will never be domain logon accounts, so all accounts that one needs to deal with are going to be local accounts. However, when working with local accounts, in order to execute many (not all) remote WMI queries or methods, remote UAC actually needs to be disabled on each target computer that is being operated on.

Disabling Remote UAC

Remote UAC is controlled by a single registry value. If the local account you are using to run the query (or in the case of BatchPatch, the account you are using to run BatchPatch or the account that you specify in the ‘alternate credentials’ field in BatchPatch) is not THE built-in administrator account on the target computers, but instead is just a regular named local account that is a member of the local administrators group on the target computers, then in order to disable remote UAC the following registry DWORD must be set to 1 on the target computers. If the DWORD does not exist or is set to 0, then remote UAC is enabled, and you will generally get ‘Access Denied’ when trying to perform a remote WMI query. To disable remote UAC, set the value of the following registry DWORD to 1. If the DWORD does not exist, then you must create it:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy

(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016 targets. NOT required for XP/2003 targets)

Disabling Admin-Approval Mode (Enabling Full-Token Mode) for the Built-in Administrator Account

Unfortunately that’s not everything. What if you are using THE built-in administrator account (as opposed to a regular named local account that is a member of the local administrators group on the target computers)? If the local account you are using to execute the WMI query/method is THE built-in administrator account on the target computers, the following registry DWORD must be set to 0 on the target computers. If the DWORD does not exist, then you must create it. When this DWORD is set to 0, the built-in administrator account is set to full-token mode, and WMI queries (including WMI queries executed through BatchPatch) will work propertly. However, if it’s set to 1, the built-in administrator account is put in admin-approval mode, which will prevent most remote WMI actions (including most BatchPatch actions) from completing successfully for those target computers:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\FilterAdministratorToken

(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016 targets. NOT required for XP/2003 targets)

Microsoft discusses remote UAC in more detail here. We discuss more about authentication options for BatchPatch here.

OK, so you have a lot of computers on your network, and you need a way to quickly install Windows Updates and/or 3rd party software updates on all computers without having to connect to each computer individually to initiate and monitor the install. BatchPatch to the rescue!

If you haven’t already done so, I would encourage you to download the free BatchPatch evaluation version. While the evaluation is limited to a maximum of 4 simultaneous target hosts, there is no time limit, and other features in the app are fully functional. This gives you a very simple way to try BatchPatch at no cost, configure your environment to work with it, and then take your time to decide if you want to purchase licenses.

Assuming that this is your first time trying the application, you’ll want to review the ‘Getting Started‘ posting to see how to configure your environment to work with BatchPatch. This tutorial goes through all of the elements that need to be addressed for setting up BatchPatch, from permissions to firewalls, though in many environments BatchPatch will just work right out of the box with no additional configuration required.

After you get the basics down, like installing Windows Updates remotely, and deploying software to numerous computers, you can test out the more advanced features like the job queue, the task scheduler, and the advanced multi-row queue sequence.

Hopefully you’ll not only begin to see just how simple it is to use BatchPatch to get your entire network of computers updated, regardless of whether you have an internal WSUS or use Windows Update or Microsoft Update, regardless of whether your computers are internet-connected or not, and even if you simply don’t have a lot of free time on your hands! BatchPatch allows you to truly minimize the amount of time and effort needed to patch computers. I continue to be amazed by how many customers have written notes to us to let us know that BatchPatch paid for itself in just the first few hours of usage based on how many man-hours it saves.

To review the full list of features and functionality that BatchPatch offers, please check out the home page. If you have any questions, problems, or concerns, don’t hesitate to reach out to us.

When it comes to performing Windows updates on an entire network of computers, there are a number of things that frequently need to be addressed, depending on the size of the environment, the number of actual target systems, the service-level agreements in place, the length and frequency of the maintenance windows, and so on. When we first started working on BatchPatch one of our goals was to try to address the needs of technology administrators in a tight package that would enable scaling from small to large environments without requiring a hefty infrastructure just to run the patching tools, and without being difficult or clunky to operate. It seems like one of the common problems that sysadmins regularly face when it comes to software management tools is that if they want more features and functionality or if they have to manage a larger environment, then the software options out there for them tend to be extremely expensive or very difficult to install or challenging to learn to operate or just plain clunky and unappealing to use. And sometimes the management systems might even require numerous servers of their own, which only adds to the expense.

In BatchPatch we feel we’ve done a good job at balancing all of the elements in a package that is very small and efficient, inexpensive, and very feature-packed. There are features in BatchPatch that “just work” that you simply will not find anywhere else. And many of the features that do find somewhere else were directly lifted from BatchPatch anyway. However, we believe even with that being the case, the value offering that BatchPatch provides simply cannot be matched. In the large majority of cases BatchPatch pays for itself in time saved usually in just the first or second use.

Today let’s review, at a basic level, how to use BatchPatch to accomplish your Windows update and general patch management tasks. The main BatchPatch interface is a grid, similar to a spreadsheet, that allows you to simply populate it with a list of target servers (or workstations, laptops, etc). There is no complex or time consuming process for adding new hosts, and you don’t have to wait around to deploy a persistent agent to targets. You can simply type the name or IP of computer, and then you’ll see it appears in the grid instantly. Alternatively you can query your Active Directory OUs and groups as another method to populate the grid, and of course you can always drag and drop (or use ‘File > Open’ or ‘File > Import’) to get an existing list of computers into the grid from a text file, CSV file, or a similar delimited file. Once you have hosts in the grid, you can simply highlight/select the desired ones, and then choose an option to execute from the ‘Actions’ menu or the ‘right-click’ menu. So in the screenshot below you can see that with the selected hosts I am about to choose ‘Download and install updates + reboot if required.’ All of the selected hosts will begin processing updates right away, and BatchPatch will monitor their statuses during the entire process, showing the completion percentage of the download and then the completion percentage of the install. Then finally when the update installation has completed, BatchPatch will initiate and monitor the reboot process until the computer is back online. It’s just as simple as that to execute virtually all of the different available actions/options in BatchPatch.

In the August 2018 release of BatchPatch, one of the new features that we added is the ‘Row Template Configurator’, which is available under ‘Grid > Row template configurator’. When you add new rows to a grid, sometimes it might be helpful to have the new rows be automatically configured with certain values such as scheduled task, job queue, deployment, remote or local command, etc. This is especially the case for users who have their grids configured to automatically synchronize with OUs/groups in Active Directory. After all, when you are automatically adding hosts/rows to a grid on a schedule, it’s common to also want other values automatically applied to the new hosts/rows too. Note, each grid can have its own row template configured/linked. This way if you want hosts that are added to one particular grid to be automatically populated with certain values, but you want hosts added to a different grid to be automatically populated with different values, you can do it very easily by applying a different row template to each grid. To use the row template configurator follow the instructions below.

1. Start with a regular row in the main BatchPatch grid. Apply any values you want to the row, such as a job queue or scheduled task or deployment or remote command or local command etc. The idea here is that you’ll create a row in the main grid that contains all of the values/columns that you would like to be automatically included for new rows that are added to the grid.
2. Once you have created a “template” row in the main grid, select ‘Grid > Row template configurator’ to launch the row template configurator form.
   
3. With the row that you created in the main form still highlighted, click the button ‘Create/update row template based on selected row in main BatchPatch grid.
4. After clicking the ‘Create/update…’ button you’ll see a single row appear the ‘Row Template’ grid. This row will contain any templatizable values from the main grid’s selected row. So if the main grid has a scheduled task configured, the row template will now show the same scheduled task values. Same goes for any job queues, deployments, commands, notes etc. They will all get included in the row template, and they will be visible in the new row template row that appears in the ‘Row Template Configurator’ form.
   
5. Now that you have configured the row template values, you need to actually enable the row template for the grid. The default setting is ‘Disabled’ which means that if you add new rows/hosts to this grid, nothing special will occur. But as soon as you switch the radio button to ‘Enabled’ and click OK, then all new rows added to the grid will automatically receive any values that were set in the row template.
   
6. So now if you look at my existing grid I have ‘host1’ showing a scheduled task configured, but host2, host3, host4, and host5 show nothing. Since I’ve just enabled a new row template for the grid, based on host1, watch what happens when I add more hosts to the grid.
   
7. All the newly added rows/hosts look identical to the row for host1. This is all thanks to the row template that we enabled for this grid.
   

We know that many of you have been looking forward to this new functionality. As always, if you have any comments or suggestions, don’t hesitate to contact us to let us know.

In BatchPatch most users enter each host name into the grid without using the entire fully qualified domain name (FQDN) or IP address. In general, for most situations entering just the host names will be sufficient. However, many users have more complex network environments, and sometimes it won’t be sufficient to enter just the unqualified single-label host name without using the FQDN or IP address. This is because when there are multiple domains involved, and a given target computer is not on the same domain as the BatchPatch computer, Windows will not automatically know what the proper DNS suffix for the target computer is unless DNS suffixes have already been configured for the network interface of the BatchPatch computer. That is to say, in a multi-domain environment, it’s often the case that the network and systems administrators will configure group policy for the domain to include a list of DNS suffixes on every member computer’s network interface, so that if a user of any computer in the domain types, for example, “ping computerX” into a cmd prompt, Windows can try each of the DNS suffixes defined on the network interface to locate computerX. So, if the 3 DNS suffixes are:

domain1.com
domain2.com
domain3.com

Behind the scenes Windows can lookup computerx.domain1.com, computerx.domain2.com, and computerx.domain3.com until it finds a host (A) record in DNS for computerx. So let’s say computerx is actually computerx.domain3.com. When the DNS suffixes on the network interface are set properly, instead of having to enter computerx.domain3.com into BatchPatch, you can simply add the host as computerx.

You can add a DNS suffix to the search list on the BatchPatch computer directly/manually by doing the following:

Manual/direct DNS Suffix Additions/Modifications:

1. In Windows select ‘Start > Run‘ and type control netconnections. Then click OK.
   
2. In the control panel network connections window that appears, select the active network interface. Right-click on it and select Properties.
   
3. In the Properties window select Internet Protocol Version 4 (TCP/IPv4), and then click the Properties button.
   
4. In the following window that appears titled Internet Protocol Version 4 (TCP/IPv4) Properties, click the ‘Advanced’ button.
   
5. In the ‘Advanced TCP/IP Settings‘ window, click on the DNS tab.
   
6. In the DNS tab click the radio button that says ‘Append these DNS suffixes (in order):‘ and click ‘Add’ to add each desired DNS suffix.
   

Group Policy DNS Suffix Additions/Modifications:

If you want to apply the same DNS suffix list to many computers, then rather than applying them manually/directly, you should consider using Group Policy to apply them instead.

1. On a computer that has the domain administrative tools installed, or on a domain controller, click Start > Programs > Administrative Tools > Group Policy Management
2. In Group Policy Management, expand the forest and the domain in which you will apply Group Policy. Right-click Group Policy Objects, and then click New.
3. In New GPO, type a name for the policy, and then click OK.
4. Right-click the new policy that you created in Step 4, and then click Edit.
5. In Group Policy Management Editor, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, and then click DNS Client.
6. Right-click DNS Suffix Search List, click All Tasks, and then click Edit.
7. On the DNS Suffix Search List Properties page, select Enabled. In the DNS Suffixes box, type the desired DNS suffixes. Click OK.
8. In Group Policy Management, expand Group Policy Objects, and then select the policy that you created in Step 4. On the Scope tab, scope the policy so that it applies to the desired comptuers.

BatchPatch provides multiple different options for applying Windows Updates to numerous target computers simultaneously. In all cases the process involves loading a list of computer names or IP addresses into a BatchPatch grid, selecting/highlighting the desired target computers in the grid, and then choosing an action from the BatchPatch Actions menu to execute on the selected computers.

BatchPatch can initiate the Windows update process on numerous computers simultaneously. They can be instructed to retrieve updates from your local WSUS, Microsoft’s public ‘Windows Update’ server, or Microsoft’s public ‘Microsoft Update’ server. Additionally, it’s possible to “push” the updates to target computers from the BatchPatch computer rather than having the target computers “pull” updates from an update server. And finally, updates can even be applied to target computers that do not have any interest access.

In BatchPatch’s default/normal mode, when BatchPatch triggers a group of target computers to initiate the download and installation of Windows updates, the target computers will search for updates on a local WSUS or on Microsoft’s public Windows update server, depending on the existing configuration of the target computers. In this default mode BatchPatch will utilize the pre-existing configuration on each target computer to determine where each target computer will search for updates to download and install. However, BatchPatch can also be instructed to override the target computer’s default configuration so that, for example, updates are downloaded directly from Microft’s public update server rather than from an internal/local WSUS server. The different Windows Update options that BatchPatch offers can be viewed under ‘Tools > Settings > Windows Update’

When BatchPatch’s ‘cached mode’ is enabled, the administrator is provided with even more options for distributing Windows updates to target computers. The following page goes into detail about all of the different cached mode options including ‘offline mode’ which provides functionality to deploy Windows updates to computers that don’t have internet access.

BatchPatch Cached Mode And Offline Windows Update

Excerpt:

• When ‘cached mode’ is enabled, the computer that is running BatchPatch will download all updates directly to its own local repository. Once downloaded to BatchPatch’s local repository, BatchPatch will handle distributing the updates to target computers. Target computers will not download their own updates from Microsoft, thus significantly reducing the overall amount of internet bandwidth used to retrieve Windows Updates.
• When ‘cached mode’ is enabled without also enabling ‘offline mode’, target computers still require internet access because each target computer will perform its own online search for updates against Microsoft’s server. However, the actual download process will take place on the BatchPatch computer, not on the target computers, thus saving internet bandwidth since any available update will only be downloaded one time by the BatchPatch computer rather than being downloaded one time by each target computer. Once BatchPatch has downloaded updates to its cache, it is able to distribute them to target computers.
• When ‘offline mode’ is enabled in conjunction with ‘cached mode’ each target computer does an offline search for available security updates, utilizing the offline scan file (wsusscn2.cab) that Microsoft provides, which means that target computers do not need to have internet access. The actual update download process will only take place through the BatchPatch computer. Once BatchPatch has downloaded updates to its cache, it is able to distribute them to target computers. With ‘offline mode’ it is also possible to download updates on a BatchPatch computer that has internet access, and then manually move the entire update cache repository to a computer or network that has no internet access, enabling you to distribute Windows Updates security updates to computers on a completely offline network.

We recently received a request for help with using BatchPatch to copy a Microsoft Outlook signature file to the appropriate user profile directory on numerous target computers. BatchPatch already has a built-in function for copying files from the BatchPatch computer to a specified directory on target computers, but a problem arises when trying to copy a file to all user profile directories on target computers because the ‘copy file/folder’ function in BatchPatch requires you to enter a specific folder, by name. How then is the administrator able to copy a file to multiple user profile directories without knowing in advance which user profiles are on which computers?

The solution to the problem outlined above involves some custom scripting. There’s no way around it. However, with a very simple script, one can then use BatchPatch to deploy the script to all of the desired target computers, thereby enabling the copying of the desired file to all the desired target computers in the user profile folders on those computers.

In the particular question that we received the user needed to copy an Outlook signature file into each user profile directory — %userprofile%\AppData\Roaming\Microsoft\Signatures\. In order to do this we need to write a script that will first enumerate each of the user profile directories on the computer, and then will copy the desired file(s) into each user profile directory. Then use BatchPatch to deploy the script and the signature file to all of the desired target computers.

1. Create a vbscript by pasting the following script text into a text document titled something like ‘script.vbs’. The .vbs file extension is required, but you may provide any name you desire for the file. The script below, when run on a computer, will check the registry to find out all of the user profile directories on the computer. It will then loop through and copy a file called “signature.file” from the folder that contains the script to each of the Outlook signatures folders on the computer. Note, we skip any profile directories that begin with ‘C:\Windows’ because we are interested in regular user profile directories that generally begin with C:\Users, so we have to discard the few that start with C:\Windows.
   

   On Error Resume Next Const HKEY_LOCAL_MACHINE = &H80000002 strComputer = "." Set objRegistry=GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv") strKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" objRegistry.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubkeys For Each objSubkey In arrSubkeys strValueName = "ProfileImagePath" strSubPath = strKeyPath & "\" & objSubkey objRegistry.GetExpandedStringValue HKEY_LOCAL_MACHINE,strSubPath,strValueName,strValue Set fso = CreateObject("Scripting.FileSystemObject") If InStr(Ucase(strValue),"C:\WINDOWS") = 0 Then ' Wscript.Echo strValue & "\AppData\Roaming\Microsoft\Signatures\" fso.CopyFile "signature.file", strValue & "\AppData\Roaming\Microsoft\Signatures\", True End If Next

2. Once we have the above script text saved to ‘script.vbs’ it’s actually very easy to deploy it with our signature.file. You’ll want to modify the script to substitute the actual name of your signature file for what I have just called ‘signature.file’ for the sake of this example.
3. Put ‘script.vbs’ and ‘signature.file’ into a single folder on the BatchPatch computer. Make sure there is nothing else in that folder.
   
4. Now you are ready to deploy the script using BatchPatch. In BatchPatch highlight the desired target computers in the grid. Then select ‘Actions > Deploy > Create/modify deployment’. In the deployment window you’ll select the file to deploy as the ‘script.vbs’. Then you’ll tick the box that says ‘Copy entire directory…’




5. To begin the deployment, click on the ‘Execute’ button. When you do this BatchPatch will copy the folder containing the ‘script.vbs’ and ‘signature.file’ files to each selected target computer. BatchPatch will then execute the ‘script.vbs’ which will determine all of the user profile folders on each computer that it runs on, and it will copy the ‘signature.file’ file to each of the enumerated user profile folders.

This is a simple topic that barely warrants a whole blog posting, but I wanted to put it out there so that people can find it more easily. When you want to share your saved configurations in BatchPatch with a different BatchPatch user at your organization, or when you want or need to move your entire BatchPatch instance from one server to another, you can do it very quickly and painlessly by following the steps below.

1. Regardless of whether you are moving the entire BatchPatch installation or if you are just sharing your saved deployments, job queues, remote commands, copy jobs etc with a colleague, you’ll need to start by exporting the saved items to a file. In BatchPatch select ‘Tools > Export saved commands, deployments, job queues, etc.’
   
2. You will be prompted to choose a location on disk to save the export file. Go ahead and save it. You can give it any name that you want. You can see in the screenshot below that I’ve titled my export file ‘BatchPatch_Settings_Export_2018-10-18’.
   
   Note, the format of the file is standard XML, so it can be opened in a text editor. I would not recommend making any modifications to this file because it’s always easy to break things by adding or removing a space or linebreak in such a way that it causes the XML importer to balk. However, certainly if you had a strong need or desire to make modifications, you could do it. Generally though it probably makes the most sense to make modifications to your saved commands/configurations inside of BatchPatch first. Then when you create the export file it will already contain everything that you need with the correct syntax.
3. If you are moving your BatchPatch installation to a new computer, move the batchpatch.exe from the old to the new machine along with the XML file you created in the previous step. If not, then just copy the XML file to the desired destination.
4. Finally, import the file using ‘Tools > Import saved commands, deployments, job queues, etc.’
   
5. It’s also not a bad idea to periodically backup your existing saved entries by using ‘Tools > Export saved commands, deployments, job queues, etc.’ This way if you lose the server that BatchPatch is running on or if you encounter some type of weird corruption you’ll be able to more easily get back your previously saved entries without having to re-create them from scratch.

I think the ‘Row Template Configurator’ falls into the category of features that most people probably are not even aware of but would use if they knew it existed. This feature was published just a couple months ago. If you haven’t yet checked it out, now might be a good time to familiarize yourself with it.

The idea is simple… each grid can have its own Row Template. You can add anything to a row template that you would add to a normal row in BatchPatch. And once something exists in the template, then when you add a new row to the grid, the new row will receive all of the values that are applied to the template row. This is particular useful for those admins who have their BatchPatch grids configured to synchronize with Active Directory. When the sync operation is performed, new rows get automatically added to the grid. If you have configured a row template for the grid, then when those new rows are added during the sync you can have them automatically include a scheduled task or job queue or deployment etc.

Here’s how it works:

1. Each grid has its own template, so to start please create a new row in the grid and add whatever you want to that row such as a job queue or scheduled task or remote command etc. In the screenshot below you can see that I have created a row and applied a recurring scheduled task to ‘Download and install updates + reboot if required’
   
2. Once you have your row configured with the desired values, it’s time to use it to create the grid’s row template. In BatchPatch click on ‘Grid > Row Template Configurator’. In the ‘Row Template Configurator’ window that appears click on the button ‘Create/update row template…’. In the screenshot below I’ve done exactly that. You can see that the ‘Row Template Configurator’ form now shows a copy of the row contents from the previous step. The Host column is excluded, of course, because the host name will never be part of the template since each row will have its own host name already.
   
3. Now that I have created the row template, if I want to activate it I need to set the ‘Row Template Status’ radio button in the upper right corner to ‘Enabled’. If it is left ‘Disabled’ then even though the row template will have been created for the grid, it won’t be active. New hosts added to the grid will not receive the template values until/unless you first enable it. In the screenshot below you can see that I have selected the radio button labeled ‘Enabled’. Click OK after enabling the template.
   
4. OK, now that we’ve created the row template all we have to do is add some new rows to the grid. Notice that the new rows automatically receive the values that were included in the template. I just added 5 new hosts to the grid, and they all look the same as the original SAMPLE row. Note, the SAMPLE row does not need to be left in the grid. I’ve left it there only for the sake of illustration.
   

I’ve previously written about configuring email notifications in BatchPatch. You can find those postings here and here. However, today I’d like to focus on an aspect of email notifications that I have not yet discussed in much detail. Today the focus is going to be on the situation where you need or want to have each host trigger its own email notification at the end of a patching operation. The emails can be configured to all be sent to a single administrator or group of administrators, or you can even configure each host to send to a separate administrator or group, if desired.

1. First please note that there are global settings and well as per-host settings for email notifications. If you want all hosts to send notifications in the same format and to the same recipients, then you can simply use the global settings without touching any of the per-host overrides. However, if you want to have emails be sent to different recipients per target host, then you would need to use the per-host overrides. We’ll get into that later. Start by examining your global email notification settings under ‘Tools > Settings > Email notifications’
   
2. Fill out all of the form with the desired information. You’ll need to specify a ‘from’ email address as well as recipients, the SMTP server address and port and logon credentials, if needed. For the body format we recommend plain text PLUS ‘Include HTML Attachment’. For the body text we have a few options. BatchPatch has some built-in variables for email notifications, which help you to customize the notification format:
   • $host – Will print the host name from the row that initiates the email notification
   • $row – Will print the entire row contents from the row that initiates the email notification
   • $grid – Will print the entire grid contents for just the grid that contains the row that initiated the email notification
   • $allgrids – Will print the contents of all grids in the BatchPatch instance

   In this tutorial since our goal is to have each host/row generate its own email notification after applying updates, we’re going to have the email alert only contain the $row variable, so that each email notification that is sent only contains information about the particular row/host that triggered the email notification. So as you can see in the screenshot above, the body text field only has $row listed.

3. Click the ‘Test email settings‘ button to make sure that BatchPatch is able to send a test email notification using the settings that you specified. If there is an error here during the test, it will need to be resolved before continuing.
4. Now that the global email notification settings have been completed, it’s time to configure a job queue for each row. The idea here is that each row will execute a job queue that includes applying Windows Updates. As the last step in the job queue we include the ‘Send email notification’ instruction.
   Select the desired target hosts in the grid, and then click ‘Actions > Job Queue > Create/modify…’ Create your queue, and then apply ‘Send email notification’ as the last step in the queue, just like what you see in my screenshot below, and then save the queue.
   
5. If you want or need any individual hosts/rows to send their email notifications to different recipients, then here you can optionally override the global/default email notification settings on a per-row basis, as needed. For example, let’s configure ‘host1’ in my grid with a new/different email recipient. I’ll select ‘host1’ and then ‘Actions > Email notifications > Override default email notification settings‘
   
6. In the window that appears you can see that I have ticked the ‘Recipients’ box and then typed in a new recipient email address. When this row triggers an email alert, it will send the email to this address instead of the addresses listed in the global settings that we modified at the beginning of this tutorial.
   
7. At this point you’re done. You can execute the job queue either on-demand or via a scheduled task. When the job queue completes, the last step it executes will be the email notification step. Each host/row that runs that job queue will send its own notification to the hosts defined in the global email notification settings, with the exception of host1, which will use the email recipient that was specified in the ‘Override default email notification settings’ window.

If your anti-virus software has been configured to block PsExec through some type of execution policy, here are your options for getting it working again:

1. Perhaps the most obvious method would be to modify the execution policy so that it no longer blocks PsExec.
2. Another option, if your AV software has such functionality, is to whitelist PsExec. In this case you should whitelist psexec.exe as well as psexesvc.exe
3. The simplest method to prevent your antivirus software from blocking PsExec is actually using a built-in switch that PsExec offers to change the remote service name. This option exists in PsExec version 2+. This method works for the large majority of situations, but depending on the actual blocking mechanism that has been used in your environment, it’s possible that this method might not work for you.

   -r Specifies the name of the remote service to create or interact with

   Under normal circumstances when PsExec.exe is executed on computer A, it creates a connection to a target computer B. On computer B a new service is created called PSEXESVC with an executable file psexesvc.exe. When you use the -r switch you are able to specify a new/different service name to be used, so the target computer will create a service and associated executable with the name you specific rather than the default/generic psexesvc. Believe it or not, this is actually enough to bypass or prevent detection in many/most cases, though again I would note that it really depends on the actual blocking mechanism that’s in place in your environment.

   This switch can be utilized when working with PsExec directly at the command line on a particular computer or it can also be used inside of BatchPatch. In BatchPatch go to ‘Tools > Settings > Remote Execution’. You’ll need to modify the value next to ‘Use PsExec -r switch to specify remote service name’. You can use any name that you want here. BatchPatchExeSvc is not a bad choice, and it’s what I have specified in my instance of BatchPatch, as you can see in the screenshot below.

   Normally it’s just the remote service PSEXESVC and/or psexesvc.exe that is blocked by an execution policy, but if you want you could go a step further and actually provide a new name for the PsExec.exe too. This file normally only would exist on the BatchPatch computer. You can change its name to whatever you want such as YourCustomName.exe and then in BatchPatch modify the value for ‘Use psexec.exe custom filepath:‘ which also lives under Tools > Settings > Remote Execution. You’ll need to specify the full filepath to your newly named .exe file, so for example C:\YourDesiredPath\YourCustomName.exe

One of the questions that people sometimes ask us is can BatchPatch initiate the Windows Update download/installation on target computers *without* also triggering an immediate reboot of those computers? The short answer is yes. The longer answer is that controlling the behavior in BatchPatch is very straightforward and simple, but the behavior of BatchPatch isn’t really what you have to worry about. It’s Windows and the various settings provided by Windows for reboots after updates that you have to be concerned about.

For this posting I’m going to focus on Windows 10 options when it comes to reboots after updates. Other Windows operating systems may vary, but since Windows 10 is the latest version of Windows, I think it makes the most sense to focus on Windows 10.

In BatchPatch you have numerous options for applying Windows Updates. The primary action items to select from in BatchPatch when downloading and/or installing updates are:

• Download available updates
• Download and install updates
• Download and install updates + reboot if required
• Download and install updates + reboot always
• Install downloaded updates
• Install downloaded updates + reboot if required
• Install downloaded updates + reboot always

If you select one of the options that does not include reboot, BatchPatch will not reboot the target(s) after installing updates. You can, optionally, always come back at any time with BatchPatch and execute a standalone reboot, but the topic of today’s posting is about controlling reboot behavior specifically for when installing Windows Updates.

The first thing that you should do is acquaint yourself with the different options that Windows provides via Group Policy for controlling computer restarts around Windows Updates installations. Once you’re well acquainted you can then test accordingly so that you can determine exactly the behavior to expect in your environment based on the settings that you select. The primary settings to control reboot after Windows Updates all live in Group Policy in Computer Configuration\Administrative Templates\Windows Components\Windows Update It’s actually possible to control all of these policies via direct registry edits too, but for ease of operation it’s really best to control these settings via Group Policy (or of course you may also use Local Policy if you’re not on a domain).

Turn off auto-restart for updates during active hours
Use this policy to configure active hours, during which the device will not be restarted. This policy has no effect if the No auto-restart with logged on users for scheduled automatic updates installations or Always automatically restart at the scheduled time policies are enabled.

Always automatically restart at the scheduled time
Use this policy to configure a restart timer (between 15 and 180 minutes) that will start immediately after Windows Update installs important updates. This policy has no effect if the No auto-restart with logged on users for scheduled automatic updates installations policy is enabled.

Specify deadline before auto-restart for update installation
Use this policy to specify how many days (between 2 and 14) an automatic restart can be delayed. This policy has no effect if the No auto-restart with logged on users for scheduled automatic updates installations or Always automatically restart at the scheduled time policies are enabled.

No auto-restart with logged on users for scheduled automatic updates installations
Use this policy to prevent automatic restart when a user is logged on. This policy applies only when the Configure Automatic Updates policy is configured to perform scheduled installations of updates.
There is no equivalent MDM policy setting for Windows 10 Mobile.

You can review more details about managing Windows device restarts after updates at this link: Manage device restarts after updates

Windows does not offer/provide a sanctioned, singular way to determine with certainty if a computer is in need of a reboot. However, Windows does mark in several places in the OS values that can be used to infer that a reboot is required to complete certain operations.

When using one of the ‘Get pending reboot status‘ actions in BatchPatch, a check is initiated that looks in the following locations of the target computer(s) to determine if reboot is needed:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update

If a subkey contains “RebootRequired” BatchPatch returns TRUE

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing

If a subkey contains “RebootPending” BatchPatch returns TRUE

HKLM\SOFTWARE\Microsoft\Updates

If the UpdateExeVolatile value exists and is greater than 0, BatchPatch returns TRUE

CCM_ClientUtilities.DetermineIfRebootPending method

If the host has SCCM installed and this method returns TRUE, BatchPatch returns TRUE

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager

If the PendingFileRenameOperations value contains any filepaths, BatchPatch displays them, but this will not cause BatchPatch to return TRUE even though the rename operations will occur upon reboot.

All that said, when you use ‘Get pending reboot status’ and it returns TRUE it doesn’t mean that you absolutely must reboot the computer. It means that Windows has operations that are pending reboot to be completed. It does not necessarily mean that the computer is in an unstable or problematic state.

If you use one of the BatchPatch methods to install Windows updates, but you do not let BatchPatch also ‘reboot if required‘ then you could leave your computers in an unstable/unprotected/vulnerable state since it is the case that some updates will not be “live” until the reboot occurs. However, if you are rebooting the computers after Windows updates are installed, but then at a later date ‘Get pending reboot status‘ reports TRUE, it does not necessarily mean that the sky is falling and that you must drop everything and reboot immediately, though it may warrant further investigation to see why BatchPatch is reporting TRUE so that you can determine if you want to reboot the computers or not.

We recently received the following questions: “How can one tell if Adobe Flash is installed on numerous target computers? If it’s installed, what’s the best way to determine which version is on each target?”

Today I’m going to demonstrate one possible way to get the desired information, but there are probably other equally viable methods, so definitely feel free to do what works best for you and your environment.

Get List of All Installed Applications

First, note that in BatchPatch there is a built-in menu item ‘Actions > Get information > Get list of installed programs‘ that one can use to obtain a list of all installed programs on target computers. This action queries the following two registry keys on target computers to obtain a list of installed applications. While this list is generally going to be pretty comprehensive, please be aware that a program can be installed without having ever registered itself with the system, so it’s possible that you could have an app that does not appear in the output list that this method obtains. Also note, this output will not necessarily include version numbers. Additionally, this output will generally include duplicate entries because many applications will be entered into both of the following registry keys as opposed to just one. For the sake of completeness BatchPatch gets information from both keys and does not extract unique results, which means that if an application is entered in both locations you will see it appear twice in the list.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall

Sample output:

Get Adobe Flash Version Number

A very quick Google search revealed this link ( https://forums.adobe.com/thread/912422 ) which explains that Adobe Flash version information can be obtained by looking at the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Macromedia

In BatchPatch we can obtain registry values from numerous computers simultaneously by selecting the desired computers in the BatchPatch grid and then executing ‘Actions > Get information > Get registry key/value‘, which will pop the following window:

In the window shown in the above screenshot you can add the desired registry key and value that you would like to read. Once the appropriate key and value name are entered, click OK to see the results.

We can see in the above screenshot of the result that the test computer I queried has version version 18.0.0.203. If a target computer does not have Adobe Flash installed at all, then we would expect this ‘Get registry key/value’ to return nothing for the registry key and value that we queried. Pretty simple! I hope this helps.

One of the topics that I have written about in the past is how you can configure filters in BatchPatch to prevent certain categories of updates from installing, or so that you can exclude particular individual updates from being installed on target computers. Those postings are here:

Filter Which Available Updates Are Included Or Excluded When Downloading Or Installing Windows Updates

Remotely Install Only A Subset Of Available Windows Updates

Additionally I have posted in the past about the ‘Row Template’ feature in BatchPatch here:

Using A Row Template To Automatically Apply Tasks To New Rows In A BatchPatch Grid

Automatically Apply Scheduled Tasks Job Queues Deployments And Commands To New Rows With The Row Template Configurator

Apply Update Exclusions Per-Grid Using the Row Template

Today I’m going to demonstrate how you can use the ‘Row Template’ feature to pre-configure a grid with Windows Update filters that will enable you to exclude certain updates from being applied to target computers, depending on which grid you add the computers to.

The ‘Row Template’ feature enables you to create a single template row for each grid. After you enable a row template for a given grid, then when you add new rows/hosts to that grid, the new rows/hosts will receive the pre-configured values that you have stored in the row template for that grid. This may sound confusing when written down, but in practice it’s actually very simple.

For example, let’s say that you have a group of SQL servers that you manage in a single BatchPatch grid. You want to ensure that these SQL servers will not install a particular update KB112233, and you want to also ensure that when new SQL servers are added to this same grid that none of them install the update either. However, you also have a separate group of web servers that you manage in a separate BatchPatch grid, and for these web servers you want them to apply KB112233, but you don’t want them to apply KB445566. And similarly, you want to ensure that when a new web server is added to the BatchPatch grid (.bps) file that it will have the same exclusion/filter rules configured as the existing servers in the grid. How can you do this?

In BatchPatch we can create a row template on a per-grid basis, and then in the row template we can store the Windows Update filters / exclusions, so that any time a new row/host is added to a grid, it will automatically receive any values that were pre-configured in the row template. This means that the new hosts/rows can automatically receive the same Windows Update filters / exclusions that exist for other hosts in the same grid.

Here’s how it works:

1. First we need to create a row template for our grid. For the sake of this example we will create a row template that will include an exclusions for update KB112233, so that KB112233 is never installed on computers that are added to this grid. In our grid we have 3 hosts to start. Create a Windows Update exclusion filter by selecting the rows and then clicking ‘Actions > Windows updates > Filter which available updates are included or excluded when downloading/installing > Exclude specific updates (textual)…’
   
2. In the exclusions window that appears I will type/paste the KB112233 that I want to be excluded from being applied to the computers in this grid. Then I’ll click Save. You can see in the screenshots below what this process looks like.
   
   
3. Now we can use one of the existing rows in the grid to create a row template. Select just a single row in the grid, and now click ‘Grid > Row template configurator’. In the window that appears click ‘Create/update row template based on selected row in main BatchPatch grid’. You’ll see now that the ‘Download/install filter’ column, including the data stored for the selected row, has been copied to the ‘Row Template’ for the grid.
   

4. At this point we just need to make sure that we enable the Row Template by clicking the radio button ‘Enabled‘ in the upper right corner of the window. In the screenshot above you can see that when I captured the image it was still set to ‘Disabled.’ Make sure you click ‘Enabled‘ before clicking OK. If a row template has been created but is left ‘Disabled’ it will have no effect. It must be ‘Enabled’ to actually do something.
5. Now the row template for the grid has been created and enabled. If we add more hosts to the grid, they will automatically receive the values that were stored in the row template. In this case we stored the ‘Download/Install Filter‘ value to exclude KB112233. So, after I add new hosts to the grid, you can see in the screenshot below that they have the same filter applied as the previously existing rows.
   

It’s becoming increasingly common for companies and organizations to segregate at least some of their servers (and even non-server computers sometimes too) so that they don’t have any internet access. The goal in eliminating internet access for computers is virtually always to increase security by decreasing the attack surface or vector. However, while it’s true that removing internet access for computers will in many ways dramatically decrease the exposure for attack, it can be a bit of a catch-22. On the one hand when a system does not have internet access, it’s not going to be as vulnerable to as many attacks. On the other hand when machines are offline it’s more difficult to keep them up to date, and when an operating system or an application running on the OS is not up to date, the system becomes more vulnerable. An attack might be less likely to occur on an offline network, but if the computers on that network are not kept up to date and are subsequently attacked in one way or another, the attack has a much higher likelihood of being successful than it would if the computers were patched/updated regularly.

How to Deploy Windows Updates to Offline Computers

There are a number of ways to accomplish this task, but unless you want a heavy monthly burden that eats a lot of human-hours, you really need to use a patch management application that’s going to do most of the work for you. You don’t necessarily have to use BatchPatch for this purpose, but even though I’m obviously biased I’m just going to come right out and say that despite my bias BatchPatch is still likely to be the easiest, most efficient, and least expensive option that you have for applying Windows Updates to numerous offline computers.

BatchPatch has two primary modes of operation (or three, depending on how you look at it). The default mode that BatchPatch operates in requires target computers to have internet access or access to a WSUS server, but if you switch BatchPatch to ‘offline mode‘ you can use it to scan offline computers for needed updates, and then deploy the updates to those computers. And you can do it efficiently so that all of the offline computers can be updated at the same time.

At the following link I have described the three different scenarios for using BatchPatch in ‘offline mode’. Note, they are ordered from least stringent to most stringent offline network scenarios. There is always a balance between security and convenience. The offline networks with the most stringent rules will generally be the least convenient or least efficient to patch. The offline networks with the least stringent rules will usually be easier or more efficient to patch but of course it always depends on the particulars of your environment. That said, when choosing which BatchPatch ‘offline mode’ approach/method to use, start at the top and work your way down until you see the method that will work for your environment. If you choose the method that is designed for the absolute most secure environments, you might be decreasing your own efficiency for patching your network if your network’s requirements are not quite so strict.

Offline Patch Management with BatchPatch

More Details on BatchPatch Cached Mode and Offline Updates

In order to use BatchPatch to deploy Windows 10 feature update 1809, please follow the method outlined below. The normal Windows Update actions in BatchPatch are not sufficient for installing the feature updates to Windows 10. Also note just for the sake of clarity that even though these are considered Windows 10 feature updates, the Windows Update Agent (WUA) puts these in the update classification called Upgrades.

1. Obtain the Windows 10 Media Creation Tool from Microsoft. Follow this link and then choose the option to download the tool. Be careful to not select the option to ‘Update now’ because at the time of this writing the above link will have both options– a link to update the current computer plus a separate link to download the Windows 10 Media Creation Tool. If you choose ‘Update now’ you’ll begin the update process for the computer that you are using to view that webpage. Instead choose the ‘Download tool now’ option, though note that it’s very possible that Microsoft could change the language or the text on the download button by the time you are reading this to something other than ‘Download tool now’. Also note, the Windows 10 Media Creation Tool does not let you choose which version of Windows 10 it will download. It will only ever download the latest release, which at the time of this writing is version 1809. If you have another means of obtaining Windows 10 media, such as through a volume licensing agreement with Microsoft, then you may do that instead of using the media creation tool.
2. Launch the Windows 10 Media Creation Tool that you downloaded in the previous step. NOTE, you *must* be logged on to the computer as a local administrator when you launch the tool. For reasons that Microsoft has not made clear, it is *not* sufficient to use run-as to launch the media creation tool elevated as administrator. Instead you have to actually be logged on to the computer with the admin account before you launch the tool. Otherwise you’ll end up launching the tool as a standard user and clicking through screens until the tool itself notifies you that it cannot complete its job.
3. Use the Windows 10 Media Creation Tool to create installation media. When you run the tool you will be prompted to select either ‘Upgrade this PC now’ or ‘Create installation media (USB flash drive, DVD, or ISO file) for another PC. The goal here is not to upgrade the current PC but rather to obtain media that can be used to update other PCs, so choose the second option to ‘Create installation media…’ and then click ‘Next’.
   
4. Select the desired language, edition, and architecture, and then click ‘Next’.
   
5. Choose which media to use. For this tutorial you should select ISO as the media type. When you click ‘Next’ you will be prompted to choose a disk location for the ISO file to be saved. Choose a folder and then wait until the download completes. It will take some time because it’s ~4GB.
   
6. Extract the ISO contents to a folder on your computer. When the download completes you will need to browse to the ISO file location. Many different tools can be used to extract the contents of the ISO file. We prefer 7-zip, which is free, for this sort of thing. When the extraction is complete you should have all of the feature update installation files in a single folder.
   
7. Create a BatchPatch deployment. In BatchPatch click on Actions > Deploy > Create/modify. In the Deployment interface that appears, browse to the folder where you extracted the ISO contents, and select the setup.exe as the file to deploy. Make sure to tick the ‘Copy entire directory‘ box and the ‘Leave entire directory‘ box. When the upgrade/installation is being performed, Windows will reboot the target computer multiple times during the process. The installation/upgrade process must have access to all of the files required for the upgrade. Having both of the checkboxes ticked will ensure that the process has all of the needed files available to it during the installation. After the upgrade is complete you may delete the files from the target computer(s), but just make sure that you don’t delete them until the upgrade process is 100% complete. In your BatchPatch deployment configuration you will also need to add the following parameters:

   /auto upgrade /quiet

8. Execute the deployment. In the deployment configuration from the previous step you can either save the deployment to execute later by using the double-right-arrow ‘>>’ button, or you can execute the deployment now for the currently selected rows in the BatchPatch grid by clicking the Execute now button. If you saved the deployment configuration for later, then when you are ready to deploy the upgrade to your target computers, go ahead an execute it by clicking Actions > Deploy > Execute deployment, and then choose the deployment that you just created/saved. The process will take some time to complete because BatchPatch has to copy the entire multi-gigabyte media folder to the target computer(s) before it can execute the upgrade. When BatchPatch shows Exit Code: 0 (SUCCESS) for a given target computer it means that the BatchPatch process has completed, but you should still expect that the target computer(s) will still be working and will still reboot at least one time but possibly multiple times while Windows is upgraded and configured, so be patient and let it complete!

   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.

   It’s unclear why these users experienced this error even though most other users have executed the deployment successfully without encountering the error. My guess is it might have something to do with the application used to extract the .ISO file and the way permissions were applied or inherited. Regardless, 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. In this way when BatchPatch copies the installation files to the target computer, the autorun.inf won’t even be there, so this error won’t occur.

For those of you using BatchPatch in online cached mode… Starting with Windows 10/2016 version 1709 you might start seeing these two errors occur together in the ‘Local Agent Log’ column:

An exception occurred during a WebClient request.. HRESULT: -2146233079

Failed: Illegal characters in path.

The Problem:

Starting with Windows 10/2016 build 1709 Microsoft began publishing some updates with different/new update URLs in the update metadata as compared to all previous versions of Windows.

These new update URLs are formatted like this:

http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/096dd15c-70d9-4d48-b99c-0272f32a1853?P1=1521499885&P2=301&P3=2&P4=DS9%2bc8sTV40DeDsw3Rjf98wBE%2bifv2dl%2fV%2buaU9HtGw%3d

Instead of like this:

http://download.windowsupdate.com/c/msdownload/update/software/secu/2018/04/windows10.0-kb4093107-x64_b5d9c24dfcf332de6968faeb867a31a2d6a10e8b.cab

The URLs that Microsoft embeds in the metadata for Windows updates is how BatchPatch knows where to download updates from when BatchPatch is running in online ‘cached mode’. Unfortunately, updates with the new URL format are not able to be downloaded in a web browser or by BatchPatch. As such, when you have online cached mode enabled, if you try to update a system that is running Windows 10/2016 version 1709 or later, you might see an error. If that happens, then in your ‘Local Agent Log’ column you will see something similar to what I have pasted below. Generally, all three of these things will likely be true in order for you to be experiencing the problem described in this blog posting. If you are not seeing all three of the below items in your ‘Local Agent Log’ column, you might be experiencing a different issue:

1. A filename that ends with this text:

   %3d

2. Exception text:

   An exception occurred during a WebClient request.. HRESULT: -2146233079

3. Exception text:

   Failed: Illegal characters in path

Sample Local Agent Log That Contains The Aforementioned Exception Text:

Local Agent Log
::Begin download
 
1> 80f5d408-146c-4819-b094-424d7bafa43f?P1=1518618864&P2=301&P3=2&P4=XQl9XGC2jopOymNc05rGw5X11vmG1pBIUA6TVBR5N5s%3d :: Attempt 1: Failure: An exception occurred during a WebClient request.. HRESULT: -2146233079. Attempt 2: Failure: An exception occurred during a WebClient request.. HRESULT: -2146233079.
 
::End download
 
Files downloaded: 0
Files located in cache: 0
Files excluded by filter: 0
Files initiated by another row: 0
Failures: 1
 
::Begin file copy operation
 
1> 80f5d408-146c-4819-b094-424d7bafa43f?P1=1518618864&P2=301&P3=2&P4=XQl9XGC2jopOymNc05rGw5X11vmG1pBIUA6TVBR5N5s%3d :: Failed: Illegal characters in path.
 
::End file copy operation
 
Files copied: 0
Files skipped: 0
Failures: 1

Workarounds:

1. Disable cached mode. When BatchPatch is running in normal/default mode with no caching, this issue does not exist. If you do not have a specific need for using cached mode, then I would recommend you simply disable it and run in normal/default mode.
2. Enable offline mode. When BatchPatch is running in offline mode (aka: offline cached mode) this issue does not exist. Offline mode will generally only install Security Updates, so it may not be optimal for you to run in this mode at all times if you want other updates to be installed. It depends on your needs and preference. If you can disable cached mode altogether, then the previous option is the best option. If you must use cached mode, then you can use offline cached mode to get the security updates installed that fail with the issue described in this blog posting.
3. Download the .msu update file directly from the Microsoft Update Catalog. You can find your update in the catalog by going to the catalog site and searching for the desired update or by submitting the search query yourself into your browser with a link formatted as follows, but of course you’ll need to substitute the KB ID of the update that you are searching for the KB ID that is used in my link here:

   https://www.catalog.update.microsoft.com/Search.aspx?q=KB4480116

   Then after downloading the .msu update file you can deploy it directly to target computers using BatchPatch’s deployment feature. You may use this tutorial to guide you through the deployment process: Remotely Deploy a Standalone MSU File to Multiple Computers