Forum Replies Created
-
Posts
-
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.
No problem. Thanks.
@NotABot – Thanks for sharing. What this problem occurring for *all* .msu files or just a particular one?
If you check \\targetcomputer\C$\Windows\Fonts and you don’t see the same thing as when you go directly to the targetcomputer and look in C:\Windows\Fonts, then it sounds like you might have some kind of DNS or naming issue where you are actually looking at two different computers, not the same one. I can’t think of any other explanation.
OK so where things have been left is that PsExec v2.32, which is the current/new release, will work the same as previous versions of PsExec, when using SYSTEM remote execution context. However, when using ‘Elevated token’ in conjunction with alternate credentials in PsExec v2.32, you also have to now additionally use the -i (interactive) switch. In the next release of BP we will add this option as well.
Microsoft appears to be considering this change intentional, and not due to a bug after all. It’s unclear at this time if they will be making any additional changes in the near future, but all signs point to this being where things will be left, at least for now. It does not appear that they plan to release an update to replace v2.32 any time in the very near future.
OK so where things have been left is that PsExec v2.32, which is the current/new release, will work the same as previous versions of PsExec, when using SYSTEM remote execution context. However, when using ‘Elevated token’ in conjunction with alternate credentials in PsExec v2.32, you also have to now additionally use the -i (interactive) switch. In the next release of BP we will add this option as well.
Microsoft appears to be considering this change intentional, and not due to a bug after all. It’s unclear at this time if they will be making any additional changes in the near future, but all signs point to this being where things will be left, at least for now. It does not appear that they plan to release an update to replace v2.32 any time in the very near future.
OK so where things have been left is that PsExec v2.32, which is the current/new release, will work the same as previous versions of PsExec, when using SYSTEM remote execution context. However, when using ‘Elevated token’ in conjunction with alternate credentials in PsExec v2.32, you also have to now additionally use the -i (interactive) switch. In the next release of BP we will add this option as well.
Microsoft appears to be considering this change intentional, and not due to a bug after all. It’s unclear at this time if they will be making any additional changes in the near future, but all signs point to this being where things will be left, at least for now. It does not appear that they plan to release an update to replace v2.32 any time in the very near future.
1. What version of PsExec are you using? If you have version 2.21 or 2.30, go get the latest v2.32 from Microsoft (or get previous version 2.20 if you have it saved somewhere). PsExec versions 2.21 and 2.3 contain bugs, so you should not use those versions.
2. Then on the target system, look in the services console (start > run > services.msc). If you see an orphaned PsExeSvc service, stop it. Then delete it. (If you previously were using the -r switch by enabling it in BatchPatch Tools > Settings > Remote Execution > Use psexec -r switch’, then look for orphaned services under the name that you specified there instead of under ‘PsExeSvc’). You can stop the orphaned service(s) using the GUI, but then you can delete it/them at an administrator command prompt with the following command:
sc delete psexesvcor if you had specified a value for -r then it would instead be:
sc delete WhateverValueYouHadSpecifiedGoesHere3. Then on the BatchPatch computer make sure you are using the new PsExec v2.32 (or use the older version 2.20 if you have it, but do NOT use the version 2.21 or 2.30.).
4. If you are using PsExec v2.32, in BatchPatch go to ‘Tools > Settings > Remote Execution’ and select ‘SYSTEM’ for all.