Summary
The custom policy in this sample (policy/azurepolicy.json) only allows the targetLicenseType parameter to be Paid or PAYG and defaults to Paid. It has no LicenseOnly option and no edition awareness. When assigned broadly (the README's default flow assigns at management-group or subscription scope across all matching Arc-enabled SQL Server extensions), it will set the license type of free Developer, Express, and Evaluation instances to Paid.
Per the official licensing documentation, Paid means "License with Software Assurance", and selecting it is a customer attestation of active Software Assurance / a SQL Server subscription. Free editions are not eligible for Software Assurance, so marking them Paid produces a false attestation and a licensing-compliance breach. These editions must be LicenseOnly.
Evidence (Microsoft Learn)
From Manage licensing and billing of SQL Server enabled by Azure Arc — license type table:
| License type |
Description |
Value |
| License with Software Assurance |
Bring your own Standard or Enterprise license with Software Assurance or a SQL Server subscription. |
Paid |
| License only |
You use a perpetual license for Standard or Enterprise edition, or you use the free Developer, Evaluation, or Express editions. |
LicenseOnly |
Same page, Important considerations:
"By selecting a license with Software Assurance, you attest that you have Enterprise or Standard licenses with active Software Assurance or an active SQL Server subscription license, and that the device is in compliance with the Product Terms outsourcing restrictions."
The value LicenseOnly is a documented, first-class option in the auto-connect tag flow (ArcSQLServerExtensionDeployment = Paid / PAYG / PAYG-Recurring / LicenseOnly) — see Manage automatic connection — but this policy sample omits it.
Impact
- Assigning the policy with its default
Paid target (or across a mixed estate) silently sets LicenseType = Paid on free-edition instances.
- That is a false Software Assurance attestation and a licensing-compliance exposure for the customer.
- Because the effect is
DeployIfNotExists with remediation, existing free-edition instances get remediated to Paid.
Expected behaviour — the license type must follow the edition (and edition combination)
The correct mapping is edition-driven, and combinations matter. The rule is:
If a host has at least one Standard or Enterprise instance → Paid.
If a host has only free editions (Developer / Express / Evaluation) → LicenseOnly.
PAYG applies where the customer chooses pay-as-you-go hourly billing for a Standard/Enterprise instance.
| Edition / combination |
Correct license type |
| Standard |
Paid |
| Enterprise |
Paid |
| Developer |
LicenseOnly |
| Express |
LicenseOnly |
| Evaluation |
LicenseOnly |
| Enterprise + Express |
Paid |
| Enterprise + Developer |
Paid |
| Standard + Express |
Paid |
| Standard + Developer |
Paid |
The current policy cannot express this: it hard-sets a single targetLicenseType (default Paid) for every matched extension, so it can neither keep free-only hosts on LicenseOnly nor correctly keep mixed hosts on Paid — it just stamps one value everywhere.
Suggested change
Minimum viable fix (unblocks correct manual use):
- Add
LicenseOnly to the targetLicenseType allowed values. The existing deployment template already applies a plain LicenseType setting for non-PAYG values, so LicenseOnly flows through with no template change.
- Remove the
Paid default (or make the parameter required with no default) so an operator must deliberately choose.
- Document the edition mapping table above in the README so operators scope assignments correctly (e.g. one assignment targeting Standard/Enterprise hosts →
Paid; another targeting free-only hosts → LicenseOnly).
Ideal fix (makes it self-correcting so we are neither in breach nor under-enabling):
- Make the policy edition/combination-aware so the value is derived automatically:
- key off the SQL Server instance edition (
Microsoft.AzureArcData/sqlServerInstances edition / version), not just the HybridCompute extension;
- evaluate per host, so any Standard/Enterprise instance present sets the host to
Paid, and only pure free-edition hosts resolve to LicenseOnly;
- this guarantees the paid editions that should be enabled are enabled, while free-only hosts stay on
LicenseOnly and out of a false SA attestation.
Note: expressing the "any paid edition on the host" aggregation purely in Azure Policy is non-trivial (policy evaluates per resource and can't easily aggregate sibling instances of a different type). If a pure-policy expression isn't feasible, the sample should either (a) target sqlServerInstances edition directly, or (b) clearly document a scoped-assignment pattern per the table, rather than defaulting to a blanket Paid.
Notes
Raised after field validation on a customer Arc onboarding where enforcing Paid across the estate would have mis-attested SA on Developer / Express instances that should be LicenseOnly, while still needing Standard / Enterprise (including mixed hosts) to be correctly set to Paid.
Summary
The custom policy in this sample (
policy/azurepolicy.json) only allows thetargetLicenseTypeparameter to bePaidorPAYGand defaults toPaid. It has noLicenseOnlyoption and no edition awareness. When assigned broadly (the README's default flow assigns at management-group or subscription scope across all matching Arc-enabled SQL Server extensions), it will set the license type of free Developer, Express, and Evaluation instances toPaid.Per the official licensing documentation,
Paidmeans "License with Software Assurance", and selecting it is a customer attestation of active Software Assurance / a SQL Server subscription. Free editions are not eligible for Software Assurance, so marking themPaidproduces a false attestation and a licensing-compliance breach. These editions must beLicenseOnly.Evidence (Microsoft Learn)
From Manage licensing and billing of SQL Server enabled by Azure Arc — license type table:
PaidLicenseOnlySame page, Important considerations:
The value
LicenseOnlyis a documented, first-class option in the auto-connect tag flow (ArcSQLServerExtensionDeployment=Paid/PAYG/PAYG-Recurring/LicenseOnly) — see Manage automatic connection — but this policy sample omits it.Impact
Paidtarget (or across a mixed estate) silently setsLicenseType = Paidon free-edition instances.DeployIfNotExistswith remediation, existing free-edition instances get remediated toPaid.Expected behaviour — the license type must follow the edition (and edition combination)
The correct mapping is edition-driven, and combinations matter. The rule is:
PaidPaidLicenseOnlyLicenseOnlyLicenseOnlyPaidPaidPaidPaidThe current policy cannot express this: it hard-sets a single
targetLicenseType(defaultPaid) for every matched extension, so it can neither keep free-only hosts onLicenseOnlynor correctly keep mixed hosts onPaid— it just stamps one value everywhere.Suggested change
Minimum viable fix (unblocks correct manual use):
LicenseOnlyto thetargetLicenseTypeallowed values. The existing deployment template already applies a plainLicenseTypesetting for non-PAYG values, soLicenseOnlyflows through with no template change.Paiddefault (or make the parameter required with no default) so an operator must deliberately choose.Paid; another targeting free-only hosts →LicenseOnly).Ideal fix (makes it self-correcting so we are neither in breach nor under-enabling):
Microsoft.AzureArcData/sqlServerInstancesedition/version), not just the HybridCompute extension;Paid, and only pure free-edition hosts resolve toLicenseOnly;LicenseOnlyand out of a false SA attestation.Notes
Raised after field validation on a customer Arc onboarding where enforcing
Paidacross the estate would have mis-attested SA on Developer / Express instances that should beLicenseOnly, while still needing Standard / Enterprise (including mixed hosts) to be correctly set toPaid.