Hello,

I'm relatively new to FIM and because of a new job back at doing MS servers again.
FIM is part of a MS Lync 2013 installation for one special customer.

Customer manages his AD himself, puts Accounts into a special security group, if Lync should be activated.

Lync is installed in own forest, with trust to customer forest.

FIM creates contacts in resource AD for customer's real accounts. Powershell script updates contacts into forest's lync-group.
Just FIM sync is used, every 30 minutes, with 4 profiles and lcssync.dll used for deprovisioning.

From time to time FIM "sees" delete of e.g. customer\user1234, in my resource forest this contact loses all its attributes, hence the group.
It was removed from Lync but Lync-enable script will try to enable "him" again and runs into error:

-ERROR- enabling   () for Lync
CN=user1234,OU=CUSTOMER,DC=blabla,DC=net
Cannot bind argument to parameter 'Identity' because it is null.

Some time later, I check in customer's AD for account customer\user1234 and it's not deleted nor disabled and "it" has all attributes.
In FIM this connector is placed into "explicit disconnectors" of CUSTOMER AD.
Here I'll do a fix of the problem.

But what's the reason for FIM to see a delete of customer\user1234?
Is there anyway to tell?

Thanks for your advise!

Bye,

Jens

• Edited by Jens Hoffmann (Administrator) Thursday, June 11, 2015 1:41 PM changed some words

Hello Nosh,

thanks for your reply.

That's not "my" problem, we export imported contacts into one special OU,
but we fetch all accounts from top to bottom of CUSTOMER's forest.

Later yesterday I found somthing; at 11:33 FIM did delta-import from CUSTOMER AD, logfile was generated and there was one change to one account:

<attr name="userAccountControl" operation="replace" type="integer" multivalued="false">
  <value>0x200</value>
 </attr>

and after that this account lost its attibutes in my resource forest and wasn't enabled in Lync.
Other script put contact again in group for enabling and this resulted in "identity is null" problem.

I talked to an admin from CUSTOMER, at 11:29 this account got changed and resulted in state  "password expired". This was't done by CUSTOMER's password policy.

How can I find the reference to this attribute in FIM?

• Edited by Jens Hoffmann (Administrator) 20 hours 46 minutes ago typo

The attribute in AD is called accountExpires .  You may not have anything in FIM that gets mapped from or to this attribute.  This is something custom, in case you did so, but it is not a common attribute people import into FIM.

If you want to find out, just check attribute mapping for the AD Ma and see if anything is mapped to accountExpires.  it will have to be an advanced flow rule as the format of accountExpires is not a date format.

userAccountControl represents the user account status, and it is different from accountExpires.  Same idea goes here. See what logic is in place mapped to this attribute.

The fact that the user lost the attributes is because this account was disabled (value 0x200 means disabled). So when user gets disabled in AD, certain attributes are nullified. This user will not need lync nor can she use it, so I don't see the issue here.

Hello Nosh,

thanks for your reply.

That's not "my" problem, we export imported contacts into one special OU,
but we fetch all accounts from top to bottom of CUSTOMER's forest.

Later yesterday I found somthing; at 11:33 FIM did delta-import from CUSTOMER AD, logfile was generated and there was one change to one account:

<attr name="userAccountControl" operation="replace" type="integer" multivalued="false">
  <value>0x200</value>
 </attr>

and after that this account lost its attibutes in my resource forest and wasn't enabled in Lync.
Other script put contact again in group for enabling and this resulted in "identity is null" problem.

I talked to an admin from CUSTOMER, at 11:29 this account got changed and resulted in state  "password expired". This was't done by CUSTOMER's password policy.

How can I find the reference to this attribute in FIM?

• Edited by Jens Hoffmann (Administrator) Friday, June 12, 2015 10:38 AM typo