Sondagem para alterações usando USNChanged

O controle DirSync é poderoso e eficiente, mas tem duas limitações significativas:

• Somente para aplicativos altamente privilegiados: para usar o controle DirSync, um aplicativo deve ser executado em uma conta que tenha o privilégio SE_SYNC_AGENT_NAME no controlador de domínio. Poucas contas são tão privilegiadas, de modo que um aplicativo que usa o controle DirSync não pode ser executado por usuários comuns.
• Sem limitação a subárvores: O controlo DirSync retorna todas as alterações que ocorrem no contexto de nomenclatura. Um aplicativo interessado apenas em alterações que ocorrem em uma pequena subárvore de um contexto de nomenclatura deve percorrer muitas alterações irrelevantes, o que é ineficiente tanto para o aplicativo quanto para o controlador de domínio.

As alterações do Ative Directory também podem ser obtidas consultando o atributo uSNChanged, o que evita as limitações do controle DirSync. Essa alternativa não é melhor do que o controle DirSync em todos os aspetos porque envolve a transmissão de todos os atributos quando qualquer atributo é alterado e requer mais trabalho do desenvolvedor do aplicativo para lidar corretamente com determinados cenários de falha. É, atualmente, a melhor maneira de escrever certos aplicativos de controle de alterações.

Quando um controlador de domínio modifica um objeto, ele define o atributouSNChangeddesse objeto como um valor maior do que o valor anterior do atributo uSNChanged para esse objeto e maior do que o valor atual do atributo uSNChanged para todos os outros objetos mantidos nesse controlador de domínio. Como consequência, uma aplicação pode encontrar o objeto alterado mais recentemente num controlador de domínio ao localizar o objeto com o maior valor uSNChanged. O segundo objeto mais recentemente alterado em um controlador de domínios terá o segundo maior valor de uSNChanged, e assim por diante.

O atributo uSNChanged não é replicado, portanto, ler o atributo uSNChanged de um objeto em dois controladores de domínio diferentes normalmente dará valores diferentes.

Por exemplo, o atributo uSNChanged pode ser usado para acompanhar alterações numa subárvore S. Primeiro, execute uma "sincronização completa" da subárvore S. Suponha que o maior valor de uSNChanged para qualquer objeto em S seja U. Consulte periodicamente todos os objetos na subárvore S cujo valor uSNChanged seja maior que U. A consulta retornará todos os objetos que foram alterados desde a sincronização completa. Defina U para o maior uSNChanged entre esses objetos alterados, e estará pronto para requisitar novamente.

As sutilezas da implementação de um uSNChanged aplicativo de sincronização incluem:

• Use o atributo highestCommittedUSN do rootDSE para vincular seus filtros de uSNChanged. Ou seja, antes de iniciar uma sincronização completa, leia o CommittedUSN mais alto do seu controlador de domínio afiliado. Em seguida, execute uma consulta de sincronização completa (usando resultados paginados) para inicializar o banco de dados. Quando isso estiver concluído, armazene o valor highestCommittedUSN lido antes da consulta de sincronização completa. Para usar como os limites inferiores do atributo uSNChanged para a próxima sincronização. Posteriormente, para executar uma sincronização incremental, releia o atributo highestCommittedUSN rootDSE. Em seguida, consulte objetos relevantes, usando resultados paginados, cuja uSNChanged seja maior do que os limites inferiores do valor do atributo uSNChanged salvo da sincronização anterior. Atualize o banco de dados usando essas informações. Quando terminar, atualize os limites inferiores do atributo uSNChanged a partir do valor highestCommittedUSN lido antes da consulta de sincronização incremental. Sempre armazene os limites inferiores do valor do atributo uSNChanged no mesmo armazenamento que o aplicativo está sincronizando com o conteúdo do controlador de domínio.

  Seguir este procedimento, em vez de se basear em valores de uSNChanged em objetos recuperados, evita que o servidor reexamine objetos atualizados que não pertencem ao conjunto aplicável à aplicação.

