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

By Scott | Published: June 10, 2021

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

By Scott | Published: May 27, 2021

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

By Scott | Published: May 6, 2021

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

Removing Orphaned PsExec Services from Target Computers

By Scott | Published: April 20, 2021

What’s the problem?

Occasionally we will hear of a situation where PsExec is not able to properly clean itself up on target computers. Under normal circumstances when PsExec runs, it installs a service on the remote computer, temporarily, in order to run the desired application/script/command. Then when it completes the action, the service is removed. However, in some rare cases PsExec fails to function properly (there are multiple reasons why PsExec can fail), and in those cases we usually find that the target computer will be left with an orphaned service that was not successfully removed during the cleanup process.

While the default remote service name that PsExec creates/installs is titled PSEXESVC, PsExec also supports the use of a -r switch, which enables the user to specify a custom name to be used for the remote service. In BatchPatch the -r switch value is configurable under ‘Tools > Settings > Remote Execution > Use PsExec -r switch to specify remote service name‘. There is additionally a setting to ‘Append random string to remote service name for each process execution‘. In the case where you have the ‘Append random string‘ option enabled AND also are experiencing a problem where PsExec is unable to remove the service successfully from a target computer, you’ll end up with a separate orphaned service for each attempt that BatchPatch made to execute an action on that particular target computer. To avoid a continual build-up of orphaned processes, the first thing we recommend doing is disabling the ‘Append random string‘ setting, so that instead of getting a new orphaned service with each BatchPatch action attempt, instead you’ll only have a single service that gets re-used with each action/command.

Disable the ‘Append random string’ option

After you have disabled the ‘Append random string‘ setting, you’ll then want to remove any orphaned services from the affected target computer. You may have something like this showing in your Services console on the affected target computer. You can view the Services console by going typing ‘services.msc’ at the ‘Run’ command of the Start menu (‘Start > run > services.msc‘).

Standard syntax for deleting a service at the cmd prompt

The normal syntax for deleting a service that you can use at the command line (cmd prompt) is:

sc.exe delete ServiceNameGoesHere

Syntax for viewing list of all orphaned services by name matching

However, if you have numerous orphaned services on a given machine, you might want to delete them all with a single command. The easiest way to do this is with PowerShell. For example, if you want to list out the orphaned services, you can use a wildcard search to show all services that contain ‘BatchPatchExeSvc’ in their name:

get-service '*BatchPatchExeSvc*'

Syntax for deleting all orphaned services by name matching

You can then use the following command to delete all the services that contain the name ‘BatchPatchExeSvc’:

get-service '*BatchPatchExeSvc*' | ForEach-object{ cmd /c  sc delete $_.Name}

Now, if you want to execute this task from within BatchPatch, use a ‘Remote command (logged output)’ with the following syntax:

powershell.exe -ExecutionPolicy Bypass -command "get-service '*BatchPatchExeSvc*' | ForEach-object{ cmd /c  sc delete $_.Name}"

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

PsExec Version 2.33 Released March 23, 2021 – LPE Mitigation

By Scott | Published: March 26, 2021

PsExec v2.33 was released March 23, 2021. We are recommending that everyone update to this version. You can download it here.

After you download it, make sure to launch it manually one time under the account that you use to run BatchPatch. Also check the file properties to make sure it isn’t being blocked by Windows. If BatchPatch gets stuck “Attempting to initiate…” then you’ll know that Windows is blocking PsExec. More on how to unblock it here: BatchPatch Stuck ‘Attempting to initiate Windows Update’ or ‘Initiating execution’

BatchPatch will look for PsExec in the Windows PATH, so many users simply drop it into C:\Windows, and nothing more is needed. However, you can optionally point BatchPatch directly to your PsExec.exe filepath by going to ‘Tools > Settings > Remote Execution > Use psexec.exe custom filepath‘. This also enables you to name the file whatever you want, which is helpful when you are retaining multiple file versions. We generally recommend hanging on to your older versions of PsExec rather than replacing them outright. This way you can always revert to an older version if needed at any time in the future for testing or whatever.

PsExec Update Details – Why is there a PsExec update? And why do we recommend using it?

The PsExec v2.33 update was released to mitigate a named pipe squatting attack that could be leveraged to elevate from a lower privileged state to system level privilege on the attacked system. On December 9, 2020, a security researcher published an article that describes a novel local privilege elevation (or local privilege escalation – LPE) attack on PsExec through a technique known as pipe squatting. PsExec uses what is called a “Named Pipe” in Windows for inter-process communication between the source computer and target computer. The named pipe acts as a communication channel, and the default name for the pipe is PSEXESVC (this is the same as the default remote service name that PsExec uses when it temporarily installs itself on a given target computer). As he explains in his article…

“Through pipe squatting however (a method in which you create the pipe first), it is possible for a low-privilege application to get access to this pipe. If a local low-privileged application creates the “\PSEXESVC” named pipe before PSEXESVC is executed, then PSEXESVC will obtain a handle to the existing instance rather than creating the named pipe itself, which will have some unexpected consequences.”

Reality check

What does this really mean, in practice? The reason it’s called a *local* privilege elevation attack is because it’s not possible to remotely exploit. A malicious application would have to already have compromised a computer and be actively running for this attack to be possible. If this pipe-squatting attack is successfully executed, it could then enable the malicious application to elevate from a lower-privileged state to having system level privileges on the computer. Due to the nature of this type of attack, Microsoft gave it an exploitability assessment of “Exploitation Less Likely.” We believe this is an accurate assessment of the threat (Note, at the time of this writing, the CVE says it was fixed in v2.32, but it was not actually fixed properly until v2.33) The good news here is that while this is a legitimate potential attack, since it’s a local privilege elevation and not a remote code exploit, malicious code would have to first, through some other means, establish presence on a given system, and then after presence is established would have to run quietly/hidden in the background, squatting on the PSEXESVC named pipe, hoping that at some point someone would come along and run PsExec against that machine, using the default service and pipe name. So, while this attack provides a potential way, under certain circumstances, to take an already compromised system and gain higher level privileges on it, exploitation is probably not too likely due to the nature of the type of attack and the type of payoff, if executed successfully. That said, of course you should still update your PsExec.

Pre-existing mitigation

Both PsExec and BatchPatch already had a built-in mitigation available for this attack at the time the attack was published. PsExec (going back all the way to v2.0 released in 2013) has a -r switch, which enables you to modify the name of the remote service and pipe name from PSEXESVC to the name of your choosing. In BatchPatch (beginning with version 20151130) this setting is located under ‘Tools > Settings > Remote Execution > Use PsExec -r switch to specify remote service name‘. When this setting is enabled, the attack is effectively prevented/mitigated because the pipe name is modified, making it no longer guessable (because it’s now the custom name of your choosing instead of the default PSEXESVC). The attacker can squat all day on PSEXESVC, but if your processes are using SOMEOTHERNAME, the attacker cannot do anything.

BatchPatch January 2021 update / April 2021 update

On January 28, 2021 we released an update to BatchPatch that, in addition to a number of other updates and bug fixes, enabled the ‘Use PsExec -r switch’ setting as the default and for anyone who wasn’t already using it, and also added some additional code in a new optional setting to append a random string to the service/pipe name for each execution, thereby making it virtually impossible to guess in advance since each action would execute with a brand new name (through the appension of a random suffix), essentially eliminating the possibility of this kind of pipe-squatting exploit from being successfully executed. This optional random suffix setting is arguably unnecessary/overkill, but we wanted it to be available to users nonetheless. In the Jan 2021 release of BatchPatch the setting was enabled by default and for existing users. In the April 2021 release it will be disabled by default and for existing users on first launch. If a user wants to keep that setting, he/she will have to manually re-enable it after launching the April 2021 version of BatchPatch.

PsExec 2021 updates

In the meantime Microsoft released 3 updates to PsExec in rapid succession in January (v2.21, v2.30, v2.32), none of which successfully mitigated this attack directly in the PsExec code itself. However, v2.33 released on March 23 properly addresses the issue, so we’re recommending that everyone start using it. You can download it here.

