Forum Replies Created
-
AuthorPosts
-
November 9, 2016 at 4:40 pm in reply to: Error 1800: Failed to creat remote working directory. #11432dougModerator
Your issue boils down to:
HRESULT -2147024843: The network path was not found.
This is the same as:
0x80070035 The network path was not found
This 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
dougModeratorPrelic – 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
November 8, 2016 at 12:17 am in reply to: regsvr32 /s twext.dll and regsvr32 /u /s twext.dll giving Exit Code: 4 #11430dougModeratorMaybe 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
dougModeratorIn ‘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
November 7, 2016 at 9:37 pm in reply to: regsvr32 /s twext.dll and regsvr32 /u /s twext.dll giving Exit Code: 4 #11426dougModeratorBatchPatch 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
dougModeratorVery weird. Thanks for letting me know!
Take care,
Doug
dougModeratorMike – 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
dougModeratorThanks 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
dougModeratorExtremely 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
dougModeratorHi 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
October 25, 2016 at 3:18 pm in reply to: Windows Update: Error 1611: -106 || Error 1620: -106 #11415dougModeratorInteresting. I’m going to send you an email to discuss further.
-Doug
October 25, 2016 at 2:49 pm in reply to: Windows Update: Error 1611: -106 || Error 1620: -106 #11413dougModeratorAnd can you confirm that you are using WSUS (as opposed to Windows Update)? If you go into BatchPatch Tools > Settings > Windows Update and change the ‘Server selection’ to ‘Windows Update’ does BatchPatch then work? I think the answer will be yes, as this is likely an issue with how WSUS is returning the search results. Let me know.
Thanks,
Doug
October 24, 2016 at 7:34 pm in reply to: Windows Update: Error 1611: -106 || Error 1620: -106 #11410dougModeratorThis error is:
0x8024e001 -2145067007 WU_E_EE_UNKNOWN_EXPRESSION
an expression handler was passed an expression that it
doesn't know aboutIt’s not something we have ever heard of or encountered before. What happens if you run Windows Update manually from the control panel Windows Update interface on one of the problematic target Windows 7 computers directly WITHOUT using BatchPatch?
-Doug
dougModeratorGene – 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
dougModeratorClose 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.
October 20, 2016 at 1:33 am in reply to: Re: BatchPatch authentication in domain and non-domain (workgroup) environments #11405dougModeratorYes, create the DWORD if it does not already exist.
-Doug
dougModeratorWe currently are not anticipating any issues.
-Doug
October 13, 2016 at 6:12 pm in reply to: Checking for updates take over 10 hours and installing taking over 24 hours! #11402dougModeratorThis 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
October 10, 2016 at 5:39 pm in reply to: Commandline options -> autosave Batchpatch lists / Feature Request #11400dougModeratorIn the run-as-service configuration there is not an option to modify any auto-save options. Grids are automatically saved every 15 seconds.
We do not recommend that multiple users share the same .bps files.
We will consider adding auto-save functionality to the regular BP when not using run-as-service.
With regard to command-line close/save-all, if you use the following command from the command-line on the batchpatch computer, BP will prompt you to save all.
taskkill /IM batchpatch.exe
Thanks,
Doug
October 6, 2016 at 3:53 pm in reply to: Commandline options -> autosave Batchpatch lists / Feature Request #11398dougModeratorHello Erwin – Out of curiosity, I wonder if you could explain why you would like to schedule closing the program? It helps for us to hear the “why” behind requests like these, so that we can get a better idea of the use case, which helps us determine how best to do a given implementation.
Currently if you use the ‘run-as-service’ feature, it auto-saves the grids that are running in the BatchPatch service instance. However, in the regular app (not using run-as-service) grids are not auto-saved.
Thanks,
Doug
dougModeratorHe emailed me that he ended up resolving by extracting the latest version of psexec into his C:windows folder.
-Doug
dougModeratorIt’s not clear to me what’s going on here, but it seems that something is not working with PsExec on the computer you are trying to use BatchPatch. And since PsExec is not working properly, BatchPatch is not able to successfully utilize PsExec for any operations that it uses PsExec for.
I don’t understand your last comment about powershell.exe, as I didn’t request you to do anything with powershell.exe, and powershell.exe should not be used to test because it is not used by BatchPatch or PsExec for the .reg deployment or the Windows Update actions.
I would suggest you try running both PsExec and BP from a different computer. Make sure you don’t have any HIPS or AV software that would be preventing PsExec from running on the BP console computer.
-Doug
dougModeratorI wonder if there is an issue with PsExec on the computer that you’re currently using to run BatchPatch?
Do other BatchPatch actions work?
What happens when you try ‘Actions > Windows Updates > Check for Windows Updates’ Is it successful?
What happens if you try to run PsExec from the command prompt (without BatchPatch) and just try a command like this:
PsExec \targetComputer IPCONFIG
What happens if you run the BatchPatch console on a different computer?
-Doug
dougModeratorActions and job queues can be scheduled to run when a user is not logged in by installing BP as a service.
dougModeratorYour update failed with HRESULT: -2145124320, which translates to:
0x80240020 WU_E_NO_INTERACTIVE_USER Operation did not complete because there is no logged-on interactive user
So, it would appear that Microsoft requires that this feature update has to be applied by the interactive/logged-on user. It cannot be applied by a third-party update tool such as BatchPatch.
-Doug
September 19, 2016 at 4:12 pm in reply to: windows updates – restart only if user restarts or shutsdown #11386dougModerator‘Actions > Send message to logged-on users’
dougModeratorNo.
dougModeratorThis would mean that the license you (or your company) purchased some years ago was a 175-host license.
-Doug
September 17, 2016 at 9:02 pm in reply to: windows updates – restart only if user restarts or shutsdown #11382dougModeratorIf you click “download updates,” BP will initiate the download of updates on the target computer. BP will *not* initiate the installation. BP will *not* ever install the updates unless you tell BP to install the updates. If updates are installing automatically at some later date, then it’s due to the policy that you have setup on the target computer. It’s not related to BP.
If you click “download + install updates, BP will initiate the download plus installation of updates. Yes, some updates require the machine to be restarted before they are officially/properly installed. And so in that case the machines will be waiting in a pending state where the updates are not completely installed, and the machine is waiting to be rebooted to complete the installation. It is generally not recommended to delay the restart because the machine, in theory, could be in an unstable state, and also could still be open to any vulnerabilities that you intended to close with the installation of security updates.
-Doug
September 17, 2016 at 4:56 pm in reply to: windows updates – restart only if user restarts or shutsdown #11380dougModeratorRob – Your posting is a statement. Do you have a question? In BatchPatch there are options to install updates with or without reboot. If you want to install updates but don’t want BatchPatch to reboot, then just choose the option to install updates. Don’t choose the option that says install + reboot.
-Doug
-
AuthorPosts