Troubleshoot Messaging Integration in SharePoint

아티클
08/24/2016

Inside SharePoint메시징 통합 문제 해결

Pav Cherny

코드 다운로드 위치: SharePoint2008_08.exe(416KB)

일반적인 문제 해결 방식
SharePoint 메시징 아키텍처
진단 정보 얻기
아웃바운드 메시지 전송
인바운드 메시지 전송
디렉터리 관리
결론

잘 설계된 SharePoint 환경에서 정보 근로자는 공동 작업을 위해 통신 습관이나 작업 방식을 변경할 필요가 없습니다. 정기적으로 공동 작업 사이트를 수동으로 확인하는 대신 SharePoint에서 문서 및 경고, 미리 알림 등의 기타 정보를 사서함으로 직접 배달할 수 있습니다.

사용자들은 이러한 메시지에 회신하거나 새 항목을 전자 메일 메시지로 문서 라이브러리 및 목록에 전송하여 워크플로에 참여할 수도 있습니다.

하지만 SharePoint®를 보안 메시징 환경에 통합하는 작업에는 해결 과제가 따르며, 비-SharePoint 구성 요소가 SharePoint 기반 공동 작업에 영향을 줄 수도 있습니다. 해결 과제는 통합 환경에서 문제가 발생할 때마다 문제의 근본 원인을 효율적으로 격리하고 없애는 것입니다.

이 칼럼에서는 빠른 결과를 제공하는 입증된 문제 해결 전략을 기반으로 SharePoint 메시징 통합에 대해 설명합니다. 여기서는 문제 지점을 효율적으로 찾아낸 다음 더욱 자세하고 상황에 맞는 문제 해결 단계로 접근합니다.

대형 조직에서 이 단계별 조사는 초기 분석 후 다른 전문가에게 문제 처리를 넘기는 것을 의미하며, 특히 문제가 비-SharePoint 구성 요소와 관련된 경우 그렇습니다. 반면 중소 규모 조직에서는 한 명의 IT 관리자가 모든 관련 시스템에 대해 직접 문제 해결을 수행하는 것이 일반적이며, 이러한 경우 구조화된 방식이 더욱 필요합니다.

이 칼럼의 연습에서는 Active Directory®, Exchange Server 2007 및 WSS 3.0의 테스트 환경을 사용합니다. 이 테스트 환경을 구성하는 단계별 지침과 이 칼럼 및 관련 자료에서 언급된 문제 해결 도구는 TechNet Magazine 웹 사이트의 코드 다운로드 섹션에서 얻을 수 있습니다.

일반적인 문제 해결 방식

다른 상호 운용성 시나리오에 비해 SharePoint 메시징 통합 문제 해결에는 구조화된 방식이 더 필요합니다. 이 노력을 복잡하게 만드는 몇 가지 요소가 있습니다.

분명 여러분은 복잡한 기술을 다루어야 하고 메시징 전송 문제, 메시지 형식 변환, 보안 측면 및 디렉터리 관리 문제를 처리하면서 일부 SharePoint 오류 메시지가 혼란스럽게 느껴질 수 있습니다. 메시징 통합이 작동하도록 하려면 모든 웹 응용 프로그램을 SharePoint 중앙 관리의 응용 프로그램 풀 ID로 실행해야 한다는 것처럼 인터넷 뉴스 그룹은 잘못된 길로 안내할 수 있는 해결되지 않은 토론 주제와 제안으로 넘쳐납니다.

그러나 긍정적인 측면도 있습니다. SharePoint는 매우 유연합니다. 사실, 여러분이 어디를 찾아봐야 하는지 알고 있다면 자세한 문제 해결 정보를 얻을 수 있습니다. 몇 가지 기본적인 스크립트를 사용하여 문제 해결 효율성을 크게 높일 수 있습니다.

첫 번째 문제 해결 목표는 다루고 있는 특정 문제를 이해하는 것입니다. 문제가 어디에 있고 어떤 구성 요소가 관련되어 있는지 파악해야 합니다. 또한 다른 시스템 구성에서 문제를 재현해 보고 Windows® 이벤트 로그 및 텍스트 기반 로그 파일을 조사해야 합니다. 그러나 일부 문제의 경우 산발적으로만 발생하기 때문에 혼란스러울 수 있습니다. 그래도 문제를 잘 재현할수록 근본 원인을 더욱 빠르게 파악하고 없앨 수 있습니다. 자주 간과되는 또 하나의 중요한 목표는 모든 구성 변경 및 수정 내용을 기록하고 환경의 모든 관련 시스템(예: 웹 팜의 모든 프론트 엔드 서버)에 적용되었는지 확인하는 것입니다.

