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

Update + Reboot Cycle with the BatchPatch Job Queue

By Scott | Published: December 22, 2020

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

By Scott | Published: December 3, 2020

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

Using the Task Scheduler to Execute a Custom Job Queue

By Scott | Published: November 19, 2020

Create a custom job queue

  1. Let’s start by creating our custom job queue. Select ‘Actions > Job Queue > Create/modify job queue‘

  2. In the Job Queue window, create your desired queue. In this case I have created a queue to execute an update + reboot cycle, indefinitely, until there are no more updates available to download/install. My queue is as follows:

    Label:START
Download and install updates + reboot always
Wait 15 minutes
Wait for host to be detected online
Check for available updates (with filters applied)
If most recent 'Check for available updates (with filters applied) found any updates, goto label:START

  3. Give the queue a title (mine is ‘Update + Reboot Cycle‘), and then click the double-right arrow to save it.

  4. Now that our custom queue has been created and saved, we can setup our scheduled task. Highlight the rows in the grid that you want the scheduled task to apply to. Next, click on ‘Actions > Task scheduler > Create/modify scheduled task‘

    5. Create a scheduled task to execute your saved job queue

  5. In the Task Scheduler window, from the Task drop-down menu find the job queue that you created, and then select it. Next, set the run date and time. You’ll do this by modifying the ‘Reference’ datetime picker. Optionally select a recurrence option. Then click OK.

  6. The only thing left to do now is make sure that the task scheduler is enabled. In the upper-right corner of the BatchPatch window you’ll see a small clock/timer icon. If it’s red, it’s disabled. If it’s green, it’s enabled. Click the icon to toggle it from enabled to disabled and vice versa. If it’s disabled, no scheduled tasks will be executed at their configured run times, so make sure it’s enabled if you want your tasks to execute.

    7. Optionally, send your grid to run in the BatchPatch service instance, so that scheduled tasks will be executed without BatchPatch needing to be open and without the computer needing to be logged-on

  7. If you need/want this grid’s scheduled tasks to execute without BatchPatch having to be open and/or without the computer needing to be logged-on, you can send the grid to the BatchPatch service instance. In this case, it won’t matter if your task scheduler icon is green or red (enabled or disabled) in the current instance of BatchPatch because in the service instance of BatchPatch, the task scheduler is always on/enabled and cannot be turned off or disabled. To send the grid to the BatchPatch service instance, right-click on the tab header and select ‘Send grid to service instance‘, as illustrated in the screenshot below.

    If the ‘Send grid to service instance‘ option is grayed out like it is in my screenshot, it means that the BatchPatch service instance is not installed. If you would like to install it, follow the instructions in this posting: Running BatchPatch as a Service

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

Remotely Deploying Windows Feature Update Version 20H2 (the ‘October 2020 Update’) to Numerous Computers

By Scott | Published: November 4, 2020

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

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

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

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

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

  1. Download (from Microsoft) the Windows 10 Media Creation Tool. Use this link to download the media creation tool directly from Microsoft. The media creation tool web page contains two options: ‘Update now’ and ‘Download tool now’. Do NOT click on ‘Update now’ because doing so would begin the update process on your computer. Since your goal is to deploy the upgrade to remote computers, instead please click on ‘Download tool now’ to save the tool to your computer. Important: When you run the media creation tool per the next step, you will not have a choice to select which Windows 10 version is used to create the media. This means that if Microsoft releases a new version of Windows 10 when you follow this tutorial, you’ll end up with that version as opposed to the specific version 20H2 that is available today at the time of this writing. If you have another channel for obtaining media for a particular Windows 10 version, such as with a Microsoft volume licensing agreement, you may use that instead of obtaining the media through the steps outlined in this tutorial.

  2. Open the Windows 10 Media Creation Tool that you saved to your computer a moment ago. IMPORTANT: It is NOT sufficient to run the tool as administrator (using right-click, run-as) from an account that is logged on without admin privileges. For reasons that aren’t fully clear, Microsoft requires that you *must* actually be logged on to the computer with an account that is a member of the local administrators group. Otherwise the tool will not allow you to run it to completion. We don’t know why Microsoft made the tool work this way, but it’s what they did, and presumably it’s for a good reason. So go ahead and log on to your computer as a local administrator, and then launch the tool and follow the rest of this tutorial.

  3. Create installation media with the Windows 10 Media Creation tool. When the tool is running you’ll have to choose between two options to either ‘Upgrade this PC now’ or ‘Create installation media (USB flash drive, DVD, or ISO file) for another PC. Choose the option to ‘Create installation media…’ and then click ‘Next’.

  4. Choose your language / edition / architecture, and then click ‘Next’.

  5. Choose the media type. For the sake of this tutorial please select ISO as the type of media. After clicking the ‘Next’ button you will be prompted to choose a location on your computer to store the ISO file that will be downloaded/created. Select a directory/location to store the file, and then do something else until the download finishes. Depending on your connection speed it could take some time because it’s something like 4GB in size.

  6. Extract the ISO contents to a location on your local disk. After the download in the previous step is complete you’ll have to locate the file on disk and then extract the contents of the ISO to another folder. I like to use the free 7-zip for this process, but you may use whichever tool you prefer: 7-zip. After the ISO has been extracted you’ll have all of the installation files for the feature update in a single folder.

  7. Configure a deployment in BatchPatch. In BatchPatch click on Actions > Deploy > Create/modify. In the window that pops up for the Deployment configuration, click on the ‘…’ button to browse to the location where your ISO contents have been extracted to, and then choose the ‘setup.exe’ file as the file to deploy. Make sure to check the boxes for ‘Copy entire directory‘ and ‘Leave entire directory‘ . After the initial deployment phase is complete, the target Windows operating system will end up rebooting itself at least once but usually more than once while it completes the setup and installation for the feature update. As the process runs it needs to have access to all of the files that BatchPatch will deploy. Having both of the aforementioned boxes checked will ensure that when the upgrade process runs on the target computer that it has all of the files it needs for the installation. After the feature update has completed 100% you may delete the files from the target computer(s). However, please make absolutely sure that the upgrade process is 100% completed before you delete any files. In your BatchPatch deployment configuration screen you will also need to add the following parameters: 
    /auto upgrade /quiet

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

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

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

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

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

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

