We innovated sconfig, and it is true that it now has dependencies on PowerShell. The new sconfig is in AzS HCI, Windows Server 2022 core, and if we had shipped a Hyper-V Server 2022 it would have been in there as well. So it wouldn't have been a differentiator per se.
Yeah, I understand that. The new sconfig certainly is better than the 2016 one. Even though I'd prefer it clickable (and winlogon too) since user32 is still present, even on the most stripped down installation. But I guess you don't want to close the door to bringing back something like Nano Server on bare metal ...which would be awesome IMHO.
I'm curious why you want to remove PowerShell, as that obviously has some major management trade-off's?? I'm assuming your goal is more about .NET'less? Would love to better understand the scenario / goals. Are your feelings different about .NET Core with PowerShell7?
Can you elaborate on your footprint feedback? Disk drives for the boot device are plenty big these days... which value is important to you? We have lots of room to further optimize the composition of AzS HCI... but I want to understand what's most important to you.
This is actually somewhat tangential to Hyper-V Server, but: A significant portion of our (as a company) projects are in telco domain. One of our largest partnership involved mixed proprietary communications routed and processed on a proprietary hardware. The specs of the hardware were well under the officially supported Windows Server minimum, e.g. 4 GB of disk space, so we properly stripped down the OS.
Something like Intel's DE3815TYKHE.
The small on-board storage allows one to deploy Hyper-V Server onto it, but freely swap the SATA disk with VMs to run. Not the actual scenario in this story though.
If you are asking why Server SKU and not IoT Enterprise LTSC, then basically the latter wouldn't fit, and the partner had procured Telco SKU licenses. We've even deployed some as the aforementioned Nano Server 2016, but that wasn't usually possible due to various driver incompatibilities, and even then we reverted most due to partner being uncertain if the licensing applied properly.
On several of the larger devices, used in backbone, we needed to isolate a problematic legacy voice software from our services, and for several reasons, we deployed them into different VMs, with Hyper-V Server 2016 as host. Now, yes, the licensing would allow us to use the 3rd instance to manage the VMs, but using stripped-down Hyper-V Server, we saved about 0.5 GBs of disk space. Insignificant amount in many scenarios, but this time it helped a lot.
Side note: Uninstalling WoW64 leaves behind about 300 MB of unused DLLs in SysWow64. I've reported it both here and on FeedbackHub, but probably it's not a priority. Just FYI.
I would not normally remove PowerShell nor .NET, if the space constrains allowed, because doing so often breaks Windows Update, but luckily these installations weren't updated (on isolated network), classic tools were enough to manage what I needed to, and the partner's administrators had their own ways.
And yes, PowerShell7 is great, especially since it's self-contaned. I can bring it on a flash drive, plug it onto any stripped down installations of mine, and it works. It even runs on the Nano Server (although I've so far tested it only in container, not in 2016 VM or bare-metal installation).
The last part of my footprint concerns is lab testing. When simulating higher amount of nodes, through swarm of local VMs, the used disk space quickly adds up. It's good being able to remove everything not needed and minimize the images. And this applies to Hyper-V Server too, since I've discovered the support for nested virtualization. I am using that SKU for some middle layer VMs. Now with AMD-V support I might be using it even more ...well in Server SKU if Hyper-V Server 2022 is not coming.
That's why it uses the same tools and management experience... such as PowerShell, Windows Admin Center, and all the existing MMC tools work as well (Failover Cluster Manager, Hyper-V Manager, etc...).
If some of the basic MMC tools, the GUI part, were available locally, I wouldn't be even mad. Not all things from ServerCoreAppCompatibility packs, just a couple of locally useful tools, e.g. diskmgmt.msc.
The 60-day free trail with AzS HCI is a little different than an Evaluation with a perpetual license. Eval is a special product that is time-bombed and can only be used for a period of time before you must move to a licensed product. The free trial gives the first 60-days as free for all subscriptions, so that's a value you can take advantage of for production deployments as well. So some trade-off's. AzS HCI also charges based on core usage to scale down for SMB customers.
So, do I read it right that we CAN continue to use Azure Stack HCI, after the 60-day free trial, the way we use Hyper-V Server now? Given we don't connect any Azure subscription and the guests are properly licensed?
