Task sequence logs seem to have changed with MECM CB version 2203

[fj40ratt]

Good afternoon all.  Hopefully I'm not going crazy here but I recently updated MECM to 2203.  In the past if my memory serves me correctly, the smsts.log files used to display the individual steps within the TS groups and whether they were successful or not.  I have a step in one of my groups that runs a script to add devices to automatically add the device being imaged to the collection I have my Bitlocker policy deployed to.  Since the upgrade, that step has stopped working or at least the newly imaged laptops are not getting automatically added to the collection anymore.  When looking at the smsts.log file on the device, there is no reference to that particular step or any of the other steps like I've seen in the past.  Did that information get moved to a different log?  I did enable the TS debugger feature during the upgrade.  Is that why I'm not getting the detail I'm used to?  Thanks.

[anyweb]

chances are you are not seeing the step as it has rolled over, as you have not provided any relevant logs it's hard to determine the issue,

so....

 

if you want us to dig deeper, zip up ALL your smsts*.log files and attach them here, we'll take a look

[fj40ratt]

That's just it.  There are no rolled smsts.log files.  Only the one.

smsts.zip

[anyweb]

the last step it runs is installing some applications,

 

Installing application 'Base Office 365 2019 v1902_SA_(Build 14131-20278)'

does this app restart the computer unexpectedly ?

after that it seems to have issues, i'm guessing your step occurs after this point ? can we see a screenshot of your task sequence with the step you are expecting to run ?

 

[fj40ratt]

So I found where it is failing, just can't figure out why.  For over a year now the vbs script that adds the laptop to my bitlocker policy collection has worked flawlessly.  Now all of a sudden it is throwing an access denied error when attempting to run the script against my site server.  The account used to run the script within the TS hasn't changed or it's password.  Only change I know of is I upgraded SCCM to the latest version.

[anyweb]

is the password defined in a variable in the task sequence, if so, re-enter it

[fj40ratt]

I did.   Still the same result.  It's almost like this months Windows server security updates are causing my grief.  Two Windows updates were installed this month.  KB5010460 on 7/12/22 and KB4486129 on 7/8/22.  I upgraded SCCM on 7/11/22.  It doesn't mean the problem wasn't happening before that but I was not aware of it until after the 11th.  My field techs are pretty good about letting me know when things aren't working that are typically automated, believe me.

[fj40ratt]

This is the TS section that fails.  The vbs script is one I pulled from online.  I can share the script if necessary.

[anyweb]

yup please share the script and i can test it in my lab, if you want email it to me niall@windows-noob.com

[anyweb]

looking at your error, the actual problem is connecting to the root\sms namespace to find the provider location

take a look at this see does it give you some pointers

https://docs.microsoft.com/en-us/troubleshoot/windows-server/system-management-components/sms-administrator-console-connectivity-issue

 

if it doesn't help try disabling the DCOM hardening.

https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c