BatchPatch Error -198: Failed to add scan package service. HRESULT -XXXXXXXXXX

When you’re running BatchPatch in offline mode, instead of performing the search for Windows Updates against a local WSUS or against Microsoft’s public Windows Update or Microsoft Update servers, BatchPatch utilizes the WsusScn2.cab file that Microsoft publishes each month in order to perform the offline scan for Windows Updates. The WsusScn2.cab is a large file that contains various metadata for Windows Updates. When an offline scan for Windows Updates is performed, Windows is able to use the WsusScn2.cab file to determine which updates are available for download/installation on the scanned computer, without needing direct access to a WSUS, Windows Update, or Microsoft Update.

In BatchPatch, if there is some type of problem with loading the WsusScn2.cab file for scanning, BatchPatch will throw an error that looks like this:

Error -198: Failed to add scan package service. HRESULT: -XXXXXXXXXX

The -198 number simply indicates that the issue was with loading the WsusScn2.cab file. The HRESULT value is the actual reason code that the Windows Update Agent reports to BatchPatch. You’ll be able to see this in the BatchPatch ‘Remote Agent Log’ column after the failure/error occurs. Or you can view it later in the target computer’s BatchPatch.log file, which by default would be located in C:\Program Files\BatchPatch\BatchPatch.log on the target computer.

Various HRESULT values that might be seen with a -198 error

Error -198: Failed to add scan package service. HRESULT: -2146762487

0x800B0109 -2146762487 CERT_E_UNTRUSTEDROOT
A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider

We believe the only reason that this would occur is if you are trying to apply updates to an operating system that Microsoft is no longer supporting and delivering updates for. If you have not purchased an Extended Security Update (ESU) package from Microsoft, we think this error could occur.


Error -198: Failed to add scan package service. HRESULT: -2147024894

0x80070002 -2147024894 ERROR_FILE_NOT_FOUND
The System cannot find the file specified

This should only happen if the WsusScn2.cab file itself does not exist on the target computer when the scan is initiated. For the most part, BatchPatch wouldn’t/shouldn’t allow the scan to be attempted to if the file isn’t there, but there may be some edge cases where it could still occur.


Error -198: Failed to add scan package service. HRESULT: -2147024674

0x8007000D The data is invalid. ERROR_INVALID_DATA

OR

Error -198: Failed to add scan package service. HRESULT: -2145124303

0x80240031 -2145124303 WU_E_INVALID_FILE
File is not of the right format

Either of the above HRESULT values indicate that there is probably an issue (presumably some type of file corruption) with the WsusScn2.cab file that is being used. Either there was corruption when downloading it from Microsoft to the BatchPatch computer, or the corruption is being introduced when the BP computer copies it to the target computers. If you manually inspect the WsusScn2.cab file (both on the BP computer in the local cache directory as well as on a couple of targets) you can right click on the file and view ‘Properties > Digital Signatures’ as a way to verify that the file has not been corrupted/modified. If the Digital Signatures tab is present with signatures listed, then the file is good. If it is not present or if it is present but with no signatures listed, then the file is not good. If it’s not good then you can delete the WsusScn2.cab file and let BatchPatch re-download it. If it’s good on the BP computer but not good on the targets, then the corruption is being introduced during the file copy from the BP computer to the targets. This would be unusual, but it would imply that you might be having issues with your network, or it could be just a one-off copy issue.


Error -198: Failed to add scan package service. HRESULT: -2147024784

0x80070070 -2147024784 ERROR_DISK_FULL
There is not enough space on the disk

This error is self-explanatory. You need to free up some disk space on the target computer and then try again.


Error -198: Failed to add scan package service. HRESULT: -2147023838

0x80070422 -2147023838 ERROR_SERVICE_DISABLED

Typically this means a required service is disabled. Start by verifying that the following services are started:

BITS service (Background Intelligent Transfer Service)
Windows Update service
Windows Modules Installer service


Error -198: Failed to add scan package service. HRESULT: -2146885619

0x8009200D -2146885619 Crypt_E_Bad_Msg
Not a cryptographic message or the cryptographic message is not formatted correctly

OR

Error -198: Failed to add scan package service. HRESULT: -2146869232

0x80096010 -2146869232 Trust_E_Bad_Digest
The digital signature of the object did not verify

Either of the above HRESULT values indicate that the WsusScn2.cab file that you have is likely failing a signature validity check, so you should re-download it and try again. We have seen a number of times when Microsoft first publishes a new WsusScn2.cab file on Patch Tuesday each month, where for some period of time soon after publishing, the WsusScn2.cab file is missing a digital signature when it’s downloaded from Microsoft’s servers. The Windows Update Agent will not load a WsusScn2.cab file that doesn’t haven’t a valid signature. If you manually inspect the WsusScn2.cab file (both on the BP computer in the local cache directory as well as on a couple of targets) you can right click on the file and view ‘Properties > Digital Signatures’ as a way to verify that the file has not been corrupted/modified. If the Digital Signatures tab is present with signatures listed, then the file is good. If it is not present or if it is present but with no signatures listed, then the file is not good. If it’s not good then you can delete the WsusScn2.cab file and let BatchPatch re-download it. If it’s good on the BP computer but not good on the targets, then probably some corruption is being introduced during the file copy from the BP computer to the targets. This would be unusual, but it would imply that you might be having issues with your network, or it could be just a one-off copy issue. If the file you are getting directly from Microsoft does not contain a digital signature, wait a while and then try to download it again from scratch.

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

BatchPatch Job Queue Branching Based on DateTime or Number of Iterations

In the most recent release of BatchPatch (August 2021), we added some new special items to the Job Queue that will give you more flexibility in your queues.

  • If this step is executed X time(s), terminate queue
  • If this step is executed X time(s), goto label:Y
  • If this step is executed between DateTimeBEGIN and DateTimeEND, terminate queue
  • If this step is executed between DateTimeBEGIN and DateTimeEND, goto label:X
  • If this step is executed between DayOfWeekBEGIN and DayOfWeekEND, terminate queue
  • If this step is executed between DayOfWeekBEGIN and DayOfWeekEND, goto label:X
  • If this step is executed between TimeOfDayBEGIN and TimeOfDayEND, terminate queue
  • If this step is executed between TimeOfDayBEGIN and TimeOfDayEND, goto label:X

One of the ways that we anticipate these options will be used is with recurring tasks that have to be executed multiple times throughout the day on a given day. For example, let’s say that you want or need to execute a script or command or actions of some kind on target computers every 15 minutes throughout the day, every day. However, you only want the command to be executed between the hours of 9AM and 5PM. You can do something like what I’ve done here, where I’ve setup my BatchPatch job queue to run on a 9AM daily recurring scheduled task. The queue itself is a loop that runs every 15 minutes to execute my custom remote command, but in each iteration of the loop, there’s a check to see what time it is. If the loop executes any time after 5PM (17:00) and before 9AM (09:00), the queue is terminated. This has the effect of running the queue loop every 15 minutes throughout each day but only during the 9AM to 5PM window. Outside of those hours, the queue is terminated until the next day when the scheduled task kicks off anew at 9AM. With all of the new special queue items shown above, you can see there’s now quite a bit of flexibility that wasn’t previously available. While we know that not everyone will need or care about these options, we expect there will be a good number of people who make great use of them.

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

BatchPatch System.MissingMethodException When Running New Version 20210827

In the most recent release of BatchPatch that we published last week (version 20210827), we finally began enforcing the requirement to have .NET version 4.6 installed on the computer where BatchPatch is run. If you don’t have .NET version 4.6 on the BatchPatch computer, BatchPatch will not be able to launch successfully. If you encounter this issue, you will likely see something similar (though not necessarily identical) to the screenshots displayed below.

If you were able to successfully run previous BatchPatch versions without issue, but then you tried the latest BatchPatch version 20210827 and discovered that it won’t even launch successfully, you probably have a .NET version issue. Please check which .NET version is installed on your BatchPatch system, and then install .NET v4.6 if you’re still running an older version of .NET.

Posted in Blog, General | Tagged , | Comments closed

Can BatchPatch Be Used to Install Windows Updates through SCCM?

One of the questions we occasionally receive from SCCM users is can BatchPatch install/apply the Windows Updates that are currently being presented to a computer through SCCM?

BatchPatch and SCCM?

There are a couple things that you need to know…

Windows Updates that are being offered to a computer to a computer through SCCM are only available inside of SCCM. BatchPatch does not have the ability to directly access or control your SCCM server. BUT… you still have options. See below.

Executing SCCM Client Triggers from within BatchPatch

If you check in BatchPatch under ‘Tools > SCCM Client Triggers‘ you will see a list of all available SCCM trigger commands. Each of these can be individually executed through BatchPatch on target computers that have SCCM installed. However, depending on your needs and your environment, utilizing these triggers may not be sufficient, so you may need to do more. See below.

Using BatchPatch in an Existing SCCM Environment

If you want to be able to use BatchPatch in an environment that already uses SCCM, you have a couple of options. If you have SCCM in your environment, it’s important to understand that SCCM utilizes its own WSUS server. Once SCCM takes control of a WSUS during the setup/configuration of SCCM, that WSUS can no longer be used by a non-SCCM application like BatchPatch to search for updates. So, if your target computers are configured via Group Policy to search for updates on a WSUS that is controlled by your SCCM server, then if you use BatchPatch to initiate a scan for available updates, and if BatchPatch’s ‘Server Selection‘ setting is set to ‘Default/Managed‘, BatchPatch will always report ‘No applicable updates’. In order to use BatchPatch with a WSUS, the WSUS must be independent. It cannot be linked to or controlled by SCCM.

So, if you want to use BatchPatch in an environment that is already using SCCM, you can either set BatchPatch’s ‘Server Selection‘ under ‘Tools > Settings > Windows Update‘ to Windows Update or Microsoft Update

Or… you can setup a secondary WSUS server that is independent and not touched by or controlled by SCCM. However, this creates a minor secondary challenge. Since Group Policy is generally the method that is used to configure target computers to point to a particular WSUS server (in the case of SCCM environments, the Group Policy setting will point to the WSUS server that has been configured for use by SCCM), you would need a way to tell a target computer to utilize your secondary independent WSUS, at will. The idea here would be that since your target computers all look to the WSUS that is controlled by SCCM (let’s call that the SCCM-WSUS from now on), you need a way to temporarily modify that setting to tell target computers to look at your independent WSUS during the time that you are using BatchPatch. While you could modify your Group Policy to point to the independent WSUS, use BatchPatch, and then set it back to the SCCM-WSUS afterward, another option that is probably more seamless would be to directly modify the GPO’s underlying registry values on target computers, rather than touching the GPO itself. In BatchPatch you could actually setup a job queue to do the following all in a single click:

Step 1. Update the target computer registry to point to your independent WSUS
Step 2. Execute your BatchPatch Windows Update actions
Step 3. Reboot the target, which will trigger a Group Policy refresh, which will have the effect of wiping out the registry values that you put in place so that they get set back to the values that the Group Policy Object contains. Alternatively instead of rebooting the target, you can send a new command to the target computer to update the registry values again to point back to the SCCM-WSUS.

At the following link we demonstrate how to setup a BatchPatch job queue with “pre” and “post” commands that will handle what I just described above.

Using An Alternate WSUS Server For BatchPatch Windows Update Actions

Using An Alternate WSUS Server For BatchPatch Windows Update Actions Part 2

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

Remotely Deploying Windows Feature Update Version 21H1 to Numerous Computers

Standard Deployment of Windows Feature Update 21H1 (and other feature updates/upgrades) with BatchPatch in Default/NON-Cached Mode

Generally speaking, if you are using the April 2020 or newer release of BatchPatch, you can install Windows feature updates with the normal ‘Windows Update’ actions in BatchPatch, when running the application in standard, non-cached, mode. To do so, you’ll just need to make sure to select the ‘Upgrades’ classification, as illustrated in the screenshot below:

After the ‘Upgrades’ classification is selected you can simply use ‘Actions > Download available updates‘ with ‘Actions > Install downloaded updates‘ or you can just use ‘Actions > Download and install updates‘. As long as you are operating in standard, non-cached mode, feature updates will install (assuming, of course, that you currently have a feature update showing in the list of available updates for a given computer).

Feature Update Deployment Considerations – Update deferral policies, and when an update is only available for “seekers”

However, please note there are a couple of other things to consider when installing feature updates using the standard non-cached mode BatchPatch update method.

First, the target computer needs to have the desired feature update showing as one of the available updates for the computer. If you’re expecting to see it but you don’t, it could be because the update is not approved on your WSUS yet, or it could be that you have a Group Policy or Local Policy setting configured for the target computer that is set to defer the installation of feature updates for a specified amount of time. Check your Group Policy configuration for any deferral policies enabled under the following locations:

Computer Configuration > Administrative Templates > Windows Components > Windows Update

Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business

Second, depending at what stage of the rollout Microsoft currently is at the time you attempt to deploy a given feature update, they might not yet be delivering the update through the normal Windows Update channel. They typically begin the rollout with delivery only to “seekers”. This is the name they give to people who manually click on the ‘Check for updates’ button in the Windows Control panel. “Seeker” updates are visible in BatchPatch when you click on ‘Search for only optional software updates

Alternate Deployment of Windows Feature Update 21H1 (and other feature updates/upgrades) with BatchPatch (can be used for deployment to offline target computers)

If you need to deploy feature update version 21H1 (or any other feature update) to target computers that don’t have internet access and don’t have WSUS access and therefore cannot be targeted in standard, non-cached mode (that is to say, you are using either online cached mode or offline cached mode with those target computers, and you are not able to disable cached mode and switch to standard mode for whatever reason), then you may use the method outlined below to deploy the feature update to those computers.

  1. Download (from Microsoft) the Windows 10 Media Creation Tool. Use this link to download the media creation tool directly from Microsoft. The media creation tool web page contains two options: ‘Update now’ and ‘Download tool now’. Do NOT click on ‘Update now’ because doing so would begin the update process on your computer. Since your goal is to deploy the upgrade to remote computers, instead please click on ‘Download tool now’ to save the tool to your computer. Important: When you run the media creation tool per the next step, you will not have a choice to select which Windows 10 version is used to create the media. This means that if Microsoft releases a new version of Windows 10 when you follow this tutorial, you’ll end up with that version as opposed to the specific version 21H1 that is available today at the time of this writing. If you have another channel for obtaining media for a particular Windows 10 version, such as with a Microsoft volume licensing agreement, you may use that instead of obtaining the media through the steps outlined in this tutorial.
  2. Open the Windows 10 Media Creation Tool that you saved to your computer a moment ago. IMPORTANT: It is NOT sufficient to run the tool as administrator (using right-click, run-as) from an account that is logged on without admin privileges. For reasons that aren’t fully clear, Microsoft requires that you *must* actually be logged on to the computer with an account that is a member of the local administrators group. Otherwise the tool will not allow you to run it to completion. We don’t know why Microsoft made the tool work this way, but it’s what they did, and presumably it’s for a good reason. So go ahead and log on to your computer as a local administrator, and then launch the tool and follow the rest of this tutorial.
  3. Create installation media with the Windows 10 Media Creation tool. When the tool is running you’ll have to choose between two options to either ‘Upgrade this PC now’ or ‘Create installation media (USB flash drive, DVD, or ISO file) for another PC. Choose the option to ‘Create installation media…’ and then click ‘Next’.
  4. Choose your language / edition / architecture, and then click ‘Next’.
  5. Choose the media type. For the sake of this tutorial please select ISO as the type of media. After clicking the ‘Next’ button you will be prompted to choose a location on your computer to store the ISO file that will be downloaded/created. Select a directory/location to store the file, and then do something else until the download finishes. Depending on your connection speed it could take some time because it’s something like 4GB in size.
  6. Extract the ISO contents to a location on your local disk. After the download in the previous step is complete you’ll have to locate the file on disk and then extract the contents of the ISO to another folder. I like to use the free 7-zip for this process, but you may use whichever tool you prefer: 7-zip. After the ISO has been extracted you’ll have all of the installation files for the feature update in a single folder.
  7. Configure a deployment in BatchPatch. In BatchPatch click on Actions > Deploy > Create/modify. In the window that pops up for the Deployment configuration, click on the ‘…’ button to browse to the location where your ISO contents have been extracted to, and then choose the ‘setup.exe’ file as the file to deploy. Make sure to check the boxes for ‘Copy entire directoryandLeave entire directory. After the initial deployment phase is complete, the target Windows operating system will end up rebooting itself at least once but usually more than once while it completes the setup and installation for the feature update. As the process runs it needs to have access to all of the files that BatchPatch will deploy. Having both of the aforementioned boxes checked will ensure that when the upgrade process runs on the target computer that it has all of the files it needs for the installation. After the feature update has completed 100% you may delete the files from the target computer(s). However, please make absolutely sure that the upgrade process is 100% completed before you delete any files. In your BatchPatch deployment configuration screen you will also need to add the following parameters:
    /auto upgrade /quiet

  8. Execute the feature upgrade deployment. In the deployment configuration that you created in the in the previous step you can execute the deployment immediately for the currently selected rows in the grid by just clicking on the ‘Execute now’ button. Alternatively you may save the deployment for future usage by clicking the double-right-arrow button ‘>>’. If you choose to save the deployment instead of executing it immediately, then when you are ready to deploy the feature update to your remote computers, you can begin the process by selecting those computers in the BatchPatch grid and then clicking on Actions > Deploy > Execute deployment, and then choose the deployment that you just created/saved.

    You should expect that the entire process will take a bit of time to complete. BatchPatch has to copy the whole installation directory to the target computer(s), which contains several gigabytes, before it can execute the upgrade process on the target(s). IMPORTANT: After the BatchPatch deployment completes for a given target computer BatchPatch will show Exit Code: 0 (SUCCESS). However, this just means that the BatchPatch deployment component is finished. The Windows feature update/upgrade process will take additional time. Please be patient and let the target computer continue upgrading and rebooting as many times as is needed. It might take a little while with multiple automatic reboots before everything is 100% finished.

    NOTE: We have had a couple of reports from users who received the following error:

    Deployment: Error: Access to the path '\\TargetComputer\C$\Program Files\BatchPatch\deployment\autorun.inf' is denied.

    We don’t know the exact cause of this issue, but it seems likely to somehow be related to the way that permissions were applied or inherited during the ISO extraction process. If you encounter this error it can be resolved quickly and easily by just deleting the autorun.inf file from the source directory after extracting the ISO contents but before executing the actual deployment for any target computers. This will prevent the problematic file from ever being copied to target computers. As such, the error will not occur.

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

BatchPatch Tweaks And Tips You’ll Probably Never Need Or Use

OK, so the title to this posting is a bit jocular and misleading because I’m going to include some things in this posting that you will want to use if you don’t already know about them. 🙂

  • Middle-click tooltip: This is a MUST-USE feature that some users never discover. Every field in the BatchPatch grid can be easily viewed by middle-clicking or scroll-wheel-clicking on it. If you aren’t already using middle-click, you should start. I honestly can’t imagine using BatchPatch without it.



  • Moving the middle-click tooltip: You can re-position the middle-click tooltip when it’s visible by right-clicking anywhere directly on it and then dragging it to a new location. Middle-click drag and ctrl-left-click will also both work.
  • Never show certain columns: If you want to prevent a certain column from ever being made visible by BatchPatch, you can do that under ‘Tools > Settings > Grid preferences > Never automatically display or unhide specific columns’
  • Generate a BatchPatch project file (.bpp): If you want to be able to launch numerous .bps files into the same grid all at once, you can use a BatchPatch project file to do that, if desired. A BatchPatch project file (.bpp) is actually just a regular text file with a .bpp extension that contains a list of full filepaths to .bps files. If you load a .bpp file into BatchPatch, all the .bps files listed in the .bpp file will be loaded as separate tabs. When you generate a .bpp file using the ‘File > Generate project file option’, BatchPatch will create a .bpp file that contains the saved filepath of each open tab in that instance of BatchPatch. If a tab has never been saved to a .bps file, it will not be included in the .bpp file.
  • Generate a BatchPatch template file (.bpt): A BatchPatch template file (.bpt) is simply a BatchPatch state file (.bps) that has been named with a
    .bpt extension instead of .bps. When you load a .bpt file into BatchPatch, BatchPatch will not allow you to save over it. When you try to save it, you will instead be forced to “Save As” a .bps file. The ‘File > Generate template file’ option will enable you to create a .bpt file from any grid in BatchPatch. However, you may also create your own .bpt files by simply renaming existing .bps files with the .bpt extension.
  • Row template configurator: Use this feature to automatically apply values to new rows that are added to a grid. If you want to auto-populate certain fields when you add a host to the grid, such as scheduled tasks, you can use this feature to do that. Using the Row Template Configurator
  • Synchronize a grid with Active Directory: If you want to have a BatchPatch grid that always has the same list of hosts as a given OU or Group in Active Directory, you can use this feature to do that. Synchronize a BatchPatch Grid with Active Directory OUs and Groups
  • Transparency: You can make the entire BatchPatch application transparent, if desired. Use the little arrow icon on the lower right corner of the BatchPatch window to access a slider that lets you adjust the level of transparency.
  • Alternating rows backcolor intensity: Use the little arrow icon in the lower left corner of the window to access a slider that lets you adjust the intensity of the alternating rows backcolor.

  • Grid borders: You can use CTRL-B toggle between 4 different styles for column and row borders in the grid.



  • Host status ping thread: Independently of the normal grid operations, it’s possible to turn on a separate ping thread that will color the LED orb icons, based on the status of the host. Click the LED image header column to turn it on or off. Middle-click the image header column to clear all rows LED image icon. Middle-click a particular row’s LED image icon to disable/remove/skip it from the check. Shift-middle-click a particular row’s LED image icon to turn it blue.
  • Multi-grid mode: ‘View > Multi-grid mode’
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

How to Check if a Particular Software Application is Installed on Multiple Computers

One of the questions that we are sometimes asked is “How can I use BatchPatch to determine if a particular application is installed on target computers?”

First, you should know that BatchPatch has a built-in action ‘Get list of installed programs‘, which you can find under ‘Actions > Get information > Get list of installed programs‘. This action will query target computers for the registry values that store the list of installed applications in Windows. While this can be valuable to look at when you want to see everything that’s installed on a computer, it’s not particularly helpful when you want to look for the presence of just a single entry, especially across numerous target systems. There are actually two issues to consider here. First, obviously if you have a list of 300 items but you’re only interested in a single piece of software, it’s just not convenient to manually read through a 300-item list just to see if there is a single item there. Second, there is no guarantee that the registry values that BatchPatch queries with the built-in action will contain the name of the software that you are looking for even if that software is actually installed on the system(s) you’re querying. Most software applications will register themselves such that they appear in that list, but not all apps do this.

The most reliable way to check for the existence of a particular application is to query something specific to that application… something that you know for sure will exist on target systems where the app is installed. We recommend you look at a system with the desired application installed, and identify either a specific file or a specific registry value that the application has as part of its installation. Then you can use BatchPatch to check target systems for just that particular file or registry value.

In the BatchPatch actions menu you have:

Actions > Get information > Check if file exists…
Actions > Get information > Check registry key/value

Also in the BatchPatch Job Queue you have:
If specified file exists, goto label:X
If specified file does not exist, goto label:X
If specified registry key exists, goto label:X
If specified registry key does not exist, goto label:X
If specified registry value exists, goto label:X
If specified registry value does not exist, goto label:X
If version of specified file is newer than Y, goto label:X
If version of specified file is older than Y, goto label:X

You can use one or more of the above items to easily assess whether or not target computers have a given application installed. In the case of the Job Queue items, you can leverage those to branch your queue based on the results of each query, which gives you a lot of options and flexibility.

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

Using an Alternate WSUS Server for BatchPatch Windows Update Actions – Part 2

I recently wrote about how to use an alternate WSUS server with BatchPatch. That posting is long and contains a lot of information about the process. I recommend that you read through it to learn about how everything fits together with BatchPatch, WSUS, and Group Policy. However, today I’d like to just get straight into a tutorial so that you can see step by step what to do without sorting through so much information.

Quick explanation of how a target computer knows which WSUS to use:

The WSUS server that any computer uses is controlled by Group Policy. When Group Policy settings are applied to a computer, it’s generally in the form of registry entries. So, in this case with WSUS server, a Group Policy is set for a group of computers that sets some registry values on those computers. The registry values tell those computers the address of the WSUS server. You can modify these registry entries directly, but note that when Group Policy refreshes, your direct edits to any registry values that are controlled by Group Policy will revert to the Group Policy settings. If you want to tell a target computer to look for updates on a different WSUS server than your Group Policy is currently set to, then you can modify the registry of the target computer, check for updates, and then modify the registry once again to put back the original settings (or just leave it until Group Policy refreshes on its own and resets the values automatically). Below I’ll show you how you can do that in BatchPatch.

How to use BatchPatch on target computers, specifying an alternate WSUS server:

  1. Create a remote command to check to see which WSUS server address is currently in use by target computers: In BatchPatch create a ‘Remote command (logged output)‘ with ‘Actions > Execute remote process/command > Create/modify remote commands (logged output)‘. Create a command with the following syntax:
    REG QUERY "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"

    You can execute that command in BatchPatch by highlighting the desired rows/computers in the grid, and then select ‘Actions > Execute remote process/command > Execute saved remote commands (logged output)

    In the result, take note of the WUServer and WUStatusServer values. If these values are not present, then the computer is not configured to get updates from a WSUS server. In the screenshot below you can see my test computer is configured to get updates from a server called MYWSUS with URL http://mywsus:8530

  2. Create remote commands for changing the WUServer and WUStatusServer registry values on target computers to point to your alternate WSUS server:

    WUServer:

    REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /t REG_SZ /d http://myalternatewsus:8530 /f

    WUStatusServer:

    REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /t REG_SZ /d http://myalternatewsus:8530 /f

  3. Create remote commands for changing the appropriate registry values on target computers to point back to your original WSUS server:

    WUServer:

    REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /t REG_SZ /d http://mywsus:8530 /f

    WUStatusServer:

    REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /t REG_SZ /d http://mywsus:8530 /f
  4. Finally, put it all together for use. We’ll create a job queue that updates the WUServer and WUStatusServer registry values, and then performs a download/install/reboot operation. In this case it’s not necessary to reset the WUServer and WUStatusServer back to their original values because upon reboot, Windows will automatically refresh the Group Policy settings for us, so there is no need. However, depending on what you are doing, you may want to execute the remote commands to reset those values, if you are concerned that Group Policy refresh won’t occur soon enough for your needs. Note, Microsoft says “Group Policy is automatically refreshed when you restart the domain member computer, or when a user logs on to a domain member computer. In addition, Group Policy is periodically refreshed. By default, this periodic refresh is performed every 90 minutes with a randomized offset of up to 30 minutes.

    Use ‘Actions > Job Queue > Create/modify job queue‘, and set the job queue to contain the following steps:

    1. Execute remote command to update WUServer
    2. Execute remote command to update WUStatusServer
    3. Execute ‘Download and install updates + reboot always’

    You can optionally save the above job queue for future execution by adding a title to the ‘Title’ field, and then clicking the double-right-arrow button. Then it’s ready any time you want to download/install Windows Updates from a different WSUS server. To execute a saved job queue, select the desired rows in the grid, and then click ‘Actions > Job Queue > Execute saved job queues

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

Using an Alternate WSUS Server for BatchPatch Windows Update Actions – Part 1

Currently BatchPatch provides you with three different options to choose from for ‘Server Selection’ in the BatchPatch settings window (‘Tools > Settings > Windows Update > Server Selection’)

  • Default / Managed
  • Windows Update
  • Microsoft Update

The ‘Server Selection’ field enables you to select which Windows Update source server target computers will use to perform their Windows Update searches and downloads.

Default / Managed: Uses the target computer’s existing configuration to determine where to search for updates.

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

Microsoft Update: Bypasses the target computer’s configuration and searches for updates on Microsoft’s public server. Includes Windows updates AND updates for other Microsoft products. Before using Microsoft Update, target servers must be opted-in to the service. See ‘Actions > Windows Updates > Opt-in…’

In general, Windows stores the Windows Update configuration in the registry. When you first install a fresh copy of Windows, the default behavior is for it to use ‘Windows Update’ to check for updates. As an end-user on a given computer, in the Windows Update control panel you are also provided with an option to ‘Receive updates for other Microsoft Products when you update Windows‘. This option is equivalent to using ‘Microsoft Update’ in BatchPatch. An example of this settings dialog is below:

WSUS, Group Policy, and Underlying Registry Values

If you are using a local WSUS server in your environment, then you will have previously configured Group Policy settings on your domain, instructing target computers to utilize the local WSUS server. Note, Group Policy (or Local Policy, or its corresponding registry modifications) is actually the only mechanism that Windows provides for specifying your own update server. The Windows Update control panel GUI only lets you choose ‘Windows Update’ or ‘Microsoft Update’, so any time a local WSUS server is being used, Group Policy will have to be used to configure target computers to point to that particular WSUS. That said, it’s important to understand that Group Policy itself is really just a mechanism for controlling registry keys/values on target computers. That is, any time you create a Group Policy in your domain, any computer that receives the Group Policy settings will get certain registry keys/values created or modified. It’s those underlying registry values that actually affect/control the behavior of the particular computer. So, to be clear, Group Policy is a mechanism for managing all kinds of settings in Windows computers that are joined to a domain. The actual settings themselves are constructed of registry keys and values. Every Group Policy setting has one or more underlying registry values that it controls. So if you create or change a domain Group Policy, various registry keys/values are created or modified on computers that receive the Group Policy, and consequently the behavior of Windows is controlled/affected by which registry keys and values exist on a given computer. Therefore it’s actually possible to effectively modify the behavior of a given computer by directly editing the registry without touching Group Policy. However, it’s very important to recognize that if you modify a registry value that is being controlled by Group Policy, whatever changes you make to that registry value will get overwritten as soon as the Group Policy settings are refreshed on that computer.

BatchPatch, SCCM, and WSUS

The most common case where some of our users need or want to have BatchPatch use a different WSUS that is separate from the primary WSUS in a given environment, is when their existing WSUS is an SCCM-controlled WSUS. For users who currently have their machines getting updates through SCCM, their SCCM infrastructure will include a WSUS server. Target computers will have a Group Policy setting that point them to the SCCM WSUS server, and this is how they’ll receive their updates. The problem for using third-party Windows Update tools like BatchPatch is that once a WSUS server has been configured as part of an SCCM deployment, that WSUS server will no longer be usable for any non-SCCM update mechanisms. You’ll notice that if you have BatchPatch set to ‘Default / Managed’, and you then use BatchPatch to perform a check for available updates on a target computer that is configured (via Group Policy, local policy, or direct registry edits) to use the SCCM-WSUS, BatchPatch will always return that there are no available updates, even if the SCCM console is actually showing that there are updates available.

Therefore, if you want to use BatchPatch in an existing SCCM environment, then your options are to either set the BatchPatch server selection to ‘Windows Update’ or ‘Microsoft Update’, OR you could configure a separate local WSUS server that is *not* attached to the SCCM infrastructure in any way. Then if you want BatchPatch to use a specific WSUS server that is *different* from your standard/default WSUS server as configured in your Group Policy settings for the domain, then you need to either update the Group Policy settings for target computers to point to the separate WSUS server, or you can directly modify the registry of target computers, temporarily, in order to point them to the separate WSUS server for the time that you are using BatchPatch.

The particular Group Policy setting that needs to be modified is ‘Specify intranet Microsoft update service location‘ under ‘Computer Configuration > Administrative Templates > Windows Components > Windows Update‘. A typical configuration is shown in my screenshot below, where MyWSUS is the name of my WSUS server. 8530 is the default http port for WSUS versions 6.2 (Windows Server 2012) and newer.

The registry values that correspond to the “intranet update service” (WUServer) and “intranet statistics server” (WUStatusServer) are highlighted in the screenshot below. They will be found in the registry of computers that have the ‘Specify intranet Microsoft update service location‘ Group Policy setting applied. The registry location is HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate:

Specifying a separate WSUS just for BatchPatch Actions

