Add a NoDCHydrate feature to defer DC creation to step 3

[michbern-ms]

This change creates a NoDCHydrate feature to defer DC creation to step 3.

• Refactor the code to hydrate the DC into its own function, Hydrate-DC
• Call the function as usual in step 2 to maintain current functionality
• Add a NoDCHydrate switch in LabConfig to enable the DC to be hydrated during Deploy instead of CreateParentDisks

This works around an issue where the Server 2025 Domain Controller does not respond well to being dehydrated and rehydrated.

The change also adds named-VHD support for WS2025.

[Karl-WE]

@machv @jaromirk do you intent to merge this. Checking the latest release I was not sure if it is included.

[machv]

@Karl-WE i will look on this over the weekend, I want to test this scenario also with older versions of win server before merging.

[Karl-WE]

Thank you for going the extra mile @machv

[michbern-ms]

Thank you, @machv . I did test with Server 2022, but it would be great to get independent confirmation. I'm happy to fix anything you find. I got into this just to fix the issue for Karl but I'm growing rather fond of these scripts.

[jaromirk]

Folks, I added some more stuff into DC hydration as I found breaking bug in networking stack. So now it also installs Hyper-V in DC and adds vswitch. It simplifies a bit this scenario https://github.com/DellGEOS/AzureStackHOLs/tree/main/lab-guides/04-TestingLogicalNetworks. Unfortunately it will also break this PR. I also added Ws2025 version into parent disks creation, so it will no longer be created as insider preview vhd.

[michbern-ms]

Thanks, @jaromirk -- I merged your changes and re-pushed. I re-tested Server 2025 (with NoDehydrateDC=$true) and Server 2022 (with NoDehydrateDC=$false).

[Karl-WE]

Tested with

• mslab dev including this fix but without the nohydrate flag since it should be no longer required since b26296.
• Host OS b26311
• DC with b26311 ISO

The original issue in #589 is solved.

@michbern-ms @jaromirk please decide if this code change is still helpful, just in case we see a reprise of the issue of importing hydrated VMs with later Windows Server versions