Roll your own AVD on HCI deployment – Part 2: The Plan & Identity


Advanced Migration GBB

Welcome back, and to Part 2 of this series. I hope that you found the first part helpful. Continuing on from the last Blog post you should have a few things sorted out now to begin our next set of deployment steps.

  1. You should have your hardware up to date with the latest available firmware.
  2. The hardware should be set for TPM, SecureBoot, and the storage controller in IT mode (if required).
  3. You should have a USB Key with the latest version of Azure Stack HCI 23H2 and the Driver/Software folder you created earlier on the root of the drive.


Now is a good time to pause and recommend that you take some time to plan the environment you’re going to deploy. As they say, “Failing to make a plan…” Seriously, you need to make a few decisions with regard to structure of the solution in order to know how all this will play out. You need to understand the infrastructure network space your HCI servers will live in:

How will they communicate with each other?

Are there VLANs and/or Firewalls involved?

What is the AD Domain you’ll connect to?

Will you need to use a Proxy to talk to Azure?

Private Endpoints?

What naming convention will you use for the systems, cluster, users?

Taking a few minutes (or more than a few) to review the network requirements. Documenting your config goes a long way in troubleshooting things later. I typically start a OneNote or Notepad doc and write down as much as I can as I go and refer to it later as needed. You can find the Network Requirements for HCI here: Physical network requirements for Azure Stack HCI – Azure Stack HCI | Microsoft Learn But, this is just the tip of the iceberg. There is a bunch you can get lost in with this aspect of the documentation. I’m still trying to find my way out! My best advice is understand the physical topology of the environment, then look at the deployment options for the number of nodes you have referenced in the docs. Then look at the IP requirements for your chosen pattern.

I have a co-worker Kevin who loves to say Firewalls, Firewalls, Firewalls. If there’s an issue with a hybrid or “Adaptive Cloud” solution, it’s almost always firewalls. So, have a look here: Firewall requirements for Azure Stack HCI – Azure Stack HCI | Microsoft Learn and make sure you can reach the endpoints, refer your NetSec team here too and discuss if these would be an issue. Most are common and known Microsoft endpoints but it’s helpful to be proactive. Another great tool that has been developed is the Environment Checker tool, Microsoft has spent a bunch of time making sure the Hybrid connectivity can be successful. You can use this: Use Azure Stack HCI Environment Checker to assess deployment readiness for Azure Stack HCI, version 23H2. – Azure Stack HCI | Microsoft Learn to make sure your network is ready to talk to Azure, if the Hardware is up to snuff, can the nodes talk to AD or Arc endpoints and the ports are open for all the needed traffic.

In order to deploy an HCI infrastructure, you need 1 IP address per server, plus a minimum of 6 additional contiguous IPs for infrastructure that will be deployed during the cluster creation process. The first consumed will be the Cluster IP, the rest are various Failover Cluster services that will also be deployed within the solution. You may also need IPs for OOB management nics and IPs for a Domain controller or two if you are building a net new environment.

Azure Stack HCI 23H2 changes the installation and cluster deployment process compared to earlier versions. In the past, you would build everything on-prem and register the cluster as a final step. Today, you install the hypervisor and do some minor personalization config, then you register the system with Azure Arc BEFORE you form the cluster, join the domain, etc… Azure will do those steps for you. It’s a BIG improvement over the old way and handles a bunch of steps for you. You should have all of these design decisions made before you move on. Write it all down! You will need it to go through the wizard later.

Active Directory

Also, with the release of 23H2, there is now a defined method of organizing your on-prem Active Directory environment resources and a PowerShell tool to help with the deployment. Let’s start there. You should have an AD environment running. This is a Prerequisite to get Azure Stack HCI going. If you’re uncomfortable adding this solution to your existing AD Domain, you can stand one up just for Azure Stack HCI. Flo Fox has written a great blog post on the concept of Fabric Identity here: Why You Should Have a Fabric Domain and Network for Azure Stack HCI (

The AD environment doesn’t have to be hybrid connected to EntraID to serve the needs of Azure Stack HCI. It’s used for the on-prem server identity space and the Failover Cluster configuration. Once you have the AD environment identified, we need to run the PowerShell utility to prep the environment. You should run this on a system that has access to the Active Directory environment. This wouldn’t be one of the HCI nodes, at least not yet. You can run it on a domain controller if that’s all you have. You also need to have a user account that can create an OU and User Accounts. You can pull down the PowerShell module by going to the command line and typing:

Install-Module AsHciADArtifactsPreCreationTool -Repository PSGallery -Force

Once you have the PowerShell module, now you need to decide what you want your OU name to be and Username. The Username should be JUST the name not a domain context as you’re already signed in to run the tool. Here is some handy code to get the objects created:

$password = ConvertTo-SecureString '<password>' -AsPlainText -Force

$user = "lcmuser"

$credential = New-Object System.Management.Automation.PSCredential ($user, $password)

New-HciAdObjectsPreCreation -AzureStackLCMUserCredential $credential -AsHciOUName "OU=ms309,DC=s31r1503,DC=microsoft,DC=com"

Tip: If you’re Password requires the $ symbol use ‘single’ hashes instead of “quotes”.

You can validate the Domain Prep and configuration was successful by looking at the OU and User Account in Active Directory Users and Computers admin tool.

In the OU, right click go into Properties and verify that Block Inheritance was enabled.

Once you have a successful result, you’ve completed the required steps to prep the on-prem domain. Yay! You did it! High Five. See that wasn’t so bad. Now we can move on to the EntraID and Azure Subscription steps to prepare the cloud side of the deployment.


Login to the Azure Portal, if you’re using a dedicated EntraID tenant for your test environment you can switch to the right one in the upper right-hand side by selecting your username.

The EntraID tenant you are currently in will be shown under your account. If this is correct, great! If not, click your user account and select the correct one. Also, while you’re in here click the Star next to the Tenant to make your default on sign-in and see at the top what the default subscription is at the top. If it’s the one you’re working with great! If not, you’ll need to change that later.

Now, select the subscription under the EntraID tenant you intend to use for your HCI environment. In order to make the subscription and EntraID changes, you’ll need the rights within both to properly complete the steps. If you don’t have Owner/Contributor rights to the subscription or Admin rights within the EntraID you’ll need to work with someone who does or have them granted to you.

We need to register Resource Providers into the Subscription to allow resources to be created. This only has to be done once per subscription. The most straightforward way to do this is within the Subscription element itself.

Type in Subscription within the search box, navigate to the list of subscriptions, select the one you are using. Then within the Subscription blade scroll down on the left side to Resource Providers:

You’ll want to register the following RPs:





Select the RPs then click Register at the top. You don’t have to wait for this to complete. Azure Resource Manager is multithreaded and will work on each one until complete. You’ll need rights to do this in the subscription. Typically, Contributor is enough.

While you’re in the subscription, also assign yourself a couple of permissions in IAM. Scroll up select IAM –> Click “Add+” in the top left corner of the blade. Then select Add Role Assignment. Assign the following Roles:

Azure Stack HCI Administrator


These will allow you to manage the HCI systems deployed within the subscription. Verify the Role Assignments are correct before moving on.

Finally, we need to assign the required permissions to deploy the Azure Stack HCI resources. The best way to do that is to pre-create a Resource Group within the subscription. You “could” do this subscription wide, but that’s not a best practice and unless you are going to be creating 100s of clusters across dozens of RGs, it doesn’t really make sense. Even then, I’m not sure it does.

Once you’ve completed assigning the RPs and your Subscription level IAM roles, scroll down to Resource Groups and create a new Resource Group. Call it whatever you like. Wait for this to complete then select the RG.

Inside the RG, you’ll go to the IAM section on the left-hand side of the blade and on the right select “Add+” like before then Add Role Assignment. You’ll want to give yourself the following roles:

Azure Connected Machine Onboarding

Azure Connected Machine Resource Manager

Key Vault Administrator

Key Vault Contributor

Key Vault Secrets User

Storage Account Contributor

There are programmatic and additional organizational methods to make these rights assignments work at scale. You could use Azure CLI or PowerShell or Cloud Shell to perform all of this. You can also create EntraID groups to organize the assignments or even create a Service Principal to manage all of the onboarding and limit rights assignments to only those who NEED to Manage or Troubleshoot all this. All of that can, and should be done if you’re going to scale this solution, but for a limited environment with very little infra, is that worth it? If so, you can have a look here:

Register your Azure Stack HCI servers with Azure Arc and assign permissions for deployment – Azure Stack HCI | Microsoft Learn

Connect hybrid machines to Azure at scale – Azure Arc | Microsoft Learn

How to manage groups – Microsoft Entra | Microsoft Learn

You can use the user rights above and the role assignments with those links to construct a scalable Cloud Identity and Onboarding solution.

At this point, we’ve completed the Identity portion of the solution, and we can begin to install the HCI Nodes. Thanks to Flo Fox and Michael Godfrey for all the documentation and scripts. Oh, and thanks to Kevin Sullivan for letting me use his catch phrase. Thanks for reading!

Scroll to top