CTS1328C / AZ-800 · Windows Server Administration · Instructor ← Instructor Hub
CTS1328C · AZ-800

Windows Server Administration

Week 1: Foundations
M01 Fundamentals  ·  M02 Active Directory  ·  M03 Storage  ·  M04 Hyper-V  ·  M05 Containers  ·  M06 Clustering
Module 01

Fundamentals

Editions, install, manage, PowerShell
Where Windows Server fits in your stack. The four editions and which to pick. Server Core vs Desktop Experience. Server Manager + roles. PowerShell verb-noun discoverability.
M01 Fundamentals overview

Windows Server Editions

Four flavors. Pick by workload, not feature count.

The licensing question precedes the technical question.

  • Standard. Physical or lightly virtualized. Per-core + Client Access Licenses (CALs). 2 VMs included.
  • Datacenter. Heavily virtualized datacenters. Per-core + CALs. Unlimited VMs.
  • Essentials. Small business, ≤25 users. Per-server, no CALs. Limited features.
  • Azure Edition. Azure hybrid. Hotpatch, no reboots, SMB over QUIC, Azure Kubernetes Service (AKS) integration.
The exam hook: Standard vs Datacenter is decided by how many VMs you'll host. More than 2 → Datacenter wins on math.
Four editions of Windows Server

Installation Options · Server Core vs Desktop Experience

Pick the surface area before the role.

Smaller install = smaller attack surface = fewer patches.

  • Server Core. No GUI. Command-line + PowerShell. sconfig for basic config. Default for production. ~6 GB.
  • Desktop Experience. Full GUI. ~10 GB. Use for learning, RDS hosts, dev environments.
  • Server Core App Compat (FoD). A Feature on Demand. Adds back the Microsoft Management Console (MMC), Event Viewer, a slim GUI subset.
  • You cannot swap between Core and Desktop after install. Decide up front.
Live demo cue: open a Server Core VM, run sconfig, walk through option 8 (network) and option 15 (exit to PowerShell). (Right-side animation previews the menu.)
Server Core: cmd.exe
C:\Users\Administrator>sconfig
===============================================================
Server Configuration
===============================================================
1)Domain/WorkgroupWORKGROUP
2)Computer NameWIN-2K22-CORE
3)Add Local Administrator
4)Configure Remote ManagementEnabled
5)Windows Update SettingsDownloadOnly
6)Download and Install Updates
7)Remote DesktopDisabled
8)Network SettingsDEMO
9)Date and Time
10)Telemetry settingsRequired
11)Windows Activation
12)Log Off User
13)Restart Server
14)Shut Down Server
15)Exit to Command LineDEMO
Enter number to select an option:

Server Manager + Roles & Features

One console, many servers. Roles vs features matters.

Server Manager is the dashboard. Roles install workloads. Features add capabilities.

  • Server Manager. Single console, centralized management. Add multiple servers to one pane via All Servers.
  • Role. A purposeful workload: Active Directory Domain Services (AD DS), DHCP, DNS, IIS, RDS. Adds servers to a specific function.
  • Feature. Supporting capability (BitLocker, .NET, Failover Clustering, Telnet client). Enables or extends.
  • Role services. Sub-components within a role. AD DS for example has multiple role services you can pick.
  • PowerShell equivalent. Get-WindowsFeature, Install-WindowsFeature, Uninstall-WindowsFeature. Scriptable; faster than the wizard.
Class anchor: "if it adds a workload, it's a role. If it adds a capability, it's a feature."

PowerShell Fundamentals

Verb-noun pattern. Pipe and discover.

Once you know the pattern, PowerShell becomes self-documenting.

  • Verb-Noun. Every cmdlet follows Verb-Noun. Predictable.
  • Standard verbs. Get, Set, New, Remove, Start, Stop. Get-Verb lists them all.
  • Discoverability. Get-Command -Noun X finds everything touching X.
  • Pipeline. Objects, not text. Chain cmdlets together with |.
  • Modules. AD, GroupPolicy, Hyper-V, Storage, ServerManager each ship a module.
Live demo cue: run Get-Command -Noun *Disk* in class. The verb-noun pattern reveals what's available without memorization.
Windows PowerShell
PS C:\>Get-Command -Noun *Disk*
CommandTypeNameSource
FunctionGet-DiskStorage
FunctionGet-DiskImageStorage
FunctionInitialize-DiskStorage
FunctionReset-PhysicalDiskStorage
FunctionSet-DiskStorage
FunctionUpdate-DiskStorage
Module 02

