0
Declined

The dimage indicates an add attrib operation, but the attrib already exists on the object.

Amol Patil 6 years ago updated by Adam van Vliet 6 years ago 16
Topic collaborators

Identity Broker is occasionally throwing “staging-error” as part of the Delta Import. 

Please see the attached files with error logs. 

Could you please review and advice?

Version Details:

Identity Broker: v5.1.0 Revision # 2
FIM 2010 R2: 4.1.3508.0

Answer

Answer

Adam/Richard/Aneesh, please replicate this (it shouldn't need the same systems). The information should be in Aneesh's comments, it's just that the analysis hasn't been done to show why it's a problem. A replication might help us track down the sequence of events that lead to the problem.

Under review

Hi Amol,

Are you able to provide any more information? I can see from the error logs that there are a number of added attributes in the import - can you identify which attribute/s already exist in the connector-space that is causing the issue? Are you able to determine if this attribute was actually added in Dynamics CRM since the last import, did it change at all, or should it be unchanged? How long have you been experiencing this error? What is the frequency with which the error occurs?

Hi Curtis, 

We have got following details. I will gather and provide you the remaining details.

Issue:

FIM Sync services generates staging error on the Dynamics CRM Users MA. The delta import is not working properly, causing for the system to fail.

Impact:
•Any changes made to CRM contact record will not flow to FIM, unless the Full import for the Dynamic CRM User MA is triggered which clears the staging error.
•Security Team mostly updates and add contact records in CRM and changes has to reflect to FIM.

Cause:
Likely a timing issue

Current Event Broker Framework:

Dynamic CRM Full Import is scheduled to run on a daily basis

Work Around:
Manually running the Full import and Sync will clear up the staging error

PS Query: We are looking at separating the Delta Import and Delta Sync on Dynamics CRM User MA while the root cause is being investigated. The approach we are looking at is if the import fails, it also stops the sync. Could you comment on this on the interim? 

Staging Error Occurrences:
1.12th January 
2.23 January
3.26th January
4.27th January
5.29th January
6.5th February 
7.9th February

Hi Amol,

Were you able to get the further details?

Hi Curtis,

can you identify which attribute/s already exist in the connector-space that is causing the issue?

It appears to be what was mentioned on the error logs I attached

Are these attributes was actually added in Dynamics CRM since the last import? did it change at all, or should it be unchanged?

I am not sure, it never made it to FIIM and got stuck. On a note, the  above record was  a newly created contact record which should have flowed smoothly to FIM.

On a note, the  above record was  a newly created contact record which should have flowed smoothly to FIM.

This can't be a newly created contact record, the FIM error reports it as an update and the mere fact that it has an existing object means it must already exist in FIM.

This error indicates there is a misunderstanding between Identity Broker and FIM as to the current state of the entity. The next time the issue occurs, before running a Full Import to resolve, could you please check the connector space to check on the existing state of the entity in FIM? Without a full comparison of the entity in IDB, FIM, the error and some understanding of what you believe has actually changed in the entity, there's not much that can be done to determine the cause of the breakdown here.

Is there an update Amol?

There is no update yet as the customer has not faced similar problem since last reported. I'll chase them if they can reproduce the problem in their test environment.

Declined

Thanks, please let us know if there's any new information.

Hi Adam,

I reviewed those screenshots/logs with Amol and here is our findings/interpretations:

  1. On the 19th of Jan 2018, the HR Team deleted the "MobileNumber" from an employee/record (CN=22573) in the CRM Source System
  2. On the 14th of March 2018  the Administrator restored the "MobileNumber" of the above-mentioned record in CRM (Source System) with same value/mobile number
  3. The Identity Broker(IdB) for Dynamics CRM Connector imported the change (MobileNumber) to IdB
  4. However, the Delta Import on Dynamics CRM MA failed with Staging-Error (CN=22573). Please see the screenshot "Sync_Service_Staging_error details" for more details. 

Please let us know what extra information you need to troubleshoot this issue. 

Cheers

Aneesh

Fantastic, thanks for that.

So that explains why it's happening, but not why it's a problem? Why are delta operations performed so infrequently? And full imports not being used to correct the state? Also, it seems (in earlier examples) that the full import corrects the state - which is what it's intended to do - i.e. working as intended.

Hi Adam, 

As far as I know, Delta Imports are configured to run every 10 seconds (if change detects in IdB). Amol, can confirm this with the customer. Full Imports are also configured to run every two hours. Again, Amol can you confirm the frequency of both run profiles (Full Import & delta Import on CRM Users MA)? 

That doesn't line up with how infrequent you said in your previous comment. If it's this frequent and it corrects itself, what's the impact?

Simply because the customer want to know why it is happening with the Identity Broker Connector/Delta Import? All other MA's they have handles Delta Imports just fine. 

Answer

Adam/Richard/Aneesh, please replicate this (it shouldn't need the same systems). The information should be in Aneesh's comments, it's just that the analysis hasn't been done to show why it's a problem. A replication might help us track down the sequence of events that lead to the problem.

Adam/Richard/Aneesh, has this been replicated?

Hi Adam, 

I don't have any capacity to reproduce this issue. I suggest someone from the Product or Support team to replicate this issue. 

Cheers

Aneesh