Release v1.3.1 - harden SPSyncUserInfoList against silent ACCESS_DENIED runs#17
Merged
Conversation
Pester Test Results68 tests 68 ✅ 2s ⏱️ Results for commit f51afce. ♻️ This comment has been updated with latest results. |
Get-SPSite -Limit All used -ErrorAction SilentlyContinue, so an account that cannot enumerate the farm site collections (wrong service account / missing Shell Admin) produced no output and no visible error: the ACCESS_DENIED thrown while enumerating the lazy collection was caught and written only to the Event Log, the run then emitted two confusing secondary errors (report + copy) on a JSON that was never written. - Remove -ErrorAction SilentlyContinue on Get-SPSite; surface the error to the console/transcript AND the Event Log with an actionable Shell Admin message. - Anti-clobber guard: a zero-user result never overwrites/copies the previous good JSON; it raises an explicit error and leaves the file untouched. - Signal success to the Main region; skip the compare/report/copy steps and Exit 1 when the snapshot was not produced. - Test-SPSUserSyncReadiness.ps1: new 'Site collection enumeration' check (Get-SPSite -Limit All under try/catch) that FAILs on ACCESS_DENIED with the Shell Admin hint - the exact permission the real run needs, which the Get-SPFarm-only check did not cover. - Add Pester regression tests for Get-SPSUniqueUsers (healthy / zero-user / ACCESS_DENIED). Fixes #16
Bump module to 1.3.1, date the CHANGELOG 1.3.1 section, rewrite RELEASE-NOTES for 1.3.1, and document the new readiness site-collection enumeration check in the Getting-Started wiki. (#16)
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Hardening release (v1.3.1) that makes
SPSyncUserInfoList.ps1fail loudly and early when it is run with the wrong service account (or a missing Shell Admin), instead of silently producing nothing. Follows a field case where the script was launched with an under-privileged account and produced no output and no visible error at all.This PR fixes the following issues:
Root cause
Get-SPSite -Limit Allused-ErrorAction SilentlyContinue. The collection is lazy, so theACCESS_DENIED(E_ACCESSDENIED 0x80070005) only threw while theforeachenumerated it — inside theGet-SPSUniqueUserstry/catch that funneled the error only to the Windows Event Log. No JSON was written, thenExport-SPSUserReportandCopy-Itemfailed on the missing file, burying the real cause under two secondary errors. Not a code bug (the account was wrong), but the tool was far too silent about it.Changes
SPSyncUserInfoList.ps1— fail fast, fail loud-ErrorAction SilentlyContinueonGet-SPSite.Get-SPSUniqueUserscatch nowWrite-Errors to the console/transcript and the Event Log, with an actionable ACCESS_DENIED message (Shell Admin / correct service account, showing the running account).Exit 1s.Test-SPSUserSyncReadiness.ps1— catch the wrong account BEFORE the runGet-SPSite -Limit Allunder try/catch → FAIL on ACCESS_DENIED with the Shell Admin hint. This is the exact permission the real run needs; the previousGet-SPFarmcheck only proved config-database access.Tests
tests/SPSyncUserInfoList.Tests.ps1:Get-SPSUniqueUserswrites JSON + reports success on a healthy farm; zero users → no JSON + Error event; ACCESS_DENIED → no JSON + actionable Error event.Release metadata
1.3.1, CHANGELOG1.3.1section dated, RELEASE-NOTES rewritten, Getting-Started wiki updated.Validation
./srcwith the repo settings: clean.Upgrade notes
Drop-in replacement for 1.3.0 — no configuration change required. A wrong account now fails the run explicitly (exit code
1) instead of silently producing nothing.