[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

[doug]

With regard to sorting for existence of logonui.exe, I would recommend creating a custom command under

'Actions > Execute remote process/command > Create/modify remote commands (logged output)'

The command would be:

WMIC PROCESS where name='logonui.exe' get caption

When you run it, in the ‘Remote Command Output Log’ column you’ll see either

No Instance(s) Available.

or

Caption logonui.exe

You should then be able to sort on that column to get the info you need. Also note, you probably already know this, but just in case you don’t… I’m not sure that logonui.exe guarantees that the user is not logged-on. For example, I think the logonui.exe will be running even during an active RDP session. That said, checking for the existence of logonui.exe should probably be used with care.

---

---

With regard to your feature request to be able to see the username of the logged-on users. You can already view this in in the ‘Logged On Users’ column. Use ‘View cell contents’ or middle-click the cell to view just that cell or double-click the row to view the entire row’s contents. Example output in the grid is:

Logged On Users

3 users:

domainuser1

domainuser2

domainuser3

---

---

I hope this helps.

-Doug

[doug]

I should also note to anyone else reading this posting that whenever possible we strongly encourage/recommend to users to not synchronize any drivers to WSUS. The drivers dramatically bloat the WSUS database and seem to only cause issues. In our experience, driver updates should generally be performed on computers as-needed and not through WSUS or Microsoft Update. You can find numerous postings on the web that agree with this sentiment. Updating drivers through the Windows Update mechanism generally seems to cause more problems than it solves.

-Doug

[doug]

chays33 – I’m not sure about the x86 vs x64 package differences. I have not experienced any issues deploying the x64 version, and I just did another test again with a 2008R2 target with no problems. Generally speaking if a Deployment ‘hangs’ indefinitely, it’s because the package was executed in a way that ended up somehow requiring interaction from the end user. The /quiet switch is there to prevent user action from being required. If you forget to use the /quiet switch, then when the package is executed, it pops up a dialog box for the user to click through. But since you’re doing a remote installation, there is no interactive user, and the dialog box is hidden on the target. And so this manifests as indefinite ‘hanging’ of the deployment.

You said that the x86 worked. Is the reason for the x64 failure occurring because you’re trying to install the x64 version on a x86 machine? What happens if you try to manually run the x64 installer at the command line on the target computer *without* using BatchPatch? So, at the cmd prompt you would type the following, where someFolder is the actual folder that you have put the .exe file:

C:someFolderIE11-Windows6.1-x64-en-us.exe /quiet /norestart

I suspect that running this at the command prompt will inform you as to why running in BP is hanging indefinitely. Does it pop up some sort of dialog box? If it pops a dialog box, then that is likely the reason that the installation is hanging. What does the dialog say? If it completes successfully, then I wonder if maybe you just forgot the /quiet switch on the first attempt? Because if it completes successfully and silently without any user interaction from the cmd prompt, then there is no reason that it won’t work from BP. And considering that I just re-tested the x64 IE11 deployment from BP without any problems, I know that it is able to work.

Scott posted an IE11 deployment tutorial here, in case it helps: Deploying IE 11 to Multiple Computers

jjlandstrom – Under ‘Tools > Settings > Windows Update’ try checking the box at the bottom that says “Re-copy/overwrite updates that have already been cached on target hosts” and then see what happens. Let me know.

-Doug

[doug]

Download from Microsoft the IE11 setup file for your language and OS:

https://support.microsoft.com/en-us/help/18520/download-internet-explorer-11-offline-installer

The command line parameters for the IE setup file are listed here:

https://technet.microsoft.com/en-us/library/cc817409.aspx

And so we simply create a deployment in BatchPatch like in the screenshot below. Note the /quiet /norestart parameters

There are more deployment examples and tutorials posted at BatchPatch Software Deployment

-Doug

[doug]

Thanks, Stefan. We understand the cause of this behavior, and we should be able to have it fixed for next release.

-Doug

[doug]

Jason – I suspect that an email address (somewhere) is not in the correct format. Feel free to email us to troubleshoot. It will probably be easier that way to trade screenshots etc to confirm that you have everything configured properly.

Thanks,

Doug

[doug]

You can programmatically launch a .bps file with a command like this:

batchpatch.exe “C:filesyourFile.bps”

You won’t be able to directly execute commands in BatchPatch from the powershell script, but you can set BP to start with the scheduler enabled (Tools > Settings > Startup options > Enable Task Scheduler on startup), and then it will execute whatever scheduled tasks you have configured in that .bps file.

Alternatively you may run BP as a service to ensure that scheduled tasks in BP execute regardless of whether or not someone is logged on to the computer. (Tools > Run BatchPatch as a service)

-Doug

[doug]

Ralf – in all Windows applications (not just BP) drag and drop does not work if the program is running as administrator. If you want to use drag and drop, just run BP without admin elevation. Admin elevation is only necessary if you need to add the localhost to your BP grid.

-Doug

[doug]

Joe – It appears that the old method outlined in the tutorial you followed no longer applies to the new Java offline installer. We weren’t aware of this change to the installer. Scott just posted a new, updated tutorial for using BatchPatch to install Java remotely with the new Java offline installer:

Remotely Install Java 8 On Numerous Computers Simultaneously

Thanks,

Doug

[doug]

Host must be added by name or IP address. In order for name to work, name resolution on your network must work. The large majority of BatchPatch users simply enter the hostname. In some cases, people enter the fully qualified domain name (FQDN) to ensure proper name resolution, but this depends on how your DNS is configured.

If you look at any of the numerous tutorials on our website, you’ll see that we always use either hostname or IP address. There are no cases that we use MAC. MAC is only useful for the Wake On LAN feature, but in that case the MAC must be added to the MAC column, not the hosts column.

More here: importing-hosts-and-other-information-into-a-batchpatch-grid

And: wake-on-lan-with-batchpatch

-Doug

[doug]

You found a bug. We’ll get that fixed. Thanks for notifying us. In the meantime, you can use ‘Actions > Clear column contents’ to empty that column.

-Doug

[doug]

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

In the meantime, the good news is that very slow updating of Win 7 computers appears to have finally been mostly resolved by Microsoft. So once you are up to date with updates on your Win 7 computers, it is likely you will once again start seeing completion occur within minutes instead of hours. We have posted about this here, if you’re curious: Checking for Windows Updates on Windows 7 is very slow

For now, a few other possible work-arounds are:

1. Perform the update process in one action, and then perform the reboot in a separate action only after you confirm that the update process has completed.

2. After you kick off the updates + reboot action on hosts, if they do not complete updating in a reasonable amount of time, such that you have any concern for it impacting your users, close BP. The update process will complete/finish on its own, but the reboot will never occur if BP is not running. You can re-open BP and re-add the same target hosts, and then you can use ‘Actions > Windows updates > Re-attach orphaned Windows Update process’ to re-connect to the target processes to continue monitoring their statuses. The ‘re-attach orphan’ option allows you to choose whether or not you want the reboot to occur when the update process is complete.

3. Utilize the Job Queue option to ‘Wait for host to have zero logged-on users’ before the reboot step. This may or may not be useful in your environment, depending on whether or not your users log off of their computers.

-Doug

[doug]

Generally speaking I would suggest that if you have jobs running that you leave them to complete before you close BatchPatch. However, BP does have the ability to re-connect to Windows Update tasks that are still running after closing BP, so you could close BP if you really want, and then you could run the new version and use ‘Actions > Windows updates > Re-attach orphaned Windows Update process’ to reconnect the existing remote processes.

Also, with regard to updating, you could also simply download the new version and run it side by side with the old version until the old version’s tasks are all complete.

-Doug

[doug]

Thanks for confirming.

[doug]

Please have a look at reason number 2 at the above linked FAQ page.

[doug]

See ‘Reason 3’ on this page:

BatchPatch FAQ

[Author]

Posts