Forum Replies Created
-
Posts
-
To close the loop on this, we identified a bug in the method that accepts the EULAs for updates. The fix has been published (20160630).
-Doug
Hard to tell exactly what happened here. You can normally use ‘Get last boot time’ in BatchPatch to quickly see the last start time of the computer, which would answer the question of whether or not it was actually rebooted. But since you already rebooted it again, you would need to look in the event log to confirm whether or not it was rebooted by BP on Wed night. To me it looks like it *was* rebooted, based on the following two events.
Wed-20:47:16> COMPUTER ONLINE
Wed-20:47:12> COMPUTER OFFLINEIn this case you used ‘Reboot (force always).’ However, the ‘force’ method does not guarantee that the computer will return a ‘success’ message to indicate that it accepted and is processing the reboot command, which is why the ‘RPC server is unavailable’ or other error/failure messages can occur in that case, even when the machine is actually rebooted successfully. Generally speaking, I would recommend always using ‘force, if required’ which will always first try a normal reboot. It will only use ‘force’ if the normal reboot cannot be initiated. There is nothing wrong with using the ‘force always’ option, but since it doesn’t guarantee a return value, it can add confusion in the cases where it doesn’t return ‘success’ but still reboots successfully. This is not a BP issue. It’s how Microsoft designed the ‘force’ method.
The one piece of the puzzle that does not make sense is the Error 1623. This should be investigated independently because it normally should only occur if there is a pre-existing Windows Update process running on the computer. From your log there does not appear to be a previous attempt to initiate Windows Update, so it’s unclear to me why you would receive this error, unless you had already initiated Windows Update from a different BP grid. Considering that you already rebooted the machine and find that it is working properly/normally, there is nothing else really to do. We won’t be able to determine why that error occurred anymore.
-Doug
We’re currently investigating this issue, which has been reported by one other user. I will update this thread when I have more information.
-Doug
It has nothing to do with WMI, and there is nothing you can do to modify the behavior. Incorrect progress information is being returned by the Windows Update agent. We have no control over this. It should not happen with any regularity. It is something that we have only ever heard of on rare occasions.
That said, you should also look at the remote agent log and make sure that there weren’t failures during the download. If updates failed to download, that could be a legitimate cause for the incomplete progress bar.
Yes, so currently there is only $computer for local commands, which pulls the host column value. However, in a future version we will likely add the ability to pull from a number of the other columns, such as $notes, $notes2, $description, $location etc. And they would be usable in not only local commands but also remote commands and get info commands.
-Doug
We have plans for a solution to this problem in a future version of the app. I’m not sure exactly what the timeline for implementation/release is.
-Doug
Thanks for clarifying. I had misunderstood your original question/request. That said, I would like to add my two cents now that I understand your question. What you’re asking to do, in my opinion, seems a bit odd and unnecessary. In fact, I suspect it will only cause you grief. The reason is because what you are trying to do is exactly what the Windows Update Agent already does. You don’t want to manually look through and compare every single installed update with the list of updates from Microsoft because that would be extremely tedious and time consuming. However, when you run Windows Update (either on the computer directly or through BatchPatch), the target machine compares what is currently installed on the machine to what updates are available. There is a lot of complex rule processing that occurs to deliver the final list of available updates. This ‘check for available updates’ action *IS* the verification, essentially. This is the process that does the comparison that you’re trying to do manually. The only caveat is that if you are using a local WSUS instead of Windows Update (or Microsoft Update), then it’s possible that you didn’t approve certain updates on the WSUS that should be installed on the target computer(s). If this is the case, then the best way to see what other updates would be available to the target computer(s) if you were not using a WSUS is to simply switch the ‘Server Selection’ in BatchPatch under ‘Tools > Settings > Windows Update’ to point to ‘Windows Update’ instead of ‘Default/managed.’ Then when you check for available updates in BatchPatch, the target computers will check against Microsoft’s servers instead of your local WSUS. The report of available updates that is generated will tell you what, if any, updates are needed by target computers. I hope this helps a bit.
Good luck.
Note the Fault Module Name: swi_ifslsp_64.dll. This .dll belongs to Sophos Layered Service Provider (LSP). I believe this is the source of the problem. It’s not a BatchPatch issue.
-Doug
Please review Troubleshooting common errors in BatchPatch
-Doug
All you really need to do is highlight every computer in one grid/tab, and then run the report. This will give you a report for that entire grid/tab. Then go to your next grid and highlight every row, and then run the report. And so on.
I hope this helps.
-Doug
No problem! Glad to hear that BP is working so well for you!
Thanks,
Doug
For what you are describing you actually do not need to change the config on the target computers. Instead, I would recommend that you leave the config on the target computers as-is. Then in BatchPatch go to ‘Tools > Settings > Windows Update’ and change the ‘Server Selection’ value to ‘Windows Update.’ Then when you initiate a download/install action in BatchPatch, BP will instruct the target computers to check for updates on Windows Update instead of your local WSUS.
I hope this helps.
-Doug
I think they are all ultimately from the same cause, which is that PsExec and PaExec are failing to operate successfully on that target. Under normal circumstances when these apps operate, they are able to create the target remote service/process, and when completed running, they are able to successfully remove the service. It sounds like this is not happening successfully for you. We have heard of this a few times, and it’s always just one or two problematic computers out of hundreds or thousands. Aside from switching from PsExec to PaExec or to an older version of PsExec (v 1.98 or earlier) and then switching back, we have not ever determined a definitive solution.
One other thing to try is see what happens when you run BatchPatch on a different computer. There was one case, if I am remembering correctly, where a problematic target stopped being problematic when the admin ran the BP console from a different computer.
-Doug
Re-attach orphan was successful, indicating that the batchpatchremoteagent.exe was still running on the target. Normally it should complete within seconds or minutes, but in some rare cases the Windows Update Agent can take a very long time to return a result. In particular there have been tons of complaints all over the web to Microsoft about Windows 7 WUA taking way too long to run, but rarely does it happen with other operating systems. Win 2008 would have been a more likely culprit than 2012, but it sounds like in your case once you rebooted the target, it started responding properly/quickly once again. You will be able to switch back to PsExec and it should work just fine.
-Doug
I think the
'Error 1620: -6. Failure'is essentially the same as the Windows Update:'Error 1620: 2. Failure'with the only difference being that using PsExec gives you the 2, while using PaExec gives you the -6. Both are failing in BP at the same spot.According to the PaExec home page, -6 means:
PAExec service could not be installed/started on remote serverI think ultimately the issue you are having with this particular computer is definitely related to PsExec and PaExec failing to operate successfully, which is what we saw in those other threads I linked to above. It’s peculiar that you are able to successfully run the
'psexec \targetComputer IPCONFIG'test, despite psexec and paexec not operating successfully for use with BP right now on that target. Unfortunately I am not able to offer you any other possible solutions/fixes. We have even heard of this issue spontaneously correcting itself for no apparent reason.-Doug
You do not have to save the grid in order to see additional details about which update failed. As mentioned above, you can view the log in BatchPatch with ‘Actions > Windows updates > View BatchPatch.log.’ Alternatively you can view this log file directly on the target computer at C:Program FilesBatchPatchBatchPatch.log. This will show you the entire BatchPatch history on that computer.
-Doug
Hello Steven – let me refer you to these two other threads. Please review them carefully, and let me know if you have any luck with the suggestions. Essentially, this issue has been reported by only a very small number of users, and it’s always only happening on just one or two of their servers. We have not so far been able to reproduce the problem.
This error occurs when BP tries to copy the BPRA (BatchPatchRemoteAgent.exe) to the target system. If the file already exists there from a previous BatchPatch action and is locked because it is still in-use, then BP cannot overwrite it. Under normal circumstances BP removes it automatically after it completes an action. If BP did not remove it, then it likely was still running or somehow got orphaned (maybe the BP console was closed and so it lost connection to the target’s agent process, for example).
First, try ‘Actions > Windows updates > Re-attach orphan’
BP will attempt to re-connect to the previously running process, if it’s still executing on the target machine. If it’s not executing, then BP will not find an orphaned process to attach to. If it DOES attach to the orphan, then you’ll know that you did actually have a process that was still running. If it does not attach, then check in the target working directory (default is C:Program FilesBatchPatch) and see if the BatchPatchRemoteAgent.exe already exists in that directory. If it does, see if you can delete it manually. Normally it would only ever be locked by the fact that it is executing, but it is also possible that it could get locked by an anti-virus software or similar HIPS or other security software.
If you don’t even find the BatchPatchRemoteAgent.exem but you continue to get the error, then it would have to be an access/permissions issue of some kind. Even if you have full admin access to the machine, something is going on where permissions are being denied when BP tries to write the BatchPatchRemoteAgent.exe to the target working directory.
-Doug
1. You need to look at the ‘Remote Agent Log’ column to see which update(s) failed to download/install. There you should also see an error number or HRESULT value, which will be the reason code for the failure. Note, the contents of the ‘Remote Agent Log’ column are replaced each time you execute a Windows Update action, so if you are running a cycle with multiple Windows Update actions, then in order to see the complete history of the entire cycle you need to look at the BatchPatch.log, which you can view in BatchPatch with ‘Actions > Windows updates > View BatchPatch.log.’ Alternatively you can view this log file directly on the target computer at C:Program FilesBatchPatchBatchPatch.log
2. I’m a little bit confused what is going on here. Your log is peculiar. In particular what does not make sense to me is that at Thu-21:29:44 the download/install/reboot task is executed. But then we see Thu-21:29:48> COMPUTER ONLINE. Where is this coming from? It’s not clear from your log where this additional “COMPUTER ONLINE” is coming from since we already see that at Thu-21:29:23> COMPUTER ONLINE. BP does not log ‘COMPUTER ONLINE’ twice under normal circumstances. Furthermore, we then don’t see anything else until ~12 hours later at Fri-09:48:57> Windows Update: Download operation completed. Additionally, we normally would not expect to see “Download operation completed” logged to ‘All Messages’ for a ‘Download and install updates + reboot if required’ action. We would only expect to see ‘Download operation completed’ logged to ‘All Messages’ when ‘Download available updates’ was executed. However, it’s surely related to the error 64 because I think BP could not continue and so it logged ‘Download operation completed’ since it could not continue with the installation and reboot. Though still I’m not positive exactly how this occurred. Lastly, the error 64 is coming from Windows, and it translates to:
ERROR_NETNAME_DELETED
64 (0x40)
The specified network name is no longer available.All in all, it’s difficult for me to tell you exactly what happened here, but I will posit a couple of guesses. It’s as if the computer went offline in the midst of a BP operation.
One possibility is that after the computer initially came back ONLINE it automatically initiated a reboot on its own. Sometimes Windows Updates will auto-reboot the computer to complete an installation. BatchPatch has no way to track this, unfortunately. However, it might be why things got weird. One way to avoid this issue is to always have a 10 minute wait period after the ‘Wait for host to go offline and come back online’ to ensure that the computer has completed any additional reboot that Windows Update might automatically initiate. In this case while it might explain why we see an additional COMPUTER ONLINE in the log, it doesn’t explain why we don’t see an additional COMPUTER OFFLINE in the log before that.
A second possibility is that someone from a different BP installation tried to perform a task on the same computer while one was already running. It’s almost as if someone rebooted the machine while BP was working. Again though, I cannot say for sure from this log exactly what is happening.
All in all, I don’t fully understand what happened here. I would suggest first starting with the BatchPatch.log to see what updates failed. Then see what happens when you initiate a new download/install/reboot task. It might be best to not use the job queue or update-reboot cycle until you are a bit more comfortable with the results that you see from executing a few standalone Windows Update actions. This is your choice, of course, and it’s certainly not a huge deal to just continue using them. The job queue and update-reboot cycle are great tools and very powerful, but they add complexity and make it harder to decipher what is going on in the event of a problem. Certainly if you DO use the job queue or cycle, then at the very least I would suggest that you try putting a 10 minute wait after the ‘wait for host to go offline and come back online’ to see if that helps deal with any extra reboots that Windows Update auto-initiates.
-Doug
Andreas – Please review instructions here:
The remote agent crashing on this single target system is indicative of some deeper problems with the target OS installation. We do not believe there is an issue with BP or the BPRA.
-1073741502 == C0000142
I googled and found this, which may or may not be helpful:
https://support.microsoft.com/en-us/kb/191991
You might consider running the system file checker or other system diagnostic tools to see if you can get to the bottom of any issues with that OS installation. The batchpatchremoteagent.exe is running successfully without crashing on literally hundreds of thousands of target computers all over the planet. Your single problematic system has some kind of problem that appears to be DLL related, according to the Microsoft link above.
-Doug
The Microsoft WMI troubleshooting link posted above is really the best source I know for troubleshooting WMI issues. For now I agree with you that simply running it on a different box is the best plan.
-Doug
There are not any programs that are known to cause issues with BP, nor would I expect any programs to cause issues with BP. The issue that you are describing is a Windows OS permissions issue, not a BP issue, and not likely related to a third party product, unless it was a security product, which I suppose could theoretically alter OS permissions/settings. I agree with you that something must have changed either on the BP host machine or on target machines. Usually an ‘Access Denied’ issue is a permissions issue on the target computer, not the host computer.
You might consider re-going-over the Microsoft WMI troubleshooting steps as a starting point to get WMI permissions working. Perhaps something has changed again with DCOM, which was the original source of the problem that amartin fixed. Sometimes just having a second set of eyes or a fresh look is all that it takes:
https://msdn.microsoft.com/en-us/library/aa394603%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
And also re-go-over the BP authentication stuff:
Unfortunately I don’t really have any other great suggestions other than to just reiterate that you are encountering a permissions issue of some kind. There is no case where ‘Access Denied’ has ever been produced when permissions were not at the core of the problem.
-Doug
Well I think you have a couple options. Considering that you got everything working last week, then either those systems have been modified since last time, or something that you are doing is different. You said that other tools that use WMI are still working fine. This to me is the key. BatchPatch does not have some special way of using WMI. WMI is WMI, and there is only one way to use it. That said, if you are successfully using WMI in other tools, then it sounds to me like maybe in BatchPatch you are executing with an account that does not have the appropriate permissions. I know you said that you’re using an account with permissions, but considering everything else that you’ve said, I would suggest taking a step back, closing all instances of BatchPatch, and then start from scratch. Verify the account that is in the local admins group on the target computer. Then since you’re using option 1, I would even suggest logging off of your own computer and re-logging back on with the same account. Maybe the password changed or expired? Then launch BP. Then test again. I can assure you that whatever problem you’re experiencing, it’s not a BP issue. If BP says “Access Denied” then it’s a permissions issue.
You need to execute the deployment specifying the silent/quiet installation parameter. See the following link for a detailed explanation of this process:
Understanding and Discovering the Silent Parameters Required to Remotely Deploy Software
1642 is returned by the msp package not by BatchPatch. We recommend that you test an installation package at the command line on a host before deploying with BatchPatch to make sure the package works. Once it’s established as a working package, deploy it with BP.
msi/msp returns codes:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa376931(v=vs.85).aspx
ERROR_PATCH_TARGET_NOT_FOUND
1642“The installer cannot install the upgrade patch because the program being upgraded may be missing or the upgrade patch updates a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch.”
You’re welcome. However, no I was not suggesting that you import into Excel. You can get exactly what you’re asking for inside of BatchPatch in 3 different ways.
1. Specify the KB number(s) or update title(s) so that only the update(s) you are looking for appears in the results:
2. If you don’t specify the KB number in the search, you can still sort your results by KB number.
3. You can also use the ‘find’ box to find the particular update that you’re looking for in the results window.
Actions > Windows updates > Generate consolidated report of update history-Doug
Thanks for reporting back. You might consider trying an app like ProcessExplorer (https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx) to determine file handle ownership (https://support.microsoft.com/en-us/kb/232830) to see which program has a lock on the psexesvc.exe file. It could be an anti-virus or similar security related application that isn’t letting it go. If you find no handles, then it might still be strange a permissions issue of some kind.
-Doug
SCCM actually relies on its own WSUS server, so I’m not sure that you are truly getting rid of WSUS. In any case, the WSUS that SCCM uses is completely “owned” by SCCM and is not compatible with 3rd party update utilities such as BatchPatch. That said, in order to use BatchPatch you would have to either point your targets to a new WSUS that is not controlled by SCCM, or you could instruct BatchPatch to search for updates on Windows Update or Microsoft Update instead of your local SCCM WSUS.
-Doug