Forum Replies Created
-
Posts
-
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.
For sales etc contact us directly at BatchPatch Contact Form
If the cmd is giving you the proper result, then I’m sure BP is too. However, because of the column size in BP it is wrapping to the next line. You can view the entire column contents by using the middle click mouse button in the cell or right click on the cell and choose view cell contents. Then you will see the entirety of the result instead of just the top line.
Thanks. What do you see if you run the wmic command at the cmd.exe command prompt *without* using batchpatch? What is the result in that case of just running the command manually?
Have you examined the setting under ‘Control Panel > All Control Panel Items > System > Computer name, domain, and workgroup settings > Computer description’? Have you made sure it matches this text? “Surface Book 2 – Rene de Vries”
The query you specified is the correct query to get the “Computer description” field from the target computer. This is the field that you see under “Control Panel > All Control Panel Items > System > Computer name, domain, and workgroup settings > Computer description.” This is *not* the same information that would appear in the Active Directory ‘Description’ field.
FYI we discovered that the Jan 12 PsExec update still has a couple of other bugs, so I’d suggest holding off on it still.
FYI we discovered that the Jan 12 PsExec update still has a couple of other bugs, so I’d suggest holding off on it still.