Forum Replies Created
-
Posts
-
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
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.
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.
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.
Thanks for your detailed explanation. This helped us finally identify and fix the bug. It will be published in the next release.
You’re welcome. Glad to hear it!
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_UrlERROR_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
“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.
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 )
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.
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-hresult-2147024894-could-not-find-file
Let me know how it goes.
-Doug
Which version of BP is this? Version is printed in ‘Help > About’
If it’s crashing, there should be a crash report. Normally this would appear right at the time of crash on screen, but if not, please check the Windows application log (in eventvwr). Then share the details here.
Indeed it sounds like an issue with Windows, confirmed by the fact that you experience it with manual Windows Update directly on the machine even when not using BP. When you say that it hangs indefinitely, my first question is how long have you actually waited? We have not ever seen nor heard of Windows (or BP) not *eventually* completing. If I were in your shoes I would let it sit for up to ~48 hours before deciding that it’s not going to proceed any further. Back in the Windows 7/2008 days there were some situations where Windows could take that long to complete. While the particular issue that occurred back on those systems is not something that we have ever seen occur on more modern versions of Windows, I would still use that timeline of up to ~48 hours as a guideline for how long I’d wait in your current predicament before feeling confident that it truly will hang indefinitely. I would also check to make sure that disk space on the system isn’t low. And one other thing that I’d be curious about is approximately how old is the hardware where this is occurring, and is the CPU pegged at or near 100% during execution?
Which report is correct?
Both reports are correct. “Correct” in this case simply means that BatchPatch reported the actual results of the queries that it made to the corresponding databases on the target computer(s). Both history report options are provided in BatchPatch because Windows doesn’t store all update history in a singular location. Our goal is to give you the tools to see as much as possible, so we include both report options. We cannot make any assurances or guarantees about what will be contained inside of each report, as these databases are maintained by the OS, not by BatchPatch. BatchPatch merely queries the databases and reports the results. The behavior that we have observed in Windows is that after a new feature update has been installed, the history gets reset. If the Windows Update Agent history database lists a particular update as having been installed at some point in the past, then you can be confident that the Windows Update Agent did, in fact, install that particular update on the datetime that it logged the installation. However, it’s also possible that someone uninstalled the update at some later time or that a feature update installation or other cumulative update installation effectively reset the components in such a way that you don’t find other evidence of the particular .NET update currently being installed, most likely because the update was baked into a feature update or cumulative update that was subsequently installed, so it can no longer be differentiated as a singular/standalone update, or perhaps because .NET was removed altogether.
What is the command/query that each of these reports use to create these reports?
I can’t provide a singular command that you can use outside of BatchPatch because the queries in BatchPatch aren’t run as single commands like that, but if you want to learn to write your own script that queries Win32_QuickFixEngineering or the Windows Update Agent history, you can find plenty of examples in Google search results.
Hello – Please contact us directly for assistance with this.
You can’t query for a specific update that is not being offered to the machine. The filter works by enabling you to filter which available updates are shown. However, if an update is not available to the computer in the first place, you can’t use the filter to make it become available. The cumulative update each month replaces all previous cumulative updates. Windows will not ever offer a cumulative update from a previous month once the new month’s cumulative update has been published. This has nothing to do with BatchPatch. It’s part of how Windows functions nowadays. If you want to install a specific cumulative update that was released in a previous month, then you need to download the update directly from the Microsoft Update Catalog. You can then use the BatchPatch ‘Deploy’ functionality to deploy it to your systems.
Excellent. I’m glad that worked. Thanks for confirming.
Also see here for a second option: batchpatch-stuck-attempting-to-initiate-windows-update
Try again. Just go run the PsExec.exe manually one time. Make sure that there is only a single prompt appearing. Then uncheck the box and click ‘Run’. After that it will stop prompting UNLESS you have other dialogs that were still pending, and if any of those dialogs is accepted without removing the checkmark.
Or just run a single row inside of BP so that it prompts just one time. And then uncheck the box.
PsExec ‘Open File – Security Warning’
*Always ask before opening this fileTo resolve this issue, uncheck the box that says “Always ask before opening this file”. This is a Windows security prompt because the PsExec.exe file was downloaded from the internet. After you uncheck the box, it will stop prompting.
You can either post it to an image hosting site and link it here or you can contact us directly.
Can you show us a screenshot of the warning that you’re seeing? I’m certain that it can be disabled, but I’d need to see it first because at the moment I don’t know what you might be seeing, as this is not something that we see or that others are currently seeing/reporting.
If the BatchPatch scan completes then there *must* be a log of it on the target computer. Maybe you changed the default location. In BatchPatch check under ‘Tools > Settings > Remote Execution > Remote working directory’. This is the location on each target computer where the BatchPatch.log is stored. You need to review that log because it will show everything that BatchPatch did with searching/downloading/installing Windows Updates. You’ll be able to see there if BatchPatch failed to install an update or if BatchPatch skipped installation of an update because of a filter that you have applied.
You can also retrieve a different Windows Update history log in BatchPatch under ‘Actions > Windows Updates > Generate consolidated report of update history’. There are two different queries that should both be reviewed because they produce different results because these are being pulled from Windows, and Windows puts them in two different locations. However, it’s still important to review the BatchPatch.log as as noted above because that will contain the exact detail of what BatchPatch did.
Note, when you check on the server if the Windows Update control panel shows updates available, it will often show a cached query result. So if you install updates in BatchPatch and then check the server Windows Update control panel, the panel might still show that the update has not been installed simply because it didn’t refresh its scan results. SO then if you opt to install the updates there, it looks like it’s installing them even though they have already been installed.
If you continue to have questions or confusion I would suggest you open a support ticket so that we can more easily review log files etc rather than trying to post them to this forum.
I’m confused by what you’re describing. In your first posting you said that performing BP check for updates in offline mode returns no updates available and does *not* detect KB5032196 or KB5032197. Now in your most recent posting you’re saying that BP check for updates *does* detect KB5032196 or KB5032197, but when attempting to download/install BP says no applicable updates. Then you separately referenced KB031990, but when I try to find KB031990, I see that it’s not a valid KB ID. With all that said, I’m really confused about what you’re talking about, and I don’t know how to respond. Posting two seems to directly contradict what you said in posting one. And then you mentioned a KB that doesn’t exist, so it just doesn’t make much sense. If you continue to have problems or questions, please try to state everything again from scratch very carefully. And please be very specific and detailed about exactly which actions you are trying, which modes you are trying them in, and the exact text that BatchPatch is returning.
A couple of additional points to consider:
If the BP check for updates finds updates available but those updates are not downloaded/installed by BP when BP performs download/install, you can see the reason why they are skipped in the ‘Remote Agent Log’ column at the end of the action (or in the BatchPatch.log file on the target computer in the remote working directory (default is C:\Program Files\BatchPatch\BatchPatch.log)). It will say in that log exactly why an update was skipped. Generally, the only reason why the check for updates would find updates but then they wouldn’t be downloaded/installed during download/installation is because your filters are set to skip them.
Offline mode utilizes the WsusScn2.cab file that Microsoft releases each month in order to scan computers and report which updates are available. The offline mode scan file (WsusScn2.cab) will not produce identical scan results compared to what is offered via the standard Windows Update channel. For whatever reason this month Microsoft has not included some updates in the WsusScn2.cab file. It’s unclear if they will release an update to the WsusScn2.cab file this month (seems unlikely) or if they will just wait for next month to add the updates in question.
In all cases, we recommend that you only use offline mode in cases where computers actually do not have access to the internet or a WSUS.
As for the particular updates that you mentioned, to get them installed asap you can download them manually directly from the Microsoft catalog, and then you can deploy them to offline computers with the BatchPatch ‘Deploy’ action.
You should generally only need the 32-bit version of PsExec. However, as for your error it sounds like you have some corruption in the operating system. If you have missing or unregistered DLLs, that’s not usually a great sign, as it indicates that your OS is not in the state that it should be. Depending on the situation, I would suggest running BP from a computer that is known to not have any OS issues. If you can start with a fresh build, that would be better than trying to fix your existing build. However, if you want to start by fixing the existing build, then you could start with the system file checker SFC.exe or maybe do an OS repair procedure with the OS installation media.
We offer support only in English. For licensing issues, please reach out to us directly at BatchPatch Contact Form
There are a few things to consider…
If you reboot a target computer, BatchPatch will automatically start pinging it at the beginning of the reboot. And then BatchPatch will automatically stop pinging it when it comes back online, if there were X number of ping timeouts before it came back online, where X is defined under ‘Tools > Settings > Ping Status Alerts > Hosts are considered offline after X ping timeouts.’ The default value is 3, and it’s what should be used for most situation. However, in some cases if you are rebooting a virtual machine, the machine can reboot SO quickly that it’s back online before there were ever 3 timeouts. You can change this value to 2, if you want, and that might take care of it. But you don’t want it to be too low because then anytime there are two ping failures in a row, if a third ping is successful, BP will stop pinging the target. So generally we recommend leaving it at 3, but for VM environments 2 might be a better option.
If you manually started pinging the machine or you used “Start pinging” from within your job queue, then you might need to manually stop pinging the machine yourself. But even if you didn’t manually start the ping you can still always add “Stop pinging” to the end of your job queue, if desired.
Yeah that makes more sense 🙂