none
FIM Password Synchronization Not Catching All Password Changes RRS feed

  • Question

  • I have a FIM 2012 R2 environment and I'm about to start synchronizing password changes from AD into our legacy systems.  I have PCNS installed on my DCs and the AD MA in FIM configured as a password sync source.

    Everything works - just not all of the time.

    I've enabled PCNS verbose logging on the DCs.  I'm getting "The password notification has been delivered to all targets - (Event ID 2100)" success messages for all password changes but the FIM sync engine ony appears to be acting on ~25% of the incoming changes.

    I had thought it was my password extension code that may have been having issues but I stripped it down to simply dropping an event into an event log and it's still dropping 75% of the changes.

    Has anyone else seen this behaviour before? 

    Is there any way to correlate PCNS events with some form of log in FIM?  I can't seem to find anything in the event log that's tied to password changes.

    Cheers,

        Ian

    Friday, November 21, 2014 7:01 PM

Answers

  • Looks like I managed to solve this one myself (it's alot easier once you manage to get logging to work correctly (doh!)).

    The problem lies in the way we're currently provisioning AD accounts (out of band through a scripted process).  This means that accounts show up in AD before FIM knows that they exist - FIM isn't having a problem finding the user in the password target connector space, it's having a problem finding them in the password source connector space.

    The 25% that are succeeding are the individuals who have already been recognized by FIM in both the source and target connector spaces.

    • Marked as answer by Ian Thomas 215 Friday, November 21, 2014 9:22 PM
    Friday, November 21, 2014 9:22 PM

All replies

  • Ok, progress.  I managed to get verbose logging working on the FIM Sync engine and I am now able to see why some of the change events are not being acted upon:

    Event ID 6904 - A password notification was received but could not be processed because a corresponding connector space object could not be located.

    What's interesting is that the related metaverse object lists connections to both the password sync source and the password sync target MAs.

    Friday, November 21, 2014 8:42 PM
  • Looks like I managed to solve this one myself (it's alot easier once you manage to get logging to work correctly (doh!)).

    The problem lies in the way we're currently provisioning AD accounts (out of band through a scripted process).  This means that accounts show up in AD before FIM knows that they exist - FIM isn't having a problem finding the user in the password target connector space, it's having a problem finding them in the password source connector space.

    The 25% that are succeeding are the individuals who have already been recognized by FIM in both the source and target connector spaces.

    • Marked as answer by Ian Thomas 215 Friday, November 21, 2014 9:22 PM
    Friday, November 21, 2014 9:22 PM