# Technical Implementation Guide: Standalone Windows Auto-Lock Enforcement 1. Introduction ---------------- This document provides a strategic and technical framework for enforcing a machine **inactivity limit (Auto-Lock)** on Windows devices managed by Hexnode. Specifically, it addresses environments where standard Mobile Device Management (UEM) Configuration Service Provider (CSP) profiles fail due to conflicts with external identity providers. By leveraging custom scripting capabilities, IT administrators can directly modify the OS-level registry or Local Security Policy to ensure strict compliance with auto-lock mandates without disrupting existing user identity configurations. 2. Business Case & Technical Context ----------------------------------------- - **Objective**: Enforce a 5-minute (300 seconds) automatic screen lock on all managed Windows devices to meet organizational security and compliance standards. - **Problem Statement**: Deploying the standard Hexnode Auto-Lock policy utilizes the Windows DeviceLock CSP. This specific CSP natively bundles inactivity timeouts with password complexity requirements (e.g., length, history, expiration). - **Technical Conflict**: On devices joined to Microsoft Entra ID or similar Identity Providers, password policies are strictly governed by cloud configurations. When the local Windows OS receives the bundled UEM payload containing password rules, it rejects the entire profile to prevent overriding the cloud policy. Consequently, the inactivity timeout is never applied. - **Proposed Solution**: Bypass the standard DeviceLock CSP by utilizing Hexnode’s [Execute Custom Script](https://www.hexnode.com/mobile-device-management/help/executing-custom-scripts-for-windows/) action. This approach directly configures the OS Registry or Local Security Policy, applying the inactivity timer independently without triggering password compliance checks. 3. Choosing Your Implementation Method --------------------------------------- Before deploying, assess which backend mechanism best fits your organizational environment. Both methods achieve the exact same 5-minute auto-lock enforcement. FeatureMethod A: Registry Modification (Automated)Method B: Local Security Policy / GPO (Manual)**Mechanism**Edits the Windows Registry directly via scripts.Edits the Windows Security Database directly.**Complexity**Low. Simple and highly reliable.Medium. Requires manual text file editing.**GPO Similarity**Good.Best. This mimics an Active Directory GPO perfectly.**Recommendation****Primary Choice**. Best for broad UEM rollouts.**Alternative Choice**. Best for one-off helpdesk fixes.4. Automated Deployment via Hexnode (UEM Rollout) -------------------------------------------------- This section outlines the deployment scripts intended for broad fleet distribution via the Hexnode portal using the **Execute Custom Script** action. ### Option A: The Registry Method (PowerShell – Recommended) - **How it works**: This PowerShell script defines the exact registry path that dictates the Windows inactivity timeout. It first checks if the necessary registry folder exists, creating it if it is missing. It then reads the current timeout value on the machine and, if it does not match the target of 300 seconds, forcefully overwrites it to bring the device into compliance. - **When to use this**: Use this as your primary deployment method. It is the most direct, lightweight, and reliable way to enforce the auto-lock timer across a standard Windows fleet. It is ideal for most environments that do not have third-party security tools actively blocking direct registry modifications. PowerShell script to set inactivity timeout on Windows devices \# Define the registry path and the desired timeout in seconds (300s = 5 mins) $RegPath = "HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System" $Name = "InactivityTimeoutSecs" $DesiredValue = 300 # Ensure the base registry path exists if (-not (Test-Path $RegPath)) { New-Item -Path $RegPath -Force | Out-Null } # Apply or enforce the inactivity timeout $CurrentValue = (Get-ItemProperty -Path $RegPath -Name $Name -ErrorAction SilentlyContinue).$Name if ($CurrentValue -ne $DesiredValue) { Write-Host "Enforcing Auto-Lock timeout to $DesiredValue seconds..." Set-ItemProperty -Path $RegPath -Name $Name -Value $DesiredValue -Type DWord -Force Write-Host "Policy applied successfully." } else { Write-Host "Device is already compliant." } 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) $RegPath = "HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System" $Name = "InactivityTimeoutSecs" $DesiredValue = 300 \# Ensure the base registry path exists if (-not (Test-Path $RegPath)) { New-Item -Path $RegPath -Force | Out-Null } \# Apply or enforce the inactivity timeout $CurrentValue = (Get-ItemProperty -Path $RegPath -Name $Name -ErrorAction SilentlyContinue).$Name if ($CurrentValue -ne $DesiredValue) { Write-Host "Enforcing Auto-Lock timeout to $DesiredValue seconds..." Set-ItemProperty -Path $RegPath -Name $Name -Value $DesiredValue -Type DWord -Force Write-Host "Policy applied successfully." } else { Write-Host "Device is already compliant." } ### Option B: The Registry Method (Batch Script) 14. **How it works**: This is a highly efficient, lightweight Command Prompt (.bat) script that executes a direct reg add command. It forces the creation or modification of the InactivityTimeoutSecs registry key, bypassing any user prompts. It includes basic error handling to report success or failure back to the UEM agent. 15. **When to use this**: Use this alternative if your organizational security policies restrict PowerShell execution, or if you simply prefer the most bare-bones, legacy-compatible script possible for enforcing the registry value. Batch script to set inactivity timeout on Windows devices @echo off :: Force the InactivityTimeoutSecs registry key to 300 seconds (5 minutes) :: The /f flag forces the overwrite without prompting the user reg add "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System" /v InactivityTimeoutSecs /t REG\_DWORD /d 300 /f :: Optional check to confirm it worked in the agent logs if %errorlevel% equ 0 ( echo Successfully enforced Auto-Lock to 300 seconds. ) else ( echo Failed to apply registry setting. Ensure script is running as System/Administrator. ) 1 2 3 4 5 6 7 8 9 10 11 @echo off :: Force the InactivityTimeoutSecs registry key to 300 seconds (5 minutes) :: The /f flag forces the overwrite without prompting the user reg add "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System" /v InactivityTimeoutSecs /t REG\_DWORD /d 300 /f :: Optional check to confirm it worked in the agent logs if %errorlevel% equ 0 ( echo Successfully enforced Auto-Lock to 300 seconds. ) else ( echo Failed to apply registry setting. Ensure script is running as System/Administrator. ) 5. Manual Remediation (Helpdesk Troubleshooting) ------------------------------------------------- Because automated text-parsing for Local Security Policies can be unreliable across different Windows environments due to file encoding restrictions, the GPO/Local Security Policy method is recommended strictly as a manual fallback. ### Method: Local Security Policy / GPO Edit (secedit) - **How it works**: This method uses the built-in Windows secedit tool to export the active security configuration to a text file. The technician manually injects the 300-second timeout rule into the file and then uses secedit to push those changes directly into the local Windows security database. - **When to use this**: Use this method for one-off troubleshooting, if a specific device is stubbornly rejecting registry changes, or if an internal compliance team mandates that configurations must exist explicitly within the Local Security Policy database. #### Execution Steps: 1. Open **Command Prompt** with Administrator privileges. 2. Export the current policy template by running: Command for exporting current Local Security Policy template secedit /export /cfg C:\\Windows\\Temp\\sec.inf 1 secedit /export /cfg C:\\Windows\\Temp\\sec.inf 3. Open the exported file in Notepad: Command for opening exported Local Security Policy template in Notepad notepad C:\\Windows\\Temp\\sec.inf 1 notepad C:\\Windows\\Temp\\sec.inf 4. Locate the \[Registry Values\] section and check for the *InactivityTimeoutSecs* entry: 1. **If the line already exists**: Update the value at the end of the line to read 4,300. 2. **If the line does NOT exist**: Paste the following line exactly below the \[Registry Values\] header: InactivityTimeoutSecs entry to added to the Local Security Policy template MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\InactivityTimeoutSecs=4,300 1 MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\InactivityTimeoutSecs=4,300 5. Save the file and close Notepad. 6. Apply the updated policy by running: Command for updating the Local Security Policy secedit /configure /db %windir%\\security\\local.sdb /cfg C:\\Windows\\Temp\\sec.inf /areas SECURITYPOLICY 1 secedit /configure /db %windir%\\security\\local.sdb /cfg C:\\Windows\\Temp\\sec.inf /areas SECURITYPOLICY 6. Post-Deployment Requirement: Device Restart ----------------------------------------------- Regardless of whether the Registry script or manual Local Security Policy method is utilized, **the Windows OS will not activate the new inactivity timer until the machine reboots**. **Action Item**: After confirming that the Custom Script has successfully executed on the targeted devices, administrators should utilize the **[Restart device](https://www.hexnode.com/mobile-device-management/help/restart-a-device-using-hexnode-uem/)** remote action within Hexnode (**Actions > Device Control > Restart Device**) to force a reboot and finalize the policy enforcement.