Forum Replies Created
-
Posts
-
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.
Currently, with a standard scroll wheel mouse you can use the mouse scroll wheel to do a horizontal scroll in the grid by holding down CTRL and then using the standard scroll wheel. Holding down CTRL changes the scroll from vertical to horizontal.
As for your hardware horizontal scroll wheel tilt not working… we will look into fixing this for the next version. Thanks for pointing it out.
Our recommended GPO settings for NO WSUS are here:
recommended-group-policy-settings-for-batchpatch-standalone-usage-with-no-wsus
Configure Automatic Updates should be set to either 2 or 3, depending on your preference.
The other settings are all up to you to decide which are best for your particular needs. We generally do not enable any of the other settings that you have mentioned, but whether or not you choose to enable other policies is of course up to you and your requirements and/or preferences.
The main thing that you seem to be asking about is the Windows Update UI in the OS. Unfortunately usoclient startscan is not supported by Microsoft to guarantee any particular operation, and it does not work consistently/reliably to refresh the UI. From what we have observed, the GPO status does not really matter. usoclient startscan will sometimes perform the refresh but other times will not, regardless of the GPO setting. I think in your case what you observed was that with certain GPO settings the UI is more regularly updated by the OS because those GPO settings were triggering the OS built-in Automatic Updates client to be more active, but of course you also experienced the downside of allowing Automatic Updates to be active, and your machines got updated and rebooted without you initiating it. Unfortunately at this time Microsoft has not provided a way to update the UI reliably/consistently when it’s not up to date, and we do not have another workaround right now. That said, realistically you just need to train your administrators to know that they cannot rely on the status of the OS Windows Update UI when using a third-party update tool like BatchPatch. BatchPatch will still always report the correct status.
I would note that you might be able to use usoclient.exe startinteractivescan to immediately refresh the UI, but the problem with this command is it will also trigger the download and install of any/all updates that are still available (any updates that have not yet actually been downloaded or installed), which is not what you want.
I don’t actually understand what you are describing. Your posting is a bit unclear, so I can’t offer advice for how to resolve your issue unless you can more clearly explain what’s going on, being as specific and detailed as possible about exactly what you are executing and what’s occurring. Or contact us directly to work with us via email and trade screenshots etc to help illustrate.
That said, I can answer your last question, which is that in BatchPatch if you use $computer inside a command, BatchPatch will replace it at the time of execution with the actual host name from that row that performs the execution.
Excellent. I’m glad you got it working. Thanks for the update.
Please see this link. Read carefully through it and check each of the things that it mentions to see if one of those is causing your issue: batchpatch-windows-update-error-1601
If Windows Firewall is truly disabled, the issue could be another firewall (whether that be software or hardware/network). “The RPC server is unavailable” means that the BP computer is not receiving a response from the target computer. Firewalls are the common reason why this occurs, but it could possibly be anti-virus or similar HIPS or other security software, as these software suites sometimes do some degree of firewalling too. Also consider if any network or other hardware firewall could be the culprit.
Considering that you are able to use “Opt-in” successfully but NOT a Windows Update action, this indicates that the blocking is specific to WMI queries. That is, the “Opt-in” action copies a script to the target computer and then uses PsExec to execute it. It does not use WMI at all. However, the Windows Update actions use some WMI queries too, and the WMI query is what’s getting blocked/dropped. WMI queries use dynamic ports, by default, and so it does sometimes happen where the firewall is just not configured properly to allow/enable WMI queries to work. A little bit more on that here: batchpatch-ports
FYI in case there was any confusion I just want to note that a “local command” in BatchPatch will execute on the BatchPatch computer. A “remote command” in BatchPatch will execute on the target computer.
Use $computer as the parameter in the command. When BatchPatch sees $computer in the command, it will replace it with the computer name from the Host column when it executes the command.
A couple of examples of this are shown in the following tutorials:
advanced-script-integration-with-batchpatch
incorporating-custom-scripts-in-batchpatch-get-local-administrators-group-membership
I don’t know enough about your particular setup or AAD to be absolutely 100% certain of what I’m about to say, but I’m pretty confident that you should be able to use BatchPatch as-is with the setup that you described.
In a standard on-premises AD domain, the primary way that BP users authenticate is by logging on to the BatchPatch computer with an account that is a member of the local administrators group on the target computers (or a member of a security group where the security group is a member of the local administrators group on the target computers). This way when the administrator launches BatchPatch, it runs with the permissions that it needs to be able to perform its tasks on target computers without having to manually specify any credentials in the software itself (because the software is already running in the context of the user that has been granted the required permissions on the target computers by having been put into the local administrators group on the target computers). Or if they don’t log on to the BatchPatch computer with the permissioned account, they might log on to the computer with a different account but then use “run-as” to launch BatchPatch in the context of the permissioned account.
I think with an AAD setup you’ll do the exact same thing. You’ll put the AAD account in the local administrators group of all target computers (or you’ll put the AAD account into a security group where the security group has been added to the local administrators group of all target computers). Then you’ll log on to the BatchPatch computer as that AAD account and then launch BatchPatch (or you’ll log on to the BatchPatch computer with a different account but then launch BatchPatch using “run-as” so that it runs in the context of the AAD account that has been granted local administrator permissions on the target computers).
The log info that you included in your posting does not show the entire picture, as the log details are spread across multiple columns. If you’d like help sorting through this, please contact us directly for further assistance. We’ll ask you to send us an HTML grid export so that we can review everything instead of just the tidbits that you’re pasting.
This tutorial demonstrates how you can use BatchPatch to execute a script to modify local group membership on multiple computers:
Using BatchPatch to Modify Local Group Membership on Multiple Remote Computers
You can also use the same concept that is described in the tutorial above to create a local user account first. In the tutorial above we use the following command to add an account to the local administrators group:
net localgroup Administrators USERNAME /addBut you can use this command to first create a local account:
net user USERNAME PASSWORD /addHow are you populating your cache folder in the first place?
Are you using online cached mode or offline cached mode?
Are you using “Download offline updates repository” to populate your cache?
Or are you just executing “Download and install updates” on target computers, and then the BatchPatch computer has access to the internet to download the updates to the cache?
Which scenario at this link describes the method/approach that you are using?
cached-mode-and-offline-updates=============
Since you have already resolved the issue by placing the files into the cache, I’m not sure that there is any value to removing them. It sounds like we might be trying to solve a problem that doesn’t exist. If your goal is to see why they weren’t downloaded in the first place, then start by going through my questions above. At the moment I don’t know enough about what you’re doing to really comment much, as there are multiple ways you could be using BatchPatch, and multiple ways for the cache to get populated etc. I’m not sure the exact method/operation that you’re using. If BatchPatch couldn’t download a file from Microsoft but then you downloaded it yourself, it sounds like the problem is solved.
This ‘Remote Agent Log’ detail that you pasted doesn’t show the download attempt because in ‘cached mode’ the download details appear in the ‘Local Agent Log’ not the ‘Remote Agent Log’ column. If you execute a new “download updates” operation, you’ll be able to see the download attempts and any failure messages. This log that you have here is showing the caching operation failing because the file didn’t exist in the cache. It’s not showing the actual download operation.