Blog | BatchPatch - The Ultimate Windows Update Tool

UAC Behavior with Remote WMI Connections in Non-Domain (Workgroup) Environments

By Scott | Published: August 15, 2018

When you are working in a network environment without a domain– that is to say there are no domain controllers and no member servers because all computers are simply part of a workgroup, authentication can be a challenge when trying to perform operations remotely. Generally speaking, if you have a network with enough computers where there is a need to perform any tasks remotely, you should ask yourself “Why is there no domain established yet?” because realistically there probably ought to be one. However, let’s assume that for whatever reason there is not already a domain and there is not going to be a domain, but you have tasks to perform on remote computers, then what?

OK, so the main issue you need to be aware of when dealing with remote WMI connections is User Account Control (UAC). In a workgroup/non-domain environment there will never be domain logon accounts, so all accounts that one needs to deal with are going to be local accounts. However, when working with local accounts, in order to execute many (not all) remote WMI queries or methods, remote UAC actually needs to be disabled on each target computer that is being operated on.

Disabling Remote UAC

Remote UAC is controlled by a single registry value. If the local account you are using to run the query (or in the case of BatchPatch, the account you are using to run BatchPatch or the account that you specify in the ‘alternate credentials’ field in BatchPatch) is not THE built-in administrator account on the target computers, but instead is just a regular named local account that is a member of the local administrators group on the target computers, then in order to disable remote UAC the following registry DWORD must be set to 1 on the target computers. If the DWORD does not exist or is set to 0, then remote UAC is enabled, and you will generally get ‘Access Denied’ when trying to perform a remote WMI query. To disable remote UAC, set the value of the following registry DWORD to 1. If the DWORD does not exist, then you must create it:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy

(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016 targets. NOT required for XP/2003 targets)

Disabling Admin-Approval Mode (Enabling Full-Token Mode) for the Built-in Administrator Account

Unfortunately that’s not everything. What if you are using THE built-in administrator account (as opposed to a regular named local account that is a member of the local administrators group on the target computers)? If the local account you are using to execute the WMI query/method is THE built-in administrator account on the target computers, the following registry DWORD must be set to 0 on the target computers. If the DWORD does not exist, then you must create it. When this DWORD is set to 0, the built-in administrator account is set to full-token mode, and WMI queries (including WMI queries executed through BatchPatch) will work propertly. However, if it’s set to 1, the built-in administrator account is put in admin-approval mode, which will prevent most remote WMI actions (including most BatchPatch actions) from completing successfully for those target computers:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\FilterAdministratorToken

(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016 targets. NOT required for XP/2003 targets)

Microsoft discusses remote UAC in more detail here. We discuss more about authentication options for BatchPatch here.

Posted in Blog, General, Tutorials | Tagged Local Accounts, remote UAC, UAC, wmi | Comments closed

Removing a Microsoft Office Update from Multiple Computers

By Scott | Published: July 31, 2018

This is one of those situations where something that seems like it ought to be very quick and simple is unfortunately not so quick and not so simple. The good news it’s also not *that* difficult, but there’s no question that it’s a pain and it takes a bit of effort.

It used to be the case that if you needed to remove a Microsoft Office Update such as KBXXXXXX that you could remove it just like you can remove any other Windows Update. In BatchPatch we have a couple of built-in options for executing the update removal process of a particular Windows Update that you can access under ‘Actions > Windows Updates > Uninstall individual update…‘ To use those menu items all you need is the KB number of the update that you want to remove.

Unfortunately for a while now the above-mentioned built-in commands for removing individual updates is only successful for standard Windows operating system updates. Microsoft Office updates, on the other hand, require a different removal command that unfortunately involves some manual digging.

The command line syntax options for removing a MSOffice update are as follows, but you have to substitute the correct Office GUID and Patch GUID values into your command, and this is what makes the process frustrating/tedious:

msiexec.exe /package {Office GUID} /uninstall {Patch GUID} /QN

msiexec.exe /package {Office GUID} /uninstall {Patch GUID} /QN REBOOT=REALLYSUPPRESS

This Microsoft Blog article explains the process for locating the correct GUIDs in the registry for the patch that you wish to uninstall.

After you find the appropriate GUIDs, you can form the actual command to use to remove the update. So, for example, the following command is an example of what your command will actually look like, as I have inserted actual GUID values, but as previously mentioned, you’ll need to find the GUIDs for the product and patch that you are removing.

c:\windows\system32\msiexec.exe /package {90140000-0012-0000-1000-0000000FF1CE} /uninstall {B23AAF3E-F931-4C72-8D96-7E58363A3D12} /qn

Once you have determined the proper syntax and have run it successfully on your test computer, you may insert it into a ‘Remote Command’ in BatchPatch. Highlight the desired target computer rows in the BatchPatch grid. Then select ‘Actions > Execute remote process/command > Create/modify remote command 1‘

Paste your command into the field, as illustrated in the screenshot above. Then either ‘Execute’ the command immediately or choose ‘Apply…’ to execute it later. Another option for executing at a later time/date is to hard-code the command into the BatchPatch menu by using ‘Actions > Execute remote process/command > Create/modify remote commands‘ In this case I have used ‘Apply…’ to apply the commands to each of the highlighted rows, which you can see in the screenshot below.

Now I can execute the applied command for each/every row by just selecting the rows that I want to include, and then clicking ‘Actions > Execute remote process/command > Execute remote command 1‘

Posted in Blog, General, Tutorials | Tagged microsoft office, msoffice, office, remove patch, remove update | Comments closed

Windows Server Patching Tools

By Scott | Published: July 25, 2018

We all know that keeping servers up to date is one of the most important aspects of keeping a secure environment. At one point or another every systems administrator is faced with the challenge of having to apply updates to numerous remote servers on a network. We have all been through the tedious process of manually connecting on an individual basis to each target computer, then applying updates or configuration changes, rebooting the computer, waiting 10 minutes, then checking to verify the computer did in fact reboot and that it did come back online after reboot. Multiply this process by a dozen or a hundred or even one thousand target computers, and all of a sudden the process becomes unwieldy, time-consuming, and downright stressful. The more computers that one is managing, the more quickly it becomes difficult to successfully keep track of the status of each target computer during such a process. Wouldn’t it be easier if we could just have a single console to manage all of the target computers, regardless of whether it’s 10, 20, 50, or 1000 machines?

BatchPatch was designed to make life easy for the systems administrators and engineers of the world. It enables the administrator to apply updates or make settings changes or to run scripts or applications remotely to numerous computers, simultaneously. No longer do you have to keep track of each machine individually with numerous remote desktop windows and ping windows etc. Instead you can just launch BatchPatch, add the desired target computers, select the desired action, and then just sit back and watch all target computers perform the specified action. You can install Windows Updates, deploy third party software or updates, deploy registry keys, run custom scripts, gather information for inventory or other purposes, etc. Or you can string together numerous actions into complete ‘job queues’ for single-click automation efforts.

In addition to the standard features mentioned above, BatchPatch also has unique sequencing functionality that enables the administrator to be able to create complex sequences of updates, reboots and deployments that involve numerous computers. Computers can be triggered by order in the sequence so that only certain machines are offline at any given time. The automation options are very cool, and they allow you to choreograph a “dance” of reboots and updates unlike anything you have seen before. With BatchPatch there is a surprising amount of functionality packaged into a very small executable. To read about all of the features that BatchPatch has to offer, please have a look at BatchPatch Home Page

Posted in Blog, General, Topics, Tutorials | Tagged server patching tools, windows update | Comments closed

Patch and Update Automation with Multiple Dependent Systems

By Scott | Published: July 18, 2018

I have posted articles and tutorials in the past on the BatchPatch feature known as the ‘Advanced multi-row queue sequence.‘ In fact there is a really thorough tutorial here that demonstrates how to integrate custom scripts into your job queues and multi-row queue sequences, which essentially enables the administrator to incorporate features/functionality into BatchPatch that might not exist already in a single-click menu item.

Today I’d like to discuss a bit more some thoughts on what an ‘Advanced multi-row queue sequence’ might look like in a different environment. For example, let’s say that you want to have one computer check for available updates and install them if there are any, but if there aren’t any, then you want the next server in the queue to do the same. Furthermore, if there *are* updates available for installation, you want to download and install them and reboot the computer, and then you want the computer to check again to see if after reboot any new updates became available. And again you want to then install any available updates, but if there are none available you want the next host in the advanced multi-row queue sequence to begin working. Additionally, if updates are available and installed and the host is then rebooted, you want to perform a verification check on that server to make sure that it is functioning properly before moving on to the next host in the sequence. There are surely multiple ways to accomplish something like this, but below I’m going to provide one possible way to accomplish this.

First, if you are not familiar with ‘Advanced multi-row queue sequence’ execution, please review the following links, which all demonstrate how to use it.

Advanced Multi Row Queue Sequence Video Tutorial

Virtual Machine Guest Host Update and Reboot Sequence Automation

Advanced Multi Row Queue Sequence Contingent Operations with Custom Scripts

Now, what if we apply the following job queue to each of the hosts in our advanced multi-row queue sequence? This allows us to have each host do multiple cycles of ‘download/install/reboot’ along with running a custom script to verify that our target is functioning in the way that we want … i.e. in addition to being online, which BatchPatch checks for, the custom script can check to see that the server is providing whatever service it provides. If the verification script finds that it is providing the service, the script returns 0. If the verification script finds that it is not providing the service, the script returns a non-0 integer. This enables us to use the two following special job queue items:

Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors

So, if we apply the queue below to three hosts in the BatchPatch grid, for example. And if include those three hosts in the advanced multi-row queue sequence, such that each host represents one sequence position, which means that each host will execute the complete job queue below in sequence, so that no host goes offline at the same time, and so that if one host fails the verification script, then no other hosts will be acted upon in any way, then we can accomplish a pretty solid automation routine.

Check for available updates
Terminate queue if previous 'Check for available updates' finds 0 updates
Download and install updates + reboot if required
Wait 10 minutes
Wait for host to be detected online
*Run a custom remote verification script/deployment that returns 0 if successful/OK, non-0 if unsuccessful/notOK
Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors
Check for available updates
Terminate queue if previous 'Check for available updates' finds 0 updates
Download and install updates + reboot if required
Wait 10 minutes
Wait for host to be detected online
*Run a custom remote verification script/deployment that returns 0 if successful/OK, non-0 if unsuccessful/notOK
Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors
Check for available updates
Terminate queue if previous 'Check for available updates' finds 0 updates
Download and install updates + reboot if required
Wait 10 minutes
Wait for host to be detected online
*Run a custom remote verification script/deployment that returns 0 if successful/OK, non-0 if unsuccessful/notOK
Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors

Posted in Blog, General, Tutorials | Tagged automation, queue, sequence, windows update | Comments closed

Does BatchPatch Work Over a VPN Connection?

By Scott | Published: July 4, 2018

One of the common questions we regularly receive is will BatchPatch be able to work over a VPN? BatchPatch *can* work over a VPN connection, but the real question is will BatchPatch work over *your* VPN connection? It really depends on how your VPN and VPN firewall are configured, not on how BatchPatch is configured.

In corporate environments we usually see two ways that VPNs are deployed. In one configuration a site-to-site VPN configuration might be used to effectively connect a remote office to a corporate headquarters in order for the users in the remote office to be able to connect to all the resources in the corporate headquarters just as if those users were connected directly to the LAN in the headquarters office. Typically in this kind of site-to-site VPN configuration there is little to no firewalling between the two offices, because the goal is for the remote office users to have an identical experience to the users who are directly connected to the main LAN back at headquarters. When a firewall is used to block ports or services between sites, the experience for remote users is quickly degraded because they don’t get the same unfettered access to resources that users in headquarters get. This diminished experience in turn makes it harder, sometimes, for remote users to complete their duties. Similarly, if there is significant firewalling of ports or services between the two offices, IT administrators who work in the main office might not be able to perform all of the duties that they need to perform on remote office computers. Furthermore, in the typical site-to-site VPN setup, users do not have to run special VPN client software on their computers. In fact, when they are plugged into the LAN in the remote office, they should have a seamless experience in which they cannot even tell that there is any difference to be connected to the main office. Plugging a computer into either the home office or the remote office should yield the same experience for the end user.

In the second type of configuration, instead of setting up a complete site-to-site VPN with little to no restrictions between the two sites, remote users might install a VPN client software on their computers. Whenever they want or need to connect to services in the main corporate headquarters they simply launch the VPN client software, click the ‘connect’ button, and then the VPN software establishes a tunnel to the corporate LAN. Once connected, the users are able to access various services that have been pre-configured by the IT department. In this case where VPN client software is used, it seems to be much more common in corporate environments for firewall configurations to be more tightly locked down such that only designated sites and services are made available to the end users who connect through the VPN. Frequently in this type of VPN configuration, if an application has not bee pre-approved and pre-configured to work across the tunnel, it won’t. And similarly, IT staff frequently are not able to connect from the main office to the VPN-connected client computers in order to manage them in the same way that they would be able to manage the computers that are directly connected to the corporate LAN. But again, it all depends on how the firewalls are configured.

So, when it comes to BatchPatch, if you’re not sure if it will work over your VPN, here is what I would suggest:

1. Download the free evaluation version of BatchPatch from https://batchpatch.com/download

2. Test BatchPatch on your main LAN without involving any VPNs. After all, if you can’t get BatchPatch working without using the VPN, then you’re certainly not going to get it working over the VPN. Please carefully review the ‘Getting Started‘ page to learn how to configure your environment to work with BatchPatch.

3. Once you have BatchPatch working on your main LAN, then go ahead and test it over the VPN. If it doesn’t work, visit the administrator or engineer who controls the VPN and firewall devices in your environment, and work with him or her to get everything configured for BatchPatch to function properly. In some cases if corporate policy prevents them from modifying the existing VPN to allow BatchPatch to function, they might still be willing or able to configure a specially permissioned VPN that is strictly for IT staff and that has less restrictions in place so that software like BatchPatch can be allowed to work over it.

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

Deploying .MSI Installer Packages to Multiple Remote Computers

By Scott | Published: June 28, 2018

If the software or update that you want to deploy to computers on your network is formatted as a .MSI file, here is how to use BatchPatch to deploy it to any number of computers at one time.

Add the desired target computers to the BatchPatch grid. BatchPatch provides numerous ways to add hosts to a grid, so just pick your desired method. You can import a text file list of computers using ‘File > Open…‘ or by just dragging and dropping the text file onto the BatchPatch window (unless you have launched BatchPatch as administrator, in which case drag-drop functionality will be disabled). Alternatively you could manually type or paste a list of computers into the ‘Add hosts‘ dialog under ‘File > Add hosts…‘, or if you are working in a domain environment you could add hosts from an Active Directory organizational unit (OU) or security group by selecting ‘File > Add hosts from directory…‘
Now that you have your desired hosts added to the grid, highlight them, and then select ‘Actions > Deploy software/patch/script/regkey etc > Create/modify deployment…‘
In the deployment window that appears, select the .MSI file that you plan to deploy. Note, some .MSI packages will initiate a reboot of the target computer, so if you want to prevent that from happening, then make sure to check the /norestart button. After installation you can then initiate the reboot yourself through BatchPatch under ‘Actions > Reboot…‘ so that you can more easily monitor what’s going on. Also, if the .MSI package has additional files that are required by it for it to run to completion, then you need to make sure to have those files in the same folder as the .MSI file, and then check the box ‘Copy entire directory contents in addition to the specified file‘. This way all of the required files will be copied to the target computer. Then when the .MSI file is executed, it will be able to find the other files that it needs to complete its work.
At this point we are ready to execute the deployment. If you want to save the deployment for execution at a later time, add a title in the ‘Deployment Title‘ field, and then save the deployment by clicking the double-right-arrow button. However, if you are ready to deploy the .MSI to your targets now, then just make sure they are all highlighted in the grid, and then click ‘Execute now‘. As always, we recommend testing any deployment on a single computer before attempting a larger deployment to many computers.

Posted in Blog, General, Tutorials | Comments closed

Inform Users Before Applying Updates and Rebooting

By Scott | Published: June 19, 2018

BatchPatch has a feature ‘Send message to logged-on users’ that enables the administrator to quickly and easily produce a pop-up message on the interactive desktop of target computers, so that a logged-on user will see the message. The message text is completely customizable, and the message can even be set to go away after X seconds. Used in conjunction with BatchPatch job queues and/or scheduled tasks means that you can setup a routine where at a scheduled time BatchPatch will automatically notify end-users with a pop-up message on their computers that in X seconds or minutes their computers will be updated and rebooted. Let’s go over how to set this up.

Create a message to send to logged-on users. Go to ‘Actions > Send message to logged-on users > Create/modify messages’. In the window that appears, create a message, give it a title, and optionally set the message to auto-close after X seconds. Then click the double-right-arrow button (>>) to save the message.

Create a job queue. The purpose of this job queue will be to send the message that was created in the previous step to target computers, then wait 5 minutes, then initiate an update/reboot task. Go to ‘Actions > Job Queue > Create / modify’. In the window that appears we’ll create a job queue with those steps. Note, since we saved our message to logged-on users, it now appears in the ‘Saved User-Defined Commands and Deployments’ grid in the lower-left portion of the job queue window. Give the job queue a title, and click the double-right-arrow (>>) button to save the queue.

Create a scheduled task. Now that we have a job queue saved, we can set it to be executed by the BatchPatch task scheduler at a desired time on a desired day. Highlight the desired rows/targets in your BatchPatch grid, and then select ‘Actions > Task scheduler > Create / modify scheduled task’. From the drop-down menu select the job queue that you created in the previous step. Then set a day/time for the task to be executed.

Enable the task scheduler. Now that the scheduled task has been created, the last thing that needs to be done is to enable the scheduler, which by default is not running. Click on the small red clock icon in the upper right corner of the screen. Upon clicking it will turn from red to green, indicating that the scheduler has been enabled.

Posted in Blog, General, Tutorials | Tagged logged-on user, message, notify | Comments closed

Quickly Confirming There Is Enough Disk Space On Remote Computers Before Patching

By Scott | Published: June 4, 2018

For those of you who already use BatchPatch, you’ve probably experimented with the built-in options it has for checking the disk space on remote computers. These options are pretty straightforward, and I will go over them in a moment. However, what I’d also like to address is the question of not just how do you check for disk space on remote computers, but how do you quickly and easily confirm that many remote computers have enough disk space available before you begin a patching operation? What I mean to say here is that while you can easily check for the available disk space on many remote computers using BatchPatch, how would you go about actually reviewing the results to make a quick determination that you have enough space on your target computers? If you have 100 or 1000 computers or more computers, it could take a long time to carefully review results. Of course you could write a custom script to handle this, but let me show you two very quick ways to accomplish this in BatchPatch with no custom scripting required.

Checking for Available Disk Space

Actions > Get information > Get disk space (% with graph)
Actions > Get information > Get disk space (available MB)
Actions > Get information > Get disk space (available MB) > All disks

Reviewing Disk Space Results Quickly

If you look at the screenshots above you can see the three primary ways that disk space info can be retrieved and displayed in BatchPatch. In the case of method 3 where we check for the disk space on all disks for a single computer, the results cannot be quickly reviewed for many computers, so let’s focus on the first two methods.

In method 2 where we get the available disk space in MB, we can quickly sort the rows by available MB, which gives us an immediate way of knowing which targets might be running tight on disk space. We can just look at the top of the grid (or bottom, depending on direction of sorting) to see the targets that have less available space on the scanned drive.

Unfortunately for method 1 the sorting option doesn’t give us great results because it will sort based on percentage used rather than actual available MB free. Percentage isn’t particularly useful if you really just want to make sure that each computer has, say, 1000MB free for Windows Updates to be applied since the percentage depends on the overall amount of disk space available.

However, we do actually have another facility that makes method 1 a more viable option for quickly determining if there is enough disk space. Under ‘Tools > Settings > General‘ there is a setting called ‘Low Disk Space Warning Threshold (MB)’ for which the default value is 500. For the sake of this example I’m going to set it to 50,000. Note, this is not a practical value to set, but I’m using it in this example just to illustrate what it does. A more practical value might be something like 1500MB or 2000MB, depending on your preference for how much free space should trigger the warning.

Notice that when I re-check the disk space %, now each target that has less than 50,000MB available on the scanned disk will show the bar in red instead of purple, so unless you are color-blind, this could be another method for quickly confirming available disk space is above a desired threshold on numerous computers.

Posted in Blog, General, Tutorials | Tagged disk space, free disk space, remote disk space | Comments closed

Automated Patch Management

By Scott | Published: May 28, 2018

Today I’d like to go through all the ways that BatchPatch can be used to automate your software and operating system patch management.

Standard BatchPatch Actions:

If you log on to a computer locally to apply updates and reboot, it’s a multi-step process. First you have to use remote desktop to connect to the desired computer, then you have to logon, then you have to launch the Windows Update control panel, then you have to download and install the available updates. At this point you’d have to wait usually at least a few minutes, but sometimes much longer while the download and update process completes. And even after the updates have been installed you still then have to manually initiate a reboot and monitor the computer with a ping command or a monitoring tool while the reboot is taking place, so that you can confirm that the computer is back online after the reboot. This process could easily take 30 minutes per computer, which is fine if you just have a few, but what if you have dozens or hundreds or even thousands of computers to manage?

With BatchPatch you can add all of the desired computers to a grid, and then select the entire lot to ‘Download and install updates + reboot if required.’ Instead of having to individually log on to each computer to perform the action, BatchPatch will remotely connect to every computer at the same time to initiate and monitor the whole process. You can have the entire fleet of computers updated and rebooted within a matter of minutes. How’s that for automation! BatchPatch can perform almost any action that you would ever need to perform on remote computers, and it can do all of the remote computers simultaneously. This is great for deploying software or updates, or for executing remote commands or scripts, or for retrieving information or updating registry values etc.

Example:
batch-install-windows-updates

Scheduled Tasks:

Ok, so you’ve been using BatchPatch to manage updates, but what if you don’t even want to touch the BatchPatch console? You could further automate your updating process by scheduling task to occur at a desired date/time, so that when that time arrives BatchPatch will automatically launch the tasks that you scheduled across whichever target computers you created the schedule for. You can even have it email you a copy of the BatchPatch grid for review so that you don’t have to touch the BatchPatch console during the maintenance window, if so desired.

Another automation option for scheduled tasks is the facility in the scheduler to ‘Run task immediately upon detecting target computer online’. This option let’s you configure a scheduled task to run as soon as BatchPatch detects the target computer on the network, rather than having to wait for a specific scheduled date/time for the task to run. This way if you have computers that are frequently pulled off the network, instead of scheduling an update process to occur at a date/time, since you don’t know if the computer will be connected to the network at that time, it’s often easier to just have BatchPatch run the task as soon as the computer is detected online.

Example:
using-the-task-scheduler-in-batchpatch

Job Queues:

If you need to run multiple different tasks in a specific sequence so that you can start and stop scripts before and after patching, or execute multiple patch and reboot cycles with a single click, or any number of other things, check out the Job Queue feature.

Example:
using-the-job-queue-in-batchpatch-for-multi-step-execution

Multi-Row Sequences:

What about the case where you have multiple computers that are all dependent on one another in some way, such that you want to make sure that only one of them is taken offline at any given time. Or perhaps you want/need to apply updates and reboot these computers in a specific order. Or maybe it’s a virtual machine host with a number of virtual machine guests on it, and you want to apply updates to all guests first, and then when the guests are complete you want to update and reboot the host. Well, you could certainly oversee this process manually. You could make sure to be careful about which machines you update and in which order and when. However, wouldn’t it be nice if you could kick off these entire sequences with a single click rather than having to manually manage the whole process? BatchPatch has a feature called “Advanced multi-row queue sequence” that enables the administrator to construct sequences of actions across multiple computers for maximum automation and control.

Example:
advanced-multi-row-queue-sequence

Posted in Blog, General | Tagged Automated Patch Management, automation | Comments closed

Remotely Uninstall Firefox from Multiple Computers

By Scott | Published: May 21, 2018

Removing Firefox from numerous computers does not have to be a tedious process. While you could certainly use remote desktop to connect to each target computer and then manually launch the add/remove programs applet, this would take a very long time if you had to perform the task on dozens or perhaps hundreds or even thousands of computers. Alternatively you could just use BatchPatch to perform this task on all of your remote computers at the same time, enabling you to effectively uninstall Firefox from your entire network of computers in under a minute. The process if very straightforward and simple.

First you’ll just need to identify the installation directory on your computers. For example, on my lab computers Firefox is installed in either “C:\Program Files\Mozilla Firefox” or “C:\Program Files (x86)\Mozilla Firefox”. If your computers have Firefox installed in a different directory then just make sure you substitute your installation directory in the command instead of using the one in my command.

In order to remove Firefox from numerous computers using BatchPatch, we first have to be able to successfully uninstall it from a single computer at the command prompt with no user interaction. We need the process to execute “silently” or “quietly” so that it simply runs to completion without needing any additional interaction from the user or administrator to complete the process. We don’t want a situation where we have to click “yes” or confirm in some other way to proceed with the uninstallation. We just want the process to run on its own after we launch it. So first to confirm that we are able to successfully remove the software from just one computer using the command prompt rather than BatchPatch, we execute the following command in a cmd.exe window.

The x64 version of Firefox default setup uninstall command:

"C:\Program Files\Mozilla Firefox\uninstall\helper.exe" /S

The x86 version of Firefox default uninstall command:

"C:\Program Files (x86)\Mozilla Firefox\uninstall\helper.exe" /S

Run the command and make sure that it successfully removes Firefox. If the command does not successfully remove Firefox on your computer at the command prompt, then there’s no way that BatchPatch will be able to remotely execute the same command with success. However, the command should work for you just as it did for me to completely remove Firefox. Once confirmed, we can then run the same command in BatchPatch to target numerous remote computers, simultaneously.

We highlight the desired target computers in our BatchPatch grid and then select ‘Actions > Execute remote process/command > Create/modify remote command 1’

In the command window you may insert the removal command just as I have done here:

Click ‘Execute’ to launch the command on all of the selected/highlighted hosts in the BatchPatch grid. In my lab the entire process completes in just a handful of seconds. Firefox is removed, and I can go on about my other business. 🙂

Posted in Blog, General, Tutorials | Tagged remote uninstall software, remove firefox, remove software remotely, uninstall firefox | Comments closed