scheduling full sync by DSA

"This includes proper email addressing and switching."
That means to skip all attributes for DSA? There are some one, which are mandatory like attribute 'proxyaddresses' which we could only skip by manipulating of skipattribute.xml file, which is by the way not supported but it did help us. Please check 'SR Number:4146391| - Skipping of IMAP and POP3 status form source to target'

"This might have been an option here??"
For this we need a list of which attributes have to be skipped by DSA.

If we use different EA in source for FIM and DirSync, we could create target object for matching before we move source object to the sync. For example EA8 for FIM and EA9 for DSA. Source Admin has to set first EA8. Then two hours later set EA9 and later set EA13."

That will handle the matching issue on the first pass, when EA8 is written. But that still leaves the mailbox enabling. That requires an attribute that is controlled by MBRedir to be updated. That is where the proxyAddresses update comes in. 

Just a little bit more about the configuration in our environment:
I agree with the idea to get GAL full before migration of the first mailbox.

It is not just an idea, it is the standard process for the migration tool. You can't grant permission to a resource you are migrating to an object that is not yet present in the target. So Delegation fails to migrate. This is a much bigger deal if you are migrating public folders. With just mailboxes, close sets of working groups can be enough, but there will still be some fall out. 

Mailbox enabled users in target will not work, because we have to migrate 8 Exchange organization parallel.

The full GAL is is tied to each Exchange org's migration, not all org. So when it starts to be migrated, the GAL for the org should be complete. And by complete, I mean complete with all in scope objects for that migration "pair" or as you said "one by one".

IHMO, FIM being as flexible as it is yet when a migration is in the mix, most FIM owners are reluctant to make changes to support the business needs. 

On a Side note: Migration Manager for Exchange supports third party sync engines, I.E. FIM. This means you would let FIM do it all. MMEX would migrate the mailboxes and FIM handles the directory. This includes proper email addressing and switching. This might have been an option here??

The situation is most difficult. As I told, it takes time to describe the whole configuration. There is another option, which could solve the timing problem in our case. If we use different EA in source for FIM and DirSync, we could create target object for matching before we move source object to the sync. For example EA8 for FIM and EA9 for DSA. Source Admin has to set first EA8. Then two hours later set EA9 and later set EA13.

Just a little bit more about the configuration in our environment:
I agree with the idea to get GAL full before migration of the first mailbox. Mailbox enabled users in target will not work, because we have to migrate 8 Exchange organization parallel. And each of 8 has more than one Exchange Server in up to 5,6, or 7 in other trees, which we are not allowed to connect to their Domain Controllers in first migration step. Instead of one by one Exchange org. we have to migrate only Mailboxes on first Exchange Server in each 8 Exchange Organization. Unresolved links are daily business, but this is another problem.

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.

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?

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.

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.

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.

Question, EA8 is being written to existing objects or newly created objects? I assume existing objects?

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'.