SharePoint 메시징 아키텍처

메시징 통합과 관련된 문제에 직면할 때마다 문제 해결을 시도하기 전에 우선 커피나 차 한 잔을 든 다음 SharePoint 메시징 통합 아키텍처를 검토하는 것이 좋습니다. 그렇지 않으면 잘못된 문제나 구성 요소를 수정하게 될 수 있습니다. 예를 들어, 나중에 살펴보겠지만 Active Directory에서 연락처 개체를 만들 수 없는 "액세스 거부" 오류가 발생했다고 해서 Active Directory에서 액세스 권한을 수정해야 하는 것은 아닙니다.

어떠한 경우든지 메시징 통합에 관련된 각 구성 요소의 역할과 개별 구성 요소가 서로 어떻게 상호 작용하는지 이해하는 것이 중요합니다. 그림 1을 보면 SharePoint-Exchange 연결 시나리오에서 중요한 구성 요소를 확인할 수 있으며, 다음 섹션에서 이에 대해 자세히 설명합니다.

그림 1 SharePoint 메시징 통합 아키텍처(크게 보려면 이미지 클릭)

진단 정보 얻기

가장 중요한 문제 해결 도구 중 하나는 믿을 수 있는 진단 정보입니다. 기본적인 도구는 Windows 이벤트 로그입니다. 무엇보다 SharePoint 중앙 관리(작업 페이지의 기록 및 보고에서 진단 로깅 클릭)를 사용하여 SharePoint에서 웹 서버의 Windows 이벤트 로그에 작성하는 상세 정보 수준을 제어할 수 있습니다. 별로 중요하지 않은 이벤트는 이벤트 로그 및 추적 로그에 기록되도록 지정할 수 있습니다. 추적 로그(기본적으로 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs에 위치)는 낮은 수준의 정보를 찾는 경우 매우 유용하지만, 매우 빨리 가득 차게 되므로 이 기능은 자주 사용되지 않습니다.

진단 정보를 얻을 수 있는 또 하나의 방법은 관련 자료의 Web Application Config.pdf에 설명된 대로 해당하는 web.config 파일을 구성하여 영향을 받는 웹 응용 프로그램에 대한 디버깅을 사용하는 것입니다. SharePoint는 사용자 인터페이스에 직접 자세한 추적 정보를 표시합니다. 이 방식의 장점은 많은 양의 추적 데이터를 분석하지 않고도 관련 오류 정보를 확인할 수 있다는 것입니다. 단점은 웹 응용 프로그램의 시스템 구성을 변경해야 한다는 것입니다. 원본 web.config 파일을 백업한 다음 문제 해결을 마친 후 원래 구성으로 되돌려야 한다는 것을 잊지 마십시오.

SMTP 서비스를 구성하여 자세한 처리 정보를 SMTP 프로토콜 로그에 작성하도록 할 수도 있습니다(IIS 관리자의 일반 탭에서 로깅 사용 확인란 선택). ODBC 로깅을 사용할 계획이 없더라도 관련 자료의 SharePoint Messaging Integration.pdf에 설명된 대로 SMTP 서비스 기능과 함께 ODBC 로깅 모듈을 설치하십시오. 그렇지 않으면 SMTP 서비스에서 프로토콜 로그를 작성하지 않습니다. 기본적으로 SMTP 프로토콜 로그는 %SystemRoot%\System32\LogFiles\SmtpSvc1에 있습니다. SMTP 통신을 상세하게 분석하고 SharePoint 서버에서 메시지가 전송되었는지 확인할 수 있도록 하는 것은 텍스트 파일입니다.

SMTP 서비스와 통신하는 허브 전송 서버의 송신 커넥터 및 수신 커넥터 구성에서도 프로토콜 로깅을 사용하도록 설정할 수 있습니다(SharePoint Messaging Integration.pdf 참조). 메시지 추적, 큐 뷰어, 파이프라인 추적 등 기타 다양한 도구를 사용하여 메시지가 허브 전송 서버 및 사서함 서버를 거쳐 Exchange Server 2007 환경에서 이동하는 경로를 확인할 수 있습니다. Exchange Server 2007 메일 흐름 문제 해결에 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkID=120145의 "전송 및 메일 흐름 문제"를 참조하십시오.

