Entry-Level Systems Administrator Interview Preparation Guide (FAANG Standards)

I’d facilitate the conversation around the shared objective first, because people usually disagree on solutions, not the user problem.

My approach:

• Restate the goal and the decision we need to make.
• Ask each function to explain what they need and why.
• Separate must-haves from preferences.
• Use clear criteria: user impact, effort, risk, and release timing.

Then I’d surface the trade-offs openly: if we choose the designer’s version, what slips? If we choose engineering’s approach, what user value do we lose? That makes the decision concrete instead of political.

If the team still can’t align, I’d make the call based on the agreed criteria and explain the rationale. I’d also make sure the decision is documented so nobody feels blindsided later.

What matters most is tone: I’d be firm on the decision but respectful of every viewpoint. People can disagree and still feel heard, which protects the working relationship after the release.

Worked example
Say the release in question is an onboarding redesign: the designer wants a fully polished new flow with custom illustrations and micro-interactions, while engineering proposes a simplified version that reuses existing components to hit the release date. Scoring both against the agreed criteria (user impact, effort, risk, release timing) shows the simplified version delivers most of the user-impact gain at a fraction of the effort and with no timeline risk, while the fully polished version would slip the release by three weeks for a comparatively small additional lift in user impact. So the simplified version ships first, and the custom illustrations and micro-interactions move into a fast-follow scoped for the next release, which is the trade-off made concrete instead of staying a hypothetical "what if."

Direct answer

A migration of this scale, 5 million users, succeeds or fails on one design choice made early: which credential-handling model connects the existing Active Directory, the on-premises directory holding every user's password and Kerberos identity, to the cloud identity provider (IdP), since that choice determines how much on-premises infrastructure has to stay up, how fast a password change actually propagates, and what happens during a cloud outage. The three options, synchronizing password hashes, pass-through authentication that checks passwords against on-premises Active Directory in real time, and full federation to a separate identity system, trade off differently on latency, on-premises dependency, and blast radius, and the safest migration keeps Kerberos-dependent legacy services working throughout by exporting or bridging Kerberos trust rather than trying to eliminate it before every legacy service has actually been moved off it, cutting over the user population in small, reversible waves rather than one global event.

Structured elaboration

• Credential handling options.
  • Password hash synchronization: a lightweight sync agent periodically synchronizes a secure hash of each user's on-premises password to the cloud identity provider, which then authenticates independently, without a live call back to on-premises infrastructure at sign-in time. This is the simplest option operationally, no dependency on on-premises availability at login time, but means a password change takes as long as the sync interval to reach the cloud side, and it does not, by itself, preserve Kerberos-based single sign-on (SSO) to on-premises legacy services, since Kerberos still needs the on-premises domain controller.
  • Pass-through authentication: sign-in requests are validated by the cloud provider calling back to lightweight on-premises agents, which validate the password directly against Active Directory in real time. A password change is effective the instant it's made on-premises, but sign-in now depends on the on-premises agents being reachable, so an on-premises outage becomes a cloud sign-in outage too.
  • Federation: the cloud identity provider hands off authentication entirely to a separate, trusted identity system, traditionally Active Directory Federation Services or a third-party federation provider, which has full control over authentication logic, custom multi-factor authentication (MFA) requirements, smart-card login, custom conditional logic, at the cost of the most on-premises infrastructure to build, secure, and keep highly available, since a federation-service outage is a full sign-in outage.
  • Choosing for this migration: for a population this large, password hash synchronization is the lowest-risk starting point for the majority of users, since it removes on-premises availability from the sign-in critical path; pass-through authentication or federation are reserved for populations with a specific requirement hash sync can't satisfy, a compliance rule against passwords ever leaving the premises even as a hash, or a custom multi-factor requirement federation already implements. Multiple methods can coexist for different user populations during migration; they don't have to be an all-or-nothing organization-wide choice.
• Kerberos interoperability and export strategies. This migration is explicit that Kerberos-based services must keep working, which means the plan cannot simply retire Active Directory the moment users are synced to the cloud. Two complementary approaches: first, keep a right-sized on-premises Active Directory presence alive specifically to keep issuing Kerberos tickets for legacy services, even after most users authenticate to cloud-facing applications through the cloud identity provider, treating Kerberos-dependent legacy services as their own migration track with their own timeline, separate from the user-authentication migration. Second, for legacy services that can be migrated off Kerberos, front them the same way a legacy web application without modern federation support would be handled, a gateway or agent translating a modern token into whatever the legacy service expects, which is the path that eventually lets the on-premises Kerberos infrastructure be retired rather than kept alive indefinitely as a permanent parallel system.
• Staged cutover with rollback. Migrate in cohorts, by business unit, office, or a similarly natural population boundary, never the whole 5 million at once. For each cohort: provision the cohort in the cloud identity provider and enable the chosen credential-handling method for their accounts while their existing on-premises sign-in path remains fully functional in parallel; run a defined validation window, see testing below, with real users in that cohort using the new path for non-critical access first; cut the cohort's primary sign-in over to the new path, keeping the old path disabled but not deleted for a defined rollback window, so a serious problem discovered just after cutover can be reversed by re-enabling the old path rather than needing to be fixed forward under pressure; only after a cohort has been stable on the new path past its rollback window does its old path get permanently retired.
• Syncing group memberships and policies. Group memberships, which drive both application access and Kerberos-based authorization to some legacy services, need to replicate to the cloud identity provider on a cadence tight enough that a change made on-premises is reflected in the cloud side before it would matter operationally, not just eventually. Validate this specifically as part of cutover testing rather than assuming the sync mechanism's default interval is good enough for every group, since a slow-to-sync removal from a privileged group is a more serious problem than a slow-to-sync addition.
• Testing and validation strategies. Before any cohort's real cutover, validate, for a representative sample of that cohort's actual accounts: sign-in succeeds through the new credential-handling path; group-membership-driven access matches what it was on the old path, so no user gains or loses access as a side effect of the migration itself; every Kerberos-dependent legacy service that cohort actually uses still authenticates correctly, since this is the requirement most likely to be silently broken by an incomplete migration; and the rollback path itself has actually been exercised at least once before relying on it, not just designed on paper, since a rollback plan that's never been tested is a plan that fails at the worst possible moment.
• Minimizing user disruption and authentication issues. Communicate to each cohort specifically, ahead of their cutover, what will change and what to do if something doesn't work, a specific support contact, not a generic help-desk queue that doesn't know this migration is happening. Schedule each cohort's cutover outside that population's peak usage window where the business allows it. Keep the previous path's credentials and configuration valid but inactive, not deleted, through the rollback window specifically so disruption during a real problem is measured in minutes, re-enabling the old path, rather than however long it takes to diagnose and fix the new path under live pressure.

Worked example

flowchart LR
    P0[Phase 0: inventory forest, SPNs, group memberships] --> P1[Phase 1: deploy sync, pilot group]
    P1 --> P2[Phase 2: staged cutover by business unit]
    P2 --> P3[Phase 3: Kerberos interop for legacy services]
    P3 --> P4[Phase 4: full cutover, legacy AD read-only]
    P4 -.->|rollback path| P1

1. Phase 0: inventory the on-premises Active Directory forest, every service that depends on Kerberos tickets, and current group structure, to scope both the user-authentication migration and the separate Kerberos-legacy-service track.
2. Phase 1: deploy the sync infrastructure and pilot password hash synchronization with a small, low-risk group, commonly IT or security staff, validating sign-in, group-membership fidelity, and Kerberos access to the legacy services that pilot group actually uses.
3. Phase 2: staged cutover cohort by cohort, by business unit, each cohort running in parallel with its old path active, validated, cut over, and held in a rollback window before the old path is retired for that cohort.
4. Phase 3: for legacy services still depending on Kerberos after most user cohorts have migrated, address them on their own track, either keeping a minimal on-premises Active Directory presence alive specifically for Kerberos ticket issuance, or fronting them with a gateway that translates a modern credential into what the legacy service expects.
5. Phase 4: once every cohort is stable past its rollback window and the Kerberos-legacy track has either retired or explicitly kept its minimal on-premises dependency, the on-premises directory's role shrinks to exactly that remaining Kerberos-legacy purpose, if any, rather than being retired in name only while still secretly load-bearing.

A rollback from Phase 2 for any single cohort re-enables that cohort's original on-premises sign-in path, which remained configured, not deleted, specifically to make this possible without a rebuild.

Trade-offs and pitfalls

Choosing federation for the whole population by default, because it offers the most control, when hash synchronization would satisfy the actual requirement for most users adds unnecessary on-premises infrastructure and a new single point of failure, the federation service, for no real benefit; the credential-handling choice should be made per requirement, not as a single organization-wide default chosen for the hardest case. Treating Kerberos interoperability as solved just because pass-through authentication or federation technically keeps passwords validated on-premises is a common confusion: none of the three credential-handling options, by themselves, preserve Kerberos ticket issuance for legacy services, since that's a separate mechanism, the domain controller acting as a Kerberos key distribution center, that has to be explicitly kept alive or replaced, not an automatic side effect of the authentication method chosen. A rollback plan that exists only as a document, never actually exercised, is the single most common way a staged-cutover-with-rollback migration turns into an unplanned, high-pressure fix-forward event the first time a cohort's cutover has a real problem; the testing strategy in this plan deliberately requires exercising the rollback itself, not just designing it. Syncing group additions promptly while treating removals as lower priority, because the sync tooling's default behavior sometimes does exactly this, quietly recreates a privilege-creep problem during the migration itself: someone removed from a sensitive group on-premises should lose the corresponding cloud access on a timeline that matches, not lag behind it.

Baseline summary (applied immediately after provisioning)

1) SSH hardening

• Enforce Protocol 2, disable root login, use key auth only, limit ciphers/MACs, change default port optionally, enable IdleTimeout.
• Why: prevents password brute-force and limits attack surface.
• Automation: Ansible role to deploy /etc/ssh/sshd_config and restart sshd; cloud-init for first-boot key injection.

2) Account & sudo policies

• Create non-root admin group (wheel/sudo), disable direct root SSH, enforce password complexity & max reuse via pam_pwquality, set sudo to require auth and log via Defaults logfile=/var/log/sudo.log.
• Why: least privilege and accountability.
• Automation: Manage /etc/sudoers.d and PAM via Ansible; use LDAP/AD or SSSD for central auth.

3) Minimal services

• Disable/remove unused daemons (telnet, ftp, rpcbind, avahi). Use systemctl mask/disable.
• Why: fewer services = fewer vulnerabilities.
• Automation: Inventory with Ansible/systemd templates; apply disable list.

4) File permissions

• Enforce /etc/ssh ownership and perms, /etc/shadow 640 root:shadow, home dirs 750.
• Why: prevents info disclosure.
• Automation: Ansible tasks with file module and a remediation playbook.

5) Audit & logging

• Enable auditd rules for execs, auth, sudo, network changes; forward logs to central SIEM (rsyslog/Fluentd).
• Why: detects intrusion and provides forensics.
• Automation: Deploy audit.rules and rsyslog config with Ansible; use ossec/wazuh agents.

6) Kernel tweaks

• Harden network (disable ipv6 if unused, disable ip_forward, enable rp_filter, tighten net.ipv4.conf.* settings), enable ASLR, cgroup hardening.
• Why: reduces kernel-level attack vectors.
• Automation: sysctl.d files via Ansible and sysctl --system; use CIS benchmark scripts.

7) Patch policy

• Apply critical security updates within 24h, regular weekly patch window for other updates; enable unattended-upgrades for security only on non-production.
• Why: timely patching reduces exploit window.
• Automation: configure unattended-upgrades, apt/yum-cron for baseline; orchestration via Ansible/Cron + patch reporting.

Enforcement & Compliance

• Use a configuration management system (Ansible / Salt / Puppet), CIS benchmark scanning (OpenSCAP, Lynis), and remediation playbooks run in CI or on-boot.
• Maintain idempotent playbooks, automated tests (molecule), and centralized reporting for drift detection.

This baseline balances immediate risk reduction with automation to ensure consistent, auditable, and maintainable server hardening.

Situation & Immediate Triage
I treat this as high-severity: public exploit + DC role. First I confirm scope (which domains/sites/DCs, CVE details, exploitability, PoC seen), check SIEM/EDR for compromise indicators, and isolate any suspicious DCs (network ACLs, host-based firewall). I take immutable evidence—memory and disk snapshots—before changes.

Risk-based Prioritization
I score impact (AD compromise = critical), likelihood (public PoC = high) and business impact (auth services, SSO). Priority: internet-facing or management DCs, then writable GC/FSO holders, then read-only/DCs in remote sites.

Temporary Mitigations

• Block exploit vectors with firewall, IPS signatures, and network ACLs.
• Restrict admin access (just-in-time), disable nonessential services (WinRM/RDP externally), enforce MFA for all admin logins.
• Apply GPO to harden LDAP/SMB if relevant.

Expedited Testing & Safe Deployment

• Reproduce and test patch in isolated lab that mirrors AD (including FSMO roles). Use snapshot-based rollback.
• Create scripted, idempotent deployment via SCCM/Intune or WSUS in rings: test DC -> small production subset -> full rollout. Ensure patches applied during maintenance windows with PSRemoting off until verified.

Verification of AD Health
After patching each DC:

• Run dcdiag, repadmin /replsummary and /showrepl, and check event logs for replication or Kerberos errors.
• Verify SYSVOL and NETLOGON shares, DNS SRV records, and validation of Group Policy processing on clients.

Rollback & Recovery

• Maintain snapshots and system state backups for each DC. If severe issues: demote affected DC, restore from known-good backup or seize FSMO to healthy DCs, then reintroduce restored DCs after validation.

Communications
I immediately notify SOC, IT leadership, app owners, and change board with risk, timeline, mitigation steps, and expected impacts. Send hourly status updates during active response and a post-incident report with root cause, timeline, and follow-up actions (monitoring, lessons learned).

Direct answer. Build a directed dependency graph from the map, topologically order it so nothing starts before what it depends on is verified healthy, and treat truly independent branches as parallel recovery tracks. Validate each step before advancing, and when a step fails, hold everything downstream in a known state and escalate through a defined decision point rather than retrying indefinitely.

1. Build and order the graph

• List every service and every "depends on" edge from the map. Anything with no unresolved incoming edges (here, the shared database) starts first.
• Order the rest by dependency depth: services that depend only on the database, then services that depend on those, and so on. A service that depends on the external payment API doesn't block anything upstream, since nothing needs it in order to start; it just needs its own dependency confirmed before it accepts payment-related traffic.
• Two services that depend on each other (a cycle) can't be strictly ordered against one another. Treat them as one recovery unit: bring both up together, then verify the pair as a whole before opening it to traffic.

2. Find the parallel opportunity

Any two services with no dependency edge between them, direct or transitive, can recover on separate tracks. The common case here is two services that both depend only on the shared database but not on each other: once the database is verified healthy, both can start at the same time instead of one waiting on the other. Parallelizing shortens wall-clock recovery time without changing the correctness of the order, since neither branch depends on the other's state.

3. Checkpoint and verify data integrity at each step, not just liveness

"Started" and "verified healthy" are not the same thing. At each step, confirm the service isn't just accepting connections but is serving data consistent with the last known-good state (for example: row counts within an expected range, no partial-write artifacts, a plausible latest-committed-transaction time). Skipping this and checking only process liveness is how a corrupted or half-restored dependency gets silently built on top of.

Log a checkpoint (what was verified, when, by what evidence) at each step. That makes the sequence auditable afterward and lets a later step's failure be traced back to a specific, verified starting point instead of an assumption.

4. Which pieces can stay in a degraded state while others recover

Not everything needs to be fully healthy before it's usable. A service that only reads reference data from the shared database can often be brought up in a degraded, read-only mode as soon as the database is verified, well before every other service has finished its own recovery. The service that depends on the external payment API is a good candidate to deliberately hold in a degraded state (accept and queue requests, decline new payment attempts) until its own dependency check passes, rather than blocking the rest of the sequence on an external system nobody on the recovery team controls.

What counts as an acceptable degraded state is a business call as much as a technical one: it depends on what each function actually needs to deliver during the outage, not on what's technically possible to bring online.

5. Handling a failed step

Define a bounded number of retries with a real timeout, not an indefinite retry loop; retrying against a dependency that isn't going to recover in that window just burns time. When the bound is hit, hold everything downstream of the failed step in its current state and escalate to a named decision point (the recovery coordinator, or the owner of the affected business function) who chooses between: wait longer, fail over to an alternate path if one exists, or proceed with dependents running in a degraded mode that doesn't require the failed step. Whatever is decided gets logged with the reasoning, same as the checkpoints, so a later review can tell what was planned and what was improvised under pressure.

Worked example

Map: shared-database (no dependencies); service-A and service-B (both depend only on shared-database, not on each other); service-C (depends on service-A); service-D (depends only on the external payment API).

Order: shared-database first. Then service-A and service-B in parallel, since neither depends on the other and both only need the database. service-C waits specifically for service-A's checkpoint to pass, and can start while service-B is still on its own track. service-D can be started any time after the database step but is deliberately held in a degraded (read-only or queued) mode until the external payment API's own health check clears, since that dependency is outside the team's control.

If service-A's checkpoint fails (health check passes but the row-count integrity check does not), service-C does not start. service-C's traffic is held, service-A is retried up to the defined bound, and if it doesn't clear, the recovery coordinator escalates: either fail service-A over to a secondary if one exists, or accept that service-C runs in a reduced-functionality mode that doesn't need service-A's data, whichever gets the organization to an acceptable state fastest.

Trade-offs & pitfalls. The most common wrong turn is treating "process is up" as "safe to build on top of": a liveness check is not a correctness check, and skipping the integrity checkpoint is how a downstream service inherits a silently corrupted starting point. Being too conservative (fully sequential, no parallel tracks) wastes recovery time when the graph has real independence in it; being too aggressive (parallelizing across an actual dependency edge) risks starting a service against data that isn't there yet. The graph should decide what's parallelizable, not intuition. And a dependency map that looks authoritative but isn't kept current is worse than no map at all, because it gives false confidence about what's actually safe to run in parallel.

Primary factors that influence a backup retention policy

• Compliance & regulations: statutory retention periods (e.g., SOX, PCI-DSS, local finance laws).
• Business requirements: RPO/RTO expectations, audit needs, reporting periods.
• Storage cost & budget: tiered storage, egress, snapshot count limits.
• Restore frequency & speed: how often data is restored -> keep recent copies on fast storage.
• Legal hold / eDiscovery: ability to suspend deletion for litigation or audit.
• Data classification & sensitivity: encrypt, separate retention for PII vs. logs.
• Operational considerations: backup window, retention management complexity, verification.

Concrete example: Finance application (7-year record requirement)

• Daily backups: retained 90 days on primary fast storage (block/snapshot).
• Weekly backups: retained 1 year on warm object storage.
• Monthly backups: retained 7 years (required by finance regulations) on cold archive.
• Yearly full exports: retained 7 years immutable + tagged for audits.
• Legal hold: ability to flag any backup set to prevent lifecycle transitions/deletion.

Lifecycle transitions (implementation example, AWS-style)

• Daily snapshots -> after 7 days copy to S3 Standard-IA for 83 days -> after 90 days transition to S3 Glacier Flexible Retrieval.
• Monthly snapshots -> immediately copy to S3 Glacier Deep Archive with Object Lock (governance/compliance) and retention set to 7 years.
• Implement automation with lifecycle rules and backup tool hooks (e.g., AWS Backup, Velero, Veeam) and integrate legal-hold via tags/locks to override deletion.
• Monitor with alerts for approaching expirations and periodic restore tests to validate retention.

Direct answer
When a client keeps retransmitting its SYN and never sends the final ACK (while the server's SYN-ACK is only retransmitted once before the connection times out), the most likely causes are that the client's connect timeout hasn't fired yet, that something between the two hosts is dropping the ACK specifically (an asymmetric path or a stateful device confused about direction), or that the client-side application itself never actually attempted the ACK due to a bug. A different failure shape, the server sends SYN-ACK and the client immediately sends RST, points to a different family of causes entirely: the client rejecting the connection outright.

Structured elaboration
For the "client retransmits SYN, no final ACK" pattern, work through causes in order of likelihood:

1. Asymmetric routing dropping only the return-to-forward-direction ACK path. If the SYN-ACK reaches the client (we know it does, since the client keeps retransmitting new SYNs rather than giving up, meaning it IS getting a response of some kind) but the client's ACK can't get back to the server along some other path, a stateful firewall or NAT device on that asymmetric path may be dropping the ACK because it doesn't recognize the connection's state in that direction.
2. A middlebox is rewriting or dropping specific TCP options in the SYN-ACK that the client's stack doesn't handle gracefully, causing it to silently discard the SYN-ACK and retry instead of ACKing it.
3. Client-side firewall or security policy is specifically blocking outbound ACKs to that destination while permitting the outbound SYNs, an unusual but real misconfiguration.
4. MTU (Maximum Transmission Unit)-related silent packet loss on the SYN-ACK's return path if it happens to be an unusually large segment (rare for a SYN-ACK specifically, since it typically carries little payload, but worth ruling out if other symptoms point that way).

For the different shape (SYN-ACK followed by an IMMEDIATE client RST): this usually means the client-side application decided, upon establishing the connection, that it doesn't actually want it, for example an application-level timeout that already expired while the handshake was in flight, a client-side connection pool that raced two connection attempts and is aborting the loser, or a security tool on the client actively resetting connections that don't match an expected certificate or policy.

Worked example
To distinguish these hypotheses in practice, compare timestamps and evidence on BOTH ends: if the server's capture shows the SYN-ACK leaving on time but the client's capture never shows it arriving, the problem is in the path (asymmetric routing, a device eating it). If the client's capture shows the SYN-ACK arriving cleanly but no ACK is ever generated by the client's own stack, the bug is on the client host itself (application logic, local firewall) rather than the network path.

Trade-offs & pitfalls
A common mistake is assuming a stuck handshake is always a network problem; a client-side timeout race (the application gives up right as the handshake completes) produces an outwardly identical-looking symptom to a network drop and is only distinguishable by comparing what each side's own capture actually shows, not by reasoning about the network path alone.

A bug that only appears under heavy load needs a test harness that can manufacture load deterministically, since waiting for production traffic to happen to trigger it again is not a repeatable investigation.

Building the harness

1. Synthetic traffic generation at a controlled, repeatable concurrency and request mix (a load-testing tool driving realistic request shapes, not just raw throughput).
2. Seed shared state deterministically (fixed starting data, fixed random seeds where the system uses randomness) so the only varying factor between runs is scheduling/timing, not also data variance.
3. Concurrency controls and deterministic schedulers where available, to bias the interleaving toward the suspected contention point rather than relying purely on load volume to eventually hit it.
4. Time manipulation (accelerating or controlling clock-dependent logic) when the bug involves timers, TTLs, or scheduled work, so you don't need to wait real-world hours to observe a time-triggered condition.
5. Minimize noise, prove causality: run the same load profile with and without the suspected contributing factor (a specific code path enabled/disabled, a specific config toggled) and compare failure rates statistically rather than trusting a single run either way.

A concrete run

Suppose the suspected bug is a cache-eviction race that only shows up under heavy concurrent writes. Running the harness at a fixed seed (seed=42) and concurrency=20 reproduces the race 0 times in 50 runs; the same harness at concurrency=200 reproduces it in 12 of 50 runs, a clear, statistically meaningful signal that concurrency level, not chance, drives the failure, and a concrete number, 12 of 50 at 200 versus 0 of 50 at 20, a reviewer can rerun and check rather than take on faith.

Applying this without dedicated load-test infrastructure

A single server that fails intermittently under heavy load, or that can't reproduce in staging, benefits from the cheaper version of the same idea: increase load safely on that one host (careful, bounded synthetic load) while capturing fine-grained logs/traces, rather than waiting for the next natural production spike.

Trade-offs and pitfalls

Synthetic load rarely matches production traffic shape exactly (arrival patterns, payload variety, cache warmth); the harness's value is in reliably reproducing the class of failure for iteration, not necessarily reproducing the exact production timeline, so a fix validated only against synthetic load still needs confirmation against real traffic before being called durable.

Brief approach
Show PowerShell commands to enable RDP, require NLA, restrict firewall to 10.10.0.0/16, and start the service. Also give equivalent GUI steps and mention policy/service changes.

PowerShell (run as Administrator)

# Enable Remote Desktop
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" -Value 0

# Require Network Level Authentication (NLA)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "UserAuthentication" -Value 1

# Disable built-in Remote Desktop rules (to avoid allowing everyone)
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Where-Object {$_.Direction -eq "Inbound"} | Disable-NetFirewallRule

# Add firewall rule allowing RDP only from 10.10.0.0/16
New-NetFirewallRule -DisplayName "Allow RDP from 10.10.0.0/16" -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow -RemoteAddress 10.10.0.0/16 -Profile Any

# Ensure Remote Desktop Service is running and starts automatically
Set-Service -Name TermService -StartupType Automatic
Start-Service -Name TermService

GUI steps

• Open System Properties (Win + Pause → Remote settings) → Remote tab:
  • Select "Allow remote connections to this computer"
  • Check "Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)"
• Open Windows Defender Firewall with Advanced Security → Inbound Rules:
  • Disable existing Remote Desktop inbound rules
  • New Rule → Port → TCP 3389 → Allow the connection → Scope tab: under "Remote IP address" add 10.10.0.0/16 → Name the rule

Group Policy (for domain or local policy)

• Path: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security
• Enable "Require user authentication for remote connections by using Network Level Authentication"

Service / policy notes

• Remote Desktop requires the TermService (Remote Desktop Services) running.
• If managed by domain GPOs, enforce NLA and firewall restrictions via Group Policy to prevent local changes.
• If using Azure/other cloud, ensure NSG or cloud firewall also restricts the source CIDR.

Direct answer

When packet loss is reported but interface counters on the involved devices show no errors, look above and below where standard counters measure: transient microbursts and per-queue tail drops that come and go faster than a counter's polling interval can capture, QoS shaping or policing discarding traffic by policy rather than by fault, and hardware-level buffering behavior (bufferbloat, offload features) that hides the real picture from a simple errors/drops counter.

Structured elaboration

1. Understand what standard interface counters actually measure, and their blind spot: most polled counters (SNMP or show interface) sample at intervals of seconds; a microburst that fills a queue and causes a tail drop for a few milliseconds, then clears, can produce zero visible increment in a counter polled every 30 or 60 seconds, even though real packets were genuinely dropped.
2. Look for per-queue, high-resolution telemetry instead: many modern switch ASICs expose per-queue drop counters (as opposed to aggregate interface-level counters) at a finer resolution; if available, these can reveal drops on a specific priority queue that never surface in the aggregate interface statistics.
3. Check whether QoS shaping or policing is discarding traffic by design, not by fault: a policer enforces a committed rate and deliberately discards or remarks traffic above that rate at ingress, usually incrementing a policy-specific counter (a conform/exceed/violate counter on the policy-map) rather than the generic interface error/drop counter an engineer checks first; a shaper, by contrast, delays and queues excess traffic rather than dropping it outright, so it manifests as added latency and jitter rather than loss, unless its own buffer also overflows. A recent QoS policy change (a lowered committed rate, or a class reclassified into a stricter policer) is a common, entirely policy-driven cause of loss that will never show up as an interface error.
4. Consider bufferbloat as a related but distinct pattern: an oversized buffer does not drop packets outright, but holds them long enough to inflate latency dramatically under load; this can look like loss to an application with a tight timeout (the packet was never actually dropped, but arrived too late to be useful), so distinguish true loss from excessive queuing delay using timestamps, not just counters.
5. Check for hardware offload masking the real picture: some NICs and switch ASICs handle certain processing (checksums, some queueing decisions) in hardware in ways that are not reflected in the counters the OS or standard management interface exposes; a discrepancy between what the application experiences and what standard counters report can be a sign that the relevant activity is happening below where those counters look.
6. Correlate timing precisely: gather the highest-resolution telemetry available (ASIC-level counters, per-queue stats, or policy-map conform/exceed/violate counters if accessible) and correlate the exact timestamps of reported application-level loss against any spike in queue depth, utilization, or policing activity at that same moment, even a spike too brief for a standard 30-second poll to register.

Worked example

An application reports occasional lost requests. Standard show interface counters on every device in the path show zero errors or drops over the reporting period. The policy-map attached to that egress interface, however, shows a nonzero and growing exceed counter under a QoS policer applied to this traffic class; a recent change lowered the committed rate for that class as part of a broader capacity reallocation. Enabling per-queue statistics on the relevant egress interface (polled every 1 second instead of every 60) corroborates this, showing brief spikes where the policed class's queue hits its maximum and experiences tail drops lasting under two seconds, precisely correlated with the timestamps of the application's reported failures; neither the standard 60-second interface counters nor a naive check of the interface's own drop counter would have surfaced this, since the drop is a deliberate policy action recorded in a QoS-specific counter.

Trade-offs & pitfalls

'The counters are clean' is often treated as proof there is no network-side loss, but standard interface counters have a real, specific blind spot for both short-duration events and policy-driven drops recorded elsewhere (in QoS policy-map counters, not the interface's own error/drop counters); before concluding the network is innocent, confirm you have looked at the highest time-resolution telemetry actually available on that hardware, and at any QoS policy applied to the affected traffic class, not just the generic interface counters. Distinguishing true drops (tail drop, policing) from bufferbloat-induced delay matters because the fixes are different: one calls for capacity, queue-management, or policy-rate changes, the other for buffer-sizing and queue-discipline tuning.