Sign in
Microsoft.com
 
Resources for IT Professionals
 
 
 
Resources for IT Professionals > Forums Home > Identity Management Forums > Identity Lifecycle Manager > DeprovisionAll() doesn't call deprovision methods on all connectors?
Ask a questionAsk a question
Search Forums:
 

General DiscussionDeprovisionAll() doesn't call deprovision methods on all connectors?

  • Monday, November 02, 2009 7:29 PMcove Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Has Code
    Sign In to Vote
    0
    Sign In to Vote
    Hi folks,

    During an account rename I need to disconnect all of the CSentrys connected to an MVentry so that the join rules can be reevaluated and re-join correctly. However when I call DeprovisionAll() (i.e. mventry.ConnectedMAs.DeprovisionAll()), one of the MAs that uses references does not get disconnected. The deprovision rule for that MA is "Stage a delete on the object for the next export run".

    Any ideas?

    Thanks,

    cs
     

All Replies

  • Monday, November 02, 2009 7:57 PMMarkus VilcinskasMSFT, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote
    Could you please post the code sequence you are using to deprovision all conncectors?

    Cheers,
    Markus
    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
     
  • Monday, November 02, 2009 8:02 PMcove Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Has Code
    Sign In to Vote
    0
    Sign In to Vote
    There isn't much to it, in the MV rule extensions I just check that the login names are the same between all of the MAs, if not I set a flag (doRename), and then call DeprovisionAll() on the mventry:
                                if (doRename) {
                                mismatched = mismatched.TrimEnd(',');
                                Log.Info("Rename logic triggered due to mismatched logins from MAs: " + mismatched);
                                Log.Debug("Calling DeprovisionAll() for this entry.");
                                mventry.ConnectedMAs.DeprovisionAll();
                            }
     
  • Monday, November 02, 2009 10:13 PMPaul LoonenMVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote
    What do you see in preview? Does this happen in every situation? Any errors that show in the preview but that are maybe not logged in the console?
    Paul Loonen (Avanade)
     
  • Monday, November 02, 2009 10:19 PMMarkus VilcinskasMSFT, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote
    What did you do to verify this?
    For example, what does the synchronization stats say?

    Are you sure that the code sequence was really processed on the object in question?
    Basically, you are right, all CS objects should be disconnected and the MV object should be deleted.
    If this doesn't happen, it can only be a simple thing.
    Is there a chance that you are reprovisioning something?
    It might be a good idea to post the entire provisioning method...

    Cheers,
    Markus
    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
     
  • Tuesday, November 03, 2009 6:17 PMAhmad Abdel-wahedMSFT, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote
    As always, Markus, I think you are right on the point.  The reprovisioning of recently disconnected items would net out so that it looked like no disconnection was attempted.

    Cove, can you please answer the questions Markus asked so we can confirm that's what's happening?  Thanks!
    AhmadAW
     
  • Tuesday, November 03, 2009 8:29 PMcove Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    Sorry for the delayed response, a number of things came up at the same time...

    I tried to nail down the exact sequence in dev of what I saw in my prod environment, but have been unsuccessful at reproducing the issue.

    What did you do to verify this?
    Are you sure that the code sequence was really processed on the object in question?
    I verified this by looking at the MV entry for the accounts that were affected before and after the MAs were run; before the MA sequence was run, the MV entries were connected to the wrong MAs (as expected), after the run sequence, all but one of the MAs connected to the MV entries were correct. So for the rules to be reevaluated at all the DeprovisionAll() must have been called. I'm not sure how the remaining MA could have been disconnected and then re-joined to the wrong object again though.

    For example, what does the synchronization stats say?
    These seem to have gone missing, probably due to an issue where ClearRuns() sometimes deletes all of the logs, I believe this is happens when an MA is running at the same time the WMI call is made.

    Is there a chance that you are reprovisioning something?
    This is quite likely, as that I believe the processing order is undefined right? So if a deprovision on a object is called, a provision could be called later and the ultimate order is undefined, right? There isn't any MV extension logic to prevent that in this case at least.

    It might be a good idea to post the entire provisioning method...
    I would, but it's complicated to get approval, I'd have to go through PSS. Is this something you would be interested in reviewing to help verify?

    Thanks,

    Cove

     

     

     
  • Tuesday, November 03, 2009 10:33 PMMarkus VilcinskasMSFT, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote
    Cove,

    as an alternative to the provisioning code, a CSExport of the remaining connector could give you the answer, too.
    It doesn't have to be true in your case; however, I have seen something like this before - you never know...

    Cheers,
    Markus
    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
     
  • Tuesday, November 03, 2009 11:06 PMcove Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote
    Ok. Thanks. I'll have to wait for the next rename to happen and see what it looks like in production. Just to claifiy, you think it was probablly because after the DisconnectAll() a provision happened and nullified the dissconnect?

    Thanks,

    Cove
     
  • Wednesday, November 04, 2009 1:57 AMMarkus VilcinskasMSFT, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    Not probably because but it is possible that :o)
    So, it might be the case - I have seen something like this before.

    In one case, the programmer made a logical mistake and didn't realize that his code has reprovisioned an object that was disconnected in the same code sequence.
    This happens if someone tries to squeeze the entire provisioning logic into one procedure.

    My advice in conjunction with this is to only do the connector evaluation in the provision procedure and to do all "complex" calculations in sub procedures.
    Otherwise, a provision procedure can become quickly unreadable...
     
    Cheers,
    Markus  

    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
     
  • Monday, November 09, 2009 5:22 PMLK10 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Has Code
    Sign In to Vote
    0
    Sign In to Vote
    Try this:

    if (Connectors == 1)
{
   string[] connMa = new string[mventry.ConnectedMAs.Count]; 
   int i = 0;
   foreach (ManagementAgent ma in mventry.ConnectedMAs)
   {
      connMa[i] = ma.Name;
      i++;
   }
   foreach (string ma in connMa)
   {
      if (!(ma == null))
      {
         mventry.ConnectedMAs[ma].Connectors.DeprovisionAll();
       }
    }
}
    Regards.
    Luka