Forum Replies Created
-
Posts
-
For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
The age of the file wouldn’t be the issue, which is why I suggested looking at the digital signature in order to confirm if the file had been corrupted since the error message that you are getting indicates that the file is corrupted (a corrupted/modified file would not contain a valid signature). If your BP computer can’t download the WsusScn2.cab file then there is either a transient issue with Microsoft’s server or there is some kind of issue with your BP computer… not sure if you have a proxy or a web filter/firewall that prevents it from getting the file. In either of those cases you can certainly put the file there yourself, and then BP will use it.
0x8007000D The data is invalid. ERROR_INVALID_DATAThis implies that there is probably an issue (presumably some type of file corruption) with the WsusScn2.cab file that ServerA is using. Either there was corruption when downloading it from Microsoft to ServerA, or the corruption is being introduced when ServerA copies it to the target computers. If you manually inspect the WsusScn2.cab file (both on ServerA as well as on a couple of targets) you can right click on the file and view ‘Properties > Digital Signatures’ as a way to verify that the file has not been corrupted/modified. If the Digital Signatures tab is present with signatures listed, then the file is good. If it is not present or if it is present but with no signatures listed, then the file is not good. If it’s not good then you can delete the WsusScn2.cab file and let BatchPatch re-download it. If it’s good on ServerA but not good on the targets, then the corruption is being introduced during the file copy from ServerA to the targets. This would be unusual, but it would imply that you have issues with your network.
Under normal circumstances when performing a deployment, the exit code is actually coming from the setup/installer application, not from psexec or BatchPatch. So if BatchPatch ‘check for available updates’ runs successfully on that same target computer where your deployment fails, then you’ll know that the issue is nothing to do with psexec but rather is due to either a problem with the deployment configuration or is the return code that the setup/installer is returning. Since you said you can successfully run the same deployment on other computers, then that would imply that there could just be an error running the setup/installer on this particular computer. In that case I would remove BatchPatch from the equation and run the setup manually on that target computer and see what it says.
The error in question is:
0x80072EE2 -2147012894 ERROR_INTERNET_TIMEOUTWe have never seen (nor would we ever expect to see) this error occur when using offline mode because when operating in offline mode, the target computer does not try to check for updates on a network/internet location. That said, I’m not quite sure what to make of it.
Things that I would look at:
1. Review all Windows Update policies applied to the target computer via group or local policy. I am not aware of any Windows Update policy that could cause the behavior that you are seeing, but it’s something worth reviewing nevertheless.
2. Review any type of software installed on the target computer that could cause unexpected behavior… this would typically be some type of antivirus software, host intrusion prevention/protection software, a software firewall, a software proxy, or any other security related software that is installed on the machine that could possibly interrupt what is happening.
3. Also review the Windows proxy settings on the system. I’m not sure if/how the Windows proxy settings could affect this behavior, but it’s another thing that should be reviewed.
Your suggested queue will work as desired. Step 2 will not be logged as a normal action, so after the email is sent, the queue will be terminated.
-Doug
A job queue step that comes after ‘check for available updates’ will not start until after ‘check for available updates’ has completed.
There is no mention of Silverlight in the link you referenced, so I really have no idea what you’re talking about when you mention that, but in that link there is a description of what your error means and suggestions on how to resolve it. Please review it again:
batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
We’ll consider this.
Thanks,
Doug
-1047526904 ==> C1900208
This error is discussed more at the following two links:
https://support.microsoft.com/en-us/help/10587/windows-10-get-help-with-upgrade-installation-errors
For what you are describing and wanting to do it does sound like you really want a tab with the “not yet complete” and a tab with the “already complete” hosts. However, if you don’t actually want to move completed hosts into a new tab then there are other options available:
For example you could assign a category or description or custom notes to rows that have been completed. Use ‘Actions > Modify category, description, location, notes, color etc’ Then sort by that column.
Another option is to use the Task Scheduler option to ‘Run task immediately upon detecting target computer online’. Apply that to every row in the grid and then start the scheduler and just leave it be and check back later.
If the same deployment is working on other computers but failing on just the one computer, then it’s likely an issue with psexec not being able to properly/successfully run on that particular computer.
If the same deployment fails on all computers, then the exit code 6 is likely being produced by the actual setup/installer that you are deploying. In that case you would need to refer to the vendor’s guide for what each exit code means.
Another thing you can test is just running ‘Check for available updates’ on the computer that is generating the exit code 6. See if it also fails with the same error, which would indicate that the issue is psexec. Also you can check ‘Check for available updates’ on all computers to further confirm the exact source of the issue.
1. If all target computers are affected then first try ‘Tools > Settings > Remote Execution > Use PsExec -r switch…’ and provide a name in that field such as BatchPatchExeSvc.
If the suggestion in 1. works, then it indicates that probably the issue is being caused by anti-virus or HIPS or other security software in your environment that is blocking PsExec from working. If it does not work, then try 2.
2. Try running BatchPatch from a different computer. If this works, then it indicates that PsExec has somehow broken or failed on the original computer. If this does not work try 3.
3. Try substituting PaExec for PsExec by renaming PaExec to PsExec. See if it also fails. Frequently when PsExec “breaks” on a computer, PaExec also breaks, further indicating something is not functioning properly in the system.
4. If you’re still stuck, try the BatchPatch troubleshooting guide to narrow down the source of the problem.
There was never a column dedicated for displaying the IP address. The behavior didn’t change in the 2019.3.19.15.59 version. There is a Host column where you may enter the hostname, the FQDN, or the IP address. If you ping a host in BP, it will display the IP that is being pinged in the ping reply column. This is how it has always been.
BP doesn’t have a way for you to give users the ability to approve a BP deployment before it begins. They would have to initiate the installation process themselves, as described below.
I would recommend you put all of the necessary files on a shared folder on your network, and then provide a link to each user such that when the user clicks on the link it executes a script (really can be just a single command) to install Windows 10 1903 silently.
-Doug
*This link* explains all of the possible reasons why you might experience this.
The updates are downloaded to the cache, yes. However, they are not downloaded to the targets. Use “Download available updates” before you use “Install downloaded updates” or use “Download and install updates” to get them from the cache onto the targets.
For any -102 error please review this posting:
batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
BP communicates with the machine programmatically through the Windows API. There isn’t a singular/simple command. No powershell is used. Where the machine gets updates from and how those updates are obtained is dependent on how your group policy is configured for the machine and what settings you are using in BP.
We’ll add this in the next version.
The default method used for reboots in a “download and install” operation (WMI) cannot reboot the local system. Windows won’t allow it. The ‘Privilege not held’ message is expected. You c instead use the ‘Reboot (shutdown.exe /r /f /t 0)’ method. This is available under the reboot menu item in BP or can be called from a job queue or task scheduler. However, realistically it’s not a great idea to use BP to reboot the local host because then it’s going to kill the BP instance, and any actions that are running in BP against other target computers will be orphaned or killed.
You can specify alternate credentials for any row under ‘Actions > Specify alternate logon credentials’
The licensing wouldn’t have anything to do with it. Under typical circumstances what you are doing should work fine. It seems like there is some type of weird permissions blockage somehow in your environment. It’s also possible that SEP is treating things differently when the source is also the target.
What happens if you try BP from a different source computer but with this same computer as the target?
Might also be interesting to try running as a different local admin user on the same computer instead of a domain admin that is a member of the local admins group. You could try defining a local admin user on the BP computer, then log on to the computer as that user and see what happens when trying to patch the local host.
The 5 indicates some level of access_denied / permissions issue. First make sure you have launched BP elevated as admin. You can only use it to patch the local host if it’s running elevated. Next make sure that you don’t have some type of antivirus or host intrusion prevention or other security related app on the system that could be blocking access or preventing psexec from working properly. You might also try ‘Tools > Remote Execution > Use PsExec -r switch to specify remote service name’ and then enter something like BatchPatchExeSvc there.
We’re going to see if we can get this into the next release.
Thanks,
Doug
It depends on which mode you are running BatchPatch in. The normal/default mode requires all computers to have internet access, but there are other options for running BP in offline mode where the targets do not need internet access. Please review the different scenarios outlined at this link where everything is explained in more detail: