[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

[doug]

To close the loop on this, we identified a bug in the method that accepts the EULAs for updates. The fix has been published (20160630).

-Doug

[doug]

Hard to tell exactly what happened here. You can normally use ‘Get last boot time’ in BatchPatch to quickly see the last start time of the computer, which would answer the question of whether or not it was actually rebooted. But since you already rebooted it again, you would need to look in the event log to confirm whether or not it was rebooted by BP on Wed night. To me it looks like it *was* rebooted, based on the following two events.

Wed-20:47:16> COMPUTER ONLINE

Wed-20:47:12> COMPUTER OFFLINE

In this case you used ‘Reboot (force always).’ However, the ‘force’ method does not guarantee that the computer will return a ‘success’ message to indicate that it accepted and is processing the reboot command, which is why the ‘RPC server is unavailable’ or other error/failure messages can occur in that case, even when the machine is actually rebooted successfully. Generally speaking, I would recommend always using ‘force, if required’ which will always first try a normal reboot. It will only use ‘force’ if the normal reboot cannot be initiated. There is nothing wrong with using the ‘force always’ option, but since it doesn’t guarantee a return value, it can add confusion in the cases where it doesn’t return ‘success’ but still reboots successfully. This is not a BP issue. It’s how Microsoft designed the ‘force’ method.

The one piece of the puzzle that does not make sense is the Error 1623. This should be investigated independently because it normally should only occur if there is a pre-existing Windows Update process running on the computer. From your log there does not appear to be a previous attempt to initiate Windows Update, so it’s unclear to me why you would receive this error, unless you had already initiated Windows Update from a different BP grid. Considering that you already rebooted the machine and find that it is working properly/normally, there is nothing else really to do. We won’t be able to determine why that error occurred anymore.

-Doug

[doug]

We’re currently investigating this issue, which has been reported by one other user. I will update this thread when I have more information.

-Doug

[doug]

It has nothing to do with WMI, and there is nothing you can do to modify the behavior. Incorrect progress information is being returned by the Windows Update agent. We have no control over this. It should not happen with any regularity. It is something that we have only ever heard of on rare occasions.

That said, you should also look at the remote agent log and make sure that there weren’t failures during the download. If updates failed to download, that could be a legitimate cause for the incomplete progress bar.

[doug]

Yes, so currently there is only $computer for local commands, which pulls the host column value. However, in a future version we will likely add the ability to pull from a number of the other columns, such as $notes, $notes2, $description, $location etc. And they would be usable in not only local commands but also remote commands and get info commands.

-Doug

[doug]

We have plans for a solution to this problem in a future version of the app. I’m not sure exactly what the timeline for implementation/release is.

-Doug

[doug]

Thanks for clarifying. I had misunderstood your original question/request. That said, I would like to add my two cents now that I understand your question. What you’re asking to do, in my opinion, seems a bit odd and unnecessary. In fact, I suspect it will only cause you grief. The reason is because what you are trying to do is exactly what the Windows Update Agent already does. You don’t want to manually look through and compare every single installed update with the list of updates from Microsoft because that would be extremely tedious and time consuming. However, when you run Windows Update (either on the computer directly or through BatchPatch), the target machine compares what is currently installed on the machine to what updates are available. There is a lot of complex rule processing that occurs to deliver the final list of available updates. This ‘check for available updates’ action *IS* the verification, essentially. This is the process that does the comparison that you’re trying to do manually. The only caveat is that if you are using a local WSUS instead of Windows Update (or Microsoft Update), then it’s possible that you didn’t approve certain updates on the WSUS that should be installed on the target computer(s). If this is the case, then the best way to see what other updates would be available to the target computer(s) if you were not using a WSUS is to simply switch the ‘Server Selection’ in BatchPatch under ‘Tools > Settings > Windows Update’ to point to ‘Windows Update’ instead of ‘Default/managed.’ Then when you check for available updates in BatchPatch, the target computers will check against Microsoft’s servers instead of your local WSUS. The report of available updates that is generated will tell you what, if any, updates are needed by target computers. I hope this helps a bit.

Good luck.

[doug]

Note the Fault Module Name: swi_ifslsp_64.dll. This .dll belongs to Sophos Layered Service Provider (LSP). I believe this is the source of the problem. It’s not a BatchPatch issue.

-Doug

[doug]

Please review Troubleshooting common errors in BatchPatch

-Doug

[doug]

All you really need to do is highlight every computer in one grid/tab, and then run the report. This will give you a report for that entire grid/tab. Then go to your next grid and highlight every row, and then run the report. And so on.

I hope this helps.

-Doug

[doug]

No problem! Glad to hear that BP is working so well for you!

Thanks,

Doug

[doug]

For what you are describing you actually do not need to change the config on the target computers. Instead, I would recommend that you leave the config on the target computers as-is. Then in BatchPatch go to ‘Tools > Settings > Windows Update’ and change the ‘Server Selection’ value to ‘Windows Update.’ Then when you initiate a download/install action in BatchPatch, BP will instruct the target computers to check for updates on Windows Update instead of your local WSUS.

I hope this helps.

-Doug

[doug]

I think they are all ultimately from the same cause, which is that PsExec and PaExec are failing to operate successfully on that target. Under normal circumstances when these apps operate, they are able to create the target remote service/process, and when completed running, they are able to successfully remove the service. It sounds like this is not happening successfully for you. We have heard of this a few times, and it’s always just one or two problematic computers out of hundreds or thousands. Aside from switching from PsExec to PaExec or to an older version of PsExec (v 1.98 or earlier) and then switching back, we have not ever determined a definitive solution.

One other thing to try is see what happens when you run BatchPatch on a different computer. There was one case, if I am remembering correctly, where a problematic target stopped being problematic when the admin ran the BP console from a different computer.

-Doug

[doug]

Re-attach orphan was successful, indicating that the batchpatchremoteagent.exe was still running on the target. Normally it should complete within seconds or minutes, but in some rare cases the Windows Update Agent can take a very long time to return a result. In particular there have been tons of complaints all over the web to Microsoft about Windows 7 WUA taking way too long to run, but rarely does it happen with other operating systems. Win 2008 would have been a more likely culprit than 2012, but it sounds like in your case once you rebooted the target, it started responding properly/quickly once again. You will be able to switch back to PsExec and it should work just fine.

-Doug

[Author]

Posts