none
Orphaned ExpectedRuleEntry RRS feed

  • Question

  • Hi,

    We have ended up with a huge number of EREs in the test environment.  Only discovered these when we were re-initialized the envrionment after deleteing all connectors spaces.  The FIMMA synced about 120k objects taking about day and half and we have only 30k users.  I have found the PowerShell scripts to remove the EREs, but this is taking just as long, I have in the order of 70K orphaned EREs.  So far the script is running for about 8 hours and it is only halfway through.

    I am working on FIM 2010 R2 RC in test environment.  Is there a quicker way of removing these orphaned EREs?

    Also noticed that there was a stored procedure with name deleteorphanedobjectsbytype, but this is abscent in FIM 2010 R2, or has it be renamed to something else? And will this be faster in removing the EREs

    Thanks

    Johan Marais

    

    JkM6228

    Thursday, May 31, 2012 9:27 AM

Answers

  • Hello Johan ;)

    Orphan ERE's are a problem and the removal of them is slow and time consuming. The best way is the use the service to removed them and the scripts that Carol published is the way to go. Any yes, that will be slow. (I learned this lesson the exact same way).

    The best way to get around this is to keep the database state as a record for rollback. A FIM Service DB restore is by far the quickest way to not run into this scenario while 'playing' in the lab. Refer to the article by Marcus on how to use Powershell to automate this scenario.

    http://social.technet.microsoft.com/wiki/contents/articles/2089.how-to-use-powershell-to-manage-multiple-fim-scenarios-on-a-lab-computer-en-us.aspx

    As far as your lab goes - either give it the weekend, or export the config and do a fresh install.

    Almero


    Almero Steyn (http://www.puttyq.com) [If a post helps to resolve your issue, please click the "Mark as Answer" of that post or "Helpful" button of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

    • Marked as answer by Johan Marais Thursday, May 31, 2012 10:36 AM
    Thursday, May 31, 2012 10:00 AM

All replies

  • Hello Johan ;)

    Orphan ERE's are a problem and the removal of them is slow and time consuming. The best way is the use the service to removed them and the scripts that Carol published is the way to go. Any yes, that will be slow. (I learned this lesson the exact same way).

    The best way to get around this is to keep the database state as a record for rollback. A FIM Service DB restore is by far the quickest way to not run into this scenario while 'playing' in the lab. Refer to the article by Marcus on how to use Powershell to automate this scenario.

    http://social.technet.microsoft.com/wiki/contents/articles/2089.how-to-use-powershell-to-manage-multiple-fim-scenarios-on-a-lab-computer-en-us.aspx

    As far as your lab goes - either give it the weekend, or export the config and do a fresh install.

    Almero


    Almero Steyn (http://www.puttyq.com) [If a post helps to resolve your issue, please click the "Mark as Answer" of that post or "Helpful" button of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

    • Marked as answer by Johan Marais Thursday, May 31, 2012 10:36 AM
    Thursday, May 31, 2012 10:00 AM
  • ALmero,

    Thanks for the reply.  It is difficult to keep the database backedup while constantly developing the solution. 

    Regards

    Johan Marais


    JkM6228

    Thursday, May 31, 2012 10:36 AM
  • The recommended way to get rid of orphaned ERE and DRE is using a stored procedure as outlined in KB 2520954.
    See Issue 4 under Fixed in FIM Service.

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

    Thursday, May 31, 2012 12:01 PM
  • Markus,

    Thanks for the reply.  I was looking for this but could'nt find it.  I am using FIM 2010 R2 RC.  Not sure if it has a different name in this version, or if it should be available.  Do you know if it should be there under different name maybe?

    Regards

    Johan Marais


    JkM6228

    Thursday, May 31, 2012 12:06 PM
  • The stored procedure is missing from FIM 2010 R2 RTM as well. Could anyone post the code for the SP or a powershell script.

    I have found the Powershell script for deleting all ERE and DRE, but I am drawing a blank as how the limit it to only Orphaned entries.

    Regards Thomas Steen Christensen

    Tuesday, August 14, 2012 1:32 PM
  • Can confirm that this feature is definitely not in FIM R2 SP1

    I threw a bit of detail on my site about it, along with a link to a helpful solution by UnifyBob.

    - Ross Currie


    FIMSpecialist.com | MCTS: FIM 2010 | Now Offering ECMA1->ECMA2 Upgrade Services

    Wednesday, March 20, 2013 11:16 PM
  • I have found this in a production environment that I am upgrading to a new fim 2010 r2 platform. In order to move the database (which is huge) into the new cluster for the upgrade I am in the process of using the powershell script to remove around 170,000 Orphaned ERE's from the portal that are still attached to a sync rule that no longer exists. The sync rule is still attached to users as not applied, pending.

    My query is , when the script is finished, do I run a full import / sync / export on the FIM MA to bring back everything to a resolved state ?

    At the moment I have all sync runs off until the process completed, after 15 hours it is at 75%. So yea, slow.


    Rob

    Thursday, December 19, 2013 9:18 AM
  • Rob,

    Answer is yes, it will also remove the orphaned EREs from the MV.  What I have done is to create a MPR which will remove EREs from objects if it is no longer needed.  The down side of this is that you end up with twice the number of MPRs but I think it is better this way. 

    We also have a routine task on weekly basis to remove orphaned EREs which is not handled by the above process.

    Regards

    Johan


    JkM6228

    Thursday, December 19, 2013 10:06 AM
  • Cheers Johan.

    Yea, I am going to use an MPR to remove the other old sync rule. The problem with the Orphans is that they refer to a Sync rule that was deleted so the resource parent is not present. So for this one, I am using the powershell script referenced.

    For the other problem I am going to use the MPR to remove them from the Sync rule, and enable the "policy update" flag.

    Its very strange that this happened, there is no history on this as I am just taking over.

    Rob


    Rob

    Thursday, December 19, 2013 11:57 AM
  • Rob,

    In my experience I have found that the EREs are not automatically removed when a user object is deleted as part of deprovisioning, they then become orphaned EREs.  In a large environment these might accumulate very quickly to what you have seen. The ideal would have been that if a user object is deleted from the portal that all EREs and DREs on that object is also deleted.

    We also do deprovisioning, but  I ensure that all not required EREs are removed before we delete a user object.  In other words, for every MPR that add a SR I have, I also have a MPR which removes the SR when a user moves out of Set which resulted in a SR been added to a user object. obviously there are exceptions.

    As I said earlier we have a routine task to manage these so that it doesn't grow to large, as this also have an impact on the performance of the portal. In a week's time we see typically 20 -30 orphaned EREs. Our FIM database has about 900k objects

    Regards

    Johan


    JkM6228

    Thursday, December 19, 2013 12:15 PM