공용 폴더 복제 문제 해결 – 3부: 복제본 삭제 문제 및 일반 문제 해결





최초 문서 게시일: 2011년 11월 28일 월요일

영문 블로그 최초 게시일: 2006년 1월 24일

이 블로그 게시물은 공용 폴더 복제 문제 해결과 관련된 세 번째 게시물입니다. 첫 번째 게시물(영문일 수 있음)에서는 새 변경 내용 복제 문제를 해결하는 방법에 대해 설명했으며, 두 번째 블로그 게시물에서는 기존 데이터 복제 문제를 해결하는 방법에 대해 다루었습니다. 시리즈의 이번 게시물에서는 복제본 삭제 문제 및 일반 문제를 해결하는 방법에 대해 다룹니다. 전반적인 내용을 파악하려면 참조 자료를 모두 확인하시기 바랍니다.

복제본 삭제 문제 해결

모든 폴더의 복제본 목록에서 이전 서버를 제거했는데 ESM에서 이전 저장소의 공용 폴더 인스턴스로 이동하면 폴더가 표시되는 경우가 있습니다. 이 경우 복제본 삭제 프로세스에서 문제가 발생한 것입니다. Exchange 2003 SP2 버전 ESM에서는 이 상태에서 공용 저장소를 삭제하려고 하면 다음과 같은 메시지가 포함된 대화 상자가 표시됩니다.

“이 공용 폴더는 폴더 복제본을 포함하므로 삭제할 수 없습니다. 데이터 손실을 방지하려면 공용 폴더 저장소를 마우스 오른쪽 단추로 클릭하고 복제본 이동을 사용하여 복제본을 다른 서버로 이동하십시오. 콘텐츠를 새 서버로 복제하고 로컬 복제본을 제거하려면 몇 시간이 걸릴 수 있습니다.”

폴더의 복제본 목록에서 저장소를 제거해도 해당 저장소에서 데이터가 즉시 삭제되지는 않습니다. 대신 저장소에서는 특수한 0x20 상태 요청을 다른 모든 복제본으로 보냅니다. 이 요청은 RDPSR(복제본 삭제 보류 중 상태 요청)이라고 하며, 응용 프로그램 로그에서 일반 상태 요청과 구분할 수 없습니다. RDPSR에는 복제본이 삭제 보류 중임을 나타내는 플래그가 포함되어 있습니다. 다른 저장소에서는 이 0x20을 받으면 RDPA(복제본 삭제 보류 승인)라는 특수한 0x10으로 응답합니다. RDPA는 해당 데이터를 삭제해도 됨을 나타내지만, 다른 저장소는 삭제 보류 중인 복제본에 들어 있는 모든 CN을 이미 포함하고 있는 경우에만 이 0x10을 보냅니다. 요청을 보낸 저장소에서 다른 저장소에 데이터가 있음을 나타내는 0x10을 받아야 복제본이 삭제됩니다.

따라서 공용 폴더 인스턴스를 비우기 전에 저장소를 삭제하면 데이터가 손실될 수 있습니다. 2003 SP2 ESM에서만 이러한 작업이 방지되며, 이전 버전에서는 공용 폴더 인스턴스를 수동으로 확인해 저장소를 삭제해도 되는지를 결정해야 합니다. 공용 저장소를 삭제하기 전에는 항상 공용 폴더 인스턴스를 확인해야 하며, 2003 SP2 ESM에서 이 경고가 표시되면 경고를 무시하거나 문제 해결을 시도하는 대신 복제본 삭제 프로세스의 문제를 해결해야 합니다.

Exchange 2003 SP2 이전 버전에서는 복제본 목록에서 제거된 서버가 RDPSR을 한 번만 보냅니다. 여기에 응답하는 서버가 없는 경우에는 저장소를 복제본 목록에 다시 추가했다가 다시 제거하여 새 RDPSR을 발송할 때까지 폴더가 공용 폴더 인스턴스에 계속 유지됩니다. 2003 SP2에서는 이 동작이 변경되어 저장소가 다른 저장소에서 RDPA를 받을 때까지 1시간마다 작업을 다시 시도합니다.

문제 해결

이 문제 해결 과정은 백필 프로세스와 거의 동일합니다.

1. 삭제 보류 중인 복제본이 0x20을 보냈는지 여부

복제본을 제거할 때 로깅이 이미 설정되어 있었던 경우가 아니면 0x20 발송 여부를 알 수 없습니다. 그러나 복제본을 다시 추가했다가 제거한 다음 응용 프로그램 로그에서 0x20을 확인할 수는 있습니다.

2. 0x20이 다른 복제본으로 배달되었는지 여부

다른 문제 해결 과정과 마찬가지로, 다른 복제본의 응용 프로그램 로그에서 0x20 수신 여부를 확인합니다.

3. 다른 복제본에서 0x10으로 응답했는지 여부

가장 주의를 기울여야 하는 과정입니다. 복제본이 삭제 보류 중인 복제본에서 0x20을 받았는데 0x10으로 응답하지 않은 경우 삭제 보류 중인 복제본에 다른 복제본에는 없는 데이터가 포함되어 있는 것입니다. 이 복제본이 해당 복제본에서 0x20을 받았다는 것은 확인되었으므로 어떤 데이터가 누락되었는지도 이미 알고 있는 상태일 것입니다. 따라서 24~48시간마다 해당 폴더에 대한 백필 요청을 확인해야 합니다. 응용 프로그램 로그를 파악한 다음 앞서 설명한 일반 백필 프로세스와 정확히 동일한 방식으로 문제를 해결합니다.

4. 삭제 보류 중인 복제본에서 0x10을 받았는지 여부

모든 데이터를 포함하고 있는 다른 복제본은 0x10으로 응답해야 합니다. 삭제 보류 중인 복제본은 해당 0x10을 받으면 최종적으로 데이터를 삭제합니다. 그러나 데이터가 즉시 삭제되지는 않습니다. 즉, 해당 복제본을 사용 중인 클라이언트가 있으면 나중에 온라인 유지 관리를 수행할 때까지는 데이터가 삭제되지 않습니다. 원하는 경우 저장소를 분리했다가 다시 탑재해 클라이언트 연결을 끊는 방법으로 데이터를 즉시 삭제할 수 있습니다.

일반 문제

서버에서 특정 유형의 복제 메시지를 다른 서버로 보냈는데 수신 서버가 들어오는 메시지를 응용 프로그램 로그에 기록하지 않는 경우가 있습니다. 그러나 메시지 추적에서는 해당 메시지가 수신 서버의 저장소에 로컬로 배달되었다고 표시됩니다. 이러한 동작이 발생하는 경우 대개 복제 상태 테이블에 문제가 있거나 SMTP 가상 서버에 사용 권한 문제가 있는 것입니다.

비교적 단순한 문제부터 먼저 설명하겠습니다. 들어오는 복제 메시지가 수신 서버에서 무시되는 경우 복제 상태(ReplState) 테이블에 문제가 있는 것입니다. ReplState 테이블에 문제가 있으면 서버에서 일부 폴더에 대해 백필 요청(0x8)을 실행하지 못할 수도 있으므로, 이 정보는 해당 상황에도 적용됩니다. 각 공용 저장소는 해당 ReplState 테이블을 사용하여 복제된 폴더의 복제 상태를 추적합니다. 이 테이블에는 각 폴더에 대해 여러 행(복제본당 행 하나)이 포함되는데, ReplState 테이블의 행이 복제본 목록과 동기화되지 않아 행이 추가로 포함되거나 누락될 수 있습니다. 복제본 목록에서 서버를 제거하고 변경 내용을 적용한 다음 서버를 즉시 다시 추가하는 등의 변경 작업만으로 테이블을 다시 동기화할 수도 있지만, 이러한 작업이 항상 가능한 것은 아닙니다. 이 작업을 위해 isinteg에 ReplState 테스트가 추가되었습니다. Exchange 2003의 경우KB889331을, Exchange 2000의 경우 KB892485를 참조하십시오. 업데이트된 isinteg.exe 및 store.exe가 있으면 isinteg를 사용하여 ReplState 테이블의 문제를 해결할 수 있습니다. ReplState 테스트만 실행하는 경우에는 대개 속도가 매우 빨라서 공용 저장소가 매우 커도 실행 시간이 1분 미만입니다. isinteg를 실행한 후에도 ReplState 테이블을 복제본 목록과 동기화하려면 이전 단계로 돌아가 폴더를 변경해야 할 수 있습니다. 복제본 목록과 테이블이 동기화되면 서버에서 들어오는 복제 메시지를 처리하거나 백필 요청을 정상적으로 실행할 수 있습니다.

들어오는 복제 메시지가 무시되도록 하는 또 다른 일반적인 문제는 Exchange 2003 관련 문제입니다. Exchange 2003 서버의 경우 메시지를 보내는 서버가 받는 SMTP 가상 서버에 대해 다른 사람 이름으로 보내기 권한을 가지고 있어야 합니다. 즉, ServerA가 Exchange 2003 서버이고 ServerB가 PF 복제 메시지를 ServerA로 보내는 경우 ServerB에는 ServerB의 SMTP 가상 서버에 대한 다른 사람 이름으로 보내기 권한이 있어야 합니다. 그렇지 않으면 ServerA가 들어오는 복제 메시지를 처리하지 않습니다. 이 사용 권한은 보통 Exchange Domain Servers 그룹을 통해 부여됩니다. 다른 사람 이름으로 보내기 권한에 문제가 있는 경우 특정 서버에서 들어오는 모든 복제 메시지를 받을 수 없게 됩니다. 복제 메시지를 서버 간에 전송하는 중에 네트워크 추적을 통해 이 문제를 쉽게 파악할 수 있습니다. 이 경우 표시되는 메시지는 다음과 같습니다.