Active Directory

Forest, Domain, OU, Users, Groups
The directory that owns identity for the org. Forest and domain boundary, why both exist. Domain Controllers and multi-master replication. Users, Groups, OUs, and the delegation model that makes them administrable at scale.
M02 Active Directory overview

AD Architecture · Forest, Domain, OU

Three nesting levels. Each has a different security boundary.

The hierarchy is also the security and replication boundary.

  • Forest. Top of the tree. The security boundary. trust does not cross forests by default. Holds the schema. Usually one per organization.
  • Domain. Replication and administrative partition within the forest. Holds users, computers, Group Policy Objects (GPOs). Domain admins are powerful within their domain, not across.
  • OU (Organizational Unit). Container inside a domain for delegation and Group Policy application. No security boundary, just management.
  • Trees. Domains sharing a contiguous namespace. corp.hexworth.com and na.corp.hexworth.com are one tree.
Common misconception to flag: students think OUs are security boundaries. They are NOT. Domain is. Forest more so.

Domain Controllers and Replication

Multi-master. Mostly. The FSMO roles are the exception.

Every DC can write, except for the five FSMO roles that require a single owner.

  • Domain Controller. Server hosting AD DS. Authenticates users, enforces policy, replicates the directory.
  • Multi-master replication. Any DC accepts writes. Changes converge to all DCs within minutes (intra-site).
  • FSMO, Flexible Single-Master Operations. Five roles that need a single owner: Schema and Domain Naming (forest); RID (Relative Identifier), PDC Emulator, Infrastructure (per-domain).
  • RODC. Read-only DC for branches you don't fully trust. Common in retail / remote offices.
  • Global Catalog. Holds a partial replica of every domain in the forest, needed for cross-domain lookups.
Live demo cue: open ADUC (Active Directory Users and Computers), show netdom query fsmo, point out which DC owns which FSMO role. (Right-side animation shows what students will see.)
Administrator: Windows PowerShell
PS C:\>netdom query fsmo
Schema master DC01.hexworth.local FOREST
Domain naming master DC01.hexworth.local FOREST
PDC DC02.hexworth.local DOMAIN
RID pool manager DC02.hexworth.local DOMAIN
Infrastructure master DC03.hexworth.local DOMAIN
The command completed successfully.

Users and Groups · AGDLP

Group nesting strategy that scales across the forest.

Don't grant permissions directly to users. Nest groups to control sprawl.

  • User accounts. Each person gets one. Service accounts are separate (use Managed Service Accounts for services).
  • Security vs Distribution. Security groups grant access. Distribution groups are email-only (rarely used outside Exchange).
  • Group scopes. Domain Local (resource scope), Global (account scope), Universal (cross-domain).
  • AGDLP. Accounts → Global groups → Domain Local groups → Permissions. The canonical nesting pattern.
  • Why AGDLP matters. Resource owners manage Domain Local groups; identity owners manage Global groups. Roles don't collide.
Class anchor: "Add accounts to Global, add Global to Domain Local, assign permissions to Domain Local." Memorize the chain.

OUs and Delegation

OUs are for admin model + Group Policy targeting.

Design your OU structure by who manages what, not by org chart.

  • OU purpose. Delegated administration + Group Policy targeting.
  • Delegation Wizard. Right-click OU → Delegate Control. Grant specific permissions to a group on just that OU.
  • OU design. Mirror the admin model. Common pattern: top-level by function (HR, IT, Sales), nested by site or device type.
  • Avoid moving objects. Moves trigger Group Policy re-evaluation, can break GPO application briefly.
Live demo cue: create a Pilot OU, run the Delegation Wizard, grant a helpdesk group "reset password" only.
Delegation of Control Wizard ×
Grant the selected groups specific tasks on the chosen OU.
Target OU: OU=Workstations,DC=hexworth,DC=local
Selected group: HEXWORTH\Helpdesk-Tier1
Tasks to delegate:
Reset user passwords and force password change at next logon
Create, delete, and manage user accounts
Modify the membership of a group
Read all user information
Module 03

Storage

Disks, partitions, Storage Spaces, cmdlets
Basic vs Dynamic disks. MBR vs GPT partition styles and why GPT won. Storage Spaces, Microsoft's software-defined storage. The PowerShell story for disks and volumes.
M03 Storage overview

Disk Types · Basic vs Dynamic

Basic is the modern default. Dynamic is legacy.

