Copyright

About copying commands from this guide

CAUTION: Many PDF editors and viewers add a line break to the end of each line of text in a PDF. As a result, when you copy commands that wrap across multiple lines in a PDF, the copied command is in the wrong format. It contains erroneous line breaks that might cause the script to fail.

To address this known limitation, do one of the following:

Paste the copied commands into a text editor and remove the line breaks.
Use the HTML version of this document when you are copying commands.

Revision history

The revision history of the document is listed in the following table.

Revision history. This table lists the dates on which this document was published and a description of the changes that are associated with each publishing date.
Date	Document revision	Description of changes
October 2026	12	Added the "Automated firmware updates after Azure Local server imaging" section under Operating System Deployment in the Predeployment Configuration topic. Added the chapter "External SAN support for Azure Local". Updated the "Deployment prerequisites for Azure Local deployment using local identity" topic to add DNS suffix as a required management service. Updated the "Configure Broadcom NICs" topic to document support for Broadcom 57416 NICs.
June 2026	11	Minor updates across the document for 2606 release
April 2026	10	Added chapter 5, "Solution Deployment with Local Identity" Removed "preview" from "Configurator app" in "Register machines with Azure Arc" topic Removed "which is in preview" from the note in "Register machines with Azure Arc" topic Updated the list with two new entries in "Deploy the Azure Local instance" topic Added a new step on Cluster options in Basic section in "Deploy Azure Local Instance using Azure portal" topic Added information about Rack aware in Advanced section in "Deploy Azure Local Instance using Azure portal" topic Updated image, "Choosing volumes" in Advanced section "Deploy Azure Local Instance using Azure portal" topic Updated step 4 in "Deploy an Azure Local instance using the Microsoft ARM template" topic to clarify that it applies to a standard cluster deployment Added a subbullet in the step "Under Networking type" to document the networking type requirements for a rack aware cluster deployment Added a subbullet in the step "Under Networking Pattern" to document the networking type requirements for a rack aware cluster deployment Added a new step and related codes for a rack aware cluster deployment in "Deploy an Azure Local instance using the Microsoft ARM template" topic. Added a new section "Drift detection for Azure Local" in "Register machines with Azure Arc" topic Updated the “Adapter requirements” section in the “Solution integration and network connectivity” topic to reflect support for configuring Network ATC intents using the Azure portal or ARM templates, starting with Azure Local Solution version 2603.
April 2026	9	Removed bullet that is related to Windows Server in “Audience and scope” topic Removed first sentence and updated SBE version number to 4.1.2505.1501 in “Download Connector” topic Added note to “SBE package update prerequisites” topic Added two notes to steps in Basics section in “Deploy Azure Local Instance using Azure portal” topic Substantial revisions to "Configuration to prepare node" topic Removed table and revised information and references in "Antivirus exclusions" topic Updated procedure of "Restart a cluster node or take a cluster node offline" topic and added link to current Microsoft procedures and renamed the topic to “Suspend and resume a cluster node"
April 2026	9	Removed "Azure portal-based" from the doc title and revised the abstract to include Azure Arc template deployment method Renamed "About using this guide" to "About copying commands from this guide" Removed any references to Azure Stack HCI 23H2 operating system as it is no longer possible to deploy the 23H2 version Added the note, ToR switches to be used for Azure Local instance deployments to "Scalable infrastructure" and "Configuring network switches" topics Added Configure Broadcom 57504 network adapters topic to "Predeployment configuration" section Added content to "Enable operating system features" in the table and a note regarding AX-670 and AX-770 nodes Updated Basics steps in "Deploy Azure Local Instance using Azure portal" procedure Updated steps in "Deploy an Azure Local instance using the Microsoft ARM template" procedure Updated "Add node to a chassis" topic to include info about racks Added a note to the "Check Azure Arc registration after reboot" topic Replaced "Stage SBE package for installation" topic with a paragraph because the installation procedure is now automatic with golden image. Updated table in "Prerequisites for adding machine to Azure Local instance" Revised step in "Install operating system on machine" topic Removed switchless storage networking warning from "Prerequisites for adding machine to Azure Local instance" topic Replaced QoS table regarding network priorities in: Step 3: Networking of "Deploy Azure Local instance using Azure portal" topic Step 19 of "Deploy an Azure Local instance using the Microsoft ARM template" topic Revised the "GPU Integration" chapter Revised "Add a node to the chassis" to include information about adding nodes to racks Updated table in "Prerequisites for repairing machine in Azure Local instance" Revised command in the note for the first step in "Add repaired machine to Azure Local instance" Added step to "Verify the health of Azure Local instance" procedure Added text with link re data disks to "Install operating system on repaired machine" procedure Minor updates throughout the document
October 2025	8	Added a topic "Check Azure Arc registration after reboot" Added a QoS table regarding network priorities to "Deploy Azure Local instance using Azure portal" in Step 3: Networking and to "Deploy an Azure Local instance using the Microsoft ARM template" in Step 19. Added note to the first step in "Add repaired machine to Azure Local instance" procedure Deleted a duplicate topic under "Best practices and recommendations" In the "Deploy an Azure Local instance using the Microsoft ARM template" procedure, revised two lines of code in the JSON snippet example In "Prerequisites for managing AX nodes," updated references to OMIMSWAC guides to version 3.4 In "Repairing machines in Azure Local instances" added reference to a relevant Microsoft article Added a topic under "Azure Local instance node expansion" for the physical addition of an AX node to a chassis Split "Update SBE package using PowerShell" into two separate topics for online and offline solutions Minor updates across document
September 2025	7	In “Install Windows Admin Center” topic, removed high-availability content, and updated figure. Windows Admin Center no longer supports it from release 2410 onwards In "Prerequisites before deploying Azure Local instance using Microsoft ARM template" section, removed all topics because they are no longer needed from Azure Local release 2507 onwards In “Configure host networking” topic, added note with caution and link about an optional deployment script that automates the operating system configurations In “Configuring iDRAC and BIOS” section, added “Configure NVIDIA (Mellanox) NICs” topic In "Register machine with Azure Arc" section, added note regarding PowerShell modules, and added link to a corrected Microsoft page regarding registering deployments with Azure Stack HCI operating system version 23H2, an added information about the Configurator app In the "Deploy an Azure Local instance using the Microsoft ARM template" procedure, corrected a capitalization error in the JSON snippet example Minor updates across document
August 2025	6	Changed references to the Azure Stack HCI operating system from 23H2 to 24H2 where required Removed the "Update the page file settings" section Removed the "Install roles and features" section Added new sections for "Add machine" and "Repair machine" Updates across the document
May 2025	5	Added the "Download Connector" section Rebranded solution for 16th generation onwards: Change "Integrated System for Microsoft Azure Stack HCI" to "AX System for Azure Local" and "AX System for Microsoft Windows Server" Changed product name from "Azure Stack HCI" to "Azure Local" where appropriate Changed "cluster" to "Azure Local instance" and "node" to "machine" where appropriate Minor changes across the document
May 2025	4	Removed the "Factory-installed operating system deployment" section Removed the "Registry settings" section
April 2025	3	Added the Golden image content Updated the GPU section Minor updates across the document
September 2024	2	Updated the following images: Fully converged network topology with two NIC ports Fully converged network topology with four NIC ports Added the following images: Dell AX-4510c and Dell AX-4520c servers of fully converged topology Dell AX-4510c and Dell AX-4520c servers of nonconverged topology Added AX-4520c GPU configuration information Minor updates across the document
May 2024	1	Initial publication

Deployment introduction

Document overview

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 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 scalable networking. The guide includes:

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

NOTE: This guide only applies to infrastructure that is built using the validated and certified AX nodes from Dell Technologies and the Azure Stack HCI operating system.

Audience and scope

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.

Assumptions

This guide assumes that deployment personnel understand the following technologies and tasks:

AX nodes from Dell Technologies
Deploying and configuring BIOS and integrated Dell Remote Access Controller (iDRAC) settings

Known issues

Before starting the cluster deployment, see Azure Local release information.

Solution overview

Solution introduction

Dell AX System for Azure Local includes various configurations of AX nodes from Dell Technologies. AX nodes power the primary compute 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 the Dell AX System for Azure Local specification sheet.

Deployment models

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

Switchless storage networking
Scalable infrastructure

Scalable infrastructure

The scalable offering for Dell AX System for Azure Local encompasses various AX node configurations. In this Azure Local solution, as many as 16 AX nodes power the primary compute cluster.

The following figure shows one of the flexible solution architectures. It includes the Azure Local instance, redundant top-of-rack (ToR) switches, a separate out-of-band (OOB) network, and an existing management infrastructure in the data center.

Dell AX System for Azure Local does not include:

Management infrastructure components such as a cluster for hosting management virtual machines
Services such as Microsoft Active Directory, Domain Name System (DNS)
Microsoft System Center components such as Operations Manager (SCOM)

The instructions in this guide do not include deployment of any of these services and components, and they assume that at least an Active Directory domain controller is available in the existing management infrastructure. In a remote office scenario, Dell Technologies recommends that you deploy either an Active Directory replica or read-only domain controller (RODC) at the remote office. If you are using an RODC at the remote site, connectivity to the central management infrastructure with a writable domain controller is mandatory during deployment of the Azure Local instance.

Top-of-rack (ToR) switches that are used in Azure Local instance deployments and that forward RDMA storage-network traffic must be listed in the Azure Local ToR switch list on the following Microsoft page: Physical network requirements for Azure Local > Network switches for Azure Local

NOTE: For deployments with ToR switches that are not listed, you must use the switchless storage-network deployment option.

Solution integration and network connectivity

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 sample switch configurations for these network connectivity options, see Switch Configurations – RoCE/iWarp (Mellanox and Intel E810 Cards) Reference Guide or Dell Technologies Enterprise SONiC with Azure Local.

NOTE: Data Center Bridging (DCB) is required for all Azure Local instance deployments.

Adapter requirements

Azure Local requires using the same adapter card vendor and model for the machines in an instance that supports instance operations. The ports that are used by the same Network ATC intent must use the same vendor, model, and speed.

Starting with Azure Local Solution version 2603, Azure Local instances that require NIC-level high availability can use the Azure portal or ARM templates to configure Network ATC intents using NIC ports from adapters that share the same PCIe Vendor ID and PCIe Device ID. This capability enables ports from both an OCP NIC and a PCIe riser NIC to be included within a single Network ATC intent, provided the adapters are of the same NIC model.

CAUTION: If you use optics or cables from one vendor with an adapter card from another vendor, Dell cannot guarantee that your configuration will work as expected. Before you mix vendor equipment in an Azure Local instance, consult the Dell Technologies cable and optics in the Support Matrix.

Fully converged network connectivity

In the fully converged network configuration, both storage and management or VM traffic use the same set of network adapters. These adapters are configured with Switch-Embedded Teaming (SET). When using RoCE in a fully converged network configuration, you must configure DCB.

The following figure depicts the integration of the fully converged architecture.

Fully converged network topology with two NIC ports

The following figure depicts the fully converged network topology with four NIC ports.

Figure illustrating fully converged network topology with four NIC ports

The following figure depicts the Dell AX-4510c fully converged network topology with embedded LAN on Motherboard (LOM).

Dell AX-4510c fully converged network topology with embedded LOM

The following figure depicts the Dell AX-4520c fully converged network topology with PCIe NICs.

In the fully converged network topology, all storage ports from the server are connected to the same network fabric. In the host operating system, the NIC ports are used for both storage and management or VM traffic. The following figure shows this configuration in the host operating system.

In the host operating system network configuration, a SET is created with two or four physical ports and virtual adapters in the host operating system that is implemented for Storage 1, Storage 2, and Management traffic.

Operating-system network configuration in fully converged topology with two NIC ports

NOTE: The number of virtual storage adapters in the host operating system must match the number of physical ports in the SET.

Non-converged network connectivity

In the non-converged network configuration, storage traffic uses a dedicated set of physical network adapters.

In the non-converged configuration, Dell Technologies recommends the following:

Storage traffic is on the physical storage network adapter ports.
Management or VM traffic goes through a SET that is created using network ports of the server rack-integrated NIC port.

The following figure depicts this network integration option.

Figure showing network integration in a non-converged configuration with two NIC ports

The following figure depicts a Dell AX-4510c non-converged network topology with embedded LOM:

Dell AX-4510 non-converged network topology with embedded LOM

The following figure depicts a Dell AX-4520c non-converged network topology with PCIe NICs:

Solution deployment

Solution deployment introduction

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

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

NOTE: Instructions in this deployment guide are applicable to the Azure Stack HCI operating system, version 24H2.

Each task in this deployment guide requires running one or more PowerShell commands. Dell Technologies recommends using these commands to complete the deployment tasks.

Deployment prerequisites

Dell Technologies assumes that the management services that are required for the operating system deployment and Azure Local instance configuration are in the existing infrastructure where the instance is being deployed.

The following table describes the management services:

Management services. Management services
Management service	Purpose	Required or optional
Active Directory	User authentication	Required only for AD-based deployments.
Domain Name System	Name resolution	Required
Azure	Deploy and manage	Required
DHCP	Hosts get IPs before and after host configuration using Network ATC	Optional

Install Windows Admin Center

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.

NOTE: The automatically generated self-signed certificate expires in 60 days. If you intend to use Windows Admin Center in a production environment, ensure that you use a certificate-authority-provided SSL certificate.

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.

Windows Admin Center All connections window

Install Dell OpenManage Integration with Microsoft Windows Admin Center

To install Dell OpenManage Integration with Microsoft Windows Admin Center (OMIMSWAC), do the following:

Before you begin

Ensure that you have Windows Admin Center installed.

NOTE: Dell Technologies recommends that you ensure that you have installed the latest online version of the OMIMSWAC extension, which contains the latest published OMIMSWAC payload.

Procedure

In Windows Admin Center, go to Settings > Extensions.
Under the Available extensions tab, select and install Dell OpenManage Integration.
When it is installed, you can access OMIMSWAC on the left panel on the cluster manager under Extensions.

Registering a Partner Admin Link (PAL) for Azure related solutions

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).

NOTE: Adding a Dell Partner ID to the Service Principal associates Dell to the customer entity, which is persistent. This means that changes in customer system administrators do not break this association.

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.

Add a PAL through the Azure portal by using PowerShell

Dell Technologies recommends that you use the Azure portal and PowerShell with the Service Principal user ID to register the Partner Admin Link (PAL).

Before you begin

Before you begin, install the Microsoft Azure CLI extension to your local system where you run the registration. Run the following command:

az extension add --name managementpartner

NOTE: The CLI-based update is audit-log tracked.

To add a PAL to a customer account, do the following:

Procedure

To log in to the customer tenant, in Azure CLI, run the following command:

az login --service-principal -u <app-id> -p <password-or-cert> --tenant <tenant>

To link the Dell Partner ID, run the following command and add the partner ID from the list in Dell Technologies Partner IDs for Partner Admin Link.
Example: az managementpartner create --partner-id 913990
```
az managementpartner create --partner-id <Partner ID>
```
The following figure shows an example of a completed registration in Azure CLI.

Successful addition of Partner ID to customer tenant

Alternatively, you can verify the registration, either using the following CLI command or in the Azure portal. This command displays a similar output to the az managementpartner create command used in the previous step.

az managementpartner show

NOTE: If there is an error when you add the Dell Partner ID, use the following command to correct the registration:

az managementpartner update --partner-id <Partner ID>

Results

The PAL is now registered.

Add a PAL through the Azure portal using the subscription user ID

You can register the Partner Admin Link (PAL) with the subscription user ID through the Azure portal.

NOTE: Portal-based registrations tie the PAL association with the customer user entering the information. If the customer user changes roles, the portal-based PAL association also ends.

The portal-based update is not audit-log tracked, while the CLI-based update is tracked.
If possible, Dell Technologies recommends that you use the user ID associated with the Service Principal for PAL registration.

To add a PAL to a customer user account using the subscription user ID, do the following:

Procedure

Go to the Microsoft Azure portal and log in to the customer environment.
From the menu bar, click the Settings icon.

Settings icon above menu

From Portal Settings, under Useful links, select Microsoft partner network.

shows the Microsoft partner network link in the Portal Settings window in the Useful links list

NOTE: If multiple directories are listed, confirm the Azure tenant, and then use the tenant that is associated with Arc registration.

In the Link to a partner ID view, for the Microsoft partner ID, enter the Microsoft Partner Network (MPN) identifier that is associated with the country of the engagement. The available country MPNs are listed in the table in Dell Technologies Partner IDs for Partner Admin Link.

Microsoft partner ID field
To activate it, click Link to a partner ID.
The PAL is now registered.

Dell Technologies Partner IDs for Partner Admin Link

The following table provides a list of Microsoft Partner Network (MPN) partner IDs for Dell Technologies that can be used for Partner Admin Link (PAL) registration with Microsoft.

NOTE: For a country whose MPN partner ID is not listed in the following table, contact the applicable Strategic Partnerships email for help:

Dell Technologies MPN partner IDs for PAL use. Dell Technologies list of MPN Partner IDs for PAL use
Country	MPN ID
Argentina	1973856
Australia	1576776
Austria	1444496
Belgium	1447258
Brazil	1563635
Canada	742767
Chile	2389235
China	2580218
Colombia	1736279
Czech Republic	1980606
Denmark	1449600
Finland	1993462
France	892181
Germany	1449416
Greece	3679221
Hong Kong Sar	2790298
India	2419713
Indonesia	2834572
Ireland	1447272
Italy	1446223
Japan	578508
Korea	2153293
Malaysia	2731874
Mexico	724848
Netherlands	1446198
New Zealand	1872429
Norway	1446238
Panama	1477223
Poland	3697305
Portugal	1552205
Romania	1735552
Russia	4543982
Singapore	2773797
Slovakia	3812320
South Africa	1970176
Spain	1004323
Sweden	1449417
Switzerland	1449592
Taiwan	5097219
Thailand	2345177
Turkey	3396579
United Arab Emirates	3159758
United Kingdom	1447267
United States	913990

Predeployment configuration

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.

Configuring network switches

Top-of-rack (ToR) switches that are used in Azure Local instance deployments and that forward RDMA storage-network traffic must be listed in the Azure Local ToR switch list on the following Microsoft page: Physical network requirements for Azure Local > Network switches for Azure Local.

NOTE: For deployments with ToR switches that are not listed, you must use the switchless storage-network deployment option.

To enable storage and VM or management traffic, you can configure the top-of-rack (ToR) network switches based on the selected network topology.

Management network redundancy is a combination of either iDRAC or operating system DNS/IP resolution.

NOTE: Dell Technologies recommends that you deploy a network topology that supports a dual-control plane while sharing a single-data plane. Virtual Link Trunking (VLT) is a Dell Technologies proprietary technology that provides network resiliency for data I/O.

You should size any solution before making a decision on the bandwidth of the SMB switch to be used.

NOTE: If you are using an All-Flash or All-NVMe solution, Dell Technologies recommends that you use 25 GbE or higher switches for SMB traffic.

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 back-up 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.

For Dell Enterprise SONiC for Azure Local networking requirements and configuration support, see Dell Technologies Enterprise SONiC with Azure Local.

Configuring iDRAC and BIOS

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

NOTE: Dell Technologies recommends that you verify that the settings you want to use for iDRAC and BIOS align with the configuration recommendations. You can do this verification either before deployment through the iDRAC and BIOS settings or after deployment through the Compliance window in the Dell OpenManage Integration extension.

CAUTION: Do not enable the Automatic Update feature in iDRAC or manually perform out-of-band component firmware updates through iDRAC. All firmware, BIOS, and drivers must align with the Support Matrix and be applied strictly through supported update workflows.

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.

NOTE: For more details about BIOS and iDRAC settings, see BIOS and iDRAC configuration recommendations.

Verify iDRAC pass-through IP address subnet mask on AX-670 and AX-770 servers

Verify and configure the OS to iDRAC Pass-through USB NIC subnet mask on 17th-generation servers, including Dell AX-670 and Dell AX-770, to ensure proper in-band communication between the host operating system and Integrated Dell Remote Access Controller (iDRAC).

To verify the correct setting of the USB NIC, do the following:

Procedure