ServerA: 220 ServerA.microsoft.com Microsoft ESMTP MAIL Service…

ServerB: EHLO ServerB.microsoft.com

ServerA: 250-ServerA.microsoft.com Hello

         250-TURN

         250-SIZE

         250-ETRN

         250-PIPELINE

         250-DSN

         250-ENHANCEDSTATUSCODES

         250-8bitmime

         250-BINARYMIME

         250-CHUNKING

         250-VRFY

         250-X-EXPS GSSAPI NTLM LOGIN

         250-X-EXPS=LOGIN

         250-AUTH GSSAPI NTLM LOGIN

         250-AUTH=LOGIN

         250-X-LINK2STATE

         250-X-EXCH50

         250 OK

여기서 중요한 사항은 ServerA에서 GSSAPI NTLM LOGIN 옵션을 보급해야 한다는 것입니다. EHLO에 대한 ServerA의 응답에 이 항목이 표시되지 않으면 대개 SMTP 가상 서버에서 Windows 통합 인증을 선택하지 않은 것입니다. KB843106(영문일 수 있음)의 1단계와 KB842273(영문일 수 있음)의 3단계에 여기에 대한 설명이 있습니다. 이러한 인증 동사가 표시되면 ServerB에서는 해당 인증을 사용합니다.

ServerB: X-EXPS GSSAPI

ServerA: 334 GSSAPI supported

ServerB: <a bunch of base64 encoded data>

ServerA: 334 <more base64 encoded stuff>

ServerB: CRLF

ServerA: 235 2.7.0 Authentication successful.

인증이 실패하는 경우에는 Kerberos 또는 ServerB의 컴퓨터 계정에 문제가 있을 수 있습니다. 그 후에 서버에서는 상태 정보를 전송한 다음 전자 메일 전송 작업을 완료합니다.

ServerB: MAIL FROM:<ServerB-IS@microsoft.com>

ServerA: 250 2.1.0 ServerB-IS@microsoft.com….Sender OK

ServerB: RCPT TO:<ServerA-IS@microsoft.com> NOTIFY=NEVER

ServerA: 250 2.1.5 ServerA-IS@microsoft.com

ServerB: XEXCH50 2404 2

ServerA: 354 Send binary data

이 메시지는 XEXCH50 동사에 대한 마지막 응답으로, 자세히 확인해야 합니다. 응답이 “354 Send binary data”이면 SMTP 가상 서버에 대한 사용 권한에 관해서는 문제가 없습니다. GSSAPI NTLM 로그인 옵션이 보급되지 않았거나 인증 시도가 실패한 경우에는 ServerA에서 대신 “504 Need to authenticate”로 응답합니다. 이러한 단계가 성공했는데 ServerA에서 “354 Send binary data”가 아닌 “504 Need to authenticate”로 응답하는 경우에는 ServerB가 ServerA의 SMTP 가상 서버에 대한 다른 사람 이름으로 보내기 권한을 가지고 있지 않은 것입니다. 이러한 현상은 다양한 방식으로 나타날 수 있습니다. 예를 들어 ESM에서 Exchange 전체 관리자 등의 권한을 위임하면 해당 사용자나 그룹은 다른 사람 이름으로 보내기 권한에 대한 거부 권한을 상속합니다. 따라서 ESM을 통해 컴퓨터 계정, Exchange Domain Servers 그룹 또는 Exchange 서버를 포함하는 일부 다른 그룹에 대한 관리 권한을 위임하면 공용 폴더 복제가 중단됩니다. 또한 컴퓨터 계정이 Exchange Domain Servers 그룹에 포함되어 있지 않을 수도 있습니다. 컴퓨터 계정은 보통 Exchange Domain Servers 그룹에 포함되는 방식을 통해 다른 사람 이름으로 보내기 권한을 얻습니다. SMTP 가상 서버에 대한 사용 권한을 평가하고 보내는 서버의 컴퓨터 계정에 적절한 권한이 없는 이유를 확인해야 합니다. “504 Need to authenticate” 문제에 대한 자세한 내용은 KB843106(영문일 수 있음)KB842273(영문일 수 있음)을 참조하십시오.

결론

이 문서를 진행하면서, Exchange 2003 SP2에는 복제 문제를 방지하고 문제 해결을 지원하는 여러 주요 향상 기능이 포함되어 있음을 확인하셨을 것입니다. 공용 저장소가 여러 개인 환경의 경우 SP2는 큰 이점을 제공하며, 특히 서버 간에 복제본을 이동하고 공용 저장소를 추가 및 제거하는 경우 SP2를 사용하면 매우 편리합니다.

이 게시물 시리즈가 도움이 되었기를 바랍니다. 게시물을 검토해 주신 Dave Whitney에게 감사의 인사를 전합니다.

Bill Long

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Public Folder Replication Troubleshooting – Part 3: Troubleshooting Replica Deletion and Common Problems를 참조하십시오.


Comments (0)

Skip to main content