Multiple Eval instances in the same Tenant/Sub

[Phydeauxman]

What files/parameters need to be modified so that my team can deploy multiple instances of an Eval HCI cluster in a single tenant/sub? My team has a need to have an HCI instance for each dev to work independently. Since each HCI instance will create app registrations, when using the guided eval to create the instance it does not have the flexibility to change the name of the cluster and therefor the app registrations.

Is there a way for us to edit scripts that get run to provide the uniqueness?

[ercohen19]

Hello. Have you tried creating each cluster in a different resource group? Otherwise, all of the scripts used in the ARM template can be found under the deployment folder.

[Phydeauxman]

Even if we use different resource groups, the App Registrations in AAD will be named the same. Will look at the deployment scripts

[mattmcspirit]

Hey Byron - are you referring to when you get to the registration phase of the cluster, and because all clusters by default should be called AZSHCICLUS, that's causing the challenge, or is it related to the Windows Admin Center registration?

If it's the AZSHCICLUS naming that's causing the issue, you could choose a different name, you may just need to pre-create the AD objects to streamline things. The automation does take care of that, however there's a script here that would help you do that after the fact: https://github.com/Azure/AzureStackHCI-EvalGuide/blob/main/deployment/helpers/Update-AD.ps1 - just choose whatever cluster name you like in that script, run it on the AzSHCIHost001 and then you should be good to create your AzSHCI cluster, with whatever name you specified in that script, and register accordingly.

Does that help?

In future, I could possibly edit the ARM template to allow you to specify a cluster name, and that would pass through to the DSC and onto the Update-AD script, but that would take me a bit of time to test and validate - hopefully the workaround above is OK for now.

Thanks!
Matt

[Phydeauxman]

Hey Byron - are you referring to when you get to the registration phase of the cluster, and because all clusters by default should be called AZSHCICLUS, that's causing the challenge, or is it related to the Windows Admin Center registration?

If it's the AZSHCICLUS naming that's causing the issue, you could choose a different name, you may just need to pre-create the AD objects to streamline things. The automation does take care of that, however there's a script here that would help you do that after the fact: https://github.com/Azure/AzureStackHCI-EvalGuide/blob/main/deployment/helpers/Update-AD.ps1 - just choose whatever cluster name you like in that script, run it on the AzSHCIHost001 and then you should be good to create your AzSHCI cluster, with whatever name you specified in that script, and register accordingly.

Does that help?

In future, I could possibly edit the ARM template to allow you to specify a cluster name, and that would pass through to the DSC and onto the Update-AD script, but that would take me a bit of time to test and validate - hopefully the workaround above is OK for now.

Thanks! Matt

Thanks for the reply Matt...I will see if I can follow the steps you outlined.

[Phydeauxman]

@mattmcspirit I was able to deploy a new cluster by making edits to the script you mentioned and the Register-AzSHCI script.

[Phydeauxman]

Hey Byron - are you referring to when you get to the registration phase of the cluster, and because all clusters by default should be called AZSHCICLUS, that's causing the challenge, or is it related to the Windows Admin Center registration?

If it's the AZSHCICLUS naming that's causing the issue, you could choose a different name, you may just need to pre-create the AD objects to streamline things. The automation does take care of that, however there's a script here that would help you do that after the fact: https://github.com/Azure/AzureStackHCI-EvalGuide/blob/main/deployment/helpers/Update-AD.ps1 - just choose whatever cluster name you like in that script, run it on the AzSHCIHost001 and then you should be good to create your AzSHCI cluster, with whatever name you specified in that script, and register accordingly.

Does that help?

In future, I could possibly edit the ARM template to allow you to specify a cluster name, and that would pass through to the DSC and onto the Update-AD script, but that would take me a bit of time to test and validate - hopefully the workaround above is OK for now.

Thanks! Matt

Matt, this morning I turned on my host and reviewed the various objects in Azure. I observed the following issues:

• My host came up fine and the cluster node VMs started fine. When I went into WAC and looked at the cluster, everything seemed fine but when I went into the Azure portal it shows the nodes as not connected.
• When I created the cluster, I modified the scripts to call the cluster a different name and to put the cluster into a different Resource Group. I noticed that another Resource Group got created that is named with the format <cluster_name>-GUID-Arc-Infra-RG. This Resource Group has the Server -Azure Arc resources for each cluster node (AZSHCINODE01, AZSHCINODE02).
• When I click on either Server -Azure Arc object, they both say This server is not connected to Azure
• If I go into the Resource Group I specified in the script to create my cluster in, it only has the Azure Stack HCI resource. If I click on that resource, it shows both nodes as disconnected.
• I tried restarting the host but it did not change anything.