Remotely Executing Windows Console or Shell Commands vs Windows Executables in BatchPatch

By Scott | Published: October 20, 2020

Today I’d like to discuss a topic that comes up sometimes that can be confusing when you don’t know anything about what is happening “under the hood” in BatchPatch.

BatchPatch Remote Commands

In BatchPatch we provide two primary ways for executing remote commands– ‘Remote command 1/2‘ and ‘Remote command 3/4 (logged output)‘. What some of you might have noticed is that if you try to run the following syntax (see the DEL command below) in ‘Remote command 1/2‘, it doesn’t work. However, you can take the exact same syntax and put it in ‘Remote command 3/4 (logged output)‘ and it works just fine. What’s going on here?

A Typical Windows DEL (delete) Command

DEL /q "C:\temp\New Text Document.txt"

The command above is a standard Windows deletion command that you can run at the command line of any Windows computer. It will simply delete the specified file. The ‘/q‘ is an instruction to *not* prompt the user for confirmation (y/n). We use the ‘/q‘ when we want to run the command without any further interaction, which is necessary when running it remotely since there is no way to interact with the remote command after it has been submitted. If the ‘/q‘ is not used for a remote DEL command, the file will not be deleted, and the remote command will hang indefinitely while it waits for someone to respond to the hidden y/n confirmation prompt. No one can respond to it though because it’s hidden; hence why we have to use ‘/q‘ in the first place.

Console / Shell Commands vs. Windows Executable Files

OK, so here’s the thing with the DEL command… On Windows computers there is no DEL.exe. Many commands like DEL are built-in to the Windows shell, whereas many other commands like IPCONFIG are actually separate executables. That is to say if you look in C:\Windows\System32, for example, you will find IPCONFIG.exe but you will not find DEL.exe because there is no DEL.exe. This fact is the reason why the above DEL command works in BatchPatch’s ‘Remote command 3/4‘ but not in ‘Remote command 1/2‘. This is explained more below.

Comparing BatchPatch Remote Command 1/2 vs BatchPatch Remote Command 3/4 (logged output)

When BatchPatch executes ‘Remote command 1/2‘, it uses the Windows Process class. It parses the command and assumes that you are running an actual executable. So, if you run ‘IPCONFIG’ in ‘Remote command 1/2‘, it works just fine because IPCONFIG.exe exists on all Windows computers, so BatchPatch uses the Windows Process class to execute IPCONFIG.exe, and everything works as expected. However, if you run a DEL command in ‘Remote command 1/2‘, it fails because BatchPatch looks for but cannot find DEL.exe (because it doesn’t exist).

When BatchPatch executes ‘Remote command 3/4 (logged output)‘, on the other hand, instead of parsing the command for the executable, BatchPatch runs the entire command inside of the Windows command console using CMD.exe. So, a DEL command works just fine in ‘Remote command 3/4 (logged output)‘ because under the hood BatchPatch is actually executing it more like this:

cmd.exe /c del /q "C:\temp\New Text Document.txt"

With all that said, if you want to execute

DEL /q "C:\temp\New Text Document.txt"

using BatchPatch, you can either execute it as-is by putting it into ‘Remote command 3/4 (logged output)‘ or you can modify it to run in ‘Remote command 1/2‘ by using this syntax instead:

cmd.exe /c del /q "C:\temp\New Text Document.txt"
Posted in Blog, General, Tutorials | Tagged , , | Comments closed