Large number of DirXML-EntitlementResult values

Wanted to share something important with the people reading this and getting it into the Google cache.

We had a customer with huge numbers of DirXMl-EntitlementResult values on users.

By huge I mean 800 with more > 1000 values. Some had over 10,000 values. It was pretty terrible.

This was actually causing eDir sync issues and we were getting strange 625 and 626 errors.

Support was succesful in nailing it down to these crazy # of values as the replication issue.

Really good news is that   from the forums here has an awesome tool Console2, that has a Multiple Value Report subtool, that allows you to find all users with more than N number of values. 

I tried checking for more than 25, and this customer had 22,000 users!  Over 1000 found almost 800!  Crazy crap. One user had 16,000 values, and each one was 18K in size, which is madness.  You can imagine how hard replicating that might be.

Console2 generates an LDIF as the output to clean up as well. (That guy thinks of everything!).

The real fix has been in the User App driver since 4.0x (2.2.0 package at least) and is a GCV called

dirxml.engine.entitl-rs-purge-type

 

This default to Current which seems to do nothing.  Switch it to either previous (keeps this and the one just before it) or notnewer which keeps any future timestamped ones and nothing earlier.

Then each time a user passes through the UA for this attribute it will clean up. 

Use Alekz's tool to clean up the terrible users, and let the system clean up over time the rest.  If you do not yet use Console2, then you are just not doing IDM correct.  This is the single most useful IDM tool I have found.  well done indeed Alekz. 

Go to http://sneakycat.biz to download a copy and get a license.

 

  • Don't you think that if you have a product architecture that uses eDirectory for storing all this information, and other RBPM attributes, that it should be able to handle it? The root cause should be fixed, i.e. why can't the database handle the values and replicate them instead of us spending time cleaning values...
  • Agreed. And it was only when it got really bad that it got in trouble.  Which suggest an upper limit on eDir replication abilities.  10,000 value of 18K on users.  Not good, but not common either.

  • I changed the gcv to "previous" and restarted the UA driver. Then i removed a user from a role that has an associated resource with an entitlement. Expecting to see this magical cleanup, I checked eDir. No change to dirxml-entitlementresult. In fact, I don't even see an event in the UA driver trace set to level 3.

    Am I missing a step here? It very well may be the case because I have never fully understood the purpose of the UA driver.

  • There needs to be a ITP XSLT style sheet called PurgeEntitlements or some such.

     

    The filter needs to be Sub-Sync on User with the DirXMl-EntitlementResult attribute Sub Sync.

    What happens is that in the shim, (which is built in Composer for IDM, which was such a super cool project that alas died, and I miss dearly, it was a tool to build drivers!  Part of Silverstream, and there were license agreements that expired and could not be renewed. Alas and alack) it sees an event, and then reads back all the current values of the user, and then compares the current value to them.  In previous, if the <attr> for this one is not the current not, it deletes it.  Sends a strange XML doc that the XSLT reformats to a remove-value in a modfy.

    So if no filter, no event to the shim to send the remove command.

    If not XSLT no conversion to modify and remove-value.

    If you are not sure, in Designer drop any UA driver into a test tree since 2.20 at least (I did not go back earlier, but that is iDM 4.01 or 4.02 so shoucl be far enough back and 10 years old at leeast!) and look at what it has and see if you are missing in your system.