none
unexpected-error when importing a user from a connected directory RRS feed

  • Question

  • Hi,

    I encountered a weird error when trying to import a user from a connected directory.  It seems that the MV entry got deleted before the object in the connector space was made a disconnector (not sure how this happened), now the connector space object "thinks" it is still connected to a MV object which no longer exists. I have two user objects like this.  I can't make the object a disconnector because it reports that the MV object doesn't exist.

    It also doesn't help to remove the object from the connected directory which is a SQL database, this also fails because of the above error. (the object is removed from the SQL database, but not from the connector space.  I have done various Full imports, Full syncs and exports but to no avail.

    Does anyone know how to resolve this without deleting the MA connector space? This is a production system and I will also have to remove all the orphaned EREs which take a long time to complete.  I have about 30K objects in the SQL database.

    Any help is appreciated

    Thanks

    Johan Marais


    JkM6228

    Thursday, April 11, 2013 11:04 AM

Answers

  • I've resorted to having to do that myself once - with similar (successful) results - and it was a last resort, and I wasn't going to recommend this here.  You are safe though I think, but this confirms you had a corruption in your CS.  I you are right that you should be able to avoid deleting the CS in Production, but be careful to back up your FIM db.  Also it would be good to find out what caused the problem in the first place.  Also, check the hotfix history to see if there's any mention of an issue like this being resolved.

    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    • Marked as answer by Johan Marais Monday, April 15, 2013 5:30 AM
    Friday, April 12, 2013 3:55 PM

