Digital Nervous System Making Incredible Software, Incredibly Simple

SCCM 2012 and SQL 2008 R2

After my earlier venture in the troubled waters of SQL database loss, I figured that I had survived the worst that could come. That is until my SQL and Storage guys let me know that due to some on-going concerns with the Cluster, that they planned to destroy and rebuild.

Gasping with the memories, I embraced the situation and opted to proceed with a local SQL 2008 R2 SP1 CU6 installation to be co-hosted on the same servers which are running my CAS and PRI sites. And being the ever so careful personally checked that I had database backups along with Server Backups (VM Snapshots in my case) of both my site servers.

At this point I then proceeded to install SQL2008 R2 SP1 CU6 on each of the two systems, which was pretty event free…

That was until I checked my SCCM environment to find that its broken – and broken badly… it’s not starting… Holy Crap what happened now – I just installed SQL… ???

Quickly I check the log file _C:Program FilesMicrosoft Configuration ManagerLogssmsexec.log _to be greeted with repeated messages of non-access to SQL

Starting SMS_EXECUTIVE...     
Microsoft System Center 2012 Configuration Manager v5.00 (Build 7711)     
Copyright (C) 2011 Microsoft Corp.    SMS_EXECUTIVE    8/20/2012 4:12:09 AM    2544 (0x09F0)
Running as a Win32 service.     
Process ID: 2320     
Worker thread ID: 2544     
Certificate (0x398530) is Exportable     
Initialize COM Security.     
InitializeCOMSecurity: RegOpenKeyEx for appid key Succeeded.     
InitializeCOMSecurity: RegQueryInfoKey for appid key Succeeded.
InitializeCOMSecurity: RegQueryValueEx for AccessPermission Succeeded.
InitializeCOMSecurity: IsValidSecurityDescriptor() Succeeded.
InitializeCOMSecurity: MakeAbsoluteSD() Succeeded.     
InitializeCOMSecurity: CoInitializeEx() Succeeded.     
InitializeCOMSecurity() Succeeded.     
Installation directory: C:Program FilesMicrosoft Configuration Manager     
This server: XXX-SC-CM01     
Site server: XXX-SC-CM01.corpnet.org     
Site code: CM0     
Site type: 8     
CSMSExecService::RegisterDBConnection: Register a DB connection...     
Initializing the status message reporting system...     
    The path to the "Status Manager" inbox is "C:Program FilesMicrosoft Configuration Managerinboxesstatmgr.boxstatmsgs".
*** [08001][10061][Microsoft][SQL Server Native Client 10.0]TCP Provider: No connection could be made because the target machine actively refused it.
				
*** [HYT00][0][Microsoft][SQL Server Native Client 10.0]Login timeout expired     
*** [08001][10061][Microsoft][SQL Server Native Client 10.0]A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.     
*** Failed to connect to the SQL Server.     
CSiteControlEx::GetCurrentSiteInfo: Failed to get SQL connection
CSiteControlEx::GetMasterSCF:Failed to read site information from database, retry in 5 seconds ...

A quick look around the web, and I located a hint; this issue appears when we have the SQL2008 R2 Native Client utilities installed; which I knew was not the case, as this was working up to a short while ago; I then checked my Primary site, only to see the same issues…

A check of the Add Remove programs on both of these servers however revealed that during the installation of my SQL 2008 R2 SP1 CU6 servers on these systems, that this process did indeed proceed to replace my original SQL 2008 Native Client with the new R2 version…

Using the remove option, I got a number of warnings that this was going to be a bad idea – but stubbornly I chose to ignore and proceed with removing this component. Next I went ahead and installed the original SQL 2008 Native Clients –

Shortcut: There is a copy of the sqlnci.exe in the Support Files which SCCM downloads during the installation routine if you have those files kept ;)

Finally, a reboot of the server, and we were back in business.

Be social and share this post!
Share via OneNote