维护准确的 Entra ID 用户帐户经理链接

许多 Microsoft 365 功能需要准确的用户管理器链接

过去，我曾写过标准化用户帐户创建过程的重要性，以便帐户属性最终完全填充部门、经理等属性。虽然在创建时确保帐户属性准确相对容易，但随着时间的推移，除非采取措施验证和纠正 Entra ID 用户帐户管理器链接中的错误，否则几乎不可避免地会出现不准确的情况。 PowerShell 在这方面非常有用，因为识别帐户数据问题的脚本很容易编写。

经理与员工的关系可能是最难管理的更新。汇报关系的变更常常在 IT 部门不知情的情况下发生。这些都是 HR 的问题，除非 HR 通知 IT 需要更新 Entra ID，否则目录将保持不变并逐渐陷入不准确的状态。

目录准确性很重要的原因是 Microsoft 365 在多个位置突出显示组织结构图，例如 Teams（图 1）、Microsoft 365 用户配置文件卡和 Outlook for Windows 中的组织资源管理器（需要 Viva Suite 许可证）。

显然，如果 Entra ID 保存的报告关系信息不准确，则应用程序生成的图表将会产生误导。这是一个应该解决的问题。

大型组织往往拥有复杂的人力资源系统，其中可能包括 Entra ID 的反馈，以处理报告关系、部门、电话号码、物理位置等变化。但让我们假设我们的组织不拥有这样的提要。相反，我们需要想出一种方法来复制人力资源信息源可用时可能发生的情况。

定义可能的解决方案

勾勒出我们可能开发的解决方案，我提出了以下建议：

• 人力资源部定期更新有关经理及其部门的信息，包括每个部门的二级经理。在本练习中，我们将使用名为 c:\temp\ManagerData.csv 的 CSV 文件来保存此数据。
• PowerShell 脚本读取 HR 信息并检查每个用户帐户，以根据分配给该帐户的部门更新经理。如果用户是部门经理，则脚本会更新 2 级经理的帐户。由于需要放弃旧的 Azure AD 和 MSOL 模块，因此我们将使用 Microsoft Graph PowerShell SDK 中的 cmdlet。

简单的。该脚本可以交互运行，但在生产环境中，更有可能使用 Azure 自动化 Runbook 等内容按计划运行脚本。

像 LiveTiles Directory（以前称为 Hyperfish）这样的商业目录维护解决方案可以更优雅、更全面地完成这项工作，但编写一个自制的解决方案会更有趣。你可以从 GitHub 下载我写的脚本。一如既往，我们编写的脚本是为了说明原理，而不是功能齐全的解决方案。请根据需要使用该脚本。

编写解决方案脚本

该示例脚本经历了几个阶段来查找用户帐户、找出要分配的正确部门经理并最终更新帐户。以下是所发生情况的概述。

首先，脚本从 HR 读取有关部门经理的信息。由于数据位于 CSV 文件中，因此只需使用 Import-CSV cmdlet。然而，该脚本可能需要处理数千名员工，因此需要快速访问数据。因此，该脚本将部门名称和经理（用户主体名称）加载到哈希表中。如果脚本检测到管理数据中存在任何错误，它会标记错误并停止。

接下来，脚本找到要处理的用户帐户集，用户帐户并不总是与可能拥有经理的真实人员相关联，因此要排除用于房间和共享邮箱以及来宾帐户等的帐户，脚本使用高级使用 Get-MgUser cmdlet 根据 Entra ID 进行图形查询，以查找至少拥有一个已分配许可证的帐户。像这样过滤 Get-MgUser 的输出是一个非常有用的命令，您最终可能会在许多脚本中使用它：

Write-Host "Finding licensed user accounts..."
[array]$Users = Get-MgUser -All -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable UsersFound | Sort-Object DisplayName
If (!($Users)) { Write-Host "Couldn't find any user accounts with assigned licenses!" ; break }

获取用户帐户集后，脚本将帐户分为已填充部门属性的帐户和未填充部门属性的帐户。显然，该脚本只能处理部门帐户，因为它使用该属性来查找经理。同时，意识到生活是不完美的，脚本会读入默认经理，以便在无法匹配部门时使用：

[array]$UsersNoDepartment = $Users | Where-Object {$Null -eq $_.department}
[array]$UsersWithDepartment = $Users | Where-Object {$Null -ne $_.department}
# Get default manager to assign people to when we can't find a department manager
$DefaultManager = $ManagerData | Where-Object {$_.Department -eq "Default" } | Select-Object -ExpandProperty Manager

脚本的下一部分重点是确定为用户帐户分配哪个管理员。如果使用用户帐户的部门值对哈希表的查找成功，我们就知道要分配哪个经理。某些条件处理处理用户是部门经理的情况。此代码的存在是因为 Microsoft 365 允许用户成为自己的经理，这在现实生活中并不常见。另一项针对首席执行官帐户的检查存在，该帐户没有经理，因为他们位于组织的最高层。

确定要分配给用户帐户的经理后，脚本会检查该帐户是否已存在该经理。为此，该脚本运行Get-MgUserManager cmdlet，并将经理的用户主体名称的值与当前部门经理的用户主体名称进行比较。如果两者匹配，脚本将不会尝试更新帐户。

$UserManager = (Get-MgUserManager -UserId $User.Id -ErrorAction SilentlyContinue).additionalProperties.userPrincipalName
 If ($DepartmentManager -eq $UserManager) {
    # Same manager, so don't update
    $DepartmentManager = $Null 
}

最后一步是脚本调用 Set-MgUserManagerByRef cmdlet 来更新帐户。该 cmdlet 通过引用进行操作，这意味着输入引用另一个对象（部门经理）。该 cmdlet 接受由其对象标识符或用户主体名称（如本示例中所使用）标识的目标对象。代码的作用如下：

Write-Host ("Updating user account {0} with manager {1}" -f $User.displayName, $DepartmentManager)
$ManagerId = ("https://graph.microsoft.com/v1.0/users/{0}" -f $DepartmentManager) 
$NewManager = @{"@odata.id"=$ManagerId}
Set-MgUserManagerByRef -UserId $User.Id -BodyParameter $NewManager

作为输出，该脚本会生成一份有关其处理的管理更新的报告。该脚本将输出导出为 CSV 文件，并通过 Out-GridView cmdlet 显示详细信息（图 2）。

该脚本还会注明是否发现任何没有部门属性的帐户。

比预期稍微复杂一点

当我开始编写示例脚本时，我认为代码最终会达到 40 行左右。最终的脚本大约是这个的两倍（没有任何错误处理），这再次证明了我在估算任务时的无能。了解如何使用 PowerShell 处理管理任务是一件好事。除此之外，本练习还演示了 Get-MgUserManager 和 Set-MgUserManagerByRef cmdlet 的使用，您可能需要这些 cmdlet 来升级使用最终版本的脚本：已弃用 AzureAD 和 MSOL 模块。

Microsoft 平台迁移规划和整合

最大限度地降低与下一次 Exchange Online 域转移相关的风险、时间、成本和复杂性