Store in: An Azure Policy definition; Use: Guest configuration in Azure Policy

For a large fleet of Azure Arc-enabled, on-premises, domain-joined servers, the lowest-administrative-effort way to deliver and enforce PowerShell DSC configurations at scale is Azure Policy guest configuration (the successor to Azure Automation State Configuration, which Microsoft has scheduled for retirement and recommends migrating away from). With guest configuration, you package the DSC content and reference it directly from a guest configuration (Azure Policy) definition -- the content does not need to be published to, or managed inside, an Azure Automation account at all. Microsoft ' s own migration guidance for machine configuration confirms that DSC content is developed and published to any HTTPS-reachable location and then attached to machines purely through Azure Policy assignments, with no compilation or hosting step inside Automation. Once the guest configuration policy is assigned to the Arc-enabled machines (scoped by subscription, resource group, or individual machine), the Guest Configuration extension on each Arc agent pulls, applies, and continuously audits/remediates the configuration -- all centrally managed through Azure Policy, with no pull server, Automation account, or manual per-server DSC push required. This gives uniform rollout and governance across all 500 servers with minimal ongoing administration. Therefore, the DSC content should be referenced from an Azure Policy (guest configuration) definition, and Guest configuration in Azure Policy is the mechanism used to apply and enforce it across the Arc-enabled fleet.