I have a SQL MA that projects records to the metaverse. I have an Extensible Connector MA that exports records to a web service. I perform the following deletion test... 1. Remove a record from the SQL connected data source 2. Run a Full Import on the SQL MA (deleted record appears as a staging delete) 3. Run a Full Synchronization on the SQL MA (deleted record appears as a deleted connector in inbound synchronization) 4. Run an Export on the Extensible Connector MA Nothing happens durig the Export in step4 and no changes are reported. This is probably due to step 3 resulting in no outbound synchronization. I'd like to know why step 3 only resulted in an inbound deletion. It appears the MV object has been deleted (it has no attributes). This is as expected as the object type is configured to delete the MV record when the SQL MA is disconnected. The deprovisioning configuration for the SQL MA is set to "Make them disconnectors". The deprovisioning configuration for the Extensible Connector MA is set to "Stage a delete on the object for the next export run". I've read a lot about the need for a dummy confirming import. Is this what I need? The data source that I'm exporting to cannot be accessed for import. Given the steps I've described above, is it right that step 4 apparently does nothing? A post from 2008 by Ahmad suggests the confirming import issue was to be resolved at some point... "We're working on a fix right now that will make it so that if you have an MA marked as export only, we will delete the object upon export. We will act as if we have done a confirming import of the operation we just exported so that you don't have to do the confirming import for an export only MA." http://social.technet.microsoft.com/Forums/en-US/identitylifecyclemanager/thread/36e2ba55-ea1a-4e47-9e30-4e6efbfc6ae0

A confirming import is a required step of the export process that enables convergence to work - it is not a dummy!To be deleted, the object must be actually deleted in the metaverse.If the object still exists, it sounds more like the object deletion rule has not been configured to delete the metaverse object.You can find all you need to know about deletions here.Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks for the response Markus. You're correct, the metaverse object wasn't being deleted. I had the importing MA's deprovisioning set to "make them disconnectors" and the exporting MA set to "stage a delete". This bit was ok. I had the object deletion rule set to "Delete metaverse object when connector from ANY of the following management agents is disconnected", which was ok too. But the MA I'd nominated was the wrong one (similarly named). It was obvious something was wrong as I was not getting any "Export Deletion". Now that I've corrected the deprovisioning setting, I run a full sync and get an outbound synchronisation event "Provisioning Disconnect". I then search the connector space of the Export MA and can see the object is marked as a disconnector, with an operation of delete. So far so good. Then I run an Export on the Export MA but I don't get any deletes. A search of the connector space shows that the disconnector object has changed to a placeholder type object. What does this mean? I'll start a new thread regarding my issues with running a confirming import.

I've corrected my object deletion rule and created a confirming import. Now after I delete a record in the SQL data source and perform a synchronization on the SQL MA these are the results... Inbound Synchronization ======================= 1 Deleted Connector 1 Metaverse Object Delete Outbound Synchronization ======================== 1 Provisioning Disconnect (for the extensible MA) However, my subsequent Export on the Extensible MA does not result in a deletion. I'm expecting to see the ExportEntry method called in my IMAExtensibleCallExport interface. But it's not happening, despite MV object being deleted, and the Extensible MA being configured to "Stage a delete on the object for the next export run". The object in my Extensible MA connector space is listed as an Explicit Disconnector (mv-deletion-rules) of object type Placeholder. According to the document referred to by Markus, FIM stages an export deletion request during a synchronization run. I'm presuming this means the synchronization run of the SQL (Import) MA, rather than the extensible (Export) MA. I haven't implemented a Deprovision method, as I'm expecting the Extensible MA's "Stage a delete on the object for the next export run" setting will trigger an ExportEntry of modificationType "delete". Also according to the document, the removal of the link relationship during the outbound synchronization phase triggers the deprovisioning synchronization rule. Is the "Provisioning Disconnect" an example of this? What do I need to do to trigger the ExportEntry method to be called during the Export? Any assistance is very much appreciated.

I've done a lot more work on this but still don't have a resolution as to why I don't get delete actions passed to the ExportEntry method. I now have a confirming import (Full Import initially and then delta import for subsequent confirms). I execute the following run profiles... 1. Full Import from data source 2. Full Synchronisation for Import MA 3. Export for Export MA 4. Confirming Full Import for Export MA <Delete record from data source> 5. Full Import from data source 6. Full Synchronisation for Import MA <Object has been deleted from Metaverse> 7. Export for Export MA 8. Confirming Delta Import for Export MA ...and there are no delete actions for my Export MA. The closest I'm getting is a delete entry in the log file configured in the Export step: delta operation="delete" Any ideas????

It doesn't look like there is anything wrong with your environment. The only thing I can think of is an issue with your MA configuration. There are two types of exports: call-based and file-based. Have you looked at these two docs yet: Developing a File-Based Export Management Agent Developing a Call-Based Export Management Agent What happens in case of an Add operation? Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi Markus, thanks for the response. The MA is a call-based Export MA (as opposed to Import and Export). Add and Replace actions are successfully being triggered in my ExportEntry method. Can you advise during which run step you would expect a delete action to be triggered in my ExportEntry method? Eg. Is it ... a. During the outbound sync (of my Import SQL MA)? b. During the export (of my XMA)? or c. During the confirming delta import (of my XMA)? Regards

Barry, Your code will get called when you run the Export (of the XMA). It looks like you have a problem with the deprovisioning code on your XMA. You have solved the problem where your MV object was not getting deleted. Now you need to tell FIM to delete the object out of the web service. There should be a section in the XMA config called "Configure Deprovisioning." In this section, make sure that "Stage a delete for this object on the next export run" is selected. Based on your description, it appears you have "make them explicit disconnectors" selected. -Jeremy

Thanks for the reply Jeremy. I can confirm that my XMA is configured to stage deletions... The deprovisioning configuration for the SQL MA is set to "Make them disconnectors". The deprovisioning configuration for the Extensible Connector MA is set to "Stage a delete on the object for the next export run". ...the object in my XMA connector space is made an explicit disconnector, and it's type is changed to "Placeholder". I can also confirm that no errors occured in any of my run steps. I understand errors in other steps can cause FIM to avoid deleting data. The closest I'm getting to a delete, is this log file that is created during the export step... <?xml version="1.0" encoding="UTF-16"?> <mmsml xmlns="http://www.microsoft.com/mms/mmsml/v2" step-type="export"> <directory-entries> <delta operation="delete" dn="a3b4c9cd-6e3b-41a5-81ed-1f97918023ba_Postal"> <anchor encoding="base64">WAAAA......</anchor> </delta> </directory-entries> </mmsml>

Is this object referenced by another object in the same connector space? Have you tried to debug your XMA code? Is your code being entered at all during the processing of this object? -Jeremy

Hi Jeremy I've finally got around to debugging the XMA code. I have a breakpoint on BeginExport and EndExport and both of these breakpoints are being reached. I also have a breakpoint on ExportEntry which is NOT being reached. This suggests my export step is successfully calling my XMA code but FIM is not advising of any delete actions. In my test, I emptied all the connector spaces and the metaverse and imported just two objects into a particular connector space. So there were no references involved. If no-one has any further suggestions I'll now prepare to make a support call to MS.

Barry, before running an export on your ECMA, you check whether you have a deletion staged. You can verify this by running "Using PowerShell to display the export state of a management agent". If there is no deletion staged, the export method won't be called. From your description, I get the impression that you are testing your scenario with a de-provisioned export phantom and not with a CS object that has a staged deletion. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks for directing me to the powershell script Markus. When the import SQL MA is synchronised, the connector is deleted, the mv object is deleted, and a provisioning disconnect is listed in the outbound sync. The powershell script lists one deletion. A search of the connector space for the export ECMA shows a pending export of type 'delete'. Interestingly, the Connector Space Object Properties for the object to be deleted has three tabs. "Pending Export", "Import" and "Lineage". The first tab "Pending Export" shows a modification type of delete. The second tab "Import" shows a modification type of "add", and all the attributes are listed with empty old values and populated new values. Perhaps this is a clue. Why would the CS object for the ECMA show a pending delete export and an add import? After running the export, no delete is passed to the ExportEntry method, the object type in the ECMA connector space is changed to a placeholder. And interestingly the powershell script still reports one deletion pending.

Barry, what you see is up to a certain degree expected. Connector space objects do always store various states of an object. When you import (stage) data from an external system, the affected connector space objects are pending. Such an object is also known as pending import. This means, they have data staged that has not been seen by the metaverse yet. Export operations don't have an impact on the import state. In your step list above, add a step: 4.5 Delta Synchronization on Export MA. Repeat your test, and you will see that the import doesn't report an add anymore. Like in case of your other post, I would suggest doing these low-level tests with an ADMA instead of your ECMA. That way, you can get a clear picture of "how it should be". So, the "add import" on your object is by design and expected - you can get rid of with with step 4.5. What strikes me a bit is that the object shows up as placeholder. As Jeremy has indicated, placeholders are referenced objects that have not been imported by FIM. I would expect the object to be an explicit disconnector. "After running the export, no delete is passed to the ExportEntry method, the object type in the ECMA connector space is changed to a placeholder. " What happens if you run a full import now? Is the object still in the connector space? Could you post a CSExport of the affected object? Again, I would analyze a deletion on an ADMA object to get a reference for "how it should be". Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi Markus I ran your suggested operation for step 4.5 and it removed the add as promised. Regarding your question on what happens if a full import is run after the export...I presume you mean an import on the export MA. If I run a confirming full import the result is "completed-no-object" because the previous Export (after the delete) did not send any updates. And at this stage the object is still present as a placeholder. Here's the xml from CSExport for the affected object... - <cs-object cs-dn="aab285ad-5c6f-4d4a-a0ff-1924cd3dd79b" id="{315007F2-474C-40F9-B756-244ACB9A69E0}"> - <unapplied-export> <delta operation="none" dn="aab285ad-5c6f-4d4a-a0ff-1924cd3dd79b" /> </unapplied-export> - <escrowed-export> <delta operation="none" dn="aab285ad-5c6f-4d4a-a0ff-1924cd3dd79b" /> </escrowed-export> - <unconfirmed-export> <delta operation="none" dn="aab285ad-5c6f-4d4a-a0ff-1924cd3dd79b" /> </unconfirmed-export> - <pending-import> <delta operation="none" dn="aab285ad-5c6f-4d4a-a0ff-1924cd3dd79b" /> </pending-import> <synchronized-hologram /> - <unapplied-export-hologram> <entry dn="aab285ad-5c6f-4d4a-a0ff-1924cd3dd79b" /> </unapplied-export-hologram> - <escrowed-export-hologram> <entry dn="aab285ad-5c6f-4d4a-a0ff-1924cd3dd79b" /> </escrowed-export-hologram> - <unconfirmed-export-hologram> <entry dn="aab285ad-5c6f-4d4a-a0ff-1924cd3dd79b" /> </unconfirmed-export-hologram> - <pending-import-hologram> <entry dn="aab285ad-5c6f-4d4a-a0ff-1924cd3dd79b" /> </pending-import-hologram> <connector>0</connector> <connector-state>explicit</connector-state> <seen-by-import>1</seen-by-import> <rebuild-in-progress>0</rebuild-in-progress> <obsoletion>0</obsoletion> <need-full-sync>0</need-full-sync> <placeholder-parent>0</placeholder-parent> <placeholder-link>0</placeholder-link> <placeholder-delete>0</placeholder-delete> <pending>0</pending> <ref-retry>0</ref-retry> <rename-retry>0</rename-retry> - <sequencers> - <current> <batch-number>197</batch-number> <sequence-number>11214</sequence-number> </current> - <unapplied> <batch-number>197</batch-number> <sequence-number>11214</sequence-number> </unapplied> - <original> <batch-number>197</batch-number> <sequence-number>11214</sequence-number> </original> </sequencers> <import-delta-operation>add</import-delta-operation> <export-delta-operation>delete</export-delta-operation> <pending-ref-delete>0</pending-ref-delete> <ma-id>{60D943B4-18A3-4FEE-9D00-E47BBCF296A6}</ma-id> <ma-name>Export</ma-name> <partition-id>{09A9A754-CA6D-4EDA-9A5E-A45F06F6A117}</partition-id> <disconnection-type>unknown-rule</disconnection-type> <disconnection-id>{CBBD455D-94BD-47C6-90E6-05AF1021A2D1}</disconnection-id> <disconnection-time>2010-05-20 03:25:18.947</disconnection-time> <last-import-delta-time>2010-05-20 03:22:35.960</last-import-delta-time> <last-export-delta-time>2010-05-20 03:25:18.950</last-export-delta-time> <partition-name>default</partition-name> </cs-object>

The ECMA is based on a File MA. When you run a full import on a File MA, the data file must have at least one object – otherwise, the import is not processed. This is a safety feature to avoid unwanted deletions. To get rid of your placeholder, you will have to put one dummy object in your import file for a full import. How you ended up with a placeholder is not really clear to me right now. Your best bet is to divide your project into two separate projects. To become familiar with how the ECMA woks, you are in my opinion better off using an ADMA with a user object. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation