Forum Replies Created
-
Posts
-
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
OK good. I’m glad that worked.
There’s no mailing list. You can see the changelog in ‘Help > Check for updates’, and when a new update is released BP will notify you unless you disable the check for updates at startup in the BP settings. If you disable it then you’d have to manually check using ‘Help > Check for updates’. Lastly, you can also follow us on FB (and still Twitter for the time being, at least). Links for those are also on the Help menu.
Hey Mike – I’m not sure what happened, but we were supposed to have a job queue item to check if a process is running with conditional branching/goto. However, somehow it didn’t get published, so we will plan on getting that into the next version.
In the meantime, instead of having your script just writing output of 0 or 1, have it actually return 0 or 1. Then you can use the job queue items “If previous action failed/errored (returned non-0), goto label:X” and “If previous action was successful (returned 0), goto label:X”
-Doug
Excellent. You’re very welcome. Thanks for confirming. I’m glad that worked!
-Doug
We have compiled them from a number of different sources over the years, so I don’t have a singular place that I can point you to right now. However, I’ll see if we can post some kind of master list. In the meantime if you google search for the HEX code you will find the meaning in the search results, but often not in the first handful of results. You need to dig down a bit further in the results list.
-Doug
What is the exact OS version number for the DCs according to BatchPatch ‘Actions > Get information > Get OS Version’ ?
How much RAM do they have installed?
0x8007000E -2147024882 E_OUTOFMEMORY0x8024000E -2145124338 SUS_E_XML_INVALIDThe first error suggests that there just isn’t enough RAM available on those target DCs. The second error is different, but I wouldn’t be surprised if that’s being caused by a memory shortage too, in this case.
Makes sense, though I can’t guarantee that we’ll even fix the RSS feed, depending on what the issue is. Maybe consider following us on FB or Twitter. Or keep a copy of the eval version of BP on your primary desktop, and then just launch it periodically to see if there are any updates. Thanks.
We’ll take a look. Thanks.
You appear to be describing an observation with the behavior of Windows Update that you’re encountering that doesn’t have anything to do with BatchPatch. If they were my systems, I would probably do nothing. My guess is the “issue” will disappear on its own. If you really want to “fix” it then you could try removing/renaming the SoftwareDistribution folder or maybe just the SoftwareDistribution\Download folder as a reset for the Windows Update components. Google for instructions on that, and perform those steps at your own risk.
We’ll fix the typo. Thanks for mentioning it.
I’m not really sure what your goal is. Why would you want to write an automation tool for this? What is the goal? What will your tool accomplish that is not accomplished in BatchPatch?
Starting within the last couple of months the download of the WsusScn2.cab is failing inside of BatchPatch because Microsoft changed the way the download link behaves which broke the existing download code inside of BatchPatch. It will be fixed in the next release, coming in the not too distant future.