Concepts of Operating System and Administration Study Notes

Windows Operating System Architecture, Installation and Deployment

Windows Server and the operating system

An operating system is the software layer that manages computer hardware and provides services to applications and users. Windows Server is the Windows family designed for server roles such as identity, file sharing, web hosting and virtualization. A server role is a collection of services that performs a particular network function.

A server is not defined only by its hardware. A suitably configured virtual machine can be a server, while powerful hardware can run a desktop operating system. The important point is the role it performs for users and other systems.

Common Windows Server editions differ in licensing, virtualization rights and advanced capabilities. Before deployment, choose an edition that supports the planned roles, capacity and availability needs. Do not assume an edition name alone guarantees every feature is installed or configured.

Windows architecture

Windows separates user-mode code from kernel-mode code.

An application normally asks the operating system for a service through an API. The request crosses into protected operating-system code when necessary. A faulty kernel driver can affect the whole system because it runs with greater privilege; a faulty user-mode application is usually isolated to its own process.

The Windows kernel and executive coordinate CPU scheduling, memory, I/O, security and object management. Device drivers let the operating system communicate with hardware. The Hardware Abstraction Layer historically provides a boundary between hardware details and higher-level operating-system components. Exact implementation details vary by Windows version, but the privilege boundary remains an important administration concept. The section Windows Internal Architecture later in this chapter names the individual components and processes.

Installation choices

A clean installation installs Windows onto a target system without retaining the existing operating system and applications. It is appropriate for a new machine or when a known-clean rebuild is required. Existing data must be preserved separately before a destructive clean installation.

An in-place upgrade keeps the existing installation while moving it to a supported newer version. It can retain applications, settings and data, but requires compatibility planning and rollback preparation.

A migration moves workloads, data and configuration from one server to another. It is useful when replacing hardware or changing architecture. A migration should identify dependencies such as DNS names, certificates, application service accounts, IP addresses, firewall rules and data ownership.

A successful installation is more than reaching the desktop. Verify activation/licensing where applicable, current patches, time settings, network connectivity, storage, drivers, administrator access and the required server roles.

Server installation planning

Before installing, document the server purpose, expected workloads, CPU/RAM/storage needs, network address, name, domain membership plan, update source and recovery method. Use a unique, meaningful hostname. A name change after services are deployed can affect certificates, DNS registrations, scripts and application settings.

Choose disk layout intentionally. The operating system, application data, logs and backups often have different growth, security and recovery requirements. Free disk space is not a substitute for a tested backup.

A Windows Server installation can use the full desktop experience or a reduced/server-core style installation on supported versions. A smaller installation can reduce attack surface and patching workload, but administrators must be prepared to use remote tools or command-line administration. Select it because it fits the operating model, not merely because it uses fewer resources.

Images and repeatable deployment

A deployment image is a prepared operating-system image used to install similar systems consistently. An image can include the operating system, approved updates, drivers and selected baseline configuration. It should not contain unique machine identity, embedded secrets or site-specific values that must differ per target.

Windows deployment commonly prepares a reference computer, generalizes it, captures an image and deploys it to target machines. Generalization removes or resets machine-specific state so deployed computers can receive their own identity. The precise toolchain depends on Windows version and organizational deployment tooling.

A good image process has these stages:

1. Build a reference system from trusted installation media.
2. Apply approved updates, drivers and baseline configuration.
3. Remove temporary files and do not embed administrator credentials.
4. Generalize the image using the supported tool and options.
5. Capture it to protected deployment storage.
6. Deploy to a test device.
7. Validate identity, activation, drivers, updates, domain join and required policies before broad use.

An image is a baseline, not a permanent substitute for patch management. A previously safe image becomes outdated as vulnerabilities and updates change.

Upgrade and migration validation

A maintenance plan should identify a change window, dependency owners, compatibility evidence, backup and recovery point, validation tests, rollback condition and communication plan. A backup that has never been restored is an assumption, not proof of recovery.

Test a workload from the user's perspective after an upgrade or migration. For example, a file server should be checked for share access and permissions, not only whether the Windows service is running. A domain controller or application server requires role-specific validation as well as basic login and network checks.

Administration tools

Windows Settings and Server Manager provide graphical administration. Microsoft Management Console snap-ins, such as Computer Management, Event Viewer and Services, expose focused tools. PowerShell provides command-line and scriptable administration and is covered in detail later.

Useful basic commands include:

hostname
Get-ComputerInfo
Get-WindowsFeature
Get-Service
Get-EventLog -LogName System -Newest 20

hostname displays the local computer name. Get-ComputerInfo returns operating-system and hardware information. Get-WindowsFeature lists server roles/features on systems that provide the ServerManager module. Get-Service inspects service status. Get-EventLog reads only the classic logs (such as System, Application and Security) and exists only in Windows PowerShell 5.1; it was removed from PowerShell 7. Get-WinEvent is the newer cmdlet: it reads classic logs, Applications and Services logs and saved .evtx files, and works in both Windows PowerShell and PowerShell 7. Command availability and output depend on the installed Windows version and roles.

Deployment security

Unattended installation files and images can contain product keys, local administrator settings, network configuration and other sensitive data. Store them with restricted access. Use secure build sources, sign or verify trusted media where the process supports it, and rotate any credential that could have been exposed in a deployment artifact.

A deployment account should have only the rights needed to perform deployment. After installation, apply domain/local policy, remove unnecessary software and services, enable logging, patch the system and confirm backup coverage. A fast deployment process that creates identical weak configurations is an operational and security failure.

Operating System Responsibilities

The operating system sits between applications and hardware. It gives programs stable services so that each application does not need to control the CPU, memory, disks and network adapters directly.

Users and administrators
          |
Applications and server roles
          |
Windows APIs and system services
          |
Executive, kernel, drivers and HAL
          |
CPU, memory, disks, network and devices

Its responsibilities include:

• Process management: creates processes and threads, schedules CPU time and ends them safely.
• Memory management: gives processes virtual address spaces, maps memory and protects one process from another.
• Storage management: exposes volumes and files through file systems, caching and device drivers.
• Device management: communicates with hardware through drivers and input/output services.
• Security: checks identities, tokens, privileges and access-control entries.
• Networking: implements protocol stacks, sockets, filtering and network services.
• Administration: records events and exposes configuration through graphical tools, commands and APIs.

A server role builds on these operating-system services. For example, a file server relies on identity, NTFS access checks, networking, storage drivers and logging. Installing a role does not replace the operating system; it adds components and configuration for a service.

Windows Internal Architecture

Windows uses protected execution modes. User-mode code has limited access. Kernel-mode code can execute privileged instructions and reach system memory and hardware through controlled components. On x86/x64 processors, kernel mode corresponds to processor privilege ring 0 and user mode to ring 3; Windows does not use rings 1 and 2.

Key components and files

A common exam trap is assuming that every critical system process runs in kernel mode. lsass.exe, services.exe and winlogon.exe are essential, highly privileged processes, but they are user-mode processes. A failure of a critical user-mode process can still force a restart because Windows treats it as essential.

User mode

Applications normally run in separate processes with private virtual address spaces. A process contains resources such as handles and one or more execution threads. If one ordinary application crashes, process isolation usually prevents it from directly overwriting another process or the kernel.

User mode also contains environment subsystems and many service processes. Windows services can start in the background without an interactive user session. Running in user mode does not automatically make a process safe: a highly privileged service can still alter important data through authorized system calls.

System-call boundary

An application uses a documented API, such as opening a file. User-mode libraries prepare a request and cross a controlled system-call boundary. Kernel-mode components validate the request, check permissions and perform the operation through the file system and storage stack.

Application requests Create/Open file
           |
           v
User-mode API library
           |
        system call
           |
           v
I/O manager -> security check -> file-system driver -> storage driver

The boundary prevents an application from directly issuing arbitrary disk commands. It also gives the operating system a place to enforce security and resource rules.

Executive services

The Windows Executive is a group of kernel-mode services. At a course level, important managers include:

These are conceptual responsibilities rather than separate programs an administrator starts manually.

Kernel

The kernel performs low-level functions such as thread scheduling, interrupt/exception handling and synchronization. The scheduler chooses a runnable thread for a processor according to priorities and system state. Applications do not own the CPU continuously; the operating system allocates execution time.

Hardware Abstraction Layer

The HAL isolates selected low-level hardware differences from higher kernel components. Modern Windows implementation details have evolved, but the architectural lesson remains: higher operating-system code should use defined abstractions instead of being rewritten for every hardware controller.

Device drivers

Drivers translate generic operating-system I/O requests into device-specific operations. Drivers can be arranged in a stack. A file request can pass through filters, a file-system driver, storage-class drivers and controller drivers.

A faulty kernel-mode driver can corrupt system memory or stop the operating system, producing a bug check. Driver source, signing, hardware compatibility and tested versions matter during installation and deployment. “Device appears in Device Manager” is not sufficient proof that it operates correctly under workload.

Registry and configuration

The Registry stores structured configuration for Windows and installed software. It is divided into logical hives and keys. Administrators should use supported tools and policies rather than treating it as an ordinary text database. A wrong registry edit can prevent a service or the operating system from starting.

Boot at a high level

On a modern UEFI system, firmware initializes hardware and starts Windows Boot Manager from the EFI System Partition. Boot components load the selected operating system, kernel, essential drivers and system configuration. Session initialization then starts services and logon components.

UEFI firmware
    -> Windows Boot Manager
    -> OS loader
    -> kernel, HAL and boot drivers
    -> system processes and services
    -> logon / server operation

The main boot files have been stable since Windows Vista/Server 2008, but the path differs by firmware mode:

After the kernel initializes, smss.exe starts, then csrss.exe, wininit.exe (which starts services.exe and lsass.exe) and winlogon.exe. bcdedit /enum run from an elevated prompt displays the boot manager and loader entries. Recovery behaviour still varies by release and firmware. The important administrative distinction is among firmware/boot failure, kernel or driver failure, and a service/role failure after Windows starts.

Windows Server Editions, Installation Options and Roles

An edition defines licensing and capability boundaries. An installation option defines how much local user interface and component surface is installed. A role is a workload installed on that operating system. These are three different choices.

Editions

Windows Server Standard and Datacenter are common editions in recent long-term servicing releases. Datacenter generally provides broader virtualization rights and data-centre features; Standard targets less virtualized or smaller deployments. Exact rights and features change by release and licensing program. Always consult documentation for the purchased version rather than memorizing one comparison forever.

The differences that have stayed consistent from Windows Server 2016 through Windows Server 2025 are:

A Standard server can still run Hyper-V; it is the number of licensed Windows Server guests that differs.

Other editions and forms to recognize:

• Essentials: small-business edition (historically 25 users and 50 devices, limited processor and memory support). From Windows Server 2019 it is sold mainly through hardware vendors.
• Evaluation: a time-limited (normally 180-day) trial of Standard or Datacenter. It can be converted to a licensed edition with DISM, but conversion is not supported on a domain controller.
• Datacenter: Azure Edition: introduced with Windows Server 2022 for Azure and Azure Stack HCI; it added hotpatching and SMB over QUIC first.
• Microsoft Hyper-V Server 2019: the last free, GUI-less hypervisor-only release; there is no Hyper-V Server 2022 or 2025.

DISM can display and change the edition of a running server. Edition changes only go upward (for example Standard to Datacenter or Evaluation to retail), and the product key below is a placeholder:

DISM /Online /Get-CurrentEdition
DISM /Online /Get-TargetEditions
DISM /Online /Set-Edition:ServerDatacenter /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula

/Get-TargetEditions lists only the editions the current installation can move to. The change requires a restart. A Datacenter server cannot be converted down to Standard; that requires a new installation.

Other Windows Server forms have existed for specialized markets, cloud use or subscription channels. An old exam question naming an edition can become outdated. The durable principle is to match edition, licensing, hardware capacity and required role features before installation.

Windows Server releases compared

All four are Long-Term Servicing Channel releases with roughly five years of mainstream and five years of extended support. The build number reported by Get-ComputerInfo (OsBuildNumber) or winver is the quickest reliable way to identify the release on a running server, because product names in tools can be inconsistent.

Server Core and Desktop Experience

Server Core installs a smaller local interface and omits much of the desktop GUI. It can reduce installed components, servicing and attack surface. Administration uses PowerShell, command-line tools, Server Manager from another computer, Windows Admin Center or other remote management.

Desktop Experience includes the graphical shell and local GUI tools. It can be useful for applications or teams requiring them but has more components to maintain.

From Windows Server 2016 onward (including 2019, 2022 and 2025), you cannot convert between Server Core and Desktop Experience after installation; changing requires a reinstall, and an in-place upgrade also keeps the existing option. Choose correctly during setup. In Windows Server 2012 and 2012 R2 the GUI could be added or removed as features (Server-Gui-Shell, Server-Gui-Mgmt-Infra), so legacy instructions using those feature names should not be applied to newer releases.

On Server Core, the text-based Server Configuration tool (sconfig) handles common first-boot tasks: computer name, domain join, network settings, Windows Update, remote management and Remote Desktop. From Windows Server 2019, the optional Server Core App Compatibility Feature on Demand adds a few GUI tools (such as Event Viewer and Device Manager) without converting the server to Desktop Experience.

Nano Server context

Nano Server appeared as a very small installation option in Windows Server 2016. It had no local logon or setup choice: administrators built a Nano Server image with PowerShell and managed it remotely. From the version 1709 semi-annual release, Microsoft limited Nano Server to a container base image rather than a general infrastructure-server installation. Treat source references to installing Nano Server as Windows Server 2016 history, not a current deployment choice.

Roles and features

A role provides a major service, such as Active Directory Domain Services, DNS Server, DHCP Server, File and Storage Services, Hyper-V, Web Server (IIS) or Windows Deployment Services. A feature supports roles or administration, such as failover clustering tools or .NET components.

Get-WindowsFeature
Get-WindowsFeature -Name DNS, DHCP, Web-Server

The cmdlets require Windows Server's ServerManager module. Installed state should be verified after role installation, then the service must be configured and tested. An installed DNS role without zones or an installed IIS role without the intended site is not a completed deployment.

Roles and features are added and removed with matching cmdlets. -IncludeManagementTools adds the related consoles and PowerShell modules, which are not installed by default from PowerShell. -WhatIf shows what would happen without making the change:

Install-WindowsFeature -Name DNS -IncludeManagementTools -WhatIf
Install-WindowsFeature -Name DNS -IncludeManagementTools
Uninstall-WindowsFeature -Name DNS -Remove
Install-WindowsFeature -Name Web-Server -Vhd 'D:\VHDs\WEB01.vhdx'

-Remove on Uninstall-WindowsFeature also deletes the feature payload from the local component store, so reinstalling it later needs installation media (-Source) or Windows Update. -Vhd installs a role into an offline virtual hard disk that is not running. Windows client editions (Windows 10/11) do not provide Get-WindowsFeature by default; they use Get-WindowsOptionalFeature -Online and Enable-WindowsOptionalFeature from the DISM module instead.

Installation Planning as a Design Activity

Good installation decisions occur before booting from media.

Workload requirements

Document the service purpose, number of users, application dependencies, expected traffic, availability target, data growth, backup objective and security classification. Hardware minimums are only enough to start Windows; workload sizing determines useful capacity.

Hardware and firmware compatibility

Check processor architecture, virtualization support when needed, memory, storage controller, network adapters, UEFI/BIOS mode, Secure Boot requirements and vendor driver support. For a virtual machine, check virtual hardware generation and hypervisor integration tools.

Microsoft's published minimums for Windows Server 2016, 2019, 2022 and 2025 are similar:

There is no 32-bit Windows Server release since Windows Server 2008, and these figures only allow Setup to complete; they are not a sizing recommendation. For comparison, Windows 11 clients require a supported 64-bit processor with at least two cores at 1 GHz, 4 GB RAM, 64 GB storage, UEFI with Secure Boot capability and TPM 2.0. This matters when the same deployment infrastructure installs both servers and Windows 10/11 clients.

Network and identity plan

Prepare hostname, IP addressing method, subnet, gateway, DNS servers, VLAN, firewall path, domain membership and management access. A server should normally use stable address planning for its role. Do not turn off a firewall as a general installation step; enable only the traffic required by installed services.

Time and naming

Correct time is essential for logs, certificates and domain authentication. Choose a unique hostname that follows organizational convention. Renaming after deploying certificate-bound or clustered applications can be complex.

Recovery plan

Before an upgrade or destructive installation, identify backup location, encryption keys, recovery media, restoration steps and decision point for rollback. Test access to the backup from a separate system. A backup stored only on the disk being repartitioned is not protection.

Firmware Modes and Disk Partition Styles

Firmware mode and partition style affect how Windows boots.

MBR

Master Boot Record is the older partitioning scheme. It stores boot and partition data near the start of a disk and has common limitations around very large disks and the number of primary partitions. It is associated with legacy BIOS boot in traditional deployments.

GPT

GUID Partition Table uses GUIDs, supports large disks and normally provides many partition entries. It stores redundant partition metadata and checksums for structural protection. GPT is the normal partner for native UEFI boot.

The exact maximum sizes depend on sector size, operating system and file system. Do not use an abstract GPT maximum as a promise that Windows, hardware or a selected file system supports that volume size.

To check partition style on a running server, Get-Disk | Select-Object Number, FriendlyName, PartitionStyle, Size shows MBR, GPT or RAW for each disk. During Setup, Shift+F10 opens a command prompt in Windows PE. There, diskpart followed by list disk marks GPT disks with an asterisk in the Gpt column. Converting a disk with diskpart clean and convert gpt erases it.

Typical UEFI Windows partitions

A clean Windows installation can create:

• EFI System Partition (ESP): contains UEFI boot files, usually FAT32.
• Microsoft Reserved Partition (MSR): reserved for Windows disk-management operations.
• Windows partition: normally NTFS and assigned C: after boot.
• Recovery partition: contains Windows Recovery Environment tools where configured.

