Lesson 2: Install and Upgrade Windows

The dangerous part of installing an operating system is not clicking Next.

It is deciding what can be erased, what must be preserved, whether the hardware is supported, how the machine will boot, which drivers are required, and what happens if deployment fails halfway through.

A good Windows installation begins before installation media is inserted.

First question: what kind of deployment is this?

"Install Windows" can describe several different jobs.

Clean install

A clean install creates a fresh operating environment.

That can make sense when the system is being repurposed, the old installation is not worth preserving, or a standardized fresh baseline is required.

It is destructive to the selected existing operating-system state.

Do not format first and ask about user data later.

In-place upgrade

An upgrade attempts to preserve supported applications, settings, and data while moving to a supported target.

The word supported matters.

Application compatibility, drivers, available storage, hardware requirements, and the vendor's supported upgrade path still apply.

Image deployment

A prepared image can deliver a standardized environment repeatedly.

That makes sense when many similar endpoints need the same base configuration.

The image itself becomes a maintained artifact that must be patched, validated, and compatible with the target hardware.

Remote network installation

A managed network installation can deliver the operating system from deployment infrastructure rather than local media.

That adds dependencies:

endpoint boot support
   ↓
network path
   ↓
deployment service
   ↓
installation image / configuration

Zero-touch deployment

Zero-touch provisioning moves more work into centralized policy, identity, and automation so the local technician performs little or no manual setup.

That saves repeated hands-on work at scale.

It does not remove dependencies. It adds several of them before the user ever signs in.

Repair installation or recovery

A damaged Windows installation may be repairable without immediately destroying the existing environment.

Supported repair or recovery options may preserve more state than a clean installation.

The decision depends on the severity of damage, confidence in the existing system, backup state, time, and organization procedure.

Clean installation is a tool, not a personality trait.

System process animation

Windows install, startup, and recovery boundaries

Keep firmware, disk layout, boot files, OS, drivers, and recovery evidence distinct.

RestartPreviousPlay sequenceNext

1. 1Firmware modeUEFI settings establish boot expectations.
2. 2Disk layoutGPT/MBR and partitions provide boot structures.
3. 3Boot filesBoot configuration points to the OS loader.
4. 4OS imageWindows system files load.
5. 5Drivers / servicesDrivers and services create a usable system.
6. 6RecoveryThe least-destructive approved tool repairs the boundary.
7. 7VerifyStartup and the original function are retested.

Technician question: When does reinstalling become premature?

Installation media changes the dependency path

Windows installation and recovery can begin from several sources:

• USB media;
• network boot;
• solid-state or flash media;
• internet-based recovery or installation;
• external or hot-swappable storage where supported;
• an internal recovery partition;
• a multiboot environment.

Do not memorize the list as interchangeable options.

Ask:

Where does the installation environment come from, and what does that source depend on?

A network install is efficient for many endpoints but useless if the deployment path is unavailable.

A local USB is self-contained but may be inefficient across thirty systems.

An internal recovery partition is convenient until the disk containing it fails.

GPT and MBR describe disk-partitioning structures

Modern Windows systems commonly use GPT with UEFI.

MBR is an older partitioning model commonly associated with legacy BIOS-era workflows and carries more limitations.

The boot mode, disk layout, and supported Windows installation need to agree.

A simplified modern relationship looks like:

supported platform
   ↓
UEFI
   ↓
GPT disk layout
   ↓
supported Windows install

Do not casually convert partition styles on a disk containing unprotected data.

Partition operations can be destructive.

Boot structure comparison

GPT and MBR answer a disk-layout question

Do not confuse a partition-table format with a filesystem or an operating system.

1. 01
   GPT

   Modern partition-table format commonly paired with UEFI boot.

   Evidence: Protective MBR, primary and backup headers, partition entries
2. 02
   MBR

   Legacy partition-table and boot-code structure with older size and primary-partition limits.

   Evidence: Single sector contains boot code and partition entries
