Azure-Virtual Machine Unable to create Virtual Interface getting loading issues for networks /IP

[MallikharjunaV]

Could someone guide us to eliminate this error and origin of this error why it is unable to fetch from Azure ARM API even though enough permissions it has??

OOB spoke Action in flow designer: Create Network Interface

[Abhishek Pal]

Hi @MallikharjunaV ,

The error in your screenshot is not the Create Network Interface API failing yet.

The failure is occurring earlier while Flow Designer is trying to populate the dependent dynamic inputs:

sn_azure_vn_spoke.get_virtual_networks_by_resource_group_metadata

and

sn_azure_vn_spoke.get_public_ip_addresses_by_resource_group_metadata

Because both metadata actions are returning no data, the Subnet field cannot load either.

The first thing I would check is the Azure Resource Management connection alias.

Starting with Microsoft Azure Virtual Network Spoke v2.0, the newer actions use the Microsoft Azure Resource Management connection alias:

sn_azure_rm_spoke.Microsoft_Azure_Resource_Management

The older Azure Virtual Network credential alias was deprecated.

Recommended troubleshooting:

1. Verify the Spoke versions

Confirm that you are using the current Microsoft Azure Virtual Network Spoke and Microsoft Azure Resource Management Spoke.

The Virtual Network Spoke depends on the Azure Resource Management Spoke and does not require its own separate connection.

Do not use the deprecated Create Network Interface action.

Use:

Create Network Interface

not:

Create Network Interface (Deprecated)

2. Verify the Azure Resource Management connection

Navigate to:

Process Automation > Workflow Studio > Integrations > Connections

Search for:

Microsoft Azure Resource Management

Open the connection and verify:

- Connection is Active
- Correct Azure tenant
- Correct Client ID
- Valid Client Secret
- Correct Subscription ID
- OAuth credential is valid
- The connection is associated with:

sn_azure_rm_spoke.Microsoft_Azure_Resource_Management

If your configuration is still using the older Azure Virtual Network alias, this is the first thing I would correct.

3. Check the Resource Group carefully

The dynamic actions in your error are specifically:

get_virtual_networks_by_resource_group_metadata

get_public_ip_addresses_by_resource_group_metadata

Therefore, ServiceNow is querying Azure for Virtual Networks and Public IP Addresses inside the Resource Group supplied to the action.

Verify that the selected Resource Group actually contains:

- The required Virtual Network
- The required Public IP Address

If, for example:

NIC/VM Resource Group = RG-Compute

but:

Virtual Network = RG-Network

the VNet will not be returned by a "by Resource Group" lookup for RG-Compute.

This is a very common architecture when organizations maintain networking resources in a central networking Resource Group.

So please verify the Azure resource locations before changing any ServiceNow code.

4. Test the Azure lookup actions independently

Before testing Create Network Interface again, test these OOB actions separately using the same Subscription ID and Resource Group:

Look up Virtual Networks Stream by Resource Group

Look up Public IP Addresses Stream by Resource Group

Check the execution details.

Possible results:

401
-> OAuth authentication/credential issue

403
-> Azure RBAC permission issue

200 with empty result
-> Wrong Subscription ID, wrong Resource Group, or there are no matching resources in that Resource Group

200 with the expected resources
-> Azure connectivity and permissions are working; investigate the Dynamic Inputs configuration/spoke version next

This test will tell you exactly which layer is failing.

5. Verify Azure RBAC

The Service Principal used by ServiceNow must be able to read the networking resources.

For troubleshooting, Microsoft Azure Network Contributor at the appropriate Resource Group or Subscription scope provides permissions including:

Microsoft.Network/*

and Resource Group read access.

If the Service Principal only has Virtual Machine Contributor or VM-specific permissions, that does not automatically provide permission to list/manage Virtual Networks, Public IP Addresses, Subnets, and Network Interfaces.

At minimum, verify access for:

Microsoft.Network/virtualNetworks/read
Microsoft.Network/virtualNetworks/subnets/read
Microsoft.Network/publicIPAddresses/read
Microsoft.Network/networkInterfaces/read
Microsoft.Network/networkInterfaces/write

and the required subnet join/network operations for your final NIC creation.

You can temporarily validate with Network Contributor and then replace it with a least-privilege custom Azure role if your security policy requires that.

6. Verify the dependent plugins

The current Azure Virtual Network Spoke requires components including:

ServiceNow Flow Designer - Dynamic Inputs
IntegrationHub Runtime
IntegrationHub Action Step - REST
Complex Object
IntegrationHub Action Step - Get Connection Info
Azure Resource Management Spoke

If Dynamic Inputs or another dependency is not installed/updated correctly, the Azure API itself may work while the Flow Designer dropdown still fails.

7. Test with static values first

If Subscription ID or Resource Group is being passed using a runtime data pill, temporarily configure a known Subscription and Resource Group value directly in the action.

Then check whether Virtual Network and Public IP load.

If they load with static values, the issue is with resolving the parent dynamic input during design time rather than with Azure permissions.

8. If the lookup actions work but the dropdown still fails

If both standalone Azure lookup actions return the expected resources successfully, but you still receive:

No dynamic inputs data was provided from the action

then:

- Confirm Azure Virtual Network Spoke is current
- Confirm Azure Resource Management Spoke is current
- Remove the Create Network Interface step from the Flow
- Save the Flow
- Add the current OOB Create Network Interface action again
- Re-enter Subscription, Resource Group and Location
- Test again

This is preferable to modifying the OOB metadata actions.

Do not customize:

sn_azure_vn_spoke.get_virtual_networks_by_resource_group_metadata

or:

sn_azure_vn_spoke.get_public_ip_addresses_by_resource_group_metadata

because these are OOB spoke actions.

Based on your screenshot, my troubleshooting order would be:

Azure Resource Management alias
-> Subscription ID
-> Resource Group
-> VNet/Public IP actually exist in that Resource Group
-> Test OOB lookup actions
-> Azure RBAC
-> Spoke/plugin versions
-> Re-add the current Create Network Interface action

The strongest clue is that both VNet and Public IP metadata calls fail at the same time. That normally points to the shared Azure Resource Management connection/context or Resource Group rather than the Create Network Interface operation itself.

Official ServiceNow references:

Microsoft Azure Virtual Network Spoke:
https://www.servicenow.com/docs/r/integrate-applications/integration-hub/azure-vir-net-spoke.html

Set up Microsoft Azure Resource Management Spoke:
https://www.servicenow.com/docs/r/integrate-applications/integration-hub/setup-res-mngmt.html

Azure Virtual Network Spoke release notes:
https://www.servicenow.com/docs/r/store-release-notes/store-integrationhub-rn-microsoft-azure-virtua...

Microsoft Azure RBAC Network Contributor:
https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/networking

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal

[MallikharjunaV]

@Abhishek Pal FYI, we tried and validated connections, spokes are latest and active, individual action we tried is get virtual networks by subscription ID and resource group but azure team says there is no dependency with resource group, virtual networks are tied with locations but not based on resource group. so OOB spoke action failing there we tried to custom the action to work based on subscription id and location but throwing errors like: Error: "AzureNetworkUtils" is not defined.,Detail: "AzureNetworkUtils" is not defined.(we gave input as location mandatory and commented resource group in side rest script of action but it still tries to fect  datastream fucngtions and expect resource group) we need alernative cusgtom script or changes that can easily pull available virtual networks  and there by able to create Network Interface  before creating VM(network interface is mandatory even if we make non mandatory it throws error) using OOB spoke. Please suggest other possible solutions/tip/tricks etc to achieve virtual machine creation with or with out Network interface.

[Abhishek Pal]

Hi @MallikharjunaV ,

Thanks for the additional details.

The moderation warning is most likely caused by the external Microsoft URLs in the previous reply, so I am removing all external links below.

Based on your testing, I would not continue modifying the OOB Create Network Interface action.

There are two important points.

1. Azure VNets have both a Resource Group and a Location.

Location is important for selecting a compatible network, but every Azure Virtual Network is also an ARM resource that belongs to a Resource Group.

The OOB ServiceNow action using Resource Group is therefore valid, but it does not match your requirement where you want to discover VNets across the subscription first and then filter them by Location.

2. Do not customize the OOB metadata actions.

Instead of modifying:

get_virtual_networks_by_resource_group_metadata

or commenting out Resource Group dependencies, use the OOB subscription-level lookup actions where available.

Recommended approach:

Subscription ID
-> Look up Virtual Networks by Subscription ID
-> Filter returned VNets by Location
-> Select the required VNet
-> Read the VNet Resource ID
-> Determine its Resource Group and VNet name
-> Retrieve Subnets
-> Create Network Interface
-> Create VM

The VNet Resource ID contains all required information.

Example format:

/subscriptions/<subscription_id>/resourceGroups/<network_rg>/providers/Microsoft.Network/virtualNetworks/<vnet_name>

From this value you can determine:

- Subscription ID
- VNet Resource Group
- VNet Name

This is important because the VM/NIC Resource Group and the VNet Resource Group do not have to be the same.

For example:

VM Resource Group:
RG-Compute

VNet Resource Group:
RG-Network

That is a valid Azure architecture.

Do not force the VM Resource Group into the VNet lookup.

Regarding the errors:

AzureNetworkUtils is not defined

or:

AzureNetworkUtilkUtils is not defined

This usually happens because the copied/customized OOB action is trying to use internal helper Script Includes from the Azure Virtual Network Spoke scope.

I would not copy or reference those internal utilities from your custom application.

Recommended solution:

Option 1 - Preferred

Create a custom Subflow that orchestrates supported OOB Azure actions.

Use:

Look up Virtual Networks by Subscription ID

Then filter the output using the required Location, for example:

uksouth

After the VNet is selected, keep the complete VNet Resource ID.

From that Resource ID determine:

network_resource_group
vnet_name

Then retrieve the Subnets for that VNet.

Option 2 - Custom REST Action

If the OOB dynamic input cannot meet your requirement, create a small custom IntegrationHub Action using the existing Microsoft Azure Resource Management connection.

The action should:

1. Receive Subscription ID and Location.
2. Call the Azure ARM API to list Virtual Networks for the subscription.
3. Filter the returned records by Location.
4. Return:

Display value:
VNet name

Actual value:
Full VNet Resource ID

For example:

Display:
my-vnet-uksouth

Value:
/subscriptions/xxx/resourceGroups/network-rg/providers/Microsoft.Network/virtualNetworks/my-vnet-uksouth

Using the complete Resource ID is better than returning only the VNet name because it prevents ambiguity when multiple Resource Groups contain similarly named resources.

Subnet lookup:

After the VNet is selected:

VNet Resource ID
-> Extract Resource Group
-> Extract VNet Name
-> Retrieve Subnets
-> Select Subnet Resource ID

Then use the complete Subnet Resource ID while creating the NIC.

If the OOB Create Network Interface action still forces Resource Group-based dynamic inputs, create a small custom REST Action only for NIC creation instead of cloning the complete OOB action.

Recommended inputs:

subscription_id
nic_resource_group
location
network_interface_name
subnet_resource_id
public_ip_resource_id

Make public_ip_resource_id optional.

Important:

A Public IP is not mandatory for an Azure Network Interface.

You can create:

VM
-> NIC
-> Private IP
-> Subnet

without assigning a Public IP.

However, a standard Azure Virtual Machine requires at least one Network Interface.

Therefore:

VM without Public IP
-> Supported

VM without Network Interface
-> Not supported for a normal Azure VM

Do not simply make the Network Interface input non-mandatory in the OOB VM action because the underlying Azure VM creation still expects a network interface.

Recommended final architecture:

Subscription ID
+
Location
-> Look up VNets by Subscription
-> Filter VNets by Location
-> Select VNet
-> Keep full VNet Resource ID
-> Derive VNet Resource Group
-> Retrieve Subnets
-> Select Subnet Resource ID
-> Create NIC
-> Return NIC Resource ID
-> Create VM using NIC Resource ID

I would avoid modifying:

- OOB Create Network Interface action
- OOB metadata actions
- AzureNetworkUtils
- Protected Azure Spoke Script Includes

If you need the VNet dropdown itself to dynamically populate based on Subscription + Location, create your own Dynamic Input backed by the subscription-level lookup instead of modifying the OOB Resource Group-based Dynamic Input.

This keeps the solution upgrade-safe and avoids the internal Script Include dependency errors you are currently seeing.

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal