Bulk onboarding Windows Servers to Azure Arc with no on-prem AD and no existing management agent

For scaling Azure Arc onboarding without a domain or pre-existing management agent use an orchestration mechanism such as Ansible or PowerShell Remoting from a secure administrative jumpbox. Maintain a CSV containing the target VM hostnames or IP addresses and have a PowerShell script use Invoke-Command or another WinRM-based remoting method to execute the Azure Arc onboarding script on each server. The onboarding script can use a pre-created Microsoft Entra service principal assigned the Azure Connected Machine Onboarding role. The jumpbox needs appropriate network connectivity to the VMs and the required outbound connectivity to Azure, including any proxy configuration used by the servers.

Enabling Azure Arc on a Hyper-V host does not automatically onboard its guest VMs. Each guest is an independent Windows machine from Azure Arc's perspective and must have the Azure Connected Machine Agent installed and registered separately. Automatic discovery and onboarding of VMs is associated with Azure Local/Azure Stack HCI scenarios using the appropriate Azure infrastructure, not ordinary standalone Hyper-V hosts. Therefore, for conventional on-premises Hyper-V, your bulk process needs to execute the Arc agent installation and registration inside every guest VM.

For application allowlisting, the Azure Connected Machine Agent uses several directories and executables that need to be permitted by the application-control policy. The primary installation location is %ProgramFiles%\AzureConnectedMachineAgent\, which contains components such as azcmagent.exe, himds.exe, and GCArcService.exe. The agent also uses %ProgramData%\AzureConnectedMachineAgent\ and %ProgramData%\GuestConfig\. Your allowlisting policy should therefore account for the agent's required executables, services, child processes, and supporting directories rather than allowing only the initial onboarding script. At a minimum, the core agent components such as azcmagent.exe, himds.exe, ExtensionService.exe, and GCArcService.exe need to be considered when constructing the policy. Because the exact files can change between agent versions, it is preferable to base the production allowlist on Microsoft's current Connected Machine Agent prerequisites and your application's specific control mechanism rather than relying on a permanently hard-coded list.

For the older Windows Server VMs, there is no native Azure Arc feature that performs directly an in-place OS upgrade across arbitrary on-premises Hyper-V guests. Once the servers are Arc-enabled, Azure management capabilities can help with patching and management, but a major Windows Server version upgrade is a separate operating-system deployment task. At scale, the practical approach is to use an existing configuration-management/orchestration mechanism to stage the installation media and automate the supported in-place upgrade where the source and target Windows Server versions support that upgrade path. Before doing this across dozens of VMs, each server should be assessed for its current Windows Server version/edition, application compatibility, disk space, boot configuration, and whether an in-place upgrade is actually supported.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin