Windows – Made For Cloud

N-4 support for Windows Server Upgrades – Wow?

gocallag — Fri, 05 Jun 2026 07:08:00 +0000

Windows Server 2025 is well and truly here, and Microsoft is pushing hard to convince you that this is the smoothest upgrade cycle in years. They’re not wrong but is it the whole story. If you’re running 2012 R2, 2016, 2019, or 2022, the new N‑4 in‑place upgrade support means you can jump straight to 2025 in one hop. That’s a big deal. But whether you really can do this is a different question.

If you’re still on 2012 R2, this is your last lifeline.

Media‑Based Upgrade: The Official Story vs Reality

Microsoft claims the ISO‑based upgrade takes “under an hour per server.” Sure, in a lab. With clean images. And no vendor agents. And no ancient NIC drivers. And no weird backup software from 2014. I was able to easily do it under these ideal conditions.

In the real world, which is often quite messy (today’s understatement), expect:

Several hours for typical servers – some of these old physical servers take 15 minutes to boot.
Longer for anything with third‑party agents, monitoring hooks, or legacy storage drivers
Rollback time if something breaks (and something always breaks). Do you have a rollback plan for your in-place upgrade? Does your backup actually work?

Still, the process is quite straightforward: mount ISO —> run setup —> choose “Keep files, settings, and apps” —> Ok, some form of conversation with a deity may help here.

Virtual Machines: The Easy Path (Mostly)

If you’re on Hyper‑V, Microsoft is right: upgrades are usually painless. Hyper‑V integration components update automatically during setup.

If you’re on VMware, Nutanix, Proxmox, or anything else, Microsoft’s advice is blunt but correct:

Update your guest drivers first. Outdated virtualization drivers are the #1 cause of upgrade failures.

Ignore this and you’ll be staring at a recovery console and re-considering your life choices.

Physical Servers: Where Things Get Messy

Microsoft politely hints that your 2012 R2 hardware is “about 15 years old.” Translation: Your server is a fossil. Don’t expect miracles.

You must validate:

NIC drivers
HBAs
RAID/storage controllers
PCIe cards
Out‑of‑band management firmware

If any of these lack 2025‑compatible drivers, you’re choosing between:

Buying new hardware
Virtualizing the workload
Moving it to the cloud
Or hoping

Planning: The Part Everyone Skips Until It’s Too Late

Microsoft’s checklist is great, but incomplete. But really put some thought into these as well …

Uninstall old antivirus/EDR agents as they break upgrades constantly
Disable third‑party disk encryption
Remove legacy monitoring agents (SolarWinds, SCOM, etc.)
Disconnect from SANs you don’t need during upgrade
Expect to reboot multiple times even after the upgrade completes

The main missing step: Fix whatever broke. Something always breaks.

You cannot in‑place upgrade domain controllers. Don’t even bother trying, let me help you here – no, stop, don’t, you can thank me later

The process for Active Directory upgrades remains the same as it has been for 20 years: Deploy new DC, Replicate, Demote / Promote, Raise Functional Levels.

Licensing: The Part Everyone Forgets – I say everyone, but it was me – I forgot.

If you have Software Assurance, you’re fine. If you rely on KMS, make sure it’s updated — 2025 requires new keys.

If the Upgrade Fails

Microsoft recommends:

Checking logs in C:\Windows\Panther
Running SetupDiag
Restoring from backup

Final Thoughts

If you didn’t test the upgrade on a clone first, you’re already headed for disaster – think of your future self.

You can find more details at Upgrading to Windows Server 2025 from Windows Server 2012 R2, 2016, 2019, or 2022 using Media (ISO) | Microsoft Community Hub

Compacting WSL hard disk

gocallag — Tue, 24 Dec 2024 06:03:54 +0000

Like many people I am an extensive user of WSL and Linux under Windows in general. It’s the only real option I have at work and it’s quite a reasonable proposition.

That being said though, the WSL vhdx files can grow as you’re doing Linux work and while you can (and should) clean up side the Linux environment it’s not reflected back to windows as free space.

So how do you compact your WSL file?

Shutdown your WSL system.

wsl.exe --list --verbose # note the verbose is required to get the state

wsl.exe --terminate Ubuntu-24.04
Shrink the disk using diskpart

diskpart

You need to select the vhdx file for your WSL instance. The VHDX file is typically found in your AppData folder. In my case it was this.

I copy the VHDX file location as a path.

DISKPART> select vdisk file="C:\Users\geoff\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_79rhkp1fndgsc\LocalState\ext4.vhdx"
Compact the vdisk

