“Dual Scan” Difficulties with Windows Update on Windows 10 versions 1607 ‘Anniversary update’ and 1703 ‘Creators update’

There is new required reading from Microsoft for all systems administrators who are managing Windows Updates in their organizations. We *strongly* recommend that all of you carefully read the following two articles so that you are aware of this new (and unexpected) behavior of the Windows Update client:

Demystifying “Dual Scan”
Improving Dual Scan on 1607

Microsoft has recently modified the behavior of Windows Update such that if you currently have your clients configured via group policy to point to an internal managed WSUS, it’s possible, depending on how things are configured, that scans for Windows Updates for your target computers might now be bypassing your WSUS and utilizing Microsoft’s public Windows Update servers instead. They describe “Dual Scan” as follows:

It is for the enterprise that wants WU to be its primary update source while Windows Server Update Services (WSUS) provides all other content. In this scenario, the WU client automatically scans against both WSUS and WU, but it only accepts scan results for Windows content from WU. Stated another way, anything on WSUS that resides in the “Windows” product family is ignored by the Dual Scan client. This is to avoid the “two masters” problem that can occur when there are multiple equally valid sources of truth for a given set of updates.


Dual Scan is automatically enabled when a combination of Windows Update group policies [or their MDM equivalents, or the underlying registry keys corresponding to either set of policies] is configured:

  • Specify intranet Microsoft update service location (i.e., WSUS)
  • Either of the policies belonging to Windows Update for Business
    • Select when Feature Updates are received
    • Select when Quality Updates are received

The group policies mentioned above are located in group policy:

Computer Configuration\Administrative Templates\Windows Components\Windows Update\Defer Windows Updates

In my particular case I have ‘Configure Automatic Updates’ and ‘Specify intranet Microsoft update service location’ enabled. These are the two standard/typical policies that any organization will have enabled if they are using a WSUS instead of Windows Update or Microsoft Update.

These two policies are located in group policy:

Computer Configuration\Administrative Templates\Windows Components\Windows Update

Additionally, I also have the ‘Defer feature updates’ setting enabled on my Windows 10 computers. This setting is visible in the ‘Advanced options’ for Window Update Settings control panel, and it’s similar to the group policy ‘Select when Feature Updates are received’ mentioned above.

The behavior that resulted from having the combination of policies described above enabled on my computer is that all of a sudden my scans for Windows Updates were being performed on Microsoft’s public Windows Update server instead of my internal managed WSUS server. Frankly, I was absolutely *shocked* at this change in behavior. We believe that this behavior should not have been automatically enabled by Microsoft but rather should only have been enabled if/when the administrator turned on this capability. However, we obviously have no control over Microsoft, which means that now we instead must just focus on understanding how to effectively disable this behavior.

How to Disable “Dual Scan”

Option 1:
One quick and simple way to disable “Dual Scan” so that your computers will only reach out to your internal WSUS and will not perform scans on the public Windows Update servers is to simply disable ‘Defer feature updates’ or set both of the following two policies to ‘Not configured’

‘Select when Feature Updates are received’
‘Select when Quality Updates are received’

Option 2:
If you want or need to leave one of the policies mentioned in ‘Option 1’ enabled, then you may instead enable a new policy ‘Do not allow update deferral policies to cause scans against Windows Update’. You can find it in group policy:

Computer Configuration\Administrative Templates\Windows Components\Windows Update

The problem, unfortunately, is that this policy exists for Windows 10 version 1607, but at the time of this writing on 2017-09-19 does not yet exist for Windows 10 version 1703. Frustrating, I know!

Additional Notes

  • If you try to enable the ‘Computer Configuration\Administrative Templates\System\Internet Communications Management\Internet Communication settings\Turn off access to all Windows Update features’ group policy then you might start seeing ‘Error -102: Failed to execute the search. HRESULT: -2145124306’ in BatchPatch.
    0x8024002E -2145124306 SUS_E_WU_DISABLED non managed server access is disallowed
  • If you try to enable the ‘Computer Configuration\Administrative Templates\Windows Components\Windows Update\Do not connect to any Windows Update Internet locations’ you might start seeing ‘-102: Failed to execute the search. HRESULT: -2145103860’ in BatchPatch.
    0x8024500C -2145103860
  • In troubleshooting this issue I also encountered ‘-102: Failed to execute the search. HRESULT: -2145123272’ at one point when my WSUS was offline
    0X80240438 -2145123272
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

Some of the “Fun” Features You Didn’t Know About in BatchPatch

Custom Row Selection Color:

You are probably already aware of the fact that you can modify the row selection color in BatchPatch. To do this you would select ‘Tools > Row selection color…’ or you could click on the color palette image in the menu strip.

However, what you might not be aware of is that you can choose a custom row selection color instead of having to use one of the pre-configured color options. To do this you must first launch the Row Selection Color form using one of the methods described above. Then inside the Row Selection Color form click on the color palette image at the bottom.

Then you can use the ‘Define Custom Color’ button in the Windows color palette control to set your own custom color.

Now you can have that ‘lime green’ row color option that you’ve been dreaming about. 😉

Alternating Rows Back Color Intensity:

BatchPatch comes out of the box with a pre-configured alternating rows gray back color, but the intensity of this gray color is actually user-configurable. See the following two screenshots for the extreme examples, but note that you can also select any intensity in between these examples.

To modify the intensity, click on the tiny arrow icon in the lower left corner of the BatchPatch main form. A slider appears that allows you to adjust the intensity of the alternating rows back color.

Grid Borders:

The BatchPatch grid borders can be set in four different positions. Use CTRL-B to change the setting to one of four options:

1. Vertical and horizontal borders

2. Vertical borders only

3. Horizontal borders only

4. No borders


And finally in the category of “Why would you ever need this?” we have the transparency option. We added this in the original version of BatchPatch simply because we could and it seemed kind of fun at the time, so why not! Clicking on the tiny arrow icon in the lower right corner of the BatchPatch main form will reveal a slider that can be used to control the level of transparency in the BatchPatch window.

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

Understanding the ‘Local Downloader’ in BatchPatch ‘Cached Mode’ and ‘Offline Mode’

One of the questions we receive sometimes is about the local downloader. While using BatchPatch ‘cached mode’ and/or ‘offline mode’ to download and install Windows updates on target computers, it can appear sometimes that everything is queued unnecessarily. One row will be executing the local downloader while other rows sit in a queued state, apparently not doing anything. Below I will explain why this happens and why it’s intentional and also not problematic and not “slow.”

The first thing to consider is that when BatchPatch is operating in ‘cached mode’ and/or ‘offline mode’ all updates that are needed by target computers are downloaded by the computer running BatchPatch, not by the individual target computers. In contrast, when running in regular/normal mode, each target computer downloads its own updates, independently, from the source update server, whether that be a local WSUS or directly from ‘Windows Update’ or ‘Microsoft Update.’

When BatchPatch is operating in ‘cached mode’ you will see ‘Executing local downloader’ appear sometimes in one of the BatchPatch rows where you executed ‘Download available updates’ or ‘Download and install updates.’ You will usually *not* see this appear in every row, and in fact it usually won’t even appear in most rows. Additionally, while one row displays ‘Executing local downloader’ you will notice that other rows might be put into a ‘Queued…’ status.

This behavior is expected / intentional, and it will not slow down your process. The reason for this behavior is because when BatchPatch operates in ‘cached mode’ the BatchPatch computer is responsible for downloading all required updates to its local cache before it can push those updates out to target computers. We intentionally do not execute more than one local downloader at any given time because we do not want the BatchPatch computer to unnecessarily download the same update more than one time. After all, this is one of the primary purposes for using ‘cached mode’ in the first place. If you are downloading/installing updates on numerous computers, in most cases you are going to be applying the exact same update to more than one computer. If each row in BatchPatch executed the local downloader simultaneously, then in the large majority of cases each row would instruct BatchPatch to download many of the same updates that are already being downloaded by another row. The most effective way to handle this situation is to prevent more than one local downloader from executing at any given time.

Imagine that you have 100 computers all requiring mostly the same updates to be installed. It’s possible that the list of applicable updates is not identical for each computer, but generally speaking when dealing with a group of computers on a network, in most cases there will be a lot of overlap in terms of which actual updates are required for computers. If you select all 100 rows/hosts and then initiate ‘Download and install updates’ with ‘cached mode’ enabled, the first row that starts executing will be the one to execute the local downloader. Other rows will be queued while the local downloader executes. The BatchPatch local downloader will then download all of the updates needed for that particular host to the local cache directory. As soon as the local downloader completes for that row, the next row will check the cache directory to see if the updates it requires are already downloaded. If it finds the updates that it needs, then it will not execute the local downloader because the updates it needs are already downloaded to the cache. The process for it to check the cache and move on to the next step happens almost instantaneously if the updates already exist in the cache. However, if one or more updates has yet to be downloaded, then this row will also initiate the local downloader just as the previous row did, and then BatchPatch will download any needed updates that do not yet exist in the cache.