• Como uSNChanged é um atributo não replicado, o aplicativo deve se vincular ao mesmo controlador de domínio sempre que for executado. Se ele não puder se vincular a esse controlador de domínio, ele deverá aguardar até que possa fazê-lo ou afiliar-se a algum novo controlador de domínio e executar uma sincronização completa com esse controlador de domínio. Quando o aplicativo se afilia a um controlador de domínio, ele registra o nome DNS desse controlador de domínio em armazenamento estável, que é o mesmo armazenamento que ele está mantendo consistente com o conteúdo do controlador de domínio. Em seguida, ele usa o nome DNS armazenado para vincular ao mesmo controlador de domínio para sincronizações subsequentes.

• O aplicativo deve detetar quando o controlador de domínio ao qual está atualmente afiliado foi restaurado a partir do backup, pois isso pode causar inconsistência. Quando a aplicação se afilia a um controlador de domínio, armazena em cache o "id de invocação" desse controlador de domínio em armazenamento estável, ou seja, o mesmo armazenamento que mantém consistente com o conteúdo do controlador de domínio. O "ID de invocação" de um controlador de domínio é um GUID armazenado no atributo invocationID do objeto de serviço do controlador de domínio. Para obter o nome distinto do objeto de serviço de um controlador de domínio, leia o atributo dsServiceName do rootDSE.

  Lembre-se de que, quando o armazenamento estável do aplicativo é restaurado a partir do backup, não há problemas de consistência porque o nome do controlador de domínio, a ID de invocação e os limites inferiores do valor do atributo uSNChanged são armazenados com os dados sincronizados com o conteúdo do controlador de domínio.

• Use a paginação ao consultar o servidor, sincronizações completas e incrementais, para evitar a possibilidade de recuperar grandes conjuntos de resultados simultaneamente. Para obter mais informações, consulte Especificando outras opções de pesquisa.

• Execute consultas baseadas em índice para evitar forçar o servidor a armazenar grandes resultados intermediários ao usar resultados paginados. Para obter mais informações, consulte Atributos indexados.

• Em geral, não use a classificação do lado do servidor dos resultados da pesquisa, que pode forçar o servidor a armazenar e classificar grandes resultados intermediários. Isso se aplica a sincronizações completas e incrementais. Para obter mais informações, consulte Especificando outras opções de pesquisa.

• Não lide com condições parentais graciosamente. O aplicativo pode reconhecer um objeto antes de reconhecer seu pai. Dependendo da aplicação, isso pode ou não ser um problema. O aplicativo sempre pode ler o estado atual do pai a partir do diretório.

• Para manipular objetos movidos ou excluídos, armazene o atributo objectGUIDde cada objeto rastreado. O atributo objectGUID de um objeto permanece inalterado, independentemente de onde ele é movido pela floresta.

• Para lidar com objetos movidos, realize sincronizações completas periódicas ou expanda o escopo de pesquisa e filtre, do lado do cliente, as alterações irrelevantes.

• Para lidar com objetos excluídos, execute sincronizações completas periódicas ou execute uma pesquisa separada de objetos excluídos quando você executar uma sincronização incremental. Ao consultar objetos excluídos, recupere oobjectGUIDdos objetos excluídos para determinar os objetos a serem excluídos do banco de dados. Para obter mais informações, consulte Recuperando objetos excluídos.

• Lembre-se de que os resultados da pesquisa incluem apenas os objetos e atributos que o chamador tem permissão para ler (com base nos descritores de segurança e DACLs nos vários objetos). Para obter mais informações, consulte Efeitos da Segurança nas Consultas.

Para obter mais informações e um exemplo de código que mostra os conceitos básicos de um aplicativo de sincronização USNChanged, consulte código de exemplo para recuperar alterações usando USNChanged.