Forum Replies Created
-
Posts
-
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.
And yes, we will look at adding some type of additional warning. I think it’s already supposed to be providing such a warning, but this particular failure occurs in an unexpected way that broke our previously working download code altogether, so the failure wasn’t caught in the expected way and consequently did not warn properly.
@booster – If you have an older WsusScn2.cab file in the cache folder at the time you start the search for updates in offline mode, and then if BP fails to download the new file like it is currently doing, then if you review the ‘All Messages’ log you’ll see the following:
07/12 11:14:02> Windows Update: WsusScn2.cab file copy complete
07/12 11:14:02> Windows Update: Copying WsusScn2.cab file from local cache to target working directory…
07/12 11:14:02> Windows Update: Queued WsusScn2.cab file copy from local cache to target working directory…
07/12 11:14:02> Windows Update: Initializing copy of WsusScn2.cab file from local cache to target working directory…
07/12 11:14:02> Windows Update: Local download complete (Files downloaded: 0. Files located in cache: 1. Files excluded by filter: 0. Files initiated by another row: 0. Failures: 0)
07/12 11:14:01> Windows Update: Executing WsusScn2.cab downloader…
07/12 11:14:01> Windows Update: Queued WsusScn2.cab downloader…
07/12 11:14:01> Windows Update: BEGIN (Offline mode: Check for available updates)
07/12 11:14:01> Windows Update: Queued…You can see: Files downloaded: 0. Files located in cache: 1, which indicates that it did not download a newer WsusScn2.cab file but instead used the existing one that was in the cache folder.
Your best bet is to either remove the old cache file before doing a new run, or manually make sure you have the latest file in place before doing a new run, or just review the log for the line I mentioned above so that you can see if an older file was used or if a new file was downloaded.
This isn’t possible. BatchPatch and apps like it require the installer program to support a silent/quiet installation so that it can be executed remotely without any user interaction.
You can download it manually in your browser from http://go.microsoft.com/fwlink/?LinkID=74689
Microsoft recently made a change to how that download link behaves. This caused our existing code that handles the download to stop functioning properly, and it’s why you’re now seeing errors all of a sudden. It will be fixed in the next release of BP. For now please download it manually using the provided link, and then put it in your local BP cache folder.