Install of "windows-screenlock.xml" fails with status code 216 and 500

[dherder]

Fleet version: 4.45.1

Web browser and operating system: host: Windows 10 Enterprise 22H2 10.0.19041.2486

---

💥  Actual behavior

When deploying "windows-screenlock.xml" from the fleet gitops repo, the status Falis with "./Device/Vendor/MSFT/Policy/Config/DeviceLock/DevicePasswordEnabled: status 216, ./Device/Vendor/MSFT/Policy/Config/DeviceLock/MaxInactivityTimeDeviceLock: status 216, ./Device/Vendor/MSFT/Policy/Config/DeviceLock/MinDevicePasswordLength: status 500, ./Device/Vendor/MSFT/Policy/Config/DeviceLock/MinDevicePasswordComplexCharacters: status 216 ", deployed to a vm Windows 10 Pro device running on Intel hardware.

🧑‍💻  Steps to reproduce

1. upload "windows-screenlock.xml" to Controls> OS Settings> Custom Settings
2. Force a Windows 10 Enterprise device to refresh vitals

🕯️ More info (optional)

Seems like there is a known issue when deploying to arm64 vms, but I'm experiencing this with an Intel based Windows 10 Enterprise vm enrolled in dogfood (Workstations canary). prospect-konrad is also experiencing this problem, but with a physical laptop running Windows 11 Pro 23H2 10.0.22621.3155

[roperzh]

hey @dherder is the idea here to investigate what's the problem with the configuration profile? To over-communicate, I don't think this is an application bug.

cc: @georgekarrv

[dherder]

@roperzh yes, I think so. If we are using this config profile within our gitops best practices, it should install on Windows 10 and 11 devices without errors. I tried modifying the profile to only include the MinDevicePasswordLength, and received odd results (like the profile stuck in pending state), but may be that was due to testing on an arm64 vm. Are we saying the Windows MDM is compatible on arm64 architecture or should we only be testing on intel?

[roperzh]

@dherder thanks, that makes sense. The summary of my understanding would be:

1. Profile verification (double check via osquery) is currently dependent on processor architecture. Arch shouldn't affect the profile being delivered successfully (in theory)
2. The profile needs to be fine tuned so it works out of the box, or, we should at least document what are the conditions required for the profile to work.

[mna]

Testing on my Windows 11 Pro 22H2 VM, here's how it went:

First run, windows-screenlock.xml untouched:

DevicePasswordEnabled: 500
MaxInactivityTimeDeviceLock: 216
MinDevicePasswordLength: 216
MinDevicePasswordComplexCharacters: 216

Second run, DevicePasswordEnabled section removed:

MaxInactivityTimeDeviceLock: 216
MinDevicePasswordLength: 500
MinDevicePasswordComplexCharacters: 216

Third run, MinDevicePasswordLength section removed:

MaxInactivityTimeDeviceLock: 216
MinDevicePasswordComplexCharacters: 500

Fourth run, MinDevicePasswordComplexCharacters section removed, succeeded:

MaxInactivityTimeDeviceLock: 200

It looks like anything related to the password fails to be set, and the Microsoft docs mention this:

DevicePasswordEnabled should not be set to Enabled (0) when WMI is used to set the EAS DeviceLock policies given that it is Enabled by default in Policy CSP for backward compatibility with Windows 8.x. If DevicePasswordEnabled is set to Enabled(0) then Policy CSP will return an error stating that DevicePasswordEnabled already exists.

I'm not quite sure what that means and if that's what is happening here, I'll try to find more details on this.

[mna]

Haven't found anything super interesting regarding EAS (Exchange ActiveSync, I think), maybe this but that's a stretch and they say that setting DevicePasswordEnabled worked but it forced changing the password. In our case it just fails to apply that policy.

I dumped the MDM Advanced Diagnostic Report on the Windows device (it generates an HTML page with the settings current value, difference from default, etc.) and interestingly it has the DevicePasswordEnabled set to 0 (not to the default 1), but AFAICT it wasn't set by us since the profile always failed when that policy was provided:

At this point I have no idea why we cannot set that policy, nothing in the docs explains it clearly outside the mention of WMI/EAS that didn't lead to anything concrete. Maybe someone with more Windows administrative knowledge could look into this, I don't think it requires the engineering team as it's about finding the right parameters to provide in the profile so that it can be successfully applied. The code (Fleet app and fleetctl) work as expected with regards to deploying it and providing the results of the attempt (as Roberto mentioned here).

@georgekarrv for how to proceed to transfer this ticket to the appropriate next step?

[mna]

I think this EAS thing is relevant, but I don't know exactly in what way:

In https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-devicelock:

The DeviceLock CSP utilizes the Exchange ActiveSync Policy Engine. When password length and complexity rules are applied, all the local user and administrator accounts are marked to change their password at the next sign in to ensure complexity requirements are met.

And in https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn282287(v=ws.11):

Devices, including servers, desktops, laptops and tablets, that are running the supported versions of Windows and are capable of installing a mail app from the Windows Store can enforce EAS policies.

I do have the Mail app on the VM, but it's not connected to any Exchange server. Might be the wrong rabbit hole, but based on those quotes that would be my guess as to what to look into?