How to Fix Stale “Ghost” Connectors in Your Database

You may have run across an issue where none of your connectors are running. When I say none, I mean AD connectors, Configuration Manager Connectors…NONE!

You also may see repeated errors in the operations event log as well.

While trying everything that I thought I knew of, from going through the Workflow engine troubleshooting, credential permissions, to possible password character issues, I searched online and ran across this article that looked promising. Trust me, it was not an easy find.

It linked to another article that talked about having Stale SCCM Connectors and getting with MSFT premier that helped them find the source of the issue. So, I decided to give that a try. And what you know…BOOM! It worked! MIND BLOWN!

While I provided the link to how to get it fixed, I would like to share a little more of my step by step process just in case you visual folks like to see it that way…here we go!

Oddly, most of the connectors stopped on Halloween, October 31st.

It was a couple weeks later when this issue was discovered.

Looking at the Event logs you may see a bunch of repeated errors and I’m going to place keywords here that you could ignore, but I want to type this out just in case someone in the future has this same issue, and by researching using these keywords, they could run across this article. Also, by looking at the errors you would think there might be permission issues or firewall talking to the database and so on…

• Error: The relationship source specified in the discovery data item is not valid
• Warning: Data Access Layer rejected retry on SQLError:
• Event ID: 3333
• Event ID: 3334

Okay, let’s get to the fix. Again, big credit for the person who posted the original article above, because I was about to do a database restore if I didn’t find a solution.

The first portion of resolving this will be done in the database. The second part will be done from exporting the “ServiceManagerLinkingFrameworkConfiguration” and making some edits within and re-importing it back into SCSM.

1. From the screenshots above you see the connectors that I’m working with. Just to be sure, run this query below against the Service Manager DB. The first one will provide you the results of the connectors that you should see in the Console.select * from MT_Connector use ServiceManager
2. Run this next query below to get the DataSourceName column.use ServiceManager select * from lfx.DataSourceFrom the results of the above screen shot you will find that there are stale (Ghost) connectors that I never knew existed or even shown up in the console with the “Delete – “in front of the connectors name. Those are the ones we are going to delete and clear out.
3. In this step, you want to copy the DataSource Name of the connectors that correlates with the name “Delete – “. Place them in the the DataSource name of the Ghost connectors in the script below. I have screenshot of the script where you input your DataSource Name, which are lines 13 to 18.

[code language=”javascript”]
—Start: Remove ghost(“deleted”) AD connectors from datasource—

use ServiceManager

DECLARE @DataSourceId INT

DECLARE @out VARCHAR(2000)

DECLARE myCursor CURSOR FOR

select DataSourceId from lfx.DataSource where DataSourceName in

(

–!!Attention!! Don’t put the datasource name here if you are not

–sure if it’s discarded object.

–Replace the ghost datasource name identified in step #3

‘ADConnector.c6f351d1445640fa942607b60c318220’,

‘ADConnector.0e1ccd9f233846a68c9949a9f8b35e0c’,

‘ADConnector.4c339a62fb0d4ae299825d50dd0eb853’,

‘ADConnector.ebbbbbdc51bf4499a95a35070483d651’,

‘ADConnector.35842b01cd22468d960f5680ba7a690e’,

‘ADConnector.87a69b3aa68140388d4c8d04a2045fcb’

–Replace the ghost datasource name identified in step #3

)

OPEN myCursor

FETCH NEXT FROM myCursor INTO @DataSourceId

WHILE @@FETCH_STATUS = 0

BEGIN

EXEC LFX.DEL_DataSource @DataSourceId, @out

SELECT @out

FETCH NEXT FROM myCursor INTO @DataSourceId

END

CLOSE myCursor

DEALLOCATE myCursor

—End: Remove ghost(“deleted”) AD connectors from datasource—
[/code]

Results after running the script:

BOOM! Lookie lookie, the connectors ran!

But we are not done yet. Although the connectors ran, we still have one more main thing to do. That is to move on to the SCSM console and editing the Management Pack.

1. Export management pack “ServiceManagerLinkingFrameworkConfiguration” to your desired location. I recommend making a copy of this management pack and storing it before editing it.
2. Open the Management Pack and do a search of the DataSourceName that you used to remove the stale (Ghost) name that started with “Delete- “. It will be sandwiched between the “Writeaction” section. Remove the whole write action section of the datasourcename you find.
3. After you have removed all the targeted DataSource Names, save the management pack and reimport into the SCSM console.
4. Remove the HealthService folder.
   1. Stop Monitoring Agent
   2. Stop System Center Data Access Service
   3. Stop System Center Management Configuration
   4. Delete “Health Service State” folder (this is located where SCSM install location, example: E:\Program Files\Microsoft System Center 2012 R2\Service Manager
   5. Start Monitoring Agent
   6. Start System Center Data Access Service
   7. Start System Center Management Configuration
5. DONE!

And all the errors in the Event logs cleared up as well:

After enabling all my connectors one by one and tested that they were to sync, perfect-o!

Let us know if this is of help and feel free to reach out through the Cireson Community for more tips and tricks!