Comprehensive administration of Microsoft Windows operating systems and Windows Server platform and related infrastructure, covering day to day operational tasks, configuration, security, and infrastructure design. Core areas include Active Directory concepts such as domains, forests, organizational units, trust relationships, and identity and access management; Group Policy design, scoping, inheritance, filtering, and deployment; server roles and services such as Domain Name System, Dynamic Host Configuration Protocol, file and print services, remote access, and remote desktop services; local and domain account and group management, role based and discretionary access control, and New Technology File System permission models; registry and service management, process and service lifecycle, and performance tuning; disk management, storage configuration, volumes, and backup and recovery strategies; patching and update management and maintenance windows; network configuration and troubleshooting including name resolution, routing, and firewall basics; monitoring, logging, and event log analysis for fault isolation and operational insight; administrative interfaces including graphical user interface and command line tools and remote administration techniques; automation and scripting with PowerShell for task automation, configuration management, and operational workflows, covering both basic PowerShell commands and broader scripting patterns; and security hardening, audit, and compliance practices for Windows environments. Candidates are expected to perform and describe practical tasks such as creating and managing user accounts and groups, applying and troubleshooting Group Policy settings, configuring core services and network settings, diagnosing Windows specific operational issues, and designing Windows oriented infrastructure for reliability, scalability, and security. Deep automation and advanced scripting topics may be assessed separately where appropriate.
HardTechnical
67 practiced
Write or describe an idempotent PowerShell DSC configuration or script that ensures the DNS Server role is installed on a target server, that an AD-integrated forward lookup zone example.corp exists, and that three A records (host1, host2, host3) are present with specified IPs. Explain how your implementation avoids creating duplicates when run multiple times and how it verifies success.
Sample Answer
**Approach (brief)**Use PowerShell DSC with built-in resources (WindowsFeature and xDnsServer) or the supported DnsServer resource from the DnsServer module. DSC ensures idempotency by declaring desired state; resources compare current state and only apply changes.**Sample DSC configuration**
powershell
Configuration Ensure-DnsAndRecords {
Import-DscResource -ModuleName PSDesiredStateConfiguration
Import-DscResource -ModuleName DnsServer # Windows Server 2012R2+ / RSAT
param(
[string]$NodeName = 'TARGET-SERVER',
[string]$ZoneName = 'example.corp',
[PSCustomObject[]]$Records = @(
@{Name='host1'; IPv4Address='10.0.0.11'},
@{Name='host2'; IPv4Address='10.0.0.12'},
@{Name='host3'; IPv4Address='10.0.0.13'}
)
)
Node $NodeName {
# Ensure DNS Server role installed
WindowsFeature DNS {
Name = 'DNS'
Ensure = 'Present'
}
# Ensure AD-integrated forward lookup zone exists
DnsServerPrimaryZone Zone {
Name = $ZoneName
DynamicUpdate = 'Secure'
ZoneFile = "$ZoneName.dns"
ZoneType = 'ActiveDirectory' # AD-integrated
DependsOn = '[WindowsFeature]DNS'
}
# Ensure A records exist - create one resource per record
foreach ($r in $Records) {
DnsServerResourceRecordA "A_$($r.Name)" {
Name = $r.Name
ZoneName = $ZoneName
IPv4Address= $r.IPv4Address
Ensure = 'Present'
DependsOn = '[DnsServerPrimaryZone]Zone'
}
}
}
}
# To generate MOF and apply:
Ensure-DnsAndRecords -NodeName 'MyServer'
Start-DscConfiguration -Path .\Ensure-DnsAndRecords -Wait -Verbose -Force
**Why this is idempotent**- DSC resources implement Get/Set/Test. Before making changes, Test-TargetResource compares existing DNS role, zone, and records to desired values; Set only runs when mismatches exist.- Each A record is declared by unique resource name; DSC checks for existing record with same name and IP, so it will not create duplicates. If a record exists but with different IP, DSC updates it to the declared IP.**Verification**- DSC returns success on Start-DscConfiguration; use Get-DscConfigurationStatus and Get-DscConfiguration to inspect.- Additional checks: use Resolve-DnsName or Get-DnsServerResourceRecord: - Get-DnsServerResourceRecord -ZoneName example.corp -Name host1 - Resolve-DnsName host1.example.corp- For automation, script a Test-DscConfiguration run; Test-TargetResource will return false if drift exists.**Notes / Best practices**- Ensure DnsServer module available on target or use xDnsServer resources (xNetworking/xDnsServer) if on older platforms.- Run as account with privileges to create zones (domain join + appropriate AD permissions for AD-integrated zones).
HardTechnical
74 practiced
A privileged domain account was used to create unusual behaviour across multiple servers. Outline a forensics and incident response plan for investigating a suspected AD compromise: list which logs and event IDs to collect from domain controllers and endpoints, how to preserve evidence (timestamps, log integrity), how to identify lateral movement (Pass-the-Hash, Kerberos anomalies), and immediate containment steps while following chain-of-custody.
Sample Answer
**Situation & goal**I would treat this as a suspected Active Directory compromise involving a privileged domain account and immediately begin coordinated forensics + IR to identify scope, preserve evidence, and contain lateral movement.**Logs & Event IDs to collect**- Domain Controllers (AD / DC): Security log, Sysvol, NTDS.dit snapshot (if authorized) - Key Event IDs: 4624 (Logon), 4625 (Logon failure), 4672 (Special privileges), 4768/4769/4770 (Kerberos TGT/service ticket), 4776 (NTLM auth), 4662 (Directory service object access), 5136 (AD object modification), 1102 (audit log cleared)- Endpoints/Servers: Security, System, Application, PowerShell/ScriptBlock transcription, Sysmon - Sysmon IDs: 1 (process create), 3 (network connect), 6/7 (driver/file create), 10 (process access), 11/12 (file create/write)- Network: firewall/IDS logs, authentication proxies, Windows Event Forwarding collector logs**Preserve evidence & integrity**- Isolate affected hosts to network segment but do not power off; take live memory captures (WinPMEM), disk images (Bitlocker keys handled), and export event logs via wevtutil or EDR with timestamps preserved.- Record SHA256 hashes of images, store on write-once media, document acquisition tool, operator, date/time (UTC), and chain-of-custody form.- Ensure NTP drift check; preserve original system time metadata; collect .evtx with API to avoid truncation.**Identify lateral movement & abuse**- Look for: - Pass-the-Hash/NTLM: 4624 logons with Authentication Package = NTLM, Logon Type 3/10 from odd hosts; 4776 NTLM authentication failures/successes; unusual workstation as source for DC logons. - Kerberos anomalies: multiple/failed 4768 requests, golden ticket indicators (unusual krbtgt service ticket lifetimes), S4U2Self/S4U2Proxy misuse (4769 for service tickets). - Lateral tools: Sysmon process chains spawning psexec/wmi (wmic, winrm), suspicious remote service creation.- Correlate timeline: cross-reference 1) high-privilege logons (4672), 2) new service installations, 3) replication or AD object edits (5136/4662).**Immediate containment steps**- Disable compromised account(s) or reset credentials after collecting live session artifacts; revoke Kerberos tickets by resetting krbtgt twice (scheduled, with understanding of impact).- Implement network-level blocking between compromised hosts, isolate jump hosts, and disable remote management channels used (Admin$/SMB/RPC) only after evidence capture.- Rotate secrets and privileged credentials via privileged account management, reset service account passwords where feasible.**Chain-of-custody & legal**- Log every action in an evidence log: who, when (UTC), tool, rationale; use write-once storage; preserve original media; coordinate with legal/HR for escalation; avoid altering original data beyond necessary live captures.**Post-incident**- Rebuild compromised hosts from known-good images, harden DC auditing (Sysmon, enhanced logging), enforce LAPS/PAWs, MFA for admin accounts, and continuous EDR/SIEM alerting for the above indicators.
MediumSystem Design
63 practiced
Design a backup and recovery strategy for domain controllers and application servers that uses Volume Shadow Copy Service (VSS) and system state backups. Explain how you would perform non-authoritative vs authoritative AD restores, how to protect backups from corruption or ransomware, and the precautions around USN rollback and virtualization snapshot restores of DCs.
Sample Answer
**Approach summary**Design a VSS + System State backup plan that reliably captures AD and application server state, enables safe recovery (non-authoritative and authoritative), and defends backups from corruption/ransomware while avoiding USN rollback and bad VM-snapshot restores.**Backup architecture**- Use Windows Server Backup or enterprise backup (Veeam/Commvault) that leverages VSS writers and captures System State (NTDS, SYSVOL, registry, COM+).- Schedule nightly system-state + full VSS image; hourly application-aware VSS snapshots for apps (SQL/Exchange).- Retain multiple recovery points (GFS), replicate backups to offsite immutable storage and an air-gapped backup appliance.- Encrypt backups, use RBAC and MFA for backup admin accounts; enable backup integrity checks and automated test restores.**Non-authoritative AD restore (when DC is lost and other DCs are source of truth)**- Boot target DC into Directory Services Restore Mode (DSRM).- Restore System State from VSS backup.- Reboot normally; AD will replicate missing objects/USNs from other DCs.- Verify replication health (repadmin /replsummary, dcdiag).**Authoritative AD restore (when you must recover deleted/changed objects)**- Boot into DSRM.- Restore System State from backup.- Use ntdsutil to mark objects or entire domain as authoritative (e.g., authoritative restore of ntds.dit or specific partitions).- Reboot; the DC advertises higher USNs so changes replicate out to other DCs.- Validate restored objects and replication.**Protecting backups from corruption/ransomware**- Immutable/Write-Once storage (WORM), cloud object lock or snapshot immutability.- Offline/air-gapped copies and at least one offline backup kept for longer retention.- Separate management network and harden backup servers; enforce MFA and least privilege.- Regularly verify backup integrity and perform scheduled restore drills.- Keep backup catalog and credentials offline/segregated.**USN rollback & virtualization snapshot precautions**- Never restore a DC by reverting a VM snapshot taken after the DC joined the domain unless snapshot was created correctly and you understand replication state — snapshot revert can cause USN rollback.- If a snapshot revert is accidentally done, treat DC as corrupt: run authoritative restore or demote and re-promote.- Preferred virtualization approach: use application-consistent VSS-based backups, or use host-level tools that quiesce the guest and coordinate AD-consistent backups. For cloning in Hyper-V/VMware, use DC-safe processes (e.g., sysprep or DC cloning) and avoid rolling back replication-aware systems.- If you must restore a DC VM, restore System State instead of reverting whole disk to avoid replication inconsistencies.**Validation and runbook**- Maintain step-by-step runbooks for non-authoritative and authoritative restores, FSMO seizure procedures, and post-restore checks (repadmin, dcdiag, SYSVOL/Netlogon shares).- Quarterly tabletop and annual live restore tests.This strategy balances reliable AD/application recovery, security of backups, and operational safeguards against USN rollback and VM-snapshot pitfalls.
HardTechnical
75 practiced
Your Windows file servers have been encrypted by ransomware. Provide a comprehensive incident response and recovery plan that covers immediate containment (network isolation, account password resets), investigation steps to determine patient-zero and scope, validation of backups before restoration, legal/compliance notifications, communication plans, and long-term hardening measures to prevent recurrence.
Sample Answer
**Summary / Objectives**I would immediately contain the incident, preserve evidence, identify scope/patient-zero, validate clean backups, notify stakeholders/legal, restore services safely, and implement hardening to prevent recurrence.**Immediate containment (first 0–4 hours)**- Isolate affected file servers from network (remove from VLAN, block at switch/ACLs) but keep powered for forensics.- Disable SMB shares and related services; block RDP and admin ports at firewall.- Reset credentials for all domain/local admin accounts and any service accounts used on affected hosts; enforce MFA where possible.- Disable compromised accounts and revoke cached creds (log off sessions).**Investigation**- Preserve system images, event logs (Windows Event, Sysmon), and network captures.- Triage timeline: examine MFT, Recent Files, USN journal, scheduled tasks, shadow copies, and EDR alerts to find patient-zero and initial vector (phishing, RDP, service exploit).- Map scope: enumerate encrypted hosts, lateral movement (PSExec, WMI), and compromised credentials.- Identify ransomware strain via ransom notes, hashes, YARA, and traffic to C2.**Backup validation & recovery**- Quarantine backups; scan backup sets offline with updated AV/antimalware and test restores to an isolated environment.- Verify integrity, completeness, and last known-good snapshots; check for backup chain tampering.- Restore domain controllers first if needed, then file servers, applying latest patches before reconnecting.- Restore in batches, monitor for re-encryption, and rotate recovered credentials.**Legal/compliance & notifications**- Notify legal, compliance, and executive teams per SLA and jurisdictional breach laws (e.g., GDPR/state breach laws).- Engage cybersecurity insurer and consider law enforcement/ENISA/FBI if appropriate.- Preserve chain-of-custody for potential investigations.**Communication plan**- Provide clear internal status updates (IT, leadership, affected business units) and external messaging templates for customers if required.- Use approved channels; avoid technical speculation; assign single spokesperson.**Long-term hardening**- Enforce least privilege, remove domain admin from daily use; implement JIT/JEA for admin tasks.- Enforce MFA for all remote access and admin accounts; disable legacy auth.- Patch management, application allowlisting (Windows Defender Application Control), endpoint detection and response, network segmentation, and micro-segmentation for servers.- Regular backup verification, immutable backups (WORM/S3 Object Lock), offline copies, and disaster recovery drills.- Improve logging/monitoring (Sysmon, central SIEM), regular threat hunting, and employee phishing training.**Metrics & follow-up**- Track MTTR, time-to-detect, backup recovery success rate, vulnerabilities remediated, and lessons learned; run a post-incident review and update runbooks.
EasyTechnical
52 practiced
Describe Windows Server servicing channels and enterprise patch management options. Explain the differences between servicing channels (such as Long-Term Servicing Channel vs Semi-Annual Channel where applicable), and describe how WSUS, SCCM/ConfigMgr or Intune can be used to manage patch deployment including pilot rings, maintenance windows and emergency patching procedures.
Sample Answer
**Overview — servicing channels**- Long-Term Servicing Channel (LTSC): fixed major release (~every 2–3 years), only security/critical fixes and cumulative updates; ideal for servers with strict stability requirements (domain controllers, database servers).- Semi-Annual Channel (SAC) / Windows Server Update Services for SAC: more frequent feature releases (every 6 months historically); suited for cloud-first or test/dev workloads that can absorb change. Note: SAC use on Server has been reduced — choose LTSC for most production Windows Server roles.**Patch-management tools & how I use them**- WSUS: on-premises update catalog, approvals, target groups. Good for basic segmentation and offline environments.- SCCM / ConfigMgr: enterprise-grade deployment — phased deployments, compliance reporting, automatic distribution points, maintenance windows, and deadline-based installations. I define collections as pilot/staging/production rings and create ADRs (automatic deployment rules) for MS monthly releases.- Intune / Windows Update for Business (WUfB): cloud-managed patch policies, feature deferral, ring assignments, and reporting for modern endpoints.**Key processes I implement**- Pilot rings: create small test groups (pilot → broad pilot → production). Validate for 48–72 hours, monitor telemetry and incident tickets before wider rollout.- Maintenance windows: enforce reboot and install windows per server role (e.g., DB: weekly low-load window), configured in SCCM or via Group Policy/WUfB.- Emergency patching: documented runbook — expedited approval, push via fast-tracked SCCM collection or Intune immediate sync, after quick smoke tests; if needed, use WSUS decline/rollback or SCCM software update rollback steps.- Validation & rollback: use pre/post snapshots/backups, update compliance reports, and have playbook for hotfix uninstall or OS rollback for failed updates.This approach balances reliability, rapid response, and auditability for enterprise Windows environments.
Unlock Full Question Bank
Get access to hundreds of Windows System Administration interview questions and detailed answers.
