I have had a bit of a search and have found a few posts where people are seeing the problem of very slow exports when initially populating the FIM portal. I was wondering if there is a decent white paper or knowledgebase article anywhere that lists all the tricks that can be used to improve this? With asynchronous mode turned off I am seeing about 0.5-0.6 objects/sec, if I set the synchronizationExportThrottle="Unlimited" I can push this up to about 1.6 objects/sec. I have tried playing with the <resourceSynchronizationClient /> settings in the miiserver.exe.config file as suggested on 1dent1ty cHa0s and can get up to almost 1.8 objects/sec. We have less than a million users in our system, so it is certainly by no means huge, but a full initial load of the portal is still going to take 5 days, which seems a little excessive to me. Are there any other settings that can be tweaked to make this workable? Cheers.

If you're near a million then you're most likely outside the normal/intended size for a default installation whereby everything gets plopped into the FIM Service. At that scale I would be aggressive in reducing scope so that you have less objects in the FIM Service. CraigMartin Edgile, Inc. http://identitytrench.com

If you're anywhere near a million objects, I would say that if it isn't huge, it is definitely in the higher percentiles among environments. The hotfix required to get asynchronous mode has warnings about not applying it unless necessary, but it doesn't sound like you would really have an option. If you have not already read the TechNet article about post-installation tasks, please review that to see if you have already followed its recommendations. The highlights are to turn off full text search during the export, and don't have anything configured in the portal that you don't have to have in order to populate the data. The rules can all be added once the data is exported to the service.

I'd like to add to the suggestions above: I've also heard that removing any Sets with complicated filtering criteria can help. Sidenote: with an initial load that large, you might want to consider changing your request history retention period to a day or two as that can help you save some database space. Good luck! Sami

Personally at that scale I'd start evaluating the necessity of the portal as part of the solution. In any case, I did a bunch of twiddling with the async options and these are what I ended up on which got me very good throughput: exportFetchResultsPollingTimerInSeconds="3" exportRequestsInProcessMaximum="350" exportWaitingForRequestsToProcessTimeoutInSeconds="600" You'll need to play with them with relation to your SQL and FIM Service perf capabilities - CPU, disk, etc. My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Your initial objects per second time, .06/sec, seems quite slow. By default, using the OOB synchronous behavior, I typically see between 1500-2000 objects per hour as adds on export to FIM MA. Unless you already have complex sets in place and possibly configuration items as suggested by Chris, I believe you may have a bottleneck somewhere else. Are the SQL DBs on the same box as FIM service, or remote? If remote, are they on same machine, are transation logs and data files on different drives? FIM seems to perform better if the two DBs are not on same disk partition. Some SQL tuning might be in order if any of the above applies to your scenario. Glenn

Thanks for the responses. Just to clarify, these figures are from our Mirrored Production Environment, so I am hoping we will see better performanace in Production, but I wanted to have all the tweaks tried out before I have to face the fun of getting the bulk of my users into the system for real. Craig - this particular FIM instance is to allow Self Service Password Reset, so I cannot really see any way of having fewer objects in the FIM Service. Chris - we have turned off text search. Unfortunately, for this case, we cannot easily remove the portal configuration as it is already in use for some users, so I guess we just have to suck it up. I will certainly rethink this for the remaining FIM Portals that we will be deploying. Thanks Sami for the suggestion about request history - I have reduced that and will see how things go when I kick off the next 200,000 users through the system. Brian - much as I would like to evaluate the solution and consider doing things differently, the product decisions have been made and the design is approved - I am just the poor soul doing the implementation. Thanks for those sample settings - I have been playing around with them and can improve things - unfortunately, though, only marginal increases. Glen - we do have some infrastructure constraints in our test environment. The SQL server is remote from FIM and unfortunately everything is on one drive. Even more unfortunately that drive is a Raid 5 SAN lun - a constraint placed on us by the customer's infrastructure team. We are hoping the Production disks will be more friendly to us. Thanks again for the pointers.

What would be considered the normal size default installation? If declarative rules are in play then it would not be difficult to reach a million objects in the FIM Service that need to synchronized. Is this why the FIM Capacity planning guide considers 200,000 users a large organisation and does not contain metrics exporting objects to the FIM Service? Sorry for my candid response but I can't believe some of the replies for what is suppose to be a enterprise class product.

I'm still experimenting with these pre-R2 settings in my UAT lab (education sector - staff and students, but staff only at this point), and I've posted my findings here ... I am using declarative rules (mostly inbound though) and the following counters are from my MV (rounded): #SRs: 31#EREs: 25,000 (5 outbound)#roles: 4,500#entitlements: 2,500#groups: 3,000#people: 14,000 I've not yet working with a full quota of entitlements at this point, but when I do I expect the number of groups to increase by an order of magnitude. This will bloat the MV even further (I have 61,000 MV objects right now, and expect this will end up around the 250,000 mark when the full quota of students and staff are combined). Will update my findings then. I appreciate many (like myself) are already working on pre-R2 projects, and R2 will be much better performed, but not everyone is going to be in a position to upgrade to R2 in the short term due to the potential retesting/rework/project risk involved (I don't expect the upgrade can be treated like a normal hotfix, and even they cost a lot in terms of regression testing, etc.). Hence I think there will be a lot of R1 sites for some time yet.Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM