Microsoft Entra Connect: servidor de preparo e recuperação de desastre

Artigo
11/06/2023

Com um servidor no modo de preparo, você pode fazer alterações na configuração e visualizar as alterações antes de tornar o servidor ativo. Ele também permite executar sincronização e importação totais para verificar se todas as alterações são esperadas antes de você fazê-las em seu ambiente de produção.

Modo de preparo

O modo de teste pode ser usado para vários cenários, incluindo:

Alta disponibilidade.
Teste e implantação de novas alterações de configuração.
Introdução de um novo servidor e encerramento do antigo.

Durante a instalação, você pode selecionar o servidor em modo de preparo. Essa ação ativa o servidor de importação e sincronização, mas não executa qualquer exportação. Um servidor no modo de preparo não executa a sincronização de senha ou o write-back de senha, mesmo que esses recursos sejam selecionados durante a instalação. Quando você desabilita o modo de preparo, o servidor inicia a exportação e habilita a sincronização de senha e o write-back de senha.

Observação

Suponha que você tenha um Microsoft Entra Connect com o recurso de Sincronização de Hash de Senha habilitado. Quando você habilita o modo de preparo, o servidor para a sincronização de alterações de senha do AD local. Quando você desabilita o modo de preparo, o servidor retoma a sincronização de alterações de senha de onde ela parou. Se o servidor estiver no modo de preparo por um longo período de tempo, poderá levar um tempo para que ele sincronize todas as alterações de senha que ocorreram durante esse período.

Você ainda pode forçar uma exportação usando o Synchronization Service Manager.

Um servidor no modo de preparo continua recebendo alterações do Active Directory e do Microsoft Entra ID e pode assumir rapidamente as responsabilidades de outro servidor em caso de falha. Se você fizer alterações de configuração no servidor primário, será sua responsabilidade fazer as mesmas alterações no servidor em modo de preparo.

Para aqueles com conhecimento das tecnologias mais antigas de sincronização, o modo de preparo é diferente, pois o servidor tem seu próprio banco de dados SQL. Essa arquitetura permite que o servidor de modo de preparo esteja localizado em um datacenter diferente.

Verifique a configuração de um servidor

Para aplicar esse método, siga estas etapas:

Preparar
Configuration
Importar e sincronizar
Verificar
Servidor ativo do comutador

Preparação

Instale o Microsoft Entra Connect, selecione modo de preparo e desmarque Iniciar sincronização na última página do assistente de instalação. Esse modo permite que você execute o mecanismo de sincronização manualmente.
Saia e entre e, no menu Iniciar, selecione Serviço de Sincronização.

Configuração

Se você tiver feito alterações personalizadas no servidor primário e deseja comparar a configuração com o servidor de preparo, use o documentador de configuração do Microsoft Entra Connect.

Importar e sincronizar

Selecione Conectores e selecione o primeiro Conector com o tipo Serviços de Domínio Active Directory. Clique em Executar, selecione Importação completa e OK. Siga estas etapas para todos os Conectores desse tipo.
Selecione o Conector com o tipo Microsoft Entra ID (Microsoft). Clique em Executar, selecione Importação completa e OK.
Verifique se a guia Conectores ainda está selecionada. Para cada Conector com tipo Active Directory Domain Services, clique em Executar, selecione Sincronização Delta e OK.
Selecione o Conector com o tipo Microsoft Entra ID (Microsoft). Clique em Executar, selecione Sincronização Delta e OK.

Você agora preparou a exportação das alterações para o Microsoft Entra ID e AD local (se estiver usando implantação híbrida do Exchange). As próximas etapas permitem que você inspecione o que está prestes a ser alterado antes de realmente começar a exportação para os diretórios.

Verificar

Inicie um prompt de comando e vá para %ProgramFiles%\Microsoft Azure AD Sync\bin
Execute: csexport "Name of Connector" %temp%\export.xml /f:x o nome do Conector pode ser encontrado no Serviço de Sincronização. Ele tem um nome semelhante a "contoso.com – Microsoft Entra ID" para o Microsoft Entra ID.
Executar: CSExportAnalyzer %temp%\export.xml > %temp%\export.csv Você tem um arquivo em %temp% chamado export.csv que pode ser examinado no Microsoft Excel. Esse arquivo contém todas as alterações que estão prestes a ser exportadas.
Faça as alterações necessárias na configuração ou nos dados e execute essas etapas novamente (importar, sincronizar e verificar) até o momento estimado para que as alterações a serem exportadas ocorram.

