March 22, 2023 at 5:41 am
Hi,
I've been tasked with finding out why we've been unable to patch the SQL server on our SCCM server... Pretty much a newbie from a SQL Management point of view, so forgive me for anything dumb i've missed.
I believe the failure to apply the patch is due to the msdb having a different collation to the instance & system databases. I believe this might have occurred years ago now when the SQL admin at the time had to recover the database after a problem occurred with it, but seems like he's restored the msdb from another server with different collation settings & not realised.
Is there an 'easy' way to correct this?
I've got an offline clone of the system that i'm running some tests on (currently doing a full uninstall, re-install & restore the user DBs ) but having some issues with it from the SCCM point of view which might actually just be because offline & unable to complete these steps in that state...
Cheers!
March 22, 2023 at 9:00 am
Sounds like your going to need to rebuild all the system databases.
No way to repair the MSDB database as its all system controlled.
Obviously rebuilding all the system DB's is an intrusive operation so make sure you have copies of everything server side.
Logins, Linked Servers, Audits, Jobs etc, anything that is in any folder in SSMS except the databases folder.
A probably more safer way is to build new and migrate, then repoint SCCM to the new SQL host, that way you can ensure everything is transferred and tested prior to making the final switch
March 22, 2023 at 12:40 pm
And get backups of your databases and test them by restoring them somewhere. Don't just take a backup. Test a restore too. It demonstrates that yes, the backup is good, and, yes, you can restore it. Then rebuild your system tables.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 22, 2023 at 9:48 pm
Ok cool, thats pretty much what I was expecting the answer to be.
"Logins, Linked Servers, Audits, Jobs etc, anything that is in any folder in SSMS except the databases folder."
Is there a recommended way to export/import all of this?
"A probably more safer way is to build new and migrate, then repoint SCCM to the new SQL host, that way you can ensure everything is transferred and tested prior to making the final switch"
Its generally recommended to keep the SQL Server on the same box as SCCM/MECM. We do also need to swap SQL editions from Enterprise to Standard on it, so thats why i'm currently trying to test an uninstall/reinstall on a cloned offline system.
The SQL uninstall/reinstall/restore user DB seems to be going OK (though i hadn't considered looking for any of the stuff you mentioned above) but the step for re-connecting SCCM/MECM afterwards is erroring out (log file shows "ConfigureSQLAlias() failed to connect to the registry with error 53"). Dunno if this might just be caused by being an offline system though.
March 23, 2023 at 5:37 am
Came across this today - https://learn.microsoft.com/en-us/sql/relational-databases/databases/rebuild-system-databases?view=sql-server-ver16#CreateMSDB
Gave it a shot on my cloned system & does get the MSDB setup as the correct collation. Still getting that same ConfigureSQLAlias failed though when running the MECM steps, but does look like the application is running properly (or as properly as it can offline).
Now to see if we can successfully patch/upgrade the SQL on the test system without it failing.
Doesn't solve our enterprise/standard edition issue, but patching/upgrading is the main concern for now.
March 23, 2023 at 9:34 am
Good luck, thanks for posting the createMSDB
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply