Forum Replies Created
-
Posts
-
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.
On January 12 2021 another PsExec update was published that fixes the 32/64 bug, so now the standard psexec.exe (32 bit version) works as expected.
On January 12 2021 another PsExec update was published that fixes the 32/64 bug, so now the standard psexec.exe (32 bit version) works as expected.
Thanks. Also just FYI for anyone else who reads this thread, the 64/32 bit weirdness appears to be a bug in the new version 2.3 of PsExec. At the moment it seems that you have to use the 64 bit version for 64 bit targets, and the 32 bit version for 32 bit targets. We believe this is not a “feature” but rather is a bug, so we are anticipating a fix/update from Microsoft/Sysinternals.
Thanks. Also just FYI for anyone else who reads this thread, the 64/32 bit weirdness appears to be a bug in the new version 2.3 of PsExec. At the moment it seems that you have to use the 64 bit version for 64 bit targets, and the 32 bit version for 32 bit targets. We believe this is not a “feature” but rather is a bug, so we are anticipating a fix/update from Microsoft/Sysinternals.
Interestingly, in testing we just discovered that while psexec.exe v2.3 throws the aforementioned error on our test machines, psexec64.exe v2.3 does not have the same issue.