Add TSG for Test-Cluster administrative privileges failure during dep…#271
Add TSG for Test-Cluster administrative privileges failure during dep…#271erskinejohn wants to merge 1 commit intomainfrom
Conversation
…loyment Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Adds a new Environment Validator known-issue troubleshooting guide to help unblock deployments failing Test-Cluster with misleading “administrative privileges / access denied” errors.
Changes:
- Added a new Known Issue TSG documenting symptoms, root cause, and resolution steps for
Test-Clusteradmin-privileges failures during deployment. - Updated the EnvironmentValidator README to include the new TSG in the Known Issues list.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
TSG/EnvironmentValidator/README.md |
Adds an index link to the newly introduced Known Issue TSG. |
TSG/EnvironmentValidator/Known-Issue-Test-Cluster-Administrative-Privileges-Failure.md |
New Known Issue TSG covering Test-Cluster deployment failures related to post-domain-join reboot/auth state. |
TSG/EnvironmentValidator/Known-Issue-Test-Cluster-Administrative-Privileges-Failure.md
Show resolved
Hide resolved
| ### Step 1: Reboot the affected node(s) | ||
|
|
||
| Reboot each node mentioned in the error message: | ||
|
|
||
| ```powershell | ||
| Restart-Computer -ComputerName <FailingNodeName> -Force | ||
| ``` | ||
|
|
||
| Wait 2-3 minutes for the reboot to complete. | ||
|
|
||
| ### Step 2: Confirm the reboot resolved the issue | ||
|
|
||
| From another node, verify you can connect to the rebooted node: | ||
|
|
||
| ```powershell | ||
| Invoke-Command -ComputerName <FailingNodeName> -ScriptBlock { whoami } | ||
| ``` |
There was a problem hiding this comment.
What: Steps 1–2 rely on remote PowerShell connectivity to the failing node (Restart-Computer -ComputerName ... and Invoke-Command -ComputerName ...).
Why: In the scenario described, authentication/remoting to the node may be the broken part, so these remote commands can fail and leave users without a workable path.
How: Add a fallback path to reboot/validate locally on the node or via out-of-band management (iLO/iDRAC/Hyper-V console), and clarify any prerequisites if remoting is expected to work.
| <table border="1" cellpadding="6" cellspacing="0" style="border-collapse:collapse; margin-bottom:1em;"> | ||
| <tr><th style="text-align:left; width: 180px;">Component</th><td><strong>EnvironmentValidator - ValidateCluster</strong></td></tr> | ||
| <tr><th style="text-align:left; width: 180px;">Severity</th><td><strong>Critical - blocks deployment</strong></td></tr> | ||
| <tr><th style="text-align:left;">Applicable Scenarios</th><td><strong>Deployment</strong></td></tr> | ||
| </table> |
There was a problem hiding this comment.
What: The metadata table lists component/severity/scenario but omits affected versions (and any known fixed version), while the Prevention section only says “upcoming release”.
Why: Without version scope, readers can’t quickly determine if they’re impacted or whether upgrading would address the issue.
How: Add an “Affected Versions” row (and fixed version if known). If the exact version isn’t known, state the best available scope (e.g., “All versions prior to ” or “Unknown at time of writing”).
Test-Cluster "permissions" errors.