I am curious if this is my issue, a defect, or something else. I am using PowerShell to connect to CME via core-service and load all users (excluding the "predefined" users). I get the user objects, but some of the properties are null. Most importantly, the Privileges property is null, even for users I know are system administrators. in fact, if I fetch such users specifically by ID, the object returned has that property set. But, when fetching them all, it doesn't. Here's how I'm loading the list.

$filter = New-Object Tridion.ContentManager.CoreService.Client.UsersFilterData
$filter.IsPredefined =$false
$client = Get-TridionCoreServiceClient
$allUsers = $client.GetSystemWideList($filter)
$allUsers | Format-Table -Wrap

I did test adding this line:

$filter.BaseColumns = 3

That didn't seem to make a difference. I also used a foreach over the items in case Format-Table was the issue.

foreach ($user in $allUsers)
    Write-Host $user.Id
    Write-Host $user.Title
    Write-Host $user.Privileges

That didn't make any difference either. Am I missing something to indicate that I want the entire user object?

2 Answers 2


This isn't specific to PowerShell. That data is simply not loaded when getting a list of users. As you might have guessed, it's for performance reasons (both time and bandwidth).

The BaseColumns flag is a generic parameter and each list supports it differently. It's fair enough to suggest that Extended could return this data, but that is not currently the case.

So yes, I'm afraid you will need to load the users individually -- or work around it in other ways. If this is a one-time thing, I'd just load them. If you regularly need to know who is an admin and who is not, I would implement an event system that sets some application data when a user is saved (don't forget to clear it when the user is no longer an admin) and then use that data instead of the regular list of users to get a list of administrators.

  • Thanks. I figured it wasn't really a PowerShell thing, but I mentioned the approach just in case it did (and to make my code somewhat sensible). I have implemented it by calling all users one at a time. unfortunately for me on a VPN that takes 5-10 minutes to run. but such is life. I am requesting an enhancement (or documentation fix) that Extended should get the whole object. that is what it implies... :) Commented May 19, 2014 at 18:42
  • I also only mentioned that it wasn't specific to PowerShell in case someone else runs into it (so they don't dismiss the answer as not applicable without reading it :)). I totally agree that it would be handy if it took the Extended flag into account so that you don't have to load all the users to get a list of administrators. Hopefully it will be added in a future version. Commented May 20, 2014 at 5:39
  • I opened ER 88020 through SDL support. hopefully for a change some day... :) Commented May 22, 2014 at 15:28

In case of doubt always call GetSystemWideListXml method. If it's there in Xml - it will be in data objects as well. You set BaseColumns.Extended, so everything seems to be right. I guess it's omitted for performance reasons as each user can have quite a few privileges. You may always re-read users you are interested in.

  • Great suggestion. I did that, and... same information returned there. So, it's for some reason excluding that data. Unfortunately my use case is to get a list of all users that are system administrators, so I can't filter that. I'll have to go re-fetch every user once I get the list of user Ids. That's quite a poor way of doing things. You'd think if I explicitly set BaseColumns.Extended that it would return everything, regardless of performance implication. :( Commented May 15, 2014 at 13:54
  • Aren't you getting whether user is admin or not in the list? Commented May 15, 2014 at 13:59
  • No. it's not in the results from GetSystemWideListXml. I did this, to output the XML of each node and each one only has ID, Title, Icon, Description, IsPredefined, Enabled. $allUserXml = $client.GetSystemWideListXml($filter) foreach ($node in $allUserXml) { Write-Host $node } Commented May 15, 2014 at 14:11
  • I see, at least you can ignore predefined and disabled users Commented May 15, 2014 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.