Introduction

Azure Stack HCI is a virtualized workload solution from Microsoft that allows businesses to run Windows and Linux apps and services in a hybrid on-premise/cloud environment. Built on top of Windows Server, Azure Stack HCI is an example of hyperconverged infrastructure (HCI). This technology virtualizes conventionally hardware-defined systems like storage and networking to create flexible, efficient infrastructure solutions.

Key Use cases

Discovery Use cases

• It discovers the AzureStack HCI components.
• Publishes relationships between resources to have a topological view and ease of maintenance.

Monitoring Use cases

• Provides metrics related to job scheduling time and status etc.
• Concern alerts will be generated for each metric to notify the administrator regarding the issue with the resource.

Supported Target Versions

Validated the application by executing powershell script against
Azure stack HCI version 22H2, OS build 20349

Prerequisites

• OpsRamp Classic Gateway (Linux) version 15.0.0 or later.
• OpsRamp NextGen Gateway version 15.0.0 or later.

• The Gateway must resolve and reach the HCI cluster and every cluster node.

• Open TCP port 22 for PowerShell over SSH.

• For legacy PowerShell Remoting, open TCP ports 5985 and/or 5986.

  Note: By default, WS-Man and PowerShell remoting use port 5985 and 5986 for connections over HTTP and HTTPS, users should be present in nodes and cluster.

Non-Admin User Privileges

  The following permissions are required regardless of the selected connection option:  

• Configure the non-administrator user on the target cluster and all applicable nodes.  

  Note

  Execute all commands in an elevated PowerShell session (Run as Administrator).
   

1. Add User to the Performance Monitor Users Group

The user must be a member of the Performance Monitor Users group to collect performance counter metrics.

net localgroup "Performance Monitor Users" /add "<user>"

2. Add User to the Hyper-V Administrators Group

The user must be added to the Hyper-V Administrators local group on every Hyper-V node.

Option 1: Using PowerShell (Recommended)

Add a Domain User

Add-LocalGroupMember -Group "Hyper-V Administrators" -Member "<domain\user>"`

Add a Local User

Add-LocalGroupMember -Group "Hyper-V Administrators" -Member "<domain\user>"`

Verify Group Membership

