I'm trying to edit the filter for the "Password Reset Users" set. I'm using the gui wizard and all I want to do is change the "User with any of the conditions below" to "user with all of the conditions below". Some details: the current filter has all my user objects in it (28.000+). I'm not sure whether this amount impacts setting the change. In the SQL tracer I can see that this specific query took 57999 ms (57 seconds). The Portal UI shows "summary: edit set", "status: Timed Out". The event log on the portal server: The Portal cannot connect to the middle tier using the web service interface. This failure prevents all portal scenarios from functioning correctly. The cause may be due to a missing or invalid server url, a downed server, or an invalid server firewall configuration. Ensure the portal configuration is present and points to the resource management service. Requestor: urn:uuid:7fb2b853-24f0-4498-9534-4e10589723c4 Microsoft.ResourceManagement.Service: System.NullReferenceException: Object reference not set to an instance of an object. P.S changing settings to other sets works okilidokely. Also doing a view members on the "password reset users" works ok. Backups run regulary and DB maintance has been performed (rebuild index, update statistics). Any thoughts? http://setspn.blogspot.com

I have seen this before. you need to increase your timeouts for this operation. Afterwards you will want to change it back, unless this is an admin partition http://technet.microsoft.com/en-us/library/ff800821(WS.10).aspx /configuration/ resourceManagementService/ @dataReadTimeoutInSeconds [0,inf) 58 The timeout used in all SQL select commands. /configuration/ resourceManagementService/ @dataWriteTimeoutInSeconds [0,inf) 58 The timeout used in all SQL update, insert, and delete commands. If it still timeoust you might also need to modify /configuration/ resourceManagementClient/ @timeoutInMilliseconds [0,360000] 90,000 The timeout of the client side of communication. David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

Seemed like a good tip. I tried them one by one (starting with the read and gradually adding the others) so my config now looks like: ... </services> </system.serviceModel> <resourceManagementClient resourceManagementServiceBaseAddress="fimsvc.domain.tld" timeoutInMilliseconds="120000"/> <resourceManagementService externalHostName="fimsvc.domain.tld" dataReadTimeoutInSeconds="120" dataWriteTimeoutInSeconds="120" /> <system.diagnostics> <sources> ... If I stopwatch between "submitting" and gettting "timed out", I have exactly 60 seconds. No matter what the above parameters are. I'm now having this behavior on two sets. So i created a new dynamic set: succeeded. I altered the dynamic membershop to a different filtered: worked. Back to my bad sets: timed out again... So I haven't got any further now. Any further tips are appreciated. http://setspn.blogspot.com

After googling a bit (using the parameters you provided) I came upon: http://technet.microsoft.com/en-us/library/ff608271(WS.10).aspx So the resourceManagementClient section was overruled by my web.config section which had 60.000 specified. Changed that to 120.000, and now it takes two minutes before timeout. So no real solution there...http://setspn.blogspot.com

I wouldn’t say I solved the problem, but I’ve definitely got my set configured as I want it… I followed: http://blogs.msdn.com/b/darrylru/archive/2010/02/02/extending-fim-timeouts.aspx Which is in fact also described at: http://technet.microsoft.com/en-us/library/ff608271(WS.10).aspx By coincidence I also had to reboot some servers in the FIM topology (some non-fim-related hotfixes had to be installed). After a reboot I was able to do a change just once, but then the issue resurfaced. So changing the timeouts didn’t really help. The Test I was trying to make currently had a 28.000 users in it scope, and had to get a new filter which consisted of “User with all of the following: not accountType = bla; not Language = a; not language = b; not language =c”. Each time I was getting either request failed or request timed out. Creating a new set with the exact same filter posed no problem. Performing changes to that set also posed no problems… And then I started gradually creating the filter. I added “not accountType = ble”, clicked submit. Watched my SQL CPU spike a bit and it got through. And so I added the clauses one by one… So I’m guessing our virtual SQL (lab environment) is being to slow somewhere. What I don’t get that all other portal interactions are fairly responsive. The preview for that exact set worked as expected. And creating/editing other sets went just fine…. I though Id write this for future reference… This seems related too: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/e7611d18-8988-4e77-bf15-762be36244da Regards, Thomas http://setspn.blogspot.com

Increasing the SQL read and write timeouts fixed this problem for me. I haven't bothered increasing the web timeout, so I still get the Set popup timing out after 60 seconds, but in the background the update completes, so I'm fine with that. I modified the file C:\Program Files\Microsoft Forefront Identity Manager\2010\Service\Microsoft.ResourceManagement.Service.exe.config < resourceManagementService externalHostName="fimserver.mydomain.local" dataReadTimeoutInSeconds="360" dataWriteTimeoutInSeconds="360" />http://www.wapshere.com/missmiis