Repository navigation
Conversation
The #59 live Patch Status refresh read SPProductVersions.GetProductVersions, which returns the product/patch status cached in the configuration database. A local binary install does not update that cache until Get-SPProduct -Local runs on the server, so the card kept the pre-install status (e.g. No Action Required) instead of the real post-install one (e.g. Upgrade Blocked). Call Get-SPProduct -Local before reading the patch status in the ProductUpdate action (which runs locally on each patched server), so the read reflects the live state. This also makes the master's later aggregate reads accurate once every server has refreshed its own entry. Refs #71
Pester Test Results 1 files 46 suites 12s ⏱️ Results for commit 018b64a. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The refresh call must use -ErrorAction Stop for its fallback handling to catch non-terminating errors reliably.
Review effort: Balanced
Findings: 1
Open (1)
What changed in this PR
Refreshes SharePoint’s local product cache after ProductUpdate so dashboards report current patch status.
Changes:
- Runs
Get-SPProduct -Localafter successful installation. - Documents the fix for #71.
| File | Description |
|---|---|
src/SPSUpdate.ps1 |
Refreshes the local product cache before reading patch status. |
CHANGELOG.md |
Records the dashboard status fix. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Add -ErrorAction Stop to Get-SPProduct -Local so a non-terminating failure is caught by the surrounding try/catch and handled as the intended non-fatal verbose path, instead of leaking an error record before the read continues. Refs #71
|
Hold — do not merge into a release yet. The underlying fix changes the live Patch Status path, which can only be exercised by a real CU install (an already-patched server reports |
Pull Request (PR) description
Fixes the stale Patch Status reported in #71, found during the v5.2.0 live-test campaign on a Subscription Edition farm.
Problem
The live Patch Status refresh added in #59 read
SPProductVersions.GetProductVersions($spFarm)(viaGet-SPSServersPatchStatus), which returns the product/patch status cached in the configuration database. A local binary install does not update that cache untilGet-SPProduct -Localruns on the server, so right after-Action ProductUpdatethe Binaries card kept the pre-install value (No Action Required) while Central Administration already showedUpgrade Blocked.Fix
Call
Get-SPProduct -Localto refresh the local server's product cache before reading the patch status in theProductUpdateaction (it runs locally on each patched server, so-Localupdates that server's own config-DB entry). This also makes the master's later aggregate reads accurate once every server has refreshed its own entry. A refresh failure is non-fatal (logged to verbose; the read then degrades to the previous behaviour).This Pull Request (PR) fixes the following issues
Task list
src; Pester 296 passed / 0 failed / 1 skipped. TheProductUpdatelive-status path is Windows/SharePoint-only and not unit-tested, consistent with the rest of that action.