Log in to iDRAC
Go to iDRAC Settings > Connectivity > Network > OS to iDRAC Pass-through.
The OS to iDRAC Pass-through window is displayed.
If USB NIC Subnet Mask is not already set to 255.255.255.0, change the field to this value.
Click Apply.
To confirm that the IP is accessible and the link is established between iDRAC and the host operating system, click Test Network Configuration.

Configure BIOS settings including the IPv4 address for iDRAC

Perform these steps to configure the IPv4 address for iDRAC. You can also perform these steps to configure any additional BIOS settings.

Procedure

During the system boot, press F2.
At System Setup Main Menu, press iDRAC Settings.
Under iDRAC Settings, select Network.
Under IPV4 SETTINGS, at Enable IPv4, select Enabled.
Enter the static IPv4 address details.
Click Back, and then click Finish.

Configure Intel E810 or E823 NICs

The Intel E810 or E823 network adapter supports both iWARP and RoCE v2 RDMA protocols.

Before you begin

Ensure that the network card or port is enabled for RDMA traffic.

To configure the Intel E810 or E823 network adapter for each port, do the following:

Procedure

During system startup, to enter system setup, press F2 and then select Device Setting.
From the list of adapters, select Intel network adapter.
Click Device Level Configuration.
(Optional) Set Virtualization Mode to SR-IOV to enable the prerequisite capability that allows tenant virtual machines to use the Azure Accelerated Networking option.
Click Back.
In the Main Configuration window, for NIC + RDMA Mode select Enabled.
To save the settings, select Back > Finish > Yes.
To return to the Device Settings window, click Yes.
Select the next port of the Intel adapter and repeat the previous steps.
To return to the System Setup window, click Finish.
To reboot the system, click Finish.

Configure NVIDIA (Mellanox) ConnectX-6 NICs

To enable support for SR-IOV in the operating system and virtual machines, you must configure the NVIDIA (Mellanox) ConnectX-6 NICs for each port.

Before you begin

Ensure that the network card or port is enabled for RDMA traffic.

To configure the NVIDIA (Mellanox) ConnectX-6 NIC (network adapter), do the following:

Procedure

During system startup, to enter the system setup, press F2, and then select System Setup.
Select Device Settings.
From the list of adapters, select NVIDIA ConnectX-6 adapter.
NIC+RDMA is set to Enabled.
Click Device Level Configuration.
(Optional) Set Virtualization Mode to SR-IOV to enable the prerequisite capability that allows tenant virtual machines to use the Azure Accelerated Networking option.
To return to the main configuration window, click Back. To save your changes, on the main configuration page, click Finish.
Repeat the steps for all NVIDIA adapters.

Configure Broadcom NICs

The Broadcom 57504 and 57416 NICs support only RoCE v2 RDMA protocol and can be configured on both converged and hyperconverged deployments. Both OCP and PCIe cards are available.

Before you begin

Ensure that the network card or port is enabled for RDMA traffic.

To configure the Broadcom NIC for each port, do the following:

Procedure

During system startup, to enter System Setup, press F2, and then select Device Settings.
From the list of adapters, select Broadcom network adapter.
Select Device Level Configuration, and from the menu choose the DCBX Mode option, and then choose Enabled (IEEE Only).
(Optional) Set Virtualization Mode to SR-IOV to enable the prerequisite capability that allows tenant virtual machines to use the Azure Accelerated Networking option.
Click Back.
In the Main Configuration window, set NIC + RDMA Mode to Enabled. To save the settings, click Finish.
To return to the Device Settings window, click Yes.
Select the next port of the Broadcom adapter and repeat the previous steps.
To return to the System Setup window, click Finish.
To reboot the system, click Finish.

Operating system deployment

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 for each physical machine in the infrastructure that is part of the Azure Local instance.

NOTE: Before creating a cluster through the Azure Portal, for Azure Stack HCI OS version 24H2 and later, you must use Dell Golden image ISO for all deployments .

Manually deploy operating system using Dell golden-image ISO

You must use a Dell provided Azure Local golden-image ISO to install the baseline operating system image for Azure Local instances.

The golden image includes the Azure Stack HCI operating system, Microsoft operating system image customization, Azure Arc extensions, LCM service, registration modules, and Dell customization. Customization includes device drivers that align with the Dell support matrix for Azure Local.

For an Azure Local solution version 2503 and later, you must use a Dell provided Azure Local golden-image ISO. To download the latest Dell provided golden-image ISO, go to Azure Local Support Matrix, and then click Azure Local Support Matrix (Version X) > Azure Local Golden Images (Version X).

NOTE: To access any of the Dell provided Azure Local golden-image ISOs, you must have a Dell Support account.

Before you begin

Before you deploy the Azure Local instance using the Azure Portal or an ARM template, you must install the golden-image ISO on all machines that are part of the Azure Local instance. You can use the iDRAC virtual media feature to mount the golden-image ISO.

Procedure

Open the iDRAC interface for the node and re-create the virtual disk on the BOSS-N1 controller where the host operating system is located. If the BOSS virtual disk is in a good state, you can choose to clean the drive, install the operating system on it, and then go to step 2.
Optionally, if the existing BOSS virtual disk is degraded, you can do the following:
1. Delete the virtual disk on the BOSS. For more information, see Dell Boot-Optimized Storage Solution-N1 User's Guide.
2. Create a virtual disk on the BOSS and initialize it. For more information, see Dell Boot-Optimized Storage Solution-N1 User's Guide.
Open iDRAC virtual console and mount the golden-image ISO.
Boot the system from the golden-image ISO. Because no other operating system is installed on the host, it should automatically boot from the ISO without requiring you to select a boot device.

For more information, see PowerEdge: How to use the Virtual Media Function on iDRAC6, iDRAC7, iDRAC8, and iDRAC9 or see the topic Deploying operating system using virtual media at iDRAC10 Version 1.20.xx User's Guide > Installing operating systems.

Image the server using the procedure in Install the Azure Stack HCI operating system.

NOTE: You must delete any previously created partitions on the boot drive during the deployment procedure.

CAUTION: Do not enable the Automatic Update feature in iDRAC or manually perform out-of-band component firmware updates through iDRAC. All firmware, BIOS, and drivers must align with the Support Matrix and be applied strictly through supported update workflows.

Automated firmware updates after Azure Local server imaging

Explains how firmware is automatically updated after server imaging by using Dell-provided Azure Local golden images.

Overview

Dell-provided Azure Local golden images include the capability to update server firmware automatically after server imaging completes. This capability is available in golden images that are released with Microsoft Azure Local Solution version 2610 and later.

Firmware updates begin automatically after the imaging process completes. The duration of the update process depends on the firmware components that require updating. During the update process, the server may reboot multiple times because firmware updates are applied during reboot operations.

Dell provides a PowerShell monitoring script that reports the status of the automated firmware update process from the host operating system while the operating system is running.

NOTE: Automated firmware updating replaces the requirement to use OMIMSWAC to update server firmware before Azure Local instance deployment.

Automated firmware updates workflow

The automated firmware update process consists of the following:

Image the server with a Dell-provided Azure Local golden image.
Allow the automated firmware update process to start.
Monitor firmware update progress.
Verify successful completion.
Continue Azure Local instance deployment.

Monitor automated firmware updates after server imaging

Describes how to monitor firmware updates that run automatically after imaging a server with a Dell-provided Azure Local golden image.

Before you begin

Before monitoring automated firmware updates, ensure that the following requirements are met:

Server imaging is completed by using a Dell-provided Azure Local golden image.
The server is accessible through the host operating system.
You can log in to the host operating system by using an account with administrative privileges.

After a server is imaged by using a Dell-provided Azure Local golden image, firmware updates start automatically. Use the Clusterless CAU monitoring script to track the progress of the firmware update operation and verify that it completes successfully.

Procedure

Sign in to the server after the imaging process completes.
To open a PowerShell session, in SConfig, enter 15 - Exit to Command Line.
To monitor the firmware update status, run the following script in a PowerShell session:
```
C:\Dell\Scripts\PreDeploy\Invoke-MonitorClusterlessCau.ps1
```
Rerun the script until the Clusterless CAU operation reports a successful completion status.

If the server reboots during the monitoring process, restart the monitoring script.

Results

The firmware update status is monitored until the automated update process completes.

Clusterless CAU status reference for automated firmware updates

Lists the status values reported by the automated firmware update monitoring script and the required administrator actions.

Automated firmware update monitoring script status values. The following table lists the status values reported by the automated firmware update monitoring script and the required administrator actions.
Status	Description	Required action
RunNotInProgress	Clusterless CAU is not running.	Wait a few seconds and rerun the firmware update monitoring script.
Scanning	Clusterless CAU is running and scanning the system.	Continue monitoring the script output. The status refreshes every 15 seconds.
Installing	Clusterless CAU is running and installing firmware updates.	Continue monitoring the script output. The status refreshes every 15 seconds.
Unknown	Clusterless CAU is no longer running and is transitioning to a final state.	No action is required. The monitoring script reports the result of the previous Clusterless CAU operation after a short delay.
Succeeded	Clusterless CAU completed successfully.	Firmware updating is complete. Proceed to the next Azure Local deployment task.
Failed	Clusterless CAU completed unsuccessfully.	Review the iDRAC Lifecycle Log and apply the required remediation.

Configure host networking

Identify the network interface cards to be used for the management or compute traffic and assign the IP address to the first port.

Before you begin

NOTE: If you have a DHCP server in your environment, skip the procedure.

Ensure that the hosts are assigned IPs in the correct VLAN.

NOTE: The host IP, DNS, and gateway addresses that are used throughout the guide are examples. You must use the relevant IPs that are based on your environment.

NOTE: You can use the optional 1_AzLocal.ps1 script from Dell ProSupport GSE on GitHub to automate the operating-system configurations for host networking, rename the system name, and register with Azure. You must still do firmware updates before the deployment. Dell Technologies Solutions Engineering has not validated this code. Use at your own risk.

To log in to the host console of each system using the iDRAC virtual console and assign host IPs and respective VLANs, do the following:

Procedure

To disable the DHCP on all management adapters (NICs) except the NDIS NIC, run the following command:

Get-NetAdapter | Where-Object {$_.InterfaceDescription -NotMatch 'NDIS' } | Set-NetIPInterface -Dhcp Disabled

To disable disconnected network interface controllers, run the following command:

Get-NetAdapter | Where-Object {$_.status -eq "disconnected"} | Disable-NetAdapter

To assign the management IP address to the first port, run the following command:

New-NetIPAddress -InterfaceAlias "Integrated NIC 1 Port 1-1" -IPAddress 192.168.10.11 -DefaultGateway 192.168.10.1 -PrefixLength 24 -AddressFamily IPv4 –Verbose

To set DNS IP addresses, run the following command:

Set-DnsClientServerAddress -InterfaceAlias "Integrated NIC 1 Port 1-1" -ServerAddresses 192.168.11.50, 192.168.11.51

To assign VLAN ID for the management adapters, run the following command:

NOTE: If the management network has any untagged VLANs that are configured in the switch, then this step is not required.

Get-NetAdapter -Name "Integrated NIC 1 Port 1-1" | Set-NetAdapter -VlanID 202 -Confirm: $false

Get-NetAdapter -Name "Integrated NIC 1 Port 2-1" | Set-NetAdapter -VlanID 202 -Confirm: $false

Configuration to prepare nodes

To allow the issuing of remote commands to nodes that are not in the domain, run the following command on each node:

#Enable Remote Desktop
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" -Value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop" 

#Configure time source using NTP server FQDN address 
w32tm /config /manualpeerlist:"<NTP Server 1 FQDN> <NTP Server 2 FQDN>" /syncfromflags:manual /update

#Check time source
w32tm /query /status 

#Optionally configure the machine to accept remote management and allow pings for troubleshooting purposes. 
 
#Enable ICMP firewall rule
netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in action=allow

Change the hostname

By default, the operating-system deployment assigns a random name as the host system name. For easier identification and uniform configuration, Dell Technologies recommends that you change the hostname to something that is relevant and identifiable.

CAUTION: The computer and cluster names cannot be more than 15 characters. If the name exceeds the character limit, the deployment will fail when the system tries to encrypt the volume.

To change the hostname, run the following Rename-Computer command:

Rename-Computer -NewName Node01 -Restart

NOTE: The command induces an automatic restart at the end of the renaming operation.

Verify and update firmware and software compliance

Dell AX System for Azure Local solutions are validated and certified with firmware versions that are related to the solution infrastructure components.

Before you begin

To ensure that the solution infrastructure remains supported and delivers optimal performance, and to avoid a partially installed SBE 4.0.0.0 version, use the validated firmware and software that is specified in the Azure Local Support Matrix.

You can verify compliance and update the machines with an Azure Stack HCI online or offline catalog by using Dell OpenManage Integration with Windows Admin Center (OMIMSWAC).

NOTE: To update the firmware using OMIMSWAC, the local admin credentials on the Windows Admin Center system and target machines must be the same and should be a member of the administrator group.

NOTE: This procedure applies only to Dell Azure Local golden images released before Azure Local version 2609. Golden images released with version 2609 and later automatically update firmware during server imaging and do not require firmware updates through OMIMSWAC before Azure Local deployment.

To check and update firmware using Windows Admin Center, do the following:

Procedure

In Windows Admin Center, in the left pane, click Add.
In the Windows Server tile, click Add.
Enter the machine name and click Add.
Under All connections, select the server, and then click Manage as.
Select use another account for this connection, and then provide the credentials in the hostname\username format.
Click Confirm.
In the Connections window, click the server name.
In Windows Admin Center, in the left pane, under EXTENSIONS, click Dell OpenManage Integration.
To accept the terms of the license agreement, review the Dell Software License Agreement and Customer Notice and then select the checkbox.
Click View > Compliance. When another menu appears, select Hardware Updates.
Click Check compliance, and then select either online catalog or offline catalog.
To update the machine, click Fix Compliance, and then select update.

Example

Alternatively, you can use the Dell DART script available on GitHub from DellProSupportGse/Tools to update each node before deployment. This script is not validated by Dell Engineering and should be used at your own discretion.

Assess environment readiness

To use the Environment Checker tool in standalone mode to assess the readiness of your environment for deploying the Azure Local solution, see Evaluate the deployment readiness of your environment for Azure Local.

Configuring firewall settings

For Azure Stack HCI operating system, configure firewall settings for outbound endpoints and internal rules and ports. For more information about configuring the firewall settings, see Firewall requirements for Azure Local | Microsoft Learn.

Deploy Azure Local Instance with Azure Stack HCI OS 24H2 or later

Deployment prerequisites

Prerequisites

Review requirements and complete the deployment prerequisites that are described in Prerequisites to deploy Azure Local - Azure Local | Microsoft Learn are met.

NOTE: Ensure that you unmount any virtual media from the iDRAC.

Management services

Dell Technologies assumes that the management services that are required for the operating-system deployment and cluster configuration are in the existing infrastructure where the Azure Local instance is being deployed.

The following table describes the management services:

Management services. The table lists the required and optional management services and their purpose.
Management service	Purpose	Required or optional
Azure	Deploy and manage	Required
Active Directory	User authentication	Required only for AD-based deployments
Domain Name System	Name resolution	Required
DHCP	Hosts get IPs before and after host configuration	Optional

Review requirements

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.

Assigning required permissions for Azure Local deployment

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

Prepare Active Directory for Azure Local instance

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.

Register machines with Azure Arc

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.

NOTE: Manual installation of PowerShell modules is no longer required. The registration procedure changed with the introduction of golden images (10.2503) or Microsoft-provided composed images.

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

NOTE:

ProxyServer is an optional parameter while registering the machine with Azure Arc.
If you register machines without a proxy configuration, you must set the no_proxy environment variable to specify the proxy-bypass list.

(Optional) If you prefer to use a guided UI-based workflow instead of the Arc script, you can select the Via Configurator App tab on the Microsoft pages that are listed above.

NOTE: Dell Technologies has validated the registration of machines using the Configurator app. However, Dell Technologies does not officially support this functionality. If users encounter any issues, they must contact Microsoft directly.

Drift detection for Azure Local

For identifying configuration related deviations or troubleshooting issues in your Azure Local environment, see Drift Detection for Azure Local. You can run drift detection either before or after the cluster is created.

Check Azure Arc registration after reboot

During Azure Arc registration, when the update phase completes, if the system reboots, check the Arc registration status on the system after the reboot completes.

When registering Azure Arc on machines that are imaged with a specific Golden image (operating system customization 12.2506.0.3136), a required update triggers a reboot.

To check the Azure Arc registration, do the following:

NOTE: If you are using the latest Dell Golden-image ISO, you can ignore the following message if the message appears during the ARC registration process: "You are not running the latest Azure Local version. Older versions can only be deployed using the ARM template. Deployment using the Azure Portal cloud wizard is not supported."

Procedure

To monitor the reboot registration status, run the following command:
```
(Get-ArcBootstrapStatus).Response.Status
```
If the system completes registration and returns a status of:
- Succeeded, no further action is required.
- Failed, rerun the Invoke-AzStackHciArcInitialization command.

(Optional) After a successful registration, run azcmagent.exe on the Azure Local machine.

# Expect a status of Connected and a recent Last Heartbeat

azcmagent.exe show 'Agent Status' 'Agent Version' 'Agent Last Heartbeat'
Sample output
Agent Version: 1.58.03228.2572
Agent Status: Connected
Agent Last Heartbeat: 2026-01-27T14:49:58Z

SBE package installation

When you use the Dell provided golden image to image a node, the SBE files are automatically placed in the C:\SBE directory. The SBE package is installed as part of the cluster deployment.

Deploy the Azure Local instance

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.
You can deploy an Azure Local rack aware cluster through the Azure portal UI by using a workflow similar to a standard cluster deployment with a dedicated storage network intent. Alternatively, you can deploy it by using an ARM template designed specifically for rack aware cluster deployments.
You must deploy an Azure Local rack aware cluster with four (2+2), six (3+3), or eight (4+4) total machines.

Deploy Azure Local Instance using Azure portal

Describes the Azure portal deployment workflow for creating an Azure Local instance.

The Azure portal deployment wizard provides a guided workflow for creating and configuring an Azure Local instance. During deployment, you define cluster, networking, management, security, and storage settings before validating and deploying the instance.

You can deploy either of the following cluster types:

Standard cluster
Rack-aware cluster

The deployment workflow consists of the following stages:

Configure deployment basics
Configure deployment settings
Configure networking
Configure management settings
Configure security settings
Configure advanced settings
Apply tags (optional)
Validate deployment readiness
Deploy the Azure Local instance

Configure deployment basics for an Azure Local instance

Configure subscription, cluster, storage, identity, and machine settings for an Azure Local deployment.

Procedure

In the Azure portal, go to Home > Azure Local.
Under Get Started, in Deploy Azure Local, select Create instance.
Specify the Subscription name, Resource group, and Instance name.
Under Cluster options, select either Standard or Rack aware.
Under Storage options, select Storage Spaces Direct (S2D).
Under Identity provider for cluster, select Active Directory.

Select the machines to be added to the cluster and click Add machines.

NOTE: Before deployment, the machines must not be joined to Active Directory.

The required extensions are automatically installed during this step.

When the extensions are installed and the status shows as Ready, click Validate selected machines.

Validating machines

Click Create a new key vault, as shown in the following figure.

NOTE:

If a previously created key vault for a decommissioned cluster exists with the same name, the previous key vault must be deleted and purged first.
Azure Local does not support deploying a cluster by using an existing Azure key vault that has private endpoints enabled.

"Create a new key vault" window with details of key vault

Click Create.
Click Next: Configuration.

The following figure shows an example of a cluster with four machines:

Example of four-machine cluster details

For more information, see Start the wizard and fill out the basics.

Configure deployment settings for an Azure Local instance

Configure deployment settings for the Azure Local instance.

Procedure

To enter details for the Azure Local instance, select New Configuration.
For more information, see Specify the deployment settings.
Click Next: Networking.

Configure networking for an Azure Local instance

Configure network topology, network intents, and IP address allocation.

Procedure

To specify the network settings, choose the networking pattern that is based on your network topology. For a two- machine Azure Local instance, you have two options for storage connectivity:
- No switch for storage
- Network switch for storage
To deploy a two- machine Azure Local instance with No switch for storage, see Azure Portal-Based Deployment and Operations Guide with Switchless Networking.
To deploy an Azure Local instance with Network switch for storage, continue the workflow. Choose between the following options:
- Group all traffic: If you are configuring a fully converged network topology, choose this option.
- Group management and compute traffic: If you are configuring a nonconverged network topology with management and compute traffic on one intent and storage traffic on physical network adapters, choose this option.
The following figure shows an example of deploying a converged network configuration with storage traffic on physical network interface controllers:

Networking window showing selected option
Enter details for the network intents or NIC, as shown in the following figure.

Enter network intent details

To update the Data Center Bridging setting and Adapter properties such as Jumbo frame size (bytes) and RDMA protocol, click Customize network settings on each network intent and, if applicable, NIC.

CAUTION: For management network intents, RDMA must be disabled. Set the frame size to 1514 for the management intent.

For storage network intents, you can select RDMA from the available options. Dell Technologies recommends RoCEv2 for Mellanox network cards and either iWARP or RoCEv2 for Intel network cards. Select 9014 as the Jumbo frame size for the storage intent.

NOTE: If you have Intel E810 or E823 cards, you can choose between iWarp or RoCE protocols for SMB Direct traffic that is based on your data-center standards. Dell Technologies does not have a recommendation on using one over the other.

The following table shows the Quality of Service (QoS) flow priorities for each network type:

QoS priorities for network intents. The table shows the QoS flow priorities that are based on traffic class for each network type.
Traffic class	Purpose	QoS flow	ETS bandwidth allocation
3	RDMA (SMB Direct)	Enabled	50 percent
7	Cluster network	Disabled	10 GbE equals 2 percent Greater than 25 GbE equals 1 percent
0-2, 4-6	0 - Best-effort traffic	Disabled	Remaining percentage distributed across the traffic classes

The following figure shows an example of setting customized network values for the storage intent:

NOTE: For new Azure Local instance deployments, the cluster System traffic priority can be configured as '7' instead of '5'. Similarly, the switch configuration must reflect the same cluster System traffic priority value.

To enter an IP address pool for the system and services, from the options, choose Manual. Enter the required details, as shown in the following figure:

For more information, see Specify network settings.

NOTE: The DNS server address cannot be changed after deployment.

Configure management settings for an Azure Local instance

Configure the custom location, deployment account, Active Directory settings, and witness configuration.

Procedure

To identify the system when creating resources, Active Directory details, and Deployment account details, under Specify a custom location name, enter the location name, as shown in the following figure:

Management window
For an Azure Local instance with two- machine, you must create a storage account. To create a storage account, click Create New.

In the Create a storage account window, enter a storage account name, and select the region and redundancy. To create the storage account, click Create, as shown in the following figure.

Window showing fields where you enter an account name and selecte the region and redundancy settings

NOTE: A cluster witness is mandatory for an Azure Local instance with two- machines. Dell Technologies recommends a cluster witness for a Azure Local instance with four- machines.

For more information, see Specify management settings.

Continue to specify Active Directory and deployment account details.
Click Next: Security.

Configure security settings for an Azure Local instance

Configure deployment security settings for an Azure Local instance.

Procedure

To configure security settings, choose one of the following options, as shown in the following figure:

Recommended security settings: Sets the highest security settings.
Customized security settings: Allows you to turn off security settings.

Recommended security setting options with a description of each included

Customized security setting options with a description of each included

NOTE: For maximum security, choose Recommended security settings.

For more information, see Set the security level.

Click Next: Advanced.

Configure advanced settings for an Azure Local instance

Configure advanced settings for an Azure Local instance.

Procedure

Click the Advanced tab.
Under Create workload and infrastructure volumes, choose Create one workload volume and storage path per machine, and one required infrastructure volume per system (Recommended).

Choosing volumes

Choosing volumes
For Rack aware deployments:
1. Specify a local availability zone name for each zone.
2. Select the machines assigned to the first availability zone. The system automatically assigns the remaining machines to the second availability zone.
3. Use descriptive zone names that reflect the physical location of the machines to make management easier in the Azure portal.
Choosing volumes

For more information, see Optionally change advanced settings and apply tags.
Select Next: Tags.

Apply tags to an Azure Local instance

Apply metadata tags to Azure Local deployment resources.

Procedure

Optionally add a tag to the Azure Local resource in Azure.

Tags are name/value pairs you can use to categorize resources.
Enter the required tag names and values.
Select Next: Validation.

Validate deployment readiness

Validate deployment settings and verify readiness before deployment.

Procedure

Create an Azure Local instance resource object and its components.
Validate the system readiness for an Azure Local instance deployment, as shown in the following figure

Validation of system readiness

For more information, see Validate and deploy the system.
Click Next: Review + create.

Deploy the Azure Local instance and monitor deployment status

Review deployment settings and start the Azure Local deployment.

To view all configuration information and then create the Azure Local instance, do the following:

Procedure

After the system verifies the settings, click Review + create.
The Azure Local instance deployment starts. For more information, see Validate and deploy the system.
To view the deployment progress in the Azure portal, go to < Azure Local instance name> > Deployments.
To see the latest status, click Refresh. When the deployment is complete, the status for all tasks shows as Success, as shown in the following figure:

Deployment status
To access the Azure Local instance remotely or from Windows Admin Center, enable remote desktop access:
1. Use the iDRAC console to log in to the machine.
2. If not already open, run the sconfig command.
3. Choose one of the following options:
  - For Remote Desktop, select option 7.
  - To enable RDP, choose option 1.
4. To allow only NLA-secured clients, choose option 1 again.

Deploy Azure Local Instance using Microsoft ARM templates

Deploy an Azure Local instance using the Microsoft Azure Resource Manager (ARM) template.

Before you begin

Before using the Microsoft Azure Resource Manager (ARM) template to deploy an Azure Local instance, you must complete the prerequisite procedures. Procedures are correct at publication but are subject to change without notice. For the most current details, see Deploy Azure Local via Azure Resource Manager deployment template > Prerequisites.

For more information about creating a service principal, service secret, and client secret for Azure Local release 2507 onwards, see Deploy Azure Local via Azure Resource Manager deployment template.

To deploy an Azure Local instance using the ARM template, do the following:

NOTE: Procedures are correct at publication but are subject to change without notice. For the most up-to-date details, see Deploy an Azure Local via Azure Resource Manager deployment template.

Procedure

In the Azure portal, from Home, click Create a Resource.
Click Template deployment (deploy using custom templates) .
Under Start with a quickstart template or template spec, choose Quickstart template.

Custom deployment window > Select a template
For a standard cluster deployment, from the Quickstart template list, choose quickstarts/microsoft.azurestackhci/create- cluster, and then click Select template. For a rack aware cluster deployment, from the Quickstart template list, choose quickstarts/microsoft.azurestackhci/create-cluster-rac-enabled, and then click Select template.
From the Basics tab, select the resource group where the Arc-enabled servers are registered for the deployment.
Select Region, and then, in Deployment Mode, select Validate.
Enter the Key Vault Name, Diagnostic Storage Account Name, and Cluster Name.

Select Witness Type, and then enter cluster Witness Storage Account Name.

NOTE: For a two- machine cluster, a witness is mandatory.

Enter Local Admin and Azure Stack LCM Admin credentials.
Enter the Azure Stack HCI Resource Provider Object ID from information collected in Prerequisites.
To collect Arc Machine Resource IDs, run (Get-AzConnectedMachine -ResourceGroupName "<your-resource-group>").Id on one of the machines. Enter the details in Arc Machine Resource IDs.
Enter the Domain FQDN, Naming prefix, and Active Directory OU path.

Enter the following:

Subnet Mask
Default gateway
Starting IP address
Ending IP address
DNS Servers IP

NOTE: Azure Local deployment requires six IP addresses for the system and services.

Under Physical Machine Settings, enter the Hostname and IP addresses for the machines, for example:
[{"name":"machine1","ipv4Address":"172.18.30.1"},{"name":"machine2","ipv4Address":"172.18.30.2"}]
Under Networking type, select the following:
- For a single-server deployment, select SingleServerDeployment.
- For a two or more machine cluster deployments , select SwitchedMultiServerDeployment.
  - This networking type is required for a rack aware cluster deployment.
- For a two-machine switchless cluster deployment, select SwitchlessMultiServerDeployment.
Under Networking Pattern, choose one of the following options:
- Select Hyperconverged to Group all traffic: If you are configuring a fully converged network topology, choose this option.
- Select ConvergedManagementCompute to Group management and compute traffic: If you are configuring a nonconverged network topology with storage traffic on physical network adapters, choose this option.
  - This networking type is required for a rack aware cluster deployment.
Set Storage Connectivity Switchless to:
- True for switchless networking
- False for switched networking

Click Edit Parameters.

NOTE: For an example of a parameter file that shows the format of various inputs, see azuredeploy.parameters.json on GitHub.

Edit Network intent details based on the network topology that you are using for the deployment.

The following table shows the Quality of Service (QoS) flow priorities for each network type:

QoS priorities for network intents. The table shows the QoS flow priorities that are based on traffic class for each network type.
Traffic class	Purpose	QoS flow	ETS bandwidth allocation
3	RDMA (SMB Direct)	Enabled	50 percent
7	Cluster network	Disabled	10 GbE equals 2 percent Greater than 25 GbE equals 1 percent
0-2, 4-6	0 - Best-effort traffic	Disabled	Remaining percentage distributed across the traffic classes

The following script shows an example of the multi- machine ConvergedManagementCompute network topology.

