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

Managing Windows Updates Remotely on Numerous Computers

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

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

Update + Reboot Cycle with the BatchPatch Job Queue

One of the things that sysadmins frequently like to do with BatchPatch is use it to create an update + reboot loop with the goal of applying updates to target computers, rebooting those computers, and then doing a fresh check for available updates. If more updates have become available after the reboot, initiate the installation of those updates, then reboot again, and then once again check for more available updates. Repeat this process until Windows reports no more updates available. Here is how you can do this with BatchPatch.

  1. Create a Job Queue by select ‘Actions > Job Queue > Create / modify job queue

  2. In the Job Queue window I’ve created a queue with the following steps:

    1. label:START
    2. Download and install updates + reboot always
    3. Wait 15 minutes
    4. Wait for host to be detected online
    5. Check for available updates
    6. If most recent ‘Check for available updates’ found any updates, goto label:START

  3. Assuming that you plan to re-use this queue on a regular basis, you’ll want to save it by clicking on the double-right-arrow button in the Job Queue window. This will add a new row to the ‘Saved Queues’ grid. At this point if you click ‘Execute now‘ the job queue will be executed for all of the currently selected/highlighted rows in the BatchPatch grid. If you want to use the queue later or if you want to execute your job queue from a scheduled task, then simply close the Job Queue window for now.
  4. When you are ready to execute your queue, highlight all of the computers in the grid that you want to run it on, and then select ‘Actions > Job Queue > Execute saved job queues > Update + Reboot Cycle‘ – Of course you’ll select the name of the queue that you used, which may not be the same as my “Update + Reboot Cycle” title.

  5. If you don’t want to run the queue on-demand but instead would rather schedule it to run as a task, have a look at this tutorial for instructions.
Posted in Blog, General, Tutorials | Tagged , , , , , , | Comments closed

Remotely Deleting Files and Folders on Multiple Computers

Below I’ll show you the commands that you can insert into BatchPatch if you need/want to delete a file or folder on numerous target computers. I’d also like to use this as an opportunity to discuss the differences between executing remote executables as compared to remote shell commands.

In BatchPatch we provide multiple different ways to execute remote commands. The two primary methods are ‘Remote Command 1/2‘ and ‘Remote Command 3/4 (logged output)‘. Under the hood these are actually executed a bit differently, and that can impact their behavior. Ultimately, we are trying to provide as much flexibility as possible to the end user, and so when we can offer a couple of different ways to do things, we often will choose to do so, just so that in the end the most possible compatibility is achieved. If you have a command that for some reason isn’t working in ‘Remote Command 1/2‘ (this is unusual, but it can happen on occasion), you might find that it works in ‘Remote Command 3/4‘, and vice versa.

In the case of file or directory deletion, we’re going to focus on the two built-in Windows shell commands DEL and RMDIR

Deleting a folder on remote computers

  1. In BatchPatch click on ‘Actions > Execute remote process/command‘ and then select one of the ‘logged output’ options. So you’ll select either ‘Create/modify remote command 3 (logged output)‘, ‘Create/modify remote command 4 (logged output)‘, or ‘Create/modify remote commands (logged output)‘. These 3 options all execute remote commands with the same method, all of which produce logged output (so if the command produces any console output or error etc, it will be captured/visible inside of BatchPatch). ‘Remote command 3‘ and ‘Remote command 4‘ are one-off command entry locations where the command saved there will be visible in the grid under the column ‘Remote command 3‘ or ‘Remote command 4‘. However, the ‘Create/modify remote commands (logged output)‘ option will enable you to save a list of different commands to be “hard-coded” into the BatchPatch actions menu. These commands will also then be available inside of the job queue and inside of the task scheduler.

  2. The syntax to delete a folder in the ‘logged output’ commands is:
    rmdir "V:\test\New folder" /s /q

  3. It’s also possible to use a ‘Remote command 1/2‘ (non-logged-output) to accomplish this task, but there are two important things to note. First, we prefer using logged-output for this task because if there is a problem completing it, we might get some feedback in the output/result that helps us understand why there was a problem. For example, the Windows RMDIR command can’t delete a directory that contains hidden or system files. Second, if you want to use ‘Remote command 1/2‘ then you have to use slightly different syntax.

    The syntax to delete a folder in the NON logged output commands is:

    cmd.exe /c rmdir "V:\test\New folder" /s /q
  4. Why is different syntax required for RMDIR commands in ‘Remote command 1/2‘ as compared to ‘Remote command 3/4 (logged output)‘?

    Under the hood, ‘Remote command 1/2‘ is looking for an actual .exe file to execute. In the case of a RMDIR command, it will look for RMDIR.exe on the target computer. However, there is no RMDIR.exe in Windows because RMDIR is a shell command that executes inside of the command prompt. For this reason, it needs to be executed with ‘cmd.exe /c’. ‘Remote command 3/4‘ automatically does this under the hood, whereas ‘Remote command 1/2‘ does not. So in order for you to use RMDIR inside of ‘Remote command 1/2‘ you must add ‘cmd.exe /c’ to the beginning of the command.

Deleting a file on remote computers

  1. In BatchPatch click on ‘Actions > Execute remote process/command‘ and then select one of the ‘logged output’ options. So you’ll select either ‘Create/modify remote command 3 (logged output)‘, ‘Create/modify remote command 4 (logged output)‘, or ‘Create/modify remote commands (logged output)‘. These 3 options all execute remote commands with the same method, all of which produce logged output (so if the command produces any console output or error etc, it will be captured/visible inside of BatchPatch). ‘Remote command 3‘ and ‘Remote command 4‘ are one-off command entry locations where the command saved there will be visible in the grid under the column ‘Remote command 3‘ or ‘Remote command 4‘. However, the ‘Create/modify remote commands (logged output)‘ option will enable you to save a list of different commands to be “hard-coded” into the BatchPatch actions menu. These commands will also then be available inside of the job queue and inside of the task scheduler.
  2. The syntax to delete a file in the ‘logged output’ commands is:
    del "V:\test\New folder\someFile.txt" /f /q

    It’s also possible to use a ‘Remote command 1/2‘ (non-logged-output) to accomplish this task, but there are two important things to note. First, we prefer using logged-output for this task because if there is a problem completing it, we might get some feedback in the output/result that helps us understand why there was a problem. Second, if you want to use ‘Remote command 1/2‘ then you have to use slightly different syntax.

    The syntax to delete a file in the NON logged output commands is:

    cmd.exe /c del "V:\test\New folder\someFile.txt" /f /q
  3. Why is different syntax required for DEL commands in ‘Remote command 1/2‘ as compared to ‘Remote command 3/4 (logged output)‘?

    Under the hood, ‘Remote command 1/2‘ is looking for an actual .exe file to execute. In the case of a DEL command, it will look for DEL.exe on the target computer. However, there is no DEL.exe in Windows because DEL is a shell command that executes inside of the command prompt. For this reason, it needs to be executed with ‘cmd.exe /c’. ‘Remote command 3/4‘ automatically does this under the hood, whereas ‘Remote command 1/2‘ does not. So in order for you to use DEL inside of ‘Remote command 1/2‘ you must add ‘cmd.exe /c’ to the beginning of the command.

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