我遇到了实验室管理和标准环境的安全问题。
我在我的域“DevDomain”中安装了 TFS2012 更新 2。我在“DevDomain”中也有一个单独的构建/实验室机器，其中安装了同一集合“CollectionA”的构建控制器、构建代理和测试控制器。
自动化构建工作完美。
我在“DevDomain”和“TestDomain”中有部署目标 PC（稍后会详细介绍）。
为了更上一层楼，我现在想自动部署 TFS 构建代理构建的软件来测试钻机；具体来说，我想让一个部署脚本卸载现有产品，将更新的安装程序复制到目标 PC 上，然后安装它。
我的第一次尝试是在我的“DevDomain”中定义一个标准环境，并让实验室构建的部署部分在同一个域中工作。
这行得通。这就是我所做的；
自动构建（使用 DefaultTemplate.xaml 进程）创建一个我想用于部署的 MSI 文件，以及一个我想运行以协调部署的 PowerShell 脚本。（脚本只是尝试通过 msiexec 运行 MSI 来卸载，在本地复制新版本，然后通过 msiexec 运行它来安装新副本）。自动构建很高兴地制作了这两个工件并将它们放入定义的 TFS 丢弃共享中。
为了解决这个问题，我有：
- 使用单台机器创建了一个新的标准实验室环境（桌面客户端角色）
- 实验室经理已成功将代理部署到此 PC
- 代理正在交互式运行并在线显示。
- 使用 LabDefaultTemplate.11.xaml 工作流创建了一个新的构建定义。
- 在配置中引用了上述实验室
- 在配置中引用了自动构建的最新输出
- 指定构建输出 PowerShell 脚本（通过 $(BuildLocation) 宏。
构建的此部署选项卡指定要在具有“桌面客户端”角色的实验室机器上运行以下脚本：
cmd /c powershell.exe "$(BuildLocation)\DeployGuiToLabWorkstation.ps1" "$(BuildLocation)"
这行得通。
请注意，我将测试代理配置为作为交互式进程运行，因为在部署工作之后我的最终目标是在这些实验室上驱动编码的 UI 测试。
当尝试部署到不同域中的机器时，问题就开始了 现在为了使这更现实，我现在需要为我的 QA 机器定义一个标准实验室环境，它们位于不同的域中；“测试域”。
域“TestDomain”与域“DevDomain”具有信任关系。“DevDomain”和“TestDomain”之间没有相互信任
测试管理器实验室中心再次定义了这个 OK 并部署了代理，代理在线向我的测试控制器报告了自己。
现在，当我更改实验室构建以引用新的标准环境（在“TestDomain”上）时，部署失败并出现此错误；
Exception Message: Team Foundation Server could not complete the deployment task for
machine '10.7.70.71', script 'cmd' and arguments '/c copy \\*buildmachine*
\TFS_Drop\...\DeployGuiToWorkstation.ps1 C:\GuiDeploy'. (type LabDeploymentProcessException)
为了诊断这一点，我将实验室部署脚本修改为：
"cmd /c powershell whoami"
根据日志，该进程正在以“nt authority\system”的身份运行，而不是为测试代理指定的实验室环境帐户。
这解释了脚本错误；目标 PC 上的 PowerShell 无法访问 TFS 放置共享，但由于此帐户是本地计算机帐户，我无法将“TestDomain”中 PC 的计算机帐户授予“DevDomain”中计算机上的共享和 NTFS 文件夹的权限
那么如何从“TestDomain”中的机器将“devDomain”共享/文件系统的权限授予“System”服务帐户？
或者
如何让测试代理（以本地计算机管理员身份运行）在其自己的帐户上下文而不是本机系统上下文中执行部署脚本？
我难住了！
编辑：似乎测试代理 UI 在您指定的帐户中运行，但是当您以这种方式配置它时，它会使服务“Visual Studio Lab Agent Service”作为本地系统运行，您可以在服务中手动将其更改为更多适当的域帐户，然后该帐户会反映在 PS“whoami”结果中。
我现在正在调查使用 TestDomain 帐户来镜像“DevDomain”帐户的服务，以便我可以适当地设置共享权限。
这是与TFS 实验室管理部署脚本类似的场景，但由于使用测试和测试设置绕过了这一点，我特别想要部署部分的解决方案，我认为值得提出这个问题。
