IM generating log on a loop when can't find an AD account

[LFMartins]

Hello Community,

We are using Account Templates to create the users AD accounts. Sometimes, the customer needs to move those AD accounts from one OU to another, and they do it manually on the AD itself. I know that this is not recommended, but they are a call center operation and it is necessary for their daily operations.  

The actual problem that we are facing happens after that manual account move, when the account owner tries to do something like a password reset on that account. IM tries but can't find the user AD account and instead of giving up it keeps looking for the user's account, generating a lot of log which sometimes fill the entire disk and compromises the application functionalities. 

Does anyone know if it is possible to change the IM behavior and force the task to fail, after some time past or after trying to find the account just for a couple of times, before generating so many log entries?  

Thanks in advance!



------------------------------
Luiz Felipe Martins
Software Consultant
Gliat Digital Intelligence
------------------------------

[Vincent Parziale]

Hello Luiz,

The use case you are performing is the root cause of your issue here. There is no way to force IM to fail because of your practices and would only be a cosmetic bandage if anything. The best way to fix your issue is to fix your procedure for moving AD accounts not by forcing IM to fail but by moving AD accounts through either the IAM UI and or Provisioning Manager. This is where you should be moving accounts from not AD directly.

IMPS Source:
http://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/identity-management-and-governance-connectors/1-0/connectors/microsoft-connectors/microsoft-active-directory-microsoft-exchange-and-microsoft-lync/managing-active-directory-accounts-and-groups-with-the-provisioning-manager/moving-accounts-with-provisioning-manager.html

IM:
Users > Manage Users > Modify User's Endpoint Account > Find Desired User > Search for endpoint account > "Move AD Account"

The outcome of your procedure has and is causing massive user corruption and breaking known inclusions between IM / IMPS / Endpoint and is HIGHLY ill-advised. This is the root cause of your logs entries growing. I would recommend that you cease your current practices and adopt a proper one that allows IM / IMPS to obtain the knowledge of where these accounts are being moved to.

Thanks,
Vinny

[LFMartins]

Hello Vincent,

Like I said, I already know that the procedure that was done is not recommended, that it was the root cause of the problem and that there is another proper way to do it, but it was an emergency situation. Not only me, but the customer is also aware of all of this. 

Moving the AD account manually was the root of the problem, but the problem itself only happened because IM handled that root cause by generating enough repeated log on that problem alone to fill the entire server disk, causing tasks to stuck "in progress" and impacting the production environment. The customer enquired if this behavior is a bug on the application or a configuration problem. So, is there some configuration that I can change that enables IM to handle the same type of problem without filling the entire disk with GBs of log files? The log level is already on its lowest and even if it weren't that would only get me some time before the log would fill the entire disc. 
 
Thanks,

[Joffrey Lemoigne]

Hi,

which version and cp are you using? Sorry if you already mentioned that previously. I had to work on a similar issue last week when some cleanup were made directly on the endpoint generating a loop when the ps tried to access one of the cleaned up entries. This should occur only if you are at the latest cp like 14.1 cp10 or 14.2 cp5 or 14.3 cplatest.

thanks

[LFMartins]

Hi Joffrey,

Sorry about the late reply. We are currently on 14.2 cp5. We have updated to CP5 less than a month ago.

Regards,

[Rinat Matityahu]

Hi Luiz

Please raise a new Support ticket for this use case. Along with the description already provided, please add the link to this community thread and mention DE446243 needs to be provided in order resolve this loop.
We would have raised such a case on your behalf but unfortunately have no way of identifying the siteID in question.

Regards
Rinat Matityahu
Principal Support Engineer
Broadcom Technical Support - EMEA

[LFMartins]

Hi Rinat,

We had a ticket on this subject, number 20304786, but it was closed. We raised a new one, number 20306860. 

Thanks for the help!