[doug]

When you perform a Windows Update action, the row in the grid will have ‘All Messages’ column, ‘Remote Agent Log’ column, ‘Local Agent Log’ column, which together can be used to see what occurred during an offline update action for a given row. You can/shold always reviews those columns after an action, if you believe something didn’t go as expected, since they will show what occurred. The contents of just the ‘Remote Agent Log’ column are also saved to the remote working directory of the target computer (default is C:\Program Files\BatchPatch\BatchPatch.log). The ‘Local Agent Log’ column is not saved outside of the BatchPatch grid.

[doug]

The log columns will show exactly what occurred and if a download was skipped or failed etc. If you need help reviewing logs, feel free to contact us.

[doug]

I suspect that if you try to log on directly to the target computer as the account that you’re using that creating this permission issue, you’ll likely see that same message at logon. As mentioned, this isn’t a BatchPatch issue per se. It’s a Windows permissions issue, so it will need to be troubleshot from that standpoint, not from anything that’s specific to BatchPatch. But ok just keep us posted here. Thanks.

[doug]

Sorry to hear that you’re having issues. It’s tough for me to say what exactly might be causing the issue. It pretty much has to be a permissions issue of some kind, but it’s weird that upgrading to Win 11 would cause it. My best guess about why the upgrade triggered the problem is because of your Group Policy settings. I’m guessing that you have different policies applied to Win 11 (or not applied), and so after the upgrade the differing policies ended up producing this unexpected result. I would suggest Googling this Windows error:

Logon failure: the user has not been granted the requested logon type at this computer

You’ll see lots of results with various potential causes and resolutions. I’d start working through those one by one to isolate what exactly is happening in your environment since the issue isn’t exactly a BatchPatch issue per se but rather is something to do with your permissions in Windows. It would be great if you could report back here when you isolate the exact cause.

[doug]

There is no such mode. However, rather than adding allowances in the firewalls on target machines to the public, instead I would recommend that you expose the required services only to the BatchPatch computer on your LAN. This is explained here:

This is the general firewall config required for BatchPatch:
using-batchpatch-with-windows-firewall

This is how to configure the Windows Firewall to expose services to only a specific IP address (this specific IP should be the LAN IP of the BatchPatch computer):
modifying-the-scope-of-windows-firewall-rules-to-allow-connections-only-from-selected-ip-addresses

[doug]

When offline mode is enabled, the BP computer will attempt to perform the download itself. If it has access to the internet, it will download the updates to its local cache and then push them to the targets for installation. The targets will not make connections to Windows Update or Microsoft Update as part of this process.

You can read more about how offline mode operates at this link: https://batchpatch.com/cached-mode-and-offline-updates

[doug]

Your posting was sitting in the spam bin, so I didn’t see this until now. Sorry for the delay. Generally the reason that this happens is due to the OS being out of support with Microsoft. I’m guessing the OS version that your targets are using is no longer supported. Time to upgrade them.

Another thing to consider that we have seen occasionally is where you need to apply the latest servicing stack update. There were some older versions of Win 10 where we saw Microsoft got things out of order somehow where a machine would not be able to use Windows Update to find any available updates until after manually applying the latest service stack update (SSU update). It seems like in these cases they got into a situation where Windows Update couldn’t be used without the latest SSU, but the latest SSU could therefore also not be obtained through Windows Update. So it required a manual intervention to install the latest SSU.

One thing you can try that might work is to try an offline scan in BatchPatch instead of online. To do that, enable offline mode under ‘Tools > Settings’ and then try. This might get you onto a SSU that is late enough to resolve the issue.

Another thing that you can do is manually download the desired monthly cumulative update and/or latest SSU directly from the Microsoft Update Catalog. Then use the ‘Deploy’ feature in BatchPatch to deploy it to your target computers all at once with just a few clicks.

[doug]

Under ‘Tools > Settings > Grid Preferences’ look at the “Hosts are considered offline after X ping timeouts.” The default value is 3. However, if you’re having a problem where your VMs are rebooting within just several seconds (the timespan of 3 ping timeouts), then try changing it to 2. That will usually resolve it. I don’t recommend changing it to 1 because if any machine has just a single ping timeout then BP will think that machine went offline, so you’ll get consistent false alerts if the value is set to 1. However, 2 is usually a good middle ground option that should work well in most situations.

==========================

The other option is don’t even use ‘Wait for host to go offline and come back online’. Instead do something like this:

-Step where reboot occurs
-Wait 10 minutes
-Wait for host to be detected online

This will generally give you a good middle ground option. In many situations a 5 min wait will work fine instead of 10, but 10 minutes should ensure that you don’t run into any issues where a machine is taking a very long time to complete the initial shutdown sequence. If you set the wait time too low, then BP will get to ‘Wait for host to be detected online’ and will find that the machine is online but not because it rebooted already but rather because it hadn’t yet actually shutdown and was still online and working to complete the initial shutdown sequence.

[doug]

In order to evaluate your queue and provide guidance/assistance, I would need to see a copy of the exact/actual queue that you setup.

The conditional operations in the job queue for ‘If this step is executed between DayOfWeekBEGIN and DayOfWeekEND’ require that job queue step to be executed inside of that time/day window in order for anything to occur. Typically these special queue items would be used inside of a loop in your job queue so that each time the job queue loops/runs, it tests to see if that step is running between DayOfWeekBEGIN and DayOfWeekEND, and then it can act accordingly.

For what you’re describing you should probably just use the task scheduler to schedule your desired job to run at your desired time.

[doug]

Windows uses the following locations to determine which apps are started automatically on a given computer:

Folders:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Registry:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

BatchPatch does not contain functionality for directly manipulating these folders and registry values, but you could optionally write a custom script to do that, which you could then deploy to each target computer by using the ‘deploy’ feature in BatchPatch.

[doug]

You have two options:

1. Switch the update classification to ‘Include “Upgrades”‘, then perform the desired upgrades, then switch it back after completion so that when your scheduled tasks execute they’ll be using the desired/correct settings.

2. Perform the upgrade with the ‘Alternate Deployment’ method described at this link starting about halfway down the page: Remotely Deploying Windows Feature Update Version 23H2 to Numerous Computers

We’ll consider other options for a future version.

[doug]

Regarding Explorer… Yes, we are experiencing the same prompt for user credentials. This is expected behavior. We will consider a custom file explorer/browser, but to your point, there already exist custom file explorer apps on the market, and you already have such an app.

Regarding ++… As described in my previous posting, BP does *not* have an issue with + symbols. The issue that you are encountering is from the *space* character in your filepath, not from the + symbol. As mentioned in the previous posting, we will have that issue/bug fixed for the next release. However, for the time being until the next version is released, a workaround would be to install your explorer++.exe into a filepath that does not have any space characters. e.g. Instead of C:\Program Files\Explorer++\explorer++.exe, install it to something like C:\ProgramFiles\Explorer++\explorer++.exe

[doug]

First, I would note that we do not encounter the same issue here. I can log on to the computer as userA, and then I can run BatchPatch with run-as under userB logon account, and inside of BatchPatch I can call the following local command successfully without any issues to launch Explorer

explorer \\$computer\c$

For me it returns exit code 1 but still launches Explorer to the proper location. I believe the reason you cannot do this even though I can do this is likely because the user that you have running BatchPatch does not have local administrator permissions on the BatchPatch computer.

================

With regard to the ++ issue… BatchPatch does not have an issue with ++. The bug you are encountering is BP failing to parse the space properly in ‘Program Files’. Thank you for highlighting this issue. We will have it fixed in the next release.

================

For the time being until the next version of BP is released, it seems like your easiest workaround is to just launch a separate instance of BP in the correct user account to be able to launch Explorer without issues without needing to run-as a different user. Alternatively, put your Explorer++ in a location that does not contain a space in the filepath.

[doug]

In that case probably the best option for you would be to launch a second instance of BP in the other user account, which you can use for the sole purpose of launching the Explorer C$ windows.

Or another option might be to NOT run a second instance but instead just modify the command so that it launches as the correct user. Something like this:

runas /noprofile /user:mymachine\administrator explorer \\$computer\c$

or

runas /user:mymachine\administrator explorer \\$computer\c$

[doug]

Try this:

1. Go to Actions > Execute local process/command > Create/modify local commands

2. Create a new command with the following syntax:

explorer \\$computer\c$

3. Save that command. It will appear under Actions > Execute local process/command > Execute saved local commands

4. Execute the command for a row. When you execute the above command for a given row in the grid, BatchPatch will automatically substitute $computer for the actual/real computer name from the Host column.

[doug]

I’d want to view an HTML grid export (File > Export grid to HTML) in order to see what might be happening, along with a screenshot of your job queue settings. Feel free to contact support directly since we can’t look at these things on the forum here.

[doug]

You should definitely NOT use offline mode unless the machines actually do not have access to the internet or to a WSUS. If you switch to online mode, you’ll be able to get all of the available updates, but whether or not this is an identical reflection of your WSUS or not will depend on the search settings and the WSUS settings. Generally speaking, I think it will give you what you’re looking for. However, in all cases it doesn’t make a ton of sense to compare your results to your local WSUS if you’re not going to actually use the WSUS to distribute the updates.

Just FYI with regard to WSUS… 30 servers in a 3-hour window is nothing. WSUS can generally handle thousands in a much smaller window. While I don’t know the details of your WSUS setup or what type of issues you are encountering with it, what I *can* tell you is that a properly functioning WSUS server will not have any issues with 30 machines. I can also give you another tip, which is that you can have group policy handle downloading the updates to the computers from the WSUS in advance of the maintenance window so that when maintenance time comes the machines are not having to download updates from the WSUS since they will have already done that. We have some instructions on WSUS GPO setup for pre-downloading updates here: batchpatch-integration-with-wsus-and-group-policy

[doug]

–Offline mode contains only a subset of updates– primarily security updates. Microsoft controls which updates are distributed through each channel. Not every update that is available from Microsoft or through your WSUS server will appear in offline mode scans.

–If you have a local WSUS server, why would you be using offline mode? You should just use your local WSUS server, which gives you full control over which updates are presented to target computers.

–This link explains all of the possible reasons why you might not be seeing updates that you expect to see when scanning for available updates in BatchPatch:

batchpatch-and-the-windows-update-control-panel-report-a-different-number-of-available-updates

[doug]

Please review the following link for all of the possible reasons (along with resolutions) for why you might see a different number of updates available in the BatchPatch search results as compared to when looking at the Windows Update control panel directly on the target computer:

batchpatch-and-the-windows-update-control-panel-report-a-different-number-of-available-updates

[doug]

This is not a topic that I’m familiar with, but what I would suggest is figure out what the command line or script syntax is to change the ownership. I would expect that a local admin would have the permission to change the ownership, so you just need the command/script/syntax to make that change via command line instead of via regedit. Then once you have a script/command that you can run locally to make the change, you can then push that out from BP so that the change-ownership script/command runs first, and then the modify the reg value part runs second.

[doug]

Two options:

1. Direct Task Scheduler: In the Task Scheduler select the drop-town Task as Execute advanced multi-row queue sequence. The row where you set this task must be the Execution Row for the desired advanced multi-row queue sequence.

2. Via the Job Queue: Create and save a job queue that uses the special item Execute advanced multi-row sequence:X. Then create a scheduled task that launches the job queue that you created.

[doug]

1. Download and install operations always have to start with a check for available updates. This is simply how the Windows Update Agent (WUA) was designed and functions, as it always has to do a fresh evaluation of the state of the machine before it can/will proceed with download/install etc.

2. Recommended Group Policy Settings for BatchPatch Standalone Usage with No WSUS

3. Microsoft has been making changing in recent years such that the behavior of cached mode is not as consistent as it used to be, depending on which version of Windows (and which build of each version) is being targeted. With certain versions of Windows it seems that the way the Windows Update functionality is changing, you might find that certain updates won’t download/install in cached mode. That said, we generally recommend to use default online mode. Even in a case of relatively limited bandwidth, it’s usually a better option. However, you might find that cached mode works great for your needs and your computers, so of course feel free to test and proceed with whatever works best for your environment and your needs.

[doug]

Thanks for your detailed explanation. This helped us finally identify and fix the bug. It will be published in the next release.

[doug]

You’re welcome. Glad to hear it!

[doug]

Did you switch from a *VERY* old version of the app to the new/current version? Many years ago we changed how the toolstrip data is stored, so if you were using a *very* old version from many years ago, that could be the reason. Otherwise the only reason the toolstrip would change is if you’re launching BP under a new user account (because that toolstrip data is stored per-user in the user profile) or on a new computer, or if somehow the settings data became corrupted. In the *very* rare case where corruption is the cause, we have only ever seen where the toolstrip gets wiped out altogether so that it appears empty in BP. If it appeared to revert back to the default toolstrip buttons on its own, we have never heard of that or seen that occur before.

BP doesn’t provide a facility for manually exporting the toolstrip buttons, but that config is stored in a file called user.config, which is located in a subfolder of

C:\Users\USERNAME\AppData\Local\Cocobolo_Software,_LLC\BatchPatch.exe_Url

[doug]

ERROR_BROKEN_PIPE 109 (0x6D) The pipe has been ended.

This most likely means that security software on your systems is severing/terminating the connection. Although the link below references different flavors of error 1611, it’s pretty likely that the 1611:109 has the same causes as 1611:64 and 1611:2250 that are described in more detail here:

Troubleshooting Errors 1611: 64 , 1620: 64 , 1611: 2250 , 1620: 2250

[doug]

“Download offline updates repository” always downloads the entire repository. However, if you already have downloaded the repository, then during a subsequent download of the repository BP will skip any of the files it finds that already exist in the cache from being previously downloaded, so each month if you re-run “Download offline updates repository” it will only add the new updates that it finds.

Another option for minimizing the files to be downloaded is to use ‘scenario 4’ instead of ‘scenario 5’ as described at this link: BatchPatch Cached Mode And Offline Updates

‘Update Date Filtering’ works exactly as is described in the software, but it doesn’t apply to “Download offline updates repository”, as “Download offline updates repository” is not affected by filters.

‘Update Date Filtering’ instructs BatchPatch to compare the current date to the LastDeploymentChangeTime property of each update. The LastDeploymentChangeTime property is printed as a date (yyyy-MM-dd) next to each update listed in the BatchPatch.log file. You can see this easily in the ‘Remote Agent Log’ column when performing a check for available updates in BatchPatch.

When updates are obtained from ‘Windows Update’ or ‘Microsoft Update,’ the LastDeploymentChangeTime property is equivalent to the date the update was published by Microsoft. When updates are obtained from WSUS, the LastDeploymentChangeTime property is equivalent to the date the update was approved in WSUS.

If you use the ‘X days ago’ option, BatchPatch will only download/install updates that were published / approved at least X days ago. For example, if you set this value to 30, updates that were published / approved any time between today and 29 days ago will *not* be installed by BatchPatch. Only updates that were published / approved 30 or more days ago will be installed.

If you select a specific date, BatchPatch will only download/install updates that were published / approved *before* that date. For example, if you set this value to 2023-03-14, updates that were published on or after that date will *not* be installed by BatchPatch. Only updates that were published / approved on 2023-03-13 or earlier will be installed.

[doug]

I don’t know enough details about your WAN vs LAN setup to make a comment about your particular environment, but from your description everything sounds like it’s working properly and as expected. You modified your hardware firewall to get things working, which indicates that the problem has nothing to do with the server itself, and this is exactly what we would expect. If you’re saying that you’re using BP over the WAN to the DC and APP servers without encountering the same issue as with your Server 2022/Exchange 2019 machine, then it would indicate that you have previously carved out allowances in the firewall for the DC and APP machines but not for the Exchange machine.

Typically BatchPatch is used on a LAN and not over a WAN because WAN connections are typically locked down (as they often should be) to be more secure. We would not normally advise using BP over a WAN unless the WAN connection is established over a VPN. In most environments, unless the WAN connection is a site-to-site VPN, admins would typically run BP in the target LAN, and the WAN connection would only be used for establishing a remote desktop connection in order to operate the BP instance in the remote LAN. From a security perspective I can’t comment on your setup because I don’t know the details of how you have everything setup and the particular use-case for your WAN, but I mention this only to note that what you’ve described about your usage of BP across a WAN sounds unusual and potentially concerning from a security perspective. Obviously you and your team will decide what is and is not appropriate from a security perspective in your environment. I only wanted to mention it to bring it to your attention in case it wasn’t already.

WMI connections operate over dynamic, not static ports. In hardware firewalls this type of allowance is typically made as DCE/RPC rather than just allowing every port over 1024. See here for more ( https://batchpatch.com/batchpatch-ports )

[doug]

We don’t have 2022 with Exchange 2019 to be able to test this, but based on what you’ve described, I can at least note that the issue that you’re encountering is specific to remote WMI calls in BatchPatch. To be clear, ‘Get CPU info’ is a remote WMI call in BP, but ‘Get computer model’ is actually executed through PsExec without using a remote WMI call. The Windows Update actions in BatchPatch all have a remote WMI call in the beginning of them, hence why they are behaving the same as ‘Get CPU info’ in this case.

Normally “RPC server is unavailable” is caused by a firewall or other security-related software that is blocking/dropping the remote connection attempt because it means that BP isn’t even getting a response from the target computer, just like if that target computer didn’t even exist at all. You said that simply disabling the ‘Active Directory Topology’ service is enough to cause things to start working again. This is quite surprising to hear since one wouldn’t expect that the ‘Active Directory Topology’ service would be involved in behavior that is similar to a firewall. However, clearly whatever is occurring is only affecting remote WMI connections and not other remote connections (because PsExec operations are still working, for example), so perhaps it’s just some type of bug in that service. Or perhaps it’s even some type of security-hardening behavior in the service that’s there intentionally to block remote WMI connections from being made to the Exchange server.

I think if I were troubleshooting this issue, one thing I’d want to test is can WMI be used locally if not remotely. I’m not sure if this would lead to any kind of solution/resolution, but it might at least give a bit more detail about where the problem is occurring. A free utility like WMI Explorer could be used locally on the machine and remotely to see if locally works when remotely doesn’t work. (Remotely it most likely should behave the same as BP, working when BP works, and not working when BP does not work). This might simply help you gather more information about the nature of the problem in case you end up reporting a bug to Microsoft (since the bug report would be that remote WMI connections are broken by the Active Directory Topology service, not that BatchPatch is broken by the service).

I’d also want to test starting and stopping that Active Directory Topology service numerous times, with attempts to use BP each time, just to ensure that the behavior is really somehow tied to that service. Like maybe when that service is started, somehow it modifies the Windows firewall behavior on that machine? Or is there anything that might be occurring with IP addresses, network interfaces, and Exchange load balancing that somehow is causing a request to the target computer to get a response out of a different network interface instead of the same interface that received the request… but only when the service is running? Also test putting the IP address instead of the host name into the BatchPatch grid and see if that makes a difference (and if your Exchange server has more than one IP, try each IP separately from BP to see if any of them behave differently). I’d also then want to see if there is anything in the event log on the target computer that gives any more information about what’s occurring. Also enable logging on the Windows Firewall on the target computer and see if it shows anything helpful about connection attempts being dropped when the AD Topology service is running vs stopped.

[doug]

If things were working up until last week, then it seems like something in your environment has changed. It appears as though PsExec is no longer working properly. I would suggest that you start by evaluating what changes were made in your environment last week that could have impacted PsExec’s ability to work properly. You also mentioned that everything works fine after reboot for an hour but then stops working again, so this also seems to point to something in your environment. The most common reasons why PsExec fails to work is due to some type of software (like anti-virus or HIPS or other security software) preventing it from working, so that could be one possibility in your environment. However, usually those types of problems would manifest with a different error, not 1611:2. But with that said, 1611 errors can appear in a few different ways, so it’s very possible that 1611:2 in your environment has the same cause as 1611:2250 or 1611:64 in a different environment.

Please carefully read through the following links, as they contain some possible solutions/fixes for the issue you are encountering. To me it appears like PsExec is not working properly, but it’s hard to know exactly why. Note that the error 2 you are receiving might be reported a bit differently than how it is reported in the links below because those are old postings where older versions of BP reported the error a bit differently. In your case you are seeing “Error 1611: 2. Failure” which indicates that PsExec is returning exit code 2. The 1611 just indicates the location in BP where the 2 was returned.

troubleshooting-errors-1611-64-1620-64-1611-2250-1620-2250

error-2-very-often-server-2012-r2-on-domain-controllers

error-2-or-error-0

error-2-hresult-2147024894-could-not-find-file

Let me know how it goes.

-Doug

[Author]

Posts