5 Replies Latest reply: Mar 1, 2013 3:28 PM by BikashBagaria RSS

    Exchange Connector - scheduled task running time


      Does anyone have any experience with long running time when you run the scheduled task for "Exchange Target Resource User Reconsiliation" for the first time (Full reconsiliation)
      It's been running for about an hour now, and I'm not sure whether this is wrong or not. In the event log I get a bunch of these:
      oracle.iam.connectors.icfcommon.recon.ReconEvent : putSingleField : Attribute [Message Body Format*] not found in Connector Object.

      *This one varies, ex. [Use Prefer Message Format]

      Any tips will be appriciated :)
        • 1. Re: Exchange Connector - scheduled task running time
          What version of the connector and what version of OIM? I have seen issues with the ICF connector and the way it does recon. Few bugs:

          1. 14757197 -> This is to solve the issue where the Get-DistributionGroup is fired at the connector for all users even though we had removed the configuration in OIM to bring the distribution groups of the user. In our environment it was take more then 2 minutes to get a user's distribution group.

          2. 14759585 -> The base connector does not have any search parameter for OU in the schedule job, thus the way it works is that it picks up all the user's from the base defined in the IT resource and then iterates through each of them to match the filter criteria in the schedule job and creates events if the filter matches. What it means thus is that all users are loaded into the connector server memory first and then they are checked for recon rule. This impacts the performance in negative way. One way to workaround it is to have the search base in IT resource limited to a specific ou, but if you have multiple OUs and a AD forest with multiple domains then you will have to create multiple IT resources and that might impact your access policy design (if any). Thus we had this bug fixed where the schedule job would have additional parameter of the OU from where we want to get the users from. If you have very high number of users, it might even crash your connector server. This bug also fixes the issue where the filter is now supported for the exchange attributes (not all though) in the schedule task. Thus you can put a filter to reconcile (or basically query) only for human mailboxes.

          3. 14786992 -> This issue was got the mailbox database. The way base connector works is to fire the command Get-MailboxDatabase for each user without any -Identity option. What it means is that this command brings in
          all the databases in the system and returns the very last in the list as that of the user. Two impacts here, performance if the number of databases are huge (80 in our case) and second is wrong data in OIM. Even though the user has mail data in datastore 'A' OIM would show that the datastore is 'Z'.

          Can't recall more now but poke around metalink and you should find one or two more which we opened.


          Edited by: Bikash Bagaria on Feb 28, 2013 8:00 PM
          • 2. Re: Exchange Connector - scheduled task running time
            Thank you :)

            I will go through this list, and check.

            By the way:

            OIM 11G R2 (
            Connector: Exchange-
            • 3. Re: Exchange Connector - scheduled task running time
              We had these issues in R1 and ICF but I think you would still see the same issue in R2 as it's the exchange dll which has these issues.

              • 4. Re: Exchange Connector - scheduled task running time
                Applied patches, and it fixed not only this error, but another one too (the one with getting wrong mail database for user)
                Thank you very much for your quick (and correct) help! :)
                • 5. Re: Exchange Connector - scheduled task running time
                  As as you are working on ICF connector, test thoroughly for AD delete recon (there is issue with that) and the following scenarios:
                  1. Disable UserMailbox from OIM -> Check for the MaxOutgoingSize and MaxIncomingSize in exchange for the user and compare it with process form fields.
                  2. Convert a UserMailbox to a MailUser or vice versa in Exchange and then do a target recon -> Verify all the fields in the process form.

                  There are bugs around these scenarios as well. (Don't wanna bad mouth about ICF but once in production you don't wanna see these bugs)