I am completely stuck trying to get a simple five-minute screen timeout working on our windows fleet. I went into the Windows Password policy and changed the “Auto lock (in minutes)” option to 5, but it silently fails on every single laptop joined to Microsoft entra ID. The screens just stay awake indefinitely. Why is a basic inactivity timer getting rejected just because we use cloud identities, and how do I actually enforce this 300 seconds lock without breaking my current setup?
Welcome to the joy of managing Windows, @jennifer. You are definitely not the first admin to lose sleep over this bizarre conflict.
The root cause comes down to exactly where that setting lives. Because you configured the “Auto lock (in minutes)” option inside the standard Password Policy payload, Hexnode pushes it out using the Windows DeviceLock CSP. The issue is that microsoft natively bundles everything in that specific Csp together, meaning your simple inactivity timeout gets packaged right alongside heavy password complexity requirements like length and expiration history inside that specific profile.
Since your devices are joined to Microsoft entra id, your cloud configuration is already strictly governing those password rules. When the local Windows OS receives the UEM payload containing overlapping password settings, it panics and rejects the entire profile to protect the cloud rules. Your innocent screen timeout gets thrown out right along with the rest of the password policy.
To fix this, you just need to bypass the standard password policy profile entirely. You can use the Execute custom script action to apply the timer directly to the registry without triggering those password compliance checks. This script worked for me:
PowerShell script to set inactivity timeout on Windows devices
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Define the registry path and the desired timeout in seconds (300s = 5 mins)