使用Graph API与PowerShell获取含EmployeeID的指定域Azure AD用户异常问题

以下是几个关键排查方向：

• 检查Filter参数的语法与编码
  Graph API的$filter需要严格遵守OData语法，同时PowerShell中特殊字符可能需要编码。正确的筛选逻辑应同时匹配邮箱后缀和存在EmployeeID：

  # 构造筛选条件
  $filterCondition = "endsWith(mail,'@gmail.com') and employeeId ne null"
  # 对筛选条件进行URL编码，避免特殊字符导致参数失效
  $encodedFilter = [System.Web.HttpUtility]::UrlEncode($filterCondition)
  

  注意参数名必须是$filter而非filter，同时逻辑运算符and需正确使用。

• 确认请求URL的参数传递方式
  PowerShell中$是特殊变量符号，直接写在URL里会被解析，需用反引号转义或单引号包裹URL：

  # 方式1：用反引号转义$符号
  $uri = "https://graph.microsoft.com/v1.0/users`?$filter=$encodedFilter&`$orderby=displayName"
  # 方式2：用单引号包裹URL，避免$符号被解析
  $uri = 'https://graph.microsoft.com/v1.0/users?$filter=' + $encodedFilter + '&$orderby=displayName'
  

  调用Invoke-RestMethod时，确保通过-Headers正确传递Bearer令牌：

  $token = "你的有效访问令牌"
  $response = Invoke-RestMethod -Uri $uri -Headers @{Authorization = "Bearer $token"} -Method Get
  

• 对比Postman与PowerShell的请求差异
  用PowerShell的-Debug参数查看实际发送的请求详情，或用抓包工具对比Postman的请求：

  Invoke-RestMethod -Uri $uri -Headers @{Authorization = "Bearer $token"} -Method Get -Debug
  

  重点检查：

  • 请求URL中的$filter参数是否和Postman完全一致
  • 请求头中的授权令牌是否有效、权限范围是否匹配（需包含User.Read.All或Directory.Read.All）

• 排查分页与返回结果的完整性
  Graph API默认每页返回100条数据，若结果超过100条需通过@odata.nextLink分页获取，但如果第一页就返回未筛选的全部用户，说明筛选参数未生效，而非分页问题。可直接查看响应的value字段，确认是否包含不符合条件的用户。

内容的提问来源于stack exchange，提问作者Dev Reddy