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

Removing Orphaned PsExec Services from Target Computers

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

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

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

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

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