Turn Your Old Windows Laptop Into a Home Server: The Complete WSL2, Docker, and High-Availability Guide

In our previous 5-part series, we explored how to transform a retired HP 15s-du2077TU laptop into a dedicated Linux server by wiping the hard drive and installing Ubuntu Server bare-metal.

But what if you do not want to destroy your pre-installed Windows installation?

Perhaps you have a pre-activated Windows Home license that you want to retain, or you need the laptop to remain dual-use—functioning as a backup Windows desktop when plugged into a monitor, while operating headlessly in the background. Or maybe you are hesitant to commit to a full bare-metal Linux installation and prefer a setup that can be reversed or migrated.

Operating a server on Windows Home introduces unique challenges. Unlike Windows Pro, Enterprise, or Server, Windows Home lacks access to Hyper-V Manager, group policy editors (gpedit.msc), and advanced remote desktop configurations. Furthermore, standard Windows installations are designed for interactive use: they put the system to sleep when the lid is closed, and force automatic restarts during OS updates, which can interrupt your background services.

This guide provides a comprehensive, 5,000+ word technical walkthrough to configuring Windows Home as a high-availability server base.

We will configure BIOS virtualization, install Windows Subsystem for Linux (WSL2), bypass the RAM-heavy Docker Desktop app by installing Docker Engine natively inside WSL2, configure port-forwarding proxies, configure automated auto-login and task schedules to run your containers on system boot, manage sleep and update states, and write PowerShell scripts to monitor battery and SSD health.

1. Virtualization Foundations on Windows Home

To run Linux workloads on Windows at near-native speeds, we will leverage Windows Subsystem for Linux (WSL2). WSL2 runs a real Linux kernel inside a lightweight utility virtual machine managed by the Windows hypervisor platform.

Before configuring the software, we must prepare the motherboard firmware.

1.1 Firmware Configuration: Enabling Intel VT-x

Because WSL2 relies on hardware-assisted virtualization, virtualization must be enabled in your laptop’s BIOS/UEFI.

Enter BIOS: Shut down your HP laptop completely. Press the power button, and immediately tap the Esc key repeatedly until the Startup Menu appears. Press F10 to enter the BIOS Setup Utility.
Locate Virtualization: Navigate to the System Configuration tab using the arrow keys.
Enable Intel Virtualization Technology: Scroll down to Virtualization Technology (VTx) and change its status to Enabled. If your processor is AMD-based, this setting may be called SVM Mode.
Enable VT-d / IOMMU: Enable Intel VT-d (directed I/O virtualization) if it is listed. This assists the kernel in handling virtualized memory mapping.
Save and Exit: Press F10, select Yes to save changes, and boot into Windows.

Verify virtualization is active: Open Windows Task Manager (Ctrl + Shift + Esc), click the Performance tab, select CPU, and verify that the bottom right display reads: Virtualization: Enabled.

+-----------------------------------------------------------+
|                   TASK MANAGER CPU VIEW                   |
|                                                           |
|  Intel Core i5-1035G1 CPU @ 1.00GHz                       |
|  Cores: 4  |  Logical Processors: 8                       |
|  L1 Cache: 320 KB  |  L2 Cache: 2.0 MB  |  L3: 6.0 MB      |
|                                                           |
|  Virtualization: ENABLED <--- (CONFIRM THIS STATUS)       |
+-----------------------------------------------------------+

1.2 Enabling Windows Virtualization Packages

Windows Home does not include the Hyper-V hypervisor management console. However, it includes the underlying Virtual Machine Platform and Windows Subsystem for Linux optional packages.

Open PowerShell as an Administrator and execute the following DISM (Deployment Image Servicing and Management) commands to activate the packages:

# Enable Windows Subsystem for Linux
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

# Enable Virtual Machine Platform (Required for WSL2)
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Restart your laptop to allow Windows to install the virtualization modules.

2. Installing and Configuring WSL2

With the virtualization packages active, we will install the default Ubuntu Linux distribution and configure its resource boundaries.

2.1 Installing Ubuntu on WSL2

Open PowerShell (no admin rights required) and run the installer:

# Update the WSL kernel and install Ubuntu
wsl --install -d Ubuntu

This command downloads the latest Linux kernel package from Microsoft and installs the Ubuntu environment. During installation, a terminal window will open, prompting you to configure a default Linux username and password (e.g., serveradmin). Keep these credentials secure, as they will manage services inside the Linux environment.

Verify the version is set to WSL2:

wsl --list --verbose

Ensure the version column displays 2. If it displays 1, convert the distribution manually:

wsl --set-version Ubuntu 2

2.2 WSL2 Resource Boundaries: Creating `.wslconfig`

By default, WSL2 acts as a dynamic utility VM: it can consume up to 50% of your host RAM (or up to 8GB, depending on your OS configuration) and uses all CPU cores. Under heavy database writes or local AI processing, WSL2 can starve the Windows host, causing Windows to stutter or lock up.

To prevent this, we must configure strict resource limits by creating a custom global configuration file in your Windows user profile folder.

In Windows, press Win + R, type notepad %USERPROFILE%\.wslconfig, and press Enter.
If prompted to create a new file, select Yes.
Add the following configurations:

[wsl2]
# Restrict WSL2 to 4 physical cores (leaving 4 threads for Windows Host processes)
processors=4

# Cap RAM allocation. On a 16 GB laptop, allocate 10-12 GB for the server, leaving 4 GB for Windows
memory=10GB

# Allocate Swap Space inside Windows (used when Linux RAM is saturated)
swap=4GB

# Set localhost forwarding to true (binds WSL2 ports directly to Windows localhost interface)
localhostForwarding=true

Save the file. To apply the new boundaries, shut down the running WSL instance from PowerShell:

wsl --shutdown

When you launch Ubuntu again, the kernel will boot within the configured limits (capped at 4 cores and 10 GB of RAM).

3. Lightweight Docker Configuration (Bypassing Docker Desktop)

Most guides recommend installing Docker Desktop for Windows to run containers. However, Docker Desktop is designed for desktop developers, not servers:

It runs a heavy background management GUI and auxiliary services that consume 1.5 GB to 2.5 GB of RAM at idle.
It forces the creation of two separate helper distributions (docker-desktop and docker-desktop-data), adding overhead.
On a resource-constrained 16 GB laptop, losing 2 GB of RAM to the Docker Desktop client leaves little room for your databases, APIs, and AI models.

To maximize efficiency, we will bypass Docker Desktop entirely. Instead, we will install the native Linux Docker Engine directly inside our WSL2 Ubuntu instance. This configuration runs Docker daemon as a lightweight system service, consuming <100 MB of RAM at idle.

Docker Desktop Setup (Heavy: ~2.0 GB Idle RAM)
==============================================
[ Windows Host ] ---> [ Docker Desktop App (1.5GB) ] ---> [ Helper WSL VM (500MB) ] ---> [ Containers ]

Native WSL2 Docker Setup (Lightweight: <100 MB Idle RAM)
========================================================
[ Windows Host ] ---> [ WSL2 Ubuntu instance ] ---> [ Docker Engine Service (80MB) ] ---> [ Containers ]

3.1 Step-by-Step Native Docker Installation in WSL2

Open your Ubuntu WSL terminal and run the following commands to configure Docker’s official repository and install the runtime engine.

1. Clean old conflicts:

sudo apt-get remove -y docker.io docker-doc podman-docker containerd runc

2. Install prerequisites:

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release

3. Register Docker’s official GPG key:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

4. Add the apt repository list:

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

5. Install the Docker packages:

sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

6. Allow your user to manage Docker without sudo:

sudo usermod -aG docker $USER

Note: Close your WSL terminal and open it again to apply the group membership changes.

3.1.1 Configuring Docker Daemon Logs Limit

Inside a lightweight WSL2 VM, Docker logs can accumulate quickly, bloating the ext4 virtual disk (VHDX) file on your Windows host. Because shrinking a VHDX file requires manual PowerShell commands (Optimize-VHD), it is critical to prevent bloating by capping log files in /etc/docker/daemon.json inside Ubuntu:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Create this file via sudo nano /etc/docker/daemon.json and reload the docker service:

sudo systemctl restart docker

3.2 Activating systemd in WSL2

