Forum Replies Created
-
Posts
-
Which version of BP is this? Version is printed in ‘Help > About’
If it’s crashing, there should be a crash report. Normally this would appear right at the time of crash on screen, but if not, please check the Windows application log (in eventvwr). Then share the details here.
Indeed it sounds like an issue with Windows, confirmed by the fact that you experience it with manual Windows Update directly on the machine even when not using BP. When you say that it hangs indefinitely, my first question is how long have you actually waited? We have not ever seen nor heard of Windows (or BP) not *eventually* completing. If I were in your shoes I would let it sit for up to ~48 hours before deciding that it’s not going to proceed any further. Back in the Windows 7/2008 days there were some situations where Windows could take that long to complete. While the particular issue that occurred back on those systems is not something that we have ever seen occur on more modern versions of Windows, I would still use that timeline of up to ~48 hours as a guideline for how long I’d wait in your current predicament before feeling confident that it truly will hang indefinitely. I would also check to make sure that disk space on the system isn’t low. And one other thing that I’d be curious about is approximately how old is the hardware where this is occurring, and is the CPU pegged at or near 100% during execution?
Which report is correct?
Both reports are correct. “Correct” in this case simply means that BatchPatch reported the actual results of the queries that it made to the corresponding databases on the target computer(s). Both history report options are provided in BatchPatch because Windows doesn’t store all update history in a singular location. Our goal is to give you the tools to see as much as possible, so we include both report options. We cannot make any assurances or guarantees about what will be contained inside of each report, as these databases are maintained by the OS, not by BatchPatch. BatchPatch merely queries the databases and reports the results. The behavior that we have observed in Windows is that after a new feature update has been installed, the history gets reset. If the Windows Update Agent history database lists a particular update as having been installed at some point in the past, then you can be confident that the Windows Update Agent did, in fact, install that particular update on the datetime that it logged the installation. However, it’s also possible that someone uninstalled the update at some later time or that a feature update installation or other cumulative update installation effectively reset the components in such a way that you don’t find other evidence of the particular .NET update currently being installed, most likely because the update was baked into a feature update or cumulative update that was subsequently installed, so it can no longer be differentiated as a singular/standalone update, or perhaps because .NET was removed altogether.
What is the command/query that each of these reports use to create these reports?
I can’t provide a singular command that you can use outside of BatchPatch because the queries in BatchPatch aren’t run as single commands like that, but if you want to learn to write your own script that queries Win32_QuickFixEngineering or the Windows Update Agent history, you can find plenty of examples in Google search results.
Hello – Please contact us directly for assistance with this.
You can’t query for a specific update that is not being offered to the machine. The filter works by enabling you to filter which available updates are shown. However, if an update is not available to the computer in the first place, you can’t use the filter to make it become available. The cumulative update each month replaces all previous cumulative updates. Windows will not ever offer a cumulative update from a previous month once the new month’s cumulative update has been published. This has nothing to do with BatchPatch. It’s part of how Windows functions nowadays. If you want to install a specific cumulative update that was released in a previous month, then you need to download the update directly from the Microsoft Update Catalog. You can then use the BatchPatch ‘Deploy’ functionality to deploy it to your systems.
Excellent. I’m glad that worked. Thanks for confirming.
Also see here for a second option: batchpatch-stuck-attempting-to-initiate-windows-update
Try again. Just go run the PsExec.exe manually one time. Make sure that there is only a single prompt appearing. Then uncheck the box and click ‘Run’. After that it will stop prompting UNLESS you have other dialogs that were still pending, and if any of those dialogs is accepted without removing the checkmark.
Or just run a single row inside of BP so that it prompts just one time. And then uncheck the box.
PsExec ‘Open File – Security Warning’
*Always ask before opening this fileTo resolve this issue, uncheck the box that says “Always ask before opening this file”. This is a Windows security prompt because the PsExec.exe file was downloaded from the internet. After you uncheck the box, it will stop prompting.
You can either post it to an image hosting site and link it here or you can contact us directly.
Can you show us a screenshot of the warning that you’re seeing? I’m certain that it can be disabled, but I’d need to see it first because at the moment I don’t know what you might be seeing, as this is not something that we see or that others are currently seeing/reporting.
If the BatchPatch scan completes then there *must* be a log of it on the target computer. Maybe you changed the default location. In BatchPatch check under ‘Tools > Settings > Remote Execution > Remote working directory’. This is the location on each target computer where the BatchPatch.log is stored. You need to review that log because it will show everything that BatchPatch did with searching/downloading/installing Windows Updates. You’ll be able to see there if BatchPatch failed to install an update or if BatchPatch skipped installation of an update because of a filter that you have applied.
You can also retrieve a different Windows Update history log in BatchPatch under ‘Actions > Windows Updates > Generate consolidated report of update history’. There are two different queries that should both be reviewed because they produce different results because these are being pulled from Windows, and Windows puts them in two different locations. However, it’s still important to review the BatchPatch.log as as noted above because that will contain the exact detail of what BatchPatch did.
Note, when you check on the server if the Windows Update control panel shows updates available, it will often show a cached query result. So if you install updates in BatchPatch and then check the server Windows Update control panel, the panel might still show that the update has not been installed simply because it didn’t refresh its scan results. SO then if you opt to install the updates there, it looks like it’s installing them even though they have already been installed.
If you continue to have questions or confusion I would suggest you open a support ticket so that we can more easily review log files etc rather than trying to post them to this forum.
I’m confused by what you’re describing. In your first posting you said that performing BP check for updates in offline mode returns no updates available and does *not* detect KB5032196 or KB5032197. Now in your most recent posting you’re saying that BP check for updates *does* detect KB5032196 or KB5032197, but when attempting to download/install BP says no applicable updates. Then you separately referenced KB031990, but when I try to find KB031990, I see that it’s not a valid KB ID. With all that said, I’m really confused about what you’re talking about, and I don’t know how to respond. Posting two seems to directly contradict what you said in posting one. And then you mentioned a KB that doesn’t exist, so it just doesn’t make much sense. If you continue to have problems or questions, please try to state everything again from scratch very carefully. And please be very specific and detailed about exactly which actions you are trying, which modes you are trying them in, and the exact text that BatchPatch is returning.
A couple of additional points to consider:
If the BP check for updates finds updates available but those updates are not downloaded/installed by BP when BP performs download/install, you can see the reason why they are skipped in the ‘Remote Agent Log’ column at the end of the action (or in the BatchPatch.log file on the target computer in the remote working directory (default is C:\Program Files\BatchPatch\BatchPatch.log)). It will say in that log exactly why an update was skipped. Generally, the only reason why the check for updates would find updates but then they wouldn’t be downloaded/installed during download/installation is because your filters are set to skip them.
Offline mode utilizes the WsusScn2.cab file that Microsoft releases each month in order to scan computers and report which updates are available. The offline mode scan file (WsusScn2.cab) will not produce identical scan results compared to what is offered via the standard Windows Update channel. For whatever reason this month Microsoft has not included some updates in the WsusScn2.cab file. It’s unclear if they will release an update to the WsusScn2.cab file this month (seems unlikely) or if they will just wait for next month to add the updates in question.
In all cases, we recommend that you only use offline mode in cases where computers actually do not have access to the internet or a WSUS.
As for the particular updates that you mentioned, to get them installed asap you can download them manually directly from the Microsoft catalog, and then you can deploy them to offline computers with the BatchPatch ‘Deploy’ action.
You should generally only need the 32-bit version of PsExec. However, as for your error it sounds like you have some corruption in the operating system. If you have missing or unregistered DLLs, that’s not usually a great sign, as it indicates that your OS is not in the state that it should be. Depending on the situation, I would suggest running BP from a computer that is known to not have any OS issues. If you can start with a fresh build, that would be better than trying to fix your existing build. However, if you want to start by fixing the existing build, then you could start with the system file checker SFC.exe or maybe do an OS repair procedure with the OS installation media.
We offer support only in English. For licensing issues, please reach out to us directly at BatchPatch Contact Form
There are a few things to consider…
If you reboot a target computer, BatchPatch will automatically start pinging it at the beginning of the reboot. And then BatchPatch will automatically stop pinging it when it comes back online, if there were X number of ping timeouts before it came back online, where X is defined under ‘Tools > Settings > Ping Status Alerts > Hosts are considered offline after X ping timeouts.’ The default value is 3, and it’s what should be used for most situation. However, in some cases if you are rebooting a virtual machine, the machine can reboot SO quickly that it’s back online before there were ever 3 timeouts. You can change this value to 2, if you want, and that might take care of it. But you don’t want it to be too low because then anytime there are two ping failures in a row, if a third ping is successful, BP will stop pinging the target. So generally we recommend leaving it at 3, but for VM environments 2 might be a better option.
If you manually started pinging the machine or you used “Start pinging” from within your job queue, then you might need to manually stop pinging the machine yourself. But even if you didn’t manually start the ping you can still always add “Stop pinging” to the end of your job queue, if desired.
Yeah that makes more sense 🙂
If you’re using the job queue to set the row color… then wouldn’t you just branch immediately after you set the row color? It would be weird and unnecessary for the queue to set the row color to red and then follow with “if row color is red…” because you already know the row color is red since you just set it that way in the previous step. Maybe I’m misunderstanding.
This looks very good and is helpful to see. Thanks for sharing!
FYI this isn’t a big deal but using start and stop pinging in the job queue isn’t really necessary. Pinging will automatically start when BP initiates a reboot, and it will stop when the host comes back online after the reboot.
You’re welcome.
Can you clarify what you’re doing? I’m just curious to understand. Since you can’t currently have the job queue branch based on whether or not there are any logged-on users, why do you need a goto to terminate the queue at all? I mean what is the goto based on? The job queue example that I showed in my previous posting above will terminate after step 3 runs. No need for a goto or a terminate queue step. If you can show me exactly what you’re doing or attempting to do, it will just help me understand your exact needs so that we can make the best decision moving forward about exactly what to add or not add to the various actions/options.
Thanks.
I wouldn’t be able to provide any further guidance. Your guess is as good as mine. What you’re trying to do is rather kludgy in the first place. I did see one example through Google searching of someone encountering the same or similar to what you’re describing, but just that one example with no solutions offered. The only thing I can think that might have an impact is the OS of the BP console computer as compared to the OS of the target. It might be that certain OS version/build combos between console and target could be the cause of the issues. Or maybe you have some type of HIPS/AV software on the target that is immediately shutting down the program that’s being executed?
I’m curious why do you want to remotely start an app in the logged-on session? What purpose does this serve? Maybe it would be better served with a logon script that runs on the target computer at logon without having to be remotely triggered? Similarly you can put a shortcut in the Windows startup folder to trigger any app to start when the computer is logged-on. This is typically how this would be accomplished, and it’s how we do it here for one of our servers that needs to run some apps at logon. It’s unusual to need to do it remotely, and if you’re trying to do it on many computers simultaneously then you’ll also have the extra issue of which Session ID to use for each target computer since they presumably won’t all be the same Session ID.
FYI:
The -d tells PsExec to not wait for the process to end before returning. Without the -d then BatchPatch will remain ‘Executing…’ indefinitely until the app is closed on the target computer.
The random exit codes that you’re seeing are normal… that’s what I see when I do it here and everything works properly. That seemingly random exit code is not an error code. It’s actually the PID (Process ID) of the remote process.
As you know -s tells PsExec to run as SYSTEM. If you remove the -s from your command and then instead change the Remote Execution Context in BatchPatch to SYSTEM, then BatchPatch will insert the -s into the command for you automatically.
Instead of using -u and -p directly in your command, if you specify alternate logon credentials for the row on BP (Actions > Specify alternate logon credentials), BP will insert the -u and -p with those credentials for you.
Thanks. We’ll consider the conditional logged-on users option. In the meantime, there is already the ability to send a custom message to logged-on users from the Job Queue. See lower-left corner ‘Saved User-Defined Commands and Deployments’ grid in the Job Queue window. Any saved ‘Send message to logged-on users’ will appear there.
You can already get just about everything you need/want right now by simply skipping the conditional check for logged-on users. Instead just do the following, which satisfies the desire to warn users, and still gets updates installed on machines where no users are logged-on yet:
JOB QUEUE:
Send message – Updates will be deployed to your machine in X minutes
Wait X minutes
Download and Install Updates Reboot if RequiredInteresting… so I just tested a bunch more options and was able to get it work. I’m glad you brought this up because I thought this was no longer possible. It used to work without anything special in the syntax, but starting with Win 10 it had stopped working like that. I discovered now that to get it work requires some extra care with the syntax.
Ok so in the past we used to be able to just execute a BatchPatch ‘Remote command’ with the interactive flag enabled in PsExec with -i. However, now the correct session ID must also be specified for the remote user.
In BatchPatch the ‘Remote Execution Context’ (under ‘Tools > Settings > Remote Execution Context’) can be set to either ‘SYSTEM’ or ‘Elevated token’ (I would recommend Elevated token for most uses), but in either case ‘Interactive’ must be UNchecked because the -i Interactive switch has to instead be added into the command directly.
Then in a BatchPatch remote command you can use this syntax below where 2 is the session ID of the target user (you can see the correct session ID in Task Manager process details on the target computer by adding the Session ID column and then looking for the value next to one of the processes that is being executed by the logged-on user. In my test machine right now it’s 2, but it might be something different in your situation):
-d -i 2 notepad-d -i 2 "C:\Program Files\Google\Chrome\Application\chrome.exe"=================================
For a BatchPatch deployment action you would need to modify the “Command to execute” field directly and insert at the beginning of that field
-i 2so that the entire field reads like this (with your own .bat filename and the correct session ID for your remote logged-on user:
-i 2 cmd.exe /c "test.bat"Everything is working as expected. Applications launched remotely will run hidden, not interactively, which is why you see the exe appear in Task Manager but the Chrome window does not appear to the logged-on user.
Microsoft made some changes recently that broke BatchPatch cached mode for Windows 11, specifically for certain types of Windows 11 updates– the ones that end in .psf and the ones that end in .wim, which will generally be the large cumulative monthly updates. We do not currently have a way to fix this, as the issue is in the Windows Update API itself, so Microsoft has to address it. Cached mode in Windows 10 also has a different but similar issue that Microsoft introduced some time ago. We do not know if/when Microsoft will address this for either Windows 10 or Windows 11.
To work around the problem, you can either enable online/non-cached mode in BatchPatch if the target computer has access to a WSUS or to Microsoft’s Windows Update servers, OR if the target computer does not have access to a WSUS or to Microsoft’s Windows Update servers you can instead just manually download the .msu version of the desired update directly from the Windows Update catalog at https://www.catalog.update.microsoft.com
Then when you have the .msu update file you can deploy that update to the air-gapped machines using BatchPatch’s ‘Deploy’ feature.
Create a new row for the sole purpose of sending an email notification. Schedule that row to run at a time when you know everything else will be done.
Alternatively, a more advanced option is to use the advanced multi-row queue sequence to trigger the email notification row to execute after everything else is done. If you search for ‘sequence’ on our main website tutorials section you can find examples for that, if interested.
Set the email body and attachment fields to $grid instead of $row. Then set just a single row to send an email notification instead of having all rows send one. When the single row sends the email notification, it will include the entire grid contents instead of just the single row contents (because of $grid instead of $row)
https://batchpatch.com/how-to-send-email-notifications-in-batchpatch
In the software under ‘Help > Check for updates > View change log’
The most recent published version of the app enables the ability to start an advanced multi row queue sequence from within a job queue