As far as I can tell, the only way to get objects from the metaverse into FIM is by using an inbound sync rule and ticking the "Create resource in FIM" box. But what if you don't want to manage all the imported objects in FIM?An example to illustrate (based on a past project of mine): a university has three user types - student, staff and alumni. To get over the various complications with people moving in between these roles, or holding more that one role at a time (eg., staff who is also student, alumni who comes back to do another course etc) all are projected into the metaverse as "person". What then happens to them in terms of provisioning to connected directories is based on attributes.Now I could well imagine that this university will only want to manage staff through the portal. Maybe students. Definitely not alumni (who are by far the largest group). How would one only create staff and students in FIM, and then remove them when they stop being staff or students?I haven't tried, but I'm guessing an old style provisioning rule won't work here because I won't be able to generate the objectid.BTW this is not a completely hypothetical question - as well as this example I have another customer with a similar scenario. They have 800 internal users and 30,000 external users. We will be looking at upgrading their ILM next year and they may only want to manage the internal users in the portal. Carolhttp://www.wapshere.com/missmiis

Hi Carol! As long as you have a an attribute that specifies what kind of person resource it is (Staff, Alumi, etc) you can specify a filter - "Connected Object Scope" on the Scope tab of an Inbound Sync Rule to decide which resources should be imported into FIM based on attribute value and since you can specify multiple sync rules for a single resource type the "Create resource in FIM" checkbox will decide if the object will end up in FIM DB.Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

I had tried out the multiple inbound sync rules but was projecting to different object types in the metaverse. You say I can have different sync rules that project to the same object type?Right - off to give it a go.http://www.wapshere.com/missmiis

It sort of works... the problem I'm having is when a person moves from one scope to the other. I am importing people from a SQL HR table. A status of 1 means active. Anything else means inactive. I created three inbound sync rules:1. Import-SQL_Users-Active Scope: status = 1 Create in FIM: Yes Inbound rules: employeeID, status = "Active" 2. Import-SQL_Users-Inactive Scope: status != 1 Create in FIM: No Inbound rules: employeeID, status = "Inactive" 3. Import-SQL_Users-Attributes Scope: all Create in FIM: No Inbound flow rules: everything else - so I only have to define them once. I also added a classic metaverse deprov rule to remove people from FIM once their status changes to Inactive. (The "Enable Deprovisioning" option is greyed out in my sync rules - is this still an awaited feature?) The real problem is when a person's status changes in the SQL table - I run into a precedence issue. The first time I tried changing a person's status from 1 to 2 nothing happened. Their status did not change in the metaverse. I figured out this was a problem with the precendence of the flow rule. I swapped the precedence and now it works. But obviously I will get a problem now if I make the data change in the other direction. I'm surprised I even need to worry about predence between two inbound sync rules which have mutually exclusive scopes - but that's certainly the way it seems to be behaving. At the end I don't know if this method would work IRL - it would depend on end user requirements of course. I feel it is not as inherently flexible as being able to write traditional provisioning code for the FIM MA. http://www.wapshere.com/missmiis

As far as I can tell, the only way to get objects from the metaverse into FIM is by using an inbound sync rule and ticking the "Create resource in FIM" box. An inbound synchronization rule defines the object and attribute flow of an object from the connector space into the metaverse.As soon as you bring something into the metaverse, it is replicated into the FIM app store. But what if you don't want to manage all the imported objects in FIM?...Now I could well imagine that this university will only want to manage staff through the portal. You need to differentiate between managed by the synchronization process and managed by the portal - these are two different things. Basically, you should bring all objects into the app store. Whether or not you are also (manually) managing by using the portal is something you can configure on the portal side.Cheers,MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation

Filtering objects this way is a bad practice.Cheers,MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation

Hi Marcus! Why is it a "bad practice"? I believe restricting what ends up in the AppStore will be a common use case in order to save CAL's so what's the recommended way to accomplish that? Edit: If I've understood the new licensing requirements correct of course? //Henrik Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

In addition to the CAL question there is a pure issue of scale. With my example of a customer who has 800 internal users and 30,000 external users (all with AD accounts) it would seem excessive to have to synchronise 30,800 objects into the app store when you only actually wanted to manage 800 in there. Also you say bring all objects into the app store - again I can see lots of examples where you wouldn't do this. Customer contact details synchronised directly from the CRM system to contacts in AD. Very large groups (10k+ members) which would slow the FIM MA down too much. I love the fact that I can offer a customisable interface for user and group management - but I can also think of plent of sync tasks I will continue to do that should bypass the app store entirely. Is this not expected?Carol http://www.wapshere.com/missmiis

... And why is there a "Create resource in FIM" checkbox at all if "As soon as you bring something into the metaverse, it is replicated into the FIM app store"?Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

Henrik,this is from the technical perspective, which doesn't include CAL issues :o)So, from the technical perspective, you should keep the number of filtered objects at a minimum.Cheers,Markus Markus Vilcinskas, Technical Content Developer, Microsoft Corporation

Markus, For what reason if I may ask?Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

Sorry, not sure I understand your question correctly...From the MV perspective, the app store is a mirror of the MV.This means, all objects in the MV are supposed to be in the app store (but of course not vice versa)."Create resource in FIM" translates to "project into the MV and provision into the FIM MA CS".Cheers,Markus Markus Vilcinskas, Technical Content Developer, Microsoft Corporation

If you have only 2% of your environment in FIM, you can forget about managing certain aspects such as unique identifiers.Also, having 98% of the objects filtered in the CS doesn't really help you in conjunction with scalability.In case of a delta sync, the sync engine would have to touch 30K objects for no good reason.If scalability is a concern, you should rather restructure your data source to make sure that only the objects you care about are in the scope of your partition\container filter.Cheers,MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation

Ooops, hold your horses! It means "bring an object from a conventional connector space of a managed data source into the connector space of the FIM 2010 Service" i.e. provision to FIM Service DB when checked. If it's not checked resources will still be projected to the Metaverse and here I wish to know the reason why "from the technical perspective" resources should be provisioned to the appstore even though I have no intention of manage it from there? I see no reason why appstore shoud be a mirror of the metaverse, I rather see it a place where resources could be manipulated in the same way as if I provisioned to an SQL DB and manipulated it there and in a SQL case there's no reason to make it a mirror of the metaverse. Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

How about projecting your users to different mv object types (e.g. portalUsers, nonPortalUsers) then not linking the nonPortalUsers to the FIM MA?Dave Nesbitt | Architect | Oxford Computer Group

Hi Dave! According to Markus appstore should be a mirror of metaverse except for those resources only available in appstore so if both of types of your resource types exist in metaverse... Personally I think it's a huge design flaw if delta sync for appstore is different from other connectors (I don't have the required knowledge to judge here) but for the unique identifiers, workflow gives us the possibility to check for that directly at the source.Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

About the horses (good idea!) :o) – let’s make sure that we are not merging too many things here. I was thinking about splitting this post since we are talking about several different topics. “If it's not checked resources will still be projected to the Metaverse” – Henrik, where did you get this from? Create resource in FIM translates to project the object into the MV and provision it into the FIM CS. If this option is not selected, there is no projection! Regarding best practices… The way I interpret best practices is “this should be your starting point in your design”. These are definitions from the ideal world perspective. If you don’t follow a best practice, ideally, I want you to do this because you have good reasons. If you have good reasons, not applying a best practice is fine – but “I want to see your reasons” – if that makes sense… It is possible that you have good reasons for not applying a best practice. Next to political reasons (which can block everything), there are budget related reasons or at the end just “I know what the tradeoff is – and I can live with it”. In other words, not applying a best practice does not necessarily mean “this is a bad solution that will not work”. Over the years, I have seen too many cases where our best practices got ignored for convenience, which has caused at the end big problems… So far, so good? Regarding the “what to do with objects I don’t plan to manage story”… If there are objects you are not planning to manage, you should not bring them into FIM in the first place. Depending on the affected connected data source, there are partition/container filters and there are views in SQL you can use to limit your data set. Yes, this may require, for example, restructuring your AD and often people don’t do this because adding a filter for “displayName = Henrik Nillson” is soooo much easier than going through the pain of convincing the AD owners to restructure the environment. Now, important is in this context, to think through what a filter like “displayName = Henrik Nillson” means to your environment – the filter is always active – even, if you have filtered Henrik already. This type of filter is always applied to all objects that are processed – whether this is necessary or not… As soon as you have filtered Henrik, why do you want to bother all objects moving forward with the question whether they are Henrik? This makes no sense from the processing perspective- does it? In my TEC 2008 presentation on best practices for ILM 2007, I covered this example. From that perspective, Dave is right on the money – projection can be the better filter in your environment if you want to exclude certain objects and want to make sure that they are not processed anymore and don’t affect others as soon as there are filtered. Just project them to an object type such as “unmanaged object” and you are good… What you need to keep in mind is that an object that is filtered by a connector filter is still a pending import! All pending imports are processed during a delta sync. While Carol’s data set is a bit small, make it 100K objects that are touched during each delta sync and then, let’s have a discussion on why FIM’s performance is bad. If you are processing thousands of objects, while only “a couple of them” really require processing, it is not because of FIM – it is because of your bad design… Does this make sense so far? I don’t know how to explain this in a good way – and I hope, that you guys can help me with the explanation, but… Two clicks don’t necessarily mean being more effective. I have seen too many examples of spaghetti code that is guilty of the bad performance reputation of Visual Basic – if that makes sense. Back to Carol, who owns this thread. To be quite honest, I don’t understand what it is you are trying to accomplish with your latest setup. There might be a good reason for these scoped ISRs – it is just too late for me to get what you are trying to accomplish… Cheers, Markus Markus Vilcinskas, Technical Content Developer, Microsoft Corporation

Ok! All this makes sense and I'm sorry and a bit ashamed, my absolute belief was that not checking the checkbox still would project the object into metaverse. :-) What I meant was that a lot of people have perfectly working legacy rules (not necessary spaghetti) and might not be interested in moving it all to declarative rules just because they upgrade, maybe they wish to start with or limit it to staff just as in Carols example, maybe for saving money on CAL's or maybe just because their legacy rules already does the work for them but then you mean it's ok to project others than staff into metaverse as a different unmanaged object type - Perfect, now we know how to follow best practices without bringing all our objects into appstore and that should also be the answer Carol is looking for but of course she must understand that she must take special care around unique identifiers etc. Edit: I promise to wear a silly hat all day long for making such a fool out of myself! //Henrik Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

Hold your horses :o) There is no (zero, zip, zilch) need to feel ashamed or anything like that. This is a very good discussion and I hope that others find it useful, too. Cheers, MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation

Of course, if the licensing for FIM CALs is flexible enough for customers with very small wallets (especially Higher Ed), or very, very large user bases, then we shouldn't get into the situation where people don't want to provision to the portal in the first place ;)Dave Nesbitt | Architect | Oxford Computer Group

A couple more questions/comments:Dave the idea of projecting to different object types had already occurred to me, but as I mentioned in the initial post I have had experience with a site where we were forced to use a single person type because of the overlap in roles, and the movement between them. (Actually it was our good friend Hugh S-W who suggested this approach to me and he was exactly right.)Markus - I'm projecting contacts into the metaverse here without ever having ticked "Create resource in FIM" and without having defined an old-style projection rule. All I did was create an inbound Synchronization rule and define my import flows. The contacts were duly created in the metaverse and I thought nothing of it. But you seem to be saying that they should not have been projected into the metaverse at all! Am I reading that right?Agree about all the best practises obviously, however we're still in a getting to know the product phase here (at least I am) and one thing about best practises is they need time to develop. One of the reasons I'm playing with these scenarios is that I want to hit the ground running when RTM comes out, and I want to have some good demos for the potentials who are already interested. So while I'm only working through hypotheticals at the moment, they are scenaros which I think will be relevant.Carolhttp://www.wapshere.com/missmiis

