How IT WorksRPC 오류 문제 해결

Zubair Alexander

다년간 Windows 서버 플랫폼을 사용했다면 RPC(원격 프로시저 호출) 오류를 한두 번 정도는 경험했을 것입니다. RPC 오류는 RPC 서버를 사용할 수 없거나 사용 가능한 끝점이 더 이상 없음을 알려 주며, 그 외에 의미를 이해하기 어려운 경고를 제공하기도 합니다. 이러한 메시지의 의미가 혼동된다면 이 문서를 읽어 보십시오.

이 문서에서는 몇 가지 일반적인 RPC 오류와 이러한 RPC 오류를 식별하는 데 사용할 수 있는 여러 가지 방법을 살펴본 다음 특정한 문제에 대한 해결책을 설명하겠습니다. RPC 오류 및 해결 방법에 대해 구체적으로 설명하기에 앞서 RPC 관련 용어의 의미를 정확하게 짚어 보기로 하겠습니다.

RPC 개요

RPC는 클라이언트와 서버가 통신하는 데 사용되는 IPC(프로세스 간 통신) 기술입니다. 간단히 말해, RPC는 일반적으로 클라이언트 컴퓨터에 설치된 프로그램이 서버 컴퓨터에 설치된 프로그램을 실행하기 위해 사용하는 기술입니다. 예를 들어 Microsoft® Outlook® 클라이언트는 RPC를 통해 Microsoft Exchange Server와 통신합니다. 클라이언트 컴퓨터는 특정 인수를 사용하여 서버 컴퓨터에 메시지를 보냅니다. 서버는 실행된 프로그램에 대한 결과가 들어 있는 메시지로 클라이언트에 응답합니다.

이 프로세스에서 가장 중요한 것은 끝점입니다. 끝점은 서버가 들어오는 클라이언트 요청에 대해 모니터링하는 대상 컴퓨터의 포트 또는 포트 그룹을 의미합니다. 좀 더 구체적으로 말하자면 끝점은 RPC에 사용되는 서버 프로세스의 네트워크 주소입니다.

RPC 하위 시스템의 일부인 끝점 매퍼는 클라이언트 요청에 응답하여 동적 끝점을 확인하는 기능을 수행합니다. 끝점 매퍼가 서버에 끝점을 동적으로 할당하는 기능을 수행하는 경우도 있습니다.

또 한 가지 중요한 RPC 구성 요소는 로케이터 서비스입니다. 로케이터 서비스는 네트워크의 RPC 서비스 및 서버 목록을 유지 관리합니다. Windows® 클라이언트는 SMB(서버 메시지 블록) 포트(TCP 139 및 445)를 통해 도메인 컨트롤러에 연결한 다음, 로케이터 서비스를 통해 RPC 서비스 또는 서버를 검색합니다.

대부분의 Windows 기본 제공 서비스는 RPC를 통해 서로 통신합니다. 예를 들어 인증서 서비스, DCOM, FRS, MSMQ, MAPI, Active Directory® 복제 서비스 등이 RPC를 사용하여 통신합니다. 따라서 네트워크에서 RPC 서비스가 정상적으로 작동하지 않는 경우 수많은 통신 문제가 발생할 수 있습니다.

RPC 오류

이제 RPC 서비스에서 문제가 발생할 경우 나타나는 몇 가지 오류에 대해 살펴보겠습니다. 여기에서 설명하는 오류 외에도 더 많은 오류가 있습니다.

FRS(파일 복제 서비스)에서 문제가 발생한 경우에는 "RPC를 사용할 수 없음" 오류일 수 있습니다. 드라이브를 매핑하는 경우에는 "액세스 거부" 오류가 나타날 수 있습니다. Active Directory 사용자 및 컴퓨터를 사용하는 경우에는 "지정한 도메인이 없거나 연결할 수 없습니다"와 같은 오류 메시지가 나타날 수 있습니다. 도메인에 로그온하면 "주 도메인에서 시스템의 컴퓨터 계정을 찾을 수 없거나 해당 계정의 암호가 올바르지 않으므로 이 도메인에 로그온할 수 없습니다"와 같은 오류 메시지가 나타날 수 있습니다.

Microsoft Outlook 클라이언트가 Exchange Server와 통신하려고 시도할 때 RPC 오류로 인해 "로그온 정보가 올바르지 않습니다" 또는 "Outlook에 로그온할 수 없습니다"와 같은 잘못된 오류가 클라이언트에 표시될 수 있습니다.

RPC 서비스를 사용할 수 없는 경우에는 이러한 오류 외에도 추가적인 문제가 발생할 수 있습니다. 예를 들어 내 네트워크 환경에서 도메인을 찾을 수 없거나 그룹 정책 스냅인을 열지 못할 수 있습니다.

이것은 문제의 원인이 RPC에 있는 것으로 예상하지 못할 수 있는 몇 가지 예에 불과합니다. 이 외에도 많은 예가 있으며, 원격 프로세스와 관련된 문제가 발생하는 경우 RPC가 원인일 수 있습니다. 이제 문제를 확실하게 파악하는 방법과, 더 중요한 문제인 오류를 정확하게 추적하는 방법에 대해 살펴보겠습니다.

문제 해결

RPC 서비스에 문제가 있는 것으로 의심되는 경우 여러 가지 도구를 사용하여 문제를 진단할 수 있습니다.

그 중 하나가 Repadmin 도구입니다. 이 프로그램은 일반적으로 Active Directory 복제 문제를 모니터링하고 해결하는 데 사용되지만 RPC 끝점 매퍼의 문제를 해결하는 데도 사용할 수 있습니다. 이 도구를 실행하려면 명령 프롬프트에서 repadmin /bind를 입력합니다. RPC에 문제가 있으면 "끝점 매퍼에서 사용 가능한 끝점이 더 이상 없습니다"와 같은 메시지가 나타날 수 있습니다. 이 메시지는 RPC와 관련하여 문제가 있음을 나타내는 첫 번째 단서입니다.

또 다른 방법은 도메인 컨트롤러의 문제를 진단하기 위한 명령줄 프로그램인 도메인 컨트롤러 진단 도구(DCDiag)를 사용하는 것입니다. "상태 1722: RPC 서버를 사용할 수 없습니다"와 같은 오류 메시지가 나타나면 RPC 오류가 있으며 도메인 컨트롤러 진단 도구가 이 오류를 발견했음을 알 수 있습니다.

Active Directory를 관리하고 수많은 유지 관리 작업을 수행하는 데 사용하는 명령줄 도구인 Ntdsutil을 사용하는 경우 서버에 연결하려고 하면 종종 RPC 오류가 발생합니다. 이 경우 대개는 "끝점 매퍼에서 사용 가능한 끝점이 더 이상 없습니다"와 같은 일반적인 오류 메시지 중 하나가 나타날 수 있습니다. 이 역시 RPC 서비스에 문제가 있음을 나타내는 단서가 됩니다. 도메인 컨트롤러의 그룹 정책 개체 간의 일관성을 검사하는 Gpotool 도구 또한 RPC가 문제의 원인인 경우 이와 비슷한 오류 메시지를 표시합니다.

Dcpromo 도구를 사용하여 Windows 2000 Server 또는 Windows Server® 2003 서버를 도메인 컨트롤러로 승격할 때 생성되는 Dcpromo.log를 통해 RPC 문제를 확인할 수도 있습니다. 예를 들어 승격에 실패하면 이 로그를 한번 살펴봅니다. 이 로그는 %windir%\debug 폴더에 있습니다. 로그에 기록된 오류는 디렉터리 서비스가 파티션 복제에 실패했거나 개체 생성에 실패한 원인에 대한 정보를 제공합니다. 메시지 끝 부분에는 오류 코드가 있습니다. 다음은 Dcpromo.log에서 볼 수 있는 오류 메시지의 예입니다.

 
08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)