Active Directory 도메인 컨트롤러의 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics에서 해당하는 레지스트리 항목을 설정하여 디렉터리 액세스 및 기타 범주에 대한 진단 로깅을 사용함으로써 자세한 문제 해결 정보를 수집할 수 있습니다. 범주에 대한 0x0 값은 중요한 이벤트만 기록하는 것을 의미하고, 0x5 값은 디버그 정보를 포함한 모든 이벤트를 기록하는 것을 의미합니다. 0x3보다 높은 로깅 수준을 사용하면 서버 성능이 저하되고 Windows 이벤트 로그가 빨리 가득 찰 수 있습니다. 일반적인 작업 중에는 모든 값이 0x0으로 설정되어야 합니다.

문제 해결 시 SharePoint, Exchange 및 Active Directory 서버의 자세한 진단 정보를 수집하면 문제 지점을 빠르고 확실하게 찾는 데 도움이 됩니다. 이러한 시스템 간의 통신은 대부분 컴퓨터 네트워크를 통해 이루어지므로 TCP/IP 도구(ping, tracert, telnet 등) 및 네트워크 모니터와 같은 추가 문제 해결 도구도 유용할 수 있습니다. Microsoft® Network Monitor 3.1은 go.microsoft.com/fwlink/?LinkId=120143에서 다운로드할 수 있습니다.

아웃바운드 메시지 전송

리소스

이벤트 로그, 추적 로그, 프로토콜 로그, 메시지 추적 로그 및 네트워크 추적이 설정되어 있으면 SharePoint 메시징 통합 관련 문제를 해결할 준비가 된 것입니다. 간단한 부분인 아웃바운드 메시지 전송부터 시작해 보겠습니다. SharePoint는 다양한 구성에서 아웃바운드 메시지 전송을 지원하고 웹 서버의 로컬 SMTP 서비스를 필요로 하지 않습니다. 하지만 완전한 메시징 통합 시나리오에서는 로컬 SMTP 서비스를 사용하는 것이 권장되는 구성입니다. 그림 2는 시나리오의 주요 구성 요소를 보여 줍니다.

그림 2 아웃바운드 메시지 전송(크게 보려면 이미지 클릭)

이 메시징 시나리오에는 네 단계가 포함됩니다. 즉, SharePoint에서 SMTP 서비스에 메시지를 전송해야 하고, SMTP 서비스에서 메시지를 처리해야 하며, 허브 전송 서버에서 메시지를 수신해야 하고, Exchange Server 2007에서 메시지를 최종 대상에게 전송해야 합니다.

SharePoint에서 SMTP 서비스에 메시지를 전송할 수 없는 경우 일반적으로 사용자 인터페이스에서 전자 메일 알림을 전송할 수 없다는 오류를 받게 됩니다. SMTP 서비스가 실행되지 않기 때문일 수 있습니다. 또는 SMTP 프로토콜 로그에 SMTP 서비스가 오류 코드 550(요청된 작업을 수행할 수 없음: 사서함 사용 불가)과 함께 제출 시도를 거부했다고 기록되면 문제가 SMTP 서비스에 있다는 것을 나타냅니다.

SharePoint 문제가 아닌지 확인하려면 기본 스크립트(관련 자료의 SMTP.vbs 참조)를 사용하여 동일한 발신자 및 수신자 정보로 SMTP를 통해 테스트 메시지를 제출할 수 있습니다. SMTP 서비스 문제라면 스크립트가 성공하지 못합니다. 사실, 이 스크립트는 그림 3에 표시된 대로 SharePoint에서 디버깅을 사용해도 알아낼 수 없는 문제의 근본 원인에 대한 귀중한 단서를 제공합니다.

그림 3 메시지를 릴레이할 수 없음(크게 보려면 이미지 클릭)

SMTP 서비스 구성에서 웹 서버 릴레이 권한을 부여하고 SMTP 서비스를 다시 시작하면 SharePoint 메시지 제출 문제를 해결할 수 있습니다. 그러면 메시지는 SMTP 서비스에 도달하는데, 이제 중요한 문제는 SMTP 서비스에서 허브 전송 서버로 메시지를 라우팅할 수 있는지 여부입니다.