Historically, WSL2 did not support systemd init processes, forcing users to start services manually using sudo service docker start. However, modern WSL2 releases natively support systemd, which allows you to manage services using standard systemctl commands.

Open your WSL terminal and create or edit the /etc/wsl.conf file:

sudo nano /etc/wsl.conf

Add these lines to enable systemd:

[boot]
systemd=true

Save the file and exit the editor. In PowerShell, restart WSL to reload the configuration:

wsl --shutdown

Now, launch Ubuntu again. The Docker daemon will start automatically on boot. Verify that systemd is managing Docker:

systemctl status docker

4. Headless Server Hacks: Managing Windows Sleep & Update States

A critical challenge when using Windows as a server platform is ensuring the host OS remains online. By default, Windows is optimized for client use: it puts the system to sleep when idle, puts the machine to sleep when the lid is closed, and forces reboots when updates are installed. We must configure settings to ensure high uptime.

4.1 Modifying Lid Close and Sleep Behavior

By default, closing your laptop lid triggers sleep mode, which halts all virtual machines and network connections. We must override this setting.

Press Win + R, type control, and press Enter to open the Control Panel.
Navigate to Hardware and Sound > Power Options.
In the left sidebar, click "Choose what closing the lid does".
Change the option for When I close the lid under both On battery and Plugged in to "Do nothing".
Click "Save changes".

+-----------------------------------------------------------+
|                      POWER SETTINGS                       |
|                                                           |
|  When I close the lid:                                    |
|     On battery:  [ Do nothing ]                           |
|     Plugged in:  [ Do nothing ]  <--- (SET BOTH TO THIS)  |
+-----------------------------------------------------------+

Next, disable the standby timeout:

Go back to Power Options and click "Change when the computer sleeps" next to your active power plan.
Set Put the computer to sleep to "Never" (under both battery and plugged-in states).
Click "Save changes".

You can also apply these settings via PowerShell as an Administrator:

# Set lid close action to do nothing (for AC power)
powercfg /setacvalueindex SCHEME_CURRENT SUB_BUTTONS LIDACTION 0

# Set lid close action to do nothing (for DC power)
powercfg /setdcvalueindex SCHEME_CURRENT SUB_BUTTONS LIDACTION 0

# Disable sleep timeout on AC power
powercfg /change standby-timeout-ac 0

# Apply changes
powercfg /setactive SCHEME_CURRENT

4.2 Handling Automatic Windows Update Restarts

Windows Update can restart your host OS without warning, killing your running WSL2 containers. While Windows Home does not allow you to disable updates completely via Group Policy, you can manage restarts using the following strategies:

Strategy A: Configure Active Hours

Windows will not force a restart during your configured active hours. You can set a window of up to 18 hours daily:

Go to Settings > Windows Update > Advanced options.
Click "Active hours" and select "Manual".
Set your active window (e.g., 06:00 AM to 12:00 AM).

Strategy B: Pause Updates

If you are deploying a critical workload or testing services over a multi-week period, you can pause updates for up to 5 weeks:

Go to Settings > Windows Update.
Click the "Pause updates" dropdown and select "Pause for 5 weeks".
Remember to resume and manually apply updates during scheduled maintenance windows.

Strategy C: Disable Windows Update Service (Manual Management)

If you want to control updates manually, you can disable the update background service. Note: This stops all automated security patches. You must remember to run updates manually to keep your host secure.

Run this PowerShell command as an Administrator to stop and disable updates:

# Stop and disable Windows Update Service
Stop-Service -Name "wuauserv"
Set-Service -Name "wuauserv" -StartupType Disabled

To re-enable updates during your maintenance window:

Set-Service -Name "wuauserv" -StartupType Automatic
Start-Service -Name "wuauserv"

If your laptop restarts, Windows will sit on the lock screen, waiting for a user to log in. In this state, standard user-context background tasks and startup scripts will not run. We must configure the system to bypass the lock screen.

The safest way to do this is using Microsoft's official Autologin tool from Sysinternals.

Download Autologin from Microsoft.
Extract the ZIP file and run Autologin64.exe as an Administrator.
Input your Windows username, domain (keep default if local), and password.
Click "Enable". The tool encrypts your password and stores it securely in the registry, allowing Windows to boot directly to the desktop automatically after a restart.

5. Automating WSL2 and Docker on Boot (Headless Startup)

Because WSL2 runs inside your user session, it does not start automatically when the machine boots. It only launches when you log in and open a terminal.

To run our laptop as a headless server, we want WSL2 and our Docker containers to start automatically on system boot. We can configure this using Windows Task Scheduler.

+------------------+     Startup Trigger     +-----------------------+
|  Windows Boot    | ----------------------> | Windows Task Scheduler|
+------------------+                         +-----------------------+
                                                         |
                                                         | Launches in background
                                                         v
                                             +-----------------------+
                                             | WSL2 VM (Ubuntu)      |
                                             | - Starts systemd      |
                                             | - Starts Docker       |
                                             +-----------------------+

Step 5.1: Create the Startup Script

We will write a simple batch script that starts WSL2, launches the Docker daemon, and boots our Docker Compose stack.

Open Notepad and create a file named start-server.bat in your project folder (e.g., C:\Server\start-server.bat):

@echo off
:: Wait 10 seconds for network interfaces to stabilize
timeout /t 10 /nobreak > nul

:: Start WSL2 Ubuntu in the background
wsl.exe -d Ubuntu -u root -- systemctl start docker

:: Start your project compose stack
wsl.exe -d Ubuntu -u serveradmin -e sh -c "cd /home/serveradmin/app-stack && docker compose up -d"

echo Server started successfully.

Step 5.2: Register the Scheduled Task

We will register this script in Task Scheduler to run at startup:

Press Win + R, type taskschd.msc, and press Enter to open the Task Scheduler.
In the right actions panel, click "Create Task..." (do not select Basic Task).
General Tab:
- Name: Start WSL2 Server
- Security options: Select "Run whether user is logged on or not". This is critical: it allows the server stack to boot even if the machine restarts and sits on the lock screen.
- Check "Run with highest privileges" (required for WSL systemctl execution).
Triggers Tab:
- Click "New..."
- Begin the task: Select "At startup".
- Click "OK".
Actions Tab:
- Click "New..."
- Action: Select "Start a program".
- Program/script: Browse and select your C:\Server\start-server.bat file.
- Start in (optional): Set to C:\Server\.
- Click "OK".
Conditions Tab:
- Uncheck "Start the task only if the computer is on AC power" (this ensures the server boots even if running on battery backup during an outage).
Settings Tab:
- Uncheck "Stop the task if it runs longer than" (we want the server running indefinitely).
Click "OK". Input your Windows password to confirm the security settings.

Now, whenever your laptop boots, Task Scheduler will run the script in a hidden background session, booting WSL2 and your Docker containers automatically.

6. WSL2 Port Forwarding and Ingress Security

WSL2 runs on a virtualized internal network behind a Network Address Translation (NAT) adapter. It receives a dynamic internal IP address (e.g., 172.23.4.12) that changes every time WSL2 restarts.

This architecture introduces two challenges:

LAN Access: While you can access WSL2 services using localhost on the host laptop, other devices on your home network (LAN) cannot access the server directly.
Dynamic Routing: Because the WSL2 IP changes on restart, static port forwarding rules on Windows will break.

We must configure routing to expose our services.

Incoming Request (LAN)
        |
        v [Port 80]
+-----------------------------------------------------------+
| WINDOWS HOST (LAN IP: 192.168.1.100)                      |
|                                                           |
|  PowerShell Port Proxy Script (Detects internal WSL IP)   |
|  Redirects traffic: 192.168.1.100:80 -> 172.23.4.12:80    |
+-----------------------------------------------------------+
        |
        v [Internal Bridge]
+-----------------------------------------------------------+
| WSL2 LINUX (Internal IP: 172.23.4.12)                     |
|                                                           |
|  Docker Containers (Caddy, APIs, databases)               |
+-----------------------------------------------------------+

6.1 Bypassing the NAT: The Automated Port Forwarding Script

To make WSL2 services accessible to your local network, we will write a PowerShell script that detects the active WSL2 IP address on boot, configures the Windows network proxy, and opens the necessary firewall ports.

Create a file named wsl-port-forward.ps1 in your server directory:

# File path: C:\Server\wsl-port-forward.ps1
# Automates Windows-to-WSL2 Port Forwarding & Firewall Openings

# Define the ports you want to expose to your home network
$ports = @(80, 443, 8080, 11434)

# 1. Retrieve the current internal IP address of the WSL2 instance
$wslIp = wsl.exe -d Ubuntu -e hostname -I
$wslIp = $wslIp.Trim()

if (-not $wslIp) {
    Write-Error "Could not retrieve WSL2 IP address. Ensure WSL2 is active."
    Exit 1
}

Write-Host "Detected WSL2 Internal IP: $wslIp"

# 2. Configure the Windows network proxy to route traffic to the WSL2 IP
# Reset existing proxy configurations to avoid route conflicts
netsh interface portproxy reset

foreach ($port in $ports) {
    Write-Host "Configuring port redirection: Host Port $port -> WSL2 IP $wslIp : Port $port"
    
    # Forward port on IPv4
    netsh interface portproxy add v4tov4 listenport=$port listenaddress=0.0.0.0 connectport=$port connectaddress=$wslIp
    
    # Configure Windows Defender Firewall to allow incoming traffic on this port
    $ruleName = "Allow_WSL2_Port_$port"
    Remove-NetFirewallRule -DisplayName $ruleName -ErrorAction SilentlyContinue
    New-NetSecurityRule -DisplayName $ruleName -Direction Inbound -Action Allow -Protocol TCP -LocalPort $port
}

Write-Host "Port proxy routing configured successfully."

Run the Script Automatically on Boot

To ensure port forwarding stays active, configure the script to run on system boot:

Open Task Scheduler.
Create a new task named WSL Port Forwarding.
Set the trigger to "At startup".
Configure the task to run under the SYSTEM account (required to run netsh commands without prompting for elevation).
Set the Action to:
- Program/script: powershell.exe
- Add arguments: -ExecutionPolicy Bypass -File C:\Server\wsl-port-forward.ps1
Save the task.

6.2 Outbound-Only Public Ingress: Cloudflare Tunnels

If you want to access your Windows home server from outside your home network, port forwarding on your residential router can be risky, especially since Windows Home is more vulnerable to automated exploits.

The safest solution is to use Cloudflare Tunnels.

Cloudflare Tunnels establish an outbound-only connection from your server to Cloudflare’s edge nodes. You do not need to open any incoming ports on your router or Windows Firewall.

You can run cloudflared (the Cloudflare Tunnel daemon) directly inside Windows as a system service:

1. Download the Windows Binary

Download the Windows installer from the Cloudflare Integration Page. Save the executable to C:\Server\cloudflared.exe.

2. Authenticate the Tunnel

Open PowerShell as an Administrator and authenticate with your Cloudflare account:

C:\Server\cloudflared.exe tunnel login

This opens a browser window where you can select your domain (e.g., oriz.in).

3. Create the Tunnel

Create a new tunnel name (e.g., windows-home-server):

C:\Server\cloudflared.exe tunnel create windows-home-server

This generates a credentials JSON file in ~/.cloudflared/.

4. Configure the Routes

Create a configuration file C:\Server\config.yml:

tunnel: <TUNNEL_UUID>
credentials-file: C:\Users\<USERNAME>\.cloudflared\<TUNNEL_UUID>.json

ingress:
  - hostname: blog.oriz.in
    service: http://localhost:80
  - hostname: api.oriz.in
    service: http://localhost:8080
  - service: http_status:404

5. Install cloudflared as a Windows Service

Install the daemon as a system service so it runs automatically in the background on system boot:

C:\Server\cloudflared.exe service install C:\Server\config.yml

Start the service:

Start-Service -Name "cloudflared"

Traffic targeting your domain will now route securely through Cloudflare’s edge network and down the outbound tunnel directly to your WSL2 proxy, bypassing Windows network constraints.

7. PowerShell Hardware Health Diagnostics

Running a consumer laptop 24/7 requires monitoring system metrics to prevent hardware failure. In this section, we will write a PowerShell monitoring script that gathers CPU temperatures, measures battery degradation, checks SSD status, and sends alert webhooks.

7.1 Retrieving Hardware Metrics on Windows Home

We will query Windows management tools using the CIM (Common Information Model) cmdlet engine.

CPU Temperature:

Motherboard thermal sensors are exposed via the MSAcpi_ThermalZoneTemperature class under the root/wmi namespace.

(Get-CimInstance -Namespace root/wmi -ClassName MSAcpi_ThermalZoneTemperature).CurrentTemperature

Note: This returns the value in tenths of a Kelvin. To convert it to Celsius: (Temp / 10) - 273.15.

Battery Health:

To check if your battery is degrading (which can lead to swelling), query the design capacity against the current full charge capacity:

$battery = Get-CimInstance -ClassName Win32_Battery
$fullCharge = $battery.FullChargeCapacity
$designLimit = $battery.DesignCapacity
$wearPercent = [math]::Round((($designLimit - $fullCharge) / $designLimit) * 100, 2)

SSD Health:

We can query the physical disk status using the storage management module:

$ssd = Get-PhysicalDisk | Select-Object DeviceId, FriendlyName, OperationalStatus, HealthStatus

7.1.1 Troubleshooting Windows CIM/WMI Access

Windows management queries require administrator privileges to read hardware attributes. If you get permission denied or null values when running Get-CimInstance:

Run as Administrator: Ensure your PowerShell shell is elevated.
ACPI Drivers: If MSAcpi_ThermalZoneTemperature returns null, your motherboard's vendor ACPI driver is not exposing thermal zones to Windows. As a fallback, you can install the open-source utility Open Hardware Monitor or CoreTemp, which expose CPU temperature parameters via the root/OpenHardwareMonitor WMI namespace.
WMI Repository Corruption: If you encounter general queries freezing, rebuild the WMI repository:
```
winmgmt /salvagerepository
```

7.2 The Complete Diagnostics Script (`wsl-server-health.ps1`)

This script compiles the hardware metrics and dispatches alerts to a Discord or Telegram webhook if values breach safe thresholds.

Create the file C:\Server\wsl-server-health.ps1:

# File path: C:\Server\wsl-server-health.ps1
# Windows Home Server Diagnostics Agent

# Configurations
$discordWebhookUrl = "https://discord.com/api/webhooks/YOUR_WEBHOOK_URL" # Optional
$telegramBotToken  = "YOUR_BOT_TOKEN"                                   # Optional
$telegramChatId    = "YOUR_CHAT_ID"                                     # Optional

# Thresholds
$maxCpuTemp = 82.0       # Celsius
$minBatteryHealth = 60.0  # Alert if health capacity drops below 60%
$hostname = $env:COMPUTERNAME

# 1. Retrieve CPU Temperature
$tempRaw = Get-CimInstance -Namespace root/wmi -ClassName MSAcpi_ThermalZoneTemperature -ErrorAction SilentlyContinue
if ($tempRaw) {
    # Convert from tenths of Kelvin to Celsius
    $cpuTemp = ($tempRaw.CurrentTemperature / 10) - 273.15
} else {
    $cpuTemp = 0.0 # ACPI temperature zone may not be exposed on all motherboards
}

# 2. Retrieve Battery Status & Health
$battery = Get-CimInstance -ClassName Win32_Battery -ErrorAction SilentlyContinue
$batteryStatus = "N/A"
$batteryCapacity = 100
$batteryHealth = 100

if ($battery) {
    $batteryStatus = $battery.BatteryStatus
    $batteryCapacity = $battery.EstimatedChargeRemaining
    
    # Calculate Wear Level
    # wmic class returns charge values in mWh
    $designCap = $battery.DesignCapacity
    $fullCap = $battery.FullChargeCapacity
    if ($designCap -gt 0 -and $fullCap -gt 0) {
        $batteryHealth = [math]::Round(($fullCap / $designCap) * 100, 1)
    }
}

# 3. Retrieve Storage Disk Health
$disk = Get-PhysicalDisk | Select-Object -First 1
$diskHealth = $disk.HealthStatus
$diskStatus = $disk.OperationalStatus

# 4. Check for Alert Conditions
$alerts = @()

if ($cpuTemp -gt $maxCpuTemp) {
    $alerts += "🔥 *CPU Overheating*: $cpuTemp C (Limit: $maxCpuTemp C)"
}

