[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

[doug]

Glad you got it worked out!

Thanks,

Doug

[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

[doug]

BatchPatch lists logged on users in the following format:

3 users:

DOMAINuser1

DOMAINuser2

DOMAINuser3

Since 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

[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 down

Sounds like you tried to execute the operation while the computer was shutting down or booting up, and the Windows Update service was not started.

[doug]

When you kill the search it will produce an error. That is expected/normal.

-Doug

[doug]

No.

[doug]

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

[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 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

[doug]

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

[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

[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

[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

[doug]

Very weird. Thanks for letting me know!

Take care,

Doug

[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

[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

[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

[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

[doug]

Interesting. I’m going to send you an email to discuss further.

-Doug

[doug]

And 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

[doug]

This error is:

0x8024e001 -2145067007 WU_E_EE_UNKNOWN_EXPRESSION

an expression handler was passed an expression that it

doesn't know about

It’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

[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

[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.

[doug]

Yes, create the DWORD if it does not already exist.

-Doug

[doug]

We currently are not anticipating any issues.

-Doug

[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

[doug]

In 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

[doug]

Hello 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

[doug]

He emailed me that he ended up resolving by extracting the latest version of psexec into his C:windows folder.

-Doug

[doug]

It’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

[Author]

Posts