These system partitions should not be deleted merely because Disk Management does not show ordinary user files. Removing the ESP can make Windows unbootable; removing recovery content can remove local repair capability.

Volumes and File Systems

A partition or logical volume defines storage space. A file system organizes files, directories, metadata, security and allocation inside that space.

NTFS

NTFS is the general-purpose Windows file system used for the operating-system volume and many data volumes. It supports discretionary access-control lists, auditing, compression, encryption through EFS in suitable contexts, quotas, alternate data streams, journaling and large files.

Journaling records metadata operations so the file-system structure can recover more consistently after interruption. It does not replace backup and does not guarantee that every application's last write is preserved.

ReFS

Resilient File System is designed for data integrity, availability and large-scale storage scenarios. Feature support varies by Windows Server edition, version and workload. It is not a general replacement for NTFS on every volume: Windows Server cannot boot from or install onto a ReFS volume, and ReFS does not support NTFS features such as EFS encryption and NTFS disk quotas. It is commonly used for Hyper-V virtual-disk storage, Storage Spaces Direct and backup repositories. Check application, backup and role compatibility before choosing it.

FAT32 and exFAT

FAT32 is widely compatible and is used for the UEFI system partition, but it lacks NTFS permissions and cannot store a single file of 4 GB or larger. This matters for bootable UEFI USB media: a FAT32 USB drive cannot hold an install.wim larger than 4 GB unless it is split into .swm files (see Windows Imaging Concepts). exFAT is useful for removable/media interoperability but is not a normal Windows Server system-volume file system.

Volume design

Separating OS, application data and logs can make capacity monitoring, backup and recovery clearer. It does not create physical redundancy if all volumes remain on one disk. RAID/storage resiliency, volume separation and backup solve different problems.

Plan free space for Windows updates, temporary installation files, logs, crash dumps and application growth. A server that starts with nearly full storage can fail during servicing even if current user data fits.

Clean Installation Workflow

A clean installation produces a new operating-system instance. The following workflow is version-neutral; screen names and prompts vary.

1. Verify prerequisites

Confirm hardware support, firmware mode, target disk, edition, installation option, media integrity, licensing route, network information and backup. Disconnect or clearly identify disks that must not be overwritten.

Trusted media matters. Obtain installation media through an approved source and verify its hash or signature when the process provides one. A modified image can introduce malware before security tools are installed.

2. Boot installation environment

Select the installation media from UEFI or firmware boot options. Booting the same USB entry in legacy mode rather than UEFI mode can lead to a different partition style or an error when the target disk is GPT.

3. Select language, edition and installation option

Choose the edition covered by the license and workload design. Selecting Datacenter media does not automatically grant a Datacenter license. Choose Server Core or Desktop Experience according to the management and application plan.

4. Choose installation type

For a new build, select the custom/clean path rather than upgrade. Read the target disk carefully. Deleting partitions destroys data and can remove vendor or recovery partitions.

5. Partition and install

For a dedicated new system disk, allowing setup to create required UEFI/GPT partitions is often safest. For a defined enterprise layout, create volumes according to the approved plan. Windows copies files, installs components and restarts.

6. Establish initial administration

Set the built-in Administrator credential when prompted by the release. Use a strong unique secret and move toward managed named accounts and least privilege. Do not embed a production administrator password into shared documentation.

7. Complete post-install configuration

Rename the computer, configure networking, time and remote administration, install supported drivers and updates, activate as required, and join the appropriate domain at the planned stage.

8. Add roles and validate

Install only required roles/features. Configure them, apply policy and test the service from another system. Capture baseline logs and configuration after success.

Clean Installation, Upgrade and Migration Decisions

Clean installation

Choose a clean installation when deploying new hardware, rebuilding an untrusted server, changing an unsupported architecture, or establishing a standardized baseline. Its strength is known state. Its cost is reinstalling applications and restoring data/configuration.

In-place upgrade

An in-place upgrade modifies the existing Windows instance. It can retain installed applications and settings, reducing workload movement. It also carries forward complexity and depends on a supported upgrade path.

Before upgrading:

1. Confirm the exact source-to-target version/edition path is supported.
2. Check hardware, drivers, applications, agents and security software.
3. Apply prerequisites and resolve health warnings.
4. Create and test backup/recovery.
5. Record current roles, features, IP configuration, services and application tests.
6. Plan downtime and rollback criteria.
7. Test the process on representative nonproduction systems.

A rollback option can expire after cleanup or subsequent changes. Do not assume it replaces a recoverable backup.

Supported in-place upgrade paths

Microsoft supports in-place upgrades only from specific earlier releases:

An older server outside these paths needs more than one upgrade step, or a migration to a clean installation (often the better choice). Other rules that apply to every path:

• The architecture stays 64-bit; a 32-bit server cannot be upgraded in place.
• The installation option is kept: Server Core stays Server Core and Desktop Experience stays Desktop Experience.
• The edition can stay the same or move up (Standard to Datacenter), not down.
• An Evaluation installation must be converted to a licensed edition first.
• The language of the installation media should match the installed system language.
• Roles have their own conditions; for example, domain controllers and failover-cluster nodes have role-specific upgrade guidance.

Running the upgrade

Mount the installation media on the running server and start setup.exe from within Windows; booting from the media offers only a clean installation. In Setup, choose the option that keeps files, settings and apps. Windows Setup also accepts command-line options; for example, a compatibility check that changes nothing:

D:\setup.exe /auto upgrade /compat scanonly

Setup logs are written under C:\$WINDOWS.~BT\Sources\Panther\ during the upgrade (setupact.log, setuperr.log). If the upgrade fails before it finishes, Setup normally rolls back to the previous version automatically. Do not rely on an undo option once an upgrade has succeeded: recover from a tested backup, a VM checkpoint taken while the server was shut down, or a rebuilt server.

Migration

Migration creates or prepares a target server and transfers the workload. It can support hardware replacement and clean operating-system baselines. The old server can remain available for controlled fallback until cutover.

