Forum Replies Created
-
Posts
-
Either use online mode (non-cached) to perform the installation instead of using offline mode, or alternatively you can deploy the .MSU file for the update directly by first obtaining the .MSU file from the Microsoft Catalog, and then deploying using the ‘Deploy’ feature in BatchPatch.
Remotely Install Multiple .MSU Files (or .MSI and .MSP files) to Numerous Computers
BatchPatch executes the command via PsExec. If you are using PsExec v2.1 or newer, network communication is encrypted. However, there are some things to still note:
1. On a modern LAN, even unencrypted traffic is NOT seen by everyone. Traffic in a switched LAN is sent only to the particular port on the switch where the destination computer is plugged in. Unless an attacker has direct access to the switch, the traffic can generally only be seen by the source and destination switch ports.
2. If you are logging command line activity of your computers (this is somewhat common at large enterprises), any commands that are sent to the command line (including the net user USERNAME PASSWORD /add command) would therefore be logged, including your command to set the password.
3. It’s always best to verify any concerns with your own eyes. You can review network traffic on the source and target computers by using an application like Wireshark to capture the traffic and then look at it.
RPC server is unavailable means that the BatchPatch computer is not getting any response from the target computer. We have only ever seen this be caused by the computer being offline (or the RPC service being stopped), a network issue preventing communication, a firewall, or some type of anti-virus or similar security software that is blocking/dropping communications, which effectively speaking would be considered a firewall even if it’s not being billed as such.
FYI a WMI failure/error or an Access Denied issue would have different error text, so we can rule those out as the cause of the error that you are seeing. The reasons mentioned above are really the only reasons we have ever seen for RPC server is unavailable.
You mentioned that the issue isn’t a firewall, but firewall is by far the most common reason for this error to occur, so I will still be focusing on that as the probable cause. It doesn’t JUST include the Windows firewall. It can include any type of software or hardware firewall or network device in between the machines. In this case I’m not sure if your setup included moving the BatchPatch machine as well as the target machines into AWS. Regardless, I would suggest you look at the AWS built-in firewall/network rules too.
Additionally, review the notes on this page about DCE/RPC
Also review this page and consider enable Windows firewall logging temporarily to see if there is anything visible in the logs that helps you troubleshoot further.
Well let’s start with the actual error message that you receive. The exact/specific error message itself is important to diagnose the cause of the problem. Start here:
For anyone else who comes across this thread, it turned out he was running the batchpatch.exe from a network location. Resolution was to move batchpatch.exe to the local computer.
I sent you an email to you to see if we can work on this directly so that I can see screenshots and more details.
When you say “remote domain” what exactly do you mean? If it’s working for a local domain but not a remote domain, there is your problem. Presumably there is some type of communication that is not permitted to the remote domain from your local domain. I would suggest very carefully going through the troubleshooting guide, step by step, until you find where exactly the issue is.
-214702488 is not an ambiguous error. It means that the system ran out of memory. The offline scan process requires a significant amount of free memory, so you would need to increase it if you want it to complete. We have not ever observed this error appearing when the issue was not tied to running out of memory.
-2146959355 is a general failure to load COM on the target machine:
0x80080005 -2146959355 CO_E_Server_Exec_FailureWe have never seen this particular HRESULT value before. It’s occurring on the target computer (not on the BatchPatch computer), and it could indicate a CPU load issue or a memory issue on the target, or possibly a permissions issue. It could even be caused by an anti-virus or similar security software on the target computer. If you haven’t experienced this issue on that target computer before, try restarting it first, and then see what happens. Otherwise look at the other possible causes that I mentioned above.
Thanks for submitting. Hopefully that will help.
I should also note that on the computer where this was occurring I didn’t want to tell Defender to ignore the threat because it’s not clear to me what would happen if the real Sabsik.FL.A!ml or Wacatac.B!ml were to then subsequently get onto the computer. Instead what I did was in gpedit.msc I enabled Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Turn on removal of items from scan history folder with the value set to 0. This caused the Defender scan history to be cleared daily. After about a week, I set this policy value back to Not Configured. At that point a week later Defender was no longer detecting the file as malicious, even if scanned directly/manually, and it has not been an issue ever since on that computer.
Indeed, you’re correct that it’s a false positive. What’s really strange and annoying is that we submitted it to Microsoft, and they basically then responded by telling us that it’s not malicious, which of course we already know. We couldn’t get them to actually pay attention to or care about what we were trying to explain to them.
We’ve only had a couple of other customer reports of this false positive in addition to one occurrence on one of our own systems.
These are the two detection names that we see in Microsoft Security/Defender:
Trojan:Script/Sabsik.FL.A!ml
Trojan:Script/Wacatac.B!mlGoogle suggests that when a Defender detection’s name has a ML suffix, it’s a “machine learning” detection. I couldn’t really find much on this subject, but it’s surely the reason why we are only aware of 4 machines (3 from customers including you, plus 1 of our own machines) producing this detection. It’s not being detected by any normal Defender ruleset, which seems to be connected to why Microsoft isn’t helpful to us when we report the false positive. Crappy quality control and customer service on their part is probably also at play here.
And as you’ve seen there are also a couple of detections in VirusTotal, despite all of the other many dozens of VirusTotal engines recognizing it as clean (because it IS clean). Based on the behavior that we have seen thus far when trying to figure out what we can do about this (seems like we can’t do anything, at the moment, since it’s a Defender issue, and submitting a false positive to Microsoft has gotten us nowhere, and 99% of Defender instances don’t detect it since it’s clean), it’s very likely to be the case that if you simply grab that .zip file on a different computer, it won’t be detected. Also we generally saw that the .zip was detected even though the extracted .exe wasn’t detected on our one system that was having all the .zip detections. Then after several days it stopped detecting anything on that one machine where it was alerting for several days. It’s all very strange, frankly.
Verifying the authenticity and integrity of the signature file ensures that you got the exact file that we digitally signed, so you can trust that it’s not malicious. However, I understand that it doesn’t exactly produce a warm and cozy feeling when Defender keeps trying to quarantine it. Even here on the system that was giving us the same issues, it was unnerving. Like a weird form of digital gaslighting.
Try using the latest version of BatchPatch
-102: Failed to execute the search. HRESULT: -2147024882
translates to:
0x8007000E -2147024882 E_OUTOFMEMORY
Increase the available memory on the target computer and then re-scan. Or you might be able to get away with just rebooting the target computer and then re-scanning right after that before most available memory is consumed by other services.
batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
I would start by going to Tools > Settings > Remote Execution > Use psexec.exe custom filepath. Configure the ‘Use psexec.exe custom filepath’ setting to point to the PsExec.exe on your system.
Initially when this forum thread was started the issue only occurred on Windows 11 Enterprise. However, it’s now an issue with standard versions of Windows 11 too.
For anyone who comes across this forum thread, we’ve posted the details and workaround here: Windows 11 Monthly Cumulative Update Fails to Install in Offline Mode: Copy To Cache: Failed. HRESULT: -2145095681 or HRESULT: -2146467818
Please read through my entire response from yesterday. It contains the answers you are looking for.
When you say “some servers are not fully patching as expected” how are you making that determination? Are you sure that the servers are not patching, or is it that the Windows Update control panel on the servers is showing stale/old/inaccurate information?
If BatchPatch’s log shows that it successfully applied an update, you can be sure that it applied the update. You can use the BatchPatch history report to see exactly what BatchPatch installed (Actions > Windows updates > Generate consolidated report of update history > Windows Update Agent). You can also see the history of BatchPatch Windows Update actions on a given server in the BatchPatch.log (Actions > Windows updates > View BatchPatch.log)
This link will also provide helpful information about why you might see a discrepancy between the number of available updates being reported by BatchPatch as compared to the target computer’s Windows Update control panel. The primary reason these days for a discrepancy is because you applied the updates in BatchPatch, but the Windows Update control panel did not yet refresh/update to match the current state.
BatchPatch and the Windows Update Control Panel Report a Different Number of Available Updates
This indicates that WMI is broken on those computers. You probably need to repair WMI or repair the OS on those machines to fix it. Some help is provided here: https://techcommunity.microsoft.com/blog/askperf/wmi-missing-or-failing-wmi-providers-or-invalid-wmi-class/375485
I’d suggest Google search for ‘repair WMI’ and ‘rebuild WMI’ for other options. Or do an OS repair/reinstall.
Yes, this will be fixed in the next build. Thanks.
The current version released earlier this week now has functionality for this scenario under Tools > Settings > Remote execution > Use alternate share path. Make sure to read the ? help text next to the item to learn how to properly use the setting.
First review the BatchPatch.log (the current run is printed in the Remote Agent Log column) for the host that is reporting no applicable updates in the filtered collection. You can view this under Actions > Windows updates > View BatchPatch.log
In the BatchPatch.log you’ll see the reason why an update was filtered out. In between the following two sections of log each update that is filtered out will be printed with a reason such Reason:UpdateClassificationFiltering or similar.
::Begin filtering collection
::End filtering collection=============================
Update classification filters are configured globally under Tools > Settings > Windows Update
Update date filtering is configured globally under Tools > Settings > Windows Update
Individual update filtering is configured per-row under Actions > Windows updates > Filter… and are stored in the column Download/Install Filter
1: Determining if software is installed can be done in a few different ways. Sometimes the easiest/simplest method for determining if an application is installed is to just look for the presence of a file or registry value. For example, if you have Chrome installed at C:\Program Files\Google\Chrome, then you can use BatchPatch to check for the existence of C:\Program Files\Google\Chrome\Application\chrome.exe
In BatchPatch go to Actions > Get info > Check if file exists
2: We have a tutorial for how to update Chrome posted here: Using BatchPatch to Update Google Chrome on Remote Computers
Contact support directly: BatchPatch contact
Help > Check for updates > View change log
This won’t work, unfortunately. We’ll consider providing a solution for this in a future version, but in the current version it would need to be an actual drive letter that’s shared with the $ notation. e.g. C: shared as \\targetComputer\C$ or D: shared as \\targetComputer\D$ etc. A different share, such as C:\SomeSharedFolder, shared as ‘\\targetComputer\SomeSharedFolder’ or ‘\\targetComputer\SomeSharedFolder$’ will not work.
You can control this under ‘Tools > Settings > Grid Preferences > Display and sizing properties for windows and columns’. However, my recommendation to you is to actually leave the default settings as-is, as this is how the app is intended to be used.
The ‘freeze’ option keeps a column in view when scrolling, like ‘freeze panes’ does in Excel. It has nothing to do with the column sizes.
The most recent version of BatchPatch is able to patch Windows 11 in offline mode without issues. We have not ever encountered the particular HRESULT value that you’re seeing (-2146467818), and I’m not quite sure what that HRESULT value means. That said, typically when there is an issue with CopyToCache it’s caused by not all of the required files being available in the cache. The offline mode procedure requires that you scan for updates on the target offline computer with Actions > Windows updates > Retrieve consolidated URL list of available updates. Then save that list and move it to a BatchPatch instance that has internet access. Use BatchPatch to download the 16 files that appear in that URL list. Then transfer those 16 files to the offline network in the BatchPatch cache folder, and then use Actions > Download and install updates
It seems to me like you probably did not follow the above process in one way or another. It seems like maybe your cache file was not populated with all of the correct/needed files for the operation to complete. I can’t say for sure.
You said that you manually installed two .MSU files. That’s fine. However, for reasons that are not clear to me, it does not look like you installed the November 2024 cumulative update even though you installed the two files that Microsoft had posted on the catalog for that KB number. My guess is that this might be part of an issue that Microsoft apparently had in November where they cataloged the updates incorrectly. I thought it had been all resolved, but maybe there is still something lingering that it’s incorrect on their end. I’m not sure.
It looks like the .MSU you installed is the SSU (servicing stack update), which is why BatchPatch is still telling you that the cumulative update is not installed. I would suggest you go back and follow the tutorial for scenario 4 at this link to get the remaining update installed: https://batchpatch.com/cached-mode-and-offline-updates
Alternatively, maybe try installing this update directly from the Microsoft Catalog: 2024-11 Cumulative Update for Windows 11 Version 24H2 for x64-based Systems (KB5046740)
Hello – When running BP as a service, the service auto-saves the grids regularly. However, when you are not running BP as a service there is not currently an auto-save option like that. However, in the Job Queue special items there is a Special action “Save current-grid HTML export” as well as “Save all-grids HTML export.” This option will save an HTML export of the grid to the filepath location specified under Tools > Settings > General > Grid export dir for job queue and scheduler. This option does not save the actual grid to a .bps file, but it saves a copy of the grid in HTML format, so it should still be helpful. We will consider a normal save grid/bps option in a future version. Thanks.
That’s correct. You either need to use the Oct 2024 WsusScn2.cab file or you can manually download the desired update directly from the Microsoft Catalog as a .MSU file, and then use the Deploy feature in BatchPatch to push it to your target computers.