Few days ago while I was in the OpsMgr 2012 console, I realised that all 3 SQL clusters hosting my OpsMgr Ops DBs are not discovered by MS SQL management packs. All other SQL clusters with same version of SQL got discovered (i.e. clusters hosting ConfigMgr 2012 site databases, etc.).
Since I backup both sealed and unsealed MPs using my OpsMgr Self Maintenance MP, I went grabbed a unsealed copy (exported to .xml) of “Microsoft.Windows.Server.2012.Discovery” MP, extracted the discovery script “DiscoverSQL2012DBEngineDiscovery.vbs” and tried to run manually on the active node of one of the problematic SQL cluster. the script failed. So I added few lines of “Wscript.Echo” to break the scripts up and identified it failed at this line:
So next, I went to check the SQL Full-Text Filter Daemon Launcher service and realised it is set to manual and I can’t start it. I got an “Access is Denied” error.
I confirmed this service is running on all other working SQL clusters. So I went to the Windows engineer who built this SQL cluster. After some troubleshooting, the Windows engineer told me it is caused by a GPO that he created for all SCOM SQL servers.
In the GPO, he restricted permission for this service and also modified NTFS permissions for the root folder of where SQL is installed to. Somehow these settings has caused the SQL Full-text Filter Daemon Launcher services to fail to start, while the SQL DB engines are running fine and we had no issues with the SCOM databases.
In the end, after all the GPO settings are reverted back, rebooted all cluster nodes. I waited overnight and checked again next day. all SQL DB engines have been discovered in SCOM. I could also manually run the discovery script on the active cluster node: