Azure Monitor SCOM Managed Instance - Frequently asked questions

To maintain latency, we recommend you have the VNet in the same region as your other Azure resources.

The minimum address space is /27 (which means /28 and above wouldn't work).

• VNet needs two subnets.
  • For SCOM Managed Instance
  • For SQL Managed Instance
• The subnet for SQL Managed Instance will be a delegated (dedicated) subnet and won't be used by the SCOM Managed Instance. Name the subnets accordingly to avoid confusion in the future while you create the SQL Managed Instance/SCOM Managed Instance.

The minimum address space needs to be /27 for SQL MI subnet and /28 for the SCOM Managed Instance subnet.

No, both the options can be left blank.

No, you can disable all of them or enable any of them based on your organization's preferences.

If you have multiple VNets created, you need to peer your VNets. If you're peering any two networks, ensure to peer from both networks to each other. Thus, if you peer three networks, you need to do six peerings. For more information on peering, see Azure Virtual Network peering.

• You need to specify a peering name (in the field Peering link name).
• The first name is used to name the peer network from the current network to the other network. The second name is used to name the peer network from the other network to this network.
• In the section Virtual Network, specify the name of the VNet that you're peering. If you can't find the VNet, you can search for it using the Resource ID. Retain the rest of the options as default.

1. If you don't see the region that you want to choose (West US or West Europe) in the list of regions, select Not seeing a region, and then select Request quota increase for your subscription.
2. Enter the required fields in Basics and go to Details to enter the Problem details.
3. Select Enter details. Quota details page opens on the right pane. In Region, choose the desired region and change the limits as desired (10 subnets and 500 vCores should suffice). Select Save and continue and then select Next: Review + create >> to raise the ticket. It might take 24 hours for the ticket to get resolved. Wait for it to get resolved before proceeding to create the SQL MI instance.
   For more information, see Which Azure regions are supported?.

Azure RBAC is the role-based access control system that Azure follows while granting permissions. For more information, see Azure role-based access control.
Azure RBAC is divided into Azure roles and Microsoft Entra ID roles. At a high level, Azure roles control permissions to manage Azure resources, while Microsoft Entra ID roles control permissions to manage Microsoft Entra ID Directory resources. The following table compares some of the differences. |Azure roles|Microsoft Entra ID roles| |---|---| |Manage access to Azure resources|Manage access to Microsoft Entra ID resources| |Supports custom roles|Supports custom roles| |Scope can be specified at multiple levels (management group, subscription, resource group, resource)|Scope can be specified at the tenant level (organization-wide), administrative unit, or on an individual object (for example, a specific application)| |Role information can be accessed in Azure portal, Azure CLI, Azure PowerShell, Azure Resource Manager templates, REST API|Role information can be accessed in Azure admin portal, Microsoft 365, admin center, Microsoft Graph, Microsoft Entra ID PowerShell|
Below is the high-level view of how the classic subscription administrator roles, Azure roles, and Azure AD roles are related.

During the deployment phase, there can be several reasons why deploying a SCOM Managed Instance shows an error. It might be due to wrong input while creation or some backend error. Raise a support ticket in case you need any further assistance. In the scenario of an error during deployment, it's best to delete the instance and create one again. For more information, see Troubleshoot issues with Azure Monitor SCOM Managed Instance.

You can either delete the instance from the instance view itself or from the Resource Group view.
In the instance view, select Delete from the top menu and wait for the confirmation that the instance has been deleted. Alternatively, go to your resource group view (search for Resource Group in the Azure search bar, and in the list of results, open your resource group). Go to the resource group where the SCOM Managed Instance resides and delete the instance.
Once the instance is deleted, you'll also have to delete the two databases created in SQL MI. In the resource view, select the two databases (depending on what name you gave to your SCOM Managed Instance) and select Delete.

Currently not supported. Today, independent of System Center Operations Manager, customers can install an Arc agent on a VM running on-premises and start seeing the resource in the Azure portal. Once they start seeing the resource in the Azure portal, they can use the Azure services for that resource (and incur the appropriate costs).

SCOM Managed Instance and System Center Operations Manager share the same feature set. You can use the same Management packs that you use in on-premises to carry out network monitoring via SCOM Managed Instance.

• SCOM Managed Instance is native to Azure, while running System Center Operations Manager in Azure VMs isn't a native solution. This means, SCOM Managed Instance integrates smoothly with Azure and all of Azure’s updates are available to SCOM Managed Instance.
• SCOM Managed Instance prepares the entire infra for high availability by deploying VMSS, Load Balancer, MSI, etc. To prepare such setup manually, it takes months of effort (and requires in-depth technical knowledge).
• SCOM Managed Instance uses SQL MI as the backend for database management by default.
• SCOM Managed Instance comes with built-in scaling, patching features, and integrated reports.

Being in the same private network so that the IPs assigned to each component in the network can be a private IP.

Since this instance requires you to create the SCOM Managed Instance in your subscription, you will be able to see all the SCOM Managed Instance resources (including the VMs). However, we recommend not to do any actions on the VMs and other resources while you're operating SCOM Managed Instance to avoid unforeseen complexities.

No.
SCOM Managed Instance Managed Gateways can be configured on any Azure and Arc-enabled server, which doesn't have Operations Manager Gateway software on it. If you want to reuse Operations Manager on-premises Gateway servers with SCOM Managed Instance, uninstall Operations Manager Gateway software on it. To configure SCOM Managed Instance Managed Gateway, see Configure monitoring of servers via SCOM Managed Instance Gateway.

No. Multi-homing on SCOM Managed Instance Managed Gateway isn't possible.

The certificates are assigned by Microsoft and are signed by CA. There's no requirement for manual management of certificates on Managed Gateways. 

Yes, if there's a direct connectivity (line-of-sight) between SCOM Managed Instance and on-premises machine via VPN/ER, you can monitor these machines. For more information, see Configure monitoring of on-premises servers.

You can't perform actions on the on-premises monitored resources, but can view them. Additionally, if the monitored objects are deleted, the portal will automatically remove those on-premises objects in five minutes.

The monitored resources and managed gateways connectivity status are updated every minute, you can view the same in the Properties context menu.

The agent will be upgraded in-place (if required) and multi-homed to the SCOM Managed Instance.

The capability is enabled with SCOM Managed Instance extension >=91.

You can view the list of properties for a monitored resource or a managed gateway in the Properties context menu.

SCOM Managed Instance enables monitoring of Azure and Arc-enabled machines. Additionally, it displays information about on-premises machines that are directly connected to the SCOM Managed Instance.

The initial retrieval of health and connectivity states on the portal takes approximately five to seven minutes. Subsequently, heartbeats occur every minute.

The minimum required .NET Framework version is 4.7.2.

On the agent/gateway server to be onboarded,

• Check if it has the outbound connectivity to *.workloadnexus.azure.com
• Check if the firewall has been opened for this URL.
  For example: Test-NetConnection westus.workloadnexus.azure.com -Port 443 (Region must be SCOM Managed Instance's region)

On the agent/gateway server to be onboarded, check if it has the outbound connectivity to management servers load balancers endpoint.
For example: Test-NetConnection wlnxMWH160LB.scommi.com -Port 5723

The agent and gateway server machines needs TLS 1.2 or more enabled, and TLS 1.1 disabled to get the successful onboarding and monitoring.
For more information, see the process for enabling TLS 1.2.

Currently, we don't support monitoring of Azure and Arc-enabled Linux machines. However, they can be managed via the Arc-enabled gateway servers.

No. You can't configure an agent to communicate with multiple SCOM Managed Instances, but it can have a multi-home configuration for on-premises System Center Operations Manager and a SCOM Managed Instance.

Currently, only Arc-enabled machines are permitted as gateway servers.

Currently, multi-homing for gateway servers isn't supported.

Next steps

Read the other FAQs:

SCOM Managed Instance overview