이번 Post에서는 Exchange 관리도구, 관리콘솔 및 관리쉘(Exchange Management Tool, Exchange Management Shell)을 오픈 시도할 때 발생될 수 있는 가장 일반적인 에러 메시지들에 대하여 확인해 보고자 합니다.
내용을 설명하기에 앞서 우선 Exchange 2010에서 모든 Management는 Remote PowerShell을 이루어진다는 것을 인지하고 있으셔야 합니다. 물론 Exchange 서버 자체에서 관리도구를 실행한다고 하여도 마찬가지로 Remote Powershell 을 통해서 이루어집니다.
Exchange 2010의 관리와 관련된 부분이 Exchange 2007서버에서의 그것과 다른 점은 Remote Powershell 의 요청프로세스가 HTTP프로토콜을 통해서 이루어지고 이러한 연결을 위한 메커니즘으로 IIS 를사용하기 때문에 IIS 에 크게 의존한다는 부분입니다. 그리고 IIS는 연결을 만들기 위해서 WinRM(Windows Remote Management)서비스 및 WSMan(Web Service for Management) 프로토콜과 함께 동작합니다.
여러분이 Exchange 관리쉘 바로가기를 클릭하게 되면 이때 Remote PowerShell 세션이 열립니다.
Exchange 2007에서처럼 단순히 Exchange 스냅인을 오픈하는 것이 아니고 PowerShell은 WinRM프로토콜을 통해서 가장 가까운 Exchange 2010서버로 IIS를 통해서 연결을 만들게 됩니다.
이때 WinRM은 사용자 인증을 검사하고 원격세션을 만든 후 RBAC(Role Based Access Control)에 기반하여 접근 권한이 있다면 명령셋을 사용자에게 보여주게 됩니다.
아래 그림을 보시면 이해가 되실 겁니다 
모든 Remote Powershell은 IIS를 통하여 연결하게 되기 때문에 우리는 Exchange 관리도구들을 시작할때 나타날 수 있는 일반적인 오류메시지들과 이러한 오류들이 무엇을 나타내고 있는지에 대하여 알아야 할 필요가 있습니다.
이슈 1
다음과 같은 메시지와 함께 Remote Server연결 실패 :
The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic.
예상 가능한 원인
1. Remote PowerShell 은 연결되는 사용자를 인증하기 위해서 Kerberos 방식을 사용합니다.
IIS는 또한 네이티브 모듈( Native Module)을 통해서 Kerberos 인증방식을 사용합니다. IIS관리자에서 PownerShell 가상 디렉토리로 이동한 뒤 모듈을 확인하면 네이티브 모듈로 C:\Program Files\Microsoft\Exchange Server\v14\B in\kerbauth.dll 로 지정된 Kerbauth 목록을 보실 수 있습니다.
만약, Kerbauth 모듈이 네이티브 모듈이 아닌 관리되는 모듈(Managed Module)로 보이거나 또는 Kerbauth 모듈이 PowerShell 가상 디렉토리가 아닌 Default Web Site 레벨에서 로드 되어 있다면 위와 같은 오류메시지가 나타날 수 있습니다.
이러한 문제를 해결하기 위해서는 Kerbauth 모듈이 기본 웹사이트에서 Enable되어있지 않아야 하며 PowerShell 가상 디렉토리에서 Enable 되어있어야 합니다.
또한 항목 유형은 부모레벨에서의 상속이 아닌 로컬(Local)로 지정되어 있어야 합니다.
2. WSMan 모듈 entry 가 아래 c:\Windows\System32\Inetsrv\config\ApplicationHost.config 파일에서 Global Modules 세션에서 존재하지 않는다면 PowerShell 가상 디렉토리에서 모듈종류가 관리되는 모듈로 보여질 수 있습니다. 
이 문제를 해결하기 위해서는 WSMan 모듈이 Server level에서 등록되고(하지만 Enable되어있지 않음) PowerShell 가상 디렉토리에서 Enable되어있는지 확인해야 합니다.
3. 연결을 시도하는 사용자가 Remote PowerShell Enabled된 사용자로 구성되어있지 않을 경우.
사용자계정에 Remote PowerShell이 Enable되어있는지 확인하고자 한다면 다른 Enable되어있는 사용자 계정으로 로그인한 다음 Exchange 관리쉘을 열고 아래 Query를 실행합니다.
(Get-User <username>).RemotePowershellEnabled 
결과는 True 또는 False를 리턴하며 만약 False로 나타난다면 해당 사용자 계정은 RemotePowerShell 사용자로 Enable되어 이지 않음을 의미합니다.
Enable하기 위해서는 아래 명령어를 실행하시면 됩니다.
Set-User <username> –RemotePowerShellEnabled $True
이슈 2
다음과 같은 메시지와 함께 Remote Server연결 실패 :
The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available.
This is usually returned by a HTTP server that does not support the WS-Management protocol.
For more information, see the about_Remote_Troubleshooting Help topic.
예상 가능한 원인
1. HTTP 바인딩이 Default web site에서 제거되었을 경우.
가장 일반적인 시나리오로는 여러개의 웹사이트가 IIS 서버에서 운영되고 있고 SSL만을 허용하기 위해서 기본 웹사이트에서 리디렉션(Redirect) 설정으로 https://mail.company.com/owa으로 설정되어 있고 이로 인해 SSL연결만을 허용하는 다른 웹사이트로 리디렉션 설정이 되어있을 경우입니다.
Remote PowerShell은 기본 웹사이트(Default web site)에 포트번호 80을 연결이 필요합니다.
혹시 자동으로 리디렉션 설정을 통해서 http 요청을 https 연결로 리디렉션하고 /OWA 디렉토리로 리디렉션 설정을 하고자 한다면
http://technet.microsoft.com/ko-kr/library/aa998359(EXCHG.80).aspx 문서에서 “IIS 7.0에서 기본 웹 사이트 또는 OWA 가상 디렉터리에 SSL이 필요한 구성의 경우” 섹션을 참고하여 설정해 주시면 됩니다.
2.기본웹사이트의 HTTP 바인딩 설정이 변경되었고 호스트헤더가 구성되어있을 경우.
이 경우 Default web site 80포트 바인딩아래에 있는 호스트이름을 제거해야 합니다.
이슈3
다음과 같은 메시지와 함께 Remote Server연결 실패 :
The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'.
추가로 시스템 이벤트로그에 다음과 같은 경고 메시지가 기록됨
Source: Microsoft-Windows-WinRM
EventID: 10113
Level: Warning
Description: Request processing failed because the WinRM service cannot load data or event source: DLL="%ExchangeInstallPath%Bin\Microsoft.Exchange.AuthorizationPlugin.dll"
예상 가능한 원인
1. ExchangeInstallPath 변수가 빠져있을 경우
이 항목을 체크하기 위해서 시스템 등록정보의 환경 변수에 가서 System 변수를 확인합니다.
여기에는 C:\Program Files\Microsoft\Exchange Server\V14 경로로 지정된 ExchangeInstallPath 변수가 나타나 있어야 합니다.
2. PowerShell 가상 디렉토리 경로가 수정되었을 경우
PowerShell 가상 디렉토리는 반드시 \Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell 위치로 지정되어 있어야 하며 그렇지 않으면 문제가 발생됩니다. 
이슈 4
다음과 같은 메시지와 함께 Remote Server연결 실패 :
The connection to the specified remote host was refused.
Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL. For more information, see the about_Remote_Troubleshooting Help topic.
예상 가능한 원인 :
1. MSExchangePowerShellAppPool 이 실행되고 있는지 확인
2. 사용자 계정이 Remote PowerShell Enabled 되어있는지 확인 ( 이를 확인하는 방법은 위에서 이미 언급되었습니다)
3. WinRM이 서버에 제대로 구성되어있는지 확인
- 서버에서 WinRM Quick Config를 실행하고 어떤 action 요구 없이 테스트를 통과해야 합니다. 만약 어떤 Action이 요구된다면 WinRM 구성이 변경되는 것을 허용하겠냐라는 창이 나타날때 예를 눌러주시면 됩니다.
- WinRM enumerate winrm/config/listener 를 실행하여 Listener가 모든 주소에서 5985 포트로 리스닝하는 HTTP가 나타나는지 확인 
이슈 5
다음과 같은 메시지와 함께 Remote Server연결 실패 :
The WinRM client received an HTTP status code of 403 from the remote WS-Management service.
예상 가능한 원인 :
1. PowerShell 가상 디렉토리에서 SSL 필요 옵션이 Enable ㅛ되어 있는지 확인
이 문제를 해결하기 위해서는 PowerShell디렉토리에서 SSL 필요 옵션을 해제하여야 합니다.
Exchange 관리도구는 80포트를 통해서 연결하며 아래의 SSL필요 옵션이 설정되어 있다면 80포트로 연결을 시도할때 IIS는 403 Error를 리턴합니다.
원문
Troubleshooting Exchange 2010 Management Tools startup issues
http://msexchangeteam.com/archive/2010/02/04/453946.aspx#comments
(0) 
(0)
댓글을 달아 주세요