Covers the functions, installation, configuration, management, dependencies, and troubleshooting of built in Windows Server roles, role services, and operating system features that provide server functionality. Candidates should understand common server roles such as Active Directory Domain Services, Domain Name System server, Dynamic Host Configuration Protocol server, File and Storage Services, Print Server, Remote Desktop Services, Remote Access, and Web Server. The topic includes the distinction between roles and features, examples of features such as Hyper V, Failover Clustering, and Backup components, and how roles or features may depend on one another.
Candidates should be able to demonstrate how to add and remove roles or features using graphical tools such as Server Manager and programmatic tools such as PowerShell, explain common PowerShell cmdlet workflows for installing and configuring roles and features, and describe how to manage individual Windows services that implement role functionality. Core service management knowledge includes startup types such as automatic, automatic delayed, manual, and disabled, service dependencies and startup order, service recovery settings, and common maintenance tasks such as restarting services and checking service status.
Troubleshooting and operational responsibilities include using Event Viewer and the Services console to diagnose service failures, interpreting relevant event logs, identifying dependency related startup issues, resolving port and network conflicts for role services, and applying best practices for high availability and scale such as clustering, load balancing, and role placement. Candidates may also be expected to explain backup and restore considerations for role data, permission and security implications of enabling roles and features, and basic monitoring strategies for role health and performance.
EasyTechnical
56 practiced
Provide command examples (both PowerShell and sc.exe or net.exe) you would use to change the startup type of the Print Spooler service to Automatic (Delayed Start) and then to Disabled. Show how you would verify the change both immediately and persistently across reboots.
Sample Answer
**Brief approach**Use PowerShell for native service control and sc.exe for low-level config. Verify immediately with service state queries and persistently by checking service start type and registry values that survive reboot.**PowerShell — set to Automatic (Delayed Start)**
powershell
# Configure
Set-Service -Name "Spooler" -StartupType AutomaticDelayedStart
# Start service now (if desired)
Start-Service -Name "Spooler"
Notes:- sc.exe requires the space after the equals sign: start= delayed-auto- Some PowerShell versions may not show AutomaticDelayedStart in Get-Service; use Get-CimInstance or registry to confirm DelayedAutoStart.
MediumTechnical
47 practiced
You have a role service that intermittently fails at boot due to a dependent service starting too late. Describe how to discover the dependency chain programmatically, how to safely modify startup behavior or dependencies, and recommend non-invasive production fixes (delayed start, service recovery options) rather than editing binary/service code.
Sample Answer
**Approach (what I’d do first)**- Programmatically discover the dependency chain and startup ordering.- Avoid editing binaries; change service config and orchestrate startup instead.- Apply low-risk production fixes: Delayed Automatic start, SC recovery actions, explicit SCM dependencies, or an orchestrated start script/Task Scheduler job.**Discover dependencies (Windows)**- Query SCM for declared dependencies:
- Get full chain recursively (PowerShell function: follow ServicesDependedOn and recurse) to build a graph.- Validate actual runtime ordering with Event Log (System) and Sysinternals Autoruns / Process Monitor.**Modify startup behavior safely (non-invasive)**- Add SCM dependency so MyService waits for the dependent service(s):
cmd
sc.exe config MyService depend= DepSvc1/DepSvc2
(Uses '/' separated list; quote spacing matters.)- Use Delayed Auto Start to allow other services to finish:
- If dependency cannot be declared (third-party service), create a lightweight wrapper or scheduled task to start MyService after a safe delay or on an EventID indicating dependent service started.**Why these choices**- SCM dependencies are authoritative and prevent race conditions without changing code.- Delayed start reduces boot contention with minimal risk.- Recovery options improve resilience to transient failures.- Scheduled tasks or wrapper scripts are reversible and non-invasive when vendor services lack proper dependencies.**Validation & Rollout**- Test on staging: reboot multiple times, capture System event logs, measure service start time.- Gradual rollout (one cluster/node), monitor for regressions, then wider deployment.- Document changes (tickets/CMDB) and provide rollback steps (sc.exe config depend= / clear DelayedAutostart).This approach finds the root cause, uses SCM and OS tools to control order/retries, and avoids touching binaries while providing resilient, reversible fixes.
EasyTechnical
52 practiced
Explain Windows service startup types: Automatic, Automatic (Delayed Start), Manual, and Disabled. For each startup type provide a concrete example of a role service where that startup type is appropriate and explain the operational reasoning behind those choices (boot performance, dependency order, security).
Sample Answer
**Overview**As a Systems Administrator I choose service startup types to balance boot performance, dependencies and security. Below are concise explanations with concrete role-service examples and operational reasoning.**Automatic**- Starts at boot before user logon.- Example: Windows Update (wuauserv) on a patch-management server.- Reasoning: Must be available immediately for scheduled patch checks and enforcement; dependency services likely expect it. Trade-off: increases boot time slightly.**Automatic (Delayed Start)**- Starts shortly after boot completion.- Example: Print Spooler (spooler) on general-purpose file/print servers.- Reasoning: Improves perceived boot performance; non-critical services start after core services, reducing I/O contention.**Manual**- Starts only when requested by user or dependent service.- Example: Remote Registry (RemoteRegistry) on hardened domain controllers.- Reasoning: Minimizes attack surface and resource use; start on-demand when management tools require it.**Disabled**- Cannot be started until re-enabled.- Example: Bluetooth Support Service on a rack-mounted server.- Reasoning: Security and stability — prevents unnecessary services from running or being abused; reduces maintenance overhead.Operational considerations: always review service dependencies and Group Policy/startup scripts before changing defaults; document changes and test during maintenance windows.
EasyTechnical
45 practiced
Provide PowerShell one-liners or short sequences to perform the following tasks on a Windows Server: 1) list available and installed roles/features; 2) install the Web-Server (IIS) role and include management tools; 3) remove the File-Services role and its management tools. Specify which module/cmdlets you used and why the approach is safe for automation.
Sample Answer
**Approach (brief)** Use the ServerManager module cmdlets (Get-WindowsFeature, Install-WindowsFeature, Remove-WindowsFeature). These are idempotent, return status, and support -WhatIf/-Confirm for safe automation.**1) List available and installed roles/features**
powershell
Import-Module ServerManager
Get-WindowsFeature | Where-Object { $_.InstallState -ne 'Removed' } # shows available and installed
Get-WindowsFeature | Where-Object { $_.InstallState -eq 'Installed' } # only installed
**2) Install Web-Server (IIS) with management tools**
powershell
# idempotent install; will skip if already present
Install-WindowsFeature -Name Web-Server -IncludeManagementTools -Restart:$false
**3) Remove File-Services role and its management tools**
powershell
# safe removal; use -WhatIf first in automation pipelines
Remove-WindowsFeature -Name File-Services -Remove -Confirm:$false
# recommended pre-check:
Get-WindowsFeature File-Services
**Why safe for automation**- Cmdlets are idempotent (no-op if state already matches). - Support -WhatIf and -Confirm for dry-runs. - Return structured objects for scripting checks and error handling (use ExitCode / Success properties).
MediumSystem Design
39 practiced
Plan a Remote Desktop Services (RDS) deployment to support 100 concurrent users who need secure remote access to internal applications. Specify which RDS role services you would deploy (Connection Broker, Session Host, Gateway, Licensing, Web Access), licensing considerations, high-availability options, and recommended security controls such as NPS, RD Gateway, SSL, and multi-factor authentication.
Sample Answer
**Approach summary**Design an RDS farm sized for 100 concurrent users with secure, highly available access to internal apps. Use separate roles for scale and fault tolerance; enforce strong authentication, TLS, and monitoring.**RDS role deployment**- RD Session Host: 4–6 VMs (estimate 16–25 users/host depending on app load). Autoscale/extra warm spare for peak.- RD Connection Broker: 2 servers in HA (paired with a SQL Server Always On Availability Group or Windows Server Failover Cluster) for session load balancing and reconnection.- RD Gateway: 2 instances in DMZ or perimeter subnet behind a load balancer.- RD Web Access: 2 instances behind LB (front-end for HTML5/RemoteApp).- RD Licensing: 2 separate servers (primary + standby) for redundancy.**Licensing**- Use RDS CALs (Per User recommended for telework scenarios). Purchase at least 100 Per User CALs + 1 RDS SAL for the licensing server.- Ensure proper activation of the RD Licensing role and tracking; maintain Software Assurance or SPLA as required.- If many external devices share users, Per User is simpler; Per Device only if devices are fixed.**High-availability**- Load balancer for RD Gateway and RD Web (F5, Azure LB, or NGFW LB).- Connection Broker HA via SQL AG or clustered DB for state.- Session Host pools distributed across at least two hypervisor hosts/availability zones to tolerate host failures.- Replicate RD Licensing or rely on DR procedures (licenses are stored centrally — keep backups).**Security controls**- RD Gateway as the only entry point; block direct RDP to session hosts.- SSL/TLS: Public CA SAN or wildcard certificate on RD Gateway/Web Access; enforce TLS 1.2+ and strong ciphers.- NPS (RADIUS) for centralized policy enforcement; integrate with MFA (Azure MFA Server, NPS extension for Azure MFA, Duo, or other RADIUS MFA).- Configure RD Gateway CAPs and RAPs: restrict users, allowed resources, and source IP ranges.- Enforce Network Level Authentication (NLA) and least-privilege session host group memberships.- Use conditional access: restrict by device compliance or IP where possible.- Network segmentation: place session hosts on internal subnet with limited outbound access.- Logging & monitoring: enable RD Gateway and Windows Event forwarding, SIEM ingestion, and regular audits.- Patch management, endpoint protection on session hosts, and user profile management (FSLogix or roaming profiles).**Operational notes**- Test performance under load; tune VMs (vCPU, RAM) and profile apps.- Configure user profile disks/FSLogix to reduce logon time.- Document backup/restore for Licensing, Connection Broker DB, and certificates.- Periodically review CAL utilization, update certificates before expiry, and run failover drills.
Unlock Full Question Bank
Get access to hundreds of Windows Server Roles and Services interview questions and detailed answers.