USNChanged를 사용하여 변경 내용 폴링

DirSync 컨트롤은 강력하고 효율적이지만 두 가지 중요한 제한 사항이 있습니다.

• 높은 권한의 애플리케이션에 대해서만: DirSync 컨트롤을 사용하려면 도메인 컨트롤러에 대한 SE_SYNC_AGENT_NAME 권한이 있는 계정에서 애플리케이션을 실행해야 합니다. 권한이 높은 계정은 거의 없으므로 DirSync 컨트롤을 사용하는 애플리케이션은 일반 사용자가 실행할 수 없습니다.
• 하위 트리 범위 지정 없음: DirSync 컨트롤은 명명 컨텍스트 내에서 발생하는 모든 변경 내용을 반환합니다. 명명 컨텍스트의 작은 하위 트리에서 발생하는 변경 내용에만 관심이 있는 애플리케이션은 애플리케이션과 도메인 컨트롤러 모두에 비효율적인 많은 관련이 없는 변경 내용을 통과해야 합니다.

DirSync 컨트롤의 제한을 방지하는 uSNChanged 특성을 쿼리하여 Active Directory의 변경 내용을 가져올 수도 있습니다. 이 대안은 특성이 변경될 때 모든 특성을 전송해야 하며 애플리케이션 개발자가 특정 오류 시나리오를 올바르게 처리하기 위해 더 많은 작업이 필요하기 때문에 모든 면에서 DirSync 컨트롤보다 낫지 않습니다. 현재 특정 변경 내용 추적 애플리케이션을 작성하는 가장 좋은 방법입니다.

도메인 컨트롤러가 개체를 수정하면 해당 개체의 uSNChanged 특성을 해당 개체의 이전 값보다 크고 해당 도메인 컨트롤러에 있는 다른 모든 개체에 대한 uSNChanged 특성의 현재 값보다 큰 값으로 설정합니다. 결과적으로 애플리케이션은 가장 큰 uSNChanged 값을 가진 개체를 찾아 도메인 컨트롤러에서 가장 최근에 변경된 개체를 찾을 수 있습니다. 도메인 컨트롤러에서 가장 최근에 변경된 두 번째 개체에는 두 번째로 큰 uSNChanged 값이 있습니다.

uSNChanged 특성은 복제되지 않으므로 두 개의 서로 다른 도메인 컨트롤러에서 개체의 uSNChanged 특성을 읽는 것은 일반적으로 다른 값을 제공합니다.

예를 들어 uSNChanged 특성을 사용하여 하위 트리 S의 변경 내용을 추적할 수 있습니다. 먼저 하위 트리 S의 "전체 동기화"를 수행합니다. S의 모든 개체에 대한 가장 큰 uSNChanged 값이 U라고 가정합니다. uSNChanged 값이 U보다 큰 하위 트리 S의 모든 개체에 대해 주기적으로 쿼리합니다. 쿼리는 전체 동기화 이후 변경된 모든 개체를 반환합니다. 이러한 변경된 개체 중에서 가장 큰 uSNChanged 로 설정하면 다시 폴링할 준비가 됩니다.

uSNChanged 동기화 애플리케이션 구현의 미묘한 차이는 다음과 같습니다.

• rootDSE의 highestCommittedUSN 특성을 사용하여 uSNChanged 필터를 바인딩합니다. 즉, 전체 동기화를 시작하기 전에 관련 도메인 컨트롤러의 highestCommittedUSN 을 읽습니다. 그런 다음 전체 동기화 쿼리(페이징된 결과 사용)를 수행하여 데이터베이스를 초기화합니다. 이 작업이 완료되면 전체 동기화 쿼리 앞에 읽 은 highestCommittedUSN 값을 저장합니다. 다음 동기화를 위해 uSNChanged 특성의 하한으로 사용합니다. 나중에 증분 동기화를 수행하려면 highcommittedUSN rootDSE 특성을 다시 읽습니다. 그런 다음 uSNChanged 가 이전 동기화에서 저장된 uSNChanged 특성 값의 하한보다 큰 페이징된 결과를 사용하여 관련 개체를 쿼리합니다. 이 정보를 사용하여 데이터베이스를 업데이트합니다. 완료되면 증분 동기화 쿼리 전에 읽은 highestCommittedUSN 값에서 uSNChanged 특성의 하한을 업데이트합니다. 항상 uSNChanged 특성 값의 하한을 애플리케이션이 도메인 컨트롤러 콘텐츠와 동기화하는 것과 동일한 스토리지에 저장합니다.

  이 절차에 따라 검색된 개체의 uSNChanged 값을 기반으로 하는 것이 아니라 서버가 애플리케이션에 적용 가능한 집합 외부에 있는 업데이트된 개체를 다시 검색하지 않도록 합니다.

• uSNChanged는 복제되지 않은 특성이므로 애플리케이션이 실행 될 때마다 동일한 도메인 컨트롤러에 바인딩해야 합니다. 해당 도메인 컨트롤러에 바인딩할 수 없는 경우 그렇게 할 때까지 기다리거나 일부 새 도메인 컨트롤러와 연결하고 해당 도메인 컨트롤러와 전체 동기화를 수행해야 합니다. 애플리케이션이 도메인 컨트롤러와 연결되면 해당 도메인 컨트롤러의 DNS 이름을 안정적인 스토리지에 기록합니다. 이는 도메인 컨트롤러 콘텐츠와 일관성을 유지하는 것과 동일한 스토리지입니다. 그런 다음 저장된 DNS 이름을 사용하여 후속 동기화를 위해 동일한 도메인 컨트롤러에 바인딩합니다.

• 애플리케이션은 현재 연결된 도메인 컨트롤러가 백업에서 복원된 시기를 검색해야 합니다. 이로 인해 불일치가 발생할 수 있기 때문입니다. 애플리케이션이 도메인 컨트롤러와 제휴하면 해당 도메인 컨트롤러의 "호출 ID"를 안정적인 스토리지에 캐시합니다. 즉, 도메인 컨트롤러 콘텐츠와 일관성을 유지하는 동일한 스토리지입니다. 도메인 컨트롤러의 "호출 ID"는 도메인 컨트롤러의 서비스 개체의 invocationID 특성에 저장된 GUID입니다. 도메인 컨트롤러의 서비스 개체의 고유 이름을 얻으려면 rootDSE의 dsServiceName 특성을 읽어보세요.

  백업에서 애플리케이션의 안정적인 스토리지를 복원할 때는 도메인 컨트롤러 이름, 호출 ID 및 uSNChanged 특성 값의 하한이 도메인 컨트롤러 콘텐츠와 동기화된 데이터와 함께 저장되기 때문에 일관성 문제가 없습니다.

• 전체 동기화와 증분 동기화 모두에서 서버를 쿼리할 때 페이징을 사용하여 큰 결과 집합을 동시에 검색할 가능성을 방지합니다. 자세한 내용은 기타 검색 옵션 지정을 참조하세요.

• 인덱스 기반 쿼리를 수행하여 페이징된 결과를 사용할 때 서버가 큰 중간 결과를 저장하도록 강요하지 않도록 합니다. 자세한 내용은 인덱싱된 특성을 참조하세요.

• 일반적으로 서버 쪽 검색 결과 정렬을 사용하지 마세요. 이렇게 하면 서버에서 대용량 중간 결과를 저장하고 정렬하도록 강제할 수 있습니다. 이는 전체 동기화와 증분 동기화 모두에 적용됩니다. 자세한 내용은 기타 검색 옵션 지정을 참조하세요.

• 부모 조건을 정상적으로 처리하지 않습니다. 애플리케이션이 해당 부모를 인식하기 전에 개체를 인식할 수 있습니다. 애플리케이션에 따라 문제가 될 수도 있으며 그렇지 않을 수도 있습니다. 애플리케이션은 항상 디렉터리에서 부모의 현재 상태를 읽을 수 있습니다.

• 이동되거나 삭제된 개체를 처리하려면 추적된 각 개체의 objectGUID 특성을 저장합니다. 개체의 objectGUID 특성은 포리스트 전체에서 이동되는 위치에 관계없이 변경되지 않은 상태로 유지됩니다.

• 이동된 개체를 처리하려면 주기적인 전체 동기화를 수행하거나 검색 scope 늘리고 클라이언트 끝에서 관심이 없는 변경 내용을 필터링합니다.

• 삭제된 개체를 처리하려면 주기적인 전체 동기화를 수행하거나 증분 동기화를 수행할 때 삭제된 개체에 대해 별도의 검색을 수행합니다. 삭제된 개체를 쿼리할 때 삭제된 개체의 objectGUID 를 검색하여 데이터베이스에서 삭제할 개체를 확인합니다. 자세한 내용은 삭제된 개체 검색을 참조하세요.

• 검색 결과에는 호출자가 읽을 수 있는 권한이 있는 개체와 특성만 포함됩니다(다양한 개체의 보안 설명자 및 DACL 기반). 자세한 내용은 보안이 쿼리에 미치는 영향을 참조하세요.

자세한 내용과 USNChanged 동기화 애플리케이션의 기본 사항을 보여 주는 코드 예제는 USNChanged를 사용하여 변경 내용을 검색하는 예제 코드를 참조하세요.