Add Azure portal deployment guide + edition/compliance mapping for Arc SQL license-type policy

[rajeevj0909]

What this adds

A copy-and-paste Azure portal deployment path for the Arc SQL Server license-type policy, plus the licensing/compliance guidance that goes with it. The existing scripted (deployment.ps1) path is unchanged.

Changes

• policy/azurepolicy.portal.json (new) — the definition ready to paste into the portal's Policy rule box. It's the repo's azurepolicy.json with the portal-incompatible read-only policyType and top-level version removed. It also adds LicenseOnly to targetLicenseType (and defaults to it) so the manual path is compliance-safe out of the box.
• README.md
  • New Deploy via the Azure Portal (copy & paste) section alongside the existing CLI path.
  • New Deployment paths at a glance table.
  • New Choosing the license type by edition (compliance) section with the edition/combination → license-type mapping and the Software Assurance attestation note.
  • Cross-link to the companion Windows Arc benefits policy in Azure/Community-Policy.

Why

Two field papercuts:

1. Users pasting azurepolicy.json into the portal hit "Could not find member 'name' on object of type 'PolicyDefinitionProperties'" — there was no portal-ready file or instructions.
2. Paid is a Software Assurance attestation. Free Developer / Express / Evaluation editions are not SA-eligible and must be LicenseOnly (docs). The README now makes the correct edition mapping explicit.

Related: #1492 (proposal to make the policy itself edition/combination-aware). This PR is docs + a portal artifact only; the deeper policy fix is tracked there.

[claestom]

Hi @rajeevj0909 - I'm the author of the Azure Policy and was wondering what the differences are with the existing JSON that can be pasted in the Portal UI?

Thanks.

[rajeevj0909]

Hi @claestom,

Fair point. The policyRule is actually identical to the existing file, the portal one just trims the read-only policyType/version and adds the LicenseOnly default.

My thinking around this was providing a Deploy via the Azure Portal (copy & paste) path for non-CLI users, plus the edition to license-type mapping in the README.

If we can point to the same file that's great, I'm just trying to simplify it for less technical users who want a Portal method.

The LicenseOnly piece is really the substance of #1492: the policy currently allows only Paid/PAYG and defaults to Paid, which mis-attests Software Assurance on free editions (Developer/Express/Evaluation). Worth noting the scripted path (deployment.ps1) is ValidateSet('Paid','PAYG') too, so there's currently no way to set the compliant LicenseOnly value at all via the sample.

Happy to go whichever way you prefer: keep the portal file, or fold the portal steps into the README near the top with a few brief steps and pointing at the existing azurepolicy.json
Thanks!

[claestom]

Hi @rajeevj0909 - I see your point. At the moment, TargetLT cannot be set to LicenseOnly, but this is definitely an interesting enhancement to consider.

Have you tested the LicenseOnly target license type?

Similar to LicenseTypesToOverwrite, we could introduce an EditionToOverwrite parameter. This would allow users to exclude specific editions such as Developer, Express, or Evaluation.

Rather than maintaining multiple policy definitions, my recommendation would be to create a single JSON file containing all your updates, and then update the related scripts, commands, and hyperlinks to reference that central file. This would make maintenance much easier and help ensure consistency across all artifacts.

[rajeevj0909]

Thanks @claestom, appreciate you taking a look and the EditionToOverwrite idea makes sense.

I haven't had a chance to test it myself, but one nuance to be aware of after checking the aliases:

LicenseTypesToOverwrite works because LicenseType sits in the extension settings this policy targets. edition isn't there though, it lives on a different resource type (Microsoft.AzureArcData/sqlServerInstances). Azure Policy can't read a sibling resource type's field in a single rule, so an EditionToOverwrite filter would need the policy to read sqlServerInstances/edition, likely by re-targeting it there rather than the extension.