JUMP TO SECTIONChoose a lesson section
What you'll be able to explain.
- 01Explain how Windows Server, server roles, features, services, applications, and the underlying VM or host differ.
- 02Choose appropriate administration tools and understand when Server Core or Desktop Experience is relevant.
- 03Trace common dependencies for domain controllers, file servers, and application servers without assuming every deployment is identical.
- 04Gather read-only evidence from Windows features, service status, event logs, DNS, storage, and TCP connectivity.
- 05Propose an authorized change and validate the affected business workflow rather than relying on a green health indicator.
What does Windows Server actually do?
Windows Server is an operating system for hosting infrastructure services and business workloads. The machine might be physical or virtual. A healthy hypervisor, booted guest, and responsive IP address are different layers of availability; none proves the user's application can complete its job.
Host and guest
The hardware or hypervisor provides CPU, memory, virtual disks, and network paths. A VM that is powered on can still have a corrupt application configuration or a stopped service.
Operating system
Windows Server manages local users and security, processes, services, filesystems, drivers, network configuration, and system logs. It provides the platform on which workloads run.
Business workload
A domain controller, shared file service, IIS site, or vendor application serves a specific need. Its health must be proven at the client and workflow level, not just in a host dashboard.
Host: Hypervisor healthy → VM powered on
Guest: Windows booted → network reachable
Service: Application worker stopped → request fails
Business: Finance Portal unavailable → user impactOperational takeawayTreat 'server online' as the beginning of an investigation, not the conclusion. Start with the failed business action and move through its dependencies.
Roles, features, services, and applications are not interchangeable.
A role describes a server's primary responsibility. Features supply supporting capabilities. Windows services are managed processes or service-hosted components; an application can depend on many of them. Installation state, startup configuration, runtime status, and actual functionality are four different questions.
Server roles
Examples include Active Directory Domain Services (AD DS), DNS Server, File and Storage Services, and Web Server (IIS). Installing a role configures capabilities; it does not automatically prove the role is configured correctly or safe for production.
Features and role services
Features can supply supporting tools or technologies, and some roles include optional role services. 'Installed' tells you about a capability, not that every dependent service is running or reachable.
Windows services
The Service Control Manager tracks service states such as Running and Stopped, startup configurations, and dependencies. Some healthy services run only on demand; not every stopped service is a failure.
Get-WindowsFeature | Where-Object Installed
Get-Service | Sort-Object Status, Name
Get-Service -Name W32Time | Format-List Name,Status,StartTypeOperational takeawayNever enable, disable, or restart a service solely because it appears stopped. Correlate its expected startup behavior and workload purpose with logs and the original symptom.
You can administer a server without opening an RDP session.
Choose the management surface that gives useful evidence with the fewest permissions and least disruption. The exact availability of tools depends on installed roles, remote management configuration, operating system version, and authorization.
Server Manager and RSAT
Server Manager can manage roles and features and connect to multiple machines. RSAT provides role-specific consoles from an administrator workstation; installing a console does not install its corresponding server role.
PowerShell and native consoles
Use read-only cmdlets such as Get-WindowsFeature, Get-Service, Get-WinEvent, and Test-NetConnection to gather targeted evidence. MMC tools such as Event Viewer and Services remain useful where appropriate.
Windows Admin Center and Server Core
Windows Admin Center offers browser-based administration where deployed. Server Core omits the full desktop shell and encourages remote/command-line management; Desktop Experience includes a traditional graphical interface. Select an installation option according to workload support and operating requirements.
What service or user transaction failed?
Can I collect the evidence remotely?
Does this step require elevated permissions?
Do I have the approved target and change scope?Operational takeawayRemote management reduces unnecessary interactive logons, but it is not an authorization shortcut. Use least-privilege credentials and approved management channels.
One server can host many different failure paths.
Select a Northstar Services server role in the interactive explorer. Toggle individual signals to see why a running VM or successful ping is never enough. Each example is illustrative; real deployments can distribute roles across several servers.
Domain controller
AD DS, DNS-based domain controller discovery, Kerberos, LDAP, replication, and time all interact. DNS is frequently hosted on domain controllers but is not mandatory on every one.
File server
Share configuration, SMB listeners, NTFS and share permissions, storage paths, identity, and client access influence whether files can actually be opened.
Application server
An IIS site or line-of-business service can require its application pool, runtime, certificate, back-end database, DNS, and network paths. A healthy Windows service does not guarantee a working HTTP transaction.
Server Dependency Explorer
Select a server role and inspect the evidence layer by layer. Nothing connects to a real server.
Hosts a fictional employee portal that depends on an application runtime and a backend service.
Inspect at least three signals to form a defensible initial hypothesis. The full dependency chain matters more than any single green indicator.
Operational takeawayFollow the dependency graph toward the failing user transaction. A signal narrows the search; it rarely establishes root cause on its own.
Collect signals that answer specific questions.
Build an evidence chain from scope and timestamp to the suspected dependency. Compare a known-good baseline if available. Use commands on systems you are permitted to inspect; some require elevated rights or particular modules.
Service and feature state
Check whether a role is installed, whether its relevant service exists, and the service state. Also review startup type and dependencies before interpreting a Stopped result.
Logs and resources
Event Viewer or Get-WinEvent can correlate service failures to the affected time. Check disk space, CPU/memory pressure, storage alerts, and recent configuration or update events.
Connectivity and application validation
Confirm the name resolves to the intended target, whether the relevant TCP port is reachable, and whether the actual application or user action works. Ping alone is not a substitute for these tests.
Get-WindowsFeature | Where-Object Installed
Get-Service -Name W3SVC
Get-WinEvent -FilterHashtable @{LogName='Application';StartTime=(Get-Date).AddHours(-1)} -MaxEvents 20
Resolve-DnsName portal.northstar.example
Test-NetConnection portal.northstar.example -Port 443
Get-Volume | Select-Object DriveLetter,FileSystemLabel,SizeRemainingOperational takeawayThese commands gather information rather than repairing anything. A successful TCP handshake confirms network reachability to a port, not whether the application returns correct data or authorizes the user.
Changes need an owner, a scope, and a way back.
Even simple restarts can disconnect sessions, interrupt stateful workloads, or mask underlying faults. A safe operator distinguishes read-only diagnosis from production-changing actions and verifies that the proposed fix addresses the actual failure.
Before
Identify affected users and workload, service dependencies, maintenance restrictions, current backups, change approval, escalation contacts, and rollback or recovery options.
During
Record a baseline and start time. Perform only the approved, targeted action, preserve evidence, monitor for unexpected impact, and stop when guardrails fail.
After
Recheck relevant service state, errors, resource levels and client connectivity. Ask the application owner to repeat the original transaction and document both technical and business acceptance results.
Operational takeawayAn appropriate restart may be part of the approved recovery plan; it is not the default diagnostic step.
Ticket: The portal is unavailable, but the VM is healthy
- The hypervisor reports VM APP-02 as running, with no host alerts.
- APP-02 responds to ICMP; users get HTTP 503 from the portal.
- A service dependency failure appears in the Application log after a deployment.
- A colleague suggests rebooting the VM immediately.
Preserve the incident timestamp and deployment context, check the application pool and required service dependencies, verify the failure in logs, and coordinate a targeted authorized remediation. Do not reboot simply because infrastructure health is green.
A reboot can alter evidence and disrupt healthy workloads without correcting a missing dependency. Validate a real portal transaction after the approved repair.
A repeatable closeout beats a lucky fix.
Turn symptoms into a support record that another technician could reproduce. Use the same evidence → decision → verification process whether the affected component is a domain controller, file server, or application server.
Scope and baseline
Write down who is affected, what still works, when the issue began, which server and application are involved, and what changed recently.
Causal hypothesis
Record the dependency you suspect and the read-only observation that would support or disprove it. Separate confirmed facts from assumptions.
Validation and handoff
Capture the approved action, rollback/stop criteria, technical retest, original user workflow result, residual risk, and the handoff owner.
Symptom / scope / start time:
Confirmed signals and evidence timestamps:
Dependency or cause established:
Authorized change / owner / rollback plan:
Technical validation and user transaction:
Follow-up monitoring / outstanding risks:Operational takeawayThe goal is to explain why the system recovered, not to claim success because an alert turned green.
Can you defend the decision?
Try answering from memory before expanding each explanation. These checks support learning; they are not an exam-readiness score.
01The hypervisor shows a VM as running and the server responds to ping. Users still cannot open the portal. Is the server healthy?+
Only the host/guest availability and some network reachability have been established. Investigate the portal listener, application service or pool, dependencies, event logs, and an actual request before concluding that the business workload is healthy.
02A server has the IIS role installed, but the website responds HTTP 503. What does the installed role prove?+
Only that the relevant role or feature is installed. It does not prove the site, application pool, application dependencies, or backend systems are functioning. Review their state and error evidence at the incident time.
03Get-Service shows a service as Stopped. Should you enable and start it immediately?+
No. Some services use manual or trigger-start configuration and can be healthy while stopped. Confirm the service's purpose, expected state, dependencies, events, change scope, and operational impact.
04How are Server Manager, RSAT, and Windows Admin Center different?+
Server Manager provisions/manages Windows Server roles and multiple servers; RSAT supplies role-specific administration tools on supported management devices; Windows Admin Center is a separate browser-based management solution where deployed. None removes the need for authorization.
05What does Test-NetConnection -Port 443 demonstrate when TcpTestSucceeded is True?+
A TCP connection to that endpoint and port succeeded from the tested client. It does not establish the correctness of TLS, authentication, an HTTP response, or the original user workflow.
06After restarting an approved service, Event Viewer shows no new errors. May the incident be closed?+
Not from that fact alone. Retest the affected endpoint and original business transaction, review dependent components, confirm owner/user acceptance as appropriate, and document the result.
Read from the source.
Vendor procedures depend on product version, hardware compatibility, and the environment's approved change controls. Verify the current documentation for any production task.