Note, the PsExec update makes a slight change to PsExec’s functionality whereby it now requires use of -i (Interactive) when using alternate credentials (except when using using -s (SYSTEM). These settings are available under ‘Tools > Settings > Remote Execution‘. In most cases these values can either all be set to ‘SYSTEM‘ (without ‘Interactive‘) or can all be set to ‘Elevated token‘ + ‘Interactive‘. Usually either of these options will provide success. For most situations, leaving everything set to ‘SYSTEM‘ (without ‘Interactive‘) should be fine and is what we are currently recommending at the time of this writing, but in cases where you are executing a remote script with alternate credentials, and the remote script needs access to network resources, in that case ‘SYSTEM‘ will not work because the SYSTEM account does not have access to network resources. So in that case you would need to use ‘Elevated token‘ + ‘Interactive‘.

BatchPatch April 2021

There will be another BatchPatch update published very soon (in early April), which will include a PsExec version check to notify users if their PsExec version is affected.

Posted in Blog, General | Tagged | Comments closed

How to Remotely Clear the Print Queue on Multiple Computers

By Scott | Published: March 8, 2021

We recently received a question about how to use BatchPatch to remotely clear the print queue on numerous computers. The process is actually pretty simple, and I’ll go through it step by step below.

  1. First we need to prepare a simple script that will do the actual work. The process for clearing a print queue involves stopping the printer spooler service, deleting all files in C:\Windows\System32\spool\PRINTERS, and then starting the spooler service back up again. Open notepad (or your favorite text editor) and add the following lines, and then save the file as ResetPrintSpooler.cmd 
    net stop spooler /yes
del C:\Windows\System32\spool\PRINTERS\*.* /s /q /f
net start spooler

  2. Now we have to create a BatchPatch deployment to handle copying the script to target computers and then executing it. Select ‘Actions > Deploy software/patch/script/regkey etc > Create/modify deployment‘, and then set your deployment configuration to look like mine. All I have done is selected the path of the .cmd file, and then I have checked the box to ‘Retrieve console output‘. Retrieving console output is not required for this deployment, but it might be helpful to see for the sake of troubleshooting any issues that arise. To save your deployment, click the double-right-arrow button.

  3. We’re now ready to execute the deployment. Highlight the desired target computers in your grid, and then select ‘Actions > Deploy > Execute saved deployments > ResetPrintSpooler‘

  4. That’s all there is to it. Upon success you’ll see something similar to what my screenshot below looks like. Note, the ‘/yes‘ in the first line of the .cmd file will stop not only the printer spooler but also any dependent services. If dependent services are stopped, you’ll see it in the output. And in that case you might want to modify your script to also add ‘net start‘ commands for those dependent services. Also note, in my sample there were no files in the print queue, so the deletion command on line 2 didn’t actually delete anything. If your queue contains entries, then you should see files deleted.

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

How to do Offline Windows Updates for Numerous Computers

By Scott | Published: February 23, 2021

Many organizations have one or more networks of computers that don’t have access to the internet, but this creates a challenge for keeping the operating systems up to date. Fortunately, BatchPatch has functionality that enables administrators to easily deploy updates to their offline computers. When it comes to offline Windows Update, there are a few considerations to take into account.

Questions to consider for offline updates

  1. Do your computers have access to the internet? If yes, then you’re probably not actually in need of a solution to handle offline Windows updates.

  2. If your computers do not have access to the internet, do they have access have access to a WSUS (Windows Server Update Services)? If they have access to a WSUS, then you probably don’t need to worry about doing an offline update procedure because the WSUS is either going to be getting its updates from an upstream WSUS server or directly from Microsoft, and the target computers will be able to retrieve their updates from the WSUS. We don’t really consider this an offline update scenario.

  3. If your computers definitely do not have access to the internet or a WSUS, then you’re going to be looking at an offline update scenario. However, depending on your particular environment, this can still accomplished in a couple of different ways.

    1. For example, does your setup allow you to have a BatchPatch computer that has access to the internet and also has access to the target computers, even if the target computers themselves don’t have direct access to the internet?

    2. If the target computers don’t have internet or WSUS access, and if the BatchPatch computer cannot simultaneously have internet access while also having access to the target computers, then you still need to consider the rules for your particular environment. For example, is your environment so tightly controlled that you aren’t even allowed to remove a single file from the offline network? In some very strict environments, files that exist in the offline network may never be taken to a different network. If this describes your setup, then you’re going to need to perform your offline update routine a bit differently than if your environment allows you to remove files from the offline network.

BatchPatch methods for offline updating

When it comes to offline updates with BatchPatch, there are two primary ways to accomplish this:

–Method 1 involves using BatchPatch to check your target computers to see which updates they need. Then take BatchPatch, along with a single file that BatchPatch produced, which lists out the needed updates, and run BatchPatch on an internet-connected computer to obtain all of the needed updates. Then bring the update files and BatchPatch back to the offline network to distribute the updates to offline target computers.

–Method 2 skips the first part and never checks which updates are needed by target computers. In this way, no list of available/needed update files has to be taken from the offline network. Instead, you simply run BatchPatch on an internet-connected computer to download *all* possible updates. Then take this update cache to the offline network where you use BatchPatch to distribute only the needed updates.

At the following link we carefully describe the 5 possible ways to use BatchPatch for online and offline update situations. Complete tutorials are included too. If you are using BatchPatch for offline updates, then check out ‘scenario 4’ and ‘scenario 5’ here: Cached Mode And Offline Windows Update

Posted in Blog, General | Tagged | Comments closed

Including Custom Remote Commands in a Job Queue

By Scott | Published: February 9, 2021

If you want to create a job queue in BatchPatch to execute a multi-step process on target computers, you can do that very easily. Today I’m going to show you how you can add your own custom remote commands or deployments to a job queue.

There are many different uses for a job queue in BatchPatch. One common use case is for downloading and installing Windows updates in a loop that will perform the download/install followed by a reboot, and then repeat the exact same process multiple times until there are no more updates available for installation. These days Windows is pretty good about not creating a situation where multiple update/reboot cycles are needed to get all updates installed, but on older versions of Windows this would happen more frequently. We still have many customers who like to perform an update/reboot cycle just so they can feel confident that they haven’t left any updates available for install.

Another common use case for the job queue is to execute a series of tasks on target computers with just a single click. For example, what if you have a custom remote command that you need/want to execute on a target computer *before* you apply updates, and then *after* the updates have been applied and the computer has been rebooted you then need/want to execute a second command. Below I’ll show you how to do that.

  1. First let’s get our custom remote commands added to BatchPatch. For the sake of this example we’ll just deploy a generic script at the beginning and end of the queue. Of course you can substitute your own custom remote command, local command, or deployment. This particular command will be executed as a BatchPatch deployment (as opposed to a standard BatchPatch remote command) because I need to actually get the script from the BatchPatch computer to the remote computers for execution. A standard “remote command” or “remote command (logged output)” in BatchPatch would only handle the execution portion, which means that whatever we would be executing in those cases would have to already exist on the target computers. However, in this case the script we want to execute is located on the BatchPatch computer, so we use a deployment operation to copy it to the targets and then perform the execution on those targets.

    I’ll start by creating a script deployment by going to ‘Actions > Deploy > Create/modify‘. In the deployment configuration window I’ll setup my script deployment and then use the double-right-arrow to save it. I’m going to create a “before” deployment as well as an “after” deployment. Each deployment will be responsible for copying my script to the target computer(s), and then executing it. However, the deployments will be setup to run inside of a job queue. See screenshots below for my “before” and “after” deployment configurations.

  2. Now let’s setup the job queue. Use ‘Actions > Job Queue > Create/modify‘. You can see in the screenshot below that I have the “before” deployment as the first step, then my Windows Update step, then my “after” deployment. Once created, it can be saved using the double-right-arrow.
  3. At this point we’re ready to execute our job queue. We can either do this on-demand, by selecting it from ‘Actions > Job Queue > Executed saved job queues‘ like in the screenshot below, or it can also be setup to run as a scheduled task for the desired date/time.

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

Managing Windows Updates Remotely on Numerous Computers

By Scott | Published: January 27, 2021

If you’re in need of a good way to remotely manage Windows Updates on your entire network of servers, desktops, workstations, laptops, and any other computers, you’ve come to the right place! We’ve put a lot of thought and effort into producing an application that enables IT systems administrators to easily install Windows Updates remotely across a large group of computers. The overall process is very simple. You load a list of computer names or IP addresses into a BatchPatch grid, then you select the desired targets for a given operation, and then you execute whatever action you want across the group of selected computers. Actions can include checking for available Windows Updates, downloading updates, installing updates, rebooting, etc. For example, you can instruct all target computers to “Download and install updates + reboot if required”. You can even create an automated cycle that will download and install updates, reboot, then check for more updates and continue the download/install/reboot cycle until no more updates are found to install.

You can use BatchPatch to get information from target computers… things like last bootup time or currently logged-on users, for example. Or let’s say that you need to find all computers that have a particular registry value or file, you can do that too. And you can automate processes based on these things as well, which means that if you want to setup a process that will only apply Windows Updates if a particular file or registry value exists, you can do that. Or maybe you want to initiate a software deployment of some third-party application, but you want to only do that if a file on target computers is older or newer than a particular version, you can do that too. You can schedule tasks to execute as soon as a target computer is detected online. And you can integrate your own custom scripts and queries too, so the sky is the limit. Additionally, if you have a group of computers with interdependencies such that the computers need to be updates and rebooted in a very specific order, BatchPatch can handle that very easily too.

Below I’m going to show you the most basic functionality that BatchPatch offers, which is to download and install updates plus reboot if the updates that were installed require it. I would encourage you to peruse the rest of our website to find all sorts of other instructional materials and tutorials for other features in the app, both basic and advanced. If you don’t find something that you’re looking for, or if you have a question that you can’t find an answer to, please feel free to reach out to us directly.

Remotely Installing Windows Updates on Multiple Computers, Simultaneously

  1. Add a list of computer names or IP addresses to a BatchPatch grid. Select ‘Grid > Add hosts‘, and then enter your list and click OK.


  2. Select/highlight the desired target computers, and then choose the desired action. In this case I’m going to use ‘Actions > Windows Updates > Download and install updates + reboot if required‘

  3. THAT’S IT! You can now sit back and relax, watching the real-time progress as your computers update and reboot. It truly couldn’t be any simpler.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Troubleshooting Windows Feature Update/Upgrade Errors

By Scott | Published: January 6, 2021

When you use BatchPatch to deploy a Windows 10 Feature Update (e.g. Windows 10 1607, 1703, 1709, 1803, 1809, 1903, 1909, 2004, 20H2 etc), if you encounter a problem, it’s generally going to be delivered to you as a single HRESULT code (e.g. Deployment: Exit Code: -1047526904), which on its own might be a bit difficult to interpret. Today I’m going to show you how to figure out what’s really going on.

Today I tried to update one of our Windows 10 1709 virtual machines to Win 10 20H2. I followed the normal BatchPatch update procedure ( Deploying Windows Feature Upgrades/Updates Remotely to Multiple Computers ), and this is the result I got: Deployment: Exit Code: -1047526912

Now what? This number isn’t particularly helpful.

Three Steps to Determining the Cause of the Windows Feature Update Failure / Error

There are three primary methods you can use to get to the bottom of the error, which we will go through below. First, please note that the exit codes are generally coming from Windows, not from BatchPatch. BatchPatch is simply running the deployment, but if it fails with an HRESULT exit code value similar the one I pasted above (a 10-digit negative number), that generally indicates the issue is not with BatchPatch but rather is something to do with Windows. If you follow the BatchPatch deployment steps properly but you encounter such an error, then you can be pretty sure that BatchPatch is not the reason for the failure. However, if the error you received does not look similar to the one pasted above (is not a 10 digit negative number), then you should review your BatchPatch deployment configuration and make sure you followed the BatchPatch Windows 10 Feature Update deployment steps properly as outlined in the tutorial.

Method 1. Convert the HRESULT value to HEX and then search for it on Google

Follow the instructions outlined here to convert the decimal HRESULT value to hexadecimal. Then Google search the hex value to see if you can find a quick solution/resolution. In many cases, this will get you the answer you need pretty quickly.

Method 2. Run the Feature Update Deployment at the Command Prompt, Manually, WITHOUT Using BatchPatch

Log on to the target computer directly, and then open an elevated/administrator command prompt (cmd.exe) window. Then run the following command *without* using the /quiet switch. This way you’ll be able to see the progress, and hopefully Windows will provide a meaningful explanation for why the failure occurred. All of the setup files should still be on the target computer from your previous attempt, so everything should already be in the right spot for to try this. Note if you have modified the ‘target working directory’ in your BatchPatch deployment configuration, then the path where you find the Windows setup files on the target computer will be different from what my screenshots below illustrate:

setup.exe /auto upgrade

You can see in my case when running it manually, as described above, I ended up with this, which told me everything I needed to know, which is that my virtual machine needs more RAM allocated before attempting the feature upgrade again:

Method 3. Review the Windows Update Log Files

In some cases Windows does not provide you with a useful, textual description of the reason for the failure. For example, some users are seeing this HRESULT when trying to update to 20H2: -1047526904. This is just a generic failure HRESULT, and Windows does not currently provide much additional information about what is causing this to occur. So, you have to do some digging in the Windows Update Log files.

On the target computer open Windows Explorer and paste this value into the address bar:
C:\$WINDOWS.~BT\Sources\Panther

Find the .xml files that look like CompatData_yyyy_mm_dd.xml

Open the last CompatData xml file with Microsoft Edge or Notepad++ or your favorite XML viewer app. It can be opened in a standard text editor like Notepad but will be a bit harder to read without the XML formatting. You can see in my case the not-enough-RAM issue shows in the log file like this ( as CompatibilityInfo BlockingType=”Hard” ):

We have had a couple of users report one particular HRESULT value, -1047526904, where the problem was actually being caused by a couple of built-in Windows drivers. Yes you read that correctly… Microsoft’s own XPS and PDF printer drivers, which are part of Windows 10 itself, are blocking the 20H2 installation process for some reason for some people. The following link shows how to determine the specific drivers that are blocking the upgrade process, and how to disable/remove them in order to complete the installation.

How to Fix What Needs Your Attention Windows 10 Setup Errors

With regard to -1047526904, it seems like Microsoft just messed up on this one (not a huge surprise), and hopefully they will resolve this issue in the next feature update, so that so many people don’t continue to encounter this same problem.

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