Compartilhar via

Mover de um ambiente para outro para o Azure DevOps no local

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

Este artigo explica como mover uma implantação do Servidor do Azure DevOps de um ambiente para outro, como alterar o nome de domínio ou mover de um grupo de trabalho para um domínio. Movimentos baseados em ambiente são comuns quando as organizações reestruturam sua infraestrutura de TI, atualizam nomes de domínio ou consolidam recursos.

Você pode encontrar diretrizes passo a passo para preparar sua implantação, atualizar permissões e contas, parar serviços, fazer backup de dados, ingressar no novo domínio, migrar contas de usuário e serviço, configurar serviços de relatório e análise, atualizar planos de backup e reiniciar serviços.

A alteração do ambiente para o Servidor do Azure DevOps requer um planejamento cuidadoso, especialmente em relação ao gerenciamento de contas e identidades, para evitar conflitos e garantir uma transição tranquila. Este artigo fornece práticas recomendadas e instruções detalhadas para ajudá-lo a concluir a movimentação com êxito.

Importante

Em algumas situações, talvez você queira alterar o domínio de uma implantação do Azure DevOps Server e seu hardware. Alterar o hardware é um movimento baseado em restauração e você nunca deve combinar os dois tipos de movimento. Primeiro conclua a movimentação de hardware e altere o ambiente.

A alteração de identidades no Servidor do Azure DevOps como parte de um movimento ambiental é o aspecto que mais frequentemente causa conflitos ou problemas. O Comando identidades é uma ferramenta poderosa, mas tem certas limitações. Leia sobre isso como parte do planejamento de sua mudança. Para ajudar a garantir uma movimentação bem-sucedida, certifique-se de entender os seguintes requisitos:

  • Depois que uma conta de usuário estiver presente no Servidor do Azure DevOps, ela não poderá ser removida ou ter outra conta mapeada para ela. Por exemplo, se você estiver movendo DomainA/UserA para DomainB/UserB, o comando Identidades só funcionará para migrar o usuário se DomainB/UserB ainda não estiver presente no Servidor do Azure DevOps.
  • Como os membros do grupo administradores locais são adicionados automaticamente ao Servidor do Azure DevOps, remova as contas que você deseja migrar desse grupo antes de alterar o domínio ou o ambiente.

Para obter mais informações em segundo plano, consulte esta postagem no blog.

1. Verificar permissões e contas

Para alterar o ambiente do Azure DevOps Server, entre como administrador no computador local, no Azure DevOps Server, no SQL Server, no relatório e em qualquer outro software dependente (como o Project Server). Evite usar contas que você planeja migrar— os membros do grupo de administradores locais são adicionados automaticamente ao Azure DevOps Server, o que pode causar problemas de migração. Use uma conta administrativa dedicada para a mudança para evitar conflitos.

Verificar permissões no nível do administrador

  • Verifique se a conta que você está usando é um membro dos seguintes grupos:
    • Servidores: Administradores (grupo de administradores locais ou equivalente)
    • Servidor do Azure DevOps: Administradores do Team Foundation e Usuários do Console de Administração
    • SQL Server: administrador do sistema

Se você não for membro de um ou mais desses grupos, obtenha permissões agora.

Depois de confirmar que sua conta tem todas as permissões necessárias, verifique se há possíveis conflitos com nomes de conta ou grupo no ambiente de destino. Como as contas no grupo administradores locais não podem ser migradas, remova todas as contas que você planeja migrar desse grupo antes de continuar.

Remover contas a serem migradas do grupo de Administradores local

Abra o grupo administradores local e remova todas as contas que você planeja migrar para o novo ambiente. Repita esse processo para quaisquer outros grupos que possam ser afetados.

Em seguida, examine a lista de identidades em seu ambiente atual do Servidor do Azure DevOps. Identifique possíveis conflitos com grupos ou contas de usuário que já possam existir no novo ambiente.

Dica

Crie uma tabela ou um mapa de migração de identidades a serem movidas. Inclua detalhes sobre contas que não podem ser migradas automaticamente para ajudar a controlar e resolver problemas durante a mudança.

Verificar identidades

  1. No servidor da camada de aplicação do Azure DevOps, abra uma janela do Prompt de Comando com permissões administrativas, navegue até %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools e execute o seguinte comando para visualizar as identidades atualmente no sistema:

    TFSConfig Identities

Uma lista de identidades é exibida.

  1. Examine usuários e grupos para identificar identidades duplicadas ou conflitantes no ambiente de destino antes de mover o Servidor do Azure DevOps. Resolva possíveis conflitos para garantir uma migração tranquila.

2. Parar serviços

A interrupção dos serviços impede que os usuários façam alterações em itens de trabalho ou integrem código-fonte na implantação original durante ou após o processo de migração.

  1. Abra uma janela do Prompt de Comando no computador da camada de aplicativo e altere os diretórios para Drive:\\%programfiles%\\TFS 12.0\\Tools.

  2. Insira o seguinte comando TFSServiceControl :

    TFSServiceControl quiesce

3. Fazer backup dos bancos de dados e da chave de criptografia do SQL Server Reporting Services

  1. Abra o console de administração do Servidor do Azure DevOps e vá para a página Backups Agendados . Faça um backup completo para fazer backup imediato de tudo especificado em seu plano de backup. Se a implantação usar relatórios, inclua a chave de criptografia neste conjunto de backup.

    Você pode fechar a janela enquanto o trabalho é concluído

    Observação

    Se você nunca configurou backups, crie um plano de backup antes de fazer um backup completo.

  2. Após a conclusão do backup, confirme se o backup está disponível em seu dispositivo de armazenamento ou compartilhamento de rede e verifique se você pode acessá-lo do novo hardware.