When the process outlined above is executing, typically what you see in the BatchPatch console is a period at the beginning of execution where most rows are doing nothing and show ‘Queued’ while just one row executes the local downloader. However, once the first row completes the local downloader process, all other rows will begin processing. This is the most efficient way to handle this process while ensuring reliability. So, while it may seem at first like things could take forever, since it appears at the onset that only one row is doing anything, in fact things will not take forever and will actually move quickly once the first local downloader completes. If you encounter this situation, please be patient and wait for the local downloader to finish downloading updates to the local cache. Once that process has been completed, in most cases you can expect everything else to move quickly from that point forward.

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

Remotely Upgrading Windows 10 to the ‘Creators Update’ version 1703 (or to the ‘Anniversary Update’ version 1607)

At the time of this writing Microsoft does not currently enable/allow remote silent deployment of Windows 10 feature upgrades (like the ‘Anniversary Update’ version 1607 or the ‘Creators Update’ version 1703) through the normal channel that BatchPatch uses to apply Windows updates. It’s true that if you use the normal Windows Update control panel interface to manually apply updates on an individual computer without the use of BatchPatch, then you will be able to successfully install the Windows 10 feature upgrades this way. However, using this method you would have to go to each target computer individually to manually apply the available updates through the control panel, which of course is far from optimal. If you want to use BatchPatch to remotely deploy Windows 10 feature upgrades, then you may use the method outlined below.

Deploying Windows 10 Feature Upgrades Remotely with BatchPatch

  1. The first thing that we need to do is obtain the installation media, ideally in ISO format. We accomplished this by running the Windows 10 Media Creation Tool, but if you have a volume licensing agreement with Microsoft then you ought to be able to obtain the ISO media through that channel, and then you can skip down a few steps in this tutorial for deployment instructions. With the Windows 10 Media Creation Tool you cannot select the specific version of Windows for which you want to obtain media. It seems that when you use the Media Creation Tool to create Windows 10 media you will always get the latest version of Windows 10 available, so keep that in mind. The Windows 10 Media Creation Tool is available here.
  2. To run the media creation tool you must be logged on to the computer as a local administrator. It is not sufficient to be logged on as a normal user and use ‘run-as’ to run the tool as an admin user. For whatever reason if you try to do that, the tool will not let you proceed until you actually log on to the computer as the admin user.
  3. When you run the tool you will have the option to either Upgrade this PC now or Create installation media (USB flash drive, DVD, or ISO file) for another PC. Select the Create installation media option, and then click Next.
  4. At the next prompt you will be able to select the language, edition, and architecture. Then click Next.
  5. Finally, select the option for ISO file and click Next.
  6. At this point you will be prompted to choose a location on disk to save the ISO file. Do that and then wait until the download has completed.
  7. Once the ISO file has been obtained, the next step is to extract its contents to a directory that you specify. I used 7-zip to accomplish this, but you can use whichever extraction tool you prefer.
  8. After you have extracted the ISO you should have a directory that contains the required installation files.
  9. At this point we can setup the BatchPatch Deployment. Select Actions > Deploy > Create/modify. In the Deployment interface, select the setup.exe (from the extracted contents of the ISO) as the file to deploy, and make sure to check the ‘Copy entire directory’ box. Also you need to add the following parameters:
    /auto upgrade /quiet

  10. When you are ready you can either save the deployment to execute later by using the double-right-arrow ‘>>’ button, or you can execute the deployment now for the currently selected rows in the BatchPatch grid by clicking the Execute now button. The deployment will take some time because BatchPatch has to copy multiple GBs of data to the target computers before it can execute the upgrade. When BatchPatch shows Exit Code: 0 (SUCCESS) for a given target computer you should expect that the target will still be working and will still reboot at least one time but possibly multiple times while Windows is upgraded and configured on the target, so be patient and let it do its thing!
Posted in Blog, General, Tutorials | Tagged | Comments closed

Automate Windows Update Installations for Multiple Remote Computers

One of the common reasons that IT administrators use BatchPatch is to help automate processes, which in turn leads to less time spent dealing with patch management. As any patching administrator has seen before, there are times when installing Windows updates on a computer and then rebooting the computer seems to only lead to more updates becoming available for installation. The annoying thing is that in these cases you are not able to simply install *all* available updates with just a single reboot. Instead what happens is you install available updates and reboot, but then new updates become available only *after* the previous installation and reboot has completed. There may even be rare cases where three complete cycles must be completed to get every applicable update applied.

If you are performing Windows updates through a manual process where you log on to each computer and initiate the download/installation/reboot process, you can imagine how unwieldy it becomes when you have numerous computers to manage and when those computers each require two complete download/install/reboot cycles before all updates have been applied. BatchPatch can dramatically reduce the pain involved in this process by providing automation capability so that the administrator, with just a few clicks, can launch the update and reboot process on numerous remote computers, simultaneously, including as many lather, rinse, repeat cycles as needed.

I have discussed the BatchPatch ‘Job Queue’ in other postings before, but today I’m going to focus on the process of using the job queue to initiate multiple update and reboot cycles on multiple target computers, so that you can quite literally sit back, relax, and just watch your computers as they download, install, reboot, wait until back online, then download, install, reboot a second time.

  1. Let’s start by selecting the desired computers in the BatchPatch grid to be patched, and then select ‘Actions > Job queue > Create/modify job queue’
  2. In the ‘Job Queue’ window all we have to do is double-click items on the left side of the window to be included in our queue. A multi-cycle update/reboot process can be handled in a number of different ways, so you do not have to use the exact job queue steps that I have selected here. However, the steps that I have selected should at least give you an idea of one possible way to perform such a cycle in BatchPatch. As you can see in the screenshot below, I have created a queue with the following steps:
    Download and install updates + reboot always
    Wait 10 minutes
    Wait for host to be detected online
    Check for available updates
    Terminate queue if previous 'Check for available updates' finds 0 updates
    Download and install updates + reboot if required

    This particular queue works well because after the first update and reboot process, it waits 10 minutes to give the computer ample time to reboot, and then it uses ‘Wait for host to be detected online’ just to make sure that the next step does not begin until after the host is up. Once it’s up, the next cycle begins, but not until after we first do a check for available updates. In this way we can use ‘Terminate queue if previous ‘Check for available updates finds 0 updates.’ This is a really nice little feature because that way we don’t continue to execute processes on the target host for no reason if there are no available updates to be installed.

  3. At this point we can simply click ‘Execute now’ to execute the queue on our selected hosts. Or we could alternatively save the queue for future use by clicking the double-right-arrow ‘>>’ button. That’s really all there is to it!
Posted in Blog, General, Tutorials | Tagged , , , , | Comments closed

Windows Patch Management Made Easy

We’re biased, of course, but we really do believe that you’re not going to find a better value than BatchPatch when it comes to patch management applications for Windows. With BatchPatch you get a very streamlined application without the clunkiness that so many modern software packages deliver… you get a lot of features and functionality for Windows patch management and related systems administration… and perhaps most importantly you get it all for a very modest price.

Patch Management:

From a patch management perspective you get standard Windows Update management that makes it extremely simple and painless to rapidly apply Windows Updates to numerous remote computers with real-time monitoring and automated reboots. You also get additional functionality for deploying standalone patches, updates, and third party software installations. In addition to standard Windows Update management you also get full capabilities for offline patch management, so that you can apply security updates to computers that do not have internet access and do not have access to a WSUS. BatchPatch’s offline mode enables you to apply Windows security updates to entire networks of computers that are completely isolated or air-gapped from the rest of the world.

Systems Administration:

As a systems administration and computer management toolset you get functionality for deploying scripts, registry keys, and other files to remote computers. You can initiate reboots, shutdowns, as well as wake on LAN (WoL). You can send messages to logged-on users, you can run custom commands, and you can even grow fruits and vegetables! OK, I’m just kidding about the fruits and vegetables, but there’s still a lot of other cool stuff you can do with BatchPatch, such as check online status of target computers or inventory hardware and software components of multiple computers, for example. The list goes on.

Automation and Sequences:

Perhaps one of the coolest and most powerful aspects of BatchPatch is the automation capability. One of the under-addressed challenges that exists in virtually all modern networks concerns the management of multi-system dependencies when dealing with updates, reboots, and other maintenance procedures frequently associated with patch management. For example, if you have 10 computers that have interdependent processes such that you have to shut them down and/or start them up in a particular sequence, it can be challenging to handle such a process efficiently, especially when you have a limited time window for maintenance. Worse yet is if you have numerous groups of interdependent systems. It’s one thing to worry about reboot and shutdown sequencing for 10 interdependent systems, but what if you have 10 separate groups of interdependent systems, with each group of systems containing several or more computers? To manually manage the process of taking them offline, applying updates, and bringing them back online in a specific sequence, is not just tedious but is also very time consuming and horribly inefficient. Maintenance routines for these kinds of interdependent systems typically require entire teams of sysadmins to be on-hand. Wouldn’t it be nice if you could automate these sequences so that fewer people can accomplish more in a shorter period of time?

Download and Evaluate:

If any or all of this sounds interesting to you or helpful for your network environment, I would encourage you to try out our free evaluation software. Download it and start patching! You might be amazed at just how much time it can save you. If you have any questions, please feel free to reach out to us at any time.

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

Batch Install Windows Updates

No doubt you have arrived here because you need or want to install Windows Updates on a batch of computers, and you want to do it as quickly and painlessly as possible. You’ve come to the right place. After all, we didn’t name the software ‘BatchPatch’ for no reason!

BatchPatch enables the administrator to perform virtually any action, remotely, on numerous target computers at the same time. So if you have 100 computers that all need Windows Updates, one of the things that you can use BatchPatch for is to trigger the download and installation of those updates on all 100 computers, simultaneously. You can even include automated reboots with real-time monitoring of the process so that you can keep track of when the computers have completed the process. The entire operation can be performed with just a few clicks, and there are a lot of other things that BatchPatch can do too. For a more complete list of features, please review the home page.

Below I will outline the process so that you can see just how simple it actually is. I would encourage you to download the free evaluation version to test it for yourself in your own environment. You can download it from here. On that same page you will find all the necessary information about prerequisites and getting started with the application in your network.

  1. Start by adding all of your desired target computers to the grid. You can do this by selecing ‘File > Add hosts.’ Or if you already have your list of computers in a text file, you can just drag and drop the text file onto the grid (or use ‘File > Open’ to open the text file in the grid).

  2. Once the host names or IP addresses have been added to the grid, all actions are performed by first selecting/highlighting the desired rows. Highlight each row that contains a host that you want to be included in the particular action that you’re about to execute. In this case we are going to select all of the hosts in the grid, and then I’m going to select ‘Actions > Windows Updates > Download and install updates + reboot if required’

  3. At this point you can just sit back and watch until all computers have been updated and rebooted. You will see each row show the status of the particular host. The process will start by searching for available updates. Once the available updates have been determined, BatchPatch will instruct the target to download and then install the updates. If you need to filter which updates are included or excluded by BatchPatch, that’s very easy to do, and this link explains exactly how to do that.

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

BatchPatch Audit Logging

Yesterday we published a new build of BatchPatch that includes a new ‘Audit Logging’ feature. The purpose of this new Audit Logging feature is to help with keeping track of who has executed actions on target computers, and which actions they have executed.

To provide access to this new feature there is now a new tab under ‘Tools > Settings > Audit Logging’

To enable audit logging simply choose a directory for the log files to be stored, and choose a file name. Then click ‘Enable audit logging.’ When audit logging is enabled or disabled, ‘enabled‘ or ‘disabled‘ stamps will get written to the log file so that for the sake of compliance you can keep track of not only actions that are executed on target computers but also if a user disables audit logging.

Once enabled, the audit log will display a copy of everything that is logged to the ‘All Messages’ column in BatchPatch, along with the timestamp of execution, the current user, the target host name, and the target user. The ‘current user’ is the name of the logon account that was used to launch/run batchpatch.exe. The ‘target user’ is the user that was specified in the ‘Alternate Credentials’ column for a given row to execute remote actions on the target host. If no alternate credentials were specified for a row, then the ‘target user’ will be written as ‘Integrated Security,’ in the audit log, which means the target user impersonated the current user for that action. The screenshot below shows a sample of what the log looks like.

If you have any comments, questions, or other feedback about this feature or any other aspects of BatchPatch, please do not hesitate to reach out to us.

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

Windows Patch Automation

We regularly receive questions from IT administrators who desire to have more control over their patch management processes as well as better automation for their patching systems. One of the phrases that we have begun to hear more and more frequently is “patch fatigue” and how it’s affecting so many organizations all over the world. Not surprisingly, patch fatigue seems to be one of the elements that drives admins to find patching solutions like BatchPatch.

When it comes to patch automation, in particular, there is a kind-of critical threshold that must be carefully assessed. Some automation is a good thing, but too much automation could actually be a bad thing if it comes at the cost of control over the entire process. If you have everything setup to run automatically without the administrator even having to monitor everything, that sounds very nice! But just because you have setup everything to run automatically does not mean that forgoing monitoring of the entire process is necessarily a good idea. And in many cases I would argue that it’s a horrible idea, but this really depends on the particular environment’s needs, service level agreements, etc. When it comes to automation we have some users who are *truly* obsessed with automating everything. Sometimes they even want to automate all the way to the point that they have automated processes setup with the sole purpose of configuring their automation for other processes, like some sort of meta-automation, if you will. 🙂

However, I would argue that there is a point where too far is too far. Ideally, the administrator really should be monitoring his/her patching processes, even if the processes themselves are launched by automated tasks. If you are able to get away without real-time monitoring, that’s all well and good, and I’m happy for you that your environment allows for that level of flexibility. You may very well not even need a third-party patch management tool. People often say things like “There is no need to use third-party patch management tools when you can just use WSUS and group policy.” This is definitely true for some environments, but generally people who make these blanket statements fail to realize that this is simply not an option in many environments, especially in environments where uptime is critical or where maintenance windows are small, or where the number of systems being patched is large. And so when I see someone make a statement like this I immediately know that one of a few things is true about his/her environment. He/she is likely dealing with a more casual environment where patches can be installed in large time window, reboots can be done without concern for exactly when those reboots occur, and perhaps also the number of computers involved is not all that high. In these cases, the administrator can develop processes that rely on automation while sacrificing precision, control, and real-time monitoring, and so WSUS and group policy alone might be sufficient in these cases. But for the rest of us who need to control precisely when our machines download and install updates or precisely when our machines reboot, and we need to monitor to make sure they are back online by a certain time and that various services are up and running after the machines are online, that’s where third party patching applications like BatchPatch come in to play. And for those of us who like to automate while still maintaining a high degree of precision and control over the whole process, BatchPatch has more advanced features like the ‘Job Queue‘ and the ‘Advanced Multi-Row Queue Sequence‘ that can be used in conjunction with the ‘Task Scheduler‘ for all of your automation desires.

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

Using BatchPatch to Modify Local Group Membership on Multiple Remote Computers

Today I’m going to demonstrate how to use BatchPatch to perform a routine task that administrators have to complete periodically, which is to edit the group membership of a particular local group on multiple computers. The cool thing with BatchPatch is that you can do all of the computers in a single shot.

To perform the actual group membership change we’re going to use the ‘Net localgroup‘ command that’s built in to Windows. However, we’ll use BatchPatch to execute the required commands, which enables us to target numerous remote computers at one time. For reference we will be using some of the commands outlined here.

  1. First let’s make a quick configuration change. Under ‘Tools > Settings Remote Execution’ let’s change the ‘Remote execution context’ to ‘Elevated token’ for ‘Remote process/command (logged output).’ The default configuration is set to use SYSTEM, which works best for most situations, but there are some situations that could require a different execution context, and this is one of those times. If you try to execute a ‘Net localgroup’ command under the SYSTEM context, it may work or you may get an error, depending on the account that is being used and the target system configuration. However, using ‘Elevated token’ should work for all scenarios (unless, of course, the account you are using simply does not have the necessary permissions needed to change the group membership on the target computer).
  2. net localgroup GroupName displays a list of users or global groups in a local group, so let’s start by listing out the users/groups contained in our local administrators group on the target computers. To do that I clicked on ‘Actions > Execute remote process/command > Create/modify remote command 3 (logged output)’. In the remote process window I typed ‘net localgroup administrators’ and then clicked ‘Execute’ so that the command would run on the highlighted computers in the grid.

  3. If we want to remove ‘johndoe’ from the administrators group, we can run ‘net localgroup administrators johndoe /delete’

  4. Similarly, if we want to add an account or global group to the local group, we do it with ‘net localgroup administrators johndoe /add’

  5. That’s all there is to it. If you want to execute this on many computers, simultaneously, all you have to do is highlight the desired rows in your BatchPatch grid before clicking the ‘Execute’ button!
Posted in Blog, General, Tutorials | Tagged , , | Comments closed