Add preflight checks and improve documentation for the “Modify SQL Server configuration” option
1.) When running the SCCM Setup Wizard and choosing “Modify SQL Server configuration” there does not appear to be an adequate preflight check to ensure Config Manager is running with full administrative rights to A) operating systems, B) SQL instances and C) Config Manager itself. These permissions are (obviously) critical to a SQL configuration change. In enterprise environments, setup.exe should be reaching out to check rights to all the things it needs to modify (file system, registry, certificates, etc.) before it executes the changes. Partial modification of the configuration has catastrophic results.
2.) Execution of the SQL configuration change does not perform quite enough validation during modification to determine that each small change was successful, with errors listed in the setup.log. It is possible for setup.exe to complete with success according to the GUI, but ultimately fail to create certificates, registry changes, and propagate SQL broker updates.
3.) Documentation around how to effectively prepare and run the “Modify SQL Server configuration” could use improvements in the areas of A) minimum rights required to the OS CAS, PRI, SQL systems and CM, B) stopping site components C) detaching a database D) copying database files E) attaching and configuring the new database, F) running setup wizard with more detail around what setup.exe performs, and how long it takes... and last G) how to validate the changes were successful with SPDiagDRS and Replication Link Analyzer.
Joel Holliday
shared this idea
Thanks for the feedback, updating status to Noted and moving to ‘Setup and Server Infrastructure’
2 comments
-
Thank you for the documentation feedback. I created an issue on the relevant article:
https://docs.microsoft.com/sccm/core/servers/manage/modify-your-infrastructure#bkmk_dbconfigI'll use this as the primary tracking for the doc suggestion
https://github.com/MicrosoftDocs/SCCMdocs/issues/987 -
OuterChild
commented
This is something that the product has needed for a long time. The setup was originally designed for recovery scenarios not for moving large production DBs.
