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

BatchPatch – New Release 2020-09-25

By Scott | Published: September 30, 2020

We published a new build at the end of last week. Here are the highlights:

Search for Updates with Filters Applied – Menu and Job Queue Items:

We added the following Windows Update action menu items:

*Check for available updates (with filters applied)
*Generate consolidated report of available updates (with filters applied)
*Retrieve consolidated url list of available updates (with filters applied)

Previously a search for updates would find all available updates, based on the search settings. However, this wasn’t super helpful if you wanted to know which updates were applicable to target computers *after* the download/install filters had been applied. Now with these new menu items you have the ability to perform a search for updates with the filters applied so that you can preview exactly which updates will be applied when the actual download and installation takes place.

Similarly, we also added the following items to the job queue:

*Check for available updates (with filters applied)
*If most recent ‘Check for available updates (with filters applied)’ found 0 updates, terminate queue
*If most recent ‘Check for available updates (with filters applied)’ found 0 updates, send email notification
*If most recent ‘Check for available updates (with filters applied)’ found 0 updates, goto label:X
*If most recent ‘Check for available updates (with filters applied)’ found any updates, goto label:X

These new job queue items will enable you to tweak your loops/branches/gotos to take into account the post-filter available updates list instead of just the pre-filter list.

Customization of User-Defined Entry Visibility and Order in Menus

All user-defined entries in the software can now be hidden from the menus, so you can customize which commands/deployments/queues etc that you want to be visible in the main menus without having to delete commands altogether in order to hide them. If you look at the screenshot below you can see that I have only checked the box next to the first two remote commands in my list. As a result of doing that, only those two commands appear in the ‘Execute saved remote commands‘ menu item. In addition to remote commands you can do the same for job queues, deployments, messages to logged-on users, copy jobs, and local commands. Additionally, you are now able to change the order of how the visible entries appear in the menus.

Confirmation Dialog Windows Now Always Fit Contents

If you are executing a job queue with numerous steps, you’ll now always be able to see the entire set of steps appear in the confirmation dialog that appears before final execution. The confirmation dialog windows throughout the app now have a scrollbar, which will be visible only if needed, so that you can now view the entire dialog contents, even in cases where the text would have been truncated in previous versions. Additionally, the confirmation dialog windows are now also resizable. In a future version we may add the ability for the window settings to be customizable by users, but for now, the good news is that you won’t have to guess at the contents anymore if you are about to execute a job queue with a lot of steps.

Bug Fixes and Miscellaneous

As always, there were a number of bugs that we fixed. Additionally we made various other minor improvements and updates throughout the code; some visible and most invisible.

Posted in Blog, General | Comments closed

Verifying the Authenticity and Integrity of BatchPatch.exe

By Scott | Published: September 29, 2020

PROTECT YOURSELF any time you download an executable file from the internet. *Before* you launch a freshly downloaded file for the first time, ensure that it’s safe. Check the digital signature to confirm that it’s signed by the publisher, and scan the file for malware. See below for more.

Sometimes we are asked why we don’t have a listing of file hashes next to the download link on our website. We definitely understand why it’s important for users to verify the integrity of a file that they download from us. We don’t want you to use a file that has been modified or tampered with, and you certainly should not open such a file on your computer. For this reason, we always digitally sign the BatchPatch.exe. A digital signature enables the end-user to confirm that a file was both published by the intended/expected source (in this case by us, Cocobolo Software, LLC) and also has not been modified, altered, or tampered with after being published or while being downloaded. A file hash on its own does not provide any any assurance that the file was published by the intended/expected source, so it is inferior to a digital signature. For example, imagine a scenario where a website is hacked. The hacker then does two things: She replaces the downloadable file on the website with her own a malicious file, and then she also replaces the file hash next to the download link to match that of the malicious file. If an end-user then comes along to download the file, he might think he is downloading a safe file because the file hash posted on the website matches the actual hash of the file after being downloaded. But little does he realize that he has downloaded a malicious file. So, for this reason, we don’t post file hashes. We do always digitally sign our BatchPatch.exe.

To verify that the BatchPatch.exe that you download from us is authentic and has not been modified or tampered with, we recommend that you check the digital signature on the BatchPatch.exe before you launch it. In this case, by verifying the digital signature on BatchPatch.exe you can be assured that the file you have is the file that we published, and that it has not been modified in between the time that we published it and the time that you obtained it. If the BatchPatch.exe does *not* have a digital signature at all OR if it has a digital signature that is *not* signed by us, Cocobolo Software, LLC, then you’ll know that the file you obtained is *not* the file that we published. Additionally note that at the time of this writing, DigiCert is our certificate authority, which means that you will see DigiCert as the issuer in the certificate.

How to Check the Digital Signature on BatchPatch.exe

  1. At the time of this writing, the BatchPatch.exe is delivered as a single ZIP file. You’ll need to start by extracting the EXE from the ZIP (right click on the .zip and choose ‘Extract’ or use your favorite extraction tool, such as 7-zip). After extracting the EXE, in Windows Explorer right-click on the BatchPatch.exe file that you obtained from us and click ‘Properties’ in the drop-down menu that appears. In the ‘BatchPatch.exe Properties’ dialog, first make sure that you see a ‘Digital Signatures’ tab. If there is no ‘Digital Signatures’ tab then it means the file is not signed. If the file is not signed, do not open it on your computer.
  2. Next, take note of who the signer is. In the screenshot above you can see the signer is us, Cocobolo Software, LLC. If you double-click on the row, or highlight the row and click ‘Details’, you can further examine the certificate, if desired.

Perform a Virus Scan on Files that you Download from the Internet:

It’s always a good idea to make sure that virus scanners aren’t alerting on the downloaded file. Even if you download a file from a trusted publisher, it’s always possible that the trusted publisher’s site has been hacked or modified without their awareness, and that a file has been modified or replaced with a malicious substitute. Use your preferred virus scanning tool, or use an online virus scanner such as VirusTotal to check any file that you download from the web before you ever launch that file for the first time.

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

Deploying .msi, .msu, and .msp Files Remotely to Numerous Computers

By Scott | Published: September 17, 2020

You can use BatchPatch to deploy virtually any type of file or package to target computers. As Windows systems administrators, we commonly have to work with .msi and .msu files, and occasionally we need to deal .msp files too. If you have a .msi, .msu, or .msp file that you need to install on numerous computers, consider using BatchPatch to perform the task. Instead of manually logging on to each target computer, you can quickly and painlessly create the deployment in BatchPatch for distribution to any number of remote computers.

Creating a BatchPatch Deployment

The process for creating a deployment for any of the aforementioned file types (.msi, .msu, .msp) is essentially the same.

  1. In BatchPatch click on ‘Actions > Deploy software/patch/script/regkey etc > Create/modify deployment‘
  2. In the Deployment window that appears, give the deployment a title, and then in the ‘Exe, msi, cmd, etc:‘ field, browse to the file you want to deploy, or manually type the path into the field. In this example you can see that I am deploying E:\temp\Special.msi. Note, if the package that you are deploying is not a standalone package but rather is one of numerous files required for the installation, then put all of the files into the same directory, and then also tick the box to ‘Copy entire directory‘. Generally, for .msi, .msu, and .msp files, they will be standalone, but if you are using ‘Copy entire directory‘ just make sure that *only* the files that are required for the deployment are included inside the directory that will be copied. This is because any/all files in that directory will be copied to each target computer where the deployment is executed, so you’ll want to ensure that only the needed files are copied, otherwise the deployment will take longer to execute, and you could even potentially end up with a disk space issue on target computers if you have very large unneeded files in the directory that is being copied.
  3. You can save the deployment by simply clicking on the double-right-arrow button. Once saved, you’ll see it appear in the list of ‘Saved Deployments’ on the right-hand side of the Deployment window. You have a couple of options for actually executing your deployment.

    4. Executing a BatchPatch Deployment

  4. If you click the ‘Execute now‘ button inside of the Deployment window, BatchPatch will immediately launch the deployment for any rows that are currently selected/highlighted in the grid. However, if you are not ready to execute yet, you can just close the Deployment window until you’re ready. Then when you’re ready, go ahead and select/highlight the desired target computers in your BatchPatch grid, and then click on ‘Actions > Deploy software/patch/script/regkey etc > Execute saved deployments > My Special.msi deployment‘

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

Error retrieving service instance data: The maximum message size quota for incoming messages has been exceeded.

By Scott | Published: August 31, 2020

Today I’d like to discuss an uncommon error that can occur when trying to launch selected .bps files that are active in the BatchPatch service instance. First, if you’re not sure what the BatchPatch service instance is, you might not be running BatchPatch as a service. This error can and will only occur when a grid is already running in the BatchPatch service instance, and then you try to view the contents of that grid. Running BatchPatch as a service is something that users can do if/when they want to be able to have BatchPatch run and execute scheduled tasks without needing to be logged-on to a computer with BatchPatch actively open and running. The service instance enables BatchPatch to run as a service, in the background, even when no one is logged-on to the computer. To learn more about running BatchPatch as a service, please review this page: Running BatchPatch as a Service

The error shown below that I want to address is:

Error retrieving service instance data: The maximum message size quota for incoming messages has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element

When BatchPatch is running as a service, the main BatchPatch instance (the one you see when you manually launch BatchPatch) communicates programmatically with the (hidden/invisible) BatchPatch service instance. When you view grids that are currently active/running inside the service instance, the main BatchPatch instance queries the BatchPatch service instance to retrieve the data that it then displays in the service instance grid viewer, as illustrated in the screenshot below.

When the main BatchPatch instance queries the BatchPatch service instance for grid data, the BatchPatch service instance then packages and compresses the data to send to main BatchPatch instance. If this compressed grid data is not smaller than the MaxReceivedMessageSize property, then the above-mentioned error message is generated. At the time of this writing, the BatchPatch MaxReceivedMessageSize is set to 2000000. This value is *not* user-configurable at the time of this writing, though we may expose this is as a user-configurable setting in a future version. In practice, 2000000 is plenty large enough to accommodate the very large majority of grids. However, if your actual .bps file grid data starts approaching 20MB (or greater), you might encounter the above-mentioned error. Even in the absence of this error message, a 20MB .bps grid file is still very large and should be cleaned up to make smaller.