메시지가 Queue 폴더에 남아 있다면 SMTP 서비스가 허브 전송 서버에 연결할 수 없는 것입니다. 이 경우 Microsoft Exchange Transport 서비스가 실행되지 않기 때문이거나 네트워크 통신 또는 구성 문제 때문일 수 있습니다. Telnet 클라이언트를 사용하면 내부 통신을 위해 구성된 수신 커넥터의 대상 포트에 연결할 수 있는지 여부를 쉽고 빠르게 확인할 수 있습니다.

반드시 TCP 포트 25가 아닐 수 있습니다. 사실, SMTP 서비스에서 이 포트를 사용할 경우 익명의 메시지 제출을 차단하도록 구성된 허브 전송 서버에 대한 기본 수신 커넥터에 메시지를 전송할 수 있습니다. 이 경우 Drop 폴더에서 메시지를 볼 수 있습니다. 이 경우 Windows SharePoint Services Timer 서비스가 중지되어 있어야 합니다. 그렇지 않으면 몇 초 후 메시지가 사라집니다. 메시지 파일은 메시지가 "진단 코드: smtp;530 5.7.1 클라이언트가 인증되지 않았습니다"로 거부되었음을 나타내는 배달 상태 알림입니다.

이 문제를 해결하려면 SharePoint 서버에 대한 전용 수신 커넥터를 만들어야 합니다. SharePoint 서버는 내부 시스템이므로 외부 보안 인증 옵션을 선택합니다. 그러면 확장 권한을 ANONYMOUS LOGON 계정에 부여하지 않아도 됩니다. 또한 IPsec를 사용하여 SharePoint 서버와 허브 전송 서버 간 통신을 보호하는 방법을 고려해 보십시오.

메시지가 SMTP Queue 폴더에서 나가고 SharePoint 서버 및 허브 전송 서버의 SMTP 프로토콜 로그(%ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive 폴더 확인)가 성공적인 메시지 전송을 나타낼 경우 Exchange Server 2007에서 메시지를 대상으로 라우팅할 수 있다면 작업이 완료되었다고 생각할 수 있습니다. 메시지가 원하는 Exchange 수신자에게 배달되지 않을 경우 앞에서 언급한 대로 Exchange Server 2007에 포함된 메일 흐름 문제 해결 도구를 사용하여 문제를 조사하십시오. 이 단계에서는 잘못된 수신자 정보, 스팸 필터 및 메시지 크기 제한으로 인해 최종 대상에 도달하지 못할 수 있습니다.

인바운드 메시지 전송

반대 방향의 메시지 전송은 잠재적인 문제가 있기 때문에 좀더 복잡합니다. 예를 들어, SharePoint 제품 설명서에서는 SharePoint 전자 메일 도메인에 대해 DNS에서 MX 레코드 구성을 권장하고 있는데 이 경우 Exchange 조직에서 메시지가 잘못 라우팅될 수 있습니다.

Exchange Server 2007에서는 연결된 주소 공간과 함께 송신 커넥터를 사용하여 메시지를 전송합니다. 이 경우 SharePoint 서버가 내부용이더라도 SharePoint 메시지를 인터넷을 통해 전송하기 위해 Edge 전송 서버로 라우팅할 수 있습니다. 내부 메시지 전송의 경우 대신 상세 주소 공간과 함께 송신 커넥터를 사용하고 SMTP 서비스를 실행하는 SharePoint 서버를 커넥터 구성에서 스마트 호스트로 지정합니다(관련 자료의 SharePoint Messaging Integration.pdf 참조). 전용 브리지헤드 서버로 잘 정의된 라우팅 토폴로지를 설정하면 Exchange에서 SharePoint로 신뢰할 수 있는 메시지 전송이 가능합니다.

메시지가 SharePoint 서버에 도달하는지 확인하려면 Windows SharePoint Services Timer 서비스를 중지합니다. 그림 4에 표시된 대로 Timer 서비스는 메시지를 처리하고 수신자 전자 메일 주소와 연결된 문서 라이브러리에 첨부 파일을 배치하기 때문에 메시지는 Drop 폴더에 쌓입니다. 메시지가 Drop 폴더에 도착하지 않으면 허브 전송 서버에서 큐 뷰어를 사용하여 Exchange에서 메시지를 제대로 라우팅하는지 확인합니다. 그런 다음 허브 전송 서버가 SharePoint 서버의 SMTP 서비스와 통신하는 것을 막을 수 있는 네트워크 통신 문제를 조사합니다.

그림 4 인바운드 메시지 전송(크게 보려면 이미지 클릭)

Timer 서비스를 다시 시작하면 메시지 항목이 Drop 폴더에서 사라지는 것을 확인할 수 있습니다. 하지만 Windows 이벤트 로그에 SharePoint에서 성공적으로 메시지를 처리했다고 기록되더라도 메시지 첨부 파일이 대상 라이브러리에 문서로 남지 않으면 Exchange에서 Exchange RTF 형식으로 메시지를 전송했음을 의미합니다. 이 문제를 조사하려면 Timer 서비스를 다시 중지하고 Outlook® 클라이언트에서 첨부 파일이 있는 다른 메시지를 전송한 다음 Drop 폴더에 도착하면 메모장에서 메시지를 엽니다. 이제 "winmail.dat" 문자열을 검색합니다. 이 문자열을 찾을 경우 Exchange Server에서 잘못된 형식으로 메시지를 전송하고 있는 것입니다.

SharePoint에서는 메시지 첨부 파일을 MIME 또는 UUENCODE 형식으로 인코딩해야 합니다. 또한 SharePoint에서는 winmail.dat 관련 처리 문제를 Windows 이벤트 로그에 표시하지 않습니다(그림 5 참조). 이 경우 첨부 파일이 문서 라이브러리에 나타나지 않습니다. 메모장을 문제 해결 도구로 사용하고 Exchange 관리 콘솔에서 SharePoint 전자 메일 도메인에 대한 원격 도메인 정의를 구성하여 형식 문제를 해결합니다. "저널 보고서의 첨부 파일로 보낸 원본 메시지의 형식" 탭의 "Exchange 서식 있는 텍스트 형식"에서 "사용 안 함"을 선택합니다.

그림 5 Winmail.dat 메시지 처리(크게 보려면 이미지 클릭)

디렉터리 관리

유용한 Timer 서비스 이벤트 중 하나는 수신 전자 메일 파일 처리 중 알 수 없는 별칭으로 인해 오류가 발생했음을 알려 주는 이벤트 6873입니다. 이 오류는 Exchange 사용자가 메시지를 전송할 때 존재하지 않는 문서 라이브러리와 같이 잘못된 SharePoint 전자 메일 주소를 지정할 경우 발생합니다.

이 문제는 SharePoint 중앙 관리의 수신 전자 메일 설정에서 Active Directory에서 메일 사용 문서 라이브러리에 대한 수신자 개체를 만들도록 디렉터리 관리 서비스를 구성하여 완화할 수 있습니다. 그러면 Exchange 사용자들은 올바른 주소 정보가 있는 수신자 개체를 주소록에서 편리하게 선택할 수 있습니다.

하지만 이렇게 하면 수많은 문제점이 발생하게 됩니다. 이 기능은 웹 서버에서 권한 요구 사항을 상승시키기 때문에 최소 권한의 원칙을 기반으로 하는 보안 시스템 구성에서 디렉터리 관리 서비스를 제대로 실행할 수 없습니다. 더욱이, 제품 설명서(예: technet.microsoft.com/library/cc262947.aspx)에서는 Active Directory에서 SharePoint 수신자 개체에 대해 지정한 OU에서 중앙 관리 응용 프로그램 풀 계정에 "사용자 계정 만들기, 삭제 및 관리" 권한을 부여해야 한다고 권장할 때 어느 정도 상황을 과장합니다.

디렉터리 관리 서비스에서는 연락처 및 그룹 개체를 생성하므로 중앙 관리 응용 프로그램 풀 계정에는 이 OU에서 연락처 및 그룹 개체에 대한 모든 제어 권한이 필요하지만, 사용자 계정에 대한 관리 권한은 필요하지 않습니다. 웹 팜에서 디렉터리 관리 서비스를 설명한 대로 설정하고 문서 라이브러리에서 전자 메일을 사용하도록 시도하면 "액세스 거부됨" 오류가 발생할 가능성이 높습니다.

오류 정보는 Active Directory 권한 문제를 지적하고, SharePoint 관리자는 모든 사람에 대해 SharePoint OU에 대한 전체 제어 권한을 빠르게 지정합니다. 하지만 이 경우 Active Directory 보안이 약해지고 문제도 해결하지 못합니다.

구조화된 문제 해결에서는 먼저 문제의 지점을 찾아낸 다음 적절한 구성 변경 내용을 적용해야 합니다. 이 방식을 따라 도메인 컨트롤러에서 Windows 이벤트 로그를 확인하고 네트워크 모니터를 사용하여 네트워크 통신을 추적할 경우 이 문제가 발생할 때 SharePoint에서 Active Directory에 액세스하지 못한다는 것을 알 수 있습니다. 따라서 Active Directory 구성을 변경해도 문제를 해결하지 못합니다. 문제는 SharePoint 서버에서 발생하고 있습니다.

안타깝게도 이 권한 문제에 대한 유용한 정보를 얻기는 매우 어렵습니다. SharePoint에서는 Windows 이벤트 로그에 추가 정보를 기록하지 않습니다. 하지만 SharePoint 디버깅을 사용할 경우 디렉터리 관리 서비스에서 SharePoint 웹 서비스의 CreateContact 메서드를 사용하도록 권장하는 호출 스택(그림 6 참조)을 볼 수 있습니다. SharePoint SDK에서는 이것을 전자 메일 통합 웹 서비스(<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx)라고 합니다.

그림 6 디버그 출력

Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall) 
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters) 
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags) 
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias) 
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration) 
   at Microsoft.SharePoint.SPList.Update() 
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args) 
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e) 
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) 
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument) 
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)

웹 브라우저에서 SharepointEmailWS.asmx를 열어 지원되는 작업 목록을 확인해 보겠습니다. CreateContact 메서드를 볼 수 있는데 CreateContact 링크를 클릭하면 Active Directory에서 연락처를 만들려는 경우 이 웹 서비스에 전송해야 하는 SOAP 메시지가 나타납니다. 이를 통해 이제 SharePoint 사용자 인터페이스 외부에서 작업할 수 있는 스크립트 기반 문제 해결 도구(관련 자료의 SharepointEmailWS.vbs 참조)를 만들 수 있으므로 테스트 실행 중 다른 사용자 계정을 쉽게 지정할 수 있습니다. 그림 7은 중앙 관리 응용 프로그램 풀 계정(왼쪽) 및 SharePoint 관리자 계정(오른쪽)에서 이 스크립트를 실행할 경우 반환되는 정보를 보여 줍니다.

그림 7 두 가지 서로 다른 "액세스 거부됨" 오류(크게 보려면 이미지 클릭)

오류 메시지가 서로 다릅니다! 두 메시지는 모두 액세스가 거부되었음을 나타내지만, 왼쪽의 오류는 처리 문제이고 오른쪽의 오류는 그렇지 않습니다. 그렇다면 응용 프로그램 풀 계정과 SharePoint 관리자 계정 사이에 어떤 차이가 있는 것일까요?

SharePoint 관리자는 SharePoint 서버의 로컬 관리자이고, 응용 프로그램 풀 계정은 그렇지 않습니다. 웹 응용 프로그램의 응용 프로그램 풀 계정을 로컬 관리자 그룹에 추가하고 웹 서버를 다시 시작하면 문제가 해결되지만 그리 좋은 소식은 아닙니다. 프로덕션 웹 서버에서 관리 권한으로 응용 프로그램 풀 계정을 실행하는 것은 허용되지 않습니다.

응용 프로그램 풀 계정에 이러한 상승된 권한이 필요한 이유는 무엇일까요? 다시 스크립트가 해답을 제시할 수 있습니다. 모든 사용자에게 테스트 목적으로 웹 서버에서 로컬 관리자 권한을 부여할 경우 응용 프로그램 풀 계정에서 전자 메일 통합 웹 서비스를 사용할 수 있지만, SharePoint 관리자를 포함하여 기타 모든 계정에 대한 액세스는 계속 거부된다는 것을 알 수 있습니다. 이것은 전자 메일 통합 웹 서비스에서는 액세스 제어 결정을 위한 기준으로 응용 프로그램 풀 구성을 사용한다는 것을 의미합니다.

응용 프로그램 풀 구성은 IIS 메타베이스(또는 IIS 7.0의 applicationHost.config 파일)의 일부이며, 메타베이스에 대한 액세스는 기본적으로 로컬 관리자로 제한됩니다. 다행히, IIS 6.0 리소스 키트 도구에 포함된 Metabase Explorer를 사용하여 비관리자 계정에 대해 메타베이스에 대한 액세스 권한을 부여할 수 있습니다. IIS 7.0에서는 다음 명령을 실행하여 간단히 applicationHost.config 파일에 전체 제어 권한을 더 쉽게 부여할 수 있습니다.

CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config" 
/G "<application pool account>" :F /E iisreset /noforce

마지막으로 Active Directory에서 연락처 개체를 만들려면 중앙 관리 응용 프로그램 풀에 대상 OU의 연락처 및 그룹 개체에 대한 전체 제어 권한이 필요합니다. 그리고 웹 응용 프로그램의 풀 계정에는 웹 팜의 SharePoint 서버에서 메타베이스에 대한 전체 액세스 권한이 필요합니다. 이제 SharePoint 사용자 인터페이스를 사용하여 연락처 개체를 만들 준비가 되었습니다.

그런데 아직 더 남아 있습니다! Active Directory에서 수신자 개체를 만드는 것은 디렉터리 통합 작업에서 절반을 완료한 것입니다. 나머지 절반은 Exchange 관련 수신자 특성을 생성하고 서버 기반 주조록을 업데이트하는 것입니다. 예를 들어, Exchange 관리 셸 명령 Update-GlobalAddressList "Default Global Address List"를 사용하여 Exchange 서버에서 전체 주소 목록을 업데이트할 경우 Outlook 주소록에서 SharePoint 문서 라이브러리에 대해 새로 만들어진 수신자 개체를 찾을 수 있습니다. 그러나 이러한 수신자에게 메시지를 전송하면 그림 8에 표시된 대로 잘못된 주소 정보로 인해 배달 못 함 보고서가 생성됩니다.

그림 8 문서 라이브러리에 배달할 수 없는 메시지(크게 보려면 이미지 클릭)

IMCEAEX는 Internet Mail Connector Encapsulated Address for Exchange의 머리글자어입니다. 이것은 이전의 Exchange Internet Mail Connector에서 처리할 수 있는 형식으로 캡슐화된 비-Exchange 수신자 주소를 나타냅니다. 그러나 이제는 Exchange Server 2007 및 기본 SMTP 기반 송신 커넥터를 사용하고 있습니다.

요점은 SharePoint 전자 메일 통합 웹 서비스에서 메시지 전송을 위해 Exchange Server 2007에 필요한 주소 특성을 작성하지 않는다는 것입니다. 이름, 성, 표시 이름 및 대상 주소(및 선택적으로 ms-Exch-RequireAuthToSendTo) 특성만 작성합니다. 그러나 메일 별칭 또는 레거시 Exchange DN이나 프록시 주소를 설정하지 않고, 수신자 개체를 Exchange 수신자 정책과 연결하지 않습니다.

이 문제를 해결하려면 Exchange 관리 셸에서 Get-Mailbox cmdlet을 사용하여 SharePoint 전자 메일 도메인을 가리키는 대상 주소를 가진 모든 수신자 개체를 가져옵니다. 그리고 다음과 같이 출력을 Set-MailContact cmdlet에 연결하여 Exchange 수신자 정책을 활성화합니다.

Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True

또는 Exchange 관리 콘솔을 사용하고 연락처 개체 속성에서 "전자 메일 주소 정책에 따라 전자 메일 주소를 자동으로 업데이트" 확인란을 선택합니다.

WSS 3.0 및 MOSS 2007은 전자 메일 기반 경고와 알림, 워크플로 및 문서 제출을 즉시 사용할 수 있도록 모든 메시징 통합을 지원합니다. 시스템을 올바르게 구성하는 일이 간단한 작업은 아니지만 메시지 통합을 통해 작업자 생산성을 높일 수 있습니다. 특히, 인바운드 및 아웃바운드 메시지 전송이 모두 제대로 작동하도록 해야 합니다. 또한 디렉터리 통합도 작동되도록 해야 합니다.

SharePoint 오류 메시지가 항상 직관적이거나 정보를 제공하지는 않습니다. 하지만 지금까지 SharePoint 서버의 보안을 위협하지 않고 통합 문제의 기본 구조를 파악한 다음 근본 원인을 찾아 안정적으로 문제를 해결할 수 있는 방법을 설명했습니다.

Pav Cherny는 공동 작업 및 통합 커뮤니케이션을 위한 Microsoft 기술을 전문으로 하는 IT 전문가이자 저술가입니다. IT 운영과 시스템 관리를 주로 다루는 백서, 제품 설명서 및 서적 등을 출간한 Pav는 문서 관리 및 지역화 서비스를 전문으로 하는 Biblioso Corporation의 사장입니다.

추가 리소스