Forum Replies Created
-
Posts
-
To be clear, are you saying that you have password-encrypted grids or are they key-encrypted? And all of a sudden one of them cannot be decrypted but the others still can be decrypted even though they are all encrypted with the same password/key? What is the *exact* message that appears in BatchPatch when you try to load the grid file?
Things to consider:
1. Key-based encryption relies on the Windows user logon account that launched the batchpatch.exe. If the password to the user account was forcibly reset (forcible reset includes any method that is *not* CTRL-ALT-DELETE, such as resetting in Active Directory directly or resetting in compmgmt.msc), the encryption keys will be reset, and grids encrypted prior to the forced password reset will no longer be able to be decrypted.
2. Password-based encryption requires the correct password to be input in order for the grid to be decrypted.
If a key-based encrypted grid fails to decrypt, it could mean the following:
A. The grid was loaded into BatchPatch but under a different user account from where it was previously saved/encrypted.
B. The password of the user account that launched BatchPatch had been forcibly reset (as described above).
C. The .bps grid file on disk was modified (such as with a text editor or script etc) such that BatchPatch cannot successfully decrypt it anymore.
D. The .bps grid file on disk became corrupted for some reason (we have not ever had a report of this occurring, so it’s unlikely though technically possible).
If you aren’t able to determine what happened and aren’t able to get things resolved, I’d want to see a screenshot of the header of the file in a text editor, but please contact us directly at BatchPatch contact to share that with us. If the file has been modified or corrupted, there is nothing that we can do. If the user account password was been forcibly reset but you didn’t make a backup of the keys prior to that, there is nothing that we can do. If we can examine the file header, we might be able to determine if the file is corrupted or at least which encryption mode that was used, which might help you retrace your steps to determine exactly what occurred.
Hello – There is not currently a way to direct the output to the ‘Description’ column. We will consider your requests for a future version. The problem with us adding ‘Get info > Find description from AD’ is that it won’t work for most users since the Active Directory powershell module needs to be installed on the computer where the command is run, and we don’t like adding functionality to the software that will not work for most users in most situations, but this is why the local and remote commands can be customized for each user’s needs. We’ll consider making it possible to direct the output to a specific column.
In the meantime one other thing to consider is that if you are adding computers manually to the grid, you can get the description from AD with your script before adding the computers to the grid. And then you can add the computers plus description to the grid using the following syntax. If you copy the below text and paste it into ‘Grid > Add hosts’, you’ll see that it populates the description value right into the description field for each computer:
computer1|||description for computer1
computer2|||description for computer2
computer3|||description for computer3If you want assistance, please contact support so that we can fully review the logs to determine what is happening.
I’m not quite sure how you are concluding that they are trying to go out to the internet, and I don’t think that’s likely to be the source of the issue here. In order to troubleshoot this, please contact support. We’ll ask to review logs etc so that we can see what’s going on.
Well… I’m not aware of any specific WMI authentication incompatibility issues for authentication between 23H2 and 24H2. However, we did see that occur some years ago with a particular version of Win 10, and it required both OSes to get upgraded to same version in order to resolve. In that case it was a bug in the OS, and Microsoft fixed it. Then we also saw something similar but not exactly the same a couple of years ago, which was a known behavior, and that’s desscribed in more detail here. I provide this for reference, not because I think it’s what’s going on in your case now:
access-is-denied-in-batchpatch-after-installing-the-june-2022-cumulative-windows-update
In your case I’d first try running BP as the actual user (right-click > run-as, or log on to the BP computer as that user), and then see if you can get it to work WITHOUT specifying alternate logon credentials (it won’t be necessary to specify alternate credentials because the app will already be running in the context of that user). If that doesn’t work, and there really isn’t any difference aside from OS version, then it seems to point to the next step maybe upgrading the BP machine to 24H2. However, realistically that shouldn’t be necessary, as I’m almost certain that we have patched from one to the other and vice versa with no issues, and we surely would have heard from other people encountering that if it were a widespread problem, so it’s pretty questionable what exactly is going on in your situation. Therefore I’d also point you to review the WMI troubleshooting links that are posted on this page:
Which Win 11 version is on the source computer?
Is the user account a local account or a domain account? I’m guessing it’s a local account, in which case the resolution is you need to create a registry value on the target computer. That’s described here:
batchpatch-authentication-in-domain-and-workgroup-non-domain-environments
Alternatively, if you use a domain account you do not need the registry value but will need to ensure that the account credentials are correct.
It’s a bug in the most recent version. Sorry about that. We’re aware of it and planning to publish a fix soon. You’re correct about the cause.
Is this happening on a single target computer or all target computers?
If it’s happening on all target computers then I think the most likely culprit would be some other application such as anti-virus or HIPS or other similar security suite is locking the file, thereby preventing Windows from removing it.
If it’s happening on a single target computer the cause could still be what I described above, especially if that computer is running different software from all of your other target computers. However, it could also be something else going on. Hard to say for sure.
You might be able to gain insight into what’s preventing the service from being removed by using Process Explorer ( https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer ) to see what might be locking the service executable.
A workaround that you could use is in BatchPatch ‘Tools > Settings Remote Execution.’ There’s a setting to “Append random string to remote service name” which would cause each action to create the remote service with a different name, which should effectively stop this error from occurring. However, it won’t stop the issue with the service not being able to be removed, so you’ll end up with potentially numerous undeleted services on the target computer(s) that presumably then will not be completely removed until after reboot.
Can you please describe the exact steps to produce this result? What action are you executing? Please be as specific and detailed as possible.
When you said that restarting resolves it, are you restarting the target computer or the BatchPatch computer?
The more details you can provide, the more likely I’ll be able to assist.
Try logging on to the BatchPatch computer as that user, and then launch BatchPatch and see if integrated security works that way. If it DOES work, then log-off and back on with the user that you were previously logged-on with. Then go back to what you tried before and use “run-as” to launch BatchPatch as the permissioned user. Does integrated security work now?
Is the account that you’re using to run BP a domain account or a local account? If it’s a local account, there’s a registry value that needs to be added on the target computer. Please read through this page carefully.
BatchPatch Authentication in Domain and Workgroup (non-domain) Environments
Windows system error code 6 is:
ERROR_INVALID_HANDLE 6 (0x6) The handle is invalidI’m not sure that we’ve seen this particular error before, but in general when there are very unusual errors like this, it typically means that psexec is failing to function properly. The most common cause of psexec failing to function properly like this is due to an anti-virus client or HIPS or other similar security software suite that terminates the process or severs the network connection abruptly before everything completes.
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