net localgroup "Hyper-V Administrators" | Select-String "<domain\user>"`

Option 2: Using Computer Management (GUI)

1. Click Start → Run, type lusrmgr.msc, and click OK.
2. Navigate to Local Users and Groups → Groups.
3. Open the Hyper-V Administrators group.
4. Right-click Hyper-V Administrators and select Properties.
5. Click Add.
6. Enter the user account name and click Check Names.
7. Click OK.
8. Click Apply, then OK.
9. Close the Properties window.
10. Restart Windows to ensure the changes take effect. Important: If the non-administrator user is not a member of the Hyper-V Administrators group, virtual machine discovery, virtual switch discovery, and monitoring operations will not function correctly in OpsRamp.

3. Grant Remote WMI Read-Only Permissions

To grant remote WMI read-only access, perform the following steps on each monitored system:

1. Press Windows Key + R, type wmimgmt.msc, and press Enter.
2. In the left pane, right-click WMI Control (Local) and select Properties.
3. Navigate to the Security tab.
4. Expand Root and select CIMV2.
5. Click Security.
6. Click Add, enter the non-administrator user account, and click OK.
7. Select the user and grant only the following permissions:
   • Enable Account (allows local read access)
   • Remote Enable (allows remote read access)
   • Execute Methods and Read Security only if the product requires them.
8. To apply the permissions to child namespaces, click Advanced, select the account, click Edit, and set Applies to to This namespace and subnamespaces.
9. Click OK, then Apply, and close all WMI management windows.

4. Grant Remote WMI Read-Only Permissions for Storage

To grant remote WMI read-only access, perform the following steps on each monitored system:

1. Press Windows Key + R, type wmimgmt.msc, and press Enter.
2. In the left pane, right-click WMI Control (Local) and select Properties.
3. Navigate to the Security tab.
4. Expand Root → Microsoft → Windows and select Storage.
5. Click Security.
6. Click Add, enter the non-administrator user account, and click OK.
7. Select the user and grant only the following permissions:
   • Enable Account (allows local read access)
   • Remote Enable (allows remote read access)
   • Execute Methods and Read Security only if the product requires them.
8. To apply the permissions to child namespaces, click Advanced, select the account, click Edit, and set Applies to to This namespace and subnamespaces.
9. Click OK, then Apply, and close all WMI management windows.

Execute Methods allows method execution, so the permissions aren’t strictly read-only if that permission is granted. Enable Account and Remote Enable are the core permissions for remote WMI access; follow the product’s requirements for any additional permissions.

5. Grant Read-Only Failover Cluster Access

The domain user must be granted read-only access to the failover cluster.

Grant-ClusterAccess -User "<domain\user>" -ReadOnly

For monitoring services like Windows Cluster Service, Windows domain users must be a part of the Local Administrators group as the integration uses win32_Service class for fetching the details. Refer to Get-CimInstance.
If the non-administrator monitoring account cannot retrieve Windows service information because of insufficient permissions, follow these steps to grant read/query access without adding the account to the local Administrators group.

Refer the steps Enable Windows Service Monitoring Permissions.

Connection Modes

Starting from Azure Stack HCI version 5.1.0, the option to select the connectionMode is available. The supported options are:

• PowerShell (existing)
• OpenSSH (new)

Note: PowerShell Remoting over WinRM is deprecated and will no longer be supported in the applicable updated application versions. These instructions apply only to earlier application versions that still support this connection option.

PowerShell Remoting over WinRM

Configuration steps

• Enable PowerShell Remoting on every applicable target:

    Enable-PSRemoting -Force

• Add the user to Remote Management Users:

    net localgroup "Remote Management Users" /add "<user>"

• Add the OpsRamp Gateway IP to TrustedHosts:

    Set-Item WSMan:\localhost\Client\TrustedHosts -Force -Concatenate -Value "<OpsRampGatewayIP>"

To allow any host, when explicitly required:

    Set-Item WSMan:\localhost\Client\TrustedHosts -Force -Value "*"

• Configure and restart WinRM:

    Set-Service WinRM -StartupType Automatic
    Restart-Service WinRM -Force

• Open WinRM ports on every applicable target:
  • 5985 for WinRM over HTTP.
  • 5986 for WinRM over HTTPS.

PowerShell pre-checks

Verify network connectivity from the Gateway:

ping <IP-address-or-hostname>
telnet <IP-address-or-hostname> 5985
telnet <IP-address-or-hostname> 5986

• For a Classic Gateway, launch PowerShell directly:

    pwsh

• For a NextGen Gateway, enter the NativeBridge container and launch PowerShell:

    kubectl exec -it nextgen-gw-0 -c nativebridge -- /bin/bash
    pwsh

Test PowerShell Remoting using the integration credential:

$password = ConvertTo-SecureString -AsPlainText -Force -String "<password>"
$credential = New-Object `
        -TypeName System.Management.Automation.PSCredential `
        -ArgumentList "<username>", $password
$session = New-PSSession `
        -ComputerName "<IP-address-or-hostname>" `
        -Credential $credential `
        -Authentication Negotiate `
        -ErrorAction Stop
$session.State

The session state must be Open. Close the test session:

Remove-PSSession $session

A successful PowerShell session confirms connectivity and authentication only. The user must also have the application-specific permissions required to execute discovery and monitoring commands.

PowerShell over SSH using OpenSSH

The non-administrator user must have the following privileges:

• Membership in the Performance Monitor Users group.
• Membership in the Hyper-V Administrators group on all Hyper-V nodes.
• Remote WMI read-only access to the Root\CIMV2 & Root\Microsoft\Windows\Storage namespace and subnamespaces.
• Read-only access to the failover cluster.

Pre-checks

Check whether OpenSSH Server is installed:

Get-WindowsCapability -Online -Name OpenSSH.Server*

Check the SSH service:

Get-Service sshd

Configuration steps

• Install OpenSSH Server if it is not already installed:

    Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

• Start sshd and configure automatic startup:

    Start-Service sshd
    Set-Service sshd -StartupType Automatic

• Open inbound TCP port 22:

    New-NetFirewallRule `
            -Name "Allow-SSH-Port-22" `
            -DisplayName "Allow SSH Port 22" `
            -Protocol TCP `
            -Direction Inbound `
            -LocalPort 22 `
            -Action Allow `
            -Profile Domain,Private,Public

• Open C:\ProgramData\ssh\sshd_config as an administrator:

    notepad C:\ProgramData\ssh\sshd_config

• Configure password authentication and the permitted user:

    PasswordAuthentication yes
    AllowUsers <ssh-username>

• Set Windows PowerShell as the OpenSSH default shell:

    Set-ItemProperty `
            -Path "HKLM:\SOFTWARE\OpenSSH" `
            -Name DefaultShell `
            -Value "$PSHOME\powershell.exe"

• Restart sshd and confirm that it is running:

    Restart-Service sshd
    Get-Service sshd

Validate connectivity from the Gateway

ping <IP-address-or-hostname>
telnet <IP-address-or-hostname> 22
ssh <username>@<IP-address-or-hostname>

The SSH connection must be established successfully, and PowerShell must be configured as the default shell. After connecting, run the following command to verify the installed PowerShell version and confirm that the active shell is PowerShell:

$PSVersionTable.PSVersion

Hierarchy of Azure Stack HCI Resources

• Azure stack HCI Cluster
  • Azure stack HCI Server
    • Azure stack HCI Virtual Switch
    • Azure stack HCI Node Disk
    • Azure stack HCI Guest Virtual Machine
    • Azure Stack HCI Node Physical Disk
  • Azure stack HCI Cluster Role
  • Azure stack HCI Cluster Disk
  • Azure stack HCI Cluster Shared Volume
  • Azure stack HCI Cluster Storage Pool

Supported Metrics

Default Monitoring Configurations

AzureStack HCI has default Global Device Management Policies, Global Templates, Global Monitors and Global metrics in OpsRamp. You can customize these default monitoring configurations as per your business use cases by cloning respective Global Templates and Global Device Management Policies. OpsRamp recommends performing the below activity before installing the application to avoid noise alerts and data.

1. Default Global Device Management Policies

   OpsRamp has a Global Device Management Policy for each Native Type of AirWave Management Platform. You can find those Device Management Policies at Setup > Resources > Device Management Policies, search with suggested names in global scope. Each Device Management Policy follows below naming convention:

   {appName nativeType - version}

   Ex: azure-stack-hci Azure stack HCI Cluster - 1 (i.e, appName = azure-stack-hci, nativeType = Azure stack HCI Cluster, version = 1)

2. Default Global Templates

   OpsRamp has a Global template for each Native Type of AirWave Management Platform. You can find those templates at Setup > Monitoring > Templates, search with suggested names in global scope. Each template follows below naming convention:

   {appName nativeType 'Template' - version}

   Ex: aruba-airwave Azure stack HCI Cluster Template - 1 (i.e, appName = aruba-airwave , nativeType = Azure stack HCI Cluster, version = 1)

3. Default Global Monitors

   OpsRamp has a Global Monitors for each Native Type which has monitoring support. You can find those monitors at Setup > Monitoring > Monitors, search with suggested names in global scope. Each Monitors follows below naming convention:

   {monitorKey appName nativeType - version}

   Ex: Azure stack HCI Cluster Monitor azure-stack-hci Azure stack HCI Cluster 1 (i.e, monitorKey = Azure stack HCI Cluster Monitor, appName = azure-stack-hci , nativeType = Azure stack HCI Cluster, version= 1)

Configure and Install the AzureStack HCI Integration

1. From All Clients, select a client.
2. Navigate to Setup > Account.
3. Select the Integrations and Apps tab.
4. The Installed Integrations page, where all the installed applications are displayed. If there are no installed applications, it will navigate to the Available Integrations and Apps page.
5. Click + ADD on the Installed Integrations page. The Available Integrations and Apps page displays all the available applications along with the newly created application with the version.
   Note: Search for the application using the search option available. Also you can use the All Categories option to search.
6. Click ADD in the Azure Stack HCI Cluster application.
7. In the Configurations page, click + ADD. The Add Configuration page appears.
8. Enter the below mentioned BASIC INFORMATION:

Notes:

• Access IP Address/Host Name from Gateway.
• If the App Failure Notifications is enabled, you will be notified in case of an application failure i.e., Connectivity Exception and Authentication Exception.
• Azure Stack HCI Server IP Discovery – Network Management Name Requirement. At present, Azure Stack HCI server IP addresses are discovered by default by filtering network management names containing ‘vManagement’ and ‘vEthernet’.
  If the cluster uses network management names other than these defaults names, you must provide the appropriate names manually.
  To retrieve the network management names, you can use the following PowerShell command:
  Get-ClusterNetwork | Where-Object {$_.Role -eq “ClusterAndClient”} | Get-ClusterNetworkInterface | Select-Object Address, State, Name
  This command returns output including the Name field, which should be used for discovery.
  Example Output:
  Address: 1.1.1.1
  Node: virtualbox
  State: Up
  

Name: virtualbox - Team

PSComputerName: 1.1.1.1
RunspaceId: 12345

In this case, the value to be provided is: Team

9. Select the below mentioned Custom Attribute:

Note: The custom attribute that you add here will be assigned to all the resources that are created by the integration. You can add a maximum of five custom attributes (key and value pair).

10. In the Native Types section, select the native types to be discovered.
11. In the DISCOVERY SCHEDULE section, select Recurrence Pattern to add one of the following patterns:
    • Minutes
    • Hourly
    • Daily
    • Weekly
    • Monthly
12. Click ADD.

Now the configuration is saved and displayed on the configurations page after you save it.
Note: From the same page, you may Edit and Remove the created configuration.

13. Click NEXT
14. Below are the optional steps you can perform on the Installation page.

• Under the ADVANCED SETTINGS, Select the Bypass Resource Reconciliation option, if you wish to bypass resource reconciliation when encountering the same resources discovered by multiple applications.

  Note: If two different applications provide identical discovery attributes, two separate resources will be generated with those respective attributes from the individual discoveries.

• Click +ADD to create a new collector by providing a name or use the pre-populated name.

15. Select an existing registered profile.
16. Click FINISH.

The integration is installed and displayed on the INSTALLED INTEGRATION page. Use the search field to find the installed integration.

Modify the Configuration

• See Modify an Installed Integration or Application article.

  Note: Select the Azure Stack HCI Cluster application.

View the Azure Stack HCI Cluster Details

The Azure Stack HCI Cluster integration is displayed in the Infrastructure > Search > Hyperconverged Infrastructure > Azure Stack HCI Cluster. You can navigate to the Attributes tab to view the discovery details and Metrics tab to view the metric details for Azure Stack HCI.

View resource metrics

To confirm Azure Stack HCI Cluster monitoring, review the following:

• Metric graphs: A graph is plotted for each metric that is enabled in the configuration.
• Alerts: Alerts are generated for metrics that are configured as defined for integration.

Resource Filter Input keys

Azure Stack HCI app Resources are filtered and discovered based on the following keys.

Supported Alert Custom Macros

Customise the alert subject and description with below macros then it will generate alert based on customisation.

Risks, Limitations & Assumptions

• For Cluster object discovery and monitoring implementation, we are considering the object which has Name equals to Cluster Name in Get-ClusterResource response.

• For ClusterGroup monitoring implementation, we are considering the object which has name as Cluster Group in Get-ClusterGroup response.

• Application can handle Critical/Recovery failure notifications for below two cases when user enables App Failure Notifications in configuration:

  • Connectivity Exception
  • Authentication Exception

• Application will not send any duplicate/repeat failure alert notification until the already existing critical alert is recovered.

• If user enables agent monitoring templates on the Cluster/Node resource, the user might see the duplicate metrics with different naming conventions.

• While trying to fetch the node ip address we receive multiple node ips, which will include many local ips and actual ips (example: let’s consider actual node ip is 10.1.1.1 when trying to fetch the details we will receive two ips one associated with cluster (192.168.0.0) and other is the actual ip). To identify the actual node ip address from the list of ip addresses received we assume that node ip address is part of the same subnet of cluster ip address meaning if cluster ip is 10.1.1.1 then node ips will be 10.1.X.X.

• We have provided the provision to give Cluster Ip Address OR HostName in configuration, but hostName provision will work only if the host name resolution works.

• Classic gateway requires additional libraries to be packaged which are needed to execute the powershell script to achieve this integration approach.

• This application supports only Classic Gateway and NextGen Gateway. Not supported with Cluster Gateway.

• The Template Applied Time will only be displayed if the collector profile (Classic and NextGen Gateway) is version 18.1.0 or higher.

• Component level thresholds can be configured on each resource level.

• Optional configuration parameters can be defined.

• Application upgrade is an automated process with version change.

• Native Bridge Memory Sizing for Azure Stack HCI in NextGen Gateway

  • Native Bridge calls shows 500MB limit supports upto 9 simultaneous calls.
    Each Azure Stack HCI configuration requires minimum four monitoring calls per cycle (three‑node cluster) scales linearly as node counts increase.
  • Default Native Bridge memory (500MB) - must be increased based on Azure Stack cluster configurations. If if Your Environment 7 Azure Stack clusters with 3 nodes each: 7 × 4 = 28 calls per cycle exceeds 500MB limit, requiring 2GB minimum allocation.
  • Memory Sizing Guidelines:
    Formula explanation
    Total calls per config = (clusters × nodes per cluster) + clusters
    Examples:
    1 cluster, 1 node : (1 × 1) + 1 = 2 calls
    1 cluster, 2 nodes : (1 × 2) + 1 = 3 calls
    5 clusters, 4 nodes per cluster: (5 × 4) + 5 = 25 calls
    9 clusters, 4 nodes per cluster: (9 × 4) + 9 = 45 calls
    

  Clusters	Nodes/Server	Total Calls	Native Bridge Memory
  1	3	4	500MB (Default)
  1	4	5	500MB
  2	3	8	500MB
  4	3	16	1GB
  8	3	32	2GB

• To modify memory limits for NextGen Gateway, seeModify Memory Limits for NextGen Gateway.

• If Physical Disk Discovery is enabled in Azure Stack HCI virtualized environments, it may result in duplicate data because both Azure Stack HCI Node Disks and Azure Stack HCI Node Physical Disks are discovered and created duplicate resources.

Version History