Forum Replies Created
-
Posts
-
The scheduler works across all tabs. I’m not quite sure what you’re describing. If you have an active support contract with us you should please contact us directly so that we can review your setup
There is not currently a credentials locker. We’ll consider this.
However, when you enter a username/password that needs to be applied to a group of hosts, you can apply that logon account’s credentials to numerous hosts in the grid at the same time by just selecting multiple rows in the grid before you click “OK” in the BP Credentials form. You don’t have to individually select a credential for each row. You can just do many rows at the same time, so long as all of the selected rows at any given time use the same credential.
You can search with ‘Grid > Find in grid’ or CTRL-F.
A filter option will be available in the next version, which we are hoping/expecting to publish in the next handful of days.
Hmmm… There is no such limitation that we are aware of or that has ever been reported or that we have ever encountered ourselves. I’m not sure what to make of this observation. My initial reaction is that maybe in your troubleshooting something seemed to indicate that it was a BP limitation/issue when in reality it actually turned out to be due to something else such as a setting or password policy or something like that on your computers? I think the only way that we could conceivably figure this out with certainty is if you could provide us with the exact password that you were using… or if you are able to reproduce it with a different password and then provide us with that different password. I wouldn’t want you to do this unless it’s not in use anymore, and also I would have you send it to us via email, not in the forum here. Then we could test that exact password to see if we can reproduce the failure. Maybe somehow a certain character or sequence of characters could possibly create a weird/unexpected interaction in BP? I honestly don’t know how this could occur, but weird/obscure bugs can/do occur, so it would be hard to rule it out with certainty until we can test a password that is known to cause the problem for you. Let me know if you want to try this. Or feel free to email us through the contact form on our main website, and we can go from there. Thanks.
I’m not sure what you’re asking. I need you to please clarify. For that matter, I’m also not sure what you’re describing about setting the local admin password too strong.
Anyway, if you specify alternate credentials in BP for a given row, you just input into the BP Credentials form the username and password that you defined for the particular user account on the target computer. There isn’t anything else special to do there.
I did a full scan and confirmed the following:
The repository generated by the Dec 2021 WsusScn2.cab file is 451GB.
The repository generated by the Jan 2022 WsusScn2.cab file is 467GB. It contains an additional 16GB of update files that are not part of the Dec 2021 repository.
Everything looks normal/correct/expected to me.
Hello – Can you clarify what you mean by “growth to x2 x2.5” ?
It seems like you’re trying to say that the size on disk of the repository has doubled? Is this correct. And what are you comparing this to? Are you saying that the January 2022 repository is double the size of December 2021 repository?
Also, you mentioned that Jan 2022 Microsoft has updated the offline scan file. Yes, Microsoft updates this file every single month. The fact that you mention this leads me to believe that maybe you have not been updating your scan file every month? And so are you comparing the repository size in Jan 2022 to some long time ago instead of to Dec 2021? It usually grows each month.
I did a quick scan, and it looks to me like the Jan 2022 repository is about 15GB larger than the Dec 2021 repository for the particular selections that you mentioned. Are you seeing something different?
You also mentioned a 2012R2 reboot loop issue. What does that have to do with the repository size?
Hello – There is not currently a CLI/API. We will consider this for a future version. Thanks.
First, check the Windows Update control panel on a target computer directly without using BatchPatch. Does the control panel show the same updates that you’re expecting to see based on what you are seeing in WSUS? The link below describes every possible reason why you might not be seeing updates in BatchPatch that you’re seeing in the Windows Update control panel of a given target computer.
BatchPatch and the Windows Update Control Panel Report a Different Number of Available Updates
Thanks. We’ll consider this.
Thanks. This is very helpful feedback.
Can you tell me specifically which menus you’re talking about? When you right-click on a row, the first menu that appears is the Actions menu. Is that the one you’d want to compact? Or is it a submenu of the Actions menu that you’d want to compact, like maybe the ‘Actions > Windows Update’ menu?
Thanks.
No. Are you running BP on a machine with a low resolution?
We realize the menus are not small. This is the tradeoff we made for us wanting items to be readily available without having to drill down multiple layers deep for commonly executed items.
We’ll consider this for a future build.
However, in the meantime you might consider customizing the toolstrip menu items. If you want you could put all of your commonly used items on the toolstrip, and then mostly avoid using the right-click menu altogether. See ‘Tools > Customize visible toolstrip buttons’
You can do this with BP. I would recommend using the ‘Advanced Multi-Row Queue Sequence’. It works in conjunction with the job queue to enable you to orchestrate a sequence across numerous hosts, with whatever dependencies etc. Here are a handful of tutorials/examples, so you can see how it works:
https://batchpatch.com/advanced-multi-row-queue-sequence-video-tutorial
https://batchpatch.com/advanced-multi-row-queue-sequence-contingent-operations-with-custom-scripts
https://batchpatch.com/custom-update-and-reboot-sequences-for-multiple-computers
https://batchpatch.com/virtual-machine-guest-host-update-and-reboot-sequence-automation
https://batchpatch.com/advanced-multi-row-queue-sequence
If, as you mentioned, this would all be much easier to do with a script, what role would you have BP play at all? I mean in that case why not just do it all with a script and not involve BP at all? I’m curious to understand what you had in mind for the role that BP would play (I mean if BP had a CLI/API). It helps for us to understand this kind of thing so that when we are deciding on new features etc, we have an idea for the expectation people have for how things would work. In the particular case that you described, I think perhaps you just weren’t aware of the advanced multi-row queue sequence, which will enable you to do the things that you described. However, if after reviewing the advanced multi-row queue sequence functionality you still believe that your process is better suited to all be manually scripted, then I’d be interested to know specifically which actions you would have BP performing in that process vs which actions you would find preferable to not use BP for. Thanks.
BP does not support command line arguments. There is no API.
That said, BP can handle a lot of dependency situations etc, generally with much more flexibility than an external scheduler. If you describe specifically what you’re trying to do or accomplish, I can let you know if/how you can do that in BP.
I would start by rebooting the BP computer and then try again with just a single row and see what happens. It’s unclear to me what would be causing this aside from an OS CPU/thread bottleneck of some kind.
No, there isn’t debug logging that will provide more info on this error.
Are you using integrated security or are you specifying alternate credentials in the row?
Is the target computer on a domain or is it standalone/workgroup?
Are you able to successfully use ‘Actions > Get information > Get last boot time’ in BatchPatch for that same target computer or does it produce an error too?
Are you able to successfully use ‘Actions > Windows Updates > Check for available updates’ or does that produce an error too ?
I’m honestly not sure how else to explain it. There are two different files. There is PsExec.exe and there is PsExeSvc.exe. PsExec.exe runs on the BP system. PsExeSvc.exe runs on the target systems while an action is executing. The -r switch effectively enables you to change the name of the PsExeSvc.exe to something else, such as BPExeSvc.exe, when it runs on target systems. But for the sake of this discussion, forget about the -r value for a moment. The point is that there are two files. PsExec.exe on the BP system, and PsExeSvc.exe on the target systems. You keep asking if -r is a veil for PsExec.exe, and what I keep trying to describe to you is that -r has nothing to do with PsExec.exe on the BP system because -r is there to change the name of PsExeSvc.exe when it runs on target systems.
Whether or not your protection application will flag PsExeSvc.exe in the same way that it flags PsExec.exe is not something that I can tell you. You will need to test it. PsExec.exe and PsExeSvc.exe are two different files, but PsExeSvc.exe is contained inside of PsExec.exe, so there certainly could be overlap when it comes to a detection algorithm looking at them, but it’s by no means a guarantee. With all that said, from what we have seen, these detection systems are generally not at all sophisticated. Even with PsExec.exe containing PsExeSvc.exe inside of it, it’s still very possible that PsExeSvc.exe will bypass detection. Furthermore, in cases where PsExeSvc.exe does *not* bypass detection, using the -r switch to change the name will in 90% of those cases actually cause detection to be bypassed due to the lack of sophistication in how the detection works in most applications. While your test of renaming PsExec.exe to readme.txt does not enable readme.txt to bypass detection, you should definitely still test PsExeSvc.exe both with and without -r to see how it behaves and if your detection system detects it when it’s PsExeSvc.exe and/or if it detects it when the -r value has been used to rename it to something else such as BPExeSvc.exe or whatever. We simply don’t know enough about exactly how your application will perform detection of these files, and we don’t know exactly what’s happening under the hood of the renaming process when using the -r value, and this is why it’s important to test it. We could go back and forth on it all day long, but until you test it, you won’t know the bottom line.
We haven’t ever heard of this or seen this error, but I suspect it’s not a very commonly used feature/function. I’m not sure why it isn’t passing through a reason… we can look at improving the error handling, which would help troubleshooting. That said, my guess is that if everything else in BP is working fine, then there is some type of permissions issue specific to viewing events on that target, so I would start by assessing permissions. Also try to connect remotely without using BP. I mean open Event Viewer on the BP computer, and then inside Event Viewer on the BP computer try to use the “Connect to Another Computer” option by right-clicking on the upper-left tree view where it says “Event Viewer (Local)”. See if you can connect to the target computer that way. If it’s not successful, maybe it provides a more detailed error.
To be clear… I’m making no comment about how your system detects the file. I’m just telling you the files that are involved and their names and where they run. You’ll have to assess if and how your system identifies the files in question.
There is a file, PsExec.exe, that runs on the BatchPatch system. On every target system there will be a different file that runs, which is named PsExeSvc.exe. If you use the aforementioned setting to specify a new name for PsExeSvc.exe, then on target systems you won’t see PsExeSvc.exe but rather will see it named BatchPatchExeSvc.exe or whatever you choose to call it.
PsExec.exe runs on the BatchPatch system. Its remote agent, PsExeSvc.exe, runs on target systems. In BatchPatch if you use ‘Tools > Settings > Remote Execution > Use PsExec -r switch’ which is both recommended and is also the default setting, then instead of PsExeSvc.exe running on target systems, BatchPatchExeSvc.exe will run on target systems (or whatever name you input in the aforementioned setting box).
106G means that the target computer was able to communicate with the WSUS, but the search was not able to complete properly. In the past we have only ever seen
HRESULT -2145124338 => 0x8024000E WU_E_XML_INVALID Windows Update Agent found invalid information in the update's XML dataHowever, in your case you’re seeing
HRESULT -2145116137 => 0x80242017 WU_E_UH_NEW_SERVICING_STACK_REQUIRED The OS servicing stack must be updated before this update is downloaded or installedMore info at the following link, but I think your easiest option is probably to run Windows Update one time with the server selection in BP set to ‘Windows Update’ or ‘Microsoft Update’. After installing updates that way and rebooting, your check for updates against the managed WSUS should work. If for some reason that doesn’t work then you’ll likely need to locate the standalone servicing stack update that your machines need in the Microsoft Update Catalog directly. Then install it manually or with the Deployment feature in BP.
If you have an active support contract with us please contact us directly for further troubleshooting. We’ll need to see more details to assess what’s going on.
@huibw – The issue described by @ariehm was not with deployments, so I’m not sure it’s the same issue that you are encountering.
The version of PsExec shouldn’t matter so long as the ‘Remote Execution Context’ is set properly to use either Elevated Token AND Interactive together, or use *just* SYSTEM (without Interactive). If the settings I just mentioned aren’t working, then it seems like there might be an issue with the actual deployment configuration. Not every deployment can be used successfully with ‘Retrieve output’. Are you saying that the deployment that used to always work with ‘Retrieve output’ no longer works with ‘Retrieve output’ or are the deployments that used to work with ‘Retrieve output’ not the exact same deployments that you are currently having trouble with? Also, do the deployments work if you uncheck ‘Retrieve output’ or do they still fail? It would also be helpful to see an example of the actual, verbatim error message that you are seeing.
Thanks for reporting back. I’m glad you got it worked out!
The filter list that you said you saw in a video still exists. It’s the same as what I described previously: ‘Actions > Windows Updates > Filter > Include specific updates (textual)’.
The URL list is not what you are looking for. That’s for cached mode and is for downloading the updates from Microsoft when your machines are in an offline environment ( https://batchpatch.com/cached-mode-and-offline-updates )
Anyway, I think you might be overthinking this whole process. All you need to do is identify the updates in your staging environment that you want to apply to your production environment. Then just make a list of those KBs. You can even just copy them using CTRL-C directly from the KB column from the ‘Consolidated report of available updates (with filters applied)’. Then paste that list of KBs into ‘Actions > Windows Updates > Filter > Include specific updates (textual)’ for your production environment.
With regard to the exact list of updates that have been applied… the list of updates that are included in a filter are not necessarily the updates that will be applied when you do an “install” operation because updates that are applied/installed have to be applicable to the machine in the first place. IF you apply a filter that includes KB123456 to a computer where KB123456 is not applicable, then KB123456 will never be applied to that computer. You can use the consolidated report of update history to report on the updates that you have actually applied/installed per-machine with BP. Additionally with regard to a consolidated report of available updates with filters applied, you can save that list from the staging environment simply by using the ‘Export’ menu item in the top left corner of the window that you see when you use the ‘consolidated report of available updates with filters applied’ action. You can export the list right there… you just cant import it into a different group of computers in your production environment because that list is specific to the computers where it was applied. If you import it in production it won’t apply to any of the machines there because they are different machine. Hence why it’s a “manual” operation to determine which updates you want to apply to a filter for a whole different group of computers. If the list of updates in staging is essentially the same as production, then you can just copy and paste the list to apply to a new computer (or use the method described in my previous posting above whereby you just launch the .bps file for staging in your production instance of BP. Then you can “transfer” the filter from one row to another by highlighting a row, opening the BP filter window, then highlight the rows in production that you want to apply it to, and click ‘Save’)
Possibly
There really isn’t anything more manual actually. If you identify updates in your staging setup that you have applied to your “filter”, you can just go to the ‘Download/install filter’ column in BP and copy that list from there. Then paste that list into the filter in the production environment. There isn’t a formal export/import option for this list because it’s applicable on a per-machine basis not globally, and you won’t have the same machines in the staging environment as the production environment. So you’re talking about taking the filter list from one machine, and applying it to another machine. So this isn’t something that we would like turn into an export/import type of thing because there isn’t really anything to export or import since it’s all specific to individual targets. You could, if you want, just take the .bps file from the staging environment and load it in the production environment. Then you have all of your filters that you have applied to each row in the staging environment right there. You can then select a row in that staging grid which has been loaded into the production instance of BP, and launch Actions > Windows Updates > Filter > Include specific updates (textual) with that row selected. You’ll then have the filter list populated in the GUI, and you can simply now select a different row (or group of rows for target machines in your production environment) and apply/save the filter there.