Azure VM Extension: Onboarding and Private Publishing

Question

Azure VM Extension: Onboarding and Private Publishing

Jay Dance 0

Problem description

I am working on developing and publishing a custom Windows Azure VM Extension for internal security automation. This extension needs to support both the Azure VM extension framework (Microsoft.Compute/virtualMachines/extensions) and Azure Arc–enabled Windows servers (Microsoft.HybridCompute/machines/extensions). I want to do this privately within my environment without using a public marketplace offer.

Environment

Virtual Machine running Windows, target resource types include native Azure VMs and Azure Arc–managed Windows servers.

What I've already tried

I have reviewed public Microsoft documentation on Azure VM extensions, examined GitHub and online specs for the extension handler protocol, looked into packaging formats and registration steps, explored guidance on private/internal extension publishing, and considered Arc extension allowlisting practices. I have also opened this support case; the initial response indicated no relevant data was available. Additionally, I explored Azure CLI examples for private extension publishing and self-help content on extension installation restrictions.

Current status

I am seeking detailed guidance on onboarding to the VM Extension Publisher program, access to the extension handler development specifications, packaging and manifest requirements, publisher registration steps, the Azure platform repository publishing process for private extensions, and how to configure Arc local extension allowlisting. I would appreciate up-to-date information or escalation to the appropriate team for further discussion.

Divyesh Govaerdhanan 11,725 Reputation points MVP Volunteer Moderator

2026-09-01T17:42:35.68+00:00
Hi Jay Dance,

Welcome to Microsoft Q&A,

If your goal is a real, formal VM extension handler (one that shows up under "Extensions + applications" and has its own install/upgrade/handler lifecycle): this is confirmed by Microsoft as not a self-service process, and it's separate from publishing an offer through Partner Center. Access to the detailed publisher documentation and the azure-extensions-cli tooling is restricted to approved/whitelisted publishers only, that's why your research into the handler protocol and packaging specs kept hitting dead ends, that material genuinely isn't public. Onboarding requires direct engagement with the Microsoft VM Extension product team. The way to start that (and this matches what's happened in every resolved case): post exactly what you posted here, with your Azure subscription ID included, and Microsoft loops in the product management team by email to schedule an onboarding discussion. Since your support case came back empty, this Q&A thread is actually the right channel, not a fallback, that's the documented pattern for how this gets picked up.

If your goal is just to run your internal security automation on your own VMs and Arc-managed servers (not make it a reusable extension other customers could discover), you almost certainly don't need to become a publisher at all. Use the Custom Script Extension instead:

Native Azure VMs: az vm extension set with Microsoft.Compute/CustomScriptExtension, pointing at your script (stored privately, e.g. in a storage account with a SAS token or a private repo).

Arc-enabled Windows servers: the same Custom Script Extension is available for Arc-managed machines through the Connected Machine agent's extension mechanism.

This gets your automation running through the standard VM extension deployment path, ARM/Bicep, CLI, or Run Command, entirely privately, with zero publisher onboarding, and it works identically across both native Azure VMs and Arc.

On the Arc allowlisting piece: Azure Arc's Connected Machine agent supports local allow lists and block lists per server, configured with azcmagent config set extensions.allowlist "Publisher/Type". If you go the Custom Script Extension route, you'd explicitly add Microsoft.Compute/CustomScriptExtension to your allowlist, note that this extension is commonly blocked by default in security-hardened Arc configs specifically because it can run arbitrary code, so you'll likely need to deliberately opt it back in. Allow lists are local to each server (can't be overridden even by an Owner/Global Admin in Azure), so this is configured per-machine or via your onboarding automation, not centrally in the portal.

Please Upvote and accept the answer if it helps!!

2 answers

Your answer

Answer 1

Jay Dance 0

The machines we're looking to deploy to have very high sensitivity requirements, and for that reason, allowing arbitrary command execution through CustomScriptExtension is not something we want to allow. If there is a way to lock it down to specific commands or processes, then we'd be interested in taking another look at it. This is why we are looking to create our own private extension.

0 comments

Answer 2

Jay Dance 0

Hopefully this thread will get escalated to someone in the VM extension team so they can answer if this is possible.

0 comments