fj40ratt

The DCOM hardening link up above doesn't work.

Script attached. Like I said, all of this was working before the 2203 upgrade. Still digging on my end. Thanks for all of the help. AddMeToCollection.vbs

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

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.

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.

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

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.

In my case with 20H2 there was still a pending cumulative Microsoft update KB5014699 that needed to be installed. After installing that update, I was able to connect through the admin console.

Having the same issue but what is really odd is most of my folks are still running 20H2 and their consoles work just fine.

Hey everyone. Hoping someone can help me with this. I have been working from home since Covid started. I have a laptop I carry back and forth with me when I do need to go into the office but I also have a laptop permanently sitting on my desk that I remote into for large jobs. Both laptops have no issues running the Admin console. I recently convinced my boss to get me a high end machine to park on my desk to run multiple VMs so I don't have to spend my days logging on and off. On the new machine, the SCCM admin console will not connect no matter what I do. The SMSAdminUI.log file just gives me the insufficient privilege message Access Denied which in turn is triggering a dcom event id 10036 on the site server. I know it isn't a privilege issue because I have no problem on my other machines. I have seen posts where a Windows update has caused some problems but they appear to be old posts. It just isn't making any sense to me. Any help is greatly appreciated. Thanks.

I've been trying to remove this update on a test device for the last 3 days using a task sequence with the command line wusa.exe /uninstall /kb:5005565 /quiet /norestart or inserting the .msu file. Neither attempt will work. I have been successful in the past removing troublesome Windows updates using this method but this one is driving me crazy. Has anyone else had to remove this particular update and been successful using SCCM? Thanks.

I've tried both creating a TS from scratch and copying from another TS. Neither has been successful. I even tried just making it a simple 8 character password containing nothing but letters with no luck. Crazy thing is that when I verify the account and password connection to the OU within the TS it verifies just fine and that same account and password will manually join a device to the domain successfully. Might be time to get Microsoft involved.

Jumped the gun. The new password works for one of my task sequences but not for any of my other TS's including any new from scratch TS's. This is crazy.

I seem to be running into this more often as of late. I've created a basic OSD task sequence but when I attempt to deploy it the collection I wish to direct it to, it does not appear in my list. I know it is there because I have deployed other OSD task sequences to the same collection previously without issue and I can see the collection. I also run into this when I create a new device collection and try to deploy an existing TS to it. Thoughts? Thanks.

Update: New 15 character password that utilized all 4 of the complexity rules in AD worked successfully. The previous attempts that were failing were only matching 3 of the 4 requirements which should have still worked since the password rule states you must have at least 3 of the 4. Really odd. Thanks for the input and willingness to help test everyone.