Migration discovery should include:

• data, shares and NTFS permissions;
• service accounts and scheduled tasks;
• certificates and private keys;
• local groups and rights;
• DNS records, aliases and IP dependencies;
• firewall rules and listening ports;
• application configuration, databases and license activation;
• monitoring, backup and security agents;
• clients, scripts or devices using hard-coded server names.

After copying files, verify owners, access control, timestamps where required and share-level permissions. A successful byte count alone does not prove that users can access the migrated service.

Migration tools

A typical robocopy staging copy for a file share:

robocopy \\FILE01\D$\Shares D:\Shares /MIR /COPYALL /DCOPY:DAT /R:2 /W:5 /MT:16 /LOG:C:\Logs\shares.log

Run it again during the cutover window to copy the final changes. Robocopy exit codes 0–7 mean success with different combinations of copied, extra or mismatched files; 8 or higher means some copies failed. Because /MIR deletes, double-check the source and destination order. Robocopy copies NTFS permissions but not share definitions, which are stored in the registry and must be recreated or migrated separately.

Side-by-side migration example

Old server                    New server
FILE01                        FILE02
Windows Server old release    Supported current release
Data D:                       New data D:

Discover -> build target -> copy/synchronize -> test
        -> maintenance cutover -> final delta -> DNS/name transition
        -> user validation -> retain rollback window -> retire old server

The final synchronization reduces changes made after the first copy. Cutover must avoid users writing to both copies independently.

Post-Installation Configuration

Computer identity

Use Server Manager, Settings/System Properties or PowerShell as supported:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Rename-Computer -NewName 'APP01' -Restart

Renaming requires appropriate rights and restart. Do it before installing name-sensitive services where possible.

Network configuration

Inspect adapters and current IP settings:

Get-NetAdapter
Get-NetIPConfiguration
Get-DnsClientServerAddress

Example static addressing on a known interface:

New-NetIPAddress -InterfaceAlias 'Ethernet' `
  -IPAddress 192.168.50.20 -PrefixLength 24 `
  -DefaultGateway 192.168.50.1

Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' `
  -ServerAddresses 192.168.50.10,192.168.50.11

These commands make immediate changes and can disconnect a remote session. Interface aliases and existing addresses vary. Validate the change through console/out-of-band access and do not copy sample addresses into a real network.

Updates and drivers

Install supported firmware and drivers through approved vendor or update channels. Apply cumulative/security updates, restart as required and check for another update cycle. Record the OS build after completion.

Device Manager can show missing or failed devices. Event logs and vendor diagnostics can reveal driver initialization errors. A generic driver can provide basic operation while lacking performance or management features.

Time, activation and domain join

Verify time zone, system time and synchronization source. Check activation/licensing state through supported interfaces. Join the domain only after DNS points to the organization's domain-capable DNS service and time is correct.

Get-TimeZone
w32tm /query /status
Add-Computer -DomainName 'corp.example' -Credential (Get-Credential) -Restart

w32tm output and domain-join cmdlet behaviour vary by context. Get-Credential prompts for the domain account interactively; without -Credential, Add-Computer uses the current user's credentials. Credentials should be entered securely, not placed in a script as clear text.

Activation methods

Activation is checked and changed with the Software Licensing Management Tool:

slmgr /dlv
slmgr /xpr
slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
slmgr /ato

/dlv displays detailed license information, /xpr shows the expiry state, /ipk installs a product key (placeholder shown) and /ato attempts activation. slmgr is a script (slmgr.vbs) and shows its results in dialog boxes; run it as cscript C:\Windows\System32\slmgr.vbs /dlv to print results in the console.

Windows Imaging Concepts

Windows installation media commonly uses Windows Imaging Format files in the sources folder. install.wim contains installable Windows images; some media use the more highly compressed install.esd, and an image split into several files for FAT32 media uses install.swm, install2.swm and so on. boot.wim provides the Windows Preinstallation Environment used to start setup or deployment. In installation media, boot.wim index 1 is plain Windows PE and index 2 is Windows PE with Windows Setup.

An image is file based rather than a raw sector copy in the ordinary WIM workflow. Identical files are stored only once (single-instance storage), so one WIM can contain several indexed editions or configurations with little extra space. Windows Server media normally includes Standard and Datacenter, each in Server Core and Desktop Experience form. Tools must select the intended index, and index numbers differ between media, so always list them first.

Servicing images with DISM

Deployment Image Servicing and Management (DISM.exe) is the built-in tool to inspect, mount, service, capture and apply Windows images. It replaced the older ImageX tool. The DISM PowerShell module provides equivalent cmdlets. Offline servicing changes a mounted image file without starting it. Online servicing (/Online) changes the running Windows installation.

A typical offline update of an install image, run from an elevated prompt (paths, index and file names are examples):

Dism /Get-ImageInfo /ImageFile:D:\Images\install.wim
Dism /Mount-Image /ImageFile:D:\Images\install.wim /Index:2 /MountDir:C:\Mount
Dism /Image:C:\Mount /Add-Driver /Driver:D:\Drivers /Recurse
Dism /Image:C:\Mount /Add-Package /PackagePath:D:\Updates\cumulative-update.msu
Dism /Image:C:\Mount /Enable-Feature /FeatureName:NetFx3 /Source:D:\sources\sxs
Dism /Image:C:\Mount /Get-Packages
Dism /Unmount-Image /MountDir:C:\Mount /Commit

Common servicing mistakes are forgetting /Commit (all changes are lost), adding a driver or update built for a different Windows release or architecture, and leaving an image mounted after a failure. Dism /Get-MountedImageInfo lists mounted images and Dism /Cleanup-Mountpoints removes stale mounts. Applications are normally installed through online servicing on a reference computer or after deployment, not by offline servicing.

The equivalent PowerShell cmdlets are Get-WindowsImage, Mount-WindowsImage, Add-WindowsDriver, Add-WindowsPackage, Enable-WindowsOptionalFeature and Dismount-WindowsImage -Save (or -Discard).

DISM also captures, applies and splits images, usually from Windows PE:

Dism /Capture-Image /ImageFile:E:\Images\ref-2026-10.wim /CaptureDir:C:\ /Name:"Reference 2026-10"
Dism /Apply-Image /ImageFile:E:\Images\ref-2026-10.wim /Index:1 /ApplyDir:W:\
Dism /Split-Image /ImageFile:E:\sources\install.wim /SWMFile:F:\sources\install.swm /FileSize:3800

/Capture-Image creates a WIM from a volume; capture from Windows PE so the captured Windows is not running. /Apply-Image writes an image to a prepared, formatted partition. After applying an image manually, bcdboot W:\Windows creates the boot files on the system partition. /Split-Image creates .swm pieces of at most the given size in MB, so a large install image fits on FAT32 USB media.

Reference-image lifecycle

Trusted media
   -> reference VM
   -> updates, drivers and approved baseline
   -> audit/test
   -> Sysprep generalize
   -> capture image
   -> protected image repository
   -> pilot deployment
   -> broad deployment

A virtual machine is often used as the reference because its hardware is controlled and snapshots support the build process. Avoid installing device-specific drivers that every target does not need.

Sysprep and generalization

Sysprep (System Preparation Tool, C:\Windows\System32\Sysprep\sysprep.exe) prepares Windows for imaging. The /generalize option removes or resets system-specific state so that clones become distinct installations. This includes the computer security identifier (SID), computer name, Plug and Play hardware state, event logs and system restore points. During the next boot, the specialize pass generates a new SID. /oobe requests the appropriate first-boot experience, and /shutdown turns off the reference after preparation.

C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown

Running Sysprep without parameters opens a small dialog with the same choices. During OOBE, pressing Ctrl+Shift+F3 also restarts the computer into audit mode for reference-image customization.

This command should run only in a disposable, prepared reference system according to the target Windows version's imaging guidance. Sysprep has limits on repeated use and can fail because of application/package state. It is not supported on a domain controller, and some server roles are not supported for generalization; if the computer is domain-joined, generalizing removes it from the domain. Capture the system only after it shuts down; booting it normally can specialize it again.

Generalization does not sanitize every secret or application identity automatically. Inspect application configuration, certificates, agents, logs and deployment accounts before capture.

Thick, thin and hybrid images

• A thick image includes many applications and settings. Deployment is fast but image maintenance is heavy.
• A thin image contains the OS and small baseline; applications install afterward. It is easier to refresh but takes longer during deployment.
• A hybrid image includes stable common components and deploys changing applications separately.

Select based on network capacity, application change rate, deployment time and patch process. A huge image is not automatically more complete if its embedded applications are outdated.

Unattended Installation

An answer file supplies setup choices without requiring a technician to answer every prompt. Windows Setup commonly uses an XML answer file such as Autounattend.xml or Unattend.xml, depending on stage and location.

Configuration passes apply settings at different phases, such as Windows PE, specialization and first logon/OOBE. A setting valid in one pass may be ignored in another. Windows Setup has seven configuration passes:

Setup automatically searches for a file named Autounattend.xml at the root of removable media, which is useful for the windowsPE pass. A file named unattend.xml is typically supplied with sysprep /unattend:<file> or setup.exe /unattend:<file>, or placed in C:\Windows\Panther. Windows System Image Manager (Windows SIM), part of the Windows Assessment and Deployment Kit (Windows ADK), builds and validates answer files against a catalog created from a specific Windows image.

Answer-file concepts include:

• edition/image selection;
• disk partitioning and formatting;
• locale and keyboard;
• product/licensing settings where permitted;
• computer naming rules;
• network and domain/workgroup choices;
• first-boot commands or scripts;
• local account configuration.

Security risks

An answer file can expose local administrator credentials, domain join accounts or product keys. Restrict file access, avoid reusable high-privilege credentials, remove temporary answer files after setup where supported and rotate any deployment secret that could be recovered.

Do not place one domain administrator password in a shared image. Prefer scoped deployment accounts and mechanisms that protect or retrieve secrets at deployment time.

Validation

XML being well formed does not prove that every component exists in the selected image or pass. Validate against the exact image, then run a pilot deployment. Inspect setup logs for settings that were ignored or rejected.

Windows Deployment Services

WDS is a Windows Server role for network-based deployment. It lets PXE-capable clients start a deployment environment without local DVD/USB media. This course emphasizes WDS for bare-metal and image-based installation.

WDS components and images

• Deployment Server: provides image and management functionality in a full WDS deployment.
• Transport Server: provides core multicast/transport capability in supported designs.
• Boot image: typically based on Windows PE and starts deployment.
• Install image: contains the operating system to apply to the target.
• Capture image: a customized boot image that can assist capturing a generalized reference machine.
• Discover image: a boot image placed on USB/DVD media so a computer that cannot PXE-boot can still locate the WDS server.

A PXE client first downloads a boot image to start Windows PE and the deployment wizard. It then chooses an install image to apply.

Network boot flow

Client powers on
     |
PXE firmware requests network configuration
     |
DHCP supplies address and boot information / network directs client
     |
Client downloads network boot program
     |
Windows PE boot image starts
     |
Administrator or automation selects install image
     |
Disk prepared, image applied, system specializes and starts

DHCP and WDS can run on the same or different servers. Options and PXE response settings depend on topology and version. Across routed subnets, relay/helper configuration should carry the required DHCP/PXE exchanges. Hard-coding legacy DHCP options is not a universal solution because UEFI and BIOS clients can need different boot files.

WDS planning

The server needs stable networking, DNS/domain integration as required by its mode, sufficient NTFS storage for images, permissions, and firewall/network reachability. Image distribution consumes bandwidth; multicast can reduce duplicate traffic when many clients deploy simultaneously, but network infrastructure must support it correctly.

WDS deployment process

1. Install the Windows Deployment Services role and selected role services.
2. Configure its remote-install repository on suitable NTFS storage.
3. Add a compatible Windows PE boot image.
4. Create an image group and add the intended install image.
5. Configure PXE response and client authorization policy.
6. Boot one representative test client using the correct firmware mode.
7. Validate disk layout, drivers, naming, network and post-install tasks.
8. Expand deployment gradually and monitor server/network capacity.