오류 코드 1722를 유의해서 보십시오. 이 오류 코드는 이 메시지에서 네 번 나오며 RPC 서버를 사용할 수 없음을 나타냅니다. 그림 1에서는 몇 가지 오류 코드와 설명을 보여 줍니다. 더 많은 오류 코드를 보려면 msdn2.microsoft.com/ms681386을 참조하십시오.

Figure 1 오류 코드 및 설명

RPC 오류 해결

앞에서는 몇 가지 RPC 오류를 찾는 방법을 살펴봤으므로 지금부터는 몇 가지 해결 방법에 대해 알아보겠습니다.

Microsoft 클라이언트는 포트 135의 RPC 끝점 매퍼에 연결합니다. 그러면 끝점 매퍼는 어떤 포트에서 요청된 서비스를 수신하는지 클라이언트에 알려 줍니다. 포트 번호는 1024에서 65,535 사이의 값 중에서 동적으로 할당됩니다. 끝점 매퍼에서 사용 가능한 끝점이 더 이상 없음을 나타내는 1753과 같은 오류 메시지가 나타나는 경우 이는 RPC 끝점 매퍼가 1024보다 큰 포트를 서비스에 사용할 수 없음을 의미합니다. 이에 대해서는 나중에 보다 자세히 살펴보겠습니다.

이때 가장 먼저 수행해야 할 작업은 서버의 RPC 서비스 상태를 확인하는 것입니다. 서버 역할의 유형에 따라 RPC 및 RPC 로케이터 서비스는 그림 2에 나열된 상태로 되어 있어야 합니다. 두 서비스 중 하나가 그림에 표시된 것처럼 구성되어 있지 않으면 상태를 조정하거나 서버를 다시 부팅하여 문제가 해결되는지 테스트합니다.

Figure 2 RPC 서비스 상태

클라이언트에서 연결 문제가 있는 서버에 성공적으로 Ping을 수행할 수 있는지 확인합니다. 예를 들어 IP 주소가 192.168.1.200인 DC1이라는 서버와 통신하는 데 문제가 있는 경우 명령 프롬프트에서 다음 명령을 사용하여 DNS가 호스트 DC1을 올바르게 확인하는지 살펴봅니다.

Ping –a 192.168.1.200

호스트 이름이 아닌 IP 주소와 함께 –a 스위치를 사용해야 합니다.

모든 것이 올바르게 작동하면 그림 3의 Ping 응답과 비슷한 응답을 DC1로부터 받게 됩니다. Ping은 IP 주소 192.168.1.200을 확인하는 데 그치지 않고 호스트 이름인 dc1.contoso.com도 확인합니다. 이로써 DNS 이름 확인이 올바르게 작동하며 호스트 dc1.contoso.com을 올바르게 확인한다는 것을 분명하게 알 수 있습니다.

Figure 3 Ping 응답

C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms

Windows XP 또는 Windows 2000 클라이언트의 레지스트리에 최소한 그림 4의 오른쪽 창에 있는 나열된 네 개의 ClientProtocols가 포함되어 있는지도 확인해야 합니다.

그림 4** 레지스트리에 나열된 RPC ClientProtocols **

이 항목 중 하나라도 없으면 그림 4에 표시된 이름 및 데이터 형식을 사용하여 새 문자열 값을 추가합니다. 기본적으로 여기에는 NetBIOS over TCP를 끝점에 대한 프로토콜 패밀리로 식별하는 데 사용되는 ncacn_nb_tcp라는 다섯 번째 항목이 있습니다. 사용자의 구성에 따라 ClientProtocols에 이 항목이 없을 수도 있습니다. 이 경우 이 항목을 수동으로 추가하여 RPC 오류가 해결되는지 확인합니다.

그림에서 왼쪽 창의 Rpc 폴더에 있는 키는 ClientProtocols, NameService, NetBios 및 SecurityService입니다. 아무 값도 지정되지 않은 Internet이라는 키가 있는 경우에는 이 키를 제거하고 컴퓨터를 다시 시작합니다. 이렇게 하면 문제가 해결될 수도 있습니다. 언제나 그렇듯이 Windows 레지스트리를 수정할 때는 세심한 주의를 기울여야 합니다.

앞에서 언급했듯이 RPC는 1024에서 65,535 사이의 포트를 사용할 수 있으므로 이러한 포트가 방화벽으로 차단되지 않았는지 확인해야 합니다. 포트가 열려 있는지 확인하는 가장 쉬운 방법은 포트 쿼리 도구를 사용하는 것입니다. 이 도구는 명령줄 버전(PortQry)과 GUI 버전(PortQueryUI)으로 제공됩니다.

PortQry는 Microsoft 다운로드 센터에서 다운로드할 수 있습니다. 자세한 내용은 "Portqry.exe 명령줄 유틸리티에 대한 설명"을 참조하십시오. 이 문서에서는 PortQry 상태 보고서에 대해 간략하게 설명하고 문제를 해결하는 데 사용할 수 있는 몇 가지 명령을 예로 보여 줍니다. 훨씬 간단한 GUI 버전을 사용할 수도 있습니다. 이 도구는 go.microsoft.com/fwlink/?LinkId=73740에서 다운로드할 수 있습니다.

포트 쿼리 도구는 RPC 오류가 발생하지 않은 컴퓨터에서 RPC 오류가 발생한 컴퓨터를 대상으로 지정하여 실행해야 합니다. 예를 들어 RPC 끝점 매퍼가 사용하는 포트 135가 열려 있는지 확인하려면 명령 프롬프트에서 다음과 같이 PortQry를 사용합니다.

portqry -n [servername] -e 135

PortQry와 PortQueryUI 중 어떤 버전을 사용하든 다음과 같은 결과가 나타납니다.

Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING

마지막 줄은 포트 135가 열려 있음을 보여 줍니다. 포트 135가 열려 있지 않으면 마지막 줄에 NOT LISTENING이 표시됩니다.

포트 범위가 열려 있는지 확인하려면 "135,1024-5000"과 같이 포트 번호 범위를 쉼표로 구분하여 입력합니다.

추가 해결 방법

지금까지 설명한 모든 방법을 시도했지만 문제가 여전히 해결되지 않은 경우 또 다른 방법을 사용할 수 있습니다. 사용자 환경에서 발생한 구체적인 문제에 따라 다음 중 한 가지 방법으로 레지스트리를 수정해 볼 수 있습니다. 그 전에 한 가지 주의해야 할 사항이 있습니다. 레지스트리를 변경하기 전에 시스템, 특히 레지스트리를 백업해 두었는지 반드시 확인해야 합니다. 이렇게 하면 무엇인가 잘못되더라도 컴퓨터를 이전 상태로 복원할 수 있습니다.

한 가지 방법은 응용 프로그램이 시스템에서 사용 가능한 사용자 포트를 요청하는 경우 TCP가 할당할 수 있는 가장 높은 포트 번호를 지정하도록 MaxUserPort를 수정하는 것입니다. 기본적으로 Windows Server 2003에서는 MaxUserPort 값이 5000으로 설정됩니다. 이는 가장 높은 포트 번호로 5000이 사용된다는 것을 의미하며 이 레지스트리 항목이 없는 경우에도 이 값이 사용됨을 나타냅니다. 사용자 구성에 따라 레지스트리에 이 항목이 없을 수도 있습니다. 이 경우 그림 5에 표시된 위치에 이 항목을 추가할 수 있습니다.

그림 5** 레지스트리의 MaxUserPort 설정 **

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000

레지스트리를 수정할 때는 해결하기 어려울 수도 있는 다른 부작용의 발생 가능성에 대해 주의해야 합니다. 이 항목을 수정하여 값을 50,000 미만으로 설정하면 Microsoft Exchange Server에 영향을 줄 수 있습니다. Exchange Server Best Practices Analyzer(BPA)는 MaxUserPort 레지스트리 키 값이 50,000 미만임을 발견한 경우 경고 메시지를 표시합니다. 이 값은 60,000으로 설정하는 것이 좋습니다. 그렇지 않으면 이벤트 9040과 같은 NSPI(Name Service Provider Interface) 프록시 경고 메시지가 나타날 수 있습니다. 자세한 내용은 Microsoft에서 제공하는 "MaxUserPort 값이 너무 낮음" 문서를 참조하십시오.

TcpMaxDataRetransmissions를 수정할 수도 있습니다. TCP 패킷은 수신 측으로부터 승인을 기다립니다. 타이머가 만료되기 전에 승인을 받지 못하면 TcpMaxDataRetransmissions 횟수에 도달할 때까지 패킷이 다시 전송됩니다. 이 매개 변수의 기본값은 5이지만 값을 4 또는 3으로 지정할 수도 있습니다. 3보다 작은 값은 사용하지 마십시오.

TcpMaxDataRetransmissions 레지스트리 항목이 없으면 레지스트리의 다음 위치에 다음과 같이 항목을 추가할 수 있습니다.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5

TcpMaxDataRetransmissions에 대한 자세한 내용은 Microsoft 기술 자료 문서 170359 "TCP/IP 최대 재전송 시간 제한을 수정하는 방법"을 참조하십시오.

TcpTimedWaitDelay 레지스트리 값을 수정할 수도 있습니다. 클라이언트가 포트를 너무 많이 사용하는 경우 TCP/IP가 닫힌 연결을 해제하기 전에 사용 가능한 포트가 남지 않을 수 있습니다. 이는 TCP/IP가 두 개의 MSL(Maximum Segment Life)이 끝날 때까지 연결을 해제하지 않기 때문인데, 이를 시간 대기 상태라고 합니다. 뿐만 아니라 각 MSL은 120초로 정의되는데, TCP/IP는 두 MSL이 끝날 때까지 연결을 해제하지 않으므로 TCP/IP가 닫힌 연결을 해제하는 데 최대 240초(4분)가 걸리게 됩니다. 이는 Windows NT®의 알려진 문제이며 서비스 팩을 통해 이미 해결되었으므로 현재는 이러한 문제가 발생할 가능성이 매우 낮습니다. 하지만 RPC 끝점 매퍼 오류를 해결하기 위한 해결 방법 중 하나로 이 설정을 수정하는 것이 좋습니다. 이에 대한 자세한 내용은 기술 자료 문서 "RPC 끝점 매퍼 오류 문제를 해결하는 방법"을 참조하십시오.

TcpTimedWaitDelay는 레지스트리의 다음 위치에 추가됩니다.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD 
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)

TcpTimedWaitDelay에 대한 자세한 내용은 기술 자료 문서 "Windows NT 클라이언트의 포트 부족"을 참조하십시오. 이 문서에서는 특정한 값을 권장하지 않지만 TcpTimedWaitDelay를 60(10진수, 단위: 초) 또는 3c(16진수)로 줄이는 것이 좋습니다.

결론

RPC 오류는 네트워크에서 발생하는 수많은 통신 오류의 근본 원인일 수 있습니다. 다행히 이러한 까다로운 문제를 해결하는 데 사용할 수 있는 다양한 독창적인 방법이 있습니다. 이 문서에서 소개한 일부 도구는 기본적으로 제공되며 다른 도구는 Windows Server Resource Kit에서 사용할 수 있습니다. 대부분의 도구는 그림 6에 나와 있습니다. 이러한 도구를 사용하여 RPC 오류의 원인과 오류가 발생한 위치를 찾은 다음, 이 문서에서 제시한 방법 중 하나를 통해 해결할 수 있습니다.

Figure 6 RPC 문제 해결 도구

Zubair Alexander는 MCSE, MCT 및 Microsoft MVP이자 IT 교육 및 컨설팅 회사인 SeattlePro Enterprises의 소유주입니다. 또한 저자, 대학 강사, 컨설턴트, 네트워크 엔지니어, 강연자, 보안 설계자, 시스템 관리자, 기술 문서 편집자, 교육 담당자 등 IT 교육 분야에서 다양한 경력을 쌓고 있습니다. 문의 사항이 있으면 alexander@techgalaxy.net으로 연락하십시오.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..