Hi, We have a small deployment of FIM 2010, and throughout some of the testing, things seem to indicate that a number of DGs and SGs criteria based memberships are not calculated instantly unless 'FIM_MaintainGroupsJob' is ran. The DGs and SGs are all criteria based, for example: (Account Status = Active, and 'Any' (MyMulti-ValuedString 'contains' 'Level A' or 'Job Code' is '100') ) The issue with this is that not all memberships are being missed, some do work without the maintenance job. The other thing is that the same Group could be calculating its membership instantly, and a moment later, additional memberships are completely bypassed until midnight when the maintenance is running. The FIM Service database has the proper indexes maintenance in place and the database is very well maintained. Doing some search on the Forum did not seem to yield a solution that would seem to resolve this. I was wondering if you've ever seen this before. Total size of users is around 3,000 and DGs and SGs membership do not exceed 500 mark per group at max. Thanks.

Which build are you on? http://social.technet.microsoft.com/wiki/contents/articles/2229.fim-2010-build-overview.aspx In build build 4.0.3594.2 there are some set calculation fixes (it is possible these affect group membership too) from http://support.microsoft.com/kb/2520954/en-us Issue 1 Fixes an issue that would sometimes cause incorrect Set calculations. This resulted in lots of set corrections. Also revised the Sets Correction job so that it does not change special sets that are maintained by another system maintenance job. -------- It is also possible that you found some sort of bug.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

Thanks David. We did apply this hotfix to the FIM environment and after few test the issue was surfaced again. We have now increased the FIM Service Database maximum memory from 2GB to 8GB; and running some tests seem to show good results so far.

Were you seeing any event log messages on the FIM Service box(es) or on the SQL Server indicating any kinds of errors that could relate? The issue with some updates sparking updates and then others happening moments later smacks of SQL Server locking issues with updating the group membership. I presume the updates are as a result of sync engine activity as opposed to portal activity? What are your settings on the MA? The asynchronous settings. Now that you are past initial load, you might need to switch back to synchronous.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

Hi David, I am not seeing any errors of any kind in the FIM environment (hosting FIM Service and FIM Service DB). The updates are generated by the FIM Service evaluating user's status and some other information. Based on the user information, the user is transitioned into a set or two, and becoming a member of one or more Distribution and Security Groups. I did remove the asynchronous settings off the FIM Service that may help throttling changes coming through the FIM Service, from the Sync engine; i.e. giving FIM Service a bit of breathing room to process changes/execute activities.