We created a new MA and sync rules to provision to a new system. There was issues with the vendor and we deleted the MA and recreated it. Now there is an error on that sync rule: e462f0ae-aedf-4a98-9218-d90fcf495d7b(The referenced Management Agent has been deleted. Please delete this Synchronization Rule, update the external system field or re-import the deleted Management Agent) I've tried to delete the sync rule, but it returns an error of Timed Out. I can't open the sync rule either. How can i get rid of this? This is causing my FIFS on the FIM MA to hit 5000 errors (sync-rule-validation-parsing-error), which is the limit. Any ideas?Opper ...don't stop.

Hi Opper, If an object (such as a SR) has references to other objects, it wont let you delete it. I'd suggest that you have EREs that reference this 'orphaned' SR - are you able to identify these EREs? Cheers, MMS_guruIdentity & Metadirectory, Hewlett-Packard UK

Idea, yes; guarantee, no - would that be good enough for you? The problem in your scenario is a dead reference to a MA object that doesn't exist anymore. I have a "quasi" repro and script code to fix it. Quasi repro means, that I have only tested the script code with an ADMA in my lab environment, which is not good enough for a general statement. The idea is to create a new MA that has the same type as the deleted management agent and to point your OSR to the new MA. One concern I have, however, are the selected object types and attributes. You new MA should have the object types selected that are configured in your synchronization rule and the attributes selected that are configured in your outbound attribute flow mappings. If you don't know what the object types and attributes are, you should be able to get the information from a FIMOV report. I can give you the script code if you want to. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi Opper, If an object (such as a SR) has references to other objects, it wont let you delete it. I'd suggest that you have EREs that reference this 'orphaned' SR - are you able to identify these EREs? Cheers, MMS_guruIdentity & Metadirectory, Hewlett-Packard UK

remove the SR from all workflows which are using you old SR .. and you can use this powershell script to delete EREs which are pointing to your SR : http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/3db4100d-16da-4002-9708-43949659a4f8/ modify the -customconfig parameter as: -customconfig "/ExpectedRuleEntry[DisplayName='your old SR DisplayName']" you can get the exact SR displayname from the portal or by going to the synchronization manager->metaverse search and search for SynchronizationRule objects.

remove the SR from the workflows referencing your SR, and if you have large number of EREs referencing the SR you'll get timeout (by default I think 60 seconds), you can increase the timeout so you can delete the SR. and you can use this powershell script to delete EREs which are pointing to your SR : http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/3db4100d-16da-4002-9708-43949659a4f8/ modify the -customconfig parameter as: -customconfig "/ExpectedRuleEntry[DisplayName='your old SR DisplayName']" you can get the exact SR displayname from the portal or by going to the synchronization manager->metaverse search and search for SynchronizationRule objects.

Great. THanks for the input! I was able to delete the SR with a few attempts. The ERE's still exist, so I'll try this script out to remove them. Opper ...don't stop.