4. Adicionar o servidor da camada de aplicativo ao seu novo domínio

  1. Em cada servidor, abra as propriedades do computador.

  2. Altere as configurações do computador para ingressar no domínio ou grupo de trabalho desejado.

    Se solicitado, insira as credenciais de uma conta com permissão para ingressar o computador no domínio.

  3. Reinicie o computador para aplicar a alteração de domínio.

    Observação

    Após a reinicialização, você poderá ver um aviso de que alguns serviços ou drivers não puderam ser iniciados. Você pode continuar com segurança com o próximo procedimento.

5. Mover contas de usuário e contas de serviço

A migração de contas geralmente é a parte mais desafiadora da alteração de ambientes, especialmente se você não planejou a migração de usuário com cuidado. O comando Identidades TFSConfig não pode migrar uma conta para uma conta de destino que já existe no Servidor do Azure DevOps.

Se os nomes de conta forem idênticos em ambos os domínios (com apenas o nome de domínio diferente), você poderá usar o modo em lote de Identidades TFSConfig para atualizar todas as identidades de uma só vez. Se os nomes de conta forem diferentes entre ambientes, você deverá atualizar cada identidade individualmente e especificar o novo nome da conta de destino, conforme descrito abaixo.

  1. No servidor da camada de aplicativo do Azure DevOps, abra uma janela do Prompt de Comando com permissões de administrador. Navegue até %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools e execute o seguinte comando para atualizar o SID da conta de serviço para o novo domínio:

    TFSConfig identities /change /fromdomain:OldComputerorDomainName /todomain:NewDomainName /account:OldTFSServiceAccount /toaccount:NewTFSServiceAccount

    Aviso

    Se sua conta de serviço fosse uma conta do sistema (como o Serviço de Rede), você não poderá migrá-la diretamente porque existe uma conta do sistema com o mesmo nome no novo ambiente. Você precisa seguir um processo de dois estágios. Veja o exemplo no Comando Identidades.

  2. Para migrar todas as contas com o mesmo nome no novo ambiente, execute:

    TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName

    Esse lote de comandos processa as contas.

  3. Se o novo domínio contiver identidades com nomes diferentes entre ambientes, atualize manualmente os SIDs para cada um. Por exemplo, caso a conta de Christie Church fosse Fabrikam\CChurch no ambiente antigo e seja NewFabrikam\ChristieC no novo, atualize o SID deles da seguinte maneira:

    TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName /account:OldAccountName /toaccount:NewAccountName

  4. Atualize a conta de serviço executando:

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

  5. Se a implantação usar relatórios, atualize a conta de fonte de dados:

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

  6. Se sua implantação usar o Servidor Proxy do Azure DevOps, atualize a conta de serviço proxy:

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

    Observação

    Se você estiver migrando para um domínio não confiável, talvez também precise adicionar manualmente usuários e grupos a equipes, projetos, coleções e ao próprio Servidor do Azure DevOps. Para obter mais informações, consulte Adicionar usuários a projetos, definir permissões de administrador para coleções de projetos e definir permissões de administrador para o Servidor do Azure DevOps.

  7. Se a implantação for integrada ao Project Server, talvez seja necessário executar outras etapas para configurar contas de serviço com as permissões necessárias. Para obter mais informações, consulte Atribuir permissões para dar suporte à integração do servidor TFS-Project e configurar a integração do servidor TFS-Project.

6. Configurar os serviços de relatório e de análise

Ignore este procedimento se sua implementação não usar relatórios.

Se você renomeou o servidor de relatório durante a movimentação, atualize o Servidor do Azure DevOps para apontar para o novo local do servidor de relatório. Você também precisa reiniciar o armazém e recriar manualmente o banco de dados do Analysis Services.

  1. Abra o console de administração do Azure DevOps, vá para o nó Relatório e edite as configurações.

    Os relatórios ainda apontam para o servidor antigo

  2. Atualize os valores nas três guias para refletir o novo nome do servidor. Insira corretamente as informações da conta da fonte de dados para o novo ambiente.

    Verifique se as informações estão corretas em todas as 3 abas

  3. Selecione Iniciar Trabalhos para reiniciar os relatórios.

  4. Selecione Iniciar Recompilação para recompilar o armazém.

7. Configurar cópias de segurança

Se você alterou o nome do compartilhamento de rede ou o dispositivo de armazenamento durante a alteração do nome de domínio, atualize seu plano de backup agendado para fazer referência aos novos recursos.

No console de administração, vá para o nó Backups Agendados e reconfigure os backups agendados para fazer backup dos bancos de dados do Azure DevOps Server no novo servidor. Para obter detalhes, consulte Criar um agendamento e um plano de backup.

8. Reiniciar serviços

Agora que você atualizou o Azure DevOps Server com todas as informações do novo ambiente, para reiniciar os serviços, execute as seguintes etapas:

  1. No computador da camada de aplicativo do Servidor do Azure DevOps, abra uma janela do Prompt de Comando com permissões administrativas e altere os diretórios para Drive:\%programfiles%\TFS 12.0\Tools.

  2. Insira o seguinte comando TFSServiceControl :

    TFSServiceControl unquiesce

FAQs (perguntas frequentes)

P: Quero alterar o servidor físico ou os servidores no meu ambiente, não os domínios. Posso fazer isso?

A: Sim, essa ação é chamada de movimentação com base em hardware, e as etapas são fornecidas em Mover ou clonar de um hardware para outro. Você não deve tentar combinar uma movimentação baseada em ambiente com um movimento baseado em hardware. Primeiro conclua a movimentação de hardware e depois altere o ambiente.

  • Last updated on