The Dell AX Solutions for Microsoft product family includes:

• Dell AX System for Azure Local (based on Azure Stack HCI operating system)
• Dell AX System for Microsoft Windows Server (Not described in this guide)

This end-to-end deployment and operations guide provides an overview of Dell AX System for Azure Local with switchless networking. The guide includes:

• Guidance on how to integrate solution components
• Instructions for preparing and deploying the solution infrastructure

The audience for this document includes systems engineers, field consultants, partner engineering team members, and customers with knowledge about deploying hyperconverged infrastructures (HCIs) with the Azure Stack HCI operating system, Hyper-V, and Storage Spaces Direct. Customers who do not have Volume License agreements with Microsoft can order AX nodes from Dell Technologies with a factory-installed operating system and OEM license or as a bare-metal installation.

An Azure Local instance can be deployed in the following ways:

• Dell Technologies Services-led—Certified deployment engineers ensure accuracy, speed, and reduced risk and downtime.
• Customer led—Customers who have the qualified level of technical expertise follow the instructions in this guide.

Dell AX System for Azure Local include various configurations of AX nodes from Dell Technologies. These AX nodes power the primary compute and storage cluster that is deployed as a hyperconverged infrastructure (HCI). The HCI uses a flexible solution architecture rather than a fixed component design.

For information about supported AX nodes and operating-system support for each of the AX nodes, see the Azure Local Support Matrix.

The solutions are available in both hybrid and all-flash configurations. For more information about available configurations, see Dell AX System for Azure Local specification sheet.

Dell AX System for Azure Local offers the following types of cluster infrastructure deployments:

• Switchless storage networking
• Scalable infrastructure

The Dell AX System for Azure Local infrastructure type offers two to four machines in a switchless configuration for storage traffic. The infrastructure can be implemented using any of the validated and supported AX nodes from Dell Technologies.

The switchless storage configuration has been validated with the following configurations for storage connectivity:

• Two-machine (back to back) connections
• Three-machine single-link or dual-link topology
• Four-machine dual-link topology

The following figure shows an Azure Local instance with a four-machine configuration and switchless storage networking that includes Out-of-Band (OOB) management to the data center network and the Azure Local instance.

Each of the variants in Dell AX System for Azure Local supports a specific type of network connectivity. The type of network connectivity determines the solution integration requirements.

For switchless storage networking, install the server cabling according to the instructions in Cabling instructions.

You can deploy Dell AX System for Azure Local by manually installing the operating system on AX node from Dell Technologies.

Each deployment has its own prerequisites, including configuring network switches, as described in this guide.

You can download the latest version of Windows Admin Center from Microsoft Windows Admin Center and install it on a supported operating system.

You can install Windows Admin Center directly on a managed machine to manage itself. You can also install Windows Admin Center on other machines in the infrastructure or on a separate management station to manage the AX nodes remotely.

The Windows Admin Center installer wizard performs the configuration tasks that are required for Windows Admin Center functionality. Tasks include creating a self-signed certificate and configuring trusted hosts for remote machine access. Optionally, you can supply the certificate thumbprint that is already present in the target machine local certificate store. By default, Windows Admin Center listens on port 443. You can change the port during the installation process.

For complete guidance about installing Windows Admin Center on supported operating systems with desktop experience or Server Core, see Install Windows Admin Center.

After the installation is complete, you can access Windows Admin Center at https://managementstationname:<PortNumber> as shown in the following figure.

Partner Admin Link (PAL) is a simple telemetry-based capability that is built into Microsoft Azure. PAL enables Microsoft to track partner involvement in Azure related technical engagements.

Adding a Dell Partner ID to the Service Principal does not provide Dell with additional access to the customer system and does not change any Azure Role-Based Account Controls (RBACs).

Dell Technologies employees can add a PAL using the user ID associated with either the subscription or Service Principal that is used for Arc or for Azure Local registrations. During a deployment, the customer creates the Service Principal for their system.

Dell Technologies recommends that you use the user ID associated with the Service Principal for the registration as described in Add a PAL through the Azure portal by using Azure PowerShell with Service Principal user ID.

Alternatively, you can follow the procedure that is described in Add a PAL through the Azure portal using the subscription user ID.

Before deploying AX nodes, complete the required predeployment configuration tasks.

Complete the following predeployment configuration before deploying the Dell AX System for Azure Local solution.

Based on the selected network topology, configure the ToR network switches to enable VM and management traffic.

The switchless storage-networking deployment model requires configuration of switches that are deployed for host management and OOB traffic only. Storage traffic uses full-mesh connectivity between the machines.

Configuring switch VLT redundancy with Virtual Router Redundancy Protocol (VRRP) provides a virtual floating IP address that any machine can reference as a gateway. If a switch fails, the virtual IP address is transferred to a peer switch.

VRRP is an active/standby first-hop redundancy protocol (FHRP). When used with VLT peers, VRRP becomes an active/active protocol. The VRRP virtual MAC address is the local destination address in the forwarding information base (FIB) table of both VLT peers. Using this method, the backup VRRP router forwards intercepted frames that have a destination MAC address that matches the VRRP virtual MAC address.

A standard Storage Spaces Direct deployment requires the following basic network types:

• OOB management
• Host management
• Compute
• Storage

The number of network ports (two or four) that are used in the storage configuration determines whether you have two or four fault domains.

For sample switch configurations, see Switch Configurations – RoCE/iWarp (Mellanox and Intel E810 Cards) Reference Guide or Dell Technologies Enterprise SONiC with Azure Local.

AX nodes from Dell Technologies are factory-configured with optimized system BIOS and iDRAC settings.

The iDRAC in AX nodes can be configured to obtain an IP address from a DHCP server or can be assigned a static IP address. When the Out-of-band (OOB) network is not configured to obtain IP addresses from a DHCP server, you must manually set a static IPv4 address on each iDRAC network interface. You can use KVM or other means to access the physical server console and set the addresses.

When deploying a switchless interconnect, follow these cabling best practices.

Dell Technologies populates PCIe network adapters consistently, but the slot enumeration sequence depends on platform and riser configuration. PCIe slot identification is labeled on the chassis, and Port 1 and Port 2 are physically labeled on the PCIe NIC adapter bracket.

Note: PCIe riser orientation may change the port orientation on each network adapter. Therefore, some network adapters may have a physically reversed orientation depending on which PCIe slot the network adapter is installed. Check the orientation of Port 1 and Port 2 on each network adapter, as shown in the following figure.

The following figure shows the two storage networks that are required to create a dual-link direct interconnect between two machines that will be clustered (also known as back-to-back). The numbered blue lines indicate the recommended cabling order, beginning with the network adapter in the lowest slot number (port 1). After cabling storage, connect all machines, LOM/rNDC/OCP, and ports 1 and 2 to a management or compute network.

The following figure shows an example of a three-machine configuration (to be clustered) that is configured with a single-link storage network interconnect. External network traffic uses the LOM/rNDC/OCP integrated network adapter. Storage network traffic uses one RDMA-capable PCIe network adapter for each server node. If there is a storage network connectivity (cable or port) failure, the management network offers some redundancy.

The three storage networks are required to create a single-link full-mesh interconnect between three clustered machines. The numbered blue lines indicate the recommended cabling order, beginning with the RDMA-capable PCIe network adapter in the lowest slot number, Port 1.

After cabling storage, you must connect all machines, LOM, rNDC, and OCP, and Ports 1 and 2 to a management or compute network.

The following figure shows the cabling topology of a Dell AX-4520c three-node instance that is configured in a single-link full mesh, enabling direct node-to-node connectivity.

The following table lists the port link connections and their details

The following figure shows an example of a three-machine configuration (to be clustered) that is configured with a dual-link full-mesh storage-network interconnect. External network traffic uses the LOM-, rNDC-, or OCP-integrated network adapter, while storage network traffic uses two RDMA-capable PCIe adapters for each server machine. In this case, each clustered machine has redundant storage network connectivity to every other machine in the Azure Local instance.

The following figure also shows six storage networks that are required to create a dual-link full-mesh interconnect between three clustered machines. The numbered blue lines indicate the recommended cabling order, beginning with the RDMA adapter in the lowest slot number (Port 1). After cabling storage, connect all machines, LOM, rNDC, or OCP, and Ports 1 and 2 to a management or compute network.

The following figure shows the cabling topology of a Dell AX-4520c three-machine instance that is configured in a dual-link full mesh, which enables direct machine-to-machine connectivity.

The following table lists the port link connections for a Dell AX-4520c three-machine instance with dual-link full-mesh cabling.

The following figure shows an example of a four-machine instance that is configured with a dual-link full-mesh storage-network interconnect. External network traffic uses the LOM-, rNDC-, and OCP-integrated network adapter, while storage network traffic uses three RDMA-capable PCIe adapters for each server machine. In this case, each machine has redundant storage network connectivity to every other machine in the instance.

The following figure also shows the twelve storage networks that are required to create a dual-link full-mesh interconnect between four clustered machines. The numbered blue lines indicate the recommended cabling order, beginning with the RDMA adapter in the lowest slot number (Port 1). After cabling storage, connect all machines, LOM , rNDC, and OCP, and Ports 1 and 2 to a management or VM network.

The following table lists the port-link connection details for a Dell AX-4520c four-machine instance with dual-link full-mesh cabling.

The following figure shows the cabling topology of a Dell AX-4520c four-machine instance that is configured in a dual-link full mesh, which enables direct machine-to-machine connectivity.

The following table lists the port link connections for four-machine, dual-link full-mesh cabling for Dell AX-4520c.

The following instructions are for manual deployment of the Azure Stack HCI OS version 24H2 on AX nodes from Dell Technologies.

Unless otherwise specified, do the steps on each physical machine in the infrastructure that is part of the Azure Local instance.

Before starting the deployment, ensure that the following requirements are met:

• The network configuration is in order.
• Internet connectivity on the machines is good.
• The Azure subscription is registered with the required resource providers. Only the owner or contributor of the subscription can register the resources provider. For the most up-to-date list of required resource providers, see Assign required permissions for Azure Local deployment.
• (Optional) A resource group is created either before or when you register the machines to Azure Arc. To create a resource group, follow the steps in Create resource groups.
• The correct tenant ID is available. To get the tenant ID, check Get subscription and tenant IDs in the Azure portal.
• Permissions are verified.
• Azure policies are reviewed.

For more information, see Assign required permissions for Azure Local deployment > Azure Local machine prerequisites.

To assign the required permissions for user roles, see Assign required permissions for Azure Local deployment.

Set up an Active Directory environment before deploying an Azure Local instance.

To prepare your Active Directory environment, see Prepare Active Directory for Azure Local deployment.

Before registering the machines with Azure Arc, if you have an Azure Arc gateway requirement in your environment, to understand the prerequisite requirements, see About Azure Arc gateway for Azure Local.

You can use one of the following options to register the Azure Local machines with Azure Arc using PowerShell commands. For details, see:

• Register Azure Local with Azure Arc > With proxy
• Register Azure Local with Azure Arc > Without proxy
• Register Azure Local with Azure Arc using Arc Gateway > With proxy
• Register Azure Local with Azure Arc using Arc gateway > Without proxy

Deploy the Azure Local instance using the Azure portal, a manual ARM template, or an Azure portal Quickstart Template deployment.

You can deploy an Azure Local instance in the following ways:

• Azure portal deployment without ARM templates, which only uses the UI in the Azure portal to deploy an Azure Local instance. For more information, see Deploy an Azure Local instance using the Azure portal.
• Manual ARM Template deployment, which allows you to manually create an ARM template (JSON file) and deploy it using Azure CLI, PowerShell, or REST APIs. For more information, see: Deploy Azure Local via Azure Resource Manager deployment template.
• Azure portal deployment with Quickstart Template (template deployment), which uses the UI in the Azure portal to deploy ARM templates. This method is not documented in this guide.

The Azure portal wizard guides you through steps to create an Azure Local instance.

You can use the wizard to define all instance‑level and machine‑level configuration settings. The wizard guides you through the following windows:

1. Basics
2. Configuration
3. Networking
4. Management
5. Security
6. Advanced
7. Tags (optional)
8. Validation
9. Review and create

To create an Azure Local instance:

1. Go to Home > Azure Local.
2. Under Get Started, in Deploy Azure Local, select Create instance, and then do the following steps in the wizard:

Step 6: Advanced

Click the Advanced tab. Under Create workload and infrastructure volumes, for Volumes, choose Create one workload volume and storage path per machine, and one required infrastructure volume per system (Recommended), as shown in the following figure.

For more information, see Optionally change advanced settings and apply tags.

Before deploying AX nodes, complete the required predeployment configuration tasks.

Perform all machine preparation procedures described in Chapter 3: Solution Deployment, including:

• Host network configuration
• Hostname configuration
• Node preparation configuration

These procedures are identical for Active Directory and Local Identity deployments.

You can deploy an Azure Local instance in the following ways:

• Azure portal deployment without ARM templates, which only uses the UI in the Azure portal to deploy an Azure Local instance. For more information, see Deploy an Azure Local instance using the Azure portal.
• Manual ARM Template deployment, which allows you to manually create an ARM template (JSON file) and deploy it using Azure CLI, PowerShell, or REST APIs. For more information, see: Deploy Azure Local via Azure Resource Manager deployment template.
• Azure portal deployment with Quickstart Template (template deployment), which uses the UI in the Azure portal to deploy ARM templates. This method is not documented in this guide.

The Azure portal wizard guides you through steps to create an Azure Local instance.

You can use the wizard to define all instance‑level and machine‑level configuration settings. The wizard guides you through the following windows:

1. Basics
2. Configuration
3. Networking
4. Management
5. Security
6. Advanced
7. Tags (optional)
8. Validation
9. Review and create

To create an Azure Local instance:

1. Go to Home > Azure Local.
2. Under Get Started, in Deploy Azure Local, select Create instance, and then do the following steps in the wizard:

Step 6: Advanced

1. Click the Advanced tab.
2. Under Create workload and infrastructure volumes, for Volumes, choose Create one workload volume and storage path per machine, and one required infrastructure volume per system (Recommended), as shown in the following figure.

For more information, see Optionally change advanced settings and apply tags.

Management tooling support varies across the Azure Local ecosystem for environments that use Azure Key Vault for identity management.

Download Connector is a component in the Solution Builder Extension (SBE) package that automates the download of new SBE bundles as they become available for your Azure Local instance.

When an SBE that includes the Download Connector is installed on your instance, manual downloading and importing of subsequent versions is no longer required. The update service automatically retrieves the next available SBE, similar to how solution updates are handled.

Download Connector is part of SBE version 4.1.2505.1501 and later. These versions also feature system and update health checks that proactively verify connectivity to the required remote resource before downloading the next SBE. System health checks run daily, while update health checks occur at the beginning of the update process.

The Solution Builder Extension (SBE) Download Connector requires outbound Internet access to retrieve update bundles and catalogs.

The SBE Download Connector that runs on the Azure Local instance must periodically connect to Internet resources to enable Download Connector to download SBE bundles for your instance. The following table lists the outbound connectivity that is required:

For more information about SBE packages with Download Connector capability and installation procedure, see Solution Builder Extensions for Azure Local - Integrated System AX Server Release Notes.

You can apply solution updates to your Azure Local instance using the Dell Solutions Builder Extensions (SBE) package. You can update your instance either by:

• Downloading offline solution updates
• Discovering online solution updates and then applying the updates

You must ensure that:

• You have a functioning Azure Local instance with Azure Stack HCI operating system, version 24H2. The instance is registered to Azure.
• You have access to the online solution update package or offline solution update package download.

You can do these updates either by:

• Using PowerShell
• Using Azure Update Manager service from the Azure portal

The process for updating the SBE package using PowerShell in offline mode can be used for both multi-machine or single-machine Azure Local instances.

To do an offline solution update, follow the steps that are described in Azure Local Dell Solution Builder Extensions Release Notes > Installation

You can install and configure GPUs on AX platforms. For a list of GPUs that are supported on AX nodes from Dell Technologies, see the Dell Solutions for Microsoft Azure > Azure Local Support Matrix.

For deployed Azure Local instance, or Windows Server 2025 (or later instance before performing any GPU hardware changes, place the target machine into maintenance mode (pause and drain).

Use Dell Support to follow the platform-specific GPU installation procedure for your server model.

For model-specific GPU slot or riser matrices and riser configuration options, see the applicable Dell installation and service manual sections for your platform, including:

• Expansion card riser specifications
• Expansion card installation guidelines
• GPU kit (if available)
• GPU specifications

For the most up-to-date list of supported GPUs for AX nodes, see the Dell Solutions for Microsoft Azure > Azure Local Support Matrix.

You can use Discrete Device Assignment (DDA) on supported GPUs so that the Azure Stack HCI and Windows Server 2025 and later operating system servers contain GPU-enabled clustered VMs.

For a list of supported GPUs, see the latest version of the Dell Technologies Solutions for Microsoft Azure Local > Support Matrix.

On the Azure Stack HCI or Windows Server 2025 or later operating-system servers, you can use GPU partitioning (GPU-P) for different workloads, such as artificial intelligence. To avoid mistakes and for a streamlined visual experience, Dell Technologies recommends that you use Windows Admin Center (WAC) for GPU-P.

For the latest supported GPU-P enabled GPUs, see Dell Technologies for Microsoft Azure Local > Support Matrix.

Dell Technologies servers do not come with a GPU-P driver. The GPU-P driver requires separate licensing from NVIDIA. For more information about licensing options and the benefits of GPU-P, see: NVIDIA Virtual GPUs.

Dell OpenManage Integration with Windows Admin Center (OMIMSWAC) simplifies the tasks of IT administrators by remotely managing the AX nodes from Dell Technologies and Windows Server cluster throughout their life cycle.

For more information about the features, benefits, and installation of OMIMSWAC, see Dell OpenManage Integration with Microsoft Windows Admin Center.

After enabling cluster management, you can use the cluster management options in the Dell OpenManage Integration extension to view and take action as required.

In the Dell OpenManage Integration extension, select View > Overview. The Overview window displays the following cluster-level information:

• Overview
• HCP Compliance
• Security
• Resources
• Quick task

For more information about each section, see the following:

Infrastructure lock (also known as iDRAC lockdown mode or system lockdown mode) helps to prevent unintended changes after a system is provisioned. Infrastructure lock is applicable to both hardware configuration and firmware updates. When the infrastructure is locked, any attempt to change the system configuration is blocked. If any attempts are made to change critical system settings, an error message is displayed.

Enabling infrastructure lock also blocks server or cluster firmware updates using the Dell OpenManage Integration extension in Windows Admin Center.

The following table lists the functional and nonfunctional features that are affected when the infrastructure lock is enabled:

You can resize volumes that are created in Spaces Direct storage pools by using the Resize-VirtualDisk cmdlet. For more information, see Manage volumes in Azure Stack HCI and Windows Server.

In an Azure Local instance, expanding storage by adding drives on the available slots on the instance machines adds storage capacity to the instance and improves storage performance. Before the storage expansion, ensure that all drive types and the amount in each drive are the same and are equal to that of the drive in use.

Do not combine different drive types in the same Azure Local instance or machine. For example, you cannot combine SATA and SAS hard drives or solid-state drives.

The following options for expanding the storage capacity of the cluster are supported:

• Option 1: Expand the storage with the same drive manufacturer, capacity, endurance, latest model, and latest firmware. Determine if the drive is available on the AX node model that is listed in the Support Matrix.
• Option 2: Expand the storage with a different drive manufacturer, model, firmware, and the same capacity and endurance. Determine if the drive is available on the AX node model that is listed in the Support Matrix.

When drives are added to extend the overall storage capacity per machine, the Azure Local instance starts claiming the hard drives into an existing storage pool.

After the drives are added, they are shown as available for pooling (CanPool is set to True) in the output of the Get-PhysicalDisk command.

In a few minutes, the added drives are claimed in the existing pool, and then Storage Spaces Direct starts the rebalance job. To verify that the new drives are a part of the existing pool, you can run the following command and see the listed results:

PS C:\> Get-ClusterPerformanceHistory -FriendlyName *Cluster* | Get-StorageHealthReport
CPUUsageAverage                 :   2.66 %
CapacityPhysicalPooledAvailable :   8.01 TB
CapacityPhysicalPooledTotal     :  69.86 TB
CapacityPhysicalTotal           :  69.86 TB
CapacityPhysicalUnpooled        :      0 B
CapacityVolumesAvailable        :  15.09 TB
CapacityVolumesTotal            :  16.88 TB
IOLatencyAverage                : 908.13 us
IOLatencyRead                   :      0 ns
IOLatencyWrite                  : 908.13 us
IOPSRead                        :      0 /S
IOPSTotal                       :      1 /S
IOPSWrite                       :      1 /S
IOThroughputRead                :      0 B/S
IOThroughputTotal               :  11.98 KB/S
IOThroughputWrite               :  11.98 KB/S
MemoryAvailable                 : 472.87 GB
MemoryTotal                     :    768 GB

After all available drives are claimed in the storage pool, the CapacityPhysicalUnpooled is 0 B.

The storage rebalance job might take a few minutes. You can monitor the process by running the Get-StorageJob command.

If the operating system cannot be recovered due to hardware or operating system failures, you can initiate a machine repair in your Azure Local instance.

If you use a golden image for your Azure Local instances that are running with Solution version 10.2503 or later, you can repair machines in your Azure Local instances.

Before you can repair a machine in your Azure Local Instance, you must ensure that the Prerequisites for repairing a machine in an Azure Local instance are met.

For more information, see Repair a node on Azure Local

This section provides an overview of the steps involved in operating system recovery on Dell AX System for Azure Local.

For manually deployed machines, you can recover the operating system on the machine by using any of the methods that were used for operating system deployment.

FullPowerCycle is a calling interface function that provides a way to reset the server auxiliary power. An increasing amount of server hardware runs on server auxiliary power. Troubleshooting some server issues requires you to physically unplug the server power cable to reset the hardware running on auxiliary power.

The FullPowerCycle feature enables the administrator to connect or disconnect auxiliary power remotely without visiting the data center. This feature is supported on AX nodes and on Storage Spaces Direct Ready machines.

The relevant commands to run in the PowerShell console are:

• To request FullPowerCycle on your system: Invoke-FullPowerCycle -status request
• To get the status of FullPowerCycle on your system: Invoke-FullPowerCycle -status Get
• To cancel FullPowerCycle on your system: Invoke-FullPowerCycle -status cancel