why does timeout not working for Microsoft entra id joined device…?Solved

Participant
Discussion
2 months ago Mar 22, 2026

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?

Replies (1)

Marked SolutionPending Review
Participant
2 months ago Mar 23, 2026
Marked SolutionPending Review

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: 

Save