Spanned/striped volumes belong to Storage Spaces now, not Dynamic Disks.

  • Basic disk. The default. Supports primary partitions, extended partitions, and on GPT supports up to 128 partitions. What you almost always use today.
  • Dynamic disk. Legacy. Supports spanned, striped, mirrored, RAID-5 volumes natively. Deprecated. do this in Storage Spaces instead.
  • Conversion. Basic to Dynamic is one-way (no data loss). Dynamic to Basic requires wiping the disk.
  • Recommendation. Stick with Basic + GPT + Storage Spaces for multi-disk scenarios. Don't reach for Dynamic in 2026.
Common misconception: students think Dynamic = "modern, advanced." It's actually deprecated. Storage Spaces replaced it.

Partition Styles · MBR vs GPT

GPT is the default. MBR is legacy compatibility.

If the firmware is UEFI, use GPT. Period.

  • MBR. Master Boot Record. Max 2 TB, max 4 primary partitions. BIOS-era.
  • GPT. GUID Partition Table. Max 18 EB, max 128 partitions. UEFI-required for boot.
  • Boot requirement. UEFI → GPT. Legacy BIOS → MBR. Mismatched = "cannot boot."
  • Conversion. MBR2GPT.exe converts without data loss. One-way.
Live demo cue: Disk Management, right-click a basic disk → Convert to GPT Disk. The option greys out when partitions exist.
New Spanned Volume...
New Striped Volume...
New Mirrored Volume...
New RAID-5 Volume...
Convert to Dynamic Disk...
Convert to GPT Disk
Offline
Properties
Greyed out: disk has existing partitions. MBR2GPT.exe from an elevated prompt converts without data loss.

Storage Spaces

Software-defined storage. Pool + virtual disk + volume.

Aggregate physical disks into a pool. Carve virtual disks with the resiliency you choose.

  • Storage Pool. A collection of physical disks. Treat as a single resource.
  • Virtual Disk. Carved from the pool. Pick resiliency: Simple, Mirror (2 or 3-way), Parity.
  • Volume. Filesystem on the virtual disk, NTFS or ReFS (Resilient File System).
  • Tiering. Mix SSD + HDD in the same pool. Hot on SSD, cold on HDD, automatic moves.
  • S2D (Storage Spaces Direct). The cluster version. Module 06 territory.
Class anchor: "Storage Spaces is software RAID for the modern era." (Right-side animation cycles SIMPLE, MIRROR, PARITY so students see the difference in write distribution.)
Resiliency SIMPLE MIRROR PARITY
Storage Pool
D1
A A A
D2
B A' B
D3
C B C
D4
D B' P
Stripe across all disks. No redundancy. Lose 1 disk = lose data. Each block written twice. Survive 1 disk failure. 3 data blocks + 1 parity block. Survive 1 disk failure (RAID-5-like).

Disk and Volume cmdlets

PowerShell beats Disk Management for repeatability.

Wire one disk in PowerShell once, script it for the next hundred.

  • Inventory. Get-Disk, Get-Partition, Get-Volume.
  • Initialize. Set-Disk -IsOffline $false, then Initialize-Disk -PartitionStyle GPT.
  • Format. New-Partition piped to Format-Volume.
  • Storage Spaces. New-StoragePool, New-VirtualDisk, New-Volume.
  • GUI to learn, PS to ship. Same outcomes, scriptable.
Live demo cue: attach a fresh VHD (Virtual Hard Disk), take it from offline to formatted in 4 cmdlets. Then Get-Disk | Format-Table to confirm.
Windows PowerShell
PS C:\>Get-Disk | Format-Table
NumberFriendlyNameOpStatusTotalSizeStyle
0Msft Virtual DiskOnline120 GBGPT
1Msft Virtual DiskOffline40 GBRAW
2Samsung SSD 980Online1 TBGPT
3WDC WD20Online2 TBGPT
Module 04

Hyper-V

Virtualization, switches, checkpoints, PowerShell
The hypervisor that ships with Windows Server. Type 1 vs Type 2. VM generations and why Gen 2 is the answer. Virtual switches. Checkpoints (what they are, what they aren't). PowerShell VM lifecycle.
M04 Hyper-V overview

Hypervisor Types · Type 1 vs Type 2

Bare-metal vs hosted. Hyper-V is Type 1.

Even when Hyper-V looks like it's "running on Windows," Windows is actually a VM on the hypervisor.

  • Type 1. Bare-metal. Hypervisor sits directly on hardware. Hyper-V, VMware ESXi, Xen. Better performance.
  • Type 2. Hosted. Hypervisor runs as an app on top of a host OS. VirtualBox, VMware Workstation. Easier to set up, lower performance.
  • Hyper-V's trick. When you enable Hyper-V on Windows Server, Windows becomes a privileged VM (the "parent partition"). The OS you see is actually running on top of Hyper-V.
  • Hardware requirements. CPU virtualization extensions (Intel VT-x or AMD-V). SLAT (Second-Level Address Translation). Available on every server-class CPU for years.
Common misconception: "Hyper-V runs on top of Windows", technically backwards. Use this to demystify the architecture.

VM Generations · Gen 1 vs Gen 2

Gen 2 is the default. Gen 1 is legacy compat.

Gen 2 = UEFI + Secure Boot + modern device stack. Use Gen 2 unless you have a reason.

  • Gen 1. Legacy BIOS, IDE, emulated devices. Compatible with 32-bit + older Linux.
  • Gen 2. UEFI, Secure Boot, SCSI-only, synthetic. Faster boot, GPT only.
  • Picking. Modern Win/Linux → Gen 2. 2008/older or 32-bit → Gen 1.
  • Cannot convert. Generation is fixed at VM creation.
  • Secure Boot. Gen 2 on by default. Linux templates need "Microsoft UEFI CA" or disabled.
Live demo cue: create one Gen 1 and one Gen 2 VM side by side, point out BIOS vs UEFI firmware UI.
GEN 1
BIOS Firmware
FirmwareLegacy BIOS
Disk ControllerIDE (boot) + SCSI
Boot DiskMBR, ≤ 2 TB
Secure BootUnavailable
NetworkLegacy NIC adapter
OS Support32-bit + 64-bit
GEN 2
UEFI Firmware
FirmwareUEFI 2.4
Disk ControllerSCSI only
Boot DiskGPT, > 2 TB OK
Secure BootOn by default
NetworkSynthetic NIC
OS Support64-bit only

Virtual Switches

Three types. Each maps to a different network goal.

Pick the switch type by who needs to reach whom.

  • External. Bound to a physical NIC. VMs talk to the outside world (and to the host). Most common.
  • Internal. Host + VMs can reach each other. No physical NIC. Useful for test labs, isolated workloads.
  • Private. VMs reach each other only. Host is excluded. Useful for malware analysis, sealed environments.
  • One NIC + External + Mgmt. When you bind External to your only NIC, you usually keep the management OS connected via a virtual adapter that uses the same switch.
Class anchor: "External = outside world. Internal = VMs + host. Private = VMs only."

Checkpoints + PowerShell VM Management

Checkpoints are point-in-time snapshots. Not backups.

Two checkpoint types. One is for prod, one is not.

  • Production checkpoint. Uses VSS (Volume Shadow Copy Service) inside the guest. Consistent application state. Safe for prod. Default in Server 2016+.
  • Standard checkpoint. Memory + disk at the instant taken. Like saved state. Good for dev/test. Bad for prod (apps mid-write).
  • NOT a backup. Checkpoints live with the VM. VHD corruption kills them too. Take a real backup separately.
  • PowerShell lifecycle. New-VM, Checkpoint-VM, Restore-VMCheckpoint, Remove-VMCheckpoint.
Live demo cue: take a Production checkpoint, change something in the guest, restore. Then Get-VMCheckpoint -VMName 'WS01'.
Production Checkpoint Workflow
VM Start
Checkpoint
Change
Restore
Recovered
VM running normally. Application state stable. Checkpoint-VM -Name 'WS01': VSS captures consistent state. Operator makes a breaking change in the guest. App misbehaves. Restore-VMCheckpoint -Name 'WS01': VM reverts to checkpoint. VM is back to the consistent state at checkpoint time. Damage undone.
Module 05

Containers

Docker, isolation modes, Nano Server
Windows containers and where they fit. Process isolation vs Hyper-V isolation. Docker commands every admin should know. Nano Server, the container-optimized OS image. Dockerfile basics.
M05 Containers overview

Containers vs VMs

Both isolate workloads. They isolate at different levels.

VMs virtualize the hardware. Containers virtualize the OS.

  • VM. Full guest OS, own kernel, own boot. Heavy. Strong isolation. Boot time in seconds to minutes.
  • Container. Shares the host kernel. Bundles just the application + its dependencies. Light. Boot time in milliseconds.
  • When to VM. Different OS family, strong tenant isolation, full-stack workload (DB + app + cache).
  • When to container. Same OS family as host, microservice, ephemeral compute, dev/test sandboxing.
  • Density. 5-10 VMs per host vs 50-100 containers per host on the same hardware is realistic.
Class anchor: "VMs share hardware. Containers share the kernel."

Windows Container Isolation Modes

Process isolation vs Hyper-V isolation. Same container, different isolation.

Same Docker image, but the runtime chooses between two isolation models.

  • Process isolation. Container shares the host kernel directly. Lightest. Requires container OS version = host OS version (e.g., Server 2022 host, Server 2022 container image).
  • Hyper-V isolation. Each container runs in a tiny utility VM with its own kernel. Heavier (~50-100 MB), but cross-version compatible (Server 2019 image on Server 2022 host works).
  • Picking. docker run --isolation=process or --isolation=hyperv. Default depends on host.
  • Security delta. Hyper-V isolation gives stronger tenant boundary, closer to VM-level. Use for hostile-multi-tenant workloads.
Class anchor: "Process = light + fast + matching versions. Hyper-V = heavier + cross-version + stronger boundary."

VM vs Docker: the security picture

Why the isolation model decides the tenant boundary.

The security ladder in motion: process isolation shares the host kernel; Hyper-V isolation adds a per-container kernel boundary (closer to VM-level); a full VM adds a complete guest OS boundary.

Docker Essentials

Six commands cover 90% of daily container work.

Learn six commands. The rest is variations.

  • docker pull. download an image from a registry.
  • docker run -it. create + start + attach.
  • docker ps -a. list all containers (running and stopped).
  • docker exec -it. run a command inside a running container.
  • docker stop / start. lifecycle control.
  • docker rm / rmi. delete containers / images.
Live demo cue: pull nanoserver:ltsc2022, run, exec, exit, remove. The lifecycle in 60 seconds.
Windows PowerShell
PS> docker pull mcr.microsoft.com/windows/nanoserver:ltsc2022
ltsc2022: Pulling from windows/nanoserver, Status: Downloaded newer image
PS> docker run -it --name web nanoserver cmd
Microsoft Windows [Version 10.0.20348.2402]
C:\> exit
PS> docker ps -a
CONTAINER ID  IMAGE      STATUS
abc123def456  nanoserver  Exited (0) 3s ago
PS> docker rm web → web

Nano Server + Dockerfile basics

Nano = the OS image for containers. Dockerfile = how you bake custom images.

Nano Server is no longer a standalone install. It's a container base image.

  • Nano Server. Ultra-stripped Windows. ~250 MB. No GUI, no MSI. Container-only.
  • Base images. nanoserver (smallest), servercore (Server APIs), server (full Windows).
  • Dockerfile. Recipe for an image. FROM, COPY, RUN, CMD. docker build bakes it.
  • Layer caching. Each line = a cached layer. Reorder so stable deps come first, app code last. Rebuilds get fast.
Live demo cue: 4-line Dockerfile, build, run. Change one line and rebuild, watch layers cache.
Dockerfile
FROM mcr.microsoft.com/
   windows/nanoserver:ltsc2022 WORKDIR C:\app COPY app.ps1 . CMD ["pwsh", "-File", "app.ps1"]
docker build .
Step 1/4 : FROM nanoserver Step 2/4 : WORKDIR C:\app Step 3/4 : COPY app.ps1 . Step 4/4 : CMD [...] Successfully built abc123def --- Rebuild after edit --- Step 1/4 : Using cache Step 2/4 : Using cache Step 3/4 : Using cache
Module 06

Failover Clustering

HA, quorum, CSV, CAU
High availability for Windows workloads. Nodes, shared storage, and the heartbeat. Quorum, the vote-based safety system. Cluster Shared Volumes for storage. Cluster-Aware Updating to patch without downtime.
M06 Failover Clustering overview

What is Failover Clustering?

Multiple servers pretending to be one. With shared storage and a heartbeat.

High availability means a workload survives a single node dying.

  • Node. A server in the cluster. Each runs Windows Server with Failover Clustering installed. Usually 2-8 nodes.
  • Shared storage. Storage all nodes can see (SAN LUN, Scale-Out File Server share, Storage Spaces Direct).
  • Heartbeat. Cluster-internal network. Nodes ping each other. Missed heartbeats → failover.
  • Clustered role. The workload that fails over, file server, Hyper-V VM, SQL, generic application.
  • Failover. When a node dies, another node takes ownership of the shared storage + role. Clients reconnect to the new owner.
Class anchor: "Failover clustering is HA, not load balancing. The role runs on ONE node at a time (with exceptions like SOFS, the Scale-Out File Server)."

Quorum and Witness

The vote-based system that prevents split-brain.

If half the nodes can't see the other half, who's still alive? Quorum answers that.

  • Quorum. Majority vote. Lose quorum, cluster shuts down (better than split-brain).
  • Node votes. One vote per node. Odd count = no tie.
  • Witness. Extra vote for even-count clusters. Disk, File Share, Cloud (Azure blob).
  • Dynamic Quorum. Cluster adjusts votes as nodes go offline.
  • 2-node case. 2 nodes + 1 witness = 3 votes. Lose 1 node, 2/3 survives.
Live demo cue: Failover Cluster Manager → Configure Cluster Quorum Settings. Walk the witness selection.
Configure Cluster Quorum Wizard ×
Select Quorum Witness
Choose which witness type the cluster will use to break ties.
Disk Witness (shared cluster disk)
File Share Witness (SMB 3.0 share on a separate server)
Cloud Witness (Azure storage blob)
Do not configure a quorum witness
Share path: \\fileserver01\ClusterWitness
Resulting vote distribution: Node-01 (1) + Node-02 (1) + Witness (1) = 3 votes. Survives 1 node failure.

Cluster Shared Volumes (CSV)

All nodes can read and write the same volume at the same time.

CSV is what makes shared-nothing Hyper-V clustering possible.

  • Normal cluster disk. Owned by one node. Failover hands it to another node when needed.
  • CSV. NTFS or ReFS volume where ALL nodes have simultaneous read/write. Built on top of regular cluster storage with a coordination layer.
  • Why it matters for Hyper-V. Multiple VMs on the same volume can run on different nodes simultaneously. Live Migration without ownership handoff.
  • CSV path. Volumes appear as C:\ClusterStorage\Volume1, ...\Volume2 on every node.
  • Where it stores data. Same shared storage as the cluster, SAN LUN, S2D, etc. CSV is a presentation layer, not a storage system.
Class anchor: "CSV = shared file system across cluster nodes. Without CSV, only one node owns a volume at a time."

Cluster-Aware Updating (CAU)

Patch the cluster without downtime. One node at a time.

CAU automates the rolling-patch dance so you don't have to.

  • Problem. Patch all nodes at once = workload dies. Manually = forget to drain.
  • CAU's choreography. Drain → install → reboot → resume → next node. Loop.
  • Two modes. Self-Updating (on schedule) or Remote Updating (you run wizard).
  • Pre/Post scripts. Custom validation between phases.
  • Patch source. Reads from WSUS (Windows Server Update Services) / Microsoft Update / SCCM (System Center Configuration Manager). Doesn't replace them.
Live demo cue: Failover Cluster Manager → Cluster-Aware Updating → Preview Updates. Talk through the AutoOrchestrator schedule.
Cluster-Aware Updating: PROD-CLUSTER-01 ×
Preview Updates
The following updates will be applied to each node in turn. Workload moves to other nodes during each patch.
NODEUPDATESSTATUS
NODE-013 criticalDONE
NODE-023 criticalPATCHING
NODE-033 criticalPENDING
NODE-043 criticalPENDING
Schedule: Every 2nd Tuesday, 02:00. AutoOrchestrator runs as the CAU clustered role.

Week 1 Wrap-Up · Week 2 Preview

What we covered. What's coming.

This week we covered
  • M01. Editions, install options, Server Manager, PowerShell basics
  • M02. AD architecture, DCs, users/groups, OUs and delegation
  • M03. Disk types, partition styles, Storage Spaces, cmdlets
  • M04. Hyper-V types, generations, switches, checkpoints, PowerShell
  • M05. Containers vs VMs, isolation, Docker, Nano + Dockerfile
  • M06. Clustering basics, quorum, CSV, CAU
Next class (Week 2)
  • M07. Monitoring, performance counters, Event Viewer, WAC
  • M08. DNS, zones, records, resolution, DNSSEC
  • M09. DHCP, scopes, reservations, failover, DORA
  • M10. Group Policy, LSDOU, GPC/GPT, troubleshooting
Reading + lab assignments: see syllabus and Hexworth Prime student deck for each module. Labs M01-M06 due before Week 2 class.
WEEK 1 1 / 33