Systems Admin Archives - Page 15 of 19

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

Restart Remote Computer with PowerShell

When a remote Windows box hangs and nobody is on site to power-cycle it, the fastest fix is Restart-Computer -ComputerName from your own PowerShell. The default refuses to kick logged-on users; the -Force switch overrides that. Verify with a continuous ping (ping -t) that walks the box through online -> timeout -> back-online states, or use the more PowerShell-native Test-Connection. The article also walks the longer-form alternative: full PowerShell Remoting via Enable-PSRemoting on the target, Enter-PSSession for interactive shells, Invoke-Command for single-shot fleet operations, and the TrustedHosts caveat for workgroup boxes. Includes the common pitfalls (forgetting -Force, expecting workgroup PSRemoting to work without TrustedHosts, restarting DCs without checking replication).

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

Convert MBR to GPT without Data Loss

MBR caps at 2 TB per disk and four primary partitions; GPT lifts both ceilings (9.4 ZB, 128 primary partitions). For data disks on a running Windows Server, the right tool is DiskGenius - free, online, three clicks per disk, no data movement, no reboot. This article walks the workflow: identify MBR disks with Get-Disk, convert with DiskGenius (right-click - Convert To GUID Partition Table - Save All - Yes), repeat for each disk, verify with Get-Disk, restart the server when the maintenance window allows. Includes why mbr2gpt.exe is the wrong tool for data disks (it is system-disk-only and requires WinPE), the gotchas (skipping Save All, converting from the wrong DAG node, BIOS-only servers and the system-disk constraint), and the difference between the in-place metadata-only conversion DiskGenius does and the copy-everything-over fresh-GPT-disk migration Microsoft suggests.

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).

Systems Admin

Troubleshoot “The Specified Server Cannot Perform the Requested Operation” Error (0x3a)

Domain join error 0x3a (The specified server cannot perform the requested operation) is almost always a TCP 389 LDAP connectivity problem dressed up in directory-layer language. This article walks the diagnostic path: confirm DNS and basic reachability, prove TCP 389 with Test-NetConnection, then narrow the block to the workstation host firewall, the DC host firewall, or the network ACL between them. Includes the multi-port sweep (53/88/135/389/445/464/3268), the residual-causes list when port 389 is open (AD DS service, time skew, stale computer object), and the common pitfalls (disabled firewall left off, public DNS resolver, 389-vs-636 confusion).

Systems Admin

Troubleshoot “Your Computer Could Not Be Joined to the Domain” Error

The 'maximum number of computer accounts' error comes from ms-DS-MachineAccountQuota, the domain-wide AD attribute that limits how many machine accounts any single authenticated user can create (default: 10). This article walks the four ways to fix it: delegate Create Computer Objects on the OU (recommended), raise the global quota in ADSI Edit (with caution), use a domain admin account (lazy), or reset/delete a stale computer object that is in the way. Includes the post-change replication step and the common pitfalls (setting the quota to 0, delegating to Authenticated Users, forgetting orphan objects, wrong default OU).

Systems Admin

Troubleshoot On-Premise Active Directory (DNS Edition)

The three most common AD-DNS failure modes and how to fix each: clients pointing at the wrong DNS server (point at a peer DC + loopback, never the DC's own external IP); the AD-integrated zone gone missing (recreate as Primary AD-integrated, restart Netlogon to re-register SRV records, verify with dcdiag /test:dns); and inter-DC replication broken (repadmin /replsummary, /showrepl, /syncall /A /e /P, plus time skew and firewall checks). Includes the four-tool diagnostic kit (nslookup SRV / dcdiag / repadmin / Event Viewer Directory Service) and 7 common pitfalls.