Skip to content

Get-MgGroupMember seems to ignore the -PageSize argument #3325

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
plmcgrn opened this issue May 14, 2025 · 0 comments
Open

Get-MgGroupMember seems to ignore the -PageSize argument #3325

plmcgrn opened this issue May 14, 2025 · 0 comments
Labels
status:waiting-for-triage An issue that is yet to be reviewed or assigned type:bug A broken experience

Comments

@plmcgrn
Copy link

plmcgrn commented May 14, 2025

Describe the bug

When calling this function with -PageSize 999, it's pretty obvious that it is ignoring that and still using the default of 100. In my test case, I'm getting the membership of a group that contains about 3000 people. This should take 3 API calls, but instead takes 30. This is my inference based on the lag/delay of the response taking 30 seconds, vs. a few seconds.

Expected behavior

Respect the -PageSize argument, perform better than 10 seconds for a single command

How to reproduce

$group = Get-MgGroup -Filter "DisplayName eq 'group_name'"

Write-Output "Measuring with page size 999"
Measure-Command {
    $members = Get-MgGroupMember -GroupId $group.id -All -PageSize 999
}

Write-Output "Measuring with page size 100"
Measure-Command {
    $members = Get-MgGroupMember -GroupId $group.id -All
}

Write-Output "Member count: $($members.Count)"

As you can see, the duration of this API call is nearly the same, regardless of page size.

Measuring with page size 999
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 27
Milliseconds      : 721
Ticks             : 277210859
TotalDays         : 0.00032084590162037
TotalHours        : 0.00770030163888889
TotalMinutes      : 0.462018098333333
TotalSeconds      : 27.7210859
TotalMilliseconds : 27721.0859

Measuring with page size 100
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 31
Milliseconds      : 812
Ticks             : 318127965
TotalDays         : 0.000368203663194444
TotalHours        : 0.00883688791666667
TotalMinutes      : 0.530213275
TotalSeconds      : 31.8127965
TotalMilliseconds : 31812.7965

Member count: 2945

SDK Version

2.17.0

Latest version known to work for scenario above?

No response

Known Workarounds

No response

Debug output

Click to expand log

The logging output is all sensitive since I'm fetching lists of users, and too large for this input

Configuration

MacOS 15.4.1, though able to reproduce the lag with same module version on Windows 11.

Name                           Value
----                           -----
PSVersion                      7.5.1
PSEdition                      Core
GitCommitId                    7.5.1
OS                             Darwin 24.4.0 Darwin Kernel Version 24.4.0: Fri Apr 11 18:33:39 PDT 2025; root:xnu-114…
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Other information

I am unable to determine if this sluggishness is due to the module ignoring -PageSize or due to the Graph API just being too slow for this type of command. Like maybe -PageSize 999 still requires the server to internally fetch in chunks of 100, synchronously, then chunks those responses back to me in the chunks of 999?

@plmcgrn plmcgrn added status:waiting-for-triage An issue that is yet to be reviewed or assigned type:bug A broken experience labels May 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:waiting-for-triage An issue that is yet to be reviewed or assigned type:bug A broken experience
Projects
None yet
Development

No branches or pull requests

1 participant