I’m currently working with Markus Vilcinskas on a couple of FIM Experts articles on how to detect non-authoritative accounts. Today we published the first two parts were the second part also contains an in depth description on how object state detection works. Enjoy!

Detecting Non-Authoritative Accounts – Part 1: Envisioning

Detecting Non-Authoritative Accounts – Part 2: Design

I turns out there’s a lot of things that needs to be in place before this is made possible…

Usage Keyword

Usage keywords are required for letting non-admin users see portal design elements like navigation bar and home page resources but also for letting them being able to use search scopes. The keyword for letting non-admin users take part of these objects is BasicUI…

1. Under Administration and Home Page Resources select the “Manage my SG’s” and add the keyword BasicUI as usage keyword.

2. Go back to Administration and select Navigation Bar Resources. Select the “My SG’s” navigation bar resource and add the BasicUI keyword to this one as well.

3. Go back to Administration again and select Search Scopes. Add BasicUI as Usage keyword to the “My Security Groups” Search Scope

MPR’s

There is two MPR’s that allows for group owners to manage their groups. Both of these are disabled by default.

4. Go back to Administration and in to Management Policy Rules. Open and enable these two MPR’s:

• Security group management: Owners can read selected attributes of group resources
• Security group management: Owners can update and delete groups they own

5. Done!

Conclusion

The usage keyword stuff is poorly documented but I hope this will be better…

I’ve had a long discussion with Markus Vilcinskas on the FIM Forum on a thread started by Carol Wapshere maybe better known as MissMiis on the subject ”Selective provisioning to FIM”.

Carol wanted a way of bringing only a subset of users into the FIM AppStore and I really understand why, the reasons could be to save money on CAL’s - 30.000 users * 25$ = 750.000$, or maybe you already have perfectly working legacy sync rules.

Think before you try to do this, the best practice is that AppStore is should be a mirror of the Metaverse except of course for the resource types that live exclusively in the AppStore.

My first idea was it could be fairly simple to filter out users from the AppStore by the filter you could find in the declarative input sync rule but that was not a good idea at all, if you have 32.000 resources and you filter out 30.000 of these all of the filtered resources will be hit during sync since they're disconnectors. This is bad!

I also must admit I had a silly belief that the “Create Resource in FIM” checkbox, unchecked would project resources into the Metaverse and I was all wrong and for that I’ve promised to wear a silly hat all day.

So how should it be done then?
The best practice is to bring all your objects into AppStore but you could bring objects you don’t want to manage in the AppStore as separate object types into Metaverse using legacy rules but remember you won’t get the management of unique identifiers and group management might become a nightmare so think before you plan on not bringing all your objects into AppStore!

Download it here
A VHD will be available in 7-10 days at the same location…

Documentation could be found at the Connect site.

• RC1 Release Notes
• RC1 Installation Guide
• RC1 SDK

Edit 2009-10-03: Documentation could now be found at http://technet.microsoft.com/en-us/library/ee621258%28WS.10%29.aspx