对于本地 Azure DevOps，从一个环境移动到另一个环境

项目
04/03/2024

Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019

最常见的基于环境的移动方案是更改Azure DevOps Server部署的域，无论是域名更改还是从工作组转到域。

重要

在某些情况下，可能需要更改Azure DevOps Server部署的域及其硬件。更改硬件是基于还原的移动，请勿合并两个移动类型。首先完成硬件移动，然后更改环境。

此外，更改Azure DevOps Server中的标识作为环境移动的一部分是最常导致冲突或问题的方面。 Identities 命令是一个功能强大的工具，但它有一定的限制。作为计划移动的一部分，请阅读该工具的相关限制。若要帮助确保移动成功，请确保您了解下列要求：

在Azure DevOps Server中存在用户帐户后，无法将其删除或将另一个帐户映射到该帐户。例如，如果要将 DomainA/UserA 移动到 DomainB/UserB，则只有在 DomainB/UserB 尚不存在于Azure DevOps Server时，Identities 命令才能迁移用户。
由于本地管理员组的成员会自动添加到Azure DevOps Server，因此在更改域或环境之前，请确保删除要从该组迁移的任何帐户。

有关进一步的背景信息，请转到此处，详细了解Azure DevOps Server中标识更改的工作原理，包括工具的限制。

我们将在以下部分中逐步完成更改Azure DevOps Server部署环境的步骤：

检查权限和帐户
停止Azure DevOps Server服务
备份数据
将Azure DevOps Server加入其新域
移动Azure DevOps Server用户和服务帐户
配置 Reporting Services 和 Analysis Services
重启Azure DevOps Server服务

检查权限和帐户

若要成功更改Azure DevOps Server的环境，你需要是本地计算机上的管理员，以及Azure DevOps Server以及部署所依赖的所有软件的管理员：SQL Server、报告以及部署与之互操作的任何其他软件，例如 Project Server。但是，本地管理员组的所有成员都会自动包含在Azure DevOps Server中，这可能会在尝试迁移帐户时出现问题。因此，您应使用无需作为环境移动一部分迁移的帐户。您可能会考虑为了移动添加一个特殊的管理帐户，并使用该帐户执行迁移。

验证管理员级别的权限

确保您要使用的帐户是下列组的成员：
- 服务器：Administrators（本地管理员组或权限相同者）
- Azure DevOps Server：Team Foundation 管理员和管理员控制台用户
- SQL Server：sysadmin

如果你不是其中一个或多个组的成员，请立即获取权限。

既然您确定要使用具有所有必需权限的帐户，那么现在可以检查帐户，看看您将迁移到的环境中是否存在任何名称或组冲突。我们已经知道作为本地 Administrators 组的成员的帐户无法迁移，那么让我们先删除这些帐户。

删除要从本地 Administrators 组迁移的帐户

打开本地 Administrators 组，然后删除要迁移到新环境的所有帐户。对可能受影响的任何其他组重复此步骤。

现在，检查当前Azure DevOps Server环境中的标识列表，并查找新环境中可能存在的组或单个用户帐户的任何潜在问题。

提示

请考虑为要作为环境移动一部分移动的标识创建一个表或一个迁移映射，包括可能无法自动迁移的帐户的详细信息。

检查标识

在 Azure DevOps 应用程序层服务器上，打开具有管理权限的命令提示符窗口，导航到 %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools，然后运行以下命令以查看系统中当前标识：
```
TFSConfig Identities
```
标识的列表将显示。检查这些用户和组，确保Azure DevOps Server要移动到的环境中的标识不存在潜在的重复项或问题，并采取措施缓解任何潜在的冲突。

停止服务

停止服务可帮助确保用户不能在移动过程中或完成后更改工作项或将源代码签入原始部署中。

在应用程序层计算机上，打开命令提示符窗口，并将目录更改为 Drive：\%programfiles%\TFS 12.0\Tools。
键入以下 TFSServiceControl 命令：

TFSServiceControl quiesce

备份数据库和 SQL Server Reporting Services 加密密钥

打开用于Azure DevOps Server的管理控制台，然后在“计划的备份”页上执行完整备份。该备份将备份你在备份计划中对备份进行的任何配置，但它将立即执行此操作，而不是根据计划的时间执行。如果你的部署使用报告，则可将加密密钥备份为该备份集的一部分进行备份。

(如果未配置备份，则必须创建计划，然后才能执行完整备份。)
完成备份后，请验证该备份在存储设备或网络共享中是否可用，以及你是否可从新硬件访问此备份。

将应用程序层服务器加入其新域

在每台服务器上，打开计算机的“属性”。
将计算机的设置更改为您要将服务器加入到的域或工作组。

