Опрос изменений с помощью USNChanged

Элемент управления DirSync является мощным и эффективным, но имеет два существенных ограничения:

• Только для приложений с высоким уровнем привилегий: чтобы использовать элемент управления DirSync, приложение должно выполняться под учетной записью, которая имеет права SE_SYNC_AGENT_NAME на контроллере домена. Немногие учетные записи настолько привилегированны, поэтому приложение, использующее элемент управления DirSync, не может выполняться обычными пользователями.
• Отсутствие области охвата поддерева: элемент управления DirSync возвращает все изменения, происходящие в пределах области имен. Приложение, интересующееся только изменениями, которые происходят в небольшом поддереве контекста именования, должны пройти через множество неуместных изменений, которые неэффективны как для приложения, так и для контроллера домена.

Изменения из Active Directory также можно получить путем запроса атрибута uSNChanged, что позволяет избежать ограничений элемента управления DirSync. Эта альтернатива не лучше элемента управления DirSync во всех отношениях, так как она включает передачу всех атрибутов при изменении любого атрибута и требует больше работы от разработчика приложения для правильной обработки определенных сценариев сбоев. В настоящее время это лучший способ написания определенных приложений отслеживания изменений.

Когда контроллер домена изменяет объект, он устанавливает атрибут uSNChanged объекта значением, которое больше предыдущего значения атрибута uSNChanged для этого объекта и больше текущего значения атрибута uSNChanged для всех остальных объектов, содержащихся на этом контроллере домена. В результате приложение может найти последний измененный объект на контроллере домена, найдя объект с наибольшим значением uSNChanged. Второй недавно измененный объект на контроллере домена будет иметь второе наибольшее значение uSNChanged и т. д.

Атрибут uSNChanged не реплицируется, поэтому чтение атрибута объекта uSNChanged на двух разных контроллерах домена обычно дает разные значения.

Например, атрибут uSNChanged можно использовать для отслеживания изменений в поддереве S. Во-первых, выполните полную синхронизацию поддерева S. Предположим, что наибольшее значение uSNChanged для любого объекта в S равно U. Периодически запрашивайте все объекты в поддереве S, у которых значение uSNChanged больше U. Запрос вернет все объекты, которые изменились с момента полной синхронизации. Установите U как наибольшее значение uSNChanged среди этих измененных объектов, и вы готовы повторно провести опрос.

Ниже представлены тонкости реализации приложения синхронизации uSNChanged:

• Используйте атрибут highestCommittedUSN rootDSE для привязки фильтров uSNChanged. То есть перед началом полной синхронизации прочитайте highestCommittedUSN вашего связанного контроллера домена. Затем выполните полный запрос синхронизации (с помощью страничных результатов), чтобы инициализировать базу данных. По завершении сохраните значение highestCommittedUSN, полученное до полного запроса синхронизации, чтобы использовать его в качестве нижней границы атрибута uSNChanged для следующей синхронизации. Позже, чтобы выполнить добавочную синхронизацию, перечитайте атрибут самый высокий rootDSE. Затем выполните запрос соответствующих объектов, используя постраничные результаты, у которых uSNChanged больше нижней границы значения атрибута uSNChanged, сохраненного из предыдущей синхронизации. Обновите базу данных с помощью этих сведений. По завершении обновите нижние границы атрибута uSNChanged из значения самого высокогоCommittedUSN, прочитанного перед инкрементным запросом синхронизации. Всегда храните нижние границы атрибута uSNChanged в том же хранилище, с которым приложение синхронизирует содержимое контроллера домена.

  Следуя этой процедуре, а не на основе значений uSNChanged для извлеченных объектов, избегает повторного получения обновленных объектов сервера, которые выходят за пределы набора, применимого к приложению.

• Так как uSNChanged является нереплицированным атрибутом, приложение должно привязаться к одному контроллеру домена при каждом запуске. Если он не может подключиться к контроллеру домена, он должен либо подождать, пока сможет это сделать, либо связаться с новым контроллером домена и выполнить полную синхронизацию с ним. Когда приложение связывается с контроллером домена, оно записывает DNS-имя этого контроллера домена в стабильное хранилище, которое синхронизируется с содержимым контроллера домена. Затем он использует хранимые DNS-имя для привязки к тому же контроллеру домена для последующей синхронизации.

• Приложение должно определить, когда контроллер домена, с которым оно в настоящее время связано, был восстановлен из резервной копии, так как это может привести к несоответствию. Когда приложение связывается с контроллером домена, оно кэширует «идентификатор вызова» этого контроллера домена в стабильном хранилище, то есть в том же хранилище, которое поддерживается в соответствии с содержимым контроллера домена. Идентификатор вызова контроллера домена — это GUID, хранящийся в атрибуте invocationID объекта службы контроллера домена. Чтобы получить уникальное имя объекта службы контроллера домена, прочитайте атрибут dsServiceName rootDSE.

  Помните, что при восстановлении стабильного хранилища приложения из резервной копии нет проблем согласованности, так как имя контроллера домена, идентификатор вызова и нижние границы значения атрибута uSNChanged хранятся с данными, синхронизированными с содержимым контроллера домена.

• Используйте разбиение на страницы при запросе сервера как для полных, так и для добавочных синхронизаций, чтобы избежать одновременного извлечения больших результирующих наборов. Дополнительные сведения см. в разделе Указание других параметров поиска.

• Выполните запросы на основе индекса, чтобы избежать принудительного хранения сервера больших промежуточных результатов при использовании страничных результатов. Дополнительные сведения см. в разделе Индексированные атрибуты.

• Как правило, не используйте сортировку результатов поиска на стороне сервера, что может принудительно хранить и сортировать большие промежуточные результаты. Это относится как к полным, так и добавочным синхронизациям. Дополнительные сведения см. в разделе Указание других параметров поиска.

• Корректно обрабатывайте отсутствие родительских условий. Приложение может распознать объект, прежде чем он распознает родительский объект. В зависимости от приложения это может быть или не может быть проблемой. Приложение всегда может считывать текущее состояние родительского элемента из каталога.

• Чтобы обработать перемещенные или удаленные объекты, сохраните атрибут objectGUIDобъектакаждого отслеживаемого объекта. Атрибут объекта objectGUID остается неизменным независимо от того, где он перемещается по лесу.

• Для обработки перемещаемых объектов выполните периодические полные синхронизации или увеличьте область поиска и отфильтруйте неинтересные изменения в конце клиента.

• Чтобы обрабатывать удаленные объекты, периодически выполняйте полную синхронизацию или выполняйте отдельный поиск удаленных объектов при добавочной синхронизации. При запросе удаленных объектов получите objectGUID , чтобы определить, какие объекты следует удалить из вашей базы данных. Дополнительные сведения см. в разделе извлечение удаленных объектов.

• Помните, что результаты поиска включают только те объекты и атрибуты, к которым вызывающий имеет право на чтение (на основе дескрипторов безопасности и списков управления доступом, DACL, на различных объектах). Дополнительные сведения см. в разделе Влияние безопасности на запросы.

Дополнительные сведения и пример кода, демонстрирующий основы приложения синхронизации USNChanged, см. в разделе Пример кода для получения изменений с помощью USNChanged.