Reducing the size of a BatchPatch .bps grid file

To check how large your .bps grid file is, simply browse to the location of the .bps file in Windows Explorer, and then right-click on the file and select ‘Properties.’ You can see in the screenshot below that my .bps file is only 24.4KB. If you are seeing the above-mentioned error message, then your .bps file is probably at least 15MB-20MB in size.

To reduce the size of your .bps file you have a few different options:

  1. Find where the bulk of the data in the .bps file is, and then remove/purge that data. Usually if you have a very large .bps file, the bulk of the data is going to be in the ‘All Messages’ column. You can selectively and simply purge this data by selecting the desired rows in the grid, and then clicking on ‘Actions > Clear column contents’ as described here: Clearing Column and Grid Contents in BatchPatch. If you are using BatchPatch job queues, you can even add a step to your queues that will execute a ‘Clear column contents’ operation for you.

  2. If you don’t want to clear the column contents in your existing .bps file, you may simply archive your existing .bps file, and then start a new one from scratch.

  3. Alternatively, you might prefer to split up your existing .bps file into multiple .bps files, which you can do by moving hosts from one grid to another. To do this, select the desired hosts to be moved, and then click on ‘Actions > Move or copy host(s) to different tab‘, and then make sure to select the option to ‘Move entire rows‘.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Reset Windows Update with a Single BatchPatch Remote Command

By Scott | Published: August 17, 2020

We recently received a request to integrate the following into BatchPatch, so that with a single click a user could perform the following actions on numerous target computers:

  1. Stop the Windows Update service by running the following command: 
    NET STOP WUAUSERV
  2. Rename the C:\Windows\SoftwareDistribution folder to C:\Windows\SoftwareDistribution.old

  3. Start the Windows Update service by running the following command: 
    NET START WUAUSERV

Currently there is not a built-in macro in BatchPatch for the above items, but the good news is that it’s easy to create your own one-click method to perform the tasks.

Before I explain how to easily incorporate this macro into your own BatchPatch instance, let’s briefly discuss the impact and implications of performing these actions. Essentially, it’s only step 2 that really *does* anything destructive, but you can’t perform step 2 without first stopping the Windows Update service. So, step 1 stops the Windows Update service, step 2 renames the SoftwareDistribution folder to SoftwareDistribution.old, and then step 3 restarts the Windows Update service. When it starts, Windows will automatically recognize that there is no longer a SoftwareDistribution folder in C:\Windows, thereby forcing it to actually create a new one from scratch.

Windows stores downloaded updates in the SoftwareDistribution folder along with a database that retains history information about updates that have previously been installed. If you have downloaded Windows updates but have not yet installed them, they will be stored in this folder until they are installed. However, if you then delete the contents of the folder or rename the folder, thereby forcing Windows to create a new folder from scratch, your downloaded but not yet installed updates will be deleted, requiring you to download them again from scratch before you can install them. Additionally, much of the Windows Update history information that Windows retains about updates that have previously been installed is stored in a database that is housed in this folder. If the folder has been renamed or deleted, you may no longer be able to determine when a particular update was previously installed. In Windows 10 it has already become increasingly difficult, or in some cases impossible, to determine when old updates were installed, because each time you install a feature update, most of this update history information is wiped since most feature update installations are treated by Windows like a complete operating system upgrade / reinstall. That said, the loss of history information that occurs when the SoftwareDistribution folder is renamed or deleted may not be such a big deal to you since you’re probably going to lose some of that information at some point in the future anyway (if you’re running Windows 10).

Many forums on the web will describe the process of renaming or deleting the SoftwareDistribution folder as a good way to reset the Windows Update components. We have even occasionally suggested it in our forums. Before you go about doing this, you should make sure you really want to do it. It will certainly fix certain issues at certain times, but I wouldn’t recommend using it as a “first-try” option. Usually this process should be reserved for a last resort attempt at fixing your issue. Also note, it generally always makes more sense to rename the folder as opposed to delete it altogether because if on the off chance it creates a problem, you can always revert back to the renamed folder, if need be. If it works without issues to solve your problem, then you can certainly just move forward and delete the old folder that you had renamed so that it’s no longer taking up space on your hard drive.

OK, so to perform the above operations as a single-click task in BatchPatch, you’ll need to do the following:

  1. Select ‘Actions > Execute remote process/command > Create/modify remote commands’
  2. In the window that appears, click ‘Add Row’ and then enter the following syntax into the ‘Command’ field (you can use any title that you like in the ‘Title’ field): 
    NET STOP wuauserv & MOVE C:\Windows\SoftwareDistribution C:\Windows\SoftwareDistribution.old & NET START wuauserv

  3. That’s it! Now when you are ready to execute the task on target computers, simply highlight the desired rows in the BatchPatch grid, then select ‘Actions > Execute remote process/command > Execute saved remote commands’. Find your command in the menu and click on it to execute it on the selected target hosts.

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