Ideas
Identity Broker for MIM watermark functioanlity enhancement
After a recent production incident where MIM kept presenting the same watermark to IDB (5.1) on delta imports there may be an opportunity for Identity Broker to handle the watermark storage in a better way that works around this MIM issue.
From talking the Curtis he mentioned that this issue has been seen with other clients, and the only workaround is to either re-create the MA or run a full import which in large environments may not be practical. Acknowledge that this is 100% a MIM issue, but could be a plus for the IDB if it can provide a workaround to such an issue that can have a big impact on large environments.
There are a few options that I could see:
- store the watermark in the MaData directory for the MA and use that instead
- store the watermark in the MaData directory for the MA and build some smarts around that watermark in combination with the MIM provided watermark.
It could be possible done by providing an option in the ECMA2 MA to enable/disable such enhanced functionality.
Answer
I have left the company, I still get his emails, brian
Thanks Andrew.
Could you let us know as soon as the issue reoccurs and you have the logs from the patch provided by Curtis?
Also, has this been raised to MS support?
This issue is now occurring on a regular basis and is interfering with the production environment. Whilst investigation is undertaken and this is raised with Microsoft can an alternate method of watermarking be developed for the IDB MA.
We are currently in a scenario where even after a full import the 2nd and subsequent following delta imports return staging errors.
I've attempted to recover logging, however as the MA is now timing out and returning no errors there is not watermark log file being generated.
Richard has also found that the same issue is occurring at DETE recently.
Hi Adam,
Yet to re-occur thankfully and hasn't been raised with Microsoft. It appears to be one of those very rare issues with a high impact.
Attached are the logs from Curtis' patch whilst the issue was still occuring and after. The entries up to 12/14/2016 2:16:21 AM: were prior to the full import being run which corrected the issue. Log entries from 12/14/2016 4:01:07 AM were the completion of the full import and subsequent MA runs (note: there are 3 IDB based MAs that will all be writing to this log)
Thanks - Andrew.
Having this issue occur on a semi-regular basis now, appears to be exhibiting the same symptoms of the previous occurrences where the old changes are being replayed back to MIM until there are so many that the import continually fails.
We are now running full imports twice a week however the issue still occurs, are you able to provide some further information so that the issue can be raised with Microsoft.
Hi Andrew,
Unfortunately there isn't a whole lot of information we can provide, and we have never found a way to consistently reproduce the problem. The symptom in the agent is only that FIM is not correctly keeping track of the CustomData property of the OpenImportConnectionRunStep, GetImportEntriesRunStep and CloseImportConnectionRunStep objects and the OpenImportConnectionResults, GetImportEntriesResults and CloseImportConnectionResults objects in the various IMAExtensible2CallImport methods. We've witnessed passing it one value and then later being given an old value or sometimes no value at all.
Customer support service by UserEcho
Moved to new issue.