[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

[doug]

I 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

[doug]

Actions and job queues can be scheduled to run when a user is not logged in by installing BP as a service.

Running BatchPatch as a Service

[doug]

Your 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

[doug]

‘Actions > Send message to logged-on users’

[doug]

No.

[doug]

This would mean that the license you (or your company) purchased some years ago was a 175-host license.

-Doug

[doug]

If 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

[doug]

Rob – 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

[doug]

I’m not able to reproduce your issue. However, I also think that what you are experiencing might be fixed in the most recent release of BP from yesterday. We added a setting for ‘Remote Execution Context’ under ‘Tools > Settings > Remote Execution.’ I suspect that in your case if you try to execute the deployment under ‘SYSTEM’ that all will work, but when you try to use one of the other execution contexts, it will not work. That’s my best guess, at least. Try it out and let me know.

If the above suggestion doesn’t work, then please can you paste the entire ‘All Messages’ column contents for me to review?

Also, can you confirm that in the Deployment window you have UNchecked ‘Retrieve console output…’ ?

Lastly, can you confirm that your ‘Command to execute’ field reads like this (name of the .reg file might be different, of course):

regedit.exe /s "wu.reg"

[doug]

Will get back to you on this in a few days…

[doug]

At the time of this writing it appears that Microsoft is only allowing the anniversary update to be installed either through WSUS or directly at the computer by the interactive user. I suspect that at some point they will change this policy, but for now it seems to be how it is. Also, they are pushing the update slowly, so not all computers are currently receiving it through the normal Windows Update channel. It has been reported that Microsoft expects to deliver the update over the course of multiple months. Many Microsoft customers are currently not even presented with the option to apply the anniversary update through Windows Update directly.

-Doug

[doug]

Troubleshooting Common Errors in BatchPatch

For all -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx

[doug]

-102: Failed to execute the search. HRESULT: -2145107940

The above -102 error indicates that the target computer’s Windows Update Agent had a problem when it tried to connect to the WSUS server. This has nothing to do with BatchPatch. The -2145107940 is a Windows Update error code that translates to:

0x8024401C WU_E_PT_HTTP_STATUS_REQUEST_TIMEOUT Same as HTTP status 408 – the server timed out waiting for the request.

---

---

-106G: Update search completed with errors: -2145124338

This error and its resolution are explained here:

Windows Update: Error 1611: -106

---

---

Since you are looking to retire your WSUS, then you don’t even need to bother with resolving the -106G error. Instead, you can do one of the following two things:

1. In BatchPatch go to ‘Tools > Settings > Windows Update’ and change the ‘Server Selection’ to ‘Windows Update.’ This setting will tell BatchPatch to have target computers search for updates against Microsoft’s public server instead of your local WSUS.

2. Change your group policy setting that currently has your OU computers pointing to your local WSUS. You would need to remove the policy for ‘Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify intranet Microsoft update service location’ Once this is done, if you leave BatchPatch in the same configuration as before with ‘Server Selection’ set to ‘Default/Managed’ then when you check for updates, the target host will go to Microsoft’s public server instead of your local WSUS.

-Doug

[doug]

To be clear, I need to see the exact contents of the .reg file please instead of a description of the contents. If you want to modify server names and IP addresses, that’s fine, but I want to see the .reg file so that I can test the same thing here. If you are a current customer, please email us directly using the contact form on our website. Include the name on your license, so that we know who you are.

(I won’t ask why you would publish local policies via reg key rather than push these through group policy.)

-Doug

[doug]

Did this problem occur with just a single target computer or all target computers? What are the contents of the .reg file?

Thanks,

Doug

[doug]

Thanks for the suggestion. We will consider this for a future build.

-Doug

[doug]

Steffen – I sent you an email to troubleshoot directly so that we can look at logs etc. What you’re describing is extremely peculiar, and I’m not sure right now what to make of it without further information.

-Doug

[doug]

Thanks for posting your fix. Unfortunately I don’t know if it’s possible to successfully run the WindowsUpdateDiagnostic.diagcab without user interaction. In order to run remotely it would have to be able to run silently/quietly without user interaction. The command line invocation for this .diagcab, according to https://blogs.msdn.microsoft.com/mattbie/2010/11/09/running-a-troubleshooter-from-the-command-line/ , is:

msdt.exe /cab c:troubleshootersmyTroubleshooter.diagcab

However, I found that when I ran this command, it still presented a dialog and did not run silently/quietly without user interaction. The following link shows the command line parameters that are available for msdt:

https://technet.microsoft.com/en-us/library/ee424379%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

However, there is no silent/quiet switch. There appears only to be an answer file /af switch, but I don’t have details on that kind of usage, and I wouldn’t be surprised if it’s not possible with the WindowsUpdateDiagnostic.diagcab.

You might have to just run the fix manually on each affected computer.

-Doug

[doug]

Hi Stefan – What you’re describing doesn’t really sound like an issue with BatchPatch. It sounds like possibly there is something (or was something) going on with your computer/OS. However, it’s very difficult to say for sure. If you had noticed that the memory usage by BP was absurdly high in task manager, then that certainly might indicate a leak, but from what you described that doesn’t seem evident. BP has a small memory footprint, and we have not observed nor have any other customers reported any clear memory leaks.

The command “sc config wuauserv start=auto” should work just fine, even without the space after the = sign. I wonder if your computer had some kind of issue while you were using BatchPatch, and so it seemed like BatchPatch was the source of the problem when really BatchPatch freezing was just a symptom of a larger problem that was occurring on your machine. This would also explain why other applications froze.

-Doug

[doug]

Danny – Thanks for sharing your experience. Glad that fixed it for you!

-Doug

[doug]

Excellent!

[doug]

jjlandstrom – This doesn’t sound like a BP issue. It sounds like something weird happening with Windows Update on the target computer or maybe some other OS issue. I would try to let it go as long as possible before killing it, just to be sure that it’s def stuck and not going to make progress. 2 hours certainly should be more than enough, but if possible maybe let it run for another couple just to be absolutely safe. Or could it be that the target computer has IE open, and IE needs to be closed first? That’s just a wild guess. I wonder if whatever is preventing it from completing is the same thing that’s preventing the ‘Deployment’ that you attempted from completing. It could indicate a deeper issue with the OS, I suppose. Not really sure. However, I had no problem deploying the IE11 x64 installer exe directly on a new 2008R2 machine, and I haven’t ever seen an issues like the one you are describing when it comes to using the WUA to update IE.

Another option is to try renaming/deleting the ‘C:WindowsSoftwareDistributionDownload’ folder on the target and then trying again. If still no luck, could try renaming/deleting the ‘C:WindowsSoftwareDistribution’ on the target and trying again.

Good luck.

-Doug

[Author]

Posts