如果系统提示您提供有权将此计算机加入到域的帐户的用户名和密码，请提供相应的凭据。
重新启动计算机以使域更改生效。

注意

重新启动计算机后，可能会显示一条警告，指示服务或驱动程序无法启动。请继续下一个过程。

移动用户帐户和服务帐户

如本主题开头所提到，移动帐户是您最可能遇到问题的情况，特别是您未仔细计划用户迁移时。 TFSConfig Identities 命令无法将任何帐户迁移到Azure DevOps Server中已存在的帐户。

如果两个域中的帐户名称相同，并且唯一不同的是域名，则您可使用 TFSConfig Identities 的批处理模式一次性更改所有标识。否则，您必须逐个更改标识并指定不同的目标帐户名称，如下详述。

在 Azure DevOps 应用程序层服务器上，打开具有管理权限的命令提示符窗口，导航到 %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools，并运行以下命令，将服务帐户的服务 ID (SID) 更改为新域：
```
TFSConfig identities /change /fromdomain:OldComputerorDomainName /todomain:NewDomainName /account:OldTFSServiceAccount /toaccount:NewTFSServiceAccount
```
警告

如果服务帐户是系统帐户（如 Network Service），则您无法直接迁移服务帐户，因为新环境中存在具有相同名称的系统帐户。您将必须执行一个两阶段过程更改。请参阅 Identities Command 中的示例。
若要迁移在新环境中具有相同名称的所有帐户，请键入以下命令：
```
TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName
```
这将对帐户执行批处理。
如果新域包含一个或多个标识，其中名称在环境之间发生更改，则需要手动更新每个标识的 SID。例如，如果 Christie Church 的用户帐户在上一个环境中为 Fabrikam\CChurch，但在新环境中为 NewFabrikam\ChristieC，则您必须手动更新她的 SID。对于具有此要求的每个帐户，请键入以下命令：
```
TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName /account:OldAccountName /toaccount:NewAccountName
```

现在运行以下命令以更新服务帐户：

TFSConfig Accounts /change /AccountType:ApplicationTier /account:AccountName /password:Password

如果您的部署使用报告，请运行以下命令以更新用于报告的数据源帐户：

TFSConfig Accounts /change /AccountType:ReportingDataSource /account:AccountName /password:Password

如果部署使用 Azure DevOps 代理服务器，请运行以下命令以更新用于代理的服务帐户：
```
TFSConfig Accounts /change /AccountType:Proxy /account:AccountName /password:Password
```
注意

如果要移动到不受信任的域，可能还需要手动将用户和组添加到团队、项目、集合和Azure DevOps Server本身。有关详细信息，请参阅将用户添加到项目、设置项目集合的管理员权限和为Azure DevOps Server设置管理员权限。
如果您的部署与 Project Server 集成，则可能需要执行其他步骤来为服务帐户配置操作所需的权限。有关详细信息，请参阅分配权限以支持 TFS-Project 服务器集成和配置TFS-Project Server 集成。

配置 Reporting Services 和 Analysis Services

如果您在部署中不使用报告，则可跳过此过程。

如果重命名了报表服务器作为此类型移动的一部分，则必须将Azure DevOps Server重定向到报表服务器的新位置。您还必须重新启动仓库并手动为 Analysis Services 重新生成数据库。

打开 Azure DevOps 管理控制台，转到“报告”节点，然后编辑设置。
更改全部三个选项卡上的值，以便它们包含服务器的新名称。确保为新环境中的数据源帐户提供正确的信息。
选择 “启动作业” 以重启报告。
选择 “开始重新生成” 以重新生成仓库。

配置备份

如果网络共享名或存储设备随域名的更改而更改，则需要更新已计划的备份计划，以指向这些重命名的资源。

在管理控制台中，转到“计划备份”节点并重新配置计划备份，以备份新服务器上的Azure DevOps Server数据库。有关详细信息，请参阅Create备份计划和计划。

重新启动服务

现在，你已使用新环境的所有信息更新了Azure DevOps Server，请重启服务。

在Azure DevOps Server应用程序层计算机上，打开具有管理权限的命令提示符窗口，并将目录更改为 Drive：\%programfiles%\TFS 12.0\Tools。
键入以下 TFSServiceControl 命令：

TFSServiceControl unquiesce

问题解答

问：我要为部署更改一台或多台物理服务器，而不是域。我是否可以执行此操作？

答: 是的。这称为基于硬件的移动，在从一个硬件移动到另一个硬件或克隆中提供了这些步骤。你不应尝试将基于环境的移动与基于硬件的移动合并。先完成硬件移动，然后再更改环境。

通过