I highly encourage everybody not to try to learn FIM with the ”learning by doing method”!In many cases, this leads to nowhere.Carol, your scenario is a perfect example for this. As a best practice :o), I would suggest using the conceptual part of the “Introduction to outbound synchronization” as a starting point for “how declarative provisioning works” discussions.Right now, I’m in the process of moving the conceptual part of this document into a separate document.It would help me if you could let me know what parts need clarification and what kind of additional information you would like to see included. I will open a separate discussion post to collect feedback in conjunction with this.Sounds good? “Create resource in FIM” translates to “project the object into the MV and provision it into the FIM CS”.If this synchronization setting is not enabled, there is no projection taking place. Carol, according to your description, your connector space objects are in the scope of three (!) ISRs.One of them “projects”. SR precedence is not applied on the SR level; it is applied on the synchronization settings level of a SR. The SR that has “Create resource in FIM” enabled is the reason why your objects are projected. Cheers,Markus Markus Vilcinskas, Technical Content Developer, Microsoft Corporation

Here is the link to the discussion post.Cheers,MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation

Markus,no in the case I mentioned there is one single ISR which is projecting a single object type. I did not tick that box and I guarantee I have objects in the metaverse. The other example with the three ISRs - that was just experimenting. And really I don't see how else I can learn this. I don't do well reading lengthy documents - hands-on practical is the only way to go. Documents along the style of the original MIIS walkthroughs would be perfect - the more choice of scenarios the better. I think it is a very good idea to break down that outbound sync document - WHICH I HAVE READ - though I have not memorised every word. You tell me not to learn by doing - that worries me a lot - how else are people supposed to learn? All IT people learn by doing. If this product has any hope of greater market penetration then it is essential that time-pressed sys admins should be able to achieve something worthwhile with a minimal time input. That's how the real world works.http://www.wapshere.com/missmiis

One thing bothers me about this... You should be able to filter if you wanted to... For licensing and scale. The checkbox in the sync rule doesn't matter. If you have the object type in the FIM to match to an object in the metaverse..... WHenever you project to that object type... It will automatically create a FIM object... So honestly the checkbox, not being checked doesn't work. I have a very very large customer right now that has this issue.. and this is a very discouraging feature that should go back to the drawing board. Joe Stepongzi - Identity Management Consultant www.microsoftIdM.com,ilmXframework.codeplex.com

I think there is something that we are forgetting here which harks back to early MIIS/ILM days when all we mostly did was user object syncs/provisions ... and that's group membership. I understand that for groups to be managed in FIM requires all member objects to be in the FIM portal, AND in the MV, AND in each participating CS. ... in which case the question comes down to (a) impact on scalability of the solution in terms of performance/throughput, and (b) cost of CALs (since as I understand it these are calculated on the number of user identities under management in the portal - by the FIM MA). Correct me if I'm wrong. I expect that most places that want to use FIM for large numbers of identities will be looking at managing group membership too ... in which case I too hope that the "education pricing" is not prohibitive ;). We shouldn't force clients to hobble their solutions (and violate "best practice" in the process) just because the pricing model gave them no choice.Bob Bradley, www.unifysolutions.net (FIMBob?)

Can't agree with you more FIMBob.... lol .... I love it... Anybody try provisioning code? to disable object creation? the other issue I have is... why not just not charge people for the extra people.. but only charge for active people... Then I wouldn't mind so much.... really all objects need to be there for workflows to fire properly without going to other data sources.. I mean I do lots of things in workflows.. Like default groups... groups I don't really need to manage or haven't scoped to do yet..... homedrives... etc.... lots of stuff.. I really think there needs to be a stipulation.. probably didn't spell that right.. lol.. Licensing definitely needs to be changed.. Also with projecting to other objects... I really don't like it.... yes you do remove disconnectors.. which means delta syncs will process quicker..... but trying to do a conversion.. (switch back to another object type is a real pain)....... I prefer to use one object with attribute changes... makes rehires, tranfers... employee to contractor and contractor to employee scenarios much cleaner...Joe Stepongzi - Identity Management Consultant ilmXframework.codeplex.com

This thread is going in different ways and I can help out to drive it back to filtering for scale and any other technical reason you might think about since none of the above means that you dont have to have CAL's. The CAL's are for all users being managed by FIM so even in this case the users are in FIM. The only way to not need CAL is to not user the FIM Service nor Portal. Brjann This posting is provided "AS IS" with no warranties, and confers no rights