[pull] master from KelvinTegelaar:master#110
Merged
pull[bot] merged 83 commits intoInformatics123:masterfrom May 8, 2026
Merged
[pull] master from KelvinTegelaar:master#110pull[bot] merged 83 commits intoInformatics123:masterfrom
pull[bot] merged 83 commits intoInformatics123:masterfrom
Conversation
Update Get-CIPPSchedulerBlockedCommands.ps1 to include queueing-related functions (Add-CippQueueMessage, New-CippQueueEntry, Set-CippQueueTask, Update-CippQueueEntry) in the blocked commands array.
No way to remediate but we can use Read-DmarcRecord directly to query the current value and use that for reporting
…tGroups Co-authored-by: Copilot <copilot@github.com>
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>
…#2041) ## Summary - Adds optional `usageLocation` (ISO 3166-1 alpha-2) to JIT Admin user creation via Graph API - Saves `defaultUsageLocation` in JIT Admin templates (both Add and Edit) - Prevents Huntress false-positive alerts for JIT Admin accounts missing usage location Fixes KelvinTegelaar/CIPP#5910 Companion PR (frontend): KelvinTegelaar/CIPP#5971 ## Changes - `Set-CIPPUserJITAdmin.ps1` — conditionally includes `usageLocation` in the Graph POST body when creating users - `Invoke-ExecJITAdmin.ps1` — passes `usageLocation` from request body to the User hashtable - `Invoke-AddJITAdminTemplate.ps1` — saves `defaultUsageLocation` in template object - `Invoke-EditJITAdminTemplate.ps1` — same for template editing
- Updated Set-CIPPManager and Set-CIPPSponsor functions to accept multiple users for bulk processing. - Modified Invoke-EditUser and Invoke-PatchUser to handle bulk updates for managers and sponsors. - Enhanced logging for success and error messages during updates.
The autocomplete component sends {label, value} objects but the
Graph API expects a plain string for usageLocation. Extract .value
before passing to API, matching the pattern used by other user
endpoints (Invoke-AddUserDefaults, Invoke-EditUser, etc).
The usageLocation autocomplete sends {label, value} objects but Graph
API
expects a plain string. This causes a "StartObject node found for
usageLocation, PrimitiveValue expected" error when creating JIT Admin
users.
Extract .value before passing to the API, same as Invoke-AddUserDefaults
and Invoke-EditUser already do.
Enable bulk processing for setting multiple managers and sponsors in user updates. Introduce 'manager' and 'sponsor' properties to the user patching functionality. Frontend PR: KelvinTegelaar/CIPP#5976
… reseller relationship links implements KelvinTegelaar/CIPP#5963
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.
7 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 : )