Active Directory Archives - Page 6 of 9

Systems Admin

Raise Active Directory Domain and Forest Functional Level

Raising AD functional level is a one-way change that unlocks newer features (PAM at 2016 forest, Protected Users at 2012 R2 domain, AD Recycle Bin at 2008 R2 forest) and removes support for older Windows Server DCs. The wizard click is fast; the pre-flight is where rollout time lives. Walks the full end-to-end procedure: replication health checks (repadmin /replsummary, Get-ADReplicationFailure), DC OS-version inventory (Get-ADDomainController), raise each domain via Active Directory Domains and Trusts (right-click domain - Raise Domain Functional Level - pick target - Raise - confirm), then raise the forest (right-click root - Raise Forest Functional Level), verify both via Properties dialog and Get-ADForest / Get-ADDomain PowerShell, then post-raise housekeeping (repadmin /syncall, Restart-Service kdc on each DC). Includes the order-matters rule (every domain must be at the new level before the forest dropdown will offer it), the FRS-to-DFS-R prerequisite for 2016, the powered-off-DC trap, and the irreversibility caveats.

Systems Admin

Forest and Domain Functional Levels in Active Directory: Theory

Functional levels are the rule book that controls what an Active Directory forest and the domains in it can do. They lock the minimum Windows Server version DCs can run, gate the features available across the directory, and shape every upgrade plan. Two attributes, two scopes - forest functional level (the floor for the whole forest) and domain functional level (per-domain, must be >= forest level). The current ceiling is Windows Server 2016; 2019 and 2022 DCs run at the 2016 level. Functional levels apply only to DCs - workstations and member servers can run any Windows version. Walks the theory: schema vs forest vs domain, the forest-beats-domain rule, the features unlocked at each level (DFS-R for SYSVOL at 2008, AD Recycle Bin at 2008 R2, gMSA at 2012, Protected Users at 2012 R2, PAM at 2016), the GUI check (Active Directory Domains and Trusts) and PowerShell check (Get-ADForest / Get-ADDomain), the FRS-to-DFS-R prerequisite for raising to 2016, and the four common misconceptions (functional level does NOT control client OS, does NOT speed up DCs, etc.).

Systems Admin

Backup and Restore Group Policy Objects (GPOs)

GPOs can be deleted in two clicks; AD replicates the deletion to every DC, SYSVOL files vanish, and clients drop the policy at next refresh. AD Recycle Bin restores the container in AD but not the SYSVOL GPT files where the actual policy settings live - so per-GPO backup is its own discipline. Walks the full GPMC lifecycle: Back Up All... for a fleet snapshot, Back Up... for one GPO before a risky edit, Manage Backups... for preview-then-restore (View Settings opens an HTML report, Restore overwrites the live GPO), and the manual re-link step that the backup does NOT capture. Plus the PowerShell-only equivalent (Backup-GPO -All / Restore-GPO -Name) for scheduled / scripted use. Includes the four pitfalls (no description = uninformative Manage Backups list, backup-on-the-DC-fails-with-the-DC trap, untested-backup wishful thinking, View-Settings-first habit) and the link-map documentation gotcha.

Systems Admin

Change the Retention Period in AD Recycle Bin

AD Recycle Bin defaults to a 180-day recovery window - long enough that 'please restore the user my predecessor deleted last quarter' lands on day 181. Two attributes on CN=Directory Service control end-to-end retention: msDS-DeletedObjectLifetime (Recycle Bin window, fully recoverable with Restore-ADObject) and tombstoneLifetime (permanent-death horizon, garbage collection cutoff). Walks the ADSI Edit edit: connect to the Configuration partition, navigate CN=Configuration / CN=Services / CN=Windows NT / CN=Directory Service, raise both attributes from 180 to 365 (always tombstoneLifetime first - the directory enforces DOL

Systems Admin

Backup and Restore AD-Integrated DNS Zones

AD-integrated DNS zones live in the directory database, not in flat .dns files - which means a Windows Server system-state backup catches them but only restores via a full authoritative restore in DSRM. For per-zone recovery (accidental delete, single-zone corruption), the right tool is dnscmd /zoneexport (or Export-DnsServerZone) for backup and the New Zone Wizard + zone-type conversion for restore. This article walks the full round trip: export fortesting.local and _msdcs.fortesting.local to .dns.backup files, simulate the disaster by deleting both zones, restore each as a standard Primary zone via the New Zone Wizard (with the rename-the-backup-file trick the wizard requires), then convert back to AD-integrated and tighten dynamic updates to Secure only. Includes the forest-wide replication-scope gotcha for _msdcs (default is domain-wide after conversion - has to be manually widened to forest), the off-server-copy requirement (the export drops files on the DC's own disk), and the verification commands.

Systems Admin

Reset the Directory Services Restore Mode (DSRM) Password

The DSRM password is the local-Administrator credential a domain controller uses when AD is offline - the only account that works during authoritative restores, ntds.dit corruption recovery, or last-DC rebuilds. Forgetting it means none of those recoveries work when you actually need them. This article walks the full reset + verify cycle on a real DC: rotate the password with ntdsutil (set dsrm password / reset password on server null - takes one minute, no reboot, no downtime), then prove the new credential works by rebooting into DSRM via F8 or 'bcdedit /set safeboot dsrepair', signing in as .\\administrator with the new password, observing the directory is offline (NTDS / Intersite Messaging / DFSR / KDC stopped, dsa.msc red-crossed), then rebooting back to normal with 'bcdedit /deletevalue safeboot'. Includes the multi-DC rotation pattern, the local-admin-vs-DSRM-vs-domain-admin distinction, and why storing the DSRM password in an AD-integrated vault is a circular dependency.

Systems Admin

Automatically Map a Network Drive by Group Membership with Group Policy

The classic 'net use' line in a logon script stalled the desktop, did not scale to multiple departments, and was painful to clean up when someone changed teams. Group Policy Preferences Drive Maps + item-level targeting replaces all of it: declarative, parallel, and scoped to AD group membership. This article walks the full workflow - create the security group in dsa.msc, share the folder with matching share + NTFS ACLs, create and link a GPO to the user OU, add a Drive Maps preference (Action: Create, Reconnect: yes, Drive Letter: S, Label as: Sales Group), then move the membership check off the OU link and onto the preference itself via Common - Item-level targeting - Security Group - User in group. Verifies with gpresult and Get-PSDrive on a domain-joined client. Includes the common pitfalls (linking to the computer OU, skipping share permissions, picking a domain-local group, forgetting the User-in-group vs Computer-in-group choice).

Systems Admin

Fixed: Trust Relationship Between Workstation and Domain Failed

Every domain-joined Windows machine shares a machine-account password with the domain controller; the password rotates every 30 days, and when the local and DC copies drift apart the secure channel collapses and logon dies with: The trust relationship between this workstation and the primary domain failed. Four working fixes, ordered heaviest to lightest. Solution 1 - drop the machine to a workgroup and rejoin the domain (always works, two reboots). Solution 2 - Reset-ComputerMachinePassword -Credential from PowerShell (one command, no reboot, the cleanest fix). Solution 3 - cache a domain credential in Credential Manager (a workaround, not a fix - the underlying drift is still there). Solution 4 - right-click the computer object in dsa.msc and pick Reset Account, then reboot the client (the right answer when the desktop is unreachable). Includes the four root causes (long offline gap, snapshot restore, cloning without sysprep, replication lag) and which solution best matches each.

Systems Admin

Rename Administrator Account with Group Policy

The built-in local Administrator account ships with two predictable properties: well-known RID 500 (predictable SID) and the literal name 'Administrator'. The Accounts: Rename administrator account security policy lets you change the name across every domain-joined computer with one GPO. This article walks the workflow: create a Computer-scoped GPO linked to the OU containing your endpoints, navigate to Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / Security Options, set Accounts: Rename administrator account with a deliberately neutral name (Operator, BuildAcct, etc.), run gpupdate /force on a target, verify in Computer Management - Local Users and Groups. Includes the GPO naming convention (C_ / U_ / CU_), the names to avoid (Admin, SuperUser, anything containing 'admin'), and the common pitfalls (linking at the domain root, picking a guessable name, confusing the local rename with the Domain Administrator rename).

Systems Admin

Remove Orphaned SIDs with PowerShell

An orphaned SID is an ACL entry whose underlying user, group, or computer was deleted but the access control entry was left behind. They show up as raw S-1-5-21-... numbers on the Security tab of AD objects and clutter audit reports without breaking access control. This article ships a complete RemoveOrphanedSID-AD.ps1 PowerShell script that recursively walks AD objects, identifies ACEs whose IdentityReference is a domain-prefixed SID that no longer resolves, and either lists or removes them. Includes the two-pass workflow (list, then remove), the -WhatIf dry-run mode, the AD: PowerShell drive provider details, why RemoveAccessRuleSpecific is the right method, and the common pitfalls (running -Remove first, scoping to forest before testing on one OU, confusing this with file-system ACL cleanup).

Systems Admin

Troubleshoot AD Promotion Stuck at “Creating the NTDS Settings Object”

The Active Directory promotion wizard reaches Creating the NTDS Settings object and never advances. The Directory Service log on the candidate fills with events 1963 / 1962 / 1125. The cause is almost always one of two things: a credential mismatch (local Administrator password matches the domain Administrator password, or the wizard credential was supplied without a domain qualifier) or stale residue from a prior failed promotion. This article walks the five-step path: prerequisite check, fix the two credential mistakes, four-step residue cleanup (reboot, delete computer object, force-leave domain, uninstall AD DS role), retry the promotion, and only then chase the deeper network and DNS causes. Includes the LDAP port 389 sweep, SRV-record verification, and replication health check on the existing DC.

Systems Admin

Troubleshoot Active Directory Domain Join Error 0x232A (DNS / NetBIOS)

Domain join error 0x232A (An Active Directory Domain Controller for the domain could not be contacted) is a name-resolution failure, not a network outage. The fix is almost always one of three things: type the DNS FQDN instead of the NetBIOS short name, point the workstation's DNS at servers that host the AD zones, or disable NetBIOS over TCP/IP entirely. This article walks the seven-step diagnostic path: confirm the name typed, fix client DNS, kill NetBIOS, verify SRV record resolution with nslookup, prove TCP 53 / 389 connectivity, check both host firewalls, and read NetSetup.log for the exact failure point. Includes the difference between 0x232A and 0x3a and the common pitfalls (public DNS in the DHCP scope, split-tunnel VPN DNS, unreplicated SRV records on a newly promoted DC).

Tag: Active Directory