Active Directory: 복제가 error 1722(The RPC server is unavailable)로 실패

안녕하세요, BlueByte입니다. 어제까지 멀쩡히 복제되던 도메인 컨트롤러가 이제 모든 확인 명령에 The RPC server is unavailable.로 답하고, repadmin /replsummary에는 status 1722 실패가 쌓입니다. 무언가 죽은 것은 아닙니다 — RPC가 source DC로 연결을 열지 못했다고 보고하는 것이고, 실제 원인은 거의 항상 RPC보다 아래 계층에 있습니다. 오늘은 이 오류가 어디에 나타나는지, 실제로 무엇을 알려주는지, 원인을 가르는 확인 절차, 원인별 해결, 그리고 새 사이트가 같은 곳에 다시 빠지지 않게 하는 법까지 하나씩 짚어보겠습니다.

1722가 나타나는 자리와 도구별 표현

하나의 status, 네 가지 얼굴입니다. repadmin이 가장 명확합니다:

C:\> repadmin /showrepl
==== INBOUND NEIGHBORS ======================================
DC=contoso,DC=com
    HQ-SITE\DC01 via RPC
        Last attempt @ 2026-09-25 09:41:12 failed, result 1722 (0x6ba):
        The RPC server is unavailable.
        7 consecutive failure(s).
        Last success @ 2026-09-24 22:10:03

repadmin /replsum·/showreps·/syncall 모두 같은 1722 (0x6ba)를 인용하며, /syncall은 이를 network error로 표현합니다. dcdiag는 Replications 테스트를 실패로 처리하고 DsBindWithSpnEx() failed with error 1722를 덧붙입니다. Active Directory Sites and Services의 Replicate Now는 DNS 조회 문제를 가리키는 문구로 끝나는 대화 상자를 띄웁니다 — 실제로 상당수가 DNS이기 때문에 쓸모 있는 힌트입니다. 복제 DC를 승격할 때는 helper DC에 NTDS Settings 개체를 만들려는 시점에서 실패합니다. Directory Service 이벤트 로그에서는 같은 status가 NTDS KCC 1311·1865·1925, NTDS Replication 1960, ActiveDirectory_DomainService 1125 뒤에 숨어 있습니다.

원인은 아래 계층인데 RPC가 1722를 보고하는 이유

RPC는 네트워크 전송과 응용 프로토콜 사이의 중간 계층이고, 실패 자체를 들여다보는 능력은 없습니다 — 하위 계층의 프로토콜 실패를 RPC 계층의 오류로 매핑할 뿐입니다. 1722 / 0x6ba / RPC_S_SERVER_UNAVAILABLE는 하위 계층 프로토콜이 연결 실패를 보고했을 때 기록되며, 대표적인 경우는 TCP connect 자체가 실패한 것입니다. Microsoft가 제시하는 원인 목록은 link local failure, DHCP failure, DNS failure, WINS failure, 방화벽 차단 포트를 포함한 routing failure, IPSec·네트워크 인증 실패, 리소스 한계, 그리고 상위 계층 프로토콜 미기동입니다. 실무에서는 순서대로 검증할 수 있는 세 갈래로 좁혀집니다: 이름 해석, 차단된 포트, 두 DC 중 한쪽의 호스트 설정.

어느 파트너·어느 파티션이 실패하는지 먼저 특정하기

destination DC에서 시작합니다 — 실패하는 RPC 클라이언트가 있는 쪽이기 때문입니다:

repadmin /replsummary
repadmin /showrepl * /csv > C:\temp\showrepl.csv
nltest /dsgetdc:contoso.com /force

/replsummary는 DC별 최대 지연을 보여주고, CSV는 한 파트너만 실패하는지 전부 실패하는지 드러냅니다. 이 구분이 다음 행동을 정합니다. 한 파트너만 실패하면 특정 두 DC 사이의 경로 문제이고, 모든 파트너가 실패하면 destination 자신 — NIC, DNS 설정, 자체 호스트 방화벽 — 을 봐야 합니다.

방화벽을 건드리기 전에 DNS부터 배제하기

이름 해석 실패는 1722 복제 오류에서 큰 비중을 차지하므로 먼저 확인합니다. 아무것도 바꾸지 않는 점검이니 겁먹지 않아도 됩니다:

dcdiag /test:dns /v /e /f:C:\temp\dns.log
ping -a 10.20.4.11

dcdiag /test:dns는 authentication·basic·forwarders·delegation·dynamic update·record registration 그룹을 모든 DC에 대해 실행한 뒤 PASS/FAIL 표와 조치 안내를 출력합니다. ping -a는 전형적인 사례를 잡아냅니다 — 몇 달 전 폐기한 장비를 가리키는 낡은 host 레코드입니다. 복제는 source DC의 GUID 기반 CNAME(_msdcs 하위)으로 바인딩하므로, 그 별칭이 없거나 glue 레코드가 다른 곳을 가리키면 일반 클라이언트 트래픽은 멀쩡해 보이는데 바인딩만 전부 실패합니다.

endpoint mapper와 동적 포트 범위 전체를 확인하기

endpoint mapper는 TCP 135에서 대기하며 서비스가 어느 임의 포트에 있는지 클라이언트에 알려 줍니다. 그래서 135만 열어서는 결코 충분하지 않습니다. Windows Server 2008 이후 기본 동적 범위는 49152–65535이고, Windows Server 2003이나 Windows 2000 DC가 남아 있는 혼합 모드 도메인은 1025–5000을 씁니다 — 오래된 문서에서 복사한 방화벽 규칙이 걸려 넘어지는 지점입니다.