Noções básicas sobre o arquivo export.csv

A maior parte do arquivo é autoexplicativa. Algumas siglas para entender o conteúdo:

OMODT – Object Modification Type. Indica se a operação em nível de objeto é um Add, Update ou Delete.
AMODT – Attribute Modification Type. Indica se a operação em um nível de atributo é um Add, Update ou Delete.

Recuperar identificadores comuns

Esse arquivo export.csv contém todas as alterações que estão prestes a ser exportadas. Cada linha corresponde a uma alteração de um objeto no espaço do conector e o objeto é identificado pelo atributo DN. O atributo DN é um identificador exclusivo atribuído a um objeto no espaço do conector. Quando você tem muitas linhas/alterações em export.csv para analisar, pode ser difícil que, com base apenas no atributo DN, você possa descobrir para quais objetos as alterações são. Para simplificar o processo de análise das alterações, use o script do PowerShell csanalyzer.ps1. O script recupera identificadores comuns (por exemplo, displayName, userPrincipalName) dos objetos. Para usar o script:

Copie o script do PowerShell da seção CSAnalyzer para um arquivo chamado csanalyzer.ps1.
Abra uma janela do PowerShell e procure a pasta em que você criou o script do PowerShell.
Execute: .\csanalyzer.ps1 -xmltoimport %temp%\export.xml.
Agora você tem um arquivo chamado processedusers1.csv que pode ser examinado no Microsoft Excel. Observe que o arquivo fornece um mapeamento de atributo DN para identificadores comuns (por exemplo, displayName e userPrincipalName). Atualmente, ele não inclui as alterações de atributo real que estão prestes a ser exportadas.

Servidor ativo do comutador

O Microsoft Entra Connect pode ser configurado em uma configuração de alta disponibilidade Active-Passive, em que um servidor enviará alterações ativamente por push para os objetos do AD sincronizados para o Microsoft Entra ID e o servidor passivo realizará essas alterações no caso de precisar assumir o comando.

Observação

Não é possível configurar o Microsoft Entra Connect em uma configuração Active-Active. Deve ser Ativo-Passivo. Verifique se apenas 1 servidor Microsoft Entra Connect está sincronizando ativamente as alterações.

Para obter mais informações sobre como configurar um servidor de sincronização do Microsoft Entra Connect no modo de preparo, consulte o modo de preparo

Talvez seja necessário executar um failover dos Servidores de Sincronização por vários motivos, como atualizar a versão do Microsoft Entra Connect ou receber um alerta de que o serviço de integridade do Serviço de Sincronização não está recebendo informações atualizadas. Nesses eventos, você pode tentar um failover dos Servidores de Sincronização seguindo as etapas abaixo.

Importante

Mudar um servidor de preparo para o modo ativo poderá ter um impacto severo na sincronização, se as condições a seguir não forem atendidas. Por precaução, sempre execute um ciclo de sincronização inicial e verifique as exportações pendentes antes de fazer essa operação.

Pré-requisitos

Um servidor do Microsoft Entra Connect Sync atualmente ativo
Um servidor de preparo do Microsoft Entra Connect Sync
O servidor de preparo tem o agendador de sincronização habilitado e sincronizado com a IMicrosoft Entra ID recentemente
No caso de atualizações em regras de sincronização ou no escopo de sincronização, execute um ciclo de sincronização inicial
Confirme se o Servidor de Sincronização do Microsoft Entra Connect está configurado para evitar exclusões acidentais
Verifique as exportações pendentes e confirme se não há atualizações significativas e se essas atualizações são esperadas
Verifique se o agente Microsoft Entra Connect Health está atualizado verificando o servidor no portal Microsoft Entra Connect Health
Alterne o servidor ativo atual para o modo de preparo, antes de alternar o servidor de preparo para ativo

Alterar atualmente o Active Sync Server para o modo de preparo

Precisamos garantir que apenas um Servidor de Sincronização esteja sincronizando alterações a qualquer momento durante todo esse processo. Se o servidor de sincronização atualmente ativo estiver acessível, você poderá executar as etapas abaixo para movê-lo para o Modo de Preparo. Se ele não estiver acessível, verifique se o servidor ou a VM não recuperam o acesso inesperadamente desligando o servidor ou isolando-o de conexões de saída.

Para o servidor do Microsoft Entra Connect ativo no momento, abra o assistente do Microsoft Entra Connect e clique em "Configurar modo de preparo" e, em seguida, Avançar:
Você precisará entrar no Microsoft Entra ID com credenciais de Administrador Global ou de Administrador de Identidade Híbrida:
Marque a caixa para o Modo de Preparo e clique em Avançar:
O servidor do Microsoft Entra Connect verificará se há componentes instalados e, em seguida, perguntará se você quer iniciar o processo de sincronização quando a alteração da configuração for concluída:

Como o servidor estará no modo de preparo, ele não gravará alterações em Microsoft Entra ID, mas manterá as alterações no AD em seu Espaço do Conector, pronto para gravá-las.
É recomendável deixar o processo de sincronização ativado para o servidor no Modo de Preparo, portanto, se ele se tornar ativo, ele assumirá rapidamente o controle e não precisará fazer uma grande sincronização para acompanhar o estado atual dos objetos do Active Directory / Microsoft Entra no escopo.

Após selecionar se deseja iniciar o processo de sincronização e clicar em Configurar, o servidor do Microsoft Entra Connect será configurado no Modo de Preparo.
Quando isso for concluído, você será solicitado com uma tela que confirme se o Modo de Preparo está habilitado.
Você pode clicar em Sair para concluir.
É possível confirmar se o servidor está no modo de preparo corretamente abrindo Windows PowerShell. Carregue o módulo "ADSync" e verifique a configuração do Agendador do ADSync, usando os comandos a seguir:

Import-Module ADSync
Get-ADSyncScheduler

Nos resultados, verifique o valor da configuração "StagingModeEnabled". Se o servidor tiver sido alternado com êxito para o modo de preparo, o valor dessa configuração deverá ser True, como no exemplo abaixo:

A captura de tela mostra o console do Serviço de Sincronização da entrada na caixa de diálogo do Microsoft Entra Connect Ativo.

Alterar o servidor de Sincronização de Preparo atual para o modo ativo

Neste ponto, todos os nossos Servidores de Sincronização do Microsoft Entra Connect devem estar no modo de preparo e não exportar alterações. Agora podemos mover nosso Servidor de Sincronização de Preparo para o modo Ativo e sincronizar ativamente as alterações.

Agora, vá para o servidor do Microsoft Entra Connect que estava originalmente no Modo de Preparo e abra o assistente do Microsoft Entra Connect.

Clique em "Configurar modo de preparo" e clique em Avançar:

A mensagem na parte inferior do assistente indica que esse servidor está no Modo de Preparo.
Entre no Microsoft Entra ID e vá para a tela Modo de Preparo.

Desmarque a caixa para Modo de Preparo e clique em Avançar

De acordo com o aviso nesta página, é importante garantir que nenhum outro servidor Microsoft Entra Connect esteja sincronizando ativamente.

Deve haver apenas um servidor de sincronização ativo Microsoft Entra Connect Sync a qualquer momento.
Quando for solicitado que você inicie o processo de sincronização, marque esta caixa e clique em Configurar:
Depois que o processo for concluído, você deverá obter a tela de confirmação abaixo, na qual poderá clicar em Sair para concluir:
Você pode confirmar novamente que isso está funcionando abrindo o Console do Serviço de Sincronização e verificando se os Trabalhos de exportação estão em execução:

Recuperação de desastre

Parte do design de implementação é planejar o que fazer em caso de desastre, quando você perde o servidor de sincronização. Há modelos diferentes para uso e qual deles usar depende de vários fatores, incluindo:

Quão tolerável é para você não poder fazer alterações em objetos no Microsoft Entra ID durante o tempo de inatividade?
Se você usar a sincronização de senha, os usuários aceitarão que devem usar a senha antiga no Microsoft Entra ID se a alterarem no local?
Você tem uma dependência em operações em tempo real, como write-back de senha?

Dependendo das respostas a essas perguntas e da política da sua organização, uma das estratégias abaixo pode ser implementada:

Recriar quando necessário.
Ter um servidor em espera reserva, conhecido como modo de preparo.
Usar máquinas virtuais.

Se não usar o banco de dados interno do SQL Express, você também deverá examinar a seção Alta disponibilidade do SQL .

Recriar quando necessário

Uma estratégia viável é planejar para a recriação do servidor quando necessário. Geralmente, a instalação do mecanismo de sincronização, a importação e a sincronização inicial podem ser concluídas em algumas horas. Se não houver um servidor reserva disponível, é possível usar temporariamente um controlador de domínio para hospedar o mecanismo de sincronização.

O servidor do mecanismo de sincronização não armazena qualquer estado sobre os objetos para que o banco de dados possa ser reconstruído com os dados no Active Directory e no Microsoft Entra ID. O atributo sourceAnchor é usado para unir os objetos do local e da nuvem. Se você recriar o servidor com objetos locais existentes e a nuvem, o mecanismo de sincronização fará a correspondência entre esses objetos novamente na reinstalação. As coisas que você precisa documentar e salvar são as alterações de configuração feitas no servidor, como regras de sincronização e de filtragem. Essas configurações personalizadas devem ser reaplicadas antes que você inicie a sincronização.

Ter um servidor em espera reserva - modo de preparo

Se você tiver um ambiente mais complexo, é recomendável ter um ou mais servidores em espera. Durante a instalação, você pode habilitar um servidor em modo de preparo.

Para obter mais informações, consulte Modo de preparo.

Usar máquinas virtuais

Um método comum e com suporte é a execução do mecanismo de sincronização em uma máquina virtual. Se o host tiver um problema, a imagem com o servidor do mecanismo de sincronização pode ser migrada para outro servidor.

Alta disponibilidade do SQL

Se você não estiver usando o SQL Server Express que vem com o Microsoft Entra Connect, a alta disponibilidade do SQL Server também deverá ser considerada. As soluções de alta disponibilidade com suporte incluem o clustering de SQL e AOA (Grupos de Disponibilidade AlwaysOn). Soluções sem suporte incluem espelhamento.

O suporte para SQL AOA foi adicionado ao Microsoft Entra Connect na versão 1.1.524.0. Você deve habilitar o SQL AOA antes de instalar o Microsoft Entra Connect. Durante a instalação, o Microsoft Entra Connect detecta se a instância do SQL fornecida está habilitada para SQL AOA ou não. Se o SQL AOA estiver habilitado, o Microsoft Entra Connect descobrirá melhor se o AOA SQL está configurado para usar replicação síncrona ou replicação assíncrona. Ao configurar o ouvinte do grupo de disponibilidade, defina a propriedade RegisterAllProvidersIP como 0. Isso ocorre porque o Microsoft Entra Connect atualmente usa o SQL Native Client para conectar-se ao SQL, e o SQL Native Client não dá suporte ao uso da propriedade MultiSubNetFailover.

Apêndice: CSAnalyzer

Consulte a seção Verificar para saber como usar esse script.

Param(
    [Parameter(Mandatory=$true, HelpMessage="Must be a file generated using csexport 'Name of Connector' export.xml /f:x)")]
    [string]$xmltoimport="%temp%\exportedStage1a.xml",
    [Parameter(Mandatory=$false, HelpMessage="Maximum number of users per output file")][int]$batchsize=1000,
    [Parameter(Mandatory=$false, HelpMessage="Show console output")][bool]$showOutput=$false
)

#LINQ isn't loaded automatically, so force it
[Reflection.Assembly]::Load("System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089") | Out-Null

[int]$count=1
[int]$outputfilecount=1
[array]$objOutputUsers=@()

#XML must be generated using "csexport "Name of Connector" export.xml /f:x"
write-host "Importing XML" -ForegroundColor Yellow

#XmlReader.Create won't properly resolve the file location,
#so expand and then resolve it
$resolvedXMLtoimport=Resolve-Path -Path ([Environment]::ExpandEnvironmentVariables($xmltoimport))

#use an XmlReader to deal with even large files
$result=$reader = [System.Xml.XmlReader]::Create($resolvedXMLtoimport) 
$result=$reader.ReadToDescendant('cs-object')
if($result)
{
    do 
    {
        #create the object placeholder
        #adding them up here means we can enforce consistency
        $objOutputUser=New-Object psobject
        Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name ID -Value ""
        Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name Type -Value ""
        Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name DN -Value ""
        Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name operation -Value ""
        Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name UPN -Value ""
        Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name displayName -Value ""
        Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name sourceAnchor -Value ""
        Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name alias -Value ""
        Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name primarySMTP -Value ""
        Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name onPremisesSamAccountName -Value ""
        Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name mail -Value ""

        $user = [System.Xml.Linq.XElement]::ReadFrom($reader)
        if ($showOutput) {Write-Host Found an exported object... -ForegroundColor Green}

        #object id
        $outID=$user.Attribute('id').Value
        if ($showOutput) {Write-Host ID: $outID}
        $objOutputUser.ID=$outID

        #object type
        $outType=$user.Attribute('object-type').Value
        if ($showOutput) {Write-Host Type: $outType}
        $objOutputUser.Type=$outType

        #dn
        $outDN= $user.Element('unapplied-export').Element('delta').Attribute('dn').Value
        if ($showOutput) {Write-Host DN: $outDN}
        $objOutputUser.DN=$outDN

        #operation
        $outOperation= $user.Element('unapplied-export').Element('delta').Attribute('operation').Value
        if ($showOutput) {Write-Host Operation: $outOperation}
        $objOutputUser.operation=$outOperation

        #now that we have the basics, go get the details

        foreach ($attr in $user.Element('unapplied-export-hologram').Element('entry').Elements("attr"))
        {
            $attrvalue=$attr.Attribute('name').Value
            $internalvalue= $attr.Element('value').Value

            switch ($attrvalue)
            {
                "userPrincipalName"
                {
                    if ($showOutput) {Write-Host UPN: $internalvalue}
                    $objOutputUser.UPN=$internalvalue
                }
                "displayName"
                {
                    if ($showOutput) {Write-Host displayName: $internalvalue}
                    $objOutputUser.displayName=$internalvalue
                }
                "sourceAnchor"
                {
                    if ($showOutput) {Write-Host sourceAnchor: $internalvalue}
                    $objOutputUser.sourceAnchor=$internalvalue
                }
                "alias"
                {
                    if ($showOutput) {Write-Host alias: $internalvalue}
                    $objOutputUser.alias=$internalvalue
                }
                "proxyAddresses"
                {
                    if ($showOutput) {Write-Host primarySMTP: ($internalvalue -replace "SMTP:","")}
                    $objOutputUser.primarySMTP=$internalvalue -replace "SMTP:",""
                }
            }
        }

        $objOutputUsers += $objOutputUser

        Write-Progress -activity "Processing ${xmltoimport} in batches of ${batchsize}" -status "Batch ${outputfilecount}: " -percentComplete (($objOutputUsers.Count / $batchsize) * 100)

        #every so often, dump the processed users in case we blow up somewhere
        if ($count % $batchsize -eq 0)
        {
            Write-Host Hit the maximum users processed without completion... -ForegroundColor Yellow

            #export the collection of users as a CSV
            Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
            $objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation

            #increment the output file counter
            $outputfilecount+=1

            #reset the collection and the user counter
            $objOutputUsers = $null
            $count=0
        }

        $count+=1

        #need to bail out of the loop if no more users to process
        if ($reader.NodeType -eq [System.Xml.XmlNodeType]::EndElement)
        {
            break
        }

    } while ($reader.Read)

    #need to write out any users that didn't get picked up in a batch of 1000
    #export the collection of users as CSV
    Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
    $objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation
}
else
{
    Write-Host "Imported XML file is empty. No work to do." -ForegroundColor Red
}

Próximas etapas

Tópicos de visão geral