DISKPART> compact vdisk
The results.

BEFORE

AFTER

As you can see, i’ve freed up nearly 6Gb.

Getting WSL2 just right

gocallag — Sun, 30 Jun 2024 04:03:35 +0000

Recent changes to WSL2 by Microsoft have made using Linux on Windows even more comfortable. I’ll describe some of the options and their use below.

Firstly, do you have WSL2 installed? If not, then this will help https://learn.microsoft.com/en-us/windows/wsl/install-manual#step-1—enable-the-windows-subsystem-for-linux

In order to best use WSL, you of course need to have a distribution installed. Ubuntu is one of the easiest and most common to install.

wsl --list --online           #check what distros are available
wsl --install -d Ubuntu-24.04 #latest at the time of writing

Now that you have a distro installed, we have something to configure. There are 2 configuration files that customise the distribution experience under WSL2. wsl.conf and .wslconfig

wsl.conf contains per-distribution settings, whereas .wslconfig configures global settings for the WSL2 environment.

wsl.conf is stored in the /etc directory within the distribution.

.wslconfig is stored in your %UserProfile% folder.

.wslconfig

The .wslconfig file is in .ini format with the GA features found under section [wsl2]. There is also an [experimental] section for unreleased options.

Note: All options may not be available to you as they are Windows OS and WSL version dependent. You can reasonably assume if you are running Windows 11, 22H2 or higher that most of the options described below are available to you. This is not the complete list, just the one’s I have found to be quite useful

GA features that I find useful

Accessible via the [wsl2] section of the .wslconfig file

Key	Value	Notes
memory	memory size (Mb, Gb)	Default is 50% of the windows memory. I find it useful to constrain the memory (in conjunction with the experimental memory release features below)
processors	number	Default is the same as present in windows
localhostForwarding	true/false	Default is true, this allows your WSL2 application to be accessible via localhost:port
nestedVirtualization	true/false	Allow nesting inside WSL2, Windows 11+
networkingMode	string, NAT, mirrored	The default is NAT, mirrored turns on mirrored networking mode. Mirrored mode is a great addition for many of my use cases.
firewall	true / false	Hyper-V firewall can filter WSL network traffic
dnsTunneling	false	see the experimental section

Some of the GA features

Experimental (though very useful) features

Accessible via [experimental] section of the .wslconfig file.

Key	Value	Notes
autoMemoryReclaim	disabled	Default is disabled, but options list gradual and dropcache can dramatically return memory outside wsl2. I default to gradual.
sparseVHD	false	When set to true new VHD’s are created as sparse saving considerable disk with all the overprovisioning issues. By default, i’m using sparse, but then again i’ve been using sparse filesystems for many years
useWindowsDnsCache	false	If you have dnsTunneling turned on then this option allows you to use or ignore what windows dns may’ve cached
hostAddressLoopback	false	if networkingMode is set to mirrored then the loopback 127.0.0.1 address can be used to access the host and the container depending on where the listening resource may be running – windows or wsl2. This is a great option if you want better sharing between windows and wsl2 distro. For example, i’ve had a mongo client on windows and mongo in wsl2 ubuntu.

Some of the Experimental features

wsl.conf

As I mentioned above the /etc/wsl.conf within the distribution controls some interesting behaviours, especially on distro launch.

[boot]

systemd=true

Solves the problem where you’re reliant on systemd resources within your WSL2 distro. I normally have it turned on.

[automount]

Key	Value	Notes
enabled	true / false	Allows windows fixed drives to be automatically mounted under /mnt (or where the root key points). I have this enabled by default
root	/mnt	Where the mounts occur for auto mounted systems
mountFsTab	true/false	Allow the /etc/fstab to be processed at WSL distro boot time. Great to get those SMB/NFS mounts going. I have this set to true as I use a lot of NFS in my test environment.

Some things to note.

Windows disks are mounted using Drvfs and are by default case sensitive. You can override this behaviour for all or single drives. More information is available at Per-directory case sensitivity and WSL – Windows Command Line (microsoft.com)

[network]

Key	Value	Notes
generateHosts	true/false	wsl will generate an appropriate /etc/hosts file based on the windows environment. I generally set this to true (the default).
generateResolvConf	true/false	wsl will generate an appropriate list of dns resolvers. I generally set this to true (the default).
hostname	string	This sets the hostname to be used within the distro. The default is the windows hostname, but this is useful if you run multiple WSL instances.