Table of Contents
PURPOSE. 2
WHY – Why delete the connector space. 2
STEPS – Steps to guide you through deleting the connector space. 3
Backup Database. 3
Validate the Object Deletion Rule. 3
ATTRIBUTE RECALL. 4
DELETING THE CONNECTOR SPACE. 5
DISABLE PROVISIONING.. 5
BRING THE OBJECTS BACK INTO THE METAVERSE (Import and Synchronization). 6
CHECKING EXPORTS BEFORE ACTUALLY EXPORTING.. 7
Pending Exports Connector Space Search. 7
Export to a drop file. 7
RETURN THE SYSTEM BACK TO THE ORIGINAL CONFIGURATION.. 8 ADDITIONAL INFORMATION ON DELETING CONNECTOR SPACES
The overall goal or purpose of this document is to provide guidance and instruction when the need arises to delete a connector space. The document will cover steps that should be done, and should be thought about prior to deleting the connector space.
Why are you deleting the connector space? It is very important to understand why you are getting ready to delete the connector space. You want to understand the ramifications of deleting the connector space in your identity management solution. It is important to understand this, as it could cause serious ramifications if not done correctly and thought out.
The main reason to delete a connector space is due to data corruption in the connector space. There are times that the connector space will end up with corrupted data and the only way around it is to delete the connector space. However, the metaverse object is ok, so we will want to leave that alone in some cases.
Is the connector space that you are deleting part of a complete FIM solution including the FIM Service Management Agent? If the answer is yes, then once you have completed these steps, then you want to review the wiki on deleting the FIM Service Management Agent Connector Space. Why? You will want to review this document, because you will want to be able to bring your environment back up in the quickest possible manner. The wiki will help cover these steps to allow you to bring your environment back and re-sync the objects from the FIM Portal with those in the metaverse.
*NOTE* If you are using Declarative Provisioning, then all of your DREs will be deleted. They will be re-created when the object is put back. It will, however, cause object synchronization “churn” that could extend the time it takes to recover from the connectorspace deletion.
Thinking of disaster recovery, we want to be able to get back to the previous setup without too much trouble should the need arise. To do this, we recommend that the FIM Synchronization Service Database (MicrosoftIdentityIntegration Server database for IIFP/MIIS/ILM) is properly backed up prior to deleting the connector space. If you are using the FIM Service and Portal, then we recommend backing up the FIM Service database as well.
Find more information on backing up the backend database here.
*NOTE*You will need to set this for each object type that you are working with in the connector space that is being deleted. (picture displays the person object type)
For more information on understanding the deprovisioning process, click here.
Attribute Recall is where the Synchronization Service decides if we need to leave the attribute information that has been provided by the management agent chosen to have its connector space deleted.
You can get here by:
At this point, we are ready to delete the connector space.
*NOTE* If you are actually deleting the management agent, then you would choose the second radio button. However, it is still very important to go through all the pieces of this document to ensure that we can get back to a previous state should the need arise.
Once the deletion process has occurred, we want to be able to import and synchronize the objects back into the metaverse without running through provisioning. This will allow for objects to join back up to existing objects. If you are using Synchronization Rule Provisioning, you need to ensure that one is disabled as well.
At this time, we should be ready to bring the objects back into the connector space first, and then send them to the metaverse. In doing so, we will take a safe path first by Previewing a few objects to ensure success. Since we do not have provisioning enabled, then we will be joining the objects to the existing metaverse objects.
A procedure such as deleting the connector space can bring some un-wanted results to appear. In light of that, we want to be extra cautious and review our Pending Exports before they are actually written to the connected data source.
There are two ways that we can actually execute this, and if the desire is to be as cautious as possible then execute them both.
If the data has returned to its correct format, and you feel comfortable, then you are ready to export the data to the connected data source, or execute the step below to Export to a Drop File.
Exporting to a drop file allows you to view the data that is going to be exported to a connected data source. Remember that exports are always delta, and only exporting changes. So the data that you will see in the drop file is just the objects that were changed, and the attributes that are being changed as well.
The data will be dropped to an XML file in the %programfiles%\Microsoft Forefront Identity Manager\2010\Synchronization Service\MaData\<Target Management Agent Name>. Review this file and understand what data will be exported, and the actions that will happen. Once the export to a drop file passes, then you are ready for the export.
ADDITIONAL INFORMATION ON DELETING CONNECTOR SPACE
Tim Macaulay edited Revision 7. Comment: updated the title
Tim Macaulay edited Revision 6. Comment: title change
Tim Macaulay edited Revision 5. Comment: Added Additional Information on deleting connector spaces