Removing an old product connector

 

UPDATE 10/4/2011 – This article is now out of date. There is a KB article with a supported method to delete old product connectors:

https://support.microsoft.com/kb/2626670

Please refer to the article above if you need to remove a connector. The blog article below is for informational purposes only now.

 

 

 

 

 

 

In OpsMgr – there is no simple way to remove a product connector once installed.  There is no delete function in the UI:

 

image

 

What if you have an old connector that you no longer use?  Or, if you quit using an Engyro connector, and started using a MS branded R2 connector?

It may be necessary to forcibly remove a connector from OpsMgr 2007.

 

*** Note – this process is not officially supported. There is no officially supported way to remove an old connector. It is only being demonstrated here for example purposes. I have used these steps with customers, and thus far no ill effects were discovered. These steps were gleaned from a MS newsgroup posting.

 

Open SQL Server Management Studio from the Start menu and run the following queries on the Operations Manager database.

 

Step 1: Remove ANY and ALL subscriptions assigned to this connector you wish to delete:

In the UI – open the connector you wish to remove – and delete the Subscriptions that are present.  Make sure these are all removed before you continue or you will have orphaned subscriptions at the end of this process.

 

Step 2: Find the ConnectorID:

select DisplayName,IsInitialized,ConnectorID from Connector,BaseManagedEntity
where Connector.BaseManagedEntityID=BaseManagedEntity.BaseManagedEntityID

This will return 3 Columns: The Display Name, Initialized Flag, and ConnectorID.

Find the ConnectorID of the connector you want to remove.  Copy it to Notepad for safekeeping.

 

Step 3: Un-Initialize the Connector

If the Connector field "IsInitialized" is 1, then you will need to uninitialize the connector before deleting it.

If IsInitialized is 0, skip to step 4.

Use the p_ConnectorUpdate SP to uninitialize the connector:

The first column is YOUR connectorID, 2nd column is the bookmark (this should be NULL), and the 3rd column is the initialized state (0 in our case)

EXEC p_ConnectorUpdate '5fabdf4c-a1f8-43bf-ac18-e46e20bd470b',NULL,0

Make sure this worked – by re-running the initial query, and ensure the connector initialized state is now 0.  DO NOT CONTINUE until this is verified as not initialized.

 

Step 4: Delete the Connector

Use the p_ConnectorDelete SP to delete the connector.

The first parameter is YOUR ConnectorID, the 2nd Parameter is the comments you want added to the alert history when the connector is deleted, and the 3rd parameter is the Modified By field you want added to the alert history. (I use NULL for the optional fields to keep it simple.)

EXEC p_ConnectorDelete '5fabdf4c-a1f8-43bf-ac18-e46e20bd470b',NULL,NULL

 

This procedure can take a long time if there is a lot of data still associated with the connector. Be Patient.

 

 

Now – I need to mention – there is also a very interesting community tool – which was written to manage product connectors.  I have not used it – but it is worth a look:

https://www.systemcentercentral.com/Downloads/DownloadsDetails/tabid/144/IndexID/12581/Default.aspx

 

 

NOW – what if you already ran this delete command – and forgot to delete any subscriptions to the connector FIRST?

 

You will start getting the following events ~every minute on your RMS event log:

 

Log Name: Operations Manager
Source: Health Service Modules
Event ID: 11502
Description:
The Microsoft Operations Manager Connector Framework Alert Forwarding module failed to mark an alert for forwarding because the connector the module is configured for no longer exists.
Connector Id: b7a64deb-f7ff-440e-bc30-d08d340dfe8d

Log Name: Operations Manager
Source: DataAccessLayer
Event ID: 33333
Description:
Data Access Layer rejected retry on SqlError:
Request: p_AlertSetConnectorId -- (AlertIdList=a2c51250-bd5a-43e5-96cc-158afc5e674d,b46ea1b2-42b5-47cf-ad15-da261ad13e13,d56effac-8c40-4d63-8337-58fdc09d1de1), (ConnectorId=b7a64deb-f7ff-440e-bc30-d08d340dfe8d), (Comments=), (ModifiedBy=Connector Framework Alert Write Action), (RETURN_VALUE=1)
Class: 16
Number: 547
Message: The UPDATE statement conflicted with the FOREIGN KEY constraint "FK_Alert_ConnectorId". The conflict occurred in database "OperationsManager", table "dbo.Connector", column 'ConnectorId'.

Log Name: Operations Manager
Source: HealthService
Event ID: 4502
Description:
A module of type "Microsoft.EnterpriseManagement.Mom.Modules.McfAlertWriteAction" reported an exception System.Data.SqlClient.SqlException: The UPDATE statement conflicted with the FOREIGN KEY constraint "FK_Alert_ConnectorId". The conflict occurred in database "OperationsManager", table "dbo.Connector", column 'ConnectorId'.
The statement has been terminated.
<snipped>

 

This is because we have deleted a connector that still had a live subscription associated with it.  We need to go and delete that subscription to clean this up.  The problem is – the connector is gone, so the subscription is no longer available in the UI.

Therefore – we will have to delete it manually.  This subscription (as all subscriptions) is kept in the “Notifications Internal Library” MP.  You need to export that MP to XML.  FIRST MAKE A BACKUP COPY OF THIS FILE IN CASE YOU MESS UP, then open it for editing in Notepad, or your XML editor of choice.

All subscriptions in this MP are kept in the <Monitoring> <Rules> section.  To identify which connector subscription RULE is causing the problem – you can search for the connector ID, from the event 11502 above.  In my example – my connector ID from this event is:  b7a64deb-f7ff-440e-bc30-d08d340dfe8d.

So – I search the XML for that string – and find b7a64deb-f7ff-440e-bc30-d08d340dfe8d in the <WriteActions> section of a specific <Rule>:

<WriteActions>
<WriteAction ID="WA" TypeID="SystemCenter!Microsoft.SystemCenter.ConnectorFrameworkAlertWriteAction">
<ConnectorId>{b7a64deb-f7ff-440e-bc30-d08d340dfe8d}</ConnectorId>
</WriteAction>
</WriteActions>

Good – I have identified the problem.  Now – I need to do two things:

    1. Find the rule ID – to identify the display string associated with it… then delete that display string.
    2. Delete the orphaned subscription rule.

So – I move up in the XML section of this rule – and I find my Rule ID.  (here is mine:)

<Rule ID="ProductConnectorSubscription2850f8e3_afe7_4c36_84d2_ee258bd086eb"

I then search for the part above which I bolded in blue (yours will be different – search for your string)

What this finds – is the display string section of the XML – which maps this GUID ID to the common name that you gave the subscription.  (here is mine:)

<DisplayString ElementID="ProductConnectorSubscription2850f8e3_afe7_4c36_84d2_ee258bd086eb">
<Name>Process All New Alerts</Name>
</DisplayString>

So – I need to DELETE this section from the XML…. just the section above, from my very specific <DisplayString ElementID="ProductConnectorSubscription2850f8e3<GUID> line, to the very next </DisplayString>.

Next – I need to delete the entire <rule> which contains the subscription we want to remove.  Mine will be from:

<Rule ID="ProductConnectorSubscription<GUID> line to the very next </Rule>

 

When you are happy – you can import this XML MP back into the management group.  It should import with no errors.  If you get an error – you made a mistake when editing the XML.  You can look on the RMS event log for the specific problem – there will be a critical event there if it fails to import.

 

Repeat this process if you deleted multiple connectors but left their subscriptions intact.  You can validate this from looking for 11502 events on your RMS.