Onboarding one Windows server to Azure Arc is easy, but onboarding dozens or hundreds quickly exposes where manual processes fall apart.
Azure Arc is designed to help organizations manage Windows, Linux, Kubernetes, SQL, SCVMM, VMware, and other resources across on‑premises and other cloud platforms from Azure. But if your onboarding process requires interactive Azure logins every time a script runs, automation stops before it really starts. In this post, we walk through how to use Entra service principles to onboard Windows machines to Azure Arc at scale, and why this approach is more secure, more scalable, and better suited for real enterprise environments.
Why Azure Arc Matters for Hybrid and Multi‑Cloud Environments
Azure Arc extends Microsoft Azure management capabilities beyond the Azure cloud itself. With Azure Arc, you can manage inventory, apply governance, deploy updates, and run automation against resources that live on‑premises or in other clouds.
For organizations operating in hybrid or multi‑cloud environments, this centralized control plane is a major advantage. Instead of stitching together multiple management tools, Azure Arc provides a consistent way to manage infrastructure wherever it runs.
The challenge is not what Azure Arc can do. The challenge is how you deploy it at scale.
Check out my previous post and video on Azure Arc here.
The Problem with Interactive Azure Logins
The Azure Arc onboarding script with manual authentication works well for demos and small environments. It prompts you to log into Azure interactively, validates your permissions, and then registers the machine.
That approach breaks down quickly in real environments.
Interactive logins do not scale, especially when onboarding large numbers of Windows servers or clients. They also introduce security risks by encouraging the use of highly privileged user accounts. And they make true automation almost impossible when using tools like Configuration Manager, Group Policy, Ansible, or CI and CD pipelines.
To solve this, we need a non‑interactive and least‑privileged authentication method.
Using Service Principals for Secure Automation
A service principal in Entra ID is a non‑human identity designed specifically for automation. It is granted only the permissions required to perform a specific task, such as onboarding machines to Azure Arc.
Using a service principal aligns with zero trust principles and least privilege access. Instead of relying on a highly privileged account, you create an identity that can do exactly one thing and nothing more.
This approach offers two major benefits.
First, the onboarding script no longer requires an interactive Azure login. A local administrator on a Windows server can run the script without having any Azure credentials at all.
Second, automation tools can execute the script at scale without human intervention. This is essential for enterprise environments that manage hundreds or thousands of machines.
Requirements to Get Started
Before creating the onboarding script, there are a few prerequisites to be aware of.
The account used to create the service principal must have the Application Administrator or Cloud Application Administrator role in Entra ID. It must also have Owner or User Access Administrator permissions on the Azure subscription where the machines will be onboarded.
From a networking perspective, the Azure Arc agent requires outbound access over TCP port 443. If your environment restricts outbound traffic, Microsoft provides a list of required URLs that must be allowed.
You will also need a Windows machine to onboard and an active Azure subscription.
Creating the Azure Arc Service Principal
The process starts in the Azure portal under Azure Arc.
You create a new service principal and choose whether it has access to the entire subscription or only a specific resource group. For most environments, limiting access to a single resource group is the better choice.
When creating the client secret, it is important to set an appropriate expiration. Secrets should be valid only as long as needed. Shorter lifetimes reduce risk and encourage better credential hygiene.
Once the service principal is created, Azure provides a file containing the application ID and client secret. This information is required later when configuring the onboarding script.
If the secret expires or needs to be rotated, you can manage secrets directly from the service principal configuration in Entra ID.
Generating the Azure Arc Onboarding Script
With the service principal in place, the next step is generating the onboarding script.
From Azure Arc, you navigate to Machines and select the option to onboard existing machines. Most of the configuration steps are the same as a standard onboarding process, including selecting the subscription, resource group, region, operating system, and connectivity method.
The key difference is the authentication method. Instead of using interactive login, select automatic authentication and choose the service principal you created earlier.
Azure then generates an onboarding script that is designed to authenticate using the service principal. This script can be downloaded in several formats depending on how you plan to deploy it, including options tailored for SCCM, Group Policy, and Ansible.
Updating and Running the Script
Before running the script, you must insert the service principal application ID and client secret into the script. This step is critical. Any extra characters or formatting issues will cause the script to fail.
Once updated, the script can be executed on the target Windows server or client. At this point, no Azure login is required. The machine authenticates using the service principal and registers itself with Azure Arc.
When the script completes, the machine appears in the Azure Arc portal as a connected machine, ready to be managed alongside other Azure resources.
Lessons Learned About Scale
One important takeaway from this process is that automation tools matter.
While it is technically possible to use PowerShell remoting to execute the script remotely, this approach is not ideal for enterprise environments. PowerShell remoting is often disabled, requires additional configuration, and does not scale well.
True automation platforms like Configuration Manager, Ansible, Desired State Configuration, or deployment pipelines are far better suited for onboarding Azure Arc at scale. The service principal-based approach makes those tools possible, but the tools themselves still need to be in place.
Even when scripts are run locally, using a service principal is still a major improvement. It reduces risk, removes the need for elevated Azure credentials, and allows other team members to onboard machines without direct Azure access.
Final Thoughts
Azure Arc is a powerful platform for managing Windows, Linux, SQL, SCVMM, VMware, and Kubernetes clusters across hybrid and multi‑cloud environments. But to unlock its full potential, onboarding must be automated, secure, and scalable.
Using service principals for Azure Arc onboarding is a foundational step toward enterprise‑ready automation. It enables least privilege access, removes interactive logins, and integrates cleanly with the automation tools organizations already rely on.
If you are serious about managing infrastructure at scale with Microsoft Azure, this is the approach that sets you up for long term success.
For a full walkthrough and live demo, be sure to watch the accompanying video.
Links:
A Beginner’s Guide to the AZ-900
https://www.udemy.com/course/beginners-guide-az-900/?referralCode=C74C266B74E837F86969
Zero to Hero with Azure Virtual Desktop
https://www.udemy.com/course/zero-to-hero-with-windows-virtual-desktop/?referralCode=B2FE49E6FCEE7A7EA8D4
Hybrid Identity with Windows AD and Azure AD
https://www.udemy.com/course/hybrid-identity-and-azure-active-directory/?referralCode=7F62C4C6FD05C73ACCC3
Windows 365 Enterprise and Intune Management
https://www.udemy.com/course/windows-365-enterprise-and-intune-management/?referralCode=4A1ED105341D0AA20D2E
Connected Machine agent network requirements
https://learn.microsoft.com/en-us/azure/azure-arc/servers/network-requirements?tabs=azure-cloud&WT.mc_id=AZ-MVP-5004159#urls
