Forum Replies Created
-
Posts
-
They’re all sortable by name already. I’m not sure what you’re doing. For example, go to ‘Actions > Deploy > Create modify’ and in the ‘Saved Deployments’ grid on the right side of the window you can organize your commands by sorting them and/or by making them either visible or invisible in the BatchPatch action menus.
Yes. If you select “Include Upgrades” to install a feature update, then BatchPatch will not be able to install any “regular” updates until you de-select the “Include Upgrades” box and re-select the other classifications. For the other classifications we generally recommend selecting the entire left-hand column of classifications:
Critical
Security
Definition
Updates
Update RollupsCorrect. If you leave it set to “Search for only optional software updates” then moving forward it’s not going to find any regular updates and will only find optional updates, which generally we do not recommend installing except in cases where you specifically need one like you did in this particular instance.
Excellent. You’re welcome.
Go to ‘Tools > Settings > Remote Execution’ and uncheck the ‘Interactive’ boxes. That should do it. Please let me know if it resolves the issue.
Thanks.
It looks like this is being delivered as an “optional update” through the normal Windows Update and Microsoft Update channels. This means that in addition to deploying the KB directly as a standalone .MSU file using the instructions at the link you posted above (using the standard BatchPatch deployment method), you can also use the normal Windows Update actions in BatchPatch to deploy this, but you’ll have to first go to ‘Tools > Settings > Windows Update’ and check the box for “Search for only optional software updates”
It appears that the current version 2.32 doesn’t actually fix the root issue, so while the original PoC for the LPE doesn’t work on 2.32, the researcher who found the issue was able to quickly modify his PoC to work on 2.32. That said, we believe Microsoft is now working on another update, so it might make sense to wait for that to be released, but of course this is up to you. As an alternative you could also use PaExec if you want. With PaExec, if you specify alternate credentials (not an issue when using integrated security), it obfuscates but does not encrypt them when sending them across the network. While this is not optimal, it’s also not necessarily a deal-breaker, but there’s a tradeoff to consider. You can read more on that tradeoff here: https://batchpatch.com/psexec-v2-1-all-network-communication-is-now-encrypted
As for updating… You can just replace the psexec.exe on your computer with the new one (though you should keep a backup of the old one too in case you want to revert to it). Or you can use ‘Tools > Settings > Remote Execution > Use psexec.exe custom filepath’ to point BatchPatch to any version of PsExec or PaExec you want.
I don’t know how you have “downloaded and staged the install” …
However, I can tell you that BatchPatch can apply feature updates in two different ways, either by using the built-in Windows Update actions (make sure the update classification ‘Upgrades’ is checked under ‘Tools > Settings > Windows Update), or by using a deployment with the ISO media:
Please contact us at https://batchpatch.com/contact
You can enable sorting under ‘Tools > Settings > Grid preferences > Enable row sorting’
Hello – First, in case you didn’t see these, here are some links that demonstrate how to send email notifications in a few different ways:
https://batchpatch.com/how-to-send-email-notifications-in-batchpatch
https://batchpatch.com/using-email-notifications-to-check-status-of-automated-patching-events
With regard to your question, I’m actually not quite sure I understand what you mean. A row is not a part of a job queue. Rather a job queue can be saved in the global saved job queues list and then later executed for a row in a grid… OR a job queue can be directly applied to a row in a grid and be saved there instead of (or in addition to) the global saved job queues list. Maybe you applied a job queue directly to a row? And you’re asking how to undo that or clear the job queue from that row? One method is to go back to the job queue window and just apply a new queue to the row and overwrite the old one. It can be another queue or an empty queue. Another option is to clear the job queue contents from the row using ‘Actions > Clear column contents’ for the desired row.
Very intersting! Thanks for the update. I’m glad you got it working. I don’t have any good ideas for why the original method would have stopped working. It’s particularly strange that it would stop working with a 2250 exit code and yet the run-as method works properly. Doesn’t make a lot of sense, but glad you have a solution/workaround.
The “update reboot cycle” was really just a limited BatchPatch job queue. It was deprecated for years and finally removed in version 20200924. You can get identical functionality plus a lot more customization options in the BatchPatch job queue.
Tutorial: https://batchpatch.com/update-reboot-cycle-with-the-batchpatch-job-queue
The command runs under “Remote process/command (logged output)” not “Remote process/command”, so that’s expected/good. I just wasn’t certain if you were using that command for every try, so I wanted to cover all possibilities just to be safe. I would suggest leaving “Remote process/command (logged output)” set to ‘Elevated token’, and you should be good to go.
Thanks.
Please look at ‘Tools > Settings > Remote Execution > Remote Execution Context’
Try the following ‘Remote Execution Context’ settings for ‘Remote process/command’ and ‘Remote process/command (logged output)’
SYSTEM
SYSTEM + interactive
Elevated token
Elevated token + interactiveDo any of the 4 options work?
Good, I’m glad that worked.
It’s good/fine to leave it that way. Actually ‘SYSTEM’ without interactive, is the default setting in the most recent version of BP for ‘Deployment’ because as of today, we think this is probably the most compatible option for deployments, in general. However, it’s possible that you could encounter a deployment in the future which requires ‘Elevated token’ instead.
Excellent. Glad you got it worked out. Thanks for explaining what the issue was. This is helpful. Essentially the issue is that when “force IPv4” is enabled BP has to do an explicit DNS lookup, otherwise it can end up pinging the IPv6 address (if IPv6 is enabled). However, when entering an IP address directly into BP as a hostname, obviously that should always be able to work regardless of the “force IPv4” setting, and a DNS lookup should not be required, so I think we can make an adjustment to the code that will take care of that. Presumably the problem in your case was specifically tied to the stale PTR record. My guess is that *just* having the stale A record wouldn’t have caused the issue. Regardless, I think we can make an adjustment to the code to at least ensure that an IP that is input directly into BP will never do the lookup.
When you unchecked it… did it ping the IPv6 address or still IPv4 address?
Also… see what happens if you toggle the setting ‘Tools > Settings > General > Force pinger to always use only IPv4’
It’s really unclear to me how or why this could happen. I can only make the same suggestions that I made above… (you didn’t mention if you tried any/all of them) … with one addition:
*reboot the BP computer
*re-add the target computer to BP from scratch in a new row
*add the target computer by IP instead of name
*add the target computer by FQDN instead of short name or IP
*check to see how many network adapters are on the computer. if there are multiple adapters, disable any adapters that are not currently in usePlease report back and let me know if any of these does the trick. While I don’t have any other suggestions to make at the moment, it will be helpful for us to know if any of these things works.
Oh and yes, if the target process is still running but BatchPatch has been closed or the network connection has been severed between BP and the target, then yes you can use ‘reattach orphan’ to reconnect and get the active progress back. Under normal operating conditions BatchPatch will not lose connectivity to the target. Really this would typically only occur if BP was closed by you or if a network disruption severed the connection from BP to the target.
Chris – Maybe I am misunderstanding the issue that you’re having? If BatchPatch loses the connection to a target computer, BatchPatch will report an error. If BatchPatch still says “Executing…” then the process is still running, and then you should wait for it to finish. If BatchPatch completes the update process and initiates the reboot, then you will see that BatchPatch has initiated the reboot, regardless of what the progress bar says.
With all that said, your initial posting seemed to say that the BatchPatch progress bar is showing less than 100% even though BatchPatch has appeared to complete the update process and already initiated the reboot. But your most recent posting seems to suggest that’s not what you’re experiencing at all. Could you please clarify/elaborate? I don’t know if I am simply misunderstanding what the problem actually is. If you prefer, feel free to reach out to us directly at https://batchpatch.com/contact to share screenshots and grid exports etc to help illustrate the issue, if that would help. Then we can work directly via email instead.
Thanks,
DougBatchPatch gets the progress information from the Windows Update Agent (WUA) on the target computer. We used to very occasionally see instances where what you are describing could happen. It is not due to an issue in BatchPatch but rather is due to the WUA notifying completion without ever setting progress to 100% (When functioning properly/normally, it sets progress to 100% first, then marks the completion bit second). We haven’t seen or heard of this happening in a long time, and when it did happen, it seemed to be specific to certain updates. That said, if you haven’t seen it prior to now, my guess is it’s because there is a particular update that is causing it this month, and that you probably won’t see it again next month. It might also be that we haven’t seen or heard of it in a long time because Windows 2012 R2 is 3 years past mainstream end of support, and that the problem primary occurred in Windows 2012 R2 and older OSes. Long story short is I wouldn’t stress too much over this issue. I don’t think there isn’t anything you can do on your end to modify the behavior. Is this the first month that you have seen it occur? Are you using a relatively recent version of BatchPatch?
-Doug
Error 1603: A fatal error occurred during installation.
Windows Installer is attempting to install an app that is already installed on your PC.
The folder that you are trying to install the Windows Installer package to is encrypted.
The drive that contains the folder that you are trying to install the Windows Installer package to is accessed as a substitute drive.
The SYSTEM account does not have Full Control permissions on the folder that you are trying to install the Windows Installer package to. You notice the error message because the Windows Installer service uses the SYSTEM account to install software.Please check ‘Tools > Settings > Remote Execution Context’ in BatchPatch. What is your Deployment context set to currently? Is ‘Interactive’ checked? Please try unchecking it and see what happens. If no luck, please try the following different combinations and let me know if any of them is successful:
1. SYSTEM
2. SYSTEM + Interactive
3. Elevated token
4. Elevated token + InteractiveSo you’re saying that up until recently this problem didn’t occur? Did you update Windows version or similar upgrade on the DCs? Did you change accounts that you’re using to do the patching? Did you change the server where BatchPatch is running? Did you switch from integrated security to alternate credentials? Different version of PsExec? Different version of BatchPatch?
What version of BP are you running? What version of PsExec are you running? What version/build of Windows is BatchPatch running on? (you can use ‘Actions > Get info > Get OS version’ to get the full details). What version/build of Windows are the DCs?
2250 is an error that we very rarely hear about. It translates to:
ERROR_NOT_CONNECTED 2250 (0x8CA) This network connection does not exist.Try enabling ‘Tools > Settings > Remote Execution > Use PsExec -r switch’ if it’s disabled, or disable it if it’s enabled. In general we recommend that this switch be enabled, but as a test, try the opposite of your current setting to see if anything changes. If no difference, then put it back to enabled (enabled is generally better than disabled). You can use a name like ‘BatchPatchExeSvc’ or whatever custom name you prefer.
It’s worth also trying FQDN or IP address instead of NetBIOS name.
Additionally, try integrated security instead of alternate credentials… this means that you would launch BatchPatch using run-as, so that it’s running as the user that has administrator privileges, instead of adding “alternate credentials” for the host/row inside of the software.
Have a look at the following link for more info:
https://batchpatch.com/troubleshooting-errors-1611-64-1620-64-1611-2250-1620-2250Additionally, consider going through the steps in this guide to see if you can pinpoint where things are failing: https://batchpatch.com/batchpatch-troubleshooting-guide
You could also try PAExec (free open source clone of PsExec) and see if any difference. In ‘Tools > Settings > Remote Execution’ you would change the ‘Use psexec custom filepath’ to point to the PAExec. Please note that when using ‘alternate credentials’ (not when using ‘integrated security’) PAExec sends them over the network obfuscated but not encrypted) PsExec (v2.x) encrypts them.
Thanks.
Thanks. We weren’t aware that anything had changed in 1809, so thanks for letting us know. What is your powershell deployment method? What is it doing differently?
You can review the change log under ‘Help > Check for updates > View change log’
Yes, in today’s release.
The way to do this is with the job queue. Create (and save) a job queue that includes the items you want to execute. Then you can execute the saved job queue in a single click whenever desired. Note, ‘Get logged on users’ was not included in the job queue until the new version of BP that we released/published today. The other items you mentioned were already available in the previous version.