WSA M19: Troubleshooting & Migration

Effective troubleshooting is a discipline, not a knack. A repeatable method keeps you from thrashing: you isolate the real problem instead of randomly changing things and hoping.

The five steps. Identify the problem precisely (what is failing, for whom, since when). Research by gathering logs and recent-change history. Hypothesize a probable cause. Test that theory with a single, reversible change. Resolve by implementing and verifying the fix, then documenting it.

The habits that make it work. Document everything (symptoms, changes, results). Change one thing at a time so you can attribute the result. Check the simple things first (cables, power, DNS) before deep analysis. And compare against a known-good baseline, half of "broken" is really "different from what worked."

Windows Server ships with four graphical diagnostic utilities, and the skill is knowing which one answers your question rather than opening them at random.

The four tools. Event Viewer holds the System, Application, and Security logs, it tells you what happened and when. Resource Monitor shows real-time CPU, memory, disk, and network, it tells you what is busy right now. Reliability Monitor plots a stability timeline, it tells you when things started breaking and what changed around then. The Best Practices Analyzer checks installed roles against Microsoft's baselines, it tells you what is misconfigured.

Reach order. For a sudden failure, start with Event Viewer and Reliability Monitor to find the moment and the change; for a performance complaint, start with Resource Monitor; for "is this role set up right," run the BPA.

Beyond the GUI, a handful of PowerShell one-liners answer the most common triage questions in seconds, which is what you actually reach for during an incident.

The four go-to checks. Pull the recent critical and error events from the System log to see what the box is complaining about. Check live memory pressure with a performance counter. Confirm a service is reachable by testing the specific TCP port. Verify name resolution is returning the right address. Together these cover "is something logged, is it starved, is the port open, is DNS right," which is most first-pass triage.

Network connectivity problems are fastest to solve when you test one layer at a time, from basic reachability up to the specific port and name. Five tools cover almost everything.

The five tools. ping checks basic Layer-3 reachability. tracert shows the route and reveals where a path stops. pathping combines the two and reports packet loss per hop, ideal for intermittent problems. Test-NetConnection is the modern tool that checks whether a specific TCP port is reachable (not just the host). nslookup / Resolve-DnsName confirm DNS is returning the right answer.

The order. Ping the host; if that works but the app fails, test the port; if the name fails, check DNS; if a remote host is unreachable, trace the route to find the hop that drops it.

Most "the network is down" calls trace to a short list of recurring causes. Knowing them turns a vague complaint into a quick checklist.

The usual five. An IP address conflict (two hosts, one address) causes intermittent drops. DNS misconfiguration breaks name resolution even when the network is fine. A firewall silently blocking the port looks like the service is down. VLAN or subnet mismatches put hosts that should talk on segments that cannot. MTU problems cause large packets to fail while pings succeed, the confusing "small things work, big things hang" symptom.

When two domain controllers disagree about the directory (a user exists on one but not another), replication has failed. Three failure modes account for most of it, and a small set of tools tells you which.

The three failure modes. Lingering objects are stale objects reintroduced by a DC that was offline past the tombstone lifetime. USN rollback happens when a DC is restored improperly (from a snapshot rather than a real restore) and its update counter goes backward, poisoning replication. RPC blocked at a firewall simply prevents partners from talking.

The toolkit. repadmin /replsummary for a forest-wide health glance, repadmin /showrepl for per-partner detail and error codes, repadmin /syncall to force replication now, and dcdiag /test:replications for a broader health test. Start with the summary, then drill into the failing partner's error code.

Authentication failures surface as confusing logon errors (events 4625 and 4771) that rarely name the real cause. A standard toolkit narrows it to DC discovery, ticket state, or a name-mapping problem.

The triage tools. nltest /dsgetdc: shows which domain controller is actually servicing a client (a wrong or unreachable DC explains many failures). klist displays the current Kerberos tickets, missing or expired tickets point at time or trust problems. setspn -L lists Service Principal Names, and a duplicate or missing SPN is the classic cause of Kerberos failing for a service. Event ID 4771 in the Security log records Kerberos pre-authentication failures with a result code that names the reason.

Once you suspect a specific domain controller, you confirm its replication health and its place in the topology, because authentication depends on a healthy, discoverable DC (and a reachable Global Catalog).

Pinpoint the failure. Get-ADReplicationFailure -Target on a named DC returns the specific replication failures affecting it, turning "auth is flaky" into a concrete error on a concrete partner.

Confirm discovery and topology. nltest /dsgetdc: verifies which DC the domain hands out for a client, and listing all DCs with their site and Global Catalog status confirms there is a reachable GC in the client's site, a missing GC breaks universal-group membership resolution and thus logons.

When a server will not boot normally, Windows offers a ladder of recovery options. Choose by severity, from the least invasive that might work up to the heavier repairs.

The four options. Safe Mode boots with minimal drivers and services, ideal when a bad driver or service is the cause, since you can disable it. Last Known Good Configuration reverts the last registry control set, useful right after a change that broke startup. System Restore rolls the system back to a saved restore point. Startup Repair (from the Windows Recovery Environment) automatically diagnoses and fixes boot-sector and BCD problems.

The progression. Try Safe Mode or Last Known Good first (fast, low-risk), then System Restore, and reach for Startup Repair / WinRE command-line tools when the boot configuration itself is damaged.

When the boot configuration is genuinely damaged, the Windows Recovery Environment command line is where you fix it. Two repair sequences cover the boot record and the system files.

Boot record repair. From WinRE, bootrec /fixmbr repairs the Master Boot Record, /fixboot writes a new boot sector, and /rebuildbcd rebuilds the Boot Configuration Data store; bcdedit /enum all lets you confirm the boot entries afterward.

System-file repair: order matters. Run DISM /Online /Cleanup-Image /RestoreHealth before sfc /scannow. DISM repairs the component store that SFC pulls its known-good files from, so running SFC first when the store itself is corrupt just reports unrepairable files. For a BSOD, the minidumps under C:\Windows\Minidump analyzed with WinDbg name the faulting driver.

Backup and recovery is the last line of defense when troubleshooting cannot save a server. Two choices matter: what you back up, and how you restore it.

Backup types by what can fail. A Full Server plus System State (AD, registry, boot) protects the whole machine and its identity. Bare Metal Recovery restores to new hardware when the box is dead. Volume or File backups protect specific data.

Recovery mode by replication direction. A non-authoritative restore brings a DC back and lets it replicate from the others (rebuild a failed DC). An authoritative restore forces the restored data to replicate to the others (recover a deletion). Choosing wrong either fails to recover the object or re-deletes it.

Migrating to a new Windows Server version is a planned project, and the approach you choose trades simplicity against risk and downtime.

The four approaches. In-place upgrades the OS on the same hardware (simplest, but riskiest, no clean fallback). Side-by-side stands up a new server and migrates roles to it (clean, with the old server as fallback). Swing uses a temporary server to hold roles during the transition. Cluster rolling upgrades one node at a time so the service stays online throughout.

The tools and the discipline. Windows Server Migration Tools, the Storage Migration Service, ADMT for Active Directory, and USMT for user state each move a different layer. Whichever path you pick, the checklist is the same: inventory roles, verify compatibility, take a full backup, test in a lab, and plan an explicit rollback before you start.

The Storage Migration Service (SMS) is purpose-built to move file servers to new hosts while preserving everything clients depend on: SMB share identity, NTFS permissions, and even the source server's name and IP at cutover, so users never have to remap drives.

The four phases. Inventory scans the source servers for their shares, data, and access-control lists. Transfer copies the data and permissions to the destination. Cutover swaps the network identity (name and IP) to the new host so clients reach it transparently. Validate confirms the shares, permissions, and client resolution still work after the swap.

Why it matters. The hard part of a file-server move is not copying bytes, it is keeping the thousands of hardcoded share paths working. SMS solves exactly that by carrying the identity across, which is why it beats a manual robocopy-and-reconfigure.

Under the GUI, the Storage Migration Service is a sequence of PowerShell cmdlets that define a job and run it through the phases, which is how you script or repeat a migration.

The job lifecycle. Install the SMS proxy feature on the destination (it speeds transfers), create a named job, register the source computer and set the destination computer, then run the phases in order: inventory, transfer, and finally cutover. Each phase is its own cmdlet so you can pause, review results, and proceed deliberately rather than all at once.

This module built a complete troubleshooting and migration toolkit, from a repeatable method down to the specific commands and the safe ways to move a server.

• Methodology: Identify, Research, Hypothesize, Test, Resolve, one change at a time, documented.
• Diagnostic tools: Event Viewer and Reliability Monitor for what/when, plus dcdiag and repadmin for AD.
• Network: Test-NetConnection, Resolve-DnsName, and trace tools, tested by layer.
• Active Directory: repadmin, nltest, and klist for replication and authentication.
• Recovery and migration: Windows Server Backup with System State, and the Storage Migration Service for seamless file-server cutover.