vanRoojen LLC

Azure Automation / Windows VM maintenance

Find the NICs Windows forgot to forget.

Ghost(NIC)Hunter deploys to your Azure subscription, discovers Windows VMs across selected resource groups, and checks for stale network adapters left behind after Accelerated Networking host changes.

Daily detection is the default. The deployment includes Log Analytics and a workbook for current, cumulative, and live power-state reporting; removal still requires an explicit operation and confirmation.

Deploy to Azure Deploy to Azure Gov View source
adapter scandetect mode
ACTIVE NIC

netvsc / mlx5 / mlx4_bus

defaultDETECT
authorityRG SCOPED
cleanup2 GATES

Problem match

Multiple Mellanox or hidden network adapters after an Azure VM move?

If Windows Device Manager shows extra, grayed-out, or hidden adapters after Stop (Deallocate), redeployment, reallocation, or host migration, the VM may have stale guest devices associated with Accelerated Networking.

Common clues include scripts enumerating more NICs than expected, stale IP configuration, or unexplained connectivity, update, performance, or activation problems.

Good fit
An Azure Windows VM shows disconnected Mellanox or other hidden adapters that are absent from the VM’s current Azure network profile.
Not automatically a ghost NIC
Azure supports intentional multi-NIC architectures and multiple IP configurations. Preserve those attached resources.
Check first
Compare the Azure VM network profile with Windows PnP and registry evidence before enabling removal.
Platform guidance
Ghost NIC troubleshooting and intentional multiple NICs from Microsoft Learn.

Maintenance sequence

Detection, evidence, then an intentional cleanup.

Ghost(NIC)Hunter follows the same check-before-remove posture Microsoft documents, wrapped in a reusable Azure Automation deployment.

01 / Detect

Inventory stale adapters

Discover Windows VMs across the selected groups, skip offline or excluded targets, then compare active PnP evidence with PCI and VMBUS registry entries.

02 / Review

Retain structured evidence

Every target emits a structured result with power state, outcome, valid, ghosted, and removed counts for Automation and Log Analytics history.

03 / Remove

Require both safety gates

Cleanup requires Operation=Remove and ConfirmRemoval=true, then retries active-adapter validation before reporting the final outcome.

Azure authority

Runs inside your subscription with a managed identity.

The portal wizard creates an Azure Automation account and grants its system-assigned identity Virtual Machine Contributor separately on each selected target resource group.

It imports the runbooks, creates a dedicated 30-day Log Analytics workspace and workbook, and links a daily detection schedule. The maintenance runbook reaches Windows through Azure VM Run Command without stored operator credentials, a Hybrid Runbook Worker, or an inbound management port.

Deployment boundary
Your selected Azure subscription and resource group.
Target boundary
One or more full Azure resource-group IDs entered in the portal wizard.
Fleet controls
ghostNicHunterExclusions tags can block scanning, removal, or both per VM.
Removal boundary
Registry and device cleanup only after explicit confirmation.
Out of scope
No automatic VM restart, snapshot, deallocation, or network reconfiguration.

Automation variable encryption

Choose protected defaults or intentional portal visibility.

New deployments create seven Ghost(NIC)Hunter Automation variables in one selected storage mode. Encrypt Automation Variables is enabled by default: values remain available to the runbooks and the validated configuration workflow, but are not readable in the Azure portal or by external PowerShell.

Choose portal-readable variables only when operators need that visibility and the applicable policy permits unencrypted Automation variables. Azure fixes the mode when each variable is created, so redeploying cannot convert an existing installation in place.

Recommended default
Encrypted variables, compatible with policies that require Automation variable encryption.
Readable alternative
Normal variables for approved operator visibility; not appropriate where policy denies unencrypted variables.
Existing installations
Normal-to-encrypted conversion uses the documented guarded migration; record custom settings before it runs.
Safety boundary
There is no automatic encrypted-to-normal conversion because encrypted values cannot be externally read back.

Included Azure Monitor workbook

See what is wrong now—and which VMs keep recurring.

The portal deployment creates a dedicated Log Analytics workspace, forwards Automation job streams, and installs the Ghost NIC Hunter workbook automatically. CLI deployments may instead supply an existing workspace.

  • CurrentLatest successful ghost count plus refreshed Azure Resource Graph power state.
  • Top offendersVMs ranked by the ghost NICs currently present.
  • CumulativeRepeated observations retained to expose recurring causes.
  • EfficacyRemoval jobs, ghost NICs removed, safety aborts, and weekly cleanup trend.
History source
Azure Automation JobLogs and JobStreams in AzureDiagnostics.
Current truth
The newest successful scan per VM, not a historical maximum.
Recurrence signal
Cumulative observations intentionally include formerly cleaned VMs.

Why ghost NICs appear

Accelerated Networking can leave stale adapters after host movement.

Microsoft documents ghost NICs after VM deallocation/reallocation, redeployment, or host migration. The old hardware-backed adapter can remain hidden in Windows and interfere with connectivity, updates, automation, performance, or activation.

Read Microsoft’s ghost NIC troubleshooting guidance.

Azure ghost NIC FAQ

Questions to answer before removing an adapter.

Why does my Azure Windows VM show multiple Mellanox Ethernet adapters after deallocation?

With Accelerated Networking, deallocation and reallocation can move a VM to different hardware. The old hardware-backed adapter can remain as a hidden device in Windows, creating a ghost NIC alongside the active adapter.

Are all multiple NICs on an Azure VM ghost NICs?

No. Azure supports intentional multi-NIC VM designs and multiple IP configurations. Ghost(NIC)Hunter targets stale, disconnected guest devices, so compare the Azure VM network profile with Windows device evidence before cleanup.

How should I check for Azure ghost NICs before removing them?

Run Ghost(NIC)Hunter in its default detection mode, review the structured evidence, and confirm a recovery point. Removal requires both Operation=Remove and ConfirmRemoval=true.

Does Ghost(NIC)Hunter restart or reconfigure the Azure VM?

No. It does not automatically restart, snapshot, deallocate, or reconfigure the VM or its Azure network resources.

Can it scan multiple Azure resource groups automatically?

Yes. Enter one or more resource-group IDs during deployment. Ghost(NIC)Hunter discovers Windows VMs in those groups and schedules detection every day at 12:30 PM Pacific time.

What happens when a target VM is stopped or deallocated?

The runbook refreshes power state before issuing Run Command. A VM that is not running is recorded as OfflineSkipped, and no guest command is sent.

Can I choose whether Automation variables are encrypted?

Yes. New deployments encrypt all seven variables by default. Choose portal-readable variables only when policy allows it and that visibility is required. Azure fixes the storage mode at creation, so an existing installation follows the documented migration path instead of switching in place.

Deploy

Choose your Azure cloud and open the portal wizard.

Authenticate to the target tenant, choose the deployment resource group, and enter one target resource-group ID or multiple IDs separated by commas. The wizard generates the account and workspace names, deploys observability, and creates the daily detection schedule. It does not run removal.

Public source repository
github.com/vanRoojen-LLC/ghostNIChunter
Azure Commercial Azure Government

Read the deployment and permission guide before rollout.