Forum Replies Created
-
Posts
-
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:
I posted a link (twice) above that describes the possible causes and resolution steps. Please review it.
We will look at adding an option in a future build to automatically exclude disabled rows from synchronizations. In the current build you would have to manually add the desired computers to the ‘Exclude hosts from synchronizations’ list in the grid synchronization settings window.
Does the uppercase DNS suffix create some kind of problem? Or is it just visually distracting/uncomfortable? I’ll discuss with the team. I’m not sure if there is a reason for it or if it was just to standardize the values.
-Doug
Makes sense. Thanks for the update.
-Doug
If it stays “Executing” indefinitely, it generally means that it did not actually run “quietly” and instead it is waiting for user input of some kind. However, since it runs hidden, of course no user input can be provided.
I would suggest that you test this syntax manually at the command prompt WITHOUT using BatchPatch. Get your syntax working manually at the command prompt without it requiring any user interaction. Once you have the syntax figured out at the command prompt, then you can easily port it into BatchPatch.
Assuming your parameters and syntax work at the command prompt without requiring any user interaction, then when you enter the command into the BatchPatch deployment the “Command to execute” field would look something like this:
msiexec.exe /p "YourFileName.msp" REINSTALLMODE=omus REINSTALL=ALL BB_DEFAULTVIEWER=0 BB_DESKSHORTCUT=0 IGNORE_RBT=1 DISABLE_WELCOME=0 /qnNOT like this:
msiexec.exe /p "C:SomeFolderYourFileName.msp" REINSTALLMODE=omus REINSTALL=ALL BB_DEFAULTVIEWER=0 BB_DESKSHORTCUT=0 IGNORE_RBT=1 DISABLE_WELCOME=0 /qnThe likely cause of this is that psexesvc is not running successfully on the target. Normally psexec creates the psexesvc service on the target computer, but this is likely failing in your case. It might be that there is antivirus or other similar blocking in place.
I would start by trying the following setting in BatchPatch:
Tools > Settings > Remote Execution > Use PsExec -r switch to specify remote service nameThis setting allows you to modify the remote service name that is used by psexec from ‘psexesvc’ to ‘BatchPatchExeSvc’ or any other custom name of your choice. In the case where anti-virus or other security related software is blocking the remote service from running, changing the name of the remote service with this setting can often work to bypass the restriction for some of those applications without having to add psexesvc to a whitelist.
I would also suggest reviewing these postings:
Thanks. It sounds like psexec is blocked on the computer. This can happen as a result of Windows settings that prevent running an executable file that was obtained from somewhere else until after permission has been explicitly granted. One way this manifests is with a popup of a dialog that says “File Insecurity Warning” and prompts you to either check or uncheck a box to make sure that it never prompts again. The issue with this is that if you are running BatchPatch as a user that is not the logged-on user, then this popup might not be visible. It’s also possible that this popup doesn’t appear at all. Another way that this can usually be resolved is to right-click on the psexec.exe and select ‘Properties.’ Then on the ‘General’ tab at the bottom there is a section titled ‘Security’ that says “This file came from another computer and might be blocked to help protect this computer. Then there is a checkbox next to that to “Unblock.” Select the checkbox and click ok.
Please confirm you got everything working.
-Doug
Can you give me the verbatim text that it gets stuck on?
The app never says these two things exactly:
“initiate windows update…”
“initiate deployment”
In order to troubleshoot this to determine exactly where things are getting stuck, I need to start with learning the exact text that you’re seeing hang indefinitely. There are too many places with *similar* text, so I can’t pinpoint your issue without knowing the exact text.
Thanks.
PsExec is a tool, not a criminal. A tool can be used by a criminal or a tool can be used by a law-abiding person. If a criminal uses a tool, does it make sense for the law abiding person to stop using that tool? What impact would this have on the criminal’s behavior or usage of the tool? For example, if a criminal used a car as the transportation mechanism to rob a bank, what would it solve if you then stopped driving your car?