Thursday, September 06, 2012 11:40 PM
Can someone please explain how something like this is possible:
- User is not in the Set
- User has no EREs
- User has one DRE (for an external SQL system, and the user still exists in the connected system)
Friday, September 07, 2012 1:48 AM
DREs are created if inbound sync rule has existence test attribute that is populated for object. So if there is an inbound sync rule for this SQL MA and the object has a connector there, then this would be expected. DREs can be used with sets in portal to drive policy; you can have set of objects with DRE populated and it basically represents 'everybody who exists in connected system X'.
This link has more information on DREs and EREs and how they are used.
Note: I personally don't like DREs because they ultimately represented by objects in the portal, so it adds more 'stuff' in portal. There are other ways to determine an object exists in a target system. For example, if you have an AD MA and want to 'prove' objects are there, you can import objectSid back into the portal. objectSid can only come from AD to begin with. There are some considerations with binary attributes and set filter definitions but this is just an example.
- Marked As Answer by Markus VilcinskasMicrosoft Employee, Owner Thursday, September 27, 2012 11:33 PM
Friday, September 07, 2012 3:52 AM
Yes I have setup existence checks in this deployment.
Essentially we have the usual Portal provisioning logic: Transition into a Set, provisions user in a SQL database (MPR, Workflows, Sync Rule)
The initial provisioning created the user in the SQL database and the object had an ERE and DRE.
When the user transitioned out of the Set, the MPR/Workflows/Sync Rule should have kicked in and removed the record from the SQL database (like it did for the other 10,000 objects). However, even tough the ERE was removed, the DRE stayed since the record was not actually removed from the SQL database.
Its a very text book FIM Portal 'transition into Set / transition out of Set' configuration that works for 99.99% of the records - why would it not work for that one record? How do we go about troubleshooting/resolving this further?
Do I need to create another Set/MPR/workflow combo to try remove the record from the target SQL database again?
- Edited by S.Kwan Friday, September 07, 2012 3:54 AM
Friday, September 07, 2012 3:55 AM
Again, I want to stress..........EREs and DREs have completely different functions. EREs defintely won't go away unless you configure workflow to gracefully remove them. With DREs, its been a long time since I have used them(again, I don't think they are a good idea, there are other ways of accomplishing what they do), I would have to test further to find out what removes them gracefully, if anything. I do know that they definitely can be orphaned, like EREs can.
Friday, September 07, 2012 4:13 AM
So if we forget about the DRE for a moment, and rephrase the question:
As mentioned, we have transition in/out Sets/MPRs/Workflows/Sync Rules setup that move 10,000+ objects around successfully based on our logic between AD/FIM/FIM Portal/custom SQL database.
We have come across a scenario where one user record, who has been removed from the relevant Set (we only have 1 Set for this logic), still exists in the target connected system - it should have been removed.
How would we troubleshoot this scenario?
PS. I will run the orphaned ERE/DRE powershell - good idea, thanks
Friday, September 07, 2012 5:21 AM
If an object is removed/filtered/disconnected at source MA and you expect it to be removed from target MA, this is a deprovisioning scenario. You can easily configure this by combo of 'configure MV deletion rule' in MV designer and 'configure deprovisioning' in MA properties. For your scenario, it sounds like you would want the MV deletion rule for person object set to 2nd radio button and have checkbox for source MA selected.
In addition, you would need to go to target MA properties and go to 'configure deprovisioning' and select 3rd radio button.
Using these two in conjunction should make objects in target MA get removed when source object is moved/removed.
You can find out more about deprovisioning here:
Saturday, September 08, 2012 12:13 AMEchoing what Glenn has said about DREs ... don't use them/don't need them. Gave up on these ages ago when I too expected the DRE to disappear and it didn't ... in my use case I had policy which continually flip-flopped between 2 EREs (locking/unlocking users in AD) and I had to abandon the idea when I couldn't cause the DREs to go away. I now generally use a boolean property in the MV and FIM which is authoritative from the source system which I am checking, and which I ensure the "allow nulls" export flow to the FIM service is checked ON :).
Wednesday, September 26, 2012 12:09 PMThank you everyone - I will need to rethink the use of DREs in the future.