I Kill Remediation Errors

This time, it is a simple blog, but it is still one with a Remediation Failed Error -201628112 ?. This nice remediation could occur when you have created a CSP to add an additional local admin on the device

CSP policy works but Intune reporting it failed. : Intune (reddit.com)

So I thought it was time to create a blog about it, so hopefully, the answer to this question can be found on Google a little bit better.

1. Adminless

Of course, you need to prevent your users from being or becoming local admins. Being a local admin does not provide security!

I have written many blogs about why this is so important. Please check my blogs about this topic first.

2. Creating a local admin

So, when you made sure that all of your users were no longer members of the local administrator’s group, you could still want to have an additional dedicated workstation local admin on the device, dedicated for administrative purposes only!

To do so, we could create a new CSP. With this CSP we just create a new user: TestUser with a nice password and will add the user to the “local group” we want.

./Device/Vendor/MSFT/Accounts/Users/TestUser/LocalUserGroup

./Device/Vendor/MSFT/Accounts/Users/TestUser/Password

When looking at the AccountType, you would probably have noticed the Integer value: 2. Let me simply explain what happens when you configured the value 1 or 2.

Integer value 1 sets as user

Integer value 2  sets as Admin

So when you want to add the user to the local admin group, you will need to define the integer value of “2”

When this CSP is deployed to your device a new local admin user will be created with the password you provided. Please note: When using this CSP: “User must change Password at next logon” will be enabled

If you don’t want that, take a look at this blog. I am using a PowerShell script and a scheduled task to ensure there are “never” more local admins on the device than we configured!

Intune | Remove Local Administrators AADJ with PowerShell (call4cloud.nl)

In this PowerShell script, I also added this part: get-localuser | Set-localUser -PasswordNeverExpires:$True. To make sure the change password issue is resolved please run this PowerShell script in 64 bits Context!.

After the local admin is created, please don’t forget to apply a local password solution like I am mentioning

The LAPS: Reloaded / Revolutions – Call4Cloud and Intune Proactive Remediations

3.Remediation Failed 201628112

Cool! We made sure we had an additional local admin on the workstations. Should we take a look at the results?

Huh? That’s odd, even while the local user has been created successfully and it’s added to the local admin group why is it giving us the famous error Remediation failed -201628112?

When in doubt, always check the official Microsoft documentation first to see if anything useful is it!

So, I am looking at the Users/UserName/Password. It tells us that the supported operation is Add, and the GET operation is not supported. When you configure this setting from the Endpoint Manager, it will report as failed when deployed.

4. Digging into the 201628112 error

But as always, I want to know why we can’t get the results. So, let’s do some troubleshooting to find out why it gives us this error.

Did you know that all of the settings and expected values are stored in the registry? Please take a look at these registry keys

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\NodeCache\CSP\Device\MS DM Server\Nodes\”node”

In my case, the node I needed was 19759. Just search for the password in the main registry key to find it.

Looking at the picture above we noticed that the Expectedvalue is empty, let’s compare it with a working one.

Okay… The working one is giving us the value we configured in the CSP in the endpoint manager. So what does the expectedvalue value means? I guess it’s quite obvious…but …let me explain some more

/NodeID/ExpectedValue

This is the value that the server expects to be on the device. When the configuration service provider initiates a session, it checks the expected value against the node’s actual value.

I am also mentioning the NodeCache key in this blog about how chrome policies could be failing and how to troubleshoot it

https://call4cloud.nl/2021/10/what-if-chrome-policies-are-failing

Okay, so looking at the password value, it is going to compare the empty value against the node’s actual value? Of course, that will end up with the 2016281112 remediation failed error I guess.

5. RebootRequiredURI’s

This is totally off-topic… but while looking at what happens on the client-side, I stumbled on this one this registry key mentioning the Reboot Required URI’s

HKLM:\SOFTWARE\Microsoft\Provisioning\SyncML\RebootRequiredURIs

If you want to know which OMA-URIs require a reboot, you will need to check out this registry key!

6. Another option to create a local admin

When we don’t want to end up with remediation errors… we could just create the additional local admin user with a PowerShell script… but then again… this will show up in your intune logs…so you will need to remove them like I am showing here!

Conclusion

It’s important to know how stuff works and what to look out for when it breaks. Sometimes, a remediation error is not so bad… as long as you know why it is happening.

After reading this blog, you will know how to kill giants—uh, sorry, my bad—and how to kill those remediation errors when adding a local admin.