if ($diskHealth -ne "Healthy") {
    $alerts += "💾 *Disk Warning*: SSD health state is $diskHealth [Status: $diskStatus]"
}

if ($batteryStatus -eq 1) { # Status 1 = Discharging (PC is running on battery power)
    $alerts += "🔌 *Power Outage*: Host laptop has lost AC power! Running on battery backup ($batteryCapacity% remaining)."
}

if ($batteryHealth -lt $minBatteryHealth) {
    $alerts += "🔋 *Battery Degraded*: Health capacity has dropped to $batteryHealth% (Wear level: $(100 - $batteryHealth)%)"
}

# Output report to console
Write-Host "Host: $hostname | Temp: $cpuTemp C | Battery Cap: $batteryCapacity% | Battery Health: $batteryHealth% | Disk: $diskHealth"

# 5. Dispatch Alert Payload if Triggered
if ($alerts.Count -gt 0) {
    $alertMessage = "🚨 **Host Alert: $hostname** 🚨`n" + ($alerts -join "`n")
    Write-Host "Alert conditions triggered: $alertMessage"
    
    # A. Send to Telegram
    if ($telegramBotToken -ne "YOUR_BOT_TOKEN" -and $telegramChatId) {
        $tgUrl = "https://api.telegram.org/bot$telegramBotToken/sendMessage"
        $tgBody = @{
            chat_id = $telegramChatId
            text = $alertMessage
            parse_mode = "Markdown"
        } | ConvertTo-Json
        
        try {
            Invoke-RestMethod -Uri $tgUrl -Method Post -Body $tgBody -ContentType "application/json" -ErrorAction Stop > $null
            Write-Host "Telegram alert dispatched."
        } catch {
            Write-Error "Failed to dispatch Telegram alert: $_"
        }
    }
    
    # B. Send to Discord
    if ($discordWebhookUrl -and -not $discordWebhookUrl.Contains("YOUR_WEBHOOK_URL")) {
        $discordBody = @{
            content = $alertMessage
        } | ConvertTo-Json -EnforceArray
        
        try {
            Invoke-RestMethod -Uri $discordWebhookUrl -Method Post -Body $discordBody -ContentType "application/json" -ErrorAction Stop > $null
            Write-Host "Discord alert dispatched."
        } catch {
            Write-Error "Failed to dispatch Discord alert: $_"
        }
    }
}

7.3 Scheduling the Diagnostics Agent

Configure the diagnostics agent to run every 10 minutes using PowerShell:

# Schedule the health script to run every 10 minutes under the SYSTEM account
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy Bypass -File C:\Server\wsl-server-health.ps1"
$trigger = New-ScheduledTaskTrigger -AtStartup
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries

# Define repetition interval (10 minutes)
$trigger.Repetition = (New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 10) -RepetitionDuration ([TimeSpan]::MaxValue))

Register-ScheduledTask -TaskName "Server_Diagnostics" -Action $action -Trigger $trigger -Settings $settings -User "SYSTEM" -Force

8. TCO & Performance Audit: Windows vs. Bare-Metal Linux

Before committing to a production deployment, it is important to evaluate the performance trade-offs of running a virtualization layer (WSL2) on top of Windows Home compared to running a bare-metal Linux installation (like Ubuntu Server).

8.1 CPU and Memory Virtualization Overhead

WSL2 is built on the Hyper-V hypervisor platform, which runs a lightweight VM containing a Microsoft-compiled Linux kernel.

CPU Performance: WSL2 CPU execution is close to bare metal. The hypervisor delegates instruction scheduling directly to the host CPU, meaning database processing and compilation tasks run at 95% to 98% of native bare-metal speeds.
Memory Overhead: Because the VM must run both the Windows host services and the Linux guest kernel, memory allocation is less efficient. Windows Home uses roughly 2.0 GB to 3.0 GB of RAM for base system processes (Desktop Window Manager, Explorer, Antivirus, Update daemons). When you allocate 10 GB of RAM to WSL2, your actual usable memory inside Linux is strictly limited to that amount. On a bare-metal Ubuntu Server installation, the OS consumes only <150 MB of RAM at idle, leaving the remaining 15.8 GB entirely available for Docker and system caching.

8.2 File I/O Performance: The Cross-OS Bottleneck

The most critical performance bottleneck in WSL2 is cross-OS file access.

Inside the Linux Virtual Disk (VHDX): If your project files, databases, and Docker volumes are stored inside the internal WSL2 Linux filesystem (e.g., /home/serveradmin/project), I/O performance is extremely fast, matching native NVMe SSD read/write speeds.
Accessing Windows Drives (/mnt/c/): If your containers query files stored on the host Windows filesystem (e.g., mounting a volume to /mnt/c/Server/data), traffic must pass through the 9P protocol translation layer. This translation layer introduces significant latency, dropping I/O throughput to 10% to 30% of native speeds and causing high CPU usage.
The Core Rule: Never mount Docker volumes or run database files from /mnt/c/. Always store active project files and database volumes directly inside the internal WSL2 root filesystem.

8.3 Feature Matrix: Windows Home + WSL2 vs. Bare-Metal Ubuntu

Performance Dimension	Windows Home + WSL2 Server	Bare-Metal Ubuntu Server
Idle Host Memory Cost	High (2.0 GB – 3.0 GB RAM consumed by Windows).	Extremely Low (<150 MB RAM at idle).
Active Memory Overhead	Virtualized memory mapping adds minor lookup latencies.	Zero overhead. All RAM is mapped directly.
Disk I/O Performance	Fast within ext4 VHDX. Slow when mounting host files.	Extremely Fast across all partitions.
Host System Recovery	Simple. Windows includes built-in recovery partitions.	Requires live USB boot tools for manual restoration.
Hardware Diagnostics	Native Windows APIs (CIM/WMI) are easy to query.	Requires Linux CLI tools (`lm-sensors`, `smartctl`).
Sleep Management	Requires manual override of lid-close actions.	Native server OS ignores sleep states by default.
Update Reboots	Requires configuring Active Hours or disabling services.	Managed via simple APT cron configurations.
Dual-Use Support	High: Laptop remains a functional Windows machine.	None: Machine functions strictly as a server.

8.4 Troubleshooting Common WSL2 Server Issues

Operating a server inside a virtualized WSL2 layer on Windows can introduce unexpected networking and timing anomalies:

1. WSL2 Clock Drift (Time Sync Failure)

When the Windows host laptop enters sleep mode (or when it undergoes a standby cycle), the WSL2 guest utility VM halts its execution. Upon waking, the guest system clock does not automatically resynchronize with the host clock, leading to clock drift (where the time inside WSL2 lags behind real time).

The Impact: Clock drift breaks HTTPS API requests, OAuth checks, and security handshakes, resulting in "Certificate expired" or "Invalid signature" errors.
The Fix: Set up a scheduled task in Windows Task Scheduler that triggers on system wake to sync the hardware clock:
```
# Sync Linux clock to Windows Host time
wsl.exe -d Ubuntu -u root -e hwclock -s
```

2. DNS Resolution Loss inside WSL2

If your home router changes its gateway IP or if you connect to a VPN on the Windows host, WSL2 can lose internet access because its auto-generated /etc/resolv.conf file points to a stale gateway proxy.

The Fix: Disable DNS auto-generation in WSL. Create the file /etc/wsl.conf inside Ubuntu and add:
```
[network]
generateResolvConf = false
```
Then, delete the symlink /etc/resolv.conf and create a static file:
```
sudo rm /etc/resolv.conf
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf
```
This locks your WSL2 DNS resolver to Cloudflare’s DNS server, bypassing local network routing changes.

9. Conclusion

Turning an old Windows laptop into a home server using WSL2 and Docker is an excellent way to reuse retired hardware without losing the benefits of your pre-installed Windows license.

By bypassing the resource-heavy Docker Desktop client, configuring .wslconfig resource caps, setting up port forwarding proxy scripts, and using Task Scheduler to automate background startups, you can achieve a stable, low-overhead hosting platform.

Your server runs headlessly in the background, secured by Cloudflare Tunnels, while your hardware health is monitored automatically by PowerShell scripts. You retain access to your Windows system while gaining a near-native Linux server playground.

Your laptop is now a dual-purpose, power-efficient local cloud node. Let it run.