Active Directory Operations and recovery
Patch domain controllers and prove recovery
Check what actually installed, patch a pilot DC and test the services clients depend on before moving to the next batch.
Compliance is a sequence of states
A DC can download an update, install it, wait for a restart, fail during completion or come back with an application incompatibility. Don’t collapse all of that into “patched”. A failed or stale scan that reports “no missing updates” hasn’t told you much. Keep the scan time, source/catalog, applicable release, installation result and restart requirement with each server’s record.
First identify the exact OS edition/version and installed build/revision. Compare them with the relevant Windows Server release information and update-history links. Friendly names such as “Windows Server 2022” are insufficient when two DCs run different cumulative updates. The update’s own KB establishes prerequisites, known issues and any phased security behavior; the monthly date alone does not.
Inventory the target without mistaking one view for all updates
From a permitted administrative session, record the target’s OS and last boot:
Get-CimInstance -ComputerName 'dc1.contoso.com' -ClassName Win32_OperatingSystem |
Select-Object CSName,Caption,Version,BuildNumber,LastBootUpTime
Get-HotFix -ComputerName 'dc1.contoso.com' |
Sort-Object InstalledOn -Descending |
Select-Object -First 15 HotFixID,Description,InstalledOn
Get-HotFix uses Win32_QuickFixEngineering. That class is not a complete inventory of every update technology or application: its documented scope is CBS updates, with exclusions for other installation paths. Nor does a particular KB’s absence establish vulnerability when a newer cumulative update supersedes it. Get-HotFix and QFE inventory limits.
On the DC itself, an elevated local session can add the OS revision and servicing-package state:
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
Select-Object ProductName,DisplayVersion,CurrentBuild,UBR
Get-WindowsPackage -Online |
Select-Object PackageName,PackageState,ReleaseType,InstallTime
Read CurrentBuild and UBR together, then check the servicing/update result. Get-WindowsPackage only inspects packages; it doesn’t install one. Its reference describes the online image and returned package information. If a property is missing, access fails or a package is pending, keep that result visible in the inventory.
Put the update’s behavior into the test plan
Read the KB before deployment. Ask whether the update changes authentication, certificate validation, LDAP signing/channel binding, RPC, trust or encryption behavior. Some hardening changes involve audit/enforcement phases, client prerequisites or separate policy. Installing a fix and enabling a security policy can be distinct changes.
Select real tests for the affected paths: a certificate sign-in, cross-domain application authentication, scheduled LDAP job, older appliance or service account. A successful privileged interactive sign-in does not cover those paths. Keep relevant certificate-mapping, LDAP client audit and Kerberos encryption evidence with the pilot when applicable.
Record which clients and applications used the pilot. A disconnected lab won’t tell you whether an infrequently used production appliance still works. And if no intended application selected the pilot DC, the pilot hasn’t tested those applications. Target tests deliberately without permanently pinning all clients to that DC.
Preserve capacity and a usable recovery route
Verify replication, DNS, SYSVOL/NETLOGON and advertising before the first servicing step. Identify existing faults so they are not silently attributed to the update. Check recent usable backups and emergency administrative access; retain the previous healthy evidence and installation package/KB identifiers.
Stage the work so the required domain/site services remain available. Include the actual host/storage failure domains, applications with explicit DC targets and the extra responsibilities of a role holder. An arbitrary “half the DCs at once” rule can remove every local DNS/GC or both DCs of a small domain. Capacity planning supplies the survivor model.
If a FSMO owner is unhealthy, find out why before moving the role. Work out the supported uninstall/recovery options for the exact update and platform too; a VM checkpoint isn’t a general patch rollback plan. A directory-aware restore, rebuilding one replica and removing a package solve different problems. Restoring directory state can affect much more than the updated OS binary.
Service a pilot, then prove it is ready
Use the organization’s supported update mechanism and the current platform procedure. Server Core supports SConfig and documented command-line/management approaches; use Microsoft’s current Server Core servicing guidance for the chosen release. Complete a required restart and verify the final installation state before counting the pilot as updated.
After startup, a DC can have running services while waiting for initial synchronization or SYSVOL readiness. Check the selected DC explicitly:
dcdiag /s:dc1.contoso.com /test:Advertising /test:Services /test:SysVolCheck /v
repadmin /showrepl dc1.contoso.com
Read the exact errors against the DCDiag test definitions. These checks cover service readiness and replication, but you still need DNS responses, real policy-file access and the original application transactions. A DC configured as a GC may not be ready to serve GC requests immediately after startup.
Inspect update and service events together
For a locally available update channel:
Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-WindowsUpdateClient/Operational'
StartTime = (Get-Date).AddHours(-6)
} | Select-Object TimeCreated,Id,LevelDisplayName,Message
Correlate the update result with System, Directory Service, DFS Replication, DNS and relevant authentication/application events. Record provider, event time and full error. If servicing fails, collect the update/CBS evidence before resetting components or deleting caches; Microsoft’s Windows Update log reference explains the different sources.
A DC that returned with a cold cache may show a temporary storage/read-load increase. Compare its recovery with the measured baseline and acceptance window instead of assuming every post-reboot delay is an update regression. Sustained new failures still need investigation before expanding the batch.
Advance only after the pilot meets the gate
Decide when to stop before starting the rollout: failed service tests, new authentication errors, unexplained replication failures, unacceptable survivor load or an exceeded recovery window. If the pilot hits one of those conditions, stop the rollout and investigate. Repeatedly installing, uninstalling and restoring makes the cause harder to follow.
After each batch, check the inventory against the intended server list. Every DC needs an outcome: updated and validated, pending action, failed or deferred with an owner. Run representative client/application tests, confirm backups and remove temporary diagnostic changes before closing the work.