-2016281112 (Remediation failed) - Minimum Password Length

Occasional Contributor

Hi all, 


I have been applied the Intune policy about minimum password length, to more than 100 clients but for 20 of them. 
My password policy has a minimum of twelve characters, one Upper case, one Lower case, one number & one special character. The user password meets the policy but, I'm still getting the device as non-compliant.

I'm getting the error message below :



Thanks in advance

11 Replies

COuld you disable the "special character" as test? to see what happens .

Take a look at this uservoice..

Thank you for your response.
I tested it last week, but it didn't work for my case.

@George Grammatikos 




I suspect it has to do with the set and get commands


The problem is that this CSP only supports Add Operation, which means the Get Operation will always fail because it has not been implemented.


We are getting the same error when we are pushing a device configuration policy to set the Password... Of course, this succeeds, but getting the result.... most of the times it fails



But you are mentioning non-compliant errors? Could you show your device securitycompliance requirements?






Please, check the system security section in the device compliance policy



Just wondering ( I am setting up a test vm right now) did the problem users also tried to change their password themself on the device itself and trying to check the compliance status in the company app?


I am missing the password type and password complexity in your screenshot? Or did you leave it on default?




And are the devices: 


azure ad joined or domain/hybrid joined


Did you also disabled Windows Hello?


And did you also read the docs from microsoft about this topic


Policy CSP - DeviceLock - Windows Client Management | Microsoft Docs


The enforcement of policies for Microsoft accounts happen on the server, and the server requires a password length of 8 and a complexity of 2. A complexity value of 3 or 4 is unsupported and setting this value on the server makes Microsoft accounts non-compliant.




One user changed his password but, he is having the same issue.
The Password type setting is the default one.
The devices are joined to an Azure AD.
The Windows Hello for some of the devices is enabled and for some others disabled.
The password has a minimum of twelve characters, x1 Upper case, x1 Lower case, x1 number & x1 special character.

@George Grammatikos 


Hi. As you know I sent you a private message with some tips.

For anyone else reading this question:





I guess when I need to troubleshoot this. I would change one setting at a time.


If you take a look at the Microsoft doc I linked to...  






I guess you have got 2 options.


*Remove that part of the compliance policy as it is not working (uservoice says the same?)

*Change the password compliance policy to require only 8 characters and digits and lowercase

characters --> check if that works


if it works -->  add uppercase

if that works --> change policy to 12 

If that works --> add complexity requirement


Also beware Users with passwords that meet the requirement are still prompted to change their passwords.

I know it can take a lot of time... but troubleshooting always does :( ..


I tried all the ways, but I'm still getting the device as non-compliant, and the error message is the same. I also test it with the assigned compliance policy without any result.
best response confirmed by George Grammatikos (Occasional Contributor)

@George Grammatikos 




So even only specifying: Require 

Password type --> Default

Minimum password --> 8 


Is  giving you non compliant errors in a new device compliance policy





what do you mean it has not been implemented?



What I am trying to say. Is that when you create some device configuration policies like this example to create a local admin user and a corresponding password.



It will always fail...  (the reporting) even when the user and the password were created.


To quote someone (have it in my internal docs... but.. not sure who said it )


The error here is due to the status check mechanism that is implemented within. In general, when Intune tries to determine if the policy takes effect on the target device, it calls Get Operation of the interested OMA-URI, which basically queries the registry key value from the client. And then compare the result with the policy value.
The problem is that this CSP only supports Add Operation, which means the Get Operation will always fail because it has not been implemented. That's why we get the error even if it successfully applied.