Would license validation be valuable?

[nafnafnaf]

Hi folks,
I recently encountered a significant issue while automating Defender for Office 365 and EXO policies in our tenant. The deployment consistently failed, but the error messages didn't clearly indicate the root cause. Debugging was hard due to 'no message' from the scripts' executions.
After troubleshooting, I discovered the issue was due to our tenant having only E3 licenses. Once we upgraded to E5, all Defender/EXO policies deployed successfully without any issues.
The Problem:

E3 licenses only include basic Exchange Online Protection (EOP) which is ok for a few DSC policies.
Advanced Defender for Office 365 policies require E5 or standalone Defender licenses
Current error messages don't clearly indicate this is a licensing issue
Users waste time troubleshooting what is actually a license limitation

Proposed Solution:
Add license validation that:

Checks tenant SKUs before attempting to deploy Defender policies
Provides clear error messages indicating which license is required
Suggests upgrade paths (E5 or Defender for Office 365 add-on)
Fails gracefully without breaking existing deployments

Affected Resources:

EXOAntiPhishPolicy
EXOSafeAttachmentPolicy
EXOSafeLinksPolicy
EXOAtpPolicyForO365
EXOAtpProtectionPolicyRule
EXOMalwareFilterPolicy

I'd be happy to contribute this feature if the maintainer thinks it would be valuable.
Has anyone else experienced similar licensing confusion?
Cheers!

[FabienTschanz]

I think that the license requirements should be mentioned in the readme of the resources, but full SKU check is probably a bit much. If we still want to introduce this feature, then it's probably best if a SKU check is added to the catch block, which is executed when a deployment fails.