All replies

  • What does the second tab of the CS object details dialog say about the connector relationship - does it say "transient object" by any chance?  Can you click on the lineage button?


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Thursday, April 11, 2013 11:23 AM
  • UNIFYBob,

    Thanks for the prompt response. on the Connector Space Tabs are the following:

    1. Import - Modification type add

    2. Synchronization Error - Same modification type with error "unexpected-error"

    3. Lineage - Object state is connector, when clicking on the Metaverse Object Properties button, the error is displayed that the MV object doesn't exist

    Regards

    Johan Maras


    JkM6228

    Thursday, April 11, 2013 11:29 AM
  • I expect your own fears that this can't be a valid state for a CS object are correct - this CS object is unlikely to be able to be corrected by any conventional action on your part.  The only thing I can think of is if you have any other MA that can project an object onto the MV on which this CS object can subsequently join?  Does this object show up at all on the joiner tab (search for all disconnectors) in which case this could make an artificial join possible?  I expect there's every chance that nothing else does project, in which case you'll probably have to use a PSS call to get this looked at (because this really does sound like a corruption).  One last thing - what happens when you do a full sync preview on this object?


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Thursday, April 11, 2013 11:40 AM
  • Hi,

    I checked the Joiner and the object doesn't show there, and because the object "thinks" that it is a connected to an object in the MV, it is not going to show in the joiner. And because the MV object doesn't exist, I can't change the state of the object to be disconnector.

    A full sync preview also produces the error "object not found"

    I think it is looking for the FIM connector because the object from the HR connector space as well as AD are both properly joined.

    Thanks

    Johan Marais


    JkM6228

    Thursday, April 11, 2013 11:52 AM
  • The joiner suggestion was really about testing the real underlying state of the CS object :).  Can you try adding a filter for the object and then commit a full sync preview?  My thinking here is that you may be able to force a break between the mystery MV object using a filter, potentially giving FIM a chance to correct itself before you remove the filter again.  I still think this is a corruption that may need a PSS call to resolve.

    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM


    • Edited by UNIFYBobMVP Thursday, April 11, 2013 12:21 PM
    Thursday, April 11, 2013 11:57 AM
  • Hi,

    I have created the filter and it doesn't break the connection when I do a full sync preview.  it seems that it check for a valid MV connector and fails if it doesn't exist. Question:

    If I delete the connectors space for the SQL database, will it provision all the objects back when doing a full sync on FIMMA? Or will I have to remove all EREs and force the MPR again to initiate the provisioning?  Also isn't there some SP in the FIM Sync Service database which checks for these type issues and cleans it up? Grasping at straws here :-). Currently I only have two objects like this.

    Regards

    Johan Marais


    JkM6228

    Thursday, April 11, 2013 12:39 PM
  • Hi,

    Also to add to this, do you think that the "FilterForDisconnection" Method in the rule extension will work any different from specifying it through the GUI? Different in that it will enforce the disconnection regardless of whether the MV object exists or not?

    Regards

    Johan Marais


    JkM6228

    Thursday, April 11, 2013 12:58 PM
  • OK - it's hard to know exactly what to expect without the full picture here, but in the old days with the ILM/MIIS sync server you could always clobber the CS and reload.  These days with EREs etc. you do have additional considerations, but in this case it should be very similar.

    "If I delete the connectors space for the SQL database, will it provision all the objects back when doing a full sync on FIMMA?"

    Yes it would, but I wouldn't do that without reloading the SQL MA and causing rejoins - or don't you have a join criteria that would be satisfied?

    If you clear the CS and you've got provisioning rules on the MV objects for this CS then the existing EREs on the MV objects will cause a new CS object to be provisioned next full sync of any *existing connector*.  But if instead you perform a full sync of the reloaded (via a FI) SQL MA then presuming you have join conditions defined then the joins will happen in lieu of provisioning.  You can see this behaviour at an individual MV object level if you disconnect a single SQL MA CS object - then find it again via a CS search and do a sync preview.  Also, if you were to do a FS on say the FIM MA connector, it would cause a new SQL CS object to be provisioned - but a subsequent full sync on the disconnected SQL CS object would cause the provisioned CS object to be deleted and the join would still occur.  This happens on a FS - but not a DS.

    If you're willing to delete the SQL MA connector space, then that would be a good start - but don't do it without first backing up the FIM and FIM Sync databases so you can recover to this point if you need.

    ** In answer to your "FilterForDisconnection" question above - are you saying you have a mix of declarative logic and rules extensions?  The rules extension logic arguably allows you more control than declarative, but in this case I don't think you're trying to change a business rule but instead fix a data corruption.  This means we only want to perform remedial action without changing the design of the solution - and to implement this method would be to do just that (in which case you do the change in the lab first and then migrate your change to Production).


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM


    • Edited by UNIFYBobMVP Thursday, April 11, 2013 1:10 PM extra question response
    Thursday, April 11, 2013 1:01 PM
  • Hi,

    Maybe I have found a solution for my problem, tell me what you think about it.  (Might also not be supported :-)). But first, I have tried to force a disconnection by making use of a rules extension through the "FilterForDisconnection" mechanism, but if gave the same error that the object doesn't exist.  Also tried to do a delete on the connector space as well, this also failed to remove the three objects which think they have a connector in the MV.  I was almost happy when I saw a prompt that you can ignore the errors and delete the objects anyway - this didn't remove the objects either.

    I then resorted to a more unconventional method - I located the records in question in the mms_connectorspace table and changed the is_connector value from 1 to a 0.  This caused the records to immediately show up in the joiner as normal disconnectors.  But because I have already started to delete the connector space I also removed the three objects in error which are now normal disconnectors.  I don't think this will be desctructive as the MV object doesn't exist anyway.  I am busy doing a full sync on the MA and it seems that it is provisioning all the objects back

    By the way I have the same problem in the lab where I am doing all of this.  I think in production it would not be necessary to delete the connector space, but just change the state of the objects to be normal disconnector.

    Regards

    Johan Marais


    JkM6228

    Friday, April 12, 2013 9:41 AM
  • I've resorted to having to do that myself once - with similar (successful) results - and it was a last resort, and I wasn't going to recommend this here.  You are safe though I think, but this confirms you had a corruption in your CS.  I you are right that you should be able to avoid deleting the CS in Production, but be careful to back up your FIM db.  Also it would be good to find out what caused the problem in the first place.  Also, check the hotfix history to see if there's any mention of an issue like this being resolved.

    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    • Marked as answer by Johan Marais Monday, April 15, 2013 5:30 AM
    Friday, April 12, 2013 3:55 PM
  • Hi,

    The procedure above seems to have solved my issue.  I also applied the procedure to the production environment and didn't had to do a delete on the connector space.  I did however removed the objects which had problems from the database so that they could be removed from the connector space before provisioning them back.  This was more of a cautionary step to ensure that they were removed in case they had other problems.  After this they were provisioned and joined properly with the relevant objects from the MV and other connectors.

    Before I attempted any changes, I made fresh backups of everything

    I am not sure as to where this issue originated from as I have migrated the solution from our dev lab to the production deployment, our lab and production is 100% mirrors of each other. I also had some hardware issues when initializing the environment discussed in this post: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/d2dc0116-3b5b-48aa-8d64-7a29da15fcd4.

    I am running FIM 2010 R2 SP1 on Windows Server 2012, SQL Server 2012 and SharePoint 2013, will check if there were any updates after SP1.

    Thanks for your assistance

    Regards

    Johan Marais


    JkM6228

    Monday, April 15, 2013 5:29 AM
  • A friend of mine, Henry, ran into a similar problem only yesterday, and I directed him to this post.  I said that this will deal with the symptom, but there may be an underlying problem - and it turns out in his case there was.  Here's his (edited) explanation - it may help someone else.

    • I have a FIM Server with multiple connected directories.
    • I have a leading (authoritative) directory from where user objects come. Then they are synced to the portal.
    • Within the portal I have some sync rules added to the object. Then new objects are created in other dirs.
    • If the employeeEndDate is reached the sync Rules are removed and the objects should be deleted in all directories but not in the leading directory.
    • Here I have developed a “shouldProjectToMetaverse” rule. It gets disconnected and not projected again.  Everything is fine so far but ...
    • Whenever the end date is reached and synced to the portal, the rules are removed as expected. I can see Provisioning Disconnects to all directories. My object deletion rules says when an object is removed from AD, the the metaverse object should be deleted. And the deletion option at the FIM MA says “Stage a Delete on the object for the next export run”.
    • When sync runs, I can see some expected deletions for the FIM portal AND I see an Add for a new user object with the same properties of the object that is about to be deleted.
    • At the next Export the object is not deleted and I get an error that an object with this name is already there and the Add operation is not successful.
    • Now I deleted the existing (old) user in FIM portal and the Export runs successfully but at the next import I get this error we talked about earlier.  Of cause there is no existing MV Object anymore in FIM Sync.
    • The reason was I have also checked “Create Resource in FIM” on the MA for the leading system. It seems the disconnection did not work because of the sync rule in the portal. Now I removed the “Create Resource in FIM” option and instead I use the “ShouldProjectToMV” code. Then I remove the Sync rule to the leading system earlier then the last connected systems (AD and portal).

    This is my solution. There are may be better ones?


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Thursday, April 18, 2013 1:23 AM
  • Hi,

    I have almost the exact same scenario as your friend.  My leading system is the HR system which controls everything that happens to a user object. I also have this MA create a resource in the FIM portal for obvious reasons.  The only other thing that I have configured on this system is to leave the attributes in the MV when a user leaves the company. (I only receive active employees).  This is to ensure that the user object from the FIM Portal and the AD remains connected until the object is removed from the AD, about 90 days after an exit, which then kicks of a chain reaction to remove the user from all connected directories. (MV deletion rule also specify that if the AD connector becomes disconnected, the rest should also be deprovisioned)

    In 99% of cases this works fine.  But in a few cases the AD object gets deleted before the other directories get disconnected, this then results in the MV object been deleted and the other directories have the problem as in this thread.

    I have tested this in my lab. If I disconnect the AD connector before the other connected directories, they still think they are connected to a MV object which doesn't exist anymore.  I think this is because the deprovisioning should happen from the FIM Portal, but by interfering with this process from the other end will result in this problem.  Fortunately the fix as explained above works just fine - but I don't think it will be supported. So far I didn't pick up any problems as a result of the fix, had to do it a couple of times in my lab :-). Busy with the tedious job in the lab to try and isolate the cause of this, my lab is 100% mirror of production with the same amount of users and MAs - this takes a long time.

    In my mind this might be a bug or problem with the sync engine, it should either not allow you to disconnect the MA controlling the deletion of objects while other are still connected, or just do a disconnect on all connectors.

    Thanks for the feedback and assistance.

    Regards

    Johan Marais


    JkM6228

    Thursday, April 18, 2013 5:49 PM
  • I raised this with Andreas from Microsoft a few hours ago and he agreed it sounded like a bug, and also asked that you raise a PSS support call so that they can get to take a look at it.  Can you do this?

    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Thursday, April 18, 2013 5:54 PM
  • Hi,

    Yes, I will but only first week in May.  I am out of the office from tomorrow until end of month.

    Thanks

    Johan Marais


    JkM6228

    Thursday, April 18, 2013 5:59 PM