"intentList": {
      "value": [
        {
          "name": "Compute_Management",
          "trafficType": [
            "Management",
            "Compute"
          ],
          "adapter": [
            "Integrated NIC 1 Port 1-1",
            "Integrated NIC 1 Port 2-1"
          ],
          "overrideVirtualSwitchConfiguration": false,
          "virtualSwitchConfigurationOverrides": {
            "enableIov": "",
            "loadBalancingAlgorithm": ""
          },
          "overrideAdapterProperty": true,
          "adapterPropertyOverrides": {
            "jumboPacket": "1514",
            "networkDirect": "Disabled",
            "networkDirectTechnology": ""
          }
        },
        {
          "name": "Storage",
          "trafficType": [
            "Storage"
          ],
          "adapter": [
            "SLOT 5 Port 1",
            "SLOT 5 Port 2"
          ],
          "overrideVirtualSwitchConfiguration": false,
          "virtualSwitchConfigurationOverrides": {
            "enableIov": "",
            "loadBalancingAlgorithm": ""
          },
          "overrideQosPolicy": true,
          "qosPolicyOverrides": {
            "priorityValue8021Action_Cluster": "5",
            "priorityValue8021Action_SMB": "3",
            "bandwidthPercentage_SMB": "50"
          },
          "overrideAdapterProperty": true,
          "adapterPropertyOverrides": {
            "jumboPacket": "9014",
            "networkDirect": "Enabled",
            "networkDirectTechnology": "iWARP"
          }
        }
      ]
    },
    "storageNetworkList": {
      "value": [
        {
          "name": "StorageNetwork1",
          "networkAdapterName": "SLOT 5 Port 1",
          "vlanId": "711"
        },
        {
          "name": "StorageNetwork2",
          "networkAdapterName": "SLOT 5 Port 2",
          "vlanId": "712"
        }
      ]

For a rack-aware cluster deployment, the custer must be set to the value of RackAware and the local availability zone names and node name values must be entered.

"clusterPattern": {
  "value": "RackAware"
},
"localAvailabilityZones": {
  "value": [
    {
      "localAvailabilityZoneName": "LocalAvailabilityZone1",
      "nodes": ["Machine01", "Machine02"]
    },
    {
      "localAvailabilityZoneName": "LocalAvailabilityZone2",
      "nodes": ["Machine03", "Machine04"]
    }
  ]
},

Save the parameters file. Leave all remaining parameters set to their default values.
Select Review + create, and then click Create.
This step validates the deployment and creates the prerequisites that are required for the deployment.
When validation is complete, click Redeploy.
Select Edit parameters, load the parameter JSON file, and then click Save.
Select the Resource Group.
Change Deployment Mode from Validate to Deploy.
To begin the deployment, select Review + create, and then click Create.

To check the deployment progress, open a new browser window, go to the resource group, and then click the cluster resource. Go to Settings > Deployment, and then click Refresh .

NOTE: Deployment can take between 2.5 and 3 hours.

Deploy Azure Local using Local Identity with Azure Key Vault

This chapter describes the additional requirements, configuration differences, and deployment considerations for deploying an Azure Local instance using Local Identity with Azure Key Vault (also known as AD‑less deployment).

This chapter does not replace the standard Azure Local deployment workflow. Unless explicitly stated otherwise, all deployment steps follow the procedures that are described in:

Chapter 3: Solution Deployment
Chapter 4: Deploying Azure Local Instance with Azure Stack HCI OS, version 24H2 or later

About Local Identity with Azure Key Vault

Overview

Azure Local can be deployed without Active Directory by using a local identity model with Azure Key Vault, previously known as AD-less deployment. This deployment option is available starting with Azure Local version 2411 and later.

In a local identity deployment:

A dedicated local administrator account is used on each machine.
Certificate‑based authentication is configured cluster‑wide.
Azure Key Vault is used to securely back up secrets such as BitLocker keys and other critical configuration data that is required for secure cluster operation.

Benefits of local identity with Azure Key Vault (without Active Directory)

Minimal edge infrastructure: Enables secure identity and secret handling in environments that do not use Active Directory.
Secure secret store: Azure Key Vault stores sensitive items such as BitLocker keys and node passwords, reducing the risk of unauthorized access and improving overall security.
Simplified management: Consolidates deployment and local identity secrets in a single vault, making them easier to manage and retrieve.
Simplified deployment: Azure portal workflows store required secrets in Azure Key Vault, reducing reliance on Active Directory and helping simplify Operational Technology network firewall configurations.

Most deployment steps are identical for Active Directory–based Azure Local deployments and deployments that use local identity with Azure Key Vault. For more information, see Deploy Azure Local using local identity with Azure Key Vault.

Key differences from Active Directory–based deployments

Key differences between Active Directory–based and Local Identity–based Azure Local deployments. The following table summarizes the functional differences between Active Directory–based and Local Identity–based Azure Local deployments
Area	Active Directory deployment	Local Identity deployment
Identity provider	Active Directory	Local administrator account
Authentication	AD objects	Certificate‑based authentication
Secret storage	Cluster and AD	Azure Key Vault
Domain join	Required	Not supported
AD preparation	Required	Not applicable

Deployment prerequisites for Azure Local deployment using local identity

Dell Technologies assumes that the management services that are required for the operating system deployment and Azure Local instance configuration are in the existing infrastructure where the instance is deployed.

For more information, see Prerequisites for cluster deployment using local identity.

The following table describes the management services:

Management services. Management services
Management service	Purpose	Required or optional
Domain Name System	Name resolution	Required
DNS suffix	Enables workgroup cluster nodes to communicate using fully qualified domain names.	Required
Azure	Deploy and manage	Required
Static IP addresses for management	Assign IP addresses to hosts before and after host configuration using Network ATC	Required
New local non–built‑in user in the local Administrators group	Administrative user account for deployment and management	Required

Prepare Azure Local machines for Local Identity

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.

Local identity-specific machine configuration procedures

Create DNS A records for hosts and cluster

Create DNS A records for the hosts and cluster to enable name resolution for individual machines and the cluster name object (CNO).

For more information, see Configure DNS server for Azure Local.

Procedure

Create a DNS A record for each machine.
Create a DNS A record for the cluster name (CNO).
(Optional) Create PTR records.

Create a local user and add to the local Administrators group

Create a dedicated local administrative user on each Azure Local node for deployment and cluster management operations.

Before you begin

Azure Local deployments that use local identity require a non built-in local administrator account. This account is used for cluster-wide management operations, such as adding or repairing nodes, and must be consistent across all nodes in the Azure Local instance.

NOTE: You are responsible for life cycle management of this account, including expiration, rotation, and security. The default local policy sets a maximum password age of 42 days. This can be modified using PowerShell or by changing the underlying password policy configuration.

Use the same username and password on all machines. The password must meet Azure complexity requirements and include at least 14 characters with a combination of lowercase letters, uppercase letters, numbers, and special characters.

Procedure

On each Azure Local node, create a new local user account, and update the $AdminUser value accordingly.

NOTE: Do not use the built-in Administrator account.

# Create new dedicated user

$AdminUser = '<DedicatedAdminUser>'
# Sample data:
# $AdminUser = 'adless-admin'
$Credentials = Get-Credential -UserName $AdminUser -Message 'Enter password:'
$Description = 'Local AD-less user'
New-LocalUser -Name $AdminUser -Password $Credentials.Password -FullName $AdminUser -Description $Description

# Add user to local admin group
Add-LocalGroupMember -Group 'Administrators' -Member $AdminUser

# Optional: Validate the new user account
Get-LocalGroupMember -Group administrators
# The output should include the user account specified by $AdminUser. 
# If it is not listed, the account was not created or added successfully.

Deploy the Azure Local instance using local identity with Azure Key Vault

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.

Deploy Azure Local Instance with local identity using Azure portal

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:

Basics
Configuration
Networking
Management
Security
Advanced
Tags (optional)
Validation
Review and create

To create an Azure Local instance:

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

Step 1: Basics

Specify the Subscription name, Resource group, and Instance name.
Instance name = Cluster Name Object (CNO)
For Cluster options, select either Standard or Rack aware.
For Identity provider, select Local identity with Azure Key Vault.
Select the machines to be added to the Azure local Instance. Click Add machines.
The required extensions are automatically installed during this step.
When the extensions are installed and the status shows as Ready, click Validate selected machines.

Validating machines

Click Create a new key vault, as shown in the following figure.

NOTE:

If a previously created key vault for a decommissioned cluster exists with the same name, the previous key vault must be deleted and purged first.
Azure Local does not support deploying a cluster by using an existing Azure key vault that has private endpoints enabled.

Click Create.
Click Next: Configuration.

The following figure shows an example of a cluster with four machines:

For more information, see Start the wizard and fill out the basics.

Step 2: Configuration

To provide details for the Azure Local instance, select New Configuration. For more information, see Specify the deployment settings.
Click Next: Networking.

Step 3: Networking

To specify the network settings, choose the networking pattern that is based on your network topology. For a two- machine Azure Local instance, you have two options for storage connectivity:
- No switch for storage
- Network switch for storage
To deploy a two- machine Azure Local instance with No switch for storage, see Azure Portal-Based Deployment and Operations Guide with Switchless Networking.
To deploy an Azure Local instance with Network switch for storage, continue the workflow. Choose between the following options:
- Group all traffic: If you are configuring a fully converged network topology, choose this option.
- Group management and compute traffic: If you are configuring a nonconverged network topology with management and compute traffic on one intent and storage traffic on physical network adapters, choose this option.
The following figure shows an example of deploying a converged network configuration with storage traffic on physical network interface controllers:

Networking window showing selected option
Provide details for the network intents or NIC, as shown in the following figure.

Enter network intent details

To update the Data Center Bridging setting and Adapter properties such as Jumbo frame size (bytes) and RDMA protocol, click Customize network settings on each network intent and, if applicable, NIC.

CAUTION: For management network intents, RDMA must be disabled. Set the frame size to 1514 for the management intent.

For storage network intents, you can select RDMA from the available options. Dell Technologies recommends RoCEv2 for Mellanox network cards and either iWARP or RoCEv2 for Intel network cards. Select 9014 as the Jumbo frame size for the storage intent.

NOTE: If you have Intel E810 or E823 cards, you can choose between iWarp or RoCE protocols for SMB Direct traffic that is based on your data-center standards. Dell Technologies does not have a recommendation on using one over the other.

The following table shows the Quality of Service (QoS) flow priorities for each network type:

QoS priorities for network intents. The table shows the QoS flow priorities that are based on traffic class for each network type.
Traffic class	Purpose	QoS flow	ETS bandwidth allocation
3	RDMA (SMB Direct)	Enabled	50 percent
7	Cluster network	Disabled	10 GbE equals 2 percent Greater than 25 GbE equals 1 percent
0-2, 4-6	0 - Best-effort traffic	Disabled	Remaining percentage distributed across the traffic classes

The following figure shows an example of setting customized network values for the storage intent:

NOTE: For new Azure Local instance deployments, the cluster System Traffic Priority can be configured as '7' instead of '5'. Similarly, the switch configuration must reflect the same cluster System Traffic Priority value.

To provide an IP address pool for the system and services, from the options, choose Manual. Enter the required details, as shown in the following figure:

Allocate IP addresses

For more information, see Specify network settings.

Step 4: Management

To identify the system when creating resources and Deployment account details, under Specify a custom location name, enter the location name, as shown in the following figure:

Management window
For an Azure Local instance with two- machine , you must create a storage account. To create a storage account, click Create New.
In the Create a storage account window, enter a storage account name, and select the region and redundancy. To create the storage account, click Create, as shown in the following figure.

Create a storage account

Continue to specify Local Administrator details. Use the same account that was created earlier. See Create a local user and add to the local Administrators group. Do not use the built-in Administrator account.

NOTE: A cluster witness is mandatory for an Azure Local instance with two- machine. Dell Technologies recommends a cluster witness for a Azure Local instance with four- machines.

For more information, see Specify management settings.

Click Next: Security.

Step 5: Security

To configure security settings, choose one of the following options, as shown in the following figure:

Recommended security settings: Sets the highest security settings
Customized security settings: Allows you to turn off security settings

Security setting options with a longer description of each included

NOTE: For maximum security, choose Recommended security settings.

For more information, see Set the security level.

Click Next: Advanced.

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.

Choosing volumes
For Rack Aware deployments:
1. Specify a local availability zone name for each zone.
2. Select the machines assigned to the first availability zone. The system automatically assigns the remaining machines to the second availability zone.
3. Use descriptive zone names that reflect the physical location of the machines to make management easier in the Azure portal.
Select Next: Tags.

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

Step 7: Tags

After applying the optional tags, click Validation.

Step 8: Validation

Create an Azure Local instance resource object and its components.
Validate the system readiness for an Azure Local instance deployment, as shown in the following figure

Validation of system readiness

For more information, see Validate and deploy the system.
Click Next: Review + create.

Step 9: Review + create

This window shows all the configuration information that you have selected so far to create the Azure Local instance. To view all configuration information and then create the Azure Local instance, do the following:

After the system verifies the settings, click Review + create.
The Azure Local instance deployment starts.
For more information, see Validate and deploy the system.
To view the deployment progress in the Azure portal, go to < Azure Local instance name> > Deployments.
To see the latest status, click the Refresh icon.
When the deployment is complete, the status for all tasks shows as Success, as shown in the following figure:

Deployment status
To access the Azure Local instance remotely or from Windows Admin Center, enable remote desktop access:
1. Use the iDRAC console to log in to the machine.
2. If not already open, run the sconfig command.
3. Choose one of the following options:
  - For Remote Desktop, select option 7.
  - To enable RDP, choose option 1.
4. To allow only NLA-secured clients, choose option 1 again.

Deploy Azure Local instance with local identity using Microsoft ARM templates

Deploy an Azure Local instance using the Microsoft Azure Resource Manager (ARM) template.

Before you begin

Before using the Microsoft Azure Resource Manager (ARM) template to deploy an Azure Local instance, you must complete the prerequisite procedures. Procedures are correct at publication but are subject to change without notice. For the most current details, see Deploy Azure Local via Azure Resource Manager deployment template > Prerequisites.

For more information about creating a service principal, service secret, and client secret for Azure Local release 2507 onwards, see Deploy Azure Local via Azure Resource Manager deployment template.

To deploy an Azure Local instance using the ARM template, do the following:

NOTE: Procedures are correct at publication but are subject to change without notice. For the most up-to-date details, see Deploy an Azure Local via Azure Resource Manager deployment template.

Procedure

In the Azure portal, go to Home, and then click Create a Resource.
Under Template deployment (deploy using custom templates), click Create.
From the Start with a quickstart template or template spec, select Quickstart template as the template source.

Custom deployment window > Select a template
From the Quickstart template (disclaimer) list, select the Azure Local AD‑less cluster template, quickstarts/microsoft.azurestackhci/create-adless-cluster-external-dns-public-preview, and then click Select template.
On the Basics tab, select the resource group where the Arc-enabled servers are registered for the deployment.
Select Region, and then, in Deployment Mode, select Validate.
Enter the Key Vault Name, Diagnostic Storage Account Name, and Cluster Name.

Select Witness Type, and then enter cluster Witness Storage Account Name.

NOTE: For a two machine cluster, a witness is mandatory.

Enter Local Admin credentials.
Enter the Azure Stack HCI Resource Provider Object ID from information collected in Prerequisites.
To collect Arc Machine Resource IDs, run (Get-AzConnectedMachine -ResourceGroupName "<your-resource-group>").Id on one of the machines. Enter the details in Arc Machine Resource IDs.

Enter the following:

Subnet Mask
Default gateway
Starting IP address
Ending IP address
DNS Servers IP

NOTE: Azure Local deployment requires six IP addresses for the system and services.

Under Physical Machine Settings, enter the Hostname and IP addresses for the machines, for example:
[{"name":"machine1","ipv4Address":"172.18.30.1"},{"name":"machine2","ipv4Address":"172.18.30.2"}]
Under Networking type, select the following:
- For a single-server deployment, select SingleServerDeployment.
- For a two or more machine cluster deployments , select SwitchedMultiServerDeployment.
- For a two-machine switchless cluster deployment, select SwitchlessMultiServerDeployment.
Under Networking Pattern, choose one of the following options:
- Select Hyperconverged to Group all traffic: If you are configuring a fully converged network topology, choose this option.
- Select ConvergedManagementCompute to Group management and compute traffic: If you are configuring a nonconverged network topology with storage traffic on physical network adapters, choose this option.
Set Storage Connectivity Switchless to:
- True for switchless networking
- False for switched networking

Click Edit Parameters.

NOTE: For an example of a parameter file that shows the format of various inputs, see azuredeploy.parameters.json on GitHub.

Edit Network intent details based on the network topology that you are using for the deployment.

The following table shows the Quality of Service (QoS) flow priorities for each network type:

QoS priorities for network intents. The table shows the QoS flow priorities that are based on traffic class for each network type.
Traffic class	Purpose	QoS flow	ETS bandwidth allocation
3	RDMA (SMB Direct)	Enabled	50 percent
7	Cluster network	Disabled	10 GbE equals 2 percent Greater than 25 GbE equals 1 percent
0-2, 4-6	0 - Best-effort traffic	Disabled	Remaining percentage distributed across the traffic classes

The following script shows an example from the ARM template and demonstrates how the Local Identity (with Azure Key Vault) deployment differs from the Active Directory deployment. The configuration that is shown corresponds to one of the possible network patterns “convergedManagementCompute.”

For readability, unrelated sections are not shown and are marked with dots (....).

For more information, see Full Azure Local/Azure Stack HCI 'create-cluster' template and parameter examples that are published in the Azure Quickstart Templates GitHub repository.

…………………..
"parameters": {
        "apiVersion": {
            "value": "2025-09-15-preview"
        }
…………………..

 "identityProvider": {
            "value": "LocalIdentity"
        },
…………………..

 "dnsZones": {
            "value": [
                {
                    "dnsZoneName": "MyDNSserver.local.net",
                    "dnsForwarder": []
                }
            ]
        },
        "dnsServerConfig": {
            "value": "YourDnsServer"
        },
…………………..
       "intentList": {
            "value": [
                {
                    "name": "Compute_Management",
                    "trafficType": [
                        "Management",
                        "Compute"
                    ],
                    "adapter": [
                        "Integrated NIC 1 Port 1-1",
                        "Integrated NIC 1 Port 2-1"
                    ],
                    "overrideVirtualSwitchConfiguration": false,
                    "virtualSwitchConfigurationOverrides": {
                        "enableIov": "",
                        "loadBalancingAlgorithm": ""
                    },
                    "overrideQosPolicy": true,
                    "qosPolicyOverrides": {
                        "priorityValue8021Action_Cluster": "7",
                        "priorityValue8021Action_SMB": "3",
                        "bandwidthPercentage_SMB": "50"
                    },
                    "overrideAdapterProperty": true,
                    "adapterPropertyOverrides": {
                        "jumboPacket": "1514",
                        "networkDirect": "Disabled",
                        "networkDirectTechnology": ""
                    }
                }

Save the parameters file. Leave all remaining parameters set to their default values.
Select Review + create, and then click Create.
This step validates the deployment and creates the prerequisites that are required for the deployment.
When validation is complete, click Redeploy.
Select Edit parameters, load the parameter JSON file, and then click Save.
Select the Resource Group.
Change Deployment Mode from Validate to Deploy.
To begin the deployment, select Review + create, and then click Create.

To check the deployment progress, do the following:

Open a new browser window, go to the resource group, and then click the cluster resource.

Go to Settings > Deployment, and then click Refresh .

NOTE: Deployment takes between 2.5 and 3 hours.

Post-deployment tasks

Perform necessary post-deployment tasks including verifying BitLocker keys in Azure Key Vault, updating configurations, recovering deleted Key Vaults, and monitoring Key Vault integration health.

To verify BitLocker keys and recovery administrator passwords are securely backed up to Azure Key Vault, see Verify secrets back up to Key Vault.
To update a new Key Vault with configurations, see Update Key Vault on Azure Local.
To recover a deleted Key Vault and resume backups, see Recover a deleted Key Vault.
To monitor the health of Key Vault integration, see Alerts for Key Vault extension.

Management tool compatibility for Azure Local with Azure Key Vault

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

Management tools

The following table provides the management tools that are supported for Azure Local environments that use Azure Key Vault for identity management:

Management tools. Table lists the management tools compatibility for Azure environments that use Azure Key Vault for identity management.
Category	Tools	Notes
Supported	PowerShell Azure Monitor Azure portal	Fully supported for typical management and monitoring workflows.
Unsupported/Limited support	Windows Admin Center System Center Virtual Machine Manager (SCVMM)	Not supported or only partially supported - avoid relying on these as primary management tools.
Mixed compatibility	Microsoft Management Consoles (MMCs)	Compatibility varies by scenario. Some MMC tools such as Hyper-V Manager, and Failover Cluster Manager may not work in all the scenarios. Test critical workflows before using MMCs in production.

External SAN support for Azure Local

Explains how Azure Local integrates with external SAN storage and describes supported deployment architectures, storage protocols, and configuration workflows.

Overview

External SAN support enables hybrid deployments that combine Storage Spaces Direct (S2D) local storage with external SAN storage. This architecture allows organizations to reuse existing SAN investments while running Azure Local workloads.

The hybrid deployment model provides flexibility to place workloads on either local Storage Spaces Direct storage or external SAN storage based on performance, capacity, and operational requirements.

This documentation applies to post-deployment integration of external SAN storage with Azure Local clusters.

External SAN support deployment workflow

To integrate external SAN storage with Azure Local:

Review supported SAN solutions.
Verify system requirements.
Plan SAN integration.
Configure Fibre Channel or iSCSI connectivity.
Configure MPIO.
Verify SAN connectivity.
Create Cluster Shared Volumes.
Configure workload storage paths.
Validate operations.

For more information, see Enable External Storage on Azure Local.

Hybrid Deployment Architecture for Azure Local

Explains how Storage Spaces Direct and external SAN storage are used together in a hybrid Azure Local deployment.

Overview

A hybrid deployment combines local Storage Spaces Direct storage with external SAN storage.

In a hybrid deployment:

Compute nodes run the Azure Local operating system and host virtual machines.
Local storage is provided by Storage Spaces Direct.
External SAN storage is presented to cluster nodes through Fibre Channel or iSCSI.
Cluster Shared Volumes can consume storage from either Storage Spaces Direct or SAN LUNs.
Workloads allows choosing the right storage tier for each workload.

Benefits of using hybrid deployment architecture

Reuse existing SAN infrastructure.
Scale storage independently from compute.
Maintain existing SAN operational practices.
Provide enterprise-class performance and reliability.
Support dual-fabric redundancy and multipath failover.

Supported SAN solutions for Azure Local

Lists supported storage arrays and storage protocols for Azure Local external SAN deployments.

Supported storage vendors

Azure Local currently supports:

Dell PowerStore T appliances
Dell PowerStore Q appliances

NOTE: PowerStore systems must run PowerStoreOS version 3.0 or later.

Supported storage protocols

Fibre Channel (FC): FC provides low-latency block storage connectivity through dedicated storage fabrics.
iSCSI: iSCSI provides block storage connectivity over Ethernet networks using TCP/IP.

For more information, see Supported SAN solutions on Azure Local.

External SAN requirements

Lists requirements for Azure Local external SAN deployments.

Azure Local requirements for external SAN deployments

Lists the Azure Local requirements for integrating external SAN storage.

System requirements

To use external SAN storage with Azure Local, the environment must meet the following requirements:

Azure Local version 2604 or later
Fully deployed and operational Azure Local cluster
Multipath I/O (MPIO) enabled
High-bandwidth, low-latency connectivity between Azure Local nodes and the SAN array

Fibre Channel requirements for Azure Local external SAN deployments

Lists the Fibre Channel (FC) infrastructure and hardware requirements for connecting Azure Local to external SAN storage.

System requirements

To use FC connectivity with Azure Local, the environment must meet the following requirements:

Windows Server 2025-certified FC host bus adapters (HBAs) installed on all nodes
Certified and supported HBA drivers are installed on all nodes. For information about the supported component models, see Dell AX System for Azure Local Support Matrix.
Properly configured FC fabrics
Independent vSAN configured for each fabric
Dual-fabric deployment recommended for redundancy and high availability

iSCSI requirements for Azure Local external SAN deployments

Lists the networking and adapter requirements for connecting Azure Local to external SAN storage using iSCSI.

System requirements

To use iSCSI connectivity with Azure Local, the environment must meet the following requirements:

Dedicated physical network adapters for iSCSI traffic
Matching NIC firmware and driver versions are installed across all nodes. For information about the supported component models, see Dell AX System for Azure Local Support Matrix.
Consistent network adapter configuration on all nodes
Reliable, high-bandwidth, low-latency iSCSI network connectivity
Optional CHAP authentication for additional security

SAN array requirements for Azure Local external SAN deployments

Lists the storage array requirements for integrating external SAN storage with Azure Local.

System requirements

To use external SAN storage with Azure Local, the SAN array must meet the following requirements:

LUNs presented to all cluster nodes
NTFS-formatted volumes for Cluster Shared Volumes (CSVs)
Consistent MPIO configuration across all nodes
Dedicated LUNs assigned to individual Cluster Shared Volumes

Planning considerations for Azure Local external SAN deployments

Describes the planning activities that should be completed before integrating external SAN storage with an Azure Local cluster.

Overview

Proper planning helps ensure a successful external SAN integration and reduces deployment issues. Before connecting SAN storage to an Azure Local cluster, review storage, network, and infrastructure requirements.

Planning activities

Before integrating external SAN storage with Azure Local:

Verify cluster deployment: Ensure that the Azure Local cluster is fully deployed and operational.
Plan the storage architecture: Determine which workloads will use Storage Spaces Direct (S2D) storage and which workloads will use external SAN storage.
Assess SAN capacity: Verify that sufficient LUN capacity is available to meet workload requirements.
Review SAN documentation: Consult SAN vendor documentation for LUN creation, zoning, masking, and connectivity requirements.
Prepare network infrastructure: Verify that Fibre Channel or iSCSI networking is configured and operational.
Document WWNs or IQNs: Collect initiator identifiers that will be used for zoning and LUN masking configuration.

Configuration considerations for Azure Local external SAN deployments

Describes deployment and configuration considerations for integrating external SAN storage with Azure Local.

External SAN deployments require consistent configuration across all cluster nodes and supporting infrastructure. Review the following considerations before configuring SAN connectivity:

Delay Fibre Channel zoning until after deployment: Do not zone Fibre Channel host bus adapter (HBA) World Wide Names (WWNs) to the SAN array until Azure Local deployment is complete. This helps prevent deployment and discovery issues.
Use identical HBA configurations: Configure all cluster nodes with the same HBA model, firmware version, and driver version.
Maintain MPIO consistency: Apply identical MPIO settings across all cluster nodes.
Plan for node reboots: Changes to MPIO policies require a rolling reboot of all cluster nodes.

Configure Fibre Channel SAN connectivity for Azure Local

Describes how to connect an Azure Local cluster to external SAN storage using Fibre Channel.

Before you begin

Before configuring Fibre Channel connectivity, ensure that the following requirements are met:

Azure Local cluster is fully deployed and running version 2604 or later.
Fibre Channel host bus adapters (HBAs) are installed on all cluster nodes.
Fibre Channel fabrics are configured with independent VSANs.
SAN array is accessible on the FC fabric with management access configured.

Procedure

Verify and enable Multipath I/O (MPIO).

Verify that Multipath I/O (MPIO) is enabled on all cluster nodes.
1. To enable the MPIO feature, run the following PowerShell command:
```
Enable-WindowsOptionalFeature -Online -FeatureName MultipathIO
```
2. To verify the MPIO status, run the following PowerShell command:
```
Get-WindowsOptionalFeature -Online -FeatureName MultipathIO |
    Select-Object FeatureName, State, RestartNeeded
```
  If RestartNeeded returns True, perform a rolling reboot of all cluster nodes before proceeding.
Collect Fibre Channel initiator identifiers.
To collect the World Wide Port Names (WWPNs) from the FC HBAs of each node, run the following PowerShell command:
```
Get-InitiatorPort | Where-Object ConnectionType -eq 'Fibre Channel' |
Select-Object NodeAddress, PortAddress, ConnectionType | Format-Table -AutoSize
```
Document the WWPN associated with each HBA port and provide the information to the SAN administrator.
Configure SAN zoning and LUN masking.
Work with the SAN administrator to complete the following tasks:
1. Create Fibre Channel zones for each cluster node HBA port.
2. Configure LUN masking to present required LUNs to all cluster nodes.
3. Verify that zoning is active on all Fibre Channel switches.
4. Create the required LUNs on the SAN array.
5. Present the LUNs to all cluster nodes.

Verify LUN visibility.

To verify that all cluster nodes can access the presented LUNs, run the following PowerShell command:

Get-PhysicalDisk

Confirm that all expected LUNs report the following values:

Status: OK or Healthy
HealthStatus: Healthy
BusType: FC

NOTE: Do not initialize the disks after they are presented to the cluster. The disks must remain in RAW format so that Azure Local can use them as Cluster Shared Volumes (CSVs).

Results

All cluster nodes can access the Fibre Channel SAN LUNs, and the storage is ready for CSV configuration.

Configure iSCSI SAN connectivity for Azure Local

Describes how to connect an Azure Local cluster to external SAN storage by using iSCSI.

Before you begin

Before configuring iSCSI connectivity, ensure that the following requirements are met:

Azure Local cluster is fully deployed and running version 2604 or later.
Dedicated physical network adapters are available for iSCSI traffic. Virtual network adapters (vNICs) are not supported.
Network adapter firmware and drivers comply with Azure Local hardware catalog requirements.
The iSCSI target array is accessible on the network with management access.

Procedure

Enable the iSCSI Initiator service.
To enable and start the Microsoft iSCSI Initiator service on each cluster node, run the following PowerShell command:
```
Set-Service -Name MSiSCSI -StartupType Automatic
Start-Service -Name MSiSCSI
```
1. To verify the service status, run the following PowerShell command:
```
Get-Service -Name MSiSCSI | Select-Object Name, Status, StartType
```
The MSiSCSI service shows a Status of Running and a StartType of Automatic.
Configure network adapters for iSCSI.
To configure dedicated network adapters for iSCSI connectivity, assign a static IP address and disable DNS registration on each iSCSI adapter. Update the adapter name and IP address values to match the deployment requirements.
```
$adapter = Get-NetAdapter | Where-Object Name -eq "Ethernet 3"
New-NetIPAddress -IPAddress 100.68.120.11 -PrefixLength 25 -InterfaceIndex $adapter.ifindex
Set-DnsClient -InterfaceIndex $adapter.ifindex -RegisterThisConnectionsAddress $false
```
Repeat this step for each dedicated iSCSI adapter on every cluster node, incrementing the IP address for each node.
Collect iSCSI initiator identifiers.
To collect the iSCSI Qualified Name (IQN) from each cluster node, run the following PowerShell command:
```
(Get-InitiatorPort | Where-Object ConnectionType -eq 'iSCSI').NodeAddress
```
Document the IQN for each node and provide the information to the SAN administrator for host registration and LUN masking configuration.

Configure iSCSI target portals.

Configure iSCSI target portals for each available network path on every cluster node. Update the target and local IP address values to match the deployment environment.

$TargetIP1 = "100.68.121.100"
$TargetIP2 = "100.68.122.100"
$LocalIP1 = Get-NetIPAddress -InterfaceIndex $adapter1.ifindex
$LocalIP2 = Get-NetIPAddress -InterfaceIndex $adapter2.ifindex

New-IscsiTargetPortal -TargetPortalAddress $TargetIP1 -InitiatorPortalAddress $LocalIP1.IPAddress[1]
New-IscsiTargetPortal -TargetPortalAddress $TargetIP2 -InitiatorPortalAddress $LocalIP2.IPAddress[1]

Connect to iSCSI targets.

To connect to the discovered iSCSI targets and enable multipath connectivity, run the following PowerShell command:

$targets = Get-IscsiTarget | Where-Object { $_.IsConnected -eq $false }

foreach ($target in $targets) {
    Connect-IscsiTarget -NodeAddress $target.NodeAddress -TargetPortalAddress $TargetIP1 -InitiatorPortalAddress $LocalIP1.IPAddress[1] -IsPersistent $true -IsMultipathEnabled $true
    Connect-IscsiTarget -NodeAddress $target.NodeAddress -TargetPortalAddress $TargetIP2 -InitiatorPortalAddress $LocalIP2.IPAddress[1] -IsPersistent $true -IsMultipathEnabled $true
}

Verify LUN visibility.
To verify that the presented LUNs are visible to the cluster nodes, run the following PowerShell command:
```
Get-PhysicalDisk
```
Confirm that all expected LUNs report the following values:
- Status: OK or Healthy
- HealthStatus: Healthy
- BusType: iSCSI

Results

All cluster nodes can access the iSCSI SAN LUNs through the configured network paths, and the storage is ready for multipath validation and Cluster Shared Volume (CSV) configuration.

MPIO for Azure Local external SAN deployments

Explains the role of Multipath I/O (MPIO) in Azure Local external SAN deployments.

Overview

Multipath I/O (MPIO) provides redundancy and load balancing for SAN storage connections. MPIO must be configured consistently across all Azure Local cluster nodes.

To integrate MPIO with Azure Local external SAN deployments, complete the folowing:

Review the default MPIO settings.
Register the storage vendor with MPIO.
Configure the MPIO load-balancing policy.
Verify the MPIO configuration.

Default MPIO settings for Azure Local

Lists the default Multipath I/O (MPIO) settings included with Azure Local version 2604 and later.

Default MPIO settings for Azure Local version 2604 and later. The following table lists the default MPIO settings that Azure Local version 2604 and later applies to all cluster nodes. Review these values before making configuration changes to ensure that any customizations align with your storage array recommendations and operational requirements.
Setting	Default value
PathVerificationState	Enabled
PathVerificationPeriod	30
PDORemovePeriod	20
RetryCount	6
RetryInterval	3
CustomPathRecovery	Disabled
CustomPathRecoveryTime	20
DiskTimeoutValue	60
Load Balance Policy	Round Robin (RR)
NewDiskPolicy	OfflineShared

Register storage vendor with MPIO

Describes how to register your storage vendor with Microsoft Device Specific Module (MSDSM) for MPIO management.

Before MPIO can manage storage array LUNs, your storage vendor must be registered with Microsoft Device Specific Module (MSDSM). Registering your storage vendor allows MPIO to claim and manage the storage devices presented to Azure Local.

Procedure

Verify whether your storage vendor is already registered.
To check whether the vendor and product combination is already registered with MSDSM for Dell PowerStore arrays, run the following PowerShell command:
```
$MSDSMSupportedHW = Get-MSDSMSupportedHW | Where-Object {$_.VendorId -eq "DellEMC" -and $_.ProductId -eq "PowerStore"}
```
If the command returns a result, the storage vendor is already registered with MSDSM and you can skip Step 2. If no result is returned, proceed to Step 2 to register the vendor.
Register the storage vendor.
To register the Dell PowerStore storage array with MSDSM if the vendor is not already registered, run the following PowerShell command:
```
if (!$MSDSMSupportedHW) {
	New-MSDSMSupportedHW -VendorId "DellEMC" -ProductId "PowerStore"
```
The Dell PowerStore vendor and product identifier are registered with MSDSM on the cluster node. Repeat this step on all cluster nodes to ensure a consistent MPIO configuration.

Results

The Dell PowerStore storage array is registered with MSDSM, allowing MPIO to claim and manage the presented SAN LUNs.

Configure the MPIO load-balancing policy

Describes how to configure the MPIO load-balancing policy for SAN-connected storage.

MPIO uses a load-balancing policy to distribute I/O traffic across available storage paths. Configure the load-balancing policy on all Azure Local cluster nodes to ensure consistent path selection behavior.

Procedure

To set the MPIO load-balancing policy to Round Robin (RR), run the following PowerShell command:

Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR

Results

MPIO uses the Round Robin load-balancing policy to distribute storage traffic across available paths on all cluster nodes.

Configure Dell PowerStore MPIO timers

Apply Dell PowerStore MPIO timer settings and perform the required rolling reboot on Azure Local cluster nodes.

After configuring the Dell PowerStore MPIO timer settings and the MPIO load-balancing policy, perform a rolling reboot of each cluster node to ensure that the configuration changes take effect.

Perform this procedure on one node at a time to maintain cluster availability.

Procedure

Pause the node and move workloads to other cluster nodes before performing maintenance.
For more information, see Pause and drain the server.

To configure the Dell PowerStore specific MPIO timers, run the following command:

Set-MPIOSetting -NewRetryCount 3 -CustomPathRecovery Enabled `
-NewPathRecoveryInterval 10 -NewDiskTimeout 30

Verify that the Dell PowerStore MPIO timer settings and load-balancing policy are correctly configured on the node.
For more information, see Verify the configuration and reboot.
To restart the node, run the following command:
```
Restart-Computer -Force
```
Wait for the node to restart and rejoin the cluster.
Resume the node and restore normal cluster operations.
For more information, see Resume the server .
Wait for storage resynchronization to complete before proceeding to the next node.
For more information, see Wait for storage to resync.

Results

The Dell PowerStore MPIO timer settings and load-balancing policy are applied consistently across all cluster nodes, and storage is synchronized and healthy before workloads resume.

Verify the MPIO configuration

Describes how to verify MPIO devices, path availability, and load-balancing configuration on Azure Local nodes.

After configuring MPIO, verify that all SAN LUNs are claimed by MPIO, multiple storage paths are available, and the configured load-balancing policy is applied consistently across all cluster nodes.

Procedure

Verify that MPIO devices are detected.
To list all storage devices managed by MPIO, run the following command:
```
Get-MPIOAvailableHW
```
Review the output to confirm that the expected storage devices are available for MPIO management.
Verify MPIO paths.
To display path information for each SAN LUN, run the following command
```
Get-MSDSMPathInfo
```
Review the output to confirm that each LUN has multiple active paths.
Verify SAN disk health.
To check the health and operational status of all SAN-connected disks, run the following command:
```
# Verify all LUNs have multiple paths
Get-PhysicalDisk | Format-Table FriendlyName, BusType, OperationalStatus, HealthStatus
```
Verify that:
- The expected SAN disks are visible.
- The disk health status is Healthy.
- The operational status indicates normal operation.
Verify path status and load-balancing policy.
To verify path state and load-balancing configuration, run the following command:
```
Get-MSDSMPathInfo | Format-Table PathId, DiskNumber, State, LoadBalancePolicy
```
Review the output to confirm that:
- All expected paths are available.
- Path states are healthy.
- The configured load-balancing policy is applied to all SAN LUNs.

Results

MPIO devices, storage paths, SAN disks, and load-balancing policies are verified and operating as expected.

Post-deployment verification for Azure Local external SAN deployments

Explains the validation and monitoring activities that should be performed after integrating external SAN storage with Azure Local.

After configuring external SAN connectivity, verify that the SAN LUNs are visible to all cluster nodes, that Multipath I/O (MPIO) is operating correctly, and that storage paths remain healthy during normal cluster operations.

Complete the following activities after configuring Fibre Channel or iSCSI SAN connectivity:

Verify SAN connectivity.
Verify MPIO path availability for SAN storage.
Monitor SAN path health and cluster status.

Verify SAN connectivity for Azure Local external SAN deployments

Describes how to verify that all Azure Local cluster nodes can access the SAN LUNs presented by the storage array.

Before using external SAN storage for workloads, verify that all cluster nodes can detect and access the presented SAN LUNs.

Procedure

On each cluster node, run the following command:
```
Get-PhysicalDisk
```
Verify the disk status.
Review the output and confirm that all expected SAN LUNs report the following values:
- Status: OK or Healthy
- HealthStatus: Healthy
- BusType: FC (Fibre Channel) or iSCSI
Verify disk consistency across all nodes.

Confirm that the same number of SAN disks is visible on every cluster node.

Results

All cluster nodes can access the expected SAN LUNs, and the presented storage is healthy and available for workload use.

Verify MPIO path availability for SAN storage

Describes how to verify that SAN LUNs are accessible through multiple active MPIO paths on Azure Local cluster nodes.

After configuring Multipath I/O (MPIO), verify that each SAN LUN has multiple active paths and that path failover protection is functioning as expected.

Procedure

To verify the number of paths per LUN, run the following command:
```
Get-MSDSMPathInfo | Group-Object DiskNumber | Select-Object Name, Count
```
Review the output to confirm that each SAN LUN is associated with multiple paths.
To verify that all paths are active, run the following command:
```
Get-MSDSMPathInfo | Where-Object {$_.State -ne "Active"} | Format-Table
```
Review the output for inactive or failed paths.
Investigate inactive paths.

If inactive paths are detected, work with the SAN administrator to identify and resolve zoning, masking, connectivity, or storage path issues.

Results

All SAN LUNs are accessible through multiple active MPIO paths, providing redundancy and load balancing for storage traffic.

Monitor SAN path health for Azure Local external SAN deployments

Describes how to monitor SAN path health, failover events, and cluster health in an Azure Local external SAN environment.

After configuring SAN connectivity and MPIO, regularly monitor storage paths to identify path failures, failover events, and cluster health issues before they affect workload availability.

Procedure

Review MPIO-related events:
1. To review MPIO-releated events, select Event Viewer > Windows Logs > System.
2. Look for events generated by the mpio event source.
Monitor storage performance.
Click Performance Monitor to:
- Track disk I/O performance metrics.
- Monitor path failover events.
- Monitor path recovery events.
Verify cluster health.
To verify cluster health, run the following command:
```
Get-ClusterResource
Get-ClusterNode | Select-Object Name, State
```

Results

SAN path health, failover activity, storage performance, and cluster health are monitored and operating as expected.

Create and use external SAN storage in Azure Local

Explains how to provision external SAN storage and make it available for Azure Local workloads.

After verifying SAN connectivity and Multipath I/O (MPIO) configuration, you can provision external SAN storage for Azure Local workloads. Using SAN-backed Cluster Shared Volumes allows virtual machines and applications to consume external SAN storage while remaining highly available across the cluster.

To provision and use external SAN storage:

Create Cluster Shared Volumes from SAN LUNs.
Configure workload storage paths on SAN-backed Cluster Shared Volumes.

Create Cluster Shared Volumes from SAN LUNs

Describes how to create Cluster Shared Volumes (CSVs) from SAN-provided LUNs.

After verifying SAN connectivity and MPIO configuration, create Cluster Shared Volumes from the SAN LUNs before using the storage for workloads.

Procedure

To initialize the SAN LUNs, run the following command:

Get-PhysicalDisk | Where-Object {$_.BusType -eq "FC" -or $_.BusType -eq "iSCSI"} | Initialize-Disk

To create a partition and format the volume with NTFS, run the following command:

New-Partition -DiskNumber <disk_number> -UseMaximumSize -AssignDriveLetter
Format-Volume -DriveLetter <drive_letter> -FileSystem NTFS -NewFileSystemLabel "SAN-CSV-01"

To add the volume to Cluster Shared Volumes, run the following command:
```
Add-ClusterSharedVolume -Name "Cluster Disk X"
```

Results

The SAN LUN is available as a Cluster Shared Volume and can be used by Azure Local workloads.

Configure workload storage paths on SAN-backed Cluster Shared Volumes

Describes how to configure workload storage locations on SAN-backed Cluster Shared Volumes.

After creating Cluster Shared Volumes, configure workload storage locations so that virtual machines and applications use SAN-backed storage.

Procedure

Log in to the Azure portal and go to your Azure Local cluster resource.
Select Settings > Storage path.
Select + Add storage path.
Enter the Cluster Shared Volume path. For example:
```
C:\ClusterStorage\Volume1
```
Confirm and save.
Repeat for each SAN CSV.

Results

Virtual machines and applications store data on SAN-backed Cluster Shared Volumes.

Troubleshoot Azure Local external SAN deployments

Provides troubleshooting guidance for common issues encountered when integrating external SAN storage with Azure Local.

External SAN storage integration issues typically involve storage path visibility, LUN presentation, or multipath failover. When troubleshooting SAN connectivity, verify storage connectivity, MPIO configuration, zoning, masking, and hardware health.

Troubleshoot MPIO paths not visible

Describes how to diagnose and resolve issues where MPIO paths are not visible or are not functioning correctly.

Use the following steps when you observe any of these symptoms:

SAN LUNs are visible, but expected MPIO paths are missing.
Storage devices do not appear to be managed by MPIO.
Storage path redundancy is unavailable.

Procedure

Verify HBA drivers.

To verify that FC or iSCSI drivers are installed and current, run the following command:

Get-CimInstance -ClassName Win32_PnpSignedDriver | Where-Object {$_.DeviceName -like "*Fibre Channel*" -or $_.DeviceName -like "*iSCSI*"}

Verify Fibre Channel zoning.

Confirm that Fibre Channel zoning is configured correctly and active on all switches.
Verify MPIO device claiming.
To check MPIO automatic claim settings, run the following command:
```
Get-MSDSMAutomaticClaimSettings
```
Verify LUN visibility.
To confirm that the SAN LUNs are visible, run the following command:
```
Get-PhysicalDisk -CanPool $true
```
Review Windows Event Viewer for MPIO-related errors and warnings.

Results

MPIO paths are visible and operating correctly.

Troubleshoot SAN LUN masking issues

Describes how to diagnose and resolve SAN LUN masking issues that prevent LUN visibility across cluster nodes.

Use the following steps when you observe any of these symptoms:

SAN LUNs are visible on some nodes but not others.
Newly presented LUNs do not appear on cluster nodes.
Inconsistent storage visibility across the cluster.

Procedure

Verify SAN LUN masking.

Confirm that the SAN array masking configuration is correct.
Verify initiator identifiers.

Confirm that all node WWPNs or IQNs are included in the masking configuration.
Verify Fibre Channel zoning.

Verify that Fibre Channel zoning includes all cluster node HBA ports.
Check switch restrictions.

Review Fibre Channel switches for port-level zoning restrictions.
Review vendor documentation.

Consult SAN vendor documentation for array-specific LUN masking requirements and procedures.

Results

All SAN LUNs are visible to all cluster nodes.

Troubleshoot SAN path failover issues

Describes how to diagnose and resolve SAN storage path failover issues.

Use the following steps when you observe any of these symptoms:

Storage traffic does not fail over to alternate paths.
MPIO path recovery does not occur.
Storage connectivity is lost during path failures.

Procedure

Verify MPIO configuration.

Confirm that MPIO is enabled on all cluster nodes.
Verify policy consistency.

Confirm that identical MPIO policies are configured across all cluster nodes.
Verify HBA firmware.

Verify that HBA firmware versions are current and supported.
Verify hardware health.

Inspect Fibre Channel or iSCSI adapters, ports, and cables for hardware issues.
Review SAN logs.

Review SAN array logs for connectivity, path, or controller-related issues.
Review vendor documentation.

Consult vendor-specific MPIO guidance for the storage platform.

Results

Storage paths fail over and recover correctly when path failures occur.

Updating Azure Local instances using SBE package

Download Connector

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.

Download Connector firewall requirements

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:

Outbound connectivity for SBE Download Connector. Outbound connectivity details for SBE Download Connector
Endpoint description	Endpoint URL	Port
SBE bundle download	dl.dell.com/*	443
SBE download catalog	downloads.dell.com/filestore/Prod/SbeDownloadCatalog/AX_SBE_Download_Catalog.xml	443
SBE download catalog redirection	aka.ms/DellAzureLocalSBEDownloadCatalog	443
Digicert Certificate Revocation Status	http://crl3.digicert.com/*	80
Digicert Certificate Revocation Status	http://crl4.digicert.com/*	80

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.

SBE package update prerequisites

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

NOTE: You must run the Get-SolutionUpdateEnvironment PowerShell command. If the SBE package (latest version is 4.0.0.0) is only partially installed, complete the installation by following the procedures that are outlined in Download Connector – Automated download of future SBE release > Installation in the Azure Local Dell Solution Builder Extensions Release Notes (Dell 2512) on GitHub.

Update SBE package using PowerShell (online)

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

To perform an online solution update, do the following:

Procedure

Depending on your deployment configuration, ensure that your Azure Local instance single-machine has or your multi-machines have good Internet connectivity.
To verify that the update service discovers the solution update, run the following command:
```
Get-SolutionUpdate | Format-Table DisplayName, State
```
To install the solution update, run the following command:
```
Get-SolutionUpdate | Start-SolutionUpdate
```

Updating SBE package using PowerShell (offline)

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.

CAUTION: Before proceeding, verify that sufficient space is available on the selected Cluster Shared Volume (CSV).

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

Update SBE package using Azure portal

Azure Update Manager allows you to apply, view, and manage updates for your Azure Local instance machines.

Before the updates start, Azure Update Manager checks the cluster readiness and lists available updates. You can also monitor the status of the updates that are being applied.

To identify and install updates, do the following:

Procedure

Go to Azure Update Manager. In the left panel, under Resources, click Azure Local.
Alternatively, you can perform the procedure by going to Azure Arc > Azure Local, and then clicking Azure Local ClusterUpdates.
Select one or more clusters from the list, and then click one-time update.
The Install Updates window appears and lists available updates.

Updates window
On the check readiness tab, review the checks and their results. When verified, click Next.
On the Select updates tab, select the available update or updates that you want to install, and then click Next.
On the Review + install tab, verify the previously selected options, and then click Install.
To monitor the update progress, go to Azure Update Manager > Azure Local. Select Azure Local Instance. In the left panel, under Operations, select History. The clusters with updated statuses appear.
1. Select the update run from the list of In-progress tasks.
2. Review the results in the Download updates tab, and then click Next.
3. From the Install tab, review the updates in progress. When the updates are complete, you see results similar to the following figure:
  
  Successful installation of updates on a cluster

GPU Integration

Installing and configuring GPUs on AX platforms

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.

NOTE: You must order AX nodes that are preconfigured for GPU integration, or converted for GPU use, including the required components.

Guidelines for installing GPU hardware

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.

GPU Discrete Device Assignment (DDA)

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.

Download and install guest drivers

Download and install guest drivers from NVIDIA Application Hub.

To download and install a guest driver, do the following:

Procedure

To download the drivers, go to NVIDIA Application Hub Login and log in with your enterprise account.
Click the NVIDIA licensing portal, and then click SOFTWARE DOWNLOADS.
All software that is available for download is listed.
To locate the driver, apply the following filters:
PRODUCT FAMILY: VGPU and either:
- For Azure Stack HCI operating system: PLATFORM: Azure Local
- For Windows Server 2025 operating system or later: PLATFORM: Windows Server
GPU guest driver download filter options

Always verify that the driver supports your GPU and its intended use.

For more information, see Virtual GPU Software for Microsoft Azure Local Release Notes.

The package contains the required driver for the virtual machine to use a GPU that is assigned through Discrete Device Assignment (DDA). With DDA (full device passthrough), you install the NVIDIA driver that enables GPU functionality in the guest virtual machine. In the DDA workflow, the NVIDIA guest driver is not required on the host. If no vendor display driver is installed, the host can show the GPU as a 3D Video Controller.

You can do DDA with either Windows Admin Center (WAC) or PowerShell. Dell Technologies recommends using WAC to reduce user error and to conform to best practices.

NOTE: Before configuring DDA, to make the GPU available for assignment to the virtual machine, you must disable and dismount the GPU from the host-management operating system.

If you are using Windows Admin Center (WAC) to configure GPU assignment, WAC automatically performs the required disable and dismount operations as part of the workflow, so you do not have to complete this step manually. This automation is one of the reasons that Dell Technologies recommends that you use WAC for GPU-related actions. For more information about configuring and performing a DDA, see Use GPUs with Discrete Device Assignment in clustered VMs.

When DDA is complete and the GPU is assigned to the virtual machine, install the NVIDIA guest driver inside the guest virtual machine so that the virtual machine can use the GPU.

NOTE: For Windows guests, the driver is in the Guest_Drivers folder of the archive and has an .exe extension.

For information about installing guest drivers, see Installing the NVIDIA vGPU Software Graphics Driver and NVIDIA Control Panel on Windows section of the NVIDIA Virtual GPU Software User Guide.

Results

When the guest driver is installed, your virtual machine is ready to use the DDA GPU. For NVIDIA software licensing requirements, modes, and license-server configuration guidance, see the NVIDIA Virtual GPU Software Client Licensing User Guide.

GPU partitioning

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.

NOTE: For GPU-P to work, you must have both a host driver and a GPU-P enabled guest (VM) driver and the correct activated license.

Download and install host and guest drivers

For GPU partitioning (GPU-P) to work, you must have both a host driver and a GPU-P enabled guest (VM) driver and the correct activated license.

To download and install host and guest drivers, do the following:

Procedure

To download the drivers, go to NVIDIA Application Hub Login and log in with your enterprise account.
Click the NVIDIA licensing portal, and then click SOFTWARE DOWNLOADS.
All software that is available for download is listed.
To locate the driver, apply the following filters:
PRODUCT FAMILY: VGPU and either:
- For Azure Stack HCI operating system: PLATFORM: Azure Local
- For Windows Server 2025 operating system or later: PLATFORM: Windows Server
GPU guest driver download filter options

Verify that the driver supports your GPU and its intended use. For more information, see Virtual GPU Software for Microsoft Azure Local Release Notes.

This package contains the host and guest drivers.

NOTE: Before proceeding to install the GPU-P drivers on the host, remove any Tesla drivers, if previously installed.

For information about installing the host driver, see Installing and Configuring the NVIDIA Virtual GPU Manager for Microsoft Azure Local or Microsoft Windows Server section of the NVIDIA Virtual GPU Software User Guide.

After the host driver is installed on every cluster node, do the GPU-P.

For information about GPU-P, see Partition and assign GPUs to a virtual machine. If you are using an Azure Local cluster, you can use the Azure portal to partition and assign GPUs to a virtual machine. For more information, see Manage GPUs via Discrete Device Assignment for Azure Local (preview).

NOTE: Dell Technologies recommends that you use WAC and GPU extensions.

When you have assigned GPU partitions to the virtual machine, install the guest driver.
For information about installing the guest driver, see Installing the NVIDIA vGPU Software Graphics Driver and NVIDIA Control Panel on Windows section of the NVIDIA Virtual GPU Software User Guide.
After you install the virtual-machine guest driver, to start using GPU-P, activate the guest virtual machine with an NVIDIA license.
For information about activating the guest virtual machine, see Configuring a Licensed Client on Windows with Default Settings of the Virtual GPU Software Client Licensing User Guide.

Dell OpenManage Integration with Windows Admin Center

Overview of Dell OpenManage Integration with Windows Admin Center

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.

NOTE: For Storage Spaces Direct Ready nodes, if you want to use the Cluster Aware Update premium feature to update the cluster using the Dell OpenManage Integration extension, contact a Dell Technologies sales representative to get an Azure Local license.

Prerequisites for managing AX nodes

The prerequisites for managing AX nodes from Dell Technologies are:

You have installed the following:
- Windows Admin Center version 2410 GA or any later supported version and you are logged in as a gateway administrator
- Dell OpenManage Integration with Microsoft Windows Admin Center extension
  For more information about the installation procedure, see the Support for Dell OpenManage Integration with Microsoft Windows Admin Center.
- Microsoft failover cluster extension is version 3.0 release or later
There is a Dell OpenManage Integration with Microsoft Windows Admin Center premium license on each AX node.
You have added the hyperconverged infrastructure cluster connection in Windows Admin Center.
You have enabled remote desktop on your cluster with Azure Stack HCI operating system 24H2.
You can access the Windows Admin Center remotely using domain administrator credentials. Otherwise, use local administrator credentials to access the Windows Admin Center locally. For more information, see What type of installation is right for you?

Managing Microsoft HCI-based clusters

To review the license agreement and enable cluster management, do the following:

Procedure

In Windows Admin Center, from the menu, select Cluster Manager.
In the Cluster Connections window, click the cluster name.
In the left pane of Windows Admin Center, under EXTENSIONS, click Dell OpenManage Integration.
Review the Dell Software License Agreement and Customer Notice, and then, to accept the terms of the license agreement, select the checkbox.

Monitoring clusters through the Overview window

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:

Overview

Overview provides high-level cluster information including the following:

Number of cluster machines
Health of a cluster that includes total number of components with health as critical across nodes or, if all components are healthy, displays Health Ok .
- Green: Healthy
- Yellow: Warning
- Red: Critical
- Grey: Unknown
Secure core status:
- Green: Enabled when all BIOS features are enabled on all nodes.
- Yellow: Partially enabled when one or more nodes do not have all BIOS features enabled.
- Red: Disabled when no node has all BIOS features enabled.
Compliance status:
- Green: Compliant when all cluster machines are compliant with all Dell policies.
- Yellow: Warning when one or more cluster nodes are not compliant with any optional policy.
- Red: Error when a cluster node is not compliant with the Dell Hardware Symmetry Policy.
- Grey: Unknown when any cluster node is not reachable.
Warranty status:
- Green: Active
- Red: Expired or Critical

HCP Compliance

When the Dell OpenManage Integration extension loads for the first time, the HCP and firmware compliance section remains empty. When you generate reports from the Action menu, the section is populated.

HCP Compliance displays the compliance status of an HCI cluster number of components for each status:
- Green: Components are compliant with Dell policies.
- Yellow: Warning when components are not compliant with any optional policy.
- Red: Error when components are not compliant with the Dell Hardware Symmetry Policy.

Security

You can view the following:

Secure core status:
- Green: Enabled when all BIOS features are enabled on all nodes.
- Yellow: Partially enabled when one or more nodes do not have all BIOS features enabled.
- Red: Disabled when no node has all BIOS features enabled.
Infrastructure lock status:
- Green: Enabled when all nodes of the cluster are locked.
- Yellow: Partially enabled when one or more nodes of the cluster are unlocked.
- Grey: Unknown when unable to connect the cluster nodes.

Resources

Resources shows:

The current storage details, such as used storage and available storage
The current CPU core details, such as current cores and available cores

Quick task

Quick task provides direct links to perform different actions using the Dell OpenManage Integration extension. If an action has a dependency on another action, the action may be disabled .

Prerequisite checks

In the Dell OpenManage Integration with Microsoft Windows Admin Center extension (Dell OpenManage Integration extension), you can use standalone prerequisite checks to verify if the connection meets the requirements for monitoring and management operations.

To verify the hardware and software requirements, when you perform any operation using the Dell OpenManage Integration extension, the extension automatically runs the prerequisite checks. If any prerequisite check fails, View Details appears in the respective window. To see how to resolve the issues before performing the operation, you can click View Details.

The Dell OpenManage Integration extension also provides a standalone Prerequisite Checks option. To verify server or cluster readiness, before you run any operation using the extension, you must run Prerequisite Checks. For a seamless monitoring and management experience, you use this check to identify and fix any problems for all operations.

If any of the prerequisite checks fail, you can resolve the issue either manually or automatically depending on the nature of the check:

For checks that are listed in the Auto Fix category, you can resolve the issue by clicking Resolve in the Dell OpenManage Integration extension.
For checks that are listed in the Manual Fix, the Dell OpenManage Integration extension displays recommendations about how to resolve issues manually.

When the prerequisite checks are all compliant, you can use the Dell OpenManage Integration extension to perform server or cluster management operations.

To run the prerequisite checks and fix any issue using one of the methods that are listed previously, do the following:

Procedure

In the Dell OpenManage Integration extension, click View > Prerequisite Checks.

To select the operations on which you want to run the prerequisite checks, click Select Operation. By default, all operations are selected.

NOTE: Check in the next step is only available after you click Select Operations in this step.

To run the prerequisite checks for the selected operations, click Check.
When the prerequisite checks are complete, View Details appears next to Select Operation.
To see the prerequisite check report, click View Details.
To fix any prerequisite issues:
1. With Auto Fix, ensure that the failed prerequisites are selected, and then click Resolve.
2. With Manual Fix, ensure that the failed prerequisites are selected, and then view the recommendations about how to resolve the issues manually.
After issues are resolved, click Rerun to see the updated prerequisite checks status report. For more information, see list of prerequisite checks in the Dell OpenManage Integration with Microsoft Windows Admin Center Version User Guide.

Health status

To view the overall health of a cluster or node, do the following steps:

In the Dell OpenManage Integration extension, to view the overall cluster health status and the health status of each node and its components, click View: Health.
The Health window appears. The system checks the inventory prerequisites. If all prerequisites are compliant, the window displays the health status of all hardware components, as shown in the following figure. If one or more checks are not compliant, an error message appears.

Health window
To see the prerequisites that have failed, click View Details.
To fix the issues that are in the Auto Fix category, click Resolve .
For issues that are in the Manual Fix category, see the recommendations about how to resolve them. For more information about inventory prerequisites checks, see Prerequisite checks .
To view the latest health information, click Refresh.

Overall Health Status

A doughnut chart displays the overall health status of a cluster using the following color code:

Green color indicates that the cluster is healthy.
Yellow color indicates that the cluster is not in recommended state.
Red color indicates that the cluster is in critical state.
Grey color indicates that indicates that the cluster nodes are not reachable and status is unknown.

The number of nodes in the doughnut chart indicates the number of cluster nodes that have the same health status as the cluster.

Different color codes show the respective health status of several nodes. To filter the health status of a node and its components, in the doughnut chart, click the respective color code. For example, to see the node and its components that are in critical health status, click the red color in the doughnut chart.

Inventory

The Inventory window lists the servers that are part of the cluster.

In the Dell OpenManage Integration extension, select View > Inventory.
The Inventory window appears and provides a list of inventory prerequisite checks. If all prerequisites are compliant, the window displays the hardware and firmware information for the cluster machines. If one or more checks are not compliant, an error message appears.
To see which prerequisites have failed, click View Details.
To fix issues that belong to the Auto Fix category, click Resolve.
To fix issues that belong to the Manual Fix category, see the recommendations about how to resolve them.
To view the latest hardware or firmware information, click Refresh.

Clicking a server name on the inventory list provides details about the following components:

System
Firmware
CPUs
Memory
Storage controllers
Storage enclosures
Network devices
Hard drives
Power supplies
Fans

Locating hard drives and viewing their status

The Blink and Unblink feature of Windows Admin Center enables you to locate hard drives (physical disks) or view drive status.

Procedure

Under the Inventory tab, from the Components list, select Physical Disks.
For each hard drive, select Blink or Unblink to control the drive's LED.

Enabling hardware alerts for Azure Local instance

Before you begin

Ensure that all checks are successful.
Ensure that Alerts is enabled on iDRAC. Go to Configuration > System Settings > Alerts.

iDRAC allow you to set alerts and actions for components that have any deviation from the predefined conditions. The alerts feature allows you to receive hardware alerts from iDRAC for each node. You can configure alerts by selecting the various categories and severities:

System Health
Storage
Updates
Configuration
Audit
Critical
Warning
Informational

After you configure the hardware alerts, an option to clear alert configurations appears.

To manage alerts, do the following:

Procedure

To configure the alerts, log in to Windows Admin Center and launch the Dell OpenManage Integration extension in the Azure Local instance.
Go to either:
- View: Configure > Hardware Alert
- Action > Hardware Alert
Select Configure Alert.
Options appear that allow you to select categories and severities.
Choose the relevant options, and then click Configure, as shown in the following figure.

Configure alerts
To view the alerts, if you are already logged in, skip this step, otherwise, log in to Windows Admin Center and launch the Dell OpenManage Integration extension for the Azure Local instance.
Go to either:
- View: Configure > Hardware Alert
- Action > Hardware Alert
If the alerts are already configured, you can see the alerts that are generated in the duration selected. You can change the duration from a few hours to last 30 days.
To refresh the alerts, click Refresh, as shown in the following figure.

iDRAC Alerts window
To remove the configured alerts, if you are already logged in, skip this step, otherwise, log in to Windows Admin Center and run the Dell OpenManage Integration extension for the Azure Local instance.
Go to either:
- View: Configure > Hardware Alert
- Action > Hardware Alert
Click Clear Alert Configuration.
When the prompt appears, the configured alerts are cleared.

Secure cluster with Secured-core

Before you begin

A malicious hacker who has physical access to a system can tamper with the BIOS. A tampered BIOS code poses a high security threat and makes the system vulnerable to further attacks. With the Secured-core feature, Dell OpenManage Integration with Microsoft Windows Admin Center (OMIMSWAC) ensures that your cluster boots using only Dell Technologies trusted software.

NOTE: For 24H2 installations, Secured-core is enabled by default.

The Secured-core feature is supported on the following configurations:

AMD processor types:
- AMD Milan with cluster nodes BIOS version 2.3.6 or later

Intel processor types:

cluster nodes BIOS version 1.3.8 or later

NOTE: Intel E-23 series and Intel Pentium SKUs, such as G6605, G6505, G6505T, G6405, and G6405T, processor types are not supported for the Secured-core feature.

Operating system versions:
- Azure Stack HCI operating system 24H2 or later
- TPM V2.0 module must be installed with firmware 7.2.2.0 or later
- OMIMSWAC premium license must be installed on each cluster node

NOTE: To ensure proper functioning of the System Guard operating system feature, ensure that the TPM Hierarchy under System Security section is enabled in the BIOS settings.

The Secured-core feature includes enabling BIOS and operating system security features. To protect infrastructure from external threats, Dell Technologies and Microsoft recommend that you enable the BIOS security features and operating system security features respectively. In Windows Admin Center, to enable BIOS security features, use the Dell OpenManage Integration extension. To enable the operating system security features, use the Security extension.

Secured-core features are enabled by default for Azure Local instance machines. For more information about the security features, see Security features for Azure Local.

To enable BIOS security features, do the following:

Procedure

Log in to Windows Admin Center and launch the Dell OpenManage Integration extension.
Select View > Security.
From the list menu, select Secured Core. Alternatively, go to the Action menu, under Security and select Secured Core.
If prompted, specify Manage as credentials.
If the following prerequisites are fulfilled on the target or cluster nodes, OMIMSWAC validates:
- Supported platform and processor types
- Supported BIOS version
- Supported operating system version
- Installed OMIMSWAC Premium License
If one or more prerequisites are not fulfilled, OMIMSWAC displays the list of prerequisites and its overall status and recommendation.
Review the recommendations with the status showing as unfulfilled and resolve the prerequisites.
1. To see the prerequisites to be fulfilled for each cluster node, switch to Show Machine Level Details.
2. After resolving the prerequisites, to display the overall status, return to Security > Secured-core.
  If all prerequisites are fulfilled, the Dell OpenManage Integration extension displays the Secured-core status for both BIOS and operating system. The overall BIOS and operating system status is the summary of all BIOS and operating-system feature configuration statuses for the entire cluster.

If the infrastructure lock is enabled, click Disable.

NOTE: Before enabling the BIOS configurations, you must disable the infrastructure lock.

Review all BIOS feature statuses and corresponding operating-system feature statuses.

A consolidated view of all BIOS and operating system feature configuration statuses is displayed in the Cluster-level BIOS Features and Status and Cluster-level OS Features and Status sections.

The following table lists the BIOS and operating system features with security functionalities:

BIOS and operating system features with security functionality. Table lists of BIOS and operating system features with security functionality and details about each one.

BIOS feature

Security function

Corresponding operating-system features

Other information

Virtualization Technology

Assists with enabling the BIOS processor-virtualization features (such as protecting against exploits in user-mode drivers and applications) and provides virtualization support to the operating system through the DMAR table.

Hypervisor-Protected Code Integrity (HVCI)
Virtualization-Based Security (VBS)

N/A

Kernel DMA Protection

When enabled, both the BIOS and operating system protect devices from Direct Memory Access attacks in early boot by using the Input/Output Memory Management Unit (IOMMU).

Boot DMA Protection

N/A

Secure Boot

Secure Boot ensures that the device boots with trusted, Dell signed software.

Secure Boot

N/A

Trusted Platform Module (TPM) 2.0

TPM PPI Bypass Provision
TPM PPI Bypass Clear
TPM2 Algorithm Selection

TPM is a dedicated microprocessor that is designed to secure hardware by integrating cryptographic keys into devices. Software can use TPM to authenticate hardware devices.

Trusted Platform Module (TPM) 2.0
System Guard

NOTE: To ensure proper functioning of the System Guard operating-system feature, ensure that the TPM Hierarchy under the System Security section is enabled in the BIOS settings.

NOTE: If the TPM firmware version is earlier than 7.2.2.0, ensure that Enable BIOS Configuration is disabled. You must replace the hardware with hardware that has TPM firmware version 7.2.2.0 or later.

NOTE: TPM2 Algorithm Selection is set to SHA256.

(AMD) Dynamic Root of Trust Measurement (DRTM)

Enables AMD DRTM and AMD secure-encryption features such as Secure Memory Encryption (SME) and Transparent Secure Memory Encryption (SME)

N/A

This feature is available for AMD-based processors.

(Intel) Trusted Execution Technology (TXT)

Enhances platform security by using Virtualization Technology, TPM Security, and TPM2 Algorithm (must be SHA256). Intel TXT provides security against hypervisor, BIOS, firmware, and other pre-launch software-based attacks by establishing a "root of trust" during the boot process.

N/A

This feature is available for Intel-based processors.

To configure Secured-core for all BIOS attributes, click Enable BIOS Configuration.

To apply the BIOS configuration, perform one of the following actions:

Apply and Reboot Now: Applies the BIOS configuration changes in all cluster nodes and reboots the cluster using Cluster-Aware Updating without impacting the workload.
Apply at Next Reboot: Saves the changes and applies the BIOS configuration in all cluster nodes at the next reboot.

CAUTION: If you choose the Apply at Next Reboot option, before performing any cluster management operations, you must exit the Dell OpenManage Integration extension and restart the cluster using Windows Admin Center .

When finished, click Apply.

NOTE: The operation enables CredSSP. To improve security, after the operation is complete, disable CredSSP.

To see the status of the BIOS configuration changes at node level, click View Details.

Enable operating system features

Before you begin

Before you begin, you must ensure that the chipset drivers are installed as shown in the following table:

NOTE: Always confirm and download the latest drivers and firmware as listed in the Azure Local Support Matrix.

Chipset required by AX node server model. This table shows a list of the chipset (DUP version) that is required for each type of supported AX node server model
Chipset	AX node
Intel chipset DUP, version 10.1.19879.8585 and later	Dell AX-650, Dell AX-750
Intel chipset DUP, version 10.1.19913.8607 and later	Dell AX-660, Dell AX-760
Intel chipset DUP, version 10.1.19928.8615 and later	Dell AX-4510c, Dell AX-4520c
Intel chipset DUP, version 10.0.26100.6725 and later	Dell AX-670, Dell AX-770
AMD chipset DUP, version 6.02.22.100 and later	Dell AX-7525

WARNING: To protect the infrastructure from external threats, Dell Technologies and Microsoft recommend that you enable Secured-core. Secured-core includes both the infrastructure and Microsoft operating system features for Dell AX System for Azure Local and Windows Server 2022 or Windows Server 2025.

Operating-system settings can be enabled manually by modifying the registry settings or by using the Windows Admin Center Security extension. To enable operating system features, do the following:

Procedure

If using the registry settings:
1. Run the following commands on each machine in a cluster:
```
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f

reg add "HKLM\System\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard" /v "Enabled" /t REG_DWORD /d 1 /f
```
2. After you run the commands, restart the servers one at a time. For more information, see Restarting a cluster machine or taking a cluster machine offline.
Go directly to Step 3.
If using the Windows Admin Center Security extension, log in to Windows Admin Center and connect to the cluster.
1. Under Extensions, click Security.
2. In the Security window, click Secured-Core.
3. Select both Hypervisor Enforced Code Integrity (HVCI) and System Guard, and then click Enable as shown in the following figure.
  
  Secured-core details
4. Restart the machines one at a time. For more information, see Restarting a cluster machine or taking a cluster machine offline.
5. After the settings are enabled and each machine is restarted, the Secured-core section on each machine must show all features with the On status, as shown in the following figure.
  
  Secured-core machine status
To verify the BIOS and operating-system settings, open the Dell OpenManage Integration extension window.
Select View > Security > Secured-core.

Protect your infrastructure with infrastructure lock

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:

Functional and nonfunctional features affected by infrastructure lock. List of functional and nonfunctional features that are affected by infrastructure lock
Disabled	Remains functional
Full stack update on clusters Individual server update and Cluster-Aware Updating on clusters Managing CPU cores on servers and clusters Integrated deploy and update clusters Preparing machines for cluster expansion Secured core	Retrieving health, inventory, and iDRAC details Blinking and unblinking server LEDs

Enable or disable infrastructure lock

Infrastructure lock is applicable to both hardware configuration and firmware updates, and it helps prevent unintended changes after a system is provisioned.

For better security, to use the infrastructure lock option, do the following:

Procedure

To enable or disable the Infrastructure lock in the Dell OpenManage Integration extension, go to View > Security.
From the list menu, select Infrastructure Lock, and then click Enable or Disable, as shown in the following figure:

Enable infrastructure lock

The infrastructure lock can also be disabled during server or cluster management operations such as server update, CAU, full stack update, manage CPU cores, and so on.

If the lock is already enabled, Dell OpenManage Integration with Microsoft Windows Admin Center (OMIMSWAC) displays an error during the management operation and gives you an option in the same window to disable the lock and proceed.

To allow OMIMSWAC to automatically lock the infrastructure after the operation is complete, select Allow OMIMSWAC, which re-enables the infrastructure lock after the operation is complete.

NOTE: You cannot use OMIMSWAC to maintain cluster homogeneity by enabling or disabling the infrastructure lock for individual servers that are part of a cluster.

Manage CPU cores in Azure Local instances

Before you begin

Ensure that the Azure Local instance contains homogenous machines. For example, the machines must have the CPUs either from Intel or AMD and from the same processor family.

NOTE: Having machines that include CPUs from both Intel and AMD or from different processor families is not supported.

Dell OpenManage Integration with Microsoft Windows Admin Center (OMIMSWAC) Premium License for Microsoft HCI Solutions must be installed on each Azure Local instance machine.

To manage workload demands, power consumption, and licensing costs, you can change the number of CPU cores that are allocated to a Azure Local instance by using the Update CPU core feature. You can use this feature to optimize CPU cores in Azure Local instances to keep the Total Cost of Ownership (TCO) at an optimal level.

To configure and manage CPU cores, do the following:

Procedure

In Windows Admin Center, connect to a Azure Local instance.
In Windows Admin Center, under Extensions, click Dell OpenManage Integration.
In Dell OpenManage Integration, select View > Configure. Another menu list appears. Select CPU Core.
To manage CPU cores, click Update CPU Core.
The Update CPU Core wizard appears.

Based on workloads, in the Update CPU Core wizard, select the number of cores to be used.

You can configure the cores, which are based on the CPU core manufacturer (Intel or AMD), as shown in the following table. To maintain an Azure Local instance homogeneity, Dell OpenManage Integration applies the same configuration across all machines in the Azure Local instance.

CAUTION: Changing the number of cores impacts the overall core count of the Azure Local instance. To maintain the balance between power and performance, ensure that you are using the correct number of cores.

CPUs. CPU types with instructions
CPU type	Instructions
Intel CPU	Select the number of cores that you want to enable per CPU. Minimum number of cores that can be enabled is four. To manage workloads, you can enable all the cores that you need.
AMD CPU	N/A

To apply the changes and reboot machines, select one of the following options:

If you want to immediately apply the changes and reboot the Azure Local instance machines, select Apply and Reboot Now.
Dell Technologies recommends using this option because the machines are rebooted automatically by using the Cluster-Aware feature to take care of the workloads.
If you want to apply the changes immediately and reboot the Azure Local instance machines later, select Apply at Next Reboot.
To apply the CPU core changes, ensure that you reboot the Azure Local instance machines later. Before rebooting the machines, take care of the workloads.

NOTE: CredSSP must be enabled before you can run Apply and Reboot Now. To improve security, disable CredSSP after the CPU configuration changes are complete.

To apply the changes, click Confirm.

Validate and remediate Azure Local instances

By using the HCI Configuration Profile (HCP) Compliance feature, you can see the Azure Local instance compliance using HCP Compliance checks, see recommendations, and remediate the non-compliant components.

Before you begin

Before you begin, the cluster:

Must be a Dell AX System for Azure Local system
Nodes must have a valid Dell OpenManage Integration with Microsoft Windows Admin Center (OMIMSWAC) premium license installed
Supported node models are listed in the Azure Local Support Matrix.

To run an HCP compliance check in the Dell OpenManage Integration extension, perform the following steps by selecting the single-node cluster in the Cluster Manager:

Procedure

Go to View > Compliance. When another menu appears, select HCP .
The Compliance Summary window appears. If Check Compliance is already enabled, go directly to step 3.
If Check Compliance is disabled, ensure:
- All the prerequisites are met.
- Required inputs are provided in the Configure Cluster Settings tab.
  If not, to save the settings for future use, choose the network topology and the deployment model, and then click Save. To generate compliance for Dell Operating System Configuration policies, the following settings are required:
  - Network topology
    - Fully-converged: All storage ports from the server are connected to the same network fabric. Within the host operating system, the NIC ports are used for both storage and management or VM traffic.
    - Non-converged-Physical: Storage traffic is on the physical storage network adapter ports and management or VM traffic through a SET that is created using network ports of the server rNDC.
    - Non-Converged-Set: Storage traffic uses virtual adapters in the host operating system that is connected to a SET.
  - Deployment model
    - Scalable model supports from 2 to 16 nodes in a cluster and uses top-of-rack (ToR) switches for management and storage traffic networking.
    - Switchless model uses full mesh connections between the cluster nodes for storage traffic and supports from 2 to 4 nodes in a cluster
    - Stretched clusters with Azure Stack HCI operating system consist of nodes residing at two different locations or sites, with each site having two or more nodes, replicating volumes either in synchronous or asynchronous mode.

To view HCP Compliance Summary, click Check Compliance.

Optional: If Internet connection is not available, to run HCP check in offline mode, do the following:

Copy and paste into a browser the URL to the asHCISolutionSupportMatrix.json file from the location that is listed in the following table that is based on the AX node model:

Download locations by AX node model. The table lists the AX server models and provides the download location URL of the relevant JSON file that the user must copy and paste into a browser.
AX node	Download location
Dell AX-4510c Dell AX-4520c Dell AX-640 Dell AX-650 Dell AX-6515 Dell AX-740xd Dell AX-7525 Dell AX-750	https://downloads.dell.com/omimswac/3.5.0/supportmatrix/15G_asHCISolutionSupportMatrix.json.cab
Dell AX-660 and Dell AX-760	https://downloads.dell.com/omimswac/3.5.0/supportmatrix/16G_asHCISolutionSupportMatrix.json.cab
Dell AX-670 and Dell AX-770	https://downloads.dell.com/omimswac/3.5.0/supportmatrix/17G_asHCISolutionSupportMatrix.json.cab

Place the files in C:\Users\Dell\HCPMetaData folder in the gateway system where Windows Admin Center is installed.
Run the HCP Compliance check.

The Dell OpenManage Integration extension fetches the applicable policies, validates the cluster node attributes against the policy attributes, and displays the compliance summary.

To fix non-compliant policies, click Fix Compliance.

WARNING: If the Dell Hardware Symmetry Policy is non-compliant with a Critical error, Fix Compliance is disabled. You are not allowed to remediate other policies until the error is resolved.

Before proceeding to the next step, to resolve the error, review the recommendations, view the details, and then contact Dell Support if required. The critical error states that this aspect of the node configuration is not supported. You must correct the error before you can deploy a symmetric HCI cluster.

Manual Fixes includes policies that require physical interventions and recommendations that can be remediated manually.

NOTE: Ensure that the cluster is compliant with Dell Hardware Symmetry Policy and Dell Operating System Configuration Policies; otherwise, the cluster performance is not guaranteed.

Automatic Fixes includes policies that can be remediated using the Dell OpenManage Integration extension.

To apply the configurations, if any of the policies fixing requires a cluster reboot, select the reboot option by restarting the cluster in Cluster-Aware Updating mode.

Choose from:

Apply and Reboot Now: Immediately applies BIOS, NIC, and iDRAC attributes concurrently to all the cluster nodes and restarts the cluster in Cluster-Aware Updating mode.

Apply at Next Reboot: Applies BIOS, NIC, and iDRAC attributes concurrently to all cluster machines when the cluster machines are restarted at the next maintenance window.

NOTE: If you choose to apply the changes at the next reboot, before the next reboot starts, ensure that you disable the infrastructure lock.

Click the Schedule Reboot checkbox to schedule the date and time when BIOS, NIC, and iDRAC attributes are applied concurrently to all the cluster nodes and restart the clusters in Cluster-Aware Updating mode.

If the infrastructure lock is enabled, a window appears to allow you to disable the lock and then proceed. To allow the Dell OpenManage Integration extension to automatically lock the infrastructure after the operation is complete, select Allow OMIMSWAC.
To trigger the updates, click Apply.
- If Kernel Soft Reboot is enabled for the cluster, the Dell OpenManage Integration extension ignores the trigger and performs a full reboot to apply all BIOS-related settings. For more information, see When to use Kernel Soft Reboot.
- The operation enables CredSSP. To improve security, after the operation is complete, disable CredSSP.
If any error occurs while applying the updates or the update job fails, see Troubleshooting in the latest version of the Dell OpenManage Integration with Microsoft Windows Admin Center User's Guide.
To see the update status and progress at node level, click View Details.
When the status finishes, the Dell OpenManage Integration extension rechecks the compliance and displays the updated compliance summary.
To export the HCP Compliance report to a Microsoft Excel spreadsheet, which can be useful when contacting the Dell Technologies support team, click Export compliance summary.

View HCP compliance summary

Dell OpenManage Integration with Microsoft Windows Admin Center (OMIMSWAC) computes the compliance using different types of Dell HCI Configuration Profile policies, including the following, and displays the report.

Dell Infrastructure Lockdown policy checks whether the Azure Local cluster infrastructure is locked.

Dell Hardware Symmetry policy checks whether cluster machines have validated and supported hardware components and have symmetrical hardware configurations.

Dell HCI Hardware Configuration policy checks whether cluster machines have Dell Technologies recommended BIOS, NIC, and iDRAC configurations.

Dell OS Configuration policy checks whether cluster machines have Dell Technologies and Microsoft recommended operating-system configurations.

For more information about checks, see OpenManage Integration with Microsoft Windows Admin Center.

If the compliance summary is already generated, the last report is displayed with a timestamp. In this case, Re-Check Compliance is enabled. You can click Re-Check Compliance to see the latest compliance report.

The compliance summary is divided into three sections:

Overall Compliance shows the overall compliance of the cluster such as compliance percentage, number of policies compliant, and total number of policies from the displayed policy types.
Overall Compliance State shows overall compliance of the cluster using a doughnut chart and color codes. The color codes indicate different compliance types. You can select different color codes, if any, to filter the respective policy details and its cluster machines. For example, when you select the red color code, policies that are not compliant and their respective cluster machines are displayed. The color codes are as follows:
- Compliant: Shows all cluster machines are compliant with all Dell policies.
- Errors: Shows if any cluster machine is not compliant with Dell Hardware Symmetry policy.
- Warnings: Shows if any cluster machine is not compliant with any optional policies.
- Unknown: Shows if any cluster machine inventory could not be retrieved when the machine is down or not reachable.
The Policy Summary shows compliance of each cluster machine and its components for each policy type:
- Policy Name: Name of Dell policies.
- Description: Description of Dell policies.
- Overall Status: Overall status of compliance of the cluster for each policy type.
- Overall State: How many policies are compliant out of the total number of policies and its percentage.
- Errors: Number of policies that are non-compliant and must be fixed.
- Warnings: Number of policies that are non-compliant and must be fixed.
- Unknown: Number of unknown issues, or unable to run or fetch the data.
- Details: See more information about each machine and its components and their compliance status.

Onboard Dell policies to Azure Arc from Windows Admin Center

To monitor the compliance of Azure Local instances, deploy Dell HCI Configuration Profile (HCP) policies in Azure Arc from Windows Admin Center.

Before you begin

Cluster must be Dell AX System for Azure Local.
Dell OpenManage Integration with Microsoft Windows Admin Center (OMIMSWAC) premium license must be installed on each cluster node.
The target servers that you want to manage must have Internet connectivity to access Azure.
Deploying Azure policies requires that you have administrator rights on the target Windows machine or server to install and configure the agent. Also, you must be a member of the Gateway access roles.
Azure Local instance and Windows Admin Center gateway must be registered in Azure and use the same account to sign in with the resource group with edit rights. For more information about Azure registration, see Register Windows Admin Center with Azure.
In all cluster nodes, Dell Technologies recommends that you ensure that all RDMA -enabled network adapters are connected to the same NIC ports.

Azure Arc is one of the primary management tools for managing resources for cloud and hybrid platforms. Dell Technologies recommends using Dell HCP policies in Azure Arc to maintain compliance with Dell Technologies recommended configurations throughout the life cycle of the Azure Local instance or host.

By using Dell OpenManage Integration for Microsoft Windows Admin Center, you can deploy Dell HCP policies to Azure Arc. And then use these policies in Azure Arc to monitor your cluster. In addition, if multiple clusters are onboarded under the same Azure subscription, you can use the same policy to manage and monitor multiple clusters in the Azure Arc.

To deploy Dell HCP policies to Azure Arc, do the following:

Procedure

Log in to Windows Admin Center.
From the All connections window, select a cluster to connect to it.
Under Extensions, click Dell OpenManage Integration > Select View > Azure Integration.
Click Sign In. A window appears where you can log in to the Azure account.
1. Specify your Azure subscription account details.
When finished, the button changes to Signed-in.
Go to the Onboarding Checklist section. The Dell OpenManage Integration extension verifies and displays the list of prerequisites and shows recommendations if prerequisites are not met.
1. To see the list of prerequisites, status, and recommendations if prerequisites do not match, click Show Details. You cannot move to the next step until all the prerequisites match the requirements.
2. To see the prerequisites with and updated status, click Refresh Checklist.
In the Onboard Policies section:
1. Click View Subscription Details to see the Azure account subscription details.
2. To edit network topology and deployment model settings, click Edit Cluster Settings, specify the details.
3. To save the settings for future use, click Save.
4. Choose from:
  - If policies are not onboarded to Azure Arc, to see the details of applicable Dell HCP policies for onboard and go to the next step, click Onboard Policies.
  - If policies are already onboarded to Azure Arc, to see the details about already onboarded policies, click View Details. To export the onboarded policies in a CSV format, click Export Details.
The Onboard Dell HCI Configuration Profile policies for Azure window displays the available policies for onboarding or updating. The window also shows the version of the previously onboarded policy, if any. All the mandatory policies are selected by default and you cannot change it. You can clear the optional policies, if any.
To onboard or update the onboarded policies, click Onboard.
After the policies are onboarded, the policy onboarding status appears beside Onboard Policies.
To see the Policy Onboarding Status window that displays the status of each policy that was onboarded to the Azure Arc, click View Details.
To export the onboarded policies in a CSV format, click Export Details.
After the policies are onboarded, to monitor your cluster using Dell HCP policies, log in to Azure portal (Azure Arc) using the same subscription account. To find the resources you want to manage, click Resource Groups.
cluster node details display.

To check the cluster compliance, under Settings, click Policies.

The Policy window displays the cluster compliance and lists all the applicable policies including the default policies.

NOTE: Ignore the policy details of the Dell Exempted Policy, which only helps with tracking policy versions of onboarded Dell HCP policies and does not impact cluster performance or compliance.

In Search, to find the policies that are onboarded from the Dell OpenManage Integration extension, enter Dell. To see more details of the compliance for a particular policy, select the policy.
For more information about viewing compliance data in Azure portal, see Get compliance data of Azure resources > Portal.

View recommendations for storage expansion

The following recommendations, using OpenManage Integration with Microsoft Windows Admin Center (OMIMSWAC) extension, enable you to prepare machines for expanding Azure Local instance storage.

Before you begin

The cluster must be Dell AX System for Azure Local
The Azure Local machines must have installed valid OMIMSWAC premium licenses.
The machine models that are supported are listed in the Azure Local Support Matrix.

In an Azure Local cluster, you can expand storage by adding drives on the available slots on the cluster machines. Expanding storage adds storage capacity to the cluster and improves storage performance.

Using the Expand Storage feature, you can view recommendations that are based on HCI Configuration Profile (HCP) policies that enable you to prepare machines for expanding cluster storage.

Procedure

In Windows Admin Center, under Extensions, click Dell OpenManage Integration > Select View > Expand Cluster. From the list menu, select ADD Storage.
If the cluster meets the prerequisites, the Dell OpenManage Integration extension validates the storage configuration of the cluster nodes against HCP policies (Dell Hardware Symmetry Policy rules) and displays the cluster-level status and drives details for each cluster node.
- If Expand Storage is enabled. To see the latest storage configuration details of the cluster machines, click Refresh Storage Inventory.
- If Expand Storage is disabled:
  - The cluster may not fulfill all prerequisites. See the banner message and ensure that the prerequisites mentioned are met. Refresh the cluster inventory, and then try again.
  - The cluster may be noncompliant if its storage configuration does not comply with all critical Dell Hardware Symmetry Policy rules. To make the cluster compliant, go to the HCP Compliance tab, follow the recommendations, and then try again.
To learn more about storage- and disk-specific rules, see OpenManage Integration with Microsoft Windows Admin Center.
If enabled, click Expand Storage.
Storage Expansion Summary appears.

In the Storage Expansion Summary wizard, view the summary about the cluster storage configuration:

Cluster name
Machine counts

Available slot count where storage expansion is possible in that cluster.

If any of the cluster machines has SAS or SATA drives, the available slots display a warning. The exact number of empty slots for drives with media types such as hard drives or solid-state drives may not be derived.

NOTE: Available empty slots are calculated using the total available slots and total connected drives. Calculated slots may not match the number of empty slots for the hard drives or solid-state drives because these drives are embedded in the server chassis.

Used storage
Available storage

If the cluster is noncompliant with a warning, follow the recommendations to make the cluster storage symmetric. The Recommendation section includes the following details:
- The Dell HCP policy rule that does not comply with your cluster
- The drive details that must be added or replaced to make your cluster compliant
When the cluster is compliant ( cluster storage is symmetric), to see storage-expansion recommendations, go back to Step 1 and follow the instructions.

If the cluster is compliant, to see the storage-expanding recommendations, choose one of the storage-expansion options, specify the storage size, and then click Refresh Recommendation. Choose from:

Increase overall capacity: Overall capacity indicates the sum of all disk-storage capacity in a cluster. To increase the overall capacity of the cluster, specify the storage size as available.
Increase usable capacity: Usable capacity indicates the actual storage size that the cluster uses after reserving some storage for fault tolerance (resiliency). Specify the overall usable capacity as available for the entire cluster.

OMIMSWAC displays overall capacity that is based on resiliency type. For more information about fault tolerance and storage efficiency on a cluster, see Fault tolerance and storage efficiency on Azure Stack HCI and Windows Server clusters.

The Recommendation section includes the following information:

Storage displays machine name and number of drives that are required, with recommended media type, and the recommended storage capacity of each drive.

Supported models

NOTE: AGN MU in the model description indicates that the model is vendor agnostic and mixed use.

Manufacturer
Endurance
Actual capacity
Bus protocol
Cache to capacity ratio (only available for hybrid machines)

NOTE:

Recommendations are derived based on possible empty slots present in the machines. For non-uniform media types across the cluster, you may see some warnings, even after following the recommendations.
To order drives, Dell Technologies recommends that you use the bus protocol, model, size that is mentioned in the storage column, and endurance information to identify compatible drives for storage expansion.

After you finish

Insert the recommended drives, and then run HCP compliance to check the updated storage configuration. For any issues, contact Dell Support.

View node-level storage configuration details

The cluster-level status includes the types of cluster storage configuration (whether single-media type or hybrid-media type), total number of drives in all cluster nodes, and the compliance status.

The following table lists the details of the storage configuration compliance statuses:

Compliance statuses for storage configuration. The table lists the details of the storage configuration compliance statuses
Status icon	Status name	Status description
	Compliant	The cluster is compliant for storage expansion as it meets all the prerequisites. Expand Storage is enabled.
	Warnings	The cluster is noncompliant as its storage configuration does not comply with the Dell Hardware Symmetry Policy rules. You can continue to view recommendation for storage expansion. However, before doing a storage expansion, Dell Technologies recommends that you make the cluster compliant by following the recommendations.
	Errors	The cluster is non-compliant as its storage configuration does not comply with some of the critical Dell Hardware Symmetry Policy rules. Expand Storage is disabled. You cannot do a storage expansion. Dell Technologies recommends that you make the cluster compliant by following the recommendations, and then doing the storage expansion.

The following list shows drive details for each cluster node that is displayed.

Node status:
- Green: Compliant, when there is no critical error or warning
- Yellow: Non-compliant but not critical, there is some warning
- Red: Non-compliant (Critical), there is critical error
Serial number
Slot number (if applicable)
Media type
Bus protocol
Model: If present, AGN MU in the model description indicates that the drive is vendor agnostic and of mixed use.
Manufacturer
Capacity
Endurance
Used for cache or capacity type
Cache or capacity ratio (available only for hybrid media types)

Post-deployment Updates and Maintenance

Post-deployment best practices

Dell Technologies recommends that you follow the guidelines that are described in this section.

Antivirus exclusions

As part of best practices, Dell Technologies and Microsoft recommend that you plan appropriate antivirus exclusions.

Azure Local instance machines by default are deployed and configured with security features including Microsoft Defender Antivirus.

If you prefer to use non-Microsoft antivirus and security software, Dell Technologies and Microsoft recommend that your vendor has validated your preferred software for Azure Local.

Follow the guidance and antivirus exclusions on Security features for Azure Local.

CAUTION: If your antivirus software is not cluster-aware, see Antivirus software that isn't cluster-aware may cause problems with Cluster Services.

Suspend and resume a cluster node

Before you begin

Ensure the following:

You have local administrator privileges to access the cluster node
Cluster node is running Azure Local version 2311.2 or later
Client used to connect to Azure Local has PowerShell installed
Suspend or resume the cluster node in Windows Failover Clustering

NOTE: Verify the health status of the cluster and volumes before and after the process using the relevant PowerShell commands.

To suspend and then resume a cluster node for maintenance, do the following:

Procedure

Suspend node

Log in to a node on the cluster with local administrator credentials.
To stop the virtual machines and suspend the node, run the following command as an administrator:
```
Suspend-ClusterNode -Name "<MachineName>" -Drain
```
This step may take some time, depending on the number of virtual machines that are migrated.
To confirm the node is suspended, run the following command:
```
Get-ClusterNode
```

Resume node

Log in to a node on the cluster with local administrator credentials.
To resume the node, run the following command as an administrator:
```
Resume-ClusterNode -Name "<machineName>" -failback immediately
```
This step may take some time, depending on the number of virtual machines that are migrated.
To confirm the node is resumed, run the following command:
```
Get-ClusterNode
```

To verify the health of the storage pool, run the following command:

Get-StoragePool -FriendlyName "<StoragePoolName>"

NOTE: If the pool is not reported as healthy, to check the status of the storage repair jobs, run the following command:

Get-StorageJob

Results

For more information, see Suspend and resume Azure Local machines for maintenance.

Azure Local instance machine expansion

In an Azure Local instance, adding server machines:

Increases the storage capacity
Improves the overall storage performance of the cluster
Provides more compute resources to add virtual machines

Before adding new server machines to an Azure Local cluster, you must complete the following requirements:

Verify that the processor model, HBA, and NICs are of the same configuration as the current machines on the cluster and PCIe slots.

Ensure that all disk types and the amount in each machine are the same as the machine in use.

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

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

Options to expand cluster storage capacity . Conditions for two options to expand storage capacity of a cluster
Option 1 conditions	Option 2 conditions
Drive is listed in the Support Matrix Same drive manufacturer Same capacity and endurance Latest model Latest firmware	Drive is listed in the Support Matrix Different drive manufacturer Same capacity and endurance Different model Different firmware

Ensure that the BIOS, drivers, firmware, and chipset are as listed in the Support Matrix.
Apply the BIOS configuration to the machine and configure iDRAC.

Add a node to the rack or chassis

To expand the number of AX nodes in a cluster, you must first add a physical node to the rack or chassis in the Dell AX System for Azure Local solution.

Most Dell AX nodes are mounted in a server rack, except for compute sleds that are mounted in a chassis. The following table lists the node models and whether they are rack- or chassis-mounted.

Where to mount an AX node based on server model. This table lists the Dell servers and describes whether they are mount on a rack or a chassis.
AX node	Mounted on
Dell AX-6515 Dell AX-650 Dell AX-660 Dell AX-7525 Dell AX-740xd Dell AX-750 Dell AX-760	Rack
Dell AX-4510c and Dell AX-4520c	Chassis

To add a node to a rack or chassis, do the following:

NOTE: These steps are written for a chassis but the rack steps are very similar.

Procedure

Identify a node with the same hardware configuration as the other nodes in the cluster.

Ensure that the existing chassis has a free slot to accommodate the node expansion. If there is no free slot, you need a new chassis.

NOTE: Powering off a chassis is optional.

Remove the blanking panel, open the chassis front door, and then identify the correct slot that is based on the slot number.
Insert and slide the node into the free slot using the guide rails. Use the locking mechanism or latches to secure the node in place.

After you finish

After installing the node, you must do the post-installation operations such as configuring the iDRAC, running hardware diagnostics, installing the operating system, and so on. See Adding machines to an Azure Local instance

Adding machines to an 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 add additional machines to these Azure Local instances.

Before you can add a machine to your Azure Local instance, you must ensure that the Prerequisites are met.

Prerequisites for adding machine to Azure Local instance

To increase compute and storage capacity, you can scale out an existing Azure Local instance by adding one or more machines.

NOTE: Machine additions must be performed sequentially. Only one machine can be added at a time.

Before you can add a machine to an Azure Local instance, ensure that the following prerequisites are met:

Procedure

Ensure that the new machine matches the model of the existing cluster machines and has identical hardware configuration.
Establish network connections for both the management and storage ports.
To verify that all machines in an Azure Local instance are running the same operating system version, run the following command:
```
Get-ComputerInfo | format-list OSDisplayVersion, OSVersion
```
To identify the existing cluster solution version, run the following command:
```
Get-SolutionUpdateEnvironment | Select-Object CurrentVersion
```

To download the required Dell Golden Image for your machine expansion, do the following:

Go to Support Matrix on GitHub.
Click the link for the release version that is compatible with the solution version of your existing Azure Local instance.
In the release version window, click the link to the Azure Local Golden Images <release> window.

In the Azure Local Golden Images <release> window, find the compatible golden image, as shown in the following table, and then click the golden-image name. The link opens the golden-image download page on dell.com. You must be logged in to view the contents.

Examples of compatible solution versions and golden image versions. The following table provides examples of compatible Azure Local instance solution versions and golden image versions
Existing Azure Local instance solution version	Golden image version to download for machine addition
11.2510.1002	11.2510..
12.*.1002	12.2510..

To download the golden image, click Download.

To verify the registration status of each machine, ensure all machines are connected, and then run the following command:
```
Get-AzureStackHCI
```
To ensure that the storage pool is in a healthy state, run the following command:
```
Get-StoragePool
```
To verify that the virtual disks are healthy, run the following command:
```
Get-VirtualDisk | Select-Object FriendlyName, HealthStatus
```
To verify that no current issues are reported on the cluster, run the following command on any of the existing Azure Local instance machines:
```
Get-HealthFault
```

Results

For more information about prerequisites for adding a machine, see the Microsoft Add a node on Azure Local > Prerequisites

After you finish

After completing all prerequisites, you can install the operating system on the newly added machine.

Install operating system on machine

Before you begin

You must ensure that the prerequisites are met.

To install the operating system onto the machine using the golden image that you downloaded during the prerequisites, do the following:

Procedure

To install the operating system, see Manually deploy operating system using Dell golden-image ISO
To configure host networking, see Configure host networking
To change the hostname to match the naming pattern that the existing Azure Local instance machines use, see Change the hostname

To register the machine with Azure Arc, see Register machines with Azure Arc

When you run the Arc registration, you must specify the Azure Local instance solution version using the following command:

Invoke-AzStackHciArcInitialization [Documented Parameters] -TargetSolutionVersion [Solution Version]

NOTE: The following parameters for Arc registration command must match the existing Azure Local instance machines:

ResourceGroup
SubscriptionID
TenantId
Cloud

After you finish

After completing the installation, you can add the machine to your Azure Local instance.

Add machine to Azure Local instance

Before you begin

Ensure that the prerequisites are met and that you have installed the operating system on the machine.

NOTE: For Active Directory domain membership, you do not have to manually join the domain of the machine to your Active Directory. This process is automatically managed as part of the Add-Server workflow.

CAUTION: Prior to or during the machine onboarding process, do not manually install Windows updates. This process is automatically managed as part of the Add-Server workflow.

To add a machine to an Azure Local instance, do the following:

Procedure

Log in to an existing machine using the Lifecycle Management (LCM) user credentials (Deployment user).

To add the machine using a local administrator credential for the machine, run the following command:

$HostIpv4 = "<Management  IP of the new node>"
#provide the local admin credentials of the new node.
$Cred = Get-Credential
Add-Server -Name "<Host name of the new node>" -HostIpv4 $HostIpv4 -LocalAdminCredential $Cred

NOTE: The Add-Server command saves the Operation ID of the machine that you use in the next step.

To monitor the machine progress, use the Operation ID that you saved to run the following command:
```
$ID = "<Operation ID>" 
Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID
```
After the machine is added to the Azure Local instance, to verify the status of the rebalancing process, run the following command:
```
Get-VirtualDisk | Get-StorageJob
```
When the rebalancing process is finished, the command does not display any results.
To sync the node to Azure portal, run the following command:
```
Sync-AzureStackHCI
```

After you finish

After the machine is added to the Azure Local instance, you must verify the Azure Local instance health.

Verify the health of Azure Local instance

After you add a machine to an Azure Local instance, you must verify the health of the instance.

Before you begin

Ensure that:

All prerequisites for adding a machine to an Azure Local instance are met
The machine is installed with the correct operating system and has been added to your Azure Local instance

To verify the Azure Local instance do the following:

Procedure

To view the status and confirm the addition of the machine on the Azure Local instance, run the following command:
```
Get-ClusterNode
```
To verify the registration status of each machine and to ensure that all machines are connected, run the following command:
```
Get-AzureStackHCI
```
To ensure that the storage pool is in a healthy state, run the following command:
```
Get-StoragePool
```
To verify that no current issues are reported on the Azure Local instance, run the following command on any of the existing machine:
```
Get-HealthFault
```
To verify that the machine extension of the Azure Local instance is successful, go to the Azure portal to view the information in the Extensions window, as shown in the following figure.

Results

For more information about adding a machine, see Add a node on Azure Local

Extending volumes

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.

Storage Spaces Direct storage expansion

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.

Repairing machines in Azure Local instances

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

Prerequisites for repairing a machine in an Azure Local instance

NOTE: Repairing a machine in your Azure Local instance is supported for both scalable and switchless storage networking.

Before you can repair a machine in your Azure Local instance, ensure that the following prerequisites are met:

Procedure

To verify that all machines in an Azure Local instance are running the same operating system version, run the following command:
```
Get-ComputerInfo -Property OSDisplayVersion,OSVersion
```
To identify the existing Azure Local instance solution version, run the following command on an existing Azure Local machine:
```
Get-SolutionUpdateEnvironment | Select-Object CurrentVersion
```

To download the required Dell Golden Image for your machine repair, do the following:

Go to Support Matrix on GitHub.
Click the link for the release version that is compatible with the solution version of your existing Azure Local instance.
In the release version window, click the link to the Azure Local Golden Images <release> window.

In the Azure Local Golden Images <release> window, find the compatible golden image, as shown in the following table, and then click the golden-image name. The link opens the golden-image download page on dell.com. You must be logged in to view the contents.

Examples of compatible solution versions and golden image versions. The following table provides examples of compatible Azure Local instance solution versions and golden image versions
Existing Azure Local instance solution version	Golden image version to download for machine repair
11.2510.1002	11.2510..
12.*.1002	12.2510..

To download the golden image, click Download.

To verify the registration status of each machine:
1. Ensure that all machines are connected, and then run the following command:
```
Get-AzureStackHCI
```
2. In the output, locate RegistrationStatus. The field status should display as Registered.

Results

For more information about prerequisites for repairing a machine, see Prerequisites > Repair a node

After you finish

After completing all prerequisites, you can reinstall the operating system and repair the faulty machine.

Install operating system on repaired machine

Before you begin

You must ensure that the prerequisites for repairing the machine in the Azure Local instance are met.

To install the operating system onto the machine using the golden image that you downloaded during the prerequisites, do the following:

Procedure

To remove the faulty Azure arc machine from the resource group, see Repair a node on Azure Local.
To remove the faulty Azure Local instance machine from Active Directory, run the following command:
```
Remove-ADComputer -Identity <computer name>
```
For example, see Remove-ADComputer.

If applicable, to remove an existing data disk, see Node replacement.

To install the operating system, see Manually deploy operating system using Dell golden-image ISO

NOTE: You must clean the operating system installation drive (BOSS) during setup.

During setup, to clean the BOSS drive, do the following:

Boot from the golden image ISO.
After the system boots into the Installer, to launch a Command Prompt window, press the Shift and F10 keys together.
In the Command Prompt window, enter diskpart and click Enter.
To view the available drives, enter list disk and click Enter.

Identify which drive is the BOSS. In the example shown in the following figure, Disk 4 is the BOSS.

CAUTION: Ensure that you correctly identify the drive that is the BOOT; the output might differ.

screenshot of an example showing a drive being identified

To select the drive that you want to clean, enter select disk [number], for example select disk 4, and then press Enter.
To clean the selected drive (BOSS in this case), enter clean, and then press Enter.
Exit diskpart and proceed with installing the operating system on the BOSS.

To configure host networking:
- For scalable storage, see Configure host networking in this guide.
- For switchless storage, see Configure host networking in Deployment and Operations Guide with Scalable Storage Networking.
To change the hostname to match the naming pattern that the existing Azure Local instance machines use, see Change the hostname.

Re-create the local admin user with the same name and password. See Create a local user and add to the local Administrators group in this guide.

NOTE: Perform this step while deploying using Local Identity with Azure Key Vault.

To register the machine with Azure Arc, see Register machines with Azure Arc

NOTE: The following parameters for Arc registration command must match the existing Azure Local instance machines:

ResourceGroup
SubscriptionID
TenantId
Cloud
TargetSolutionVersion

After you finish

After the operating system is installed, you can add the repaired machine back into your Azure Local instance.

Add repaired machine to Azure Local instance

Before you begin

Ensure that:

The Microsoft prerequisites are met
You have installed the operating system on the repaired machine.
You have removed the machine entry from the Computers folder in Active Directory.
For local identity deployment only: You have created the same local user account and added it to the local administrator group
For local identity deployment only: You have removed the faulty Azure Arc machine from the Azure Resource Group

To add a repaired machine back into an Azure Local instance, do the following:

Procedure

Remove the machine name from the Azure portal resource group.
When you run the Arc registration, you must specify the Azure Local instance solution version using the following command:
```
Invoke-AzStackHciArcInitialization -TargetSolutionVersion [Solution Version]
```

Register the node with Arc.

NOTE: When performing the step "Register the node with Arc" that is listed in Repair a node on Azure Local, you must run the following command and specify the version that matches the existing Azure Local instance:

Invoke-AzStackHciArcInitialization -TenantId <Tenant_ID> -SubscriptionID <Subscription_ID> -ResourceGroup <RG Name> -Region <location> -TargetSolutionVersion <TargetSolutionVersion>

After registering the node with Azure Arc, reassign the required Azure RBAC roles. For more information, see Assign required permissions for Azure Local deployment.
Verify that the identity used by the cluster (managed identity or service principal) has Get, List, and Backup permissions for secrets in the Azure Key Vault. Also, assign the Key Vault Secrets Officer role on the Key Vault to the nodes’ managed identity (Azure Arc–enabled server resources).
Log in to an existing Azure Local instance machine using the Lifecycle Management (LCM) user credentials (Deployment user).

To repair a machine using a local administrator credential for the repaired machine, run the following command:

#provide the local admin credentials of the repaired node.
$Cred = Get-Credential
Repair-Server -Name "<Name of the new node>" -LocalAdminCredential $Cred

NOTE: Save the Action Plan Instance ID of the machine to use in the next step.

To monitor the machine progress, use the Action Plan Instance ID that you saved to run the following command:
```
$ID = "<Operation ID>" 
Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID
```
After the repaired machine is added to the Azure Local instance, to verify the status of the rebalancing process, run the following command:
```
Get-VirtualDisk | Get-StorageJob
```
When the rebalancing process is finished, the command does not display any results.
To sync the node to Azure portal, run the following command:
```
Sync-AzureStackHCI
```

After you finish

After the machine is added to the Azure Local instance, you must verify the Azure Local instance health.

Verify the health of Azure Local instance

After you repair a machine on an Azure Local instance, you must verify the health of the instance.

Before you begin

Ensure that the Repair-Server cmdlet for the repaired machine is completed successfully.

Upon successful completion of the repair procedure, run the following post‑repair health checks to verify that the Azure Local instance is stable and operating correctly.

Procedure

To verify the registration status of each machine and to ensure that all machines are connected, run the following command:
```
Get-AzureStackHCI
```
To ensure that the storage pool is in a healthy state, run the following command:
```
Get-StoragePool
```
To verify that no current issues are reported on the Azure Local instance, run the following command on any of the existing machines:
```
Get-HealthFault
```

To verify that the addition of the repaired machine to the Azure Local instance, go to the Azure portal to view the information in the Extensions window, as shown in the following figure.

Azure portal Extensions window showing succesful machine installations

NOTE: It may take some time for you to see the addition of the repaired machine reflected in the Extensions window.

To view the status of the repaired machine, run the following command:
```
Get-ClusterNode
```
To view the status of the physical disks across the Azure Local Instance, run the following command:
```
Get-PhysicalDisk
# Expected result: OperationalStatus = OK and HealthStatus = Healthy
```
Verify that the secrets for the repaired machine are updated in Azure Key Vault by doing the following:
1. In the Azure portal, open the associated Key Vault and go to Secrets.
2. For each secret related to the repaired machine, open the latest version and check the Created/Updated timestamp to confirm that the secret was backed up recently.
Sample Secrets of a Key Vault

Results

For more information about repairing a machine, see Repair a node on Azure Local.

FullPowerCycle

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

Secure connect gateway

Secure connect gateway (SCG) is an enterprise monitoring technology that is delivered as an appliance and a stand-alone application. It monitors your devices and proactively detects hardware issues that may occur. Depending on your service contract, it also automates support request creation for issues that are detected on the monitored devices. When a hardware issue is detected, SCG automatically collects the telemetry that is required for troubleshooting the issue. The collected telemetry helps technical support to provide a proactive and personalized support experience.

For more information about SCG, see Secure Connect Gateway - Application Edition.

References

Dell Technologies documentation

These links provide more information from Dell Technologies:

Dell AX Solutions for Microsoft documentation
Dell AX System for Azure Local specification sheet
iDRAC documentation
Azure Local Support Matrix
For more information about manually configuring iDRAC, see PowerEdge: Support Articles for the iDRAC and the CMC.