Welcome to InfoTech Ninja

IT professional writing about cybersecurity, cloud & DevOps, automation, networking, and systems administration. Real-world guides for real-world problems.

#Cybersecurity #Cloud #Automation #Networking #SysAdmin

Latest Articles

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

Block Windows Store, Xbox, Solitaire, or Any Built-In App with Group Policy

Remove-AppxPackage disappears the next time provisioning runs the OS image; the right tool for keeping consumer UWP apps (Microsoft Store, Xbox, Solitaire, Mixed Reality Portal) off business endpoints is AppLocker Packaged app Rules pushed by Group Policy. Walks the full GPO end-to-end: create + link a new GPO at the OU/domain root, configure the Application Identity service to start automatically (AppLocker's hard dependency), import a 132-rule AppLocker baseline XML, scope the rules with either publisher exceptions on broad Allow rules or explicit per-package Deny rules, switch enforcement mode from Audit-only to Enforce rules, gpupdate, verify on a domain-joined client (Application Identity running, Microsoft Store / Xbox / Solitaire all hit 'This app has been blocked by your system administrator'). Includes the SKU gotcha (AppLocker only enforces on Enterprise / Education, not Pro / Home), the audit-only safety net, the AppLocker event-log IDs (8020 = blocked, 8021 = would-be-blocked) for reporting, and the local-admin-bypass test trap.

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.

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.

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

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.

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

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