3. 03
   Verify

   Firmware mode, disk layout, boot files, and OS expectations must agree.

   Evidence: Inspect actual state before converting or reinstalling

Formatting is a state-changing storage operation

Formatting creates a filesystem on the selected target volume.

It is not housekeeping.

Before formatting, prove:

• correct target disk;
• correct partition or volume;
• required data is protected;
• selected filesystem fits the use case;
• recovery plan exists.

One wrong disk selection can turn a routine deployment into a data-recovery problem.

Drivers connect Windows to hardware behavior

Windows includes drivers for a large amount of hardware.

Some systems still require trusted third-party or vendor drivers during or after deployment, including storage controllers, network adapters, graphics, chipset/platform components, and specialty hardware.

If Setup cannot see a storage device, the drive is not automatically dead.

Possible boundaries include:

• firmware or storage-controller mode;
• missing controller driver;
• unsupported hardware;
• physical storage failure.

Use trusted, approved driver sources.

"Download the first driver result you find" is not a deployment strategy.

Backward compatibility matters before the upgrade

A newer Windows version may be supported by the hardware while an older application, peripheral, or driver is not.

Before an upgrade, inventory what the user actually depends on:

• business or classroom applications;
• specialty drivers;
• printers and scanners;
• plugins or older runtime requirements;
• local files and preferences.

A technically successful upgrade that breaks the required application is still a failed deployment.

Backup is a prerequisite

Before a destructive install or major upgrade, identify what must survive:

• user documents;
• project files;
• application data;
• browser or user preferences where required;
• encryption recovery information;
• licenses or activation details where applicable;
• application installers and configuration.

Then verify the recovery path.

A folder named Backup on the same disk you are about to repartition is not independent recovery.

Hardware compatibility is only one part of supportability

Before deployment check:

hardware support
firmware / TPM / UEFI requirements
driver availability
application compatibility
storage capacity
upgrade-path support
vendor lifecycle

A setup program launching successfully does not prove the platform is supported.

Feature updates and lifecycle change the answer over time

An operating system can still boot after its support window ends.

That does not make it an appropriate managed deployment.

Technicians need to consider:

• security-update availability;
• feature-update eligibility;
• vendor lifecycle dates;
• application and hardware-vendor requirements.

"Still works" and "still supported" are different claims.

Worked case: thirty identical lab laptops

Requirement:

30 similar devices
same approved Windows baseline
organization network available
minimal technician touch
no user data present yet

Manual USB installation thirty times would work.

It is probably not the strongest design.

A maintained image, remote network deployment, or zero-touch process may provide more consistency and less repetitive work.

Now identify the dependencies:

• network availability;
• deployment service;
• hardware compatibility;
• maintained image or policy;
• failed-provisioning recovery.

Automation does not remove architecture. It moves the work earlier.

Worked case: damaged Windows installation

Evidence:

hardware diagnostics: healthy
user backup: verified
recovery environment: available
system files: damaged

A repair or recovery-first path is reasonable before destructive reinstall.

What would justify moving to a clean install?

• repair repeatedly fails;
• installation integrity cannot be trusted;
• organization baseline requires reimaging;
• the time/recovery tradeoff favors a fresh deployment.

The decision should be explicit.

Design six deployment tickets

For each supplied case, document:

installation objective
boot / installation source
clean / upgrade / image / remote / zero-touch / repair path
GPT / MBR consideration
driver dependency
data and preferences that must survive
backup / recovery verification
hardware and application compatibility concern
lifecycle concern
post-install verification

Do not use "Setup completed" as the final verification.

Verify the actual required outcome: correct supported edition and version, devices and drivers healthy, network working, applications functioning, user data restored where required, and update/security state appropriate.

Before you move on

The setup wizard is only the middle of the job.

A complete deployment is:

requirements
→ compatibility
→ data protection
→ deployment method
→ disk / boot decisions
→ drivers
→ Windows configuration
→ verification
→ recovery documentation

Next we inspect the Windows tools that expose those layers after the system is running.