Forum Replies Created
-
Posts
-
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.
First, unfortunately starting a few years ago we started frequently seeing the progress information delivered by Microsoft for various updates just not being accurate anymore. This seems to just be a matter of poor quality control at Microsoft that we sadly have no control over.
Second, it’s possible that you are encountering some kind of performance issue in BatchPatch, though based on what you’ve described as primarily a progress bar issue, the issue is most likely just number one mentioned above (unless it’s actually a combination of issues). However, with regard to BP performance… The one major factor that currently can affect performance in BP is when the volume of data in the BP grid has grown quite large over time. At a certain threshold, the grid’s performance can have issues. (We’re working on trying to improve this). If your grid size on disk is in the multiple megabytes vicinity (or higher), or if you simply have a large volume of data in the ‘All Messages’ column that grows each month because you save your grids each month and then just reopen them the next month and continue appending to them, then it’s possible that you are encountering a performance issue. The simplest way to rule out any performance-related issue is by just starting a brand new grid from scratch. If the issue still manifests, then you can be sure it’s related to the progress data from Microsoft (which we unfortunately have no control over). To keep your grids lean in the future, you can use ‘Actions > Clear column contents’. Or you can start a brand new grid from scratch and save it as a .bpt template file (‘File > Generate template file’ or save it normally as a .bps file and then manually rename it from .bps to .bpt). When you launch a .bpt template file in BatchPatch, it will always force you to save a copy of that grid instead of saving over the template. So if you launch the .bpt file at the beginning of your maintenance, then at the end when you go to save, it will make you save the grid as a brand new file so that the .bpt file is not modified at all. Then next month you can just launch the original .bpt again to start with a brand new grid again.
Hmmm. This is weird. The reason I’m confused is because when BP is “Attempting to initiate Windows Update…” it’s in that Windows Update action thread. During that “Attempting” phase, the BP Windows Update thread is trying to put some files on the target computer via SMB. When you abort or pause a job queue, the abort or pause flag on the job queue is set, but that flag is not looked at in the middle of any action. It’s only checked in between each step/action in the job queue. So setting “pause” or “abort” while the action is sitting on “Attempting to initiate Windows Update” wouldn’t have any impact on the Windows Update thread’s status while that thread is in the middle of processing since that thread is not checking the job queue “pause” or “abort” flags. It would only be after that thread completes that the “pause” or “abort” flags would be checked by the main job queue thread, which makes it confusing that pausing or aborting could have any impact on the progress of the Windows Update action.
Are you using ‘Alternate Credentials’ for the rows/hosts that are affected? Or are you using ‘Integrated Security’ where no credentials are being specified for the row and instead that row is relying on the account that was used to launch the BatchPatch.exe?
Are you using integrated security or alternate credentials?
To be clear, when you described using pause/resume on the job queue… are you saying that you literally are just clicking “Pause job queue” for the stuck row, and then a moment later “Unpause/resume job queue” for that row, and it immediately starts moving again?
Thanks.
Looks like just a delay/timing issue on Microsoft’s end. You’ll probably need to just try again until you get a successful download of the latest wsusscn2.cab file. I was just testing for the past little while without success, but then a moment ago I just got a successful download of the new wussscn2.cab file that has digital signature timestamp from just a few minutes ago (Thursday, May 11, 2023 10:50:59 AM), which means they *just* posted it. BatchPatch downloaded it and was able to scan for updates without issues.
We’ll consider this. Thank you.
Hello – This is not currently possible, but we will look at adding it in a future version. Thank you for raising it.
You can’t use alternate credentials to connect to the local computer. Remove the credentials so that BP uses integrated security (no credentials) to connect to the local computer. Generally if you want to put the local computer into BP as a target computer then you have to use integrated security (no alternate credentials) and run BP elevated as admin. If you don’t run BP as elevated in this scenario, you’ll find that some things work and others do not.
Thank you for the suggestion. We’ll consider this for a future build.
Thank you for the suggestion. We’ll have a look at this.
Not sure why that would be happening. It suggests that for some reason your download is getting corrupted. To workaround it, just use the link that came with your license to manually/directly download it via a web browser instead.
Excellent. No problem. Sounds like you have a very good handle on everything.
First I would just note that, in general, if they are supplying a list of approved updates, it doesn’t mean that an approved update will be applicable to a particular computer. So even if you change to a different update source, you might find that you still have the same result, and you still have to report back that certain “approved” updates are not installed (just because a vendor approved an update doesn’t mean the update is going to be applicable to every computer).
Second, offline mode may very well result in even fewer of the vendor-approved updates being installed because offline mode only includes security updates.
If they are giving you a list of updates, then after you go through your normal method to install whatever the WSUS presents, for remaining updates you could then go directly to the Microsoft Update Catalog to get them, and then try to deploy them directly (using the BatchPatch ‘deploy’ feature, if desired). Then see if you can even install all of them or not. My guess is that you’re often going to have updates on the vendor’s list that you can never install on some/all machines for the reason described previously (that is, where a list of vendor-approved updates is not necessarily going to be a list of *applicable* updates).
If you find that all of their approved updates are actually able to be installed, but that your upstream WSUS is simply not presenting them to the downstream server, then the best option is to just look at the upstream server and make sure it gets all of the approved updates so that the problem goes away. However, maybe you don’t have access to the upstream server, and maybe that’s why you’ve posted here in the first place. I don’t know.
Anyway… I don’t actually understand what your question/concern is about handling multiple BPURL files. The BPURL file is just a list of updates and update URLs for BP to download those updates. If you have two BPURL files, then you can just load one at a time to download the updates in them. The updates will be downloaded to the cache folder.
No, the downloading BP installation doesn’t need a separate license. In fact you could even do the downloading in evaluation mode.
For licensing issues please contact us directly.
I doubt that the file size itself is what’s causing the issue. I don’t think it loads the entire file into RAM. Also, the file size has been pretty similar for the past several months. The size cycles over time, so if you look at the historical sizes the way it works is the file size grows each month by a little, and then at some point it’s cut way down, and from there it begins growing a little each month again until eventually it’s cut back down again. The point is that while the file this month is about 800MB, a year ago it had gotten to 1100MB, and you weren’t having problems at that time. Anyway, you’re correct that the size of the file is not something that we have any control over. Microsoft distributes it, and it is what it is.