I wanted to ask this question to other FIM users. Our full syncs take about four days to complete and during this time, portal changes are not written to AD until the full sync cycle finishes. How do others combat this type of behavior? In some cases we've had syncs take five days so even starting over a weekend doesn't do us a lot of good. Cheers, Andrew

The way I would attack the problem is to start with seeing why the full sync is taking so long. It may be that it just takes that long, or it may be possible to optimize the system so that full syncs don't take so long. It should also only be necessary to do a full sync if you change the sync server config, so you should rarely have to do a full sync. Can you send more info about your scenario - objects, disconnectors, etc in the system you are doing a full sync on? We can start from there and see what can be done. But you are correct, - while you're doing a sync on one MA, you can't sync new data coming from the portal.Frank C. Drewes III - Senior Consultant: Oxford Computer Group

Like frank says, tell us more about you setup. 4 days is very long. You should start considering the delta synchronization and delta imports where appropiate and only export if there is data to export to CS. How many managements agent do you have and what agents cause long processing times during full synchronization? Are imports also running very long?Need realtime FIM synchronization and advanced reporting? check out the new http://www.imsequencer.com that supports FIM 2010, Omada Identity Manager, SQL, File, AD or Powershell real time synchronization!

Hi there, We have four MAs. We're managing 300,000 AD group objects with FIM. We do delta's syncs every 30 minutes and those complete within 20 minutes of their scheduled runs. We only do full syncs when required, due to a code change or some type of configuration change. We have a big code change coming up and will need to do a full sync. We've worked extensively with MS and our internal DBA group to optimize SQL but the syncs just take that long. Our envrionment is two portal servers, a FIM service server, the sync engine and SQL. Due to our organiztion SQL and FIM cannot reside on the same box but we have them on the same subnet at least. 72cores in the SQL box with 32GB of RAM on SAN storage. When we do our syncs, full or otherwise, all of the servers are under very low utiliziation in terms of resources. The FIM MA is what seems to take the longest.

What portion of the 4 days is caused by the FIM MA, and is this the Full Sync, Export or Import? And what are the times for the other agents and what profiles are they running. It seems your hardware is capable enough, are you only managing groups or also users? and how many? Need realtime FIM synchronization and advanced reporting? check out the new http://www.imsequencer.com that supports FIM 2010, Omada Identity Manager, SQL, File, AD or Powershell real time synchronization!

Yes - groups (the evil combination of reference and multivalued attributes) Which FIM version are you on? There are supposed to be some performance improvements in Update 2 and in FIM R2 when it RTM's specifically with that scenario. I obviously wouldn't jump right to either one right now, but it might be worth setting up a test lab with those and see if you get the big performance improvements promised. Frank C. Drewes III - Senior Consultant: Oxford Computer Group

It is the Export on the FIM MA that tends to take the longest but the entire sync cycle itself is just long. On some runs, it will complete in two days. I'll have to get stats on the other agents. Our production build is 4.0.3594.2. We haven't applied Update 2 in production but it is in our dev / test environments. We're pretty sure our sync times are something we just have to live with. We've had extensive engagements with MS about it and nothing definitive as to the cause. We have a lot of churn in our directory and a boat load of groups. :) We're only managing groups at this time and not user objects. My main question was just to get a sense of what other organizations do with similar sync times to appease their users while the water boils. :)

How many objects have you got there? And are you using declarative sync? Because if so the EREs and DREs will be slowing you down and I would suggest moving to classic. Or upgrading to R2 to second it comes out to get the scoped (read "no ERE") outbound sync rules. On the exports - I guess you've already set the tuning parameters in the config file to allow faster processing? The other thing to look at is the number of sets on the portal, and what sort of workflows you fire on exports through the fim ma. One other question - which objects are being exported to the portal? If groups are managed in the portal then are there only import flow rules on the groups? What do you have export flow rules on?http://www.wapshere.com/missmiis