Forum Replies Created
-
Posts
-
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.
There is not currently a shared repository, but you can export from one installation to import at another installation by using ‘Tools > Export’ and ‘Tools > Import’
Well I mean if you identify certain updates (either by KB number or by update title) in your staging environment that you are going to approve for installation in your production environment, you can simply use ‘Actions > Windows Updates > Filter > Include specific updates (textual)’ and then just paste your list right there.
Thanks for the suggestion. We’ll consider this for the next version.
This likely has something to do with SSL config and communication between the target and the WSUS. Have a look at the solutions provided at these two links:
https://faultbucket.ca/2012/08/windows-server-2012-windows-update-error-0x80240440
For other HRESULT values please see: https://batchpatch.com/batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
For other HRESULT values please see: https://batchpatch.com/batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
For other HRESULT values please see https://batchpatch.com/batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
Each sequence must have its own execution row. There is not currently a way to trigger one sequence to start when another has completed, but you can certainly just set it up as a single larger sequence that encompasses both of the smaller ones. If you want the completion of one sequence to trigger the start of another sequence, then it seems to me that’s what you really want anyway… I mean you really just want one larger sequence that encompasses the two individual smaller sequences. Why would you split it into two smaller sequences if the goal would be to have completion of one sequence would trigger the start of the other sequence? How is this different or better than just having a single larger sequence?
Make sure that ‘Tools > Settings > Remote Execution > Use psexec custom filepath‘ is pointing to psexec.exe and not pointing to batchpatch.exe
We have a handful of tutorials on the website:
https://batchpatch.com/advanced-multi-row-queue-sequence-video-tutorial
https://batchpatch.com/advanced-multi-row-queue-sequence
https://batchpatch.com/virtual-machine-guest-host-update-and-reboot-sequence-automation
https://batchpatch.com/patch-and-update-automation-with-multiple-dependent-systemsThe process works as follows:
1. First you must choose the action(s) that will be executed on each host/row when the sequence runs. The actions are assigned by using the regular job queue
configuration screen for each row that you want to include in the sequence. For this process you’ll select ‘Actions > Job Queue > Create/modify job queue.’ In
the Job Queue window you’ll choose your desired queue, and then finally you’ll click ‘Apply queue to row(s) without executing.’2. For all rows that you want to be part of a sequence, you’ll need to choose a sequence name. You’ll apply a particular sequence name to each host that is
included in a given sequence. With the sequence name you’ll also apply a sequence position number. Multiple hosts can have the same position number, if desired.
So, if you need to have one host execute an action, and then when it completes you need five hosts to all execute actions simultaneously, and then when they all
complete you need three other hosts to all execute actions simultaneously, you can do that by applying the following sequence position numbers:host1 YourSequenceName:PositionNumber1
host2 YourSequenceName:PositionNumber2
host3 YourSequenceName:PositionNumber2
host4 YourSequenceName:PositionNumber2
host5 YourSequenceName:PositionNumber2
host6 YourSequenceName:PositionNumber2
host7 YourSequenceName:PositionNumber3
host8 YourSequenceName:PositionNumber3
host9 YourSequenceName:PositionNumber33. For each sequence name you must create a sequence execution row. This is a special row that is designated for launching a particular sequence.
hostX YourSequenceName:ExecutionRow
4. When you’re ready to execute a sequence, highlight the execution row for the sequence you want to execute, and then choose ‘Actions > Job Queue > Execute
advanced multi-row job queue sequence.’ BatchPatch will find all rows that have the same sequence name as the execution row, and then BatchPatch will launch
the job queue for all rows set to position number 1. When all position 1 rows have completed their queues, all position 2 job queues will be executed. When
all position 2 rows have completed their queues, all position 3 job queues will be executed. And so on.————————————-
In your case you asked to make sure that the groups finish rebooting and come back online before the next group begins, so you could configure your job queue something like this:
Download and install updates + reboot always Wait 10 minutes Wait for host to be detected online
In the screenshot above the SQL group will perform its update/reboot/wait actions, followed by the APP group, followed by the WEB group.
————————————-
However, you actually asked specifically about having *only* the reboot portion be staggered, in which case you’d have to actually add all computers to the grid twice, then you’d have to apply two separate job queues, and then you’d have to combine them all into a single sequence, as shown in the screenshot below. However, I would recommend doing what I’ve described above, not what you described (below). That’s because if your goal is to prevent services from being affected and only having certain machines offline at the same time, then you probably should not install updates at the same time on all groups either because there are times where during the update installation process services could be taken offline by Windows. To be safe you should instead install updates on a single group and reboot that single group, then install updates on the next group and reboot the next group, then install updates on the last group and reboot the last group.
Anyway though… if you still want to perform the update on all machines simultaneously followed by staggered reboots, you can do it. For this you’d have two separate job queues. The queue for updating, which occurs in sequence position 1 is simply:
Download and install updatesThe queue for rebooting and waiting, which occurs in sequence position 2, 3, and 4 is:
Reboot (force, if required) Wait 10 minutes Wait for host to be detected online
More recently we’ve learned of two possible causes for this error. 1: If you are trying to apply updates to an operating system that Microsoft is no longer supporting and delivering updates for. If you have not purchased an Extended Security Update (ESU) package from Microsoft, you might need to do this. 2: You have not installed the most recent servicing stack update (SSU). Try manually applying the most recent SSU for the OS in question, and it’s likely this error will go away.
More recently we’ve learned of two possible causes for this error. 1: If you are trying to apply updates to an operating system that Microsoft is no longer supporting and delivering updates for. If you have not purchased an Extended Security Update (ESU) package from Microsoft, you might need to do this. 2: You have not installed the most recent servicing stack update (SSU). Try manually applying the most recent SSU for the OS in question, and it’s likely this error will go away.
I understand what you’re saying. It’s not clear to me why you would see a change after upgrading, as we have not observed that before, and Windows shouldn’t be making modifications that would lock you out. However, with Windows anything is possible. Even including a bug in the particular build of 20H2 that you have installed. Regardless, BatchPatch didn’t change during the upgrade, the target computer changed. And ‘Access Denied’ is always a permissions/authentication issue of some kind. Specifically, the error you are encountering is occurring when BatchPatch attempts to make a WMI connection to the target computer. I would suggest that you try the following things:
1. Log on to the target computer directly/manually with the same logon account that you are using to attempting to connect from BatchPatch. Just make sure that you’re able to log on successfully with the same username/password.
2. Since you are using a local account (not a domain account), check the registry values described in the section titled ‘Using Alternate Credentials with a Local Account’ at https://batchpatch.com/batchpatch-authentication-in-domain-and-workgroup-non-domain-environments Make sure the necessary registry values were not removed/modified during the upgrade process
3. Test out option 1 and option 2 instead of just option 3 at the following link to see if you experience different results: https://batchpatch.com/batchpatch-authentication-in-domain-and-workgroup-non-domain-environments Make sure the necessary registry values were not removed/modified during the upgrade process
4. This link has some further WMI troubleshooting steps to try that are equally relevant for BatchPatch because in both cases it’s just a WMI connection that is being attempted, so it doesn’t matter if that WMI connection is being attempted from BatchPatch or from a different app, it’s still a WMI query being made in all cases: https://community.spiceworks.com/support/inventory/troubleshooting/advanced-wmi-issues
5. If you have any type of anti-virus or HIPS or similar security app running on the target, check that too as a possible culprit. However, generally ‘Access Denied’ is virtually always something specific to Windows permissions/authentication
6. See if you have the latest build of 20H2 or if there is an update available. You can manually/directly check for updates at the Windows Update control panel of the target computer