microsoft / microsoft/sql-server-samples
Policy `Configure Arc-enabled SQL Server license type` can set free editions (Developer/Express/Evaluation) to Paid — Software Assurance attestation / compliance risk
Nobody has claimed this yet.
- Dominant language
- PowerShell
- Stars
- 11.2k
- Forks
- 9.1k
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 14
Description
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
Paidtarget (or across a mixed estate) silently setsLicenseType = Paidon free-edition instances. - That is a false Software Assurance attestation and a licensing-compliance exposure for the customer.
- Because the effect is
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:
If a host has at least one Standard or Enterprise instance →
Paid.
If a host has only free editions (Developer / Express / Evaluation) →LicenseOnly.
PAYGapplies 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
LicenseOnlyto thetargetLicenseTypeallowed values. The existing deployment template already applies a plainLicenseTypesetting for non-PAYG values, soLicenseOnlyflows through with no template change. - Remove the
Paiddefault (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/sqlServerInstancesedition/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 toLicenseOnly; - this guarantees the paid editions that should be enabled are enabled, while free-only hosts stay on
LicenseOnlyand out of a false SA attestation.
- key off the SQL Server instance edition (
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
sqlServerInstancesedition directly, or (b) clearly document a scoped-assignment pattern per the table, rather than defaulting to a blanketPaid.
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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Inspect policy/azurepolicy.json and the README's assignment flow first. Compare the parameter defaults and deployment behavior with the documented edition mapping; done means the sample no longer encourages blanket Paid for free editions and its supported assignment or scoping behavior is documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, powershell, sql
- Domain
- cloud, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100