Test-NetConnection -ComputerName DC01.contoso.com -Port 135
netsh int ipv4 show dynamicport tcp

ComputerName     : DC01.contoso.com
RemoteAddress    : 10.20.4.11
RemotePort       : 135
TcpTestSucceeded : True
 
Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384

135는 응답하는데 복제는 계속 실패한다면, mapper는 허용하고 상위 포트는 버리는 방화벽의 전형적인 신호입니다. 포트 하나 확인으로 부족할 때는 Microsoft의 portqry가 범위 전체를 훑습니다 — portqry -n DC01 -r 49152-65535 — 다만 별도로 내려받아야 하는 도구입니다. 범위 전체 개방이 어렵다면, 동적 범위 자체를 좁히는 대신 문서화된 레지스트리 값으로 AD 복제를 특정 포트에 고정하는 방법이 지원됩니다.

네트워크 점검으로는 잡히지 않는 호스트 쪽 원인 두 가지

DNS가 해석되고 포트도 열려 있다면 DC 자체로 눈을 돌립니다. 첫째는 RPC 클라이언트 프로토콜입니다. HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc 아래 ClientProtocols 키가 있어야 하고, ncacn_http·ncacn_ip_tcp·ncacn_np·ncacn_ip_udp 네 개의 REG_SZ 값이 각각 rpcrt4.dll을 가리켜야 합니다. 키나 값 중 하나라도 없으면 정상 서버에서 가져와 import합니다.

Get-ItemProperty "HKLM:\Software\Microsoft\Rpc\ClientProtocols"

둘째, DC 간 SMB signing 불일치도 같은 증상을 만듭니다. 문서화된 해법은 장비마다 손으로 맞추는 대신 Default Domain Controllers Policy의 Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options에서 일관된 설정을 내려보내는 것입니다. 목록에 둘 더 있습니다. UDP fragmentation은 RPC 실패처럼 보이는 복제 오류로 드러나는데 LSASRV 40960·40961 이벤트가 단서이고, Kerberos를 TCP로 강제하는 것이 문서화된 대응입니다. 그리고 불량 NIC 드라이버 — 최근 드라이버 업데이트가 있었다면 변경 이력에 함께 올려 두세요.

사례: 오래된 방화벽 규칙 뒤에 놓인 새 지사 사이트

목요일에 새 사이트로 지사 DC를 승격합니다. 승격은 성공하는데 금요일이 되니 repadmin /replsummary가 허브 DC 두 대 모두에 대해 1722를 보여줍니다. 그러면서도 지사 DC는 사용자 인증을 정상으로 처리합니다. 모든 파트너가 실패하므로 destination을 의심하고 DNS부터 봅니다 — dcdiag /test:dns는 통과하고 ping -a도 허브 DC를 정확히 해석합니다. Test-NetConnection -Port 135도 성공합니다. 바로 이 지점이 이 사례를 헷갈리게 만듭니다. mapper가 응답하니 방화벽은 무고해 보이니까요. 이어서 netsh int ipv4 show dynamicport tcp가 양쪽 모두 시작 포트 49152를 보고하는데, 2012년 문서에서 복사한 사이트 간 규칙은 1025–5000만 허용하고 있었습니다. 규칙을 양방향 49152–65535로 넓히자 해결되고, 이어서 실행한 repadmin /syncall /AdeP가 1분 안에 수렴합니다.

복제가 수렴하는지 확인하고, 포트를 문서로 남기기

확인은 명령 하나와 후속 하나입니다:

repadmin /syncall /AdeP
repadmin /replsummary

/syncall /AdeP는 모든 파티션에 변경을 밀어 넣고 파트너별 결과를 보고하며, /replsummary의 최대 지연은 다음 주기에 늘지 않고 0을 향해 줄어야 합니다. 독립적인 확인으로 dcdiag /test:replications를 한 번 더 돌려 보세요. 예방은 대부분 문서화입니다. DC가 실제로 쓰는 동적 범위를 기록하고, DC 간 방화벽 규칙은 옛 도메인에서 물려받은 범위 대신 49152–65535로 작성하고, repadmin /replsummary를 기존 모니터링에 넣습니다. 복제 장애는 본래 조용하고, 조용한 장애가 비싼 장애입니다.

KCC 토폴로지 이벤트·깨진 신뢰 관계와 무엇이 다른가

1722 없이 KCC 1311이나 1865만 찍힌다면 전송이 아니라 토폴로지 문제입니다 — site link나 subnet 구성이 잘못되어 KCC가 완전한 spanning tree를 만들지 못한 것이고, 방화벽을 아무리 손봐도 나아지지 않습니다. 반대로 멤버 서버가 도메인과의 신뢰 관계가 실패했다고 호소한다면, 그것은 컴퓨터 한 대의 machine account 암호 문제이지 DC 간 경로 문제가 아닙니다 — repadmin 출력에는 나타나지 않습니다.

다음에 복제가 1722에서 멈추면 이 순서를 거꾸로 따라가 보세요. repadmin이 지목한 파트너와 파티션, DNS가 source DC의 _msdcs 별칭을 올바른 호스트로 해석하는지, 135와 동적 범위가 양방향으로 열려 있는지, 그리고 그 다음에야 DC 자체를 살펴보는 순서입니다.