This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Accurate Token Bloat Report


I see there is a Token Bloat report which is based upon the object being in 'X' number of groups. Would it be possible to have a report created that takes in to account the number of groups the object is in (Directly and indirectly) and also the type of groups they are in as these have different values. It would also need to take in to account if there is SID History tied to the object an the groups themselves. Another consideration is whether the account is also delegated for delegation as this impacts the Token size.

An MS engineer wrote a script which is pretty accurate, but we would ideally want that criteria reporting off of the Quest data already captured, but taking in to account the same considerations.



  • Hello Adam,

    Thanks for the request. I'll have a look at the supplied script and see what we can do to make a custom report which takes into account more of the things which effect the token bloat.

    By the way, which version of ER do you have, 3.0?
  • Hi Peter,

    Much appreciated. Yes, we are running version 3.0 of ER.


  • Hello,


    After a little bit of work, I have an approximation of the actual token size.  The script you referenced makes use of some logic which decide what the max token size should be which was not done.  instead I sort descending the token size, so the accounts at the top are the most likely to  have token bloat.


    Now for the caveats: the PowerShell script uses the Token Groups property for each user.  ER does not collect that field, so instead I have to use the group collections.  This means that if an user/group is added as a member of a group from another domain, Those foreign groups will only be included in the calculation if ER has collected those Domains.  Through my testing, I have some users which return the same results as the PowerShell script and others which are wildly off due to collections which have not happened.


    Alternate TokenSize

  • Hi Peter,

    Thanks for coming back to me. We areonly looking at a Single forest/Single Domain without trusts so this is fine. However, I don't understand your schema so just want to check a few things. Does this include Global Groups? Only seeing a reference for universal and Domain Local (I think) - also, does this include only Security Groups? The token Sizes I am seeing don't match up.


  • There are 3 types of groups I am checking, universal (Internal and external), Domain Local and global (type 'D' in Reporter's DB). I'm also adding in the Sid history for the groups and the account itself. I do see that I am not filtering out distribution groups, so yes, my number can be larger in those case.

    I guess there is another potential for differences. when executing the Powershell script, the script uses the TokenGroups attribute as I had mentioned, which may return 5 special built-in groups (Network, Interactive, remote interactive Logon, etc) these groups have memberships which are dynamic and are not enumerable by ER, so they don't get included in the calculation. As such, the numbers in the script can be off by a small number of bytes.

    How close are your numbers?
  • The numbers i get are actually smaller than that of the script, by a few hundred or so - this would likely be the built in groups etc as you say. Is there a possibility that ER can be extended to capture TokenGroups?

    I would say the numbers are more accurate than the other Report available based on the group count for sure. Is there a field we can filter by to exclude distribution groups? GroupType maybe?

    Only other amendment i made was that the EstimatedTokenSize column didn't have an "As" statement on the Select statement, so wasn't showing in the CSV.

    Appreciate your help Peter.
  • Adam,

       Because you seem to be fine with updating the SQL in the report and because I don't know what the exact changes you may have made, you can update the SQL to filter out the distribution groups from the calculations.

    2/3rds of the way down there is an "insert into @USERsGroups" statement which ends in "AND ( du.LDM_TOMBSTONED = 0 )"

    On a new line add to the Where clause

    AND dg.IsSecurityEnabled = 1

    otherwise tell me what exactly what change you made and I can update the report.


    As for TokenGroups, that field cannot be extended within Report.






  • Hi Peter,

    Thank you, That filtered out the Distribution groups and has shrunk the estimated token size. It is off still slightly, but i am guessing this is built in groups etc as you have said.

    If the Token Groups is something you can potentially have raised as a feature request in a later release, that would be handy.

    Thank you very much for the report.

  • Hello Adam,

    I am very happy to see that Peter was able to help you with this report.

    I have logged an enhancement request for Token Groups. It will be considered for a future release of Enterprise Reporter. Tracking number is: VSTS019904

    Thank you,
    Enterprise Reporter Development Manager
  • Excellent, thanks Angela, appreciated.