Add options to deployed VMs

cloudmadlab commented 2 years ago

Please consider the following user story for automation:

I know that most, if not all, labs include a dual-homed VM to run the Scenario.ps1 commands from - whether the DC, Windows 10, or other. On this dual-homed VM, I want to configure a static MAC address on the vNIC connected to the external vSwitch. This would allow me to create a DHCP reservation outside of the MSLabs environment that will ensure that the external interface always gets the same IP. This will allow me to RDP directly to the dual-homed VM from my lab's launch pad rather than jumping to the Hyper-V host and connecting to the VM.

This story also requires that RDP and ICMPv4 requests are enabled on the dual-homed VM. I am accomplishing this on the cluster nodes using the CustomPowerShellCommands option:

1..4 | ForEach-Object { $LABConfig.VMs += @{ VMName = "AzSHCI$_" ; Configuration = 'S2D' ; ParentVHD = 'AzSHCI20H2_G2.vhdx' ; HDDNumber = 10 ; HDDSize = 10TB ; MemoryStartupBytes = 1GB; VMProcessorCount = "Max" ; CustomPowerShellCommands = "Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name 'fDenyTSConnections' -value 0","Enable-NetFirewallRule -DisplayGroup 'Remote Desktop'","New-NetFirewallRule -DisplayName 'Allow inbound ICMPv4' -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -Action Allow" } }

jaromirk commented 2 years ago

@machv we should have some conversation on this. bwt. it would make sense to do it only for management machine. You dont want to rdp into azshci hosts, or do you? I could imagine parameter DualHome=$True; DualHomeCustomMacAddress=xxxxxxxxxx; ... Ideas? For RDP I think we can add it the same way we do winrm=$true... so EnableRDP=$True ?)

cloudmadlab commented 2 years ago

@jaromirk - I'd be looking at RDP and ICMP response on the management VM only. I can always add anything I want to the azshci hosts via your CustomPowerShellOptions option.

Where would these parameters be placed since the DC creation is not part of LabDeploy.ps1? I would suggest that the DC never be the management VM. The management VM would always be created for all labs via LabDeploy.ps1 and would be Windows 10/11.

Those parameters sound reasonable. Some other ideas:

MgmtVmDualHome = $True MgmtVmExternalVnicStaticMACAddress = xxxxxxxxxx MgmtVmEnableRDP = $True MgmtVmEnableIcmpResponse = $True

Thoughts?

jaromirk commented 2 years ago

I can create a hash table for management settings. If there will not be any machine specified as management, all these settings can be configured using powershell direct against DC. if machine is specified, only that one will get settings. If multiple machines specified, it will configure only first one (to prevent duplicite mac). Makes sense?

jaromirk commented 2 years ago

how about this?

$LabConfig=@{ DomainAdminName='LabAdmin'; AdminPassword='LS1setup!'; Prefix = 'MSLab-' ; DCEdition='4'; Internet=$true ; AdditionalNetworksConfig=@(); VMs=@();mgmtVMs@()}

$LabConfig.mgmtVMs+={VMName=DC;ExternalVnicStaticMACAddress=00000000;EnableRDP=$True;EnableIcmpResponse=$true}
$LabConfig.mgmtVMs+={VMName=Management;ExternalVnicStaticMACAddress=00000001;EnableRDP=$True;EnableIcmpResponse=$true}

jaromirk commented 2 years ago

or since it's just one VM, we could enable all things like RDP and ping automagically (as I would guess you want to have both enabled) and just say in labconfig following:

$LabConfig=@{ DomainAdminName='LabAdmin'; AdminPassword='LS1setup!'; Prefix = 'MSLab-' ; DCEdition='4'; Internet=$true ;  AdditionalNetworksConfig=@(); VMs=@(); MgmtVm=DC; MgmtVmMAC=00000000 }

and if MgmtVM is specified, we would configure RDP and ping. If also StaticMac is specified, we would configure that one too.. If it is other VM than DC, we would configure DualHome. Makes sense?

cloudmadlab commented 2 years ago

I've only been through a few of the labs so far. Could you please confirm the following:

Every lab has DC running.
DC is always dual-homed and has NAT running for the outbound Internet access for the lab VMs.

If this is the case, we only need an option to enable RDP/ICMP on the DC (or just add by default). I would only want this just in case I would need to RDP from my management VM to the DC. There would be no option to set a static MAC address on the DC. Only if someone elects to deploy a management VM (Win 10/11) would they have the option to dual-home and set a static MAC address on the external interface of that management VM. As you said, RDP/ICMP would be enabled on the management VM by default.

How about:

$LabConfig=@{ DomainAdminName='LabAdmin'; AdminPassword='LS1setup!'; Prefix = 'MSLab-' ; DCEdition='4'; Internet=$true ; AdditionalNetworksConfig=@(); VMs=@(); DcRdpIcmp=$True; MgmtVm=$True; MgmtVmDualHomed=$True; MgmtVmStaticMAC=00000000 }

jaromirk commented 2 years ago

1) Yes, DC is always there 2) Only if internet=$true

I would configure MgmtVm=DC; MgmtVmMAC=00000000 ... in case you want DC with custom MAC (and it can be configured - why not)... and if you would like to configure any other VM, then you would configure MgmtVm=Management; MgmtVmMAC=00000000 and it would add additional NIC to VM Management, configure fw rules, and configure MAC (if Mac was specified). Assuming you dont need to have multiple "Management" VMs...

cloudmadlab commented 2 years ago

This makes sense to me. So I'm clear:

RDP/ICMP and dual-homing would be enabled automagically on management VM - DC or other Win 10/11. There wouldn't be a parameter for these.
Paramters would exist for choosing the management VM - DC or other Win 10/11 - and setting the static MAC address. And this static MAC address would only be for the new external interface being created.
In the case that someone elects the management VM, they would have a DC, as well. In this case, both the DC and management VM would have RDP/ICMP allowed and be dual-homed. The only additional parameter at that point would be to set the static MAC address on the management VM's external vNIC to static.

machv commented 2 years ago

@jaromirk In the scenario where DC would be the management machine, wouldn't be then the effect of both Internet and MgmtVm parameters the same?

Another option would be to allow this on per VM basis (but it would not allow to use DC for that as DC is handled as a special VM).

$LABConfig.VMs += @{ 
  VMName = 'Management' ;
  ParentVHD = 'Win10_G2.vhdx'
  AdditionalNetworkAdapters = @{ # New config option to allow mgmt access
     VirtualSwitchName = 'MyCorporateNetwork' # mandatory 
     Mac = 'E3-D8-F2-CA-11-06' # Optional parameter
     VlanId = 15 # Optional parameter if VLANs are used in the environment
     IpConfiguration = @ { # DHCP or specific IP set with Set-VMNetworkConfiguration function
       IpAddress = '172.17.1.15'
       Subnet = '255.255.255.0'
     }
  }
}

This might be another way for non DC machines.

Remaining stuff (RDP/Ping remains the same, and might still be solved by custom code in CustomPowerShellCommands as mentioned in the first post.

Which way would you prefer more?

jaromirk commented 2 years ago

@machv well, it sounds better to separate net adapters config. It's true we have now too much happening - VLAN, static IP, vswitchname... You are right! As always :). Nice discussion btw. The only thing we need to add is AllowICMP and AllowRDP - probably separate. Btw. we should also step back and start thinking about LabConfig in general :).

machv commented 2 years ago

Let's see how it would look like in action :) I will prepare a draft for this and push it to my GitHub fork for testing.

cloudmadlab commented 2 years ago

Thanks for the prompt attention! I'm ready to help test if needed.

machv commented 2 years ago

OK, in pull request #468 is proposal for this feature, as of now only for network adapters itself, we will need to handle ICMP/RDP if needed.

jaromirk commented 2 years ago

Can you also add optional Name? It's more or less cosmetic change. I never used it in real world... but it would help us identify network adapter from inside of the host in case we would need it later https://github.com/microsoft/MSLab/blob/master/Scripts/3_Deploy.ps1#L1170

jaromirk commented 2 years ago

@machv @cloudmadlab folks, how's the status? 🙂. Is PR from Vladimír OK?

cloudmadlab commented 2 years ago

@machv @jaromirk - Please accept my apologies for the long delay in confirming the new functionality in the PR. I validated a few different scenarios, and I think we're good to go. Thanks so much and excellent work!

I guess the only other item is to enable RDP and ICMPv4 automatically during the deployment of the management VM. I am fine with this being the default behavior or if you guys prefer to make it a parameter.

I also liked @jaromirk's idea about being able to name the virtual adapter, so they are easily identifiable in the OS. In fact, if the same name could be applied to the adapter name at both the virtual hardware and OS layers, that would be ideal. (e.g. Management1, Internet, etc.).

machv commented 2 years ago

Great, thank you for the info. I will add the option to specify the adapter name as optional parameter.

cloudmadlab commented 2 years ago

And the RDP/ICMP? Or will you enable on the management VM by default?

Karl-WE commented 2 years ago

Hi this is an interesting PR. Thank you.

As the title say add options to deployed VMs I could imagine some more ideas in addition to the RDP / WinRM / IPv4 / IPv6 ICMP in.

Question: Is it okay to add / discuss them here or one PR per VM option that come into my mind ?

"The management VM would always be created" I like the idea to (optionally) create a management VM during the LabCreation.

from a licensing standpoint I would not create W10/W11 for management but Windows Server 2022 LTSC (or Azure Edition). Why?

If the VM is Win10/Win11 you may not access it without VDA licensing except you have M365 or Wxx licensing plans via CSP or sorts.
Windows Server VM is always licensed through the Datacenter of Azure Stack HCI nodes.
Windows Server VM does inherit the activation via Hyper-V from the Azure Stack HCI nodes (since 21H2).
Why Windows Server VM, except from licensing: The GUI tools (RSAT) are no longer under development so there is no potential gap between W11 or WS 2022 or later anymore.

Idea: The Management VM should include (all can be scripted)

all RSAT Tools, Server Manager, esp. Bitlocker Management for DSAC integration
Windows Admin Center in the latest version
winget (not yet officially supported but is possible)
PowerShell 7.x release

To manage Azure Stack HCI + VMs + Clustering etc. This is how I would do this in production.

jaromirk commented 2 years ago

Hey @Karl-WE, what you can do is to use DSC! It's by default installed on DC and here is an example of labconfig. In zip file you will find example dsc configuration that is then applied to VMs when it boots... https://github.com/microsoft/MSLab/tree/master/Scenarios/LAPS%20on%20Nano

Karl-WE commented 2 years ago

Hi @jaromirk Jaromir I have browsed your repo and seen it. It is so helpful. What do you think about my question on VM options also the Management VM? Saw that some of the scenarios already include WAC.

jaromirk commented 2 years ago

I think we can add RDP and Ping options (the same way we do WinRM=$True). I would not add much thought, because idea of this project was to rapidly provide vanilla environment to be able to demonstrate all steps that needs to be performed to make something running. If you need production-like looking environment, there are another excellent projects like AutomatedLab

microsoft / MSLab

Add options to deployed VMs #466