Realistically, if your goal is to use BatchPatch in an existing SCCM environment, and for whatever reason you can’t or don’t want to have BatchPatch point to ‘Windows Update’ or ‘Microsoft Update’, you would have to then create a new/separate WSUS server that is just for use by BatchPatch (and any other non-SCCM update tools). While you could then manually update Group Policy, temporarily, on certain servers, in practice this could be difficult or annoying for various reasons. It makes more sense to just manually update the Windows Update registry settings on desired target computers to point those computers to the alternate WSUS, then perform your BatchPatch actions, and then reset the registry values or just wait for Group Policy to refresh on its own (it will refresh automatically after reboot, after logon, or at 90 minute intervals throughout the day without a reboot).

One way to do accomplish this from BatchPatch is to use BatchPatch to execute a “pre” and “post” command to update the WUServer and WUStatusServer registry values before and after using BatchPatch to check for or download/install updates.

Caveats: Really there is just a single potential issue to keep in mind, which is that you won’t know when Group Policy on a given target computer could automatically refresh. If you update the WUServer registry value to point to an alternate WSUS server, and then you start using BatchPatch on a given target computer, it’s conceivable that the registry value could be auto-updated back to the original setting by a Group Policy refresh while you are still using BatchPatch. This shouldn’t be an issue if it occurs while a BatchPatch action is executing, but if the setting gets reverted without you realizing, and then you perform some other BatchPatch action, the target WSUS server would be different than you think for that subsequent BatchPatch action. I’d say that overall the “risk” here is not significant. The Group Policy refresh isn’t going to be happening constantly, but according to Microsoft can occur in regular intervals of 90 minutes by default. The best way to ensure that this does not become an issue for you is to simply execute your “pre” task before each BatchPatch Windows Update action/command that you perform on target computers.

BatchPatch “Pre” Command to Update WUServer and WUStatusServer Registry Values on Target Computers

In the screenshot below you can see that I have created 4 command under ‘Actions > Execute remote process/command > Create/modify remote commands

Create/Update WUServer Registry Value to http://mywsus:8530

reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /t REG_SZ /d http://mywsus:8530 /f

Create/Update WUStatusServer Registry Value to http://mywsus:8530

reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /t REG_SZ /d http://mywsus:8530 /f

Delete WUServer Registry Value

reg delete HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /f

Delete WUStatusServerRegistry Value

reg delete HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /f

You can use commands like the ones above to execute “pre” and “post” commands in BatchPatch. Though, rather than delete the registry values in your case you might want to set them back to whatever they were originally set to by your Group Policy settings. Also in many cases it might be fine to never run a “post” command at all, and instead just let Group Policy automatically refresh on its own when you’re done with your BatchPatch duties, especially if your BatchPatch duties will include rebooting target computers since a reboot will initiate a Group Policy refresh when the computer comes back online. Figure out what works best in your environment for your needs. Even if you don’t initiate a reboot, the Group Policy will be automatically refreshed within 90 minutes.

“Pre” and “post” commands can be run by selecting the desired target hosts in the BatchPatch grid and using ‘Actions > Execute remote process/command > Execute saved remote commands

Alternatively you could create a Job Queue that automatically executes your “pre” and/or “post” commands before and after various Windows Update actions. For example, see below for one possible Job Queue idea. To have this job queue perform as desired/expected, make sure BatchPatch server selection is set to ‘Default / Managed’. Then when you run the queue it will update the WUServer and WUStatusServer registry values on the target machine before initiating the Windows Update command, so when the Windows Update action runs it will use the WUServer and WUStatusServer values that you inserted, thereby enabling you to utilize a different WSUS, temporarily. Here is one example of how your job queue could look:

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

Error 1612 / 1621 : No application is associated with the specified file for this operation. Please make sure that C:\Windows\SYSTEM32\ntdll.dll is a valid/accessible filepath. HRESULT: -2147467259

There is an edge-case bug that exists in the current version 20210407 of BatchPatch. We’ve had several reports of users encountering the error described in this posting.

Error 1612 / 1621 : No application is associated with the specified file for this operation.  Please make sure that C:\Windows\SYSTEM32\ntdll.dll is a valid/accessible filepath. HRESULT: -2147467259

What’s happening here is that in the most recent version of BatchPatch, at launch time the software attempts to detect the full filepath of the PsExec.exe on the system, so that it can use that full filepath to execute PsExec from that point forward. However, in some edge cases it seems that the detection is erroneously locking on to C:\Windows\SYSTEM32\ntdll.dll instead of the actual path of the PsExec.exe. So far we’ve only had a few reports from users where this happened. We’ll have a fix/resolution in the next release of BP, but in the meantime, if this happens to you, you can resolve it very quickly/easily.

You’ll need to just manually modify/set the PsExec path in your BatchPatch settings. Go to ‘Tools > Settings > Remote Execution > Use psexec.exe custom filepath‘. Use the file selection […] button, and browse to the actual location of your psexec.exe file (it must be a local filepath, not a network path).

Once you have this value set to the actual location of your psexec.exe, you can simply click OK to save the setting. The error should no longer occur.

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