ADWS parameter MaxGroupOrMemberEntries

  • Last Post 26 January 2017
barkills posted this 31 July 2015

By default, ADWS restricts several of the AD cmdlets, like Get-ADGroupMember, to returning a mere 5,000 member entries. Which is annoying when you have larger groups, like we do.  We’d like to bump that limit, as described here:   We’re wondering two things: 1.      Does anyone else have any experience good or bad, in doing this? I’m aware of a couple threads in the PowerShell forum about this topic that touch on the session time limit and creative workarounds for the odd limitation of the 3 PS cmdlets this configuration setting affects. [Note to any product team member reading this: the fact that some PS cmdlets are not affected by this limitation points to inconsistent design thinking, and I’d argue you should consider fixing this so it is consistent.] 2.      On a WS2012R2 DC, we see no hint of the MaxGroupOrMemberEntries in the XML config file. It seems to be the only default setting called out in the URL which is not present in the XML config file. It being an XML file and this being the only documentation we can find, that is a bit problematic in terms of actually changing the default value. Does anyone have more information that’d help us with this issue?   Thanks,   Brian Arkills

barkills posted this 26 January 2017

No one ever responded to my email 18+ months ago, so I’m responding to my own post for the general benefit of everyone. ;)


I ran into this annoying limitation again recently, and after a bit of fresh research found, as someone who actually did make the limit change and had specific syntax to make the change, although there is no real report on impact.


I went ahead and changed this ADWS limit to 200000 on one of our DCs and re-ran my PS script against that DC. One of many large groups had a timeout (as might occasionally be expected due to other load), but

otherwise there was no significant impact (to the DC) and I didn’t have to use the awkward & annoying workarounds of:

$members = Get-ADGroup <groupname> -properties Member | select-object -expandproperty member


(Get-ADGroup <groupname> -properties members).members | Get-ADUser -properties samAccountName | Select-Object samAccountName


$group =[adsi]”LDAP://CN=Group1,OU=Groups,DC=msad”

$members = $group.psbase.invoke("Members") | foreach {$.GetType().InvokeMember("name",'GetProperty',$null,$,$null)}


As a domain which has large groups, we seem to run into quite a few Microsoft design constraints, and after trying this in a large AD at 40 times the existing limit, I’m not sure I really understand why Microsoft

chose such a low number, although I guess it is because of customers which run DCs on underpowered hardware. Speaking of other design constraints, I hope Microsoft fixes Azure AD Connect’s group member limitation. Clearly AAD Graph API has no member constraint

so this seems to be a database/MIM sync engine issue.


Anyhow, I hope this info is helpful to others.