Friday, May 11, 2012 5:04 PM
I am using classic provisioning rules but recently discussed with a colleague about how group and user resources are getting created in the FIM portal by the FIM MA without the use of sync rules. The only classic provisioning code I have for the FIM MA is to deprovision terminated employees, nothing to create a FIM connector.
I've seen other posts how people can't get the FIM MA to provision objects into the portal without a sync rule, but I have the opposite problem, there are objects I'd like to restrict the creation in the portal as I only need them in the metaverse for other MAs to consume, but I don't know how to prevent this if I am not doing anything now to provision the objects into the portal other than having the object type mapping.
As a workaround in my test environment I am creating a new metaverse object type that isn't mapped to a object type in the FIM MA and that seems to be working but I'd really like to understand how the FIM MA decides to create objects in its connector space without anything from what I can tell, saying to do so. When the objects are created it always says "provisioning-rule" as the reason.
Friday, May 11, 2012 8:03 PM
If you project an object into the Metaverse as a class that you have established a linkage to in the FIM MA definition, you will automatically create an object of that type in the FIM MA with only the MV ID and the Resoruce ID on it. So honestly, you don't really NEED inbound source rules, you could just use this to create the object in the portal and use classic rules without ever having to write "provision to FIM" code.
Give it a try and see if that matches what you are experiencing.
- Marked As Answer by Markus VilcinskasMicrosoft Employee, Owner Sunday, March 17, 2013 2:18 PM
Friday, May 11, 2012 8:23 PMThat's what I figured. So, if I don't do an object type mapping, then it won't project unless I use a ISR or classic provisioning code to create it?
Friday, May 11, 2012 9:34 PM
It was my understanding that if you didn't have an object mapping, you can't get it into the FIM MA at all. If you're going to try using MVExtension code to provision into FIM MA - let me know if it works or not.
Never had a need to do that, but it would be interesting if you can...
Frank C. Drewes III - Senior Consultant: Oxford Computer Group
Saturday, May 12, 2012 5:15 PM
Really I am looking to find out why I am having objects created in FIM with no ISR defined with a Create Resource in FIM Portal ...
I want to be able to do that, limiting the objects that get created in the portal to ones that I need in the portal. But I can't track down where the provisioning rules are that are telling the sync engine to create a connector in the FIM MA connector space.
Monday, May 14, 2012 8:36 AMThere aren't any rules, it is a feature built-in to the product. If you have the object type mapped then it will always create a FIM portal object. There is no way to choose which objects get provisioned and which don't this way. The only way is by having different object types. It is a pain at times.
Monday, May 14, 2012 12:31 PMSo the Create Resource in FIM Portal on a ISR is worthless?
Monday, May 14, 2012 12:47 PM'Create Resource in FIM' will create it in the Metaverse. I don't think you can select the FIM portal as a system anywhere in a sync rule.
Monday, May 14, 2012 1:06 PMSo that just controls whether the ISR is a join or a join else project ...
Tuesday, May 29, 2012 4:14 PM
That's correct. Microsoft considers the FIM sync engine metaverse and the FIM portal to be inextricably linked, intertwined, and in many ways mirror images. If you can manage objects in the sync engine as a completely separate object type that has no mapping to a FIM MA object type, they'll never be provisioned there. However, if some objects of an object type should go to the portal and others not, there aren't really any supported ways to make that work.
Carol suggested a way to keep some objects out of the FIM MA/portal by calling a deprovision on it in your provisioning code, however it is probably unsupported and has some limitations that I found when playing with it if those objects are ever going to change in a way that should permit them to be provisioned to the portal later. It's still a clever idea to keep in your toolkit.
- Marked As Answer by Markus VilcinskasMicrosoft Employee, Owner Sunday, March 17, 2013 2:19 PM