[pull] dev from KelvinTegelaar:dev#100
Open
pull[bot] wants to merge 39 commits intoisgq-github01:devfrom
Open
Conversation
Drift detection used rawData.templates from the frontend form snapshot to resolve tag-assigned Intune templates. This snapshot goes stale when templates are added to a tag after the drift standard is saved, causing policies to appear as deviations despite being compliant in standards. Replace rawData.templates with a live database lookup by package property, matching the approach already used by Get-CIPPTenantAlignment. Also consolidate template table queries into a single unfiltered load.
The report block overwrote the actual current expiration day count with the boolean literal $true whenever StateIsCorrect was true, then wrote that boolean into the compare field as the "Current" value. This caused the drift page to render Expected=120 / Current= true and flag a deviation even when the policy was correctly set -- while the remediate block (which used the unmangled value) logged "already set to 120 days". Removing the conditional reassignment makes the report always emit the real numeric value, so when state matches expected the drift page goes green instead of showing a phantom deviation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The standard fetches $CurrentState from SPO once at the top, then the remediate block calls Set-CIPPSPOTenant to mutate the live state but never refreshes $CurrentState. When both remediate and report run in the same pass, the report block builds CurrentValue from the stale pre-remediation $CurrentState and writes it into the drift compare field -- producing Expected=true / Current=false on the manage drift page even though the live SPO state is now correct (and the logbook says "Successfully set File Requests..."). After a successful Set-CIPPSPOTenant, mirror the just-applied properties into $CurrentState so the report block writes the post-remediation values. The catch path is untouched, so failed remediation correctly leaves the original state in the report. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The autoclaim GET endpoint at admin.microsoft.com returns the policy
state under tenantPolicyValue, not policyValue:
{
"policyId": "Autoclaim",
"tenantPolicyValue": "Disabled",
"tenantId": "..."
}
CIPP was reading $AutoClaimPolicy.policyValue (which does not exist
on the response object) so it always evaluated to $null, causing:
- the initial Compare to find a diff vs the Expected 'Disabled',
- remediation to fire every run,
- the post-remediation re-fetch to also read null,
- the drift compare-field to be written with Value=null,
- the manage drift page to show a phantom deviation despite the
log saying "Changed Self Service status for product
'Trial Autoclaim - autoclaim' from '' to 'Disabled'".
The POST body still uses {"policyValue": "Disabled"} -- Microsoft's
read/write schemas are asymmetric on this endpoint, so only the
read paths needed the property name corrected.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The state check uses Compare-Object (order-insensitive) so $StateIsCorrect correctly reported "Federation Configuration already set." But the report block wrote the raw arrays to the compare field, where the current side was alphabetically sorted upstream and the expected side was in user-input order from $Settings.DomainList. The drift page diffs the JSON arrays literally, so identical sets in different orders rendered as a phantom deviation. Sort the parsed expected arrays (AllowedDomainsAsAList for AllowSpecificExternal, BlockedDomains for BlockSpecificExternal) at the source so they match the already-sorted current values. Set-CsTenantFederationConfiguration is set-semantic on the Microsoft side, so order does not affect remediation behavior. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Same shape as the TeamsFederationConfiguration fix: the state check uses Compare-Object (order-insensitive) so $StateIsCorrect correctly reports "already correctly configured", but the report block writes the raw arrays to the compare field where Current and Expected come from different sources and may be ordered differently. The drift page diffs the JSON arrays literally, producing phantom deviations even though the policies are correctly applied. SafeLinksPolicy.DoNotRewriteUrls: Current was $CurrentState.DoNotRewriteUrls (raw API), Expected was $Settings.DoNotRewriteUrls.value (raw user input). Sort both in the report block so they match regardless of input or API order. MalwareFilterPolicy.FileTypes: Current was $CurrentState.FileTypes (raw API), Expected was $ExpectedFileTypes ($DefaultFileTypes + user-supplied OptionalFileTypes split). Sort both in the report block. Set-SafeLinksPolicy and Set-MalwareFilterPolicy treat these lists as sets on the Microsoft side, so order does not affect remediation behavior -- only the drift display. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
limit to one per role
User reporting DB, add rerun protection and add null guarding
…olicies (#2038) This pull request introduces several improvements and bug fixes to the standards enforcement scripts, focusing on ensuring accurate reporting and consistency in policy comparisons. The main changes involve normalizing list-type values for reliable comparisons, correcting field references, and updating in-memory state after remediation to prevent reporting outdated values. **Policy comparison normalization:** * Updated all list-type fields (such as `FileTypes`, `DoNotRewriteUrls`, and domain lists in Teams federation) to be sorted before comparison, ensuring that order differences do not cause false drift reports. [[1]](diffhunk://#diff-21f5937855b4b87d151a77151a2b79e689eef46e372ef5fec22864e684729b19L223-R223) [[2]](diffhunk://#diff-21f5937855b4b87d151a77151a2b79e689eef46e372ef5fec22864e684729b19L241-R241) [[3]](diffhunk://#diff-636adbbc5bcc10efc5ba31410af63ff8cf0c352f5cfeac24dde5d4f7463348a5L234-R234) [[4]](diffhunk://#diff-636adbbc5bcc10efc5ba31410af63ff8cf0c352f5cfeac24dde5d4f7463348a5L248-R248) [[5]](diffhunk://#diff-8094476ac96a5b9884740aae3a3e267ea51843d9caa915f8c9fd87d1aecf9d87L78-R78) [[6]](diffhunk://#diff-8094476ac96a5b9884740aae3a3e267ea51843d9caa915f8c9fd87d1aecf9d87L88-R88) **Bug fixes and accuracy improvements:** * Corrected the field used for reporting the 'Trial Autoclaim' policy value from `policyValue` to `tenantPolicyValue` in `Invoke-CIPPStandardDisableSelfServiceLicenses`. [[1]](diffhunk://#diff-8d188a1e9388883bced1f8938fab119c89ab15d3aaea5f5357817a6a32cb4e5aL69-R69) [[2]](diffhunk://#diff-8d188a1e9388883bced1f8938fab119c89ab15d3aaea5f5357817a6a32cb4e5aL148-R148) * In `Invoke-CIPPStandardSPFileRequests`, updated the in-memory state after remediation so that drift reports reflect the post-remediation values rather than outdated ones. **Code cleanup:** * Removed an unnecessary line in `Invoke-CIPPStandardTeamsMeetingRecordingExpiration` that could have incorrectly set the current value to `$true` instead of the actual expiration days.
Adjust the comparison logic to properly handle cases where the result is null when the CompareType is not 'Catalog'. This ensures that the comparison results are always returned as an array, preventing potential errors. Fixes "Failed to compare policies: Index operation failed; the array index evaluated to null." error on the compare policy page
Enhance the ListIntunePolicy function to support group policy definition lookups and improve handling of requests for configuration policies and group policy configurations. This update allows for more efficient data retrieval. Frontend PR: KelvinTegelaar/CIPP#5951
…tandardSPFileRequests function
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )