I'm experiencing significant growth of my templog.ldf file (for the tempdb database) when I go to export objects to the FIM Service database via the FIMMA export. It seems to be averaging about 700k of log file growth per object processed . It was probably halfway to 60-70GB in size before it ran out of space on my test box (on a real production box it might be less of a problem but I'm not there yet) while processing over 90,000 user objects. I also have several dozen groups that are included (I think). Is this normal? Does it likely indicate a configuration problem, or is there some way to avoid this? Right now I'm doing exports a few thousand at a time, which keeps templog.ldf from growing too much larger than the MicrosoftIdentityIntegrationServer.mdf file (weighing it at 3GB) that I moved over and upgraded to FIM. I've already tried turning off Full Text Search according to the article http://technet.microsoft.com/en-us/library/ff608274(WS.10).aspx but that does not seem to have any impact. It did not appear to change the speed of the process either. I have not made any or many of the other changes in the best practices as I don't currently have the hardware to support it (different spindles, etc.) For reference, I have FIM 2010 and all related components (SQL 2008 R2, WSS 3.0, the FIM Service and the FIM Sync Service) running on the same box. I don't expect stellar performance, but a templog.ldf file that was 25-30GB and still growing was a bit of a surprise to me.

What is your version numbers for both SQL and FIM, Chris? Just checking you have the latest and greatest patches ... The tempdb bloat on export could be attributed to a number of things which happen on either the fim sync engine or fim service side ... so to isolate it to one or the other I would suggest the following: Edit the Export (to FIM) run profile and set the logging option to create an xml "drop file" and abort the run ... this way you take the FIM service out of the equation and can monitor the affect of the export on the tempdb growth (I suspect this is not the issue, but you need to eliminate this) If your tempdb doesn't grow (at least not to the same extent) after step 1, run a standard export to FIM and monitor the generated REQUEST activity on the Search Requests page in the portal - also check the event log to see if there's any errors being thrown (just in case) My guess is that there might be an MPR you've created/modified which is firing (unexpectedly) on export to FIM which is causing your bloat ...Bob Bradley, www.unifysolutions.net (FIMBob?)

Hey Bob! It's been a busy month with no FIMmy play time, but here are my details: SQL Server 2008 10.0.4000.0 SP2 Enterprise Edition (64-bit). FIM 2010 4.0.2592.0 I haven't quite gotten to MPRs in my learning yet...it looks like whatever came preloaded are all disabled. The day after I posted I did manage to get the export done save about 60 items that errored, done by exporting in workable chunks. Suspecting the errors were related to user-group relationships that hadn't been built properly yet, I ran a FIFS. The export errors are still there, and the exception points to an MPR. I don't really want to get into that now...was really just wondering what to expect from the new product. I guess if several dozen groups all with a few thousand users each in them, and those groups are throwing export errors, that might bog it down. . . . Ah! The Search Requests page did show 95351 items total, which perhaps had something to do with it as well. There I can see why the groups aren't exporting, as well. There's no policy allowing the sync account to create them like there is for the "Create Person" requests. FIM is so ODD for someone who just learned ILM over the last year+ !

If you have both SQL DBs on the same SQL Server instance, then you may want to look into splitting them into atleast two seperate SQL Server instances. SQLServer1\Fimservice SQLServer2\FimSynchronizationSErver Here are some good topology documents: http://technet.microsoft.com/en-us/library/ff400273(WS.10).aspx http://technet.microsoft.com/en-us/library/ff602886(WS.10).aspx Tim Timothy P Macaulay, MCSD, MCSD.NET, MCAD, MCP

If you have both SQL DBs on the same SQL Server instance, then you may want to look into splitting them into atleast two seperate SQL Server instances. SQLServer1\Fimservice SQLServer2\FimSynchronizationSErver Here are some good topology documents: http://technet.microsoft.com/en-us/library/ff400273(WS.10).aspx http://technet.microsoft.com/en-us/library/ff602886(WS.10).aspx Tim Timothy P Macaulay, MCSD, MCSD.NET, MCAD, MCP

I have the same problem and I think its normal to have that size growth when dealing with large number of objects, you need to create a procedure to shrink the database log file by using: dbcc ShrinkFile('tempdblog.ldf') then create a job in the SQL Server Agent to run the procedure you just created, and schedule it as needed I schedule the job to run daily every 3 hours. you can check this article How to shrink the tempdb database in SQL Server