Forum Replies Created
-
Posts
-
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.
Well, it’s all relative. 70% of 0 is 0. But 70% of 64GB is ~45GB. So the real question is how much absolute memory is available, not how much percentage is available. I don’t know if adjusting the page file would have any impact or not because 32-bit systems only have a max of 4GB of addressable memory, and the OS is going to be using most of that, and it’s not really clear what’s happening under the hood with the Windows Update Agent that would cause the out of memory error to occur in the first place, and I don’t know the current size of your paging file or if it would change the outcome of what you’re encountering. As for producing reports, I hear ya. You can still see the history report under ‘Actions > Windows update > Generate consolidated report of update history’ so maybe that helps. But also try doing a fresh reboot of a target system and then immediately scanning after it comes back online, and see if that does the trick. Or try evaluating if there are any other RAM hogs that can be killed before doing the scan for updates. Etc.
The error is:
0x8007000E -2147024882 E_OUTOFMEMORYIf these 32-bit computers are memory-constrained then you could see if rebooting one and then immediately performing the scan right after that works (before memory gets hogged by anything else on the machines). However, that might not be a sustainable practice.
As a workaround I would suggest that since you are able to manually install the updates directly… just use the BatchPatch ‘Deploy’ feature to deploy those .msi files directly to target computers. This way you can still do it all quickly, and it avoids the scan process that is failing due to lack of available memory.
The offline WsusScn2.cab file is different each month, and it’s possible that each month it has different memory requirements to run. However, it’s also possible that the target OS memory usage increased after applying Windows updates a few months ago. Or maybe you installed some other app on those target systems a few months ago that increased their memory usage? Another option then might be to manually kill apps that are hogging memory before you do the monthly patching.
This is a little confusing to me because on the one hand you’re saying that you “use it a lot,” but on the other hand you’re saying it doesn’t work at all. If it doesn’t work, how could you be using it a lot?
As a start, you said you’re using “check if process is running” while then referring to just the *service* status after that, as opposed to *process* status. A service effectively is indeed just a running process, but I suspect you are mixing up service names with process names. If you use “check if process is running” then you’ll need to identify the name of the *process* that you want to check for. This is usually not the same as the name of the corresponding *service* that’s running the process.
Disabling won’t stop a ‘copy file/folder’ job. You’ll need to close the application altogether. We’ll look at adding functionality for stop/cancel in a future version.
For now you can create a remote command and add that to your job queue. The syntax of the command would be:
TASKKILL /F /IM "hungProcess.exe"I would suggest you follow all of the steps and links outlined at Troubleshooting Common Errors in BatchPatch
@all – The error you’re getting is because BatchPatch is not getting a response to WMI queries against the target computer.
The same info that I posted previously still applies. When BatchPatch executes a remote command with logged output (or a user-defined ‘Get info’ command) it will log the output to a file (BatchPatchRemoteProcessOutputXXXXXXXXX.log) in the remote working directory on the target computer. A BatchPatch deployment with ‘Retrieve console output’ enabled will log to a file (BatchPatchDeploymentOutputXXXXXXXXX.log) in the BatchPatch deployment remote working directory. Each command will log to a unique file (the XXXXXXXXX is a random number that’s appended to the file name, so each new command that is executed from BP gets a new random number assigned, which means that each new command gets a new log file created).
The content of logged output is limited to the output that a particular command produces. So for any normal/typical command, the output is tiny. The command runs on the target computer, the output of the command is sent to the .log file. When the command completes, BatchPatch reads the contents of the .log file and then deletes it.
If the .log file is excessively large then it indicates that one of the commands that you executed produced a massive output. I can’t imagine any command producing 66GB of output unless it contained an infinite loop, but perhaps there could be some other weird edge case problematic command that doesn’t contain a loop but instead just somehow creates 66GB of output because of some other reason or problem with the command. I don’t know.
If I were in your shoes there are really just a few things I would do.
1. I would check the ‘modified’ stamp on the file to see when it was modified, and then I would compare that to my BatchPatch grid to see if I could figure out which command created it. Then I would examine that command and test running it so that I could watch in real-time what it does and what it outputs.
2. If I can’t get a ‘modified’ stamp because the file has already been removed, I would do a general review of the BatchPatch grid and all the commands that were executed against that target computer, and then I’d see if I could reproduce it by re-executing those same commands/sequences in BatchPatch.
3. If I did have access to the file, I might try to see if I could read the file to get a sense of what’s in it, which might help identify what caused it to get so large. Since it’s so big it might be hard to read even with a program that is designed to read large text files (such as the app “Large Text File Viewer”), so I probably would not try to open it in any type of app that will attempt to display the whole file. It is probably better to explore with cygwin commands or something similar just so that you can read just single lines of the file without having to open the entire file in a text file viewer, which will likely be problematic. Or if you do any coding you could even write a little text file reader in C++ or C# that would be scan the file and spit out a line here and there just to see what’s in it, similar to what you could do with cygwin commands like to read the head and/or tail of the file.
Excellent. You’re welcome.
Thanks. We’ll look at adding this.
Create a local command in BatchPatch (‘Actions > Execute local process/command > Create/modify local commands‘) with the following syntax:
cmd.exe /c start \\$computer\c$or
cmd.exe /c start \\$computer\SomeOtherFolderYou will then see your local command under ‘Actions > Execute local process/command > Execute saved local command‘. You can also add a toolstrip button with ‘Tools > Customize visible toolstrip buttons‘. Just scroll to the bottom of the ‘Customize Toolstrip’ window and check the box next to the local command that you created.
This functionality already exists. The ‘add hosts from directory’ and ‘synchronize grid with directory’ options already let you select security groups in addition to OUs.
Based on what you’ve said, it sounds like the results showing in the Windows control panel are simply stale. BatchPatch shows a real-time picture of what’s available. Windows doesn’t. Please refer to reason number 3 on the list at the link above, and then follow the link and instructions there. Let me know how it goes.
Thanks. We’ll consider this.