LifeBytes Journal

Local administrator accounts are one of the easiest targets in a Windows domain. If every workstation shares the same local admin password (or if passwords are rarely rotated), a single compromised machine can quickly turn into lateral movement across the network. Microsoft’s solution is Windows LAPS (Local Administrator Password Solution), which automatically generates unique, random local admin passwords per device and stores them securely in Active Directory (or Azure AD/Entra in cloud scenarios). This guide focuses on deploying modern Windows LAPS in an on-prem Active Directory environment using Group Policy and PowerShell.

What You Need Before You Start

To follow this tutorial, you should have a domain-joined environment and permissions to modify Active Directory and Group Policy. Your clients should be on supported Windows versions (Windows 10/11 and modern Windows Server builds). You also need at least one management workstation or server where you can run PowerShell with the Active Directory module installed. If you previously used the legacy “Microsoft LAPS” MSI, note that Windows LAPS is built-in to newer Windows versions and uses different policies and cmdlets.

Step 1: Confirm Windows LAPS Is Available on Clients

On a target workstation, open PowerShell and verify you have access to LAPS cmdlets (exact availability depends on OS build). You can quickly check with:

Get-Command -Module Laps

If the module is not present on older builds, install the relevant Windows update or confirm the device is on a supported version. In most current enterprise builds, Windows LAPS is included and managed through Group Policy/MDM without installing extra software.

Step 2: Extend the Active Directory Schema for Windows LAPS

Windows LAPS stores password data in AD attributes. To add those attributes, extend the schema once per forest. On a management machine with appropriate rights (typically Schema Admins), run PowerShell as Administrator:

Update-LapsADSchema

After this completes, Active Directory will have the attributes needed to store the managed local admin password and its expiration time.

Step 3: Set Permissions for Who Can Read Passwords

By default, you should restrict password read access to a small set of helpdesk or server-admin groups. A practical approach is to grant read access to a dedicated security group (for example, “LAPS Password Readers”) on the OU that contains your computers.

Run the following from a machine with the AD module installed, adjusting the OU distinguished name and group name to match your environment:

Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=example,DC=com" -AllowedPrincipals "EXAMPLE\\LAPS Password Readers"

You should also allow computers to write their own password to AD (often already covered, but it’s good to be explicit):

Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=example,DC=com"

If you want to confirm permissions, use:

Find-LapsADExtendedRights -Identity "OU=Workstations,DC=example,DC=com"

Step 4: Create and Link a Group Policy for Windows LAPS

Open Group Policy Management, create a new GPO (for example, “Windows LAPS – Workstations”), and link it to the OU that contains the computers you want to manage. Then edit the GPO and configure Windows LAPS settings under:

Computer Configuration > Policies > Administrative Templates > System > LAPS

Recommended baseline settings for many organizations include:

Enable password backup: Set to Back up the password to Active Directory.

Password settings: Use a strong length (for example, 16–24) and enable complexity. Longer is better because users never have to type these passwords routinely; they retrieve them only when needed.

Password age (days): Choose a rotation period that fits your risk tolerance, such as 7–30 days for workstations and 1–7 days for privileged servers.

Managed account name: Decide whether you will manage the built-in local Administrator or a custom local admin account. Many teams prefer a custom local admin name to reduce guessability, but either approach can work when LAPS is properly enforced.

After configuring the GPO, run gpupdate /force on a test machine or wait for policy refresh.

Step 5: Validate That Passwords Are Being Stored in AD

Once the policy applies, the client should generate a new password and write it to AD. From your admin workstation, retrieve the password for a computer (example computer name: PC-041):

Get-LapsADPassword -Identity "PC-041"

If you only want to see basic fields (and avoid copying sensitive output), you can pipe to a format view. Also confirm the expiration time is present, which indicates rotation is scheduled.

Step 6: Force an Immediate Password Rotation (When Needed)

When a technician uses a local admin password for troubleshooting, a good practice is to rotate it immediately after the session. You can trigger a rotation by shortening the expiration time in AD. One way is to set the password to expire now and let the client rotate at next policy processing:

Reset-LapsPassword -Identity "PC-041"

Depending on your configuration and client behavior, you may also combine this with a policy refresh on the endpoint.

Common Troubleshooting Tips

Passwords are not appearing in AD: Verify the GPO is linked to the correct OU, the computer account is in that OU, and the device is actually receiving the LAPS policy (check Resultant Set of Policy). Also confirm the computer has permission to write its own LAPS attributes by rechecking Set-LapsADComputerSelfPermission.

Helpdesk can’t read passwords: Confirm the user is in the correct group and that group has read permission on the OU where the computer object lives. Remember that OU-level permissions won’t help if the computer is located somewhere else.

Rotation doesn’t happen on schedule: Ensure the device is online regularly, time is synchronized, and Group Policy refresh is working. Rotation depends on the endpoint being able to update AD.

Final Thoughts

Windows LAPS is one of those rare security improvements that is both powerful and practical: it reduces password reuse risk without adding daily friction for users. Start with a pilot OU, lock down who can read passwords, and document a simple helpdesk workflow for retrieving and rotating passwords. Once it’s stable, expand the policy to all workstations and then to servers with stricter rotation rules.

Slow sign-ins on Windows Server (and on domain-joined PCs) are often blamed on “the network” or “the domain,” but in many cases the real cause is a specific Group Policy setting, a broken script, a stalled drive mapping, or a DNS-related delay that forces Windows to wait. This how-to tutorial shows a practical, admin-friendly process to diagnose and fix long login times and sluggish Group Policy processing using built-in tools: Event Viewer, gpresult, Group Policy Management, and Group Policy Analytics in Windows Admin Center.

1) Confirm the symptom and capture a baseline

Before changing anything, confirm where the time is being spent. Ask the affected user (or test account) to reproduce the issue and note: the device name, username, time of login, and whether it’s over VPN/Wi‑Fi. If you can, compare a “fast” machine with a “slow” one in the same OU. Baselines matter because login delay can be caused by user policies, computer policies, or both.

2) Check Group Policy processing events (fastest way to find the bottleneck)

On the affected server or workstation, open Event Viewer and navigate to: Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational. This log is designed specifically for Group Policy troubleshooting and typically reveals which extension is slow (Scripts, Drive Maps, Registry, Security, etc.).

Filter the log by the time of the slow sign-in. Look for warnings/errors and for events that show processing duration. Common red flags include: “scripts took X seconds,” “Drive Maps extension stalled,” “cannot reach a domain controller,” or “waiting for network.” If you see consistent delays tied to a specific extension, you’ve likely found the root cause category.

3) Generate a detailed policy report with gpresult

Run an elevated Command Prompt and export a report. For computer policy (run as admin): gpresult /h C:\Temp\gpresult.html. For a specific user session on a server with multiple users: gpresult /h C:\Temp\userpolicy.html /user DOMAIN\username. Open the HTML report and review applied GPOs, denied GPOs, and especially the sections for logon scripts, drive mappings, scheduled tasks, and folder redirection.

Pay attention to “Filtering: Denied” and “WMI Filter” outcomes. WMI filters can add noticeable delay, particularly when they query slow namespaces or complex conditions. If a WMI filter is involved, test its query locally using wbemtest or PowerShell to see if it runs slowly.

4) Use Windows Admin Center Group Policy Analytics to catch legacy or problematic settings

If you manage modern Windows Server environments, Windows Admin Center (WAC) provides Group Policy Analytics, which can import a GPO backup and analyze compatibility and policy types. This is useful when cleaning up long-lived domains with years of inherited GPOs. In WAC, open Group Policy, then Analytics, and import GPO backups from your domain (export them first from Group Policy Management Console).

Focus on settings that are obsolete, duplicated, or implemented in multiple places. While Analytics is not a “performance tool” by itself, it helps you reduce policy bloat, which indirectly reduces processing time and avoids conflicts that cause repeated retries.

5) Fix the top real-world causes of slow login

5.1 Broken drive mappings or unreachable file servers

Drive maps are a classic culprit. If a GPO maps a drive to a server that is offline, blocked by firewall, or unreachable over VPN, Windows can pause during sign-in while it retries. In the gpresult report, find mapped drives and verify each UNC path. Prefer using Item-level targeting to apply certain mappings only when a network or subnet is present. If the environment uses VPN, consider making non-critical mappings “Reconnect” without blocking logon, or move them to post-login scripts.

5.2 Slow or failing logon scripts

Logon scripts that call legacy tools, query remote shares, or run multiple installers can add minutes. In the GroupPolicy Operational log, confirm if “Scripts” is taking long. Then review the script content. Replace legacy batch logic with a lightweight PowerShell script, add timeouts to network calls, and log script runtime to a local file so you can measure improvements. If the script depends on a share, ensure DNS resolves quickly and the share is highly available.

5.3 “Always wait for the network” and synchronous processing

The policy Computer Configuration > Administrative Templates > System > Logon > “Always wait for the network at computer startup and logon” can improve reliability for some environments, but it can also increase perceived sign-in time, especially on Wi‑Fi and VPN. If your logs show repeated “waiting for network” behavior and users don’t need synchronous startup, test disabling this setting in a controlled OU and measure the effect.

5.4 DNS and DC discovery delays

If the device uses incorrect DNS servers (for example, public DNS instead of AD DNS), Group Policy and authentication can stall. Verify the client’s DNS settings point only to domain DNS servers. Then test name resolution and DC discovery: nslookup domain.local and nltest /dsgetdc:domain.local. Fixing DNS misconfiguration often produces immediate improvements without touching GPOs.

6) Reduce GPO scope and remove “policy sprawl” safely

Large environments frequently accumulate overlapping policies. Consolidate where possible: avoid stacking many small GPOs that each do one thing if they all target the same OU. Disable unused sections (disable User or Computer configuration if not used), remove obsolete preference items, and eliminate redundant registry settings. After each change, force an update for testing: gpupdate /force, then perform a fresh sign-in and compare event timings.

7) Validate, document, and monitor

After applying fixes, repeat your baseline test and re-check the GroupPolicy Operational log to confirm the slow extension is resolved. Keep a short change record: which GPO was modified, what was removed/changed, and the measured improvement. For ongoing monitoring, periodically review the same log on a few representative machines (especially after major GPO changes) to catch regressions early.

With a disciplined approach—starting from event logs, validating with gpresult, and cleaning GPOs with modern tooling—you can usually turn “mysterious slow logins” into a clear, fixable list of causes. The key is to measure, change one thing at a time, and confirm the improvement in the logs.