Version note for step 3: Microsoft has partially deprecated the classic WDS operating-system deployment workflow. Using the boot.wim taken directly from Windows 11 or Windows Server 2022 (and later) installation media as a WDS boot image is not supported. WDS can still PXE-boot custom Windows PE boot images built with the Windows ADK or a deployment platform such as Configuration Manager. Boot images from Windows 10 or Windows Server 2019 and earlier media still work in the classic workflow. Topic 5 covers WDS role configuration in more detail.

Turning off Windows Firewall is not a sound WDS prerequisite. Configure required WDS, DHCP and management rules. Likewise, a static server address is useful, but it must be part of a valid DNS and routing design.

WDS troubleshooting

If a client receives no IP address, begin with DHCP/VLAN/relay reachability. If it receives an address but no boot offer, inspect WDS PXE response, relay and firewall. If it downloads a boot program but fails before Windows PE, check architecture/firmware-compatible boot files and network transfer. If Windows PE starts but cannot see the disk or network, add suitable storage or network drivers to the boot image. If no install image appears, check architecture, permissions and image-group configuration.

Deployment with Management Platforms

System Center Configuration Manager, now represented in Microsoft Configuration Manager branding, can coordinate operating-system deployment, applications, updates, inventory and compliance. A task sequence can partition disks, apply an image, inject drivers, join a domain, install applications and run validation steps.

A task sequence is automation, not proof. Each step should have conditions, error handling, logs and a defined retry/rollback approach. Driver selection should use hardware models rather than injecting every available driver into every system.

Deployment systems should maintain collections or groups so that destructive OS deployment is targeted only to authorized devices. A mistaken collection membership can reimage the wrong computer. Approval and role-based access therefore protect the deployment platform itself.

Post-Installation Verification

Verification must test the operating system, hardware, security and intended role.

System identity and build

hostname
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, TotalPhysicalMemory

Check that name, release, build, edition and domain/workgroup match the plan.

Hardware and storage

Get-PnpDevice | Where-Object Status -ne 'OK'
Get-Disk
Get-Partition
Get-Volume

Look for failed devices, unexpected offline disks, wrong partition style, missing volumes, incorrect file systems and low free space. Cmdlet availability can depend on version/module.

Network and DNS

Get-NetIPConfiguration
Test-NetConnection 192.168.50.1
Resolve-DnsName corp.example

Test gateway or required destinations, DNS resolution and required application ports. A successful ping does not prove a TCP service or DNS configuration.

Roles, services and events

Get-WindowsFeature | Where-Object InstallState -eq 'Installed'
Get-Service | Where-Object Status -ne 'Running'
Get-WinEvent -LogName System -MaxEvents 50

Not every stopped service is faulty; many start on demand or are disabled intentionally. Compare with the designed role. Review critical/error events with context rather than treating every warning as deployment failure.

Security and recovery

Confirm firewall profiles/rules, endpoint security, local administrator policy, patch level, logging, monitoring and backup enrollment. Perform a role-specific backup or restore test according to the recovery plan. Remove temporary media, scripts and credentials.

Application acceptance

Test from a client perspective. For IIS, request the intended site. For a file server, access a share as an authorized and unauthorized user. For a domain service, run role-specific diagnostics. A green service status is only one piece of evidence.

Installation and Deployment Troubleshooting

Setup cannot use the selected disk

Check whether the installer booted in UEFI or legacy mode and whether the disk is GPT or MBR as required. Confirm storage-controller visibility and drivers. Protect data before converting or deleting partitions.

Disk or network adapter is missing

The installation environment can lack a suitable driver. Obtain a signed driver intended for the hardware and Windows release. For mass deployment, add critical boot/storage/network drivers to the correct image rather than manually loading them on every device.

Repeated restart or boot failure

Separate firmware/boot-manager failures from driver/kernel failures. Use Windows Recovery Environment, startup repair, boot logs, event data or safe/recovery options as supported. A newly added storage or filter driver is a stronger suspect than an unrelated user application if Windows fails early.

Domain join fails

Verify DNS server settings first. A client must resolve domain records through appropriate DNS. Check time synchronization, network reachability, firewall, credentials, computer-name uniqueness and permissions. Public DNS configured on a domain member does not know private Active Directory records.

Sysprep fails

Read Sysprep logs (setupact.log and setuperr.log in C:\Windows\System32\Sysprep\Panther) rather than recapturing blindly. Common causes include unsupported app-package state, pending operations or exceeding supported image-processing conditions. Repair the reference build or rebuild it from the documented process; avoid manually copying an unspecialized VM disk as the final image.

Deployed machines share identity or configuration

Confirm that the reference was generalized and the deployment process applies unique names, addresses and management identities. Some agents and applications need their own identity-reset procedure beyond Sysprep.

Deployment is slow

Measure WDS/server disk throughput, network utilization, multicast configuration, image size and post-install downloads. A thick image reduces later application transfer but increases image distribution and maintenance. Diagnose the bottleneck before adding server CPU.

Common Mistakes

• Selecting an edition based only on name rather than licensing and required capabilities.
• Choosing Server Core without a remote-management plan, or Desktop Experience without a workload need.
• Treating an installed role as a configured and verified service.
• Deleting EFI or recovery partitions because they lack drive letters.
• Confusing a volume layout with backup or physical redundancy.
• Starting a clean installation without a separately verified backup.
• Performing an in-place upgrade without a supported path and rollback condition.
• Capturing an image without generalizing machine-specific state.
• Unmounting a serviced image without /Commit, which discards every change.
• Booting from installation media to perform an "upgrade"; an in-place upgrade starts from Setup inside the running Windows.
• Storing reusable administrator or domain credentials in an answer file.
• Disabling Windows Firewall instead of allowing required service traffic.
• Deploying one image broadly before testing hardware drivers and firmware mode.
• Declaring success when Windows boots without testing the user-facing role.

Key Points

• Windows separates user mode from privileged kernel mode; drivers and kernel components have system-wide impact.
• Editions, Server Core/Desktop Experience installation options, and server roles answer different design questions.
• Standard includes two Windows Server VMs per licensed host; Datacenter includes unlimited VMs plus Storage Spaces Direct, SDN and Shielded VMs.
• From Windows Server 2016 onward, Server Core and Desktop Experience cannot be switched after installation.
• Plan workload, compatibility, identity, network, storage, security and recovery before installation.
• UEFI commonly boots Windows from GPT storage using an EFI System Partition; legacy BIOS/MBR is a different path.
• NTFS is the general Windows system/data file system; ReFS usage depends on role, edition and release.
• Clean installation, in-place upgrade and migration have different benefits, dependencies and rollback needs.
• Generalized WIM-based images create repeatable baselines, but they still need patching and unique post-deployment identity.
• Sysprep /generalize resets the SID and other machine-specific data; DISM mounts, services (drivers, updates, features), captures and applies WIM images.
• Unattended answer files improve consistency and also create credential and targeting risks.
• WDS uses network boot, Windows PE boot images and install images for repeatable deployment.
• Post-install validation covers build, drivers, disks, networking, roles, events, security, backup and application behaviour.
• Document every deployment decision so later administrators can reproduce, repair and securely retire the server.

Worked Deployment Decision

An organization must replace twenty unsupported file servers. Existing data must remain available, the hardware changes, and a long outage is unacceptable. Treating this as “run Setup twenty times” misses the real problem.

First inventory server roles, shares, permissions, storage use, applications, dependencies, firmware and network identity. Select a supported Windows Server edition and installation option. Build and patch a reference process, but do not embed the old server's identity. Test required storage/network drivers in Windows PE and the installed operating system.

~~~text inventory old server ↓ design target storage and identity ↓ deploy clean target from tested image ↓ configure role and security ↓ copy/synchronize data and permissions ↓ perform client acceptance tests ↓ controlled cutover ↓ verify backup and rollback condition ~~~

This is a side-by-side migration. A clean target reduces inherited configuration, while staged data transfer reduces cutover time. The old server remains a rollback resource until acceptance conditions are met.

Acceptance evidence

The migration is not complete merely because files appear in a directory. Permissions, share configuration, applications and recovery must also behave as designed.

Installation Automation Boundaries

Automation improves consistency when inputs are controlled. It can partition a disk, apply an image, add drivers, configure locale and run post-install steps. The same automation can erase the wrong disk or distribute a secret if targeting is careless.

Use separate phases:

1. Discovery: identify device model, firmware mode, disks and network.
2. Eligibility: confirm that the machine matches the approved deployment group.
3. Apply: partition and install using controlled media/image.
4. Specialize: assign unique identity and environment settings.
5. Configure: apply roles, updates and security policy.
6. Validate: collect evidence and reject failed builds.

Do not put reusable privileged credentials in an answer file stored with general deployment media. Use protected mechanisms appropriate to the management platform and remove temporary secrets.

Repeatability and drift

An image is a baseline at capture time. Drivers, patches and application packages change afterward. Maintain a documented image pipeline:

~~~text approved source media ↓ reproducible customization patched reference ↓ generalize and capture versioned image ↓ pilot deployment acceptance results ↓ controlled release ~~~

Record image version, source build, included updates, drivers and validation results. Rebuilding from a documented process is safer than repeatedly modifying an unexplained “golden” machine.

Architecture-Based Failure Reasoning

Windows architecture helps interpret symptoms:

• One user application crashes while the OS remains stable: begin with that user-mode process and its dependencies.
• Every application using one device fails: investigate its driver, device and service stack.
• The system fails before logon after a new boot/storage driver: use recovery tools and examine early boot dependencies.
• A role is installed but clients cannot use it: verify service configuration, network binding, firewall, DNS and authorization.
• A graphical tool is absent on Server Core: use PowerShell, remote administration or supported command tools; do not assume the role itself is missing.

The kernel/user boundary is not a troubleshooting slogan. It indicates fault impact. Kernel-mode defects can affect the whole computer; a user-mode process normally has a more limited failure boundary.

Final Installation Checklist

Before installation:

• confirm supported edition, installation option and upgrade/migration path;
• inventory hardware, firmware, drivers, applications and dependencies;
• verify backup and recovery media separately;
• plan disk layout, name, addresses, DNS, time and domain placement;
• document rollback and acceptance criteria.

After installation:

• verify build and activation context;
• install approved updates and signed drivers;
• configure management access and firewall deliberately;
• add only required roles/features;
• verify storage, network, DNS and time;
• enroll monitoring, logging and backup;
• run role-specific authorized and unauthorized tests;
• store configuration and validation evidence.

This closes the loop between architecture, deployment and operation. A server is ready when it satisfies its documented service, security and recovery requirements, not simply when Setup reaches the desktop or command prompt.

Change and Rollback Record

Every production installation or migration should leave a concise operational record: who approved it, source image and build, selected edition and installation option, firmware/partition mode, drivers, roles, network identity, update level, validation results and remaining exceptions. Record the previous state and the point after which rollback is no longer safe.

Rollback is more than “restore the backup.” A usable plan identifies the trigger, decision owner, old-system availability, DNS/name reversal, data written after cutover and how those new changes will be preserved. Test the steps before the maintenance window.

When validation fails, do not hide it by marking the deployment successful with a comment. Classify the failure as blocking or accepted risk, capture evidence and either correct it or execute the planned rollback. This discipline prevents a technically bootable server with broken identity, storage, permissions or recovery from entering service as if it were complete.

Finally, review the deployed server from the client's viewpoint and the administrator's viewpoint. The client needs the intended service, name resolution and authorization. The administrator needs secure management, observable health, consistent configuration and tested recovery. Both perspectives are necessary. A service that works only from the local console is not proven reachable, while a service reachable by one administrator account is not proof that ordinary permissions are correct. Record successful and deliberately denied tests so later troubleshooting has a trustworthy baseline.

Retain that baseline with change records, recovery documentation and responsible ownership details throughout the server's supported operational life and eventual replacement cycle.