This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

scheduling full sync by DSA

Hello,

the goal is to start a full sync by DSA for example every 2 hours. Best way will be to create a windows schedule job. Is there an powershell cmdlet or any command to start a Re-Syn (full sync)?

MMEX 8.14 is in use without MMAD licenses.

Thanks,

Soheil

  • There is no reason to do this. Why do you think you need to do this?
  • Hello Jeff,

    to answer your question I have to describe the whole configuration. This will take time. I did understand the problem after creating of a support case by quest. The answer was:

    'populating of Mail Attribute is up to FIM and you have 2 options - create target object for matching before you move source object to the sync or change source mail-related attribute once object in target has been prepared.'

    Both options are not easy to implement. A scheduled Re-Sync is the best way in our case, I believe.
  • Please explain it all, AND give me the SR number and I will review your case.

    Again, I don't think a resync is the right way to address anything. There are other reasons this is a bad idea.
  • Sure, thanks.
    SR Number:4200999| - Why DirSync does not match new objects in source with same object in target by a deltasync

    What you should first know:
    If extensionattribute 8 (EA8) is set to '1' for an AD-Object in source, two hours later Microsoft FIM will create an E-Mail-User for it in target environment. DSA is not configured to create new objects in target AD. But EA8 = '1' is used as a filter for DSA. If EA8 is set to '1' by a source admin, DSA will create for this object a linked or a shared mailbox in target exchange organization, depending of enabled or disabled source user object.

    For Mailbox collection we also use EA13 as filter. EA13 = '1' for a source object means: start sync and '2' means: auto switch the mailbox.
    So we have two Mailbox collection and a source admin decide which time she/he will set EA8 to '1' and EA13 to '1' or to '2'.
  • Question, EA8 is being written to existing objects or newly created objects? I assume existing objects?
  • EA8 being written only to objects in target, which did exist as we did start the migration and during the migration, if new objects were created in source. EA8 is just a trigger for FIM and for DSA. Our job is only to migrate mailboxes from source to target not user object. But for linked mailboxes we have to create disabled user objects, which is done by FIM.
  • I think you meant "EA8 being written only to objects in Source"

    Why DirSync does not match new objects in source with same object in target by a deltasync.

    This is because in Delta Sync, the DSA is only seeing objects in the source that have changed from the last full or delta sync pass (USN Higher then last seen). Changing EA8 on an existing object will add it to the sync scope (LDAP Query) and EA8 will be an attribute that needs to be written. So this would actually trigger the matching of the object to the source (I.E. EA8 will be written and the service attributes will be written).

    Your problem is deeper. You want the object to be matched AND mailbox to be created. To trigger the mailbox provision sub task (MBRedir), an attribute MBRedir handles need to be updated. The proxyAddresses is an example. Change the proxyAddresses attribute and that will trigger what you are looking for in delta.
  • So looking at your timing, the first time a newly stamped EA8 Object moves into the scope of the sync, there is no matching object, so the attribute change to EA8 is a lost change. Two hours later, it is created but there is NO change to the source object for the DSA to replicate to trigger the matching.

    This is your root cause.

    The fix would be to have FIM Add a ProxyAddress to the source proxyAddresses attribute AFTER the object was created in the target.
  • So we have a third option, which is kind of second option. The only problem is the customer does not allowed us to change any attributes in source AD by FIM.
    Yes, DSA does it but only for an attribute (targetaddress9 in source. And this was actually not allowed, but it was a 'must to be' for the migration.

    And we have also a complex FIM logic implemented. That means the FIM guys will never change FIM configuration just for period of time (coex. time), because after migration there will be no DSA and FIM will provision new linked mailboxes alone.

    So, back to my main question: Is it possible to run a full sync each two hours? If yes, how?
  • No. There is not. The only way to trigger a full sync while in delta is for the source DC to be changed. That will trigger a full resync dynamically because the USN are different.

    If you would let the DSA create the objects, there would have been the same problem. You would still not have mailboxes created without changing a MBRedir source attribute.

    Really you should not be adding mailboxes into the scope of the dir sync as the migration runs. All users and groups in the should be mail/mailbox enabled in the target when you migrated the first mailbox. This is to fully populate the GAL and allow the delegates and permissions and other tasks to work with a full map. Without this mapping alot of functionality with have less then a full map to wotk with and some translation functionality will be lost.

    So you are really painted into a corner with your non standard configuration using two directory sync products in concert and the limitation you customer has placed on you.

    To automate this, FIM needs to change the source object post creation in the target. Or you could stop adding source users into the scope of the sync period, and that would solve the issue once and for all.