Forum Replies Created
-
Posts
-
Error 1611: 59
First, in the ‘All Messages’ column what do you see the line right before the ‘Error 1611:59’ appears? We would generally expect to see another failure right before it such as:
“Failed to obtain result. ERROR MESSAGE”
59 is a Windows system error code:
ERROR_UNEXP_NET_ERR
59 (0x3B)
An unexpected network error occurred.
It’s unclear to me what might have caused this. I don’t think it’s an issue with BatchPatch. I also wouldn’t be surprised if the issue goes away on its own. What happens if you try again after rebooting the target computers?
When you perform ‘Install downloaded updates’ in BP, the ‘Searching’ that you see take place occurs because before we can install updates we have to search for updates that have already been downloaded to the computer. This is actually an offline search that doesn’t reach out to WSUS or Windows Update, and normally this search should be quick, but it seems that something might have changed with Windows Updates this month because we did hear of one other customer (so far) who experienced very slow searching on Windows 2012 R2 targets this month too, similar to what you experienced.
Starting about 2 years ago, Windows 7 targets began to experience very slow search for updates. You can find discussions about this all over internet forums, and you can read our posting about it here: Checking for Available Windows Updates on Windows 7 Targets Takes Too Long
The aforementioned issue was not specific to BatchPatch usage, but rather was just slow searching for Windows Updates, regardless of the method used to perform the updates search/download/install. They claimed the issue was related to supersedence rule chain processing, which is why one of the characteristics is that svchost.exe consumes a lot of CPU while the search is taking place. That issue was resolved a couple of months ago (after plaguing users for the better part of 2 years) for Windows 7 targets, but now the behavior seems to be the same this month for at least some people with Windows 2012 R2. I would expect that if you checked the CPU usage during the search that you too would see svchost.exe consuming a lot of CPU resources while the search is being performed.
What we saw in the WindowsUpdate.log file for the one customer who reported slowness this month was that even for AutomaticUpdates, the search was also very slow. However, I think it seems fast when you do the action at the Windows Update control panel GUI directly on the target computer because Microsoft is utilizing some sort of caching, such that when you go to install the updates at the panel, the slow search was already performed behind the scenes, and so all you end up seeing is the download/install going pretty quickly.
Ultimately the issue is not something that we really have any control over since it’s tied to the Windows Update Agent and not to BP specifically, but we are researching and testing now to see if we can reproduce it or learn any more about what is really going on here. I will post here with any updates, and I predict that we will probably also end up posting about it in the BP blog at some point too.
-Doug
Sounds like an issue with PsExec not working properly on those two machines. The 233 is a Windows system error code:
ERROR_PIPE_NOT_CONNECTED 233 (0xE9) No process is on the other end of the pipe.I would first just test psexec at the cmd prompt from the BP computer to the problematic target computer by doing the following from the cmd prompt of the BP computer:
psexec \\targetComputer cmdAnd then see if you are able to issue commands successfully. Check for the existence of the psexesvc process on the target computer.
In some cases where psexec isn’t working quite right to a particular target computer, sometimes you can simply run it from a different computer, and similarly you can end up successfully running BP from a different computer.
In other cases switching the version of psexec can seem to help. If you can find a copy of an old version (ideally v1.98), you might have luck using that instead. We’ve even heard of a couple of cases where switching to an old version of psexec and then switching back to the latest version works.
Another option is to try paexec (a clone of psexec), and see if it works in place of psexec.
-Doug
cappper – In pointing out ‘Generate consolidated report of Windows Updates,’ my thought was that you would use it *instead* of running ‘Check for available Windows Updates,’ not *in addition to* running ‘Check for available Windows Updates.’ This way you would just run a single action in which you would be able to see which updates were applicable to your systems, based on your filtering selections.
I have added your suggestion to our list. Thanks.
-Doug
cappper –
First, I would strongly recommend that you select ‘critical,’ ‘security,’ ‘definition,’ ‘updates,’ ‘update rollups.’ Microsoft regularly delivers important updates under ‘updates’ and ‘update rollups’ too, so if you leave those unchecked you will be missing LOTS of important updates.
That said, if you still want to only select ‘critical,’ security,’ and ‘definition’ updates, then currently your best option would be to use the ‘Generate consolidated report of Windows Updates’ action. This will allow you to immediately see which updates will actually be applicable to your machines based on your selected classification filtering since there is a column in that report that will display the update classification, and the report grid can also be sorted by that same column, if desired.
-Doug
Glad you got it worked out!
Thanks,
Doug
Hi Paolo –
To do what you are wanting to do, you’ll need to use the BatchPatch Multi-Row Queue Sequence. You’ll probably use the advanced option, but depending on your needs you might also just use the basic option. Tutorials for this feature are at the following links:
Basic Multi-Row Queue Sequence Tutorial
Advanced Multi-Row Queue Sequence Tutorial 1
Advanced Multi-Row Queue Sequence Tutorial 2
For stopping and starting services inside of a multi-row queue sequence, you would probably use remote process/command actions that look like this:
NET STOP "DisplayNameOfService"
NET STOP "DNS Client"
NET START "DisplayNameOfService"
NET START "DNS Client"OR
WMIC SERVICE where caption='DisplayNameOfService' CALL stopservice
WMIC SERVICE where caption='DNS Client' CALL stopservice
WMIC SERVICE where caption='DisplayNameOfService' CALL startservice
WMIC SERVICE where caption='DNS Client' CALL startservice-Doug
BatchPatch lists logged on users in the following format:
3 users:
DOMAINuser1
DOMAINuser2
DOMAINuser3Since BatchPatch rows are only large enough to view one line at a time, you may use any of the following methods to view the contents of the cell:
‘Middle-click’ or ‘Right-click > View cell contents’ will display just the contents of the single cell that you clicked on.
‘Double-click’ will display the contents of the entire row that you double-clicked on.
‘Actions > Expand row(s)’ or ‘Right-click > Expand row(s)’ will display the contents of all selected/highlighted rows.
-Doug
-102: Failed to execute the search. HRESULT: -2145124322 =>
0x8024001E -2145124322 WU_E_SERVICE_STOP call was aborted due to service stop or system shut downSounds like you tried to execute the operation while the computer was shutting down or booting up, and the Windows Update service was not started.
When you kill the search it will produce an error. That is expected/normal.
-Doug
No.
If it says ‘Searching…’ then it is likely to actually be searching still. Killing it won’t solve anything because you’ll then just have to start over and wait for it to search all over again. The process is really not ever ‘stuck.’ But some computers can take a very long time to search for updates. This is not a BatchPatch issue. Generally it is a Windows 7 thing, which Microsoft acknowledged. You can read more about slow check for Windows Updates on Windows 7 here:
Windows 7 slow check for updates
-Doug
Your issue boils down to:
HRESULT -2147024843: The network path was not found.This is the same as:
0x80070035 The network path was not foundThis is a Windows issue, not a BatchPatch issue.
1. Make sure target computer firewall is configured properly: Using BatchPatch with Windows Firewall
2. Make sure no other software such as HIPS is blocking.
3. Make sure you are using correct computer name and that you can resolve fileshares on the target computer using that same name… so ‘start > run > \targetComputeradmin$ must be accessible, and so must \targetComputerC$Program FilesBatchPatch’
4. Google search 0x80070035 The network path was not found for more solutions… e.g. https://social.technet.microsoft.com/Forums/office/en-US/028a3d13-f571-49e0-abe7-1ca61fb92082/error-code-0x80070035-the-network-path-was-not-found?forum=w7itpronetworking
Prelic – Please have a look at this link, which explains more about slow Windows 7 checking for updates. This is a Microsoft issue, not a BatchPatch issue. You may be able to resolve it by pre-installing a select few updates manually in order to speed up the search time. The link below has more details.
Checking for Available Windows Updates on Windows 7 Targets Takes Too Long
Microsoft addresses it here: https://support.microsoft.com/en-us/kb/3200747
-Doug
Maybe try /f which according to the link below “Adds the registry entry without prompting for confirmation.”
https://technet.microsoft.com/en-us/library/cc742162(v=ws.11).aspx
-Doug
In ‘Tools > Settings > Windows Update’ you can modify the ‘Server Selection’ to be your WSUS (default/managed), ‘Windows Update,’ or ‘Microsoft Update.’ You can also adjust the actual search to include all software updates or just the important/recommended updates.
-Doug
BatchPatch returns the error that was reported by regsvr32 on the target machine, so I don’t think this is a BP error, but rather it’s an error from regsvr32. Googling reveals that the exit 4 is probably indicating an issue with locating the dll in question. Perhaps try the full path instead of just the .dll name?
https://stackoverflow.com/questions/22094309/regsvr32-exit-codes-documentation
-Doug
Very weird. Thanks for letting me know!
Take care,
Doug
Mike – I’m sorry to hear that you’re still having problems. We have zero other people who have ever encountered/reported this issue before, so it is exceedingly rare. There *must* be something atypical about your system/setup/environment. I wouldn’t know what else to suggest at this point other than trying a different computer. Even if you launch it on your personal/home computer I’m sure you’ll see that it works. You would need to really dig in and try to find what is different/atypical about the computer you’re attempting to use to run the app. Keep me posted if you figure out the culprit.
Thanks,
Doug
Thanks for the additional info and clarifications. With just one particular server having a problem with psexec, I don’t really have a great solution for you, unfortunately. Every once in a great while we here of a customer with a psxec issue on a single target server, and there never seems to be any rhyme or reason to getting it working again. We have had a couple people who simply updated the psexec version to the latest, and then all of a sudden it started working. We have had a couple people who downgraded the psexec version (usually to v1.98 if you can find it) and then all of a sudden it started working. Using paexec instead of psexec could possibly work too, but possibly not. We have also heard of it spontaneously just starting to work with no apparent changes made. And we have heard of it working from a different source computer where you simply run psexec from a different computer instead of the one that you’re currently using as the source.
With regard to the registry key to change BP to using PaExec instead of PsExec, it definitely does work as we use it all the time for testing. You can ensure it’s working by simply removing any copy of psexec that you have, so you’ll know if psexec is not even on the system, paexec is the one that is being invoked. You can also watch in realtime the processes list in task manager on the BP computer or with other tools or on the target server task manager processes list etc. Additionally, if you for some reason you have problems, you can also simply remove psexec and then take paexec and rename it to psexec, and that will work too from BP.
However, of course if you get paexec being used by BP that won’t guarantee that it will fix your problem, unfortunately.
I hope this helps a bit.
-Doug
Extremely peculiar. Do you have a different machine you can try it on? I can’t imagine any reason to explain the behavior you are seeing. Does your machine have any unusual or very strict security policy or software applied to it? Not that I can even imagine how or why a policy or software could cause this issue, but typically strict security policies or AV software or HIPS software are usually the ones that get their hooks deep enough into the OS to cause weird interactions with other apps.
-Doug
Hi Michael – I’m sorry to hear that you’re having a problem. The evaluation version of BP only allows once instance of the batchpatch.exe to be run at a time. If it’s giving you that message, then it would seem that there is already an instance of batchpatch.exe running on that computer, perhaps under a different logon account? I would suggest checking in Task Manager processes list and kill any existing batchpatch.exe processes that you see. Then launch just a single instance of the batchpatch.exe and you should be good to go. For what it’s worth, no one has ever reported what you are describing (unless there actually is already an instance of batchpatch.exe running), so this isn’t a normal/regular type of problem and it should be totally resolvable.
Thanks,
Doug
Gene – To be clear, I didn’t make a suggestion. I simply responded to your question about how to use PaExec instead of PsExec in BP.
I don’t know what you mean when you say “I am launching psexec remotely to test a server…” Could you clarify *exactly* what you are doing/testing? PsExec should not ever be launched “remotely” as it needs to run locally on the same machine that is running BatchPatch.
If you have an error with just a single target server, then it’s unclear what might be the issue though it seems specific to that particular server since other servers are working normally/properly. It may have something to do with psexec/paexec, but it might not. However, if you have an error with any/all target servers, then it seems to be an indication that there is a problem with the computer that is running BatchPatch.
At this time I don’t fully understand exactly all of the things that you are trying and experiencing. Is BatchPatch working properly to patch target servers with the exception of the single target computer you are experiencing the error on? The more clearly you can explain in step by step detail of what you are trying and what you are experiencing, the more likely I’ll be able to understand and help.
-Doug
Close all instances of BatchPatch. Then in HKCUSoftwareBatchPatch change the REG_DWORD isPsExec to 0. Then launch BatchPatch. That will work.
Alternatively you can just rename paexec to psexec.
We currently are not anticipating any issues.
-Doug
This doesn’t really sound like an issue with BatchPatch, considering that the BP code has not changed, and considering that the issue appears to affect only some servers, and the servers that are affected are different each time, and no other customers are reporting anything similar.
I know you don’t have any Windows 7 targets, but this sounds not-too-dissimilar from what Windows 7 users have been experiencing for more than a year now with slow Windows Updates, due to some issues with the OS that Microsoft has continued to work on fixing all of this time. I would suggest you have a look at this posting just to get an idea of what was going on there, just in case there might be any potential relationship to what you’re currently seeing.
Checking for Available Windows Updates on Windows 7 Targets Takes Too Long
In your case it sounds like it could be something in your environment or it could be something with Microsoft’s update servers or connectivity to those servers.
When BP initiates a search for updates or a download/install operation, it invokes the Windows Update Agent, which is the same agent that the control panel Windows Update GUI uses, so there isn’t generally any difference in the time it takes to check through the control panel Windows Update GUI vs BP.
I’m going to send you an email so that you can send me some logs to look at.
Thanks,
Doug