JFC it's been a LONG time. I haven't been here since 911CD and Bootland. The only familiar names showing up are toolkit authors in the Downloads page. If you guys are still around, it's great to be back. I've been getting by over the years with very little frustration thanks to the memories and struggles we all carried with deep interest in WinPE from the crude nu2 era. Last week I was looking up tools from some familiar names (TheTruth, Paraglider, Misty) to update some libraries and was pleasantly surprised to find some sites still up but realized that it's probably not enough. I may once again need help figuring out a new project and remembered this place exists. While I'm proud of you all and Reboot.Pro is a godsend for those of us that actually make any attempts to understand WTF is going on, I'm fairly certain none of us are ready for this headache, namely because I'm not even sure if it's appropriate to my goals and I appear to be the only one talking about it in any friend group.
The tiny pink elephant in the room is Windows Nano Server.
For context, I've done very few hardware changes over the years but my server situations have remained relatively the same with lots of unusual scaling and more competent hardware with apps that eat several GB of memory instead of MB. One of the biggest things that made me stop and reevaluate full WS installations was discovering the serious driver and memory overhead involved in some apps on newer systems. I can get rid of these or try to do better. The discrepancies range from mild to wild depending on the core flavor, priority channel and install type of the OS. For the past 3 years I've switched all production over to Windows Server 2012 R2 for myself and recommended it to all my clients. I'm at a point where it's probably time to move on from this but WS2012R2 is the most efficient and compatible balance that I've discovered shy of making the system completely headless. Nano Server looks ideal for what I want but this is where things get really stupid:
Microsoft made two primary builds of Windows Server 2016 since a few Tech Preview builds. My R1 candidate included a build path for Nano Server as a very self-involved option for situations where both the full desktop experience and server core deployments are too much overhead. So this purely headless option was made and later prioritized to handle Hyper-V and Docker/Containers, which I personally avoid. The above article does a great job outlining how and why that doesn't work out of the box. At this point the 2016 distribution has been memory holed by Windows Server 2019 and this new VM+container direction. While I personally enjoy the extensive driver compatibility and application support in WS2019, there are too many bugs and app issues that make it less than ideal for prime time, let alone for building something like Nano Server. It's fun to play with but a nightmare when you need to get any real actual work done, so I'm probably about to start looking for my first consumer level OS in 15 years. There appears to be a NanoServer distribution for WS2019 but it's not included in the install media or the evaluation image. Instead, you pull it through Powershell and Docker then mount it to Hyper-V. You don't "apply" it to a physical partition like the 2016 model. The 2019 model is only available for use inside a VM, which I've learned doesn't play well with VMWare. Since my test tools only ever involved Qemu and VMware, I resort to grabbing a 64-bit copy of WinImage that allows for VHD/VHDX conversion and convert the file to VMDK before loading it into VMware.
Whether you use the Windows ADK for Windows 10 and Nano Server Image Builder to build a Nano Server VHD/VHDX or build everything through a few minimalist Powershell scripts, you essentially end up with the same product by taking the WIM image file, adding packages and converting it to VHD/VHDX for deployment. All the network and related drivers need to be added during compilation so if you don't have all the necessary 64-bit drivers it can be a hassle to get this working right on the first few tries. I would recommend testing in a VM as the WinPE script for deploying Nano Server is extremely destructive to any physical system. I would prefer to detach any physical disk from the system before deployment and possibly installing it directly to a DOM if possible, allowing for simple tests.
Both the factory WIM and deployment-ready converted images appear to have the same post-processing abilities as any other WinPE so I'm really curious if Nano Server can be prepared and deployed similar to the ways we use WinBuilder or PEBakery. Seeing how we're all on 64-bit systems and Nano Server has most SysWOW64 libraries stripped out, it would be interesting to bring some relatively minimal 32-bit support and setup some custom background services to run a truly headless server. Without any sort of local logon or GUI, this will force me to think of my own server situations and deployments in significantly better ways. In the 4 years that Nano Server has been around, it hasn't had any real traction. Nobody is talking about it and it's probably time for another look. I've physically installed this to an older system twice and that was as soon as WS2016 went retail. It has a bit of a learning curve when all the management is remote Powershell/WinRM but I think it would be better practice for me to be using this on my minimalist .NET+SQLEspress web+NAS+video stream/ingestion system than giving it a full Windows UI. I recognize NIC teaming is going to be a challenge to do what I want but if I have to login via remote desktop to run huge network, power management and studio apps that should be background services with a web UI, or a management panel on another computer, I would prefer to be on those instead of resorting to remote desktop, especially now that most management situations are mobile and allow for quick maintenance. Would you guys consider this to be a reasonable situation or is the concept of a headless Windows Server just that? I personally think it's really close and just needs a little bit of work. Thanks.