Inside SharePoint: Enterprise Project Management with SharePoint

아티클
08/24/2016

Inside SharePointSharePoint를 사용하여 엔터프라이즈 프로젝트 관리

Pav Cherny

코드 다운로드 위치: ChernySharePoint2008_12.exe(959 KB)

어떤 SharePoint 기술이 적합한가? 답을 찾는 과정에서 공동 작업 및 Social Computing, 포털, 엔터프라이즈 검색, 엔터프라이즈 콘텐츠 관리, 비즈니스 프로세스와 폼, 비즈니스 인텔리전스, 개발자 플랫폼 기능 등과 같은 수많은 범주 목록을 철저하게 조사하여 Windows SharePoint Services(WSS) 3.0, Microsoft Office Search Server 2008 Express, Microsoft Office Forms Server 2007 및 Microsoft Office SharePoint Server(MOSS) 2007에서 사용 가능한 기능을 비교해 보았을 것입니다. 하지만 Microsoft의 SharePoint 제품 및 기술 목록에 없기 때문에 고려할 수 없었던 기술이 하나 있습니다. 그것이 바로 EPM(Enterprise Project Management)이며 이 기술은 Microsoft Office Project Server(MOPS) 2007 이상에서 사용할 수 있습니다.

MOPS 2007은 SharePoint 기술이지만, WSS 3.0을 기반으로 작성되고 MOSS 2007과 비교할 수 있을 정도로 WSS 3.0의 기능을 확장합니다. WSS 3.0 및 MOSS 2007에 포함된 간단한 작업 관리 기능으로는 역부족인 부서 내 또는 부서 간의 작업, 리소스 및 예산 관리 작업을 수행하여 팀 공동 작업의 효율성을 높이려면 MOPS 2007을 선택하는 것이 좋습니다. MOPS를 사용하면 팀 사이트를 프로젝트 작업 영역으로 전환하고, 부서 내 또는 부서 간의 팀 공동 작업을 관리하며, 전체 조직을 위한 견고한 EPM 기반을 구축할 수 있습니다. 하지만 무엇보다도 먼저 부서의 과제를 완벽하게 파악해야 합니다.

이 칼럼에서는 SQL Server 2005 SP2 및 WSS 3.0 SP1이 설치된 Windows Server 2008 환경에 MOPS 2007을 배포하는 과정에 대해 살펴보겠습니다. 먼저 MOPS 아키텍처를 검토하여 시스템 설계자의 관점에서 구성 요소가 WSS 3.0과 어떻게 통합되는지를 알아보겠습니다. 이러한 내용을 익히면 다음에서 다룰 응용 프로그램 풀 구성 문제, 액세스 권한 부족, 큐 시스템 시작 오류, SQL Server 2005 Analysis Services 관련 문제 등과 같은 일반적인 배포 및 통합 문제를 이해하는 데 많은 도움이 될 것입니다.

이 SharePoint 칼럼에서 지금까지 사용했던 테스트 환경과 마찬가지로 서버 팜에 두 대의 WSS 3.0 서버가 있고, 전용 도메인 컨트롤러 하나와 SQL Server를 실행하는 별도의 한 대 컴퓨터로 구성된 기본 테스트 환경을 사용하여 배포 및 문제 해결 단계를 설명하겠습니다. TechNet Magazine 웹 사이트에서 제공하는 이 칼럼에 대한 첨부 자료에서 단계별 지침이 포함된 관련 워크시트를 참조할 수 있습니다.

Project Server 아키텍처

MOPS 2007은 복합적인 기능을 제공하는 최고급 SharePoint 응용 프로그램 중 하나로서, 중앙 집중식 관리, 사이트 구축, 인증 및 보안을 위해 WSS 3.0 플랫폼을 최대한 활용합니다. 또한 25개의 일반 및 전문 MOPS 웹 파트와 PWA(Project Web Access) 사이트별로 최대 4개의 MOPS 데이터베이스로 구성된 새로운 데이터베이스 모음과 같은 추가 구성 요소를 추가합니다. 그림 1에 나와 있는 것처럼 PSI(Project Server Interface)를 구성하는 21개의 공용 및 내부 MOPS 웹 서비스를 통해 각 구성 요소를 액세스합니다. MOPS 웹 서비스에 대한 자세한 내용은 MSDN을 참조하십시오.

그림 1 SharePoint와 MOPS 2007의 통합(더 크게 보려면 이미지를 클릭하십시오.)

MOPS 2007 아키텍처는 클라이언트 워크스테이션, 응용 프로그램 서버 및 데이터베이스 서버를 통해 배포되는 다양한 구성 요소를 사용합니다. 이 칼럼에서는 주로 이러한 구성 요소를 중심으로 설명합니다. 모든 기술에 대한 자세한 내용은 Project 2007 SDK의 "Project Server 아키텍처" 문서를 참조하십시오.

SDK를 참조할 때 PWA 웹 파트 및 Microsoft Office Project Professional 2007은 PSI 웹 서비스를 직접 액세스하지 않는다는 사실에 유의하십시오. SDK에서는 클라이언트가 PSI를 직접 호출하도록 권장하지만, 실제로 대부분의 응용 프로그램은 PSI 웹 서비스에 간접적으로 액세스하는 PWA 사이트의 구성 요소 중 하나인 PSI Forwarder를 사용합니다. 시스템 수준 권한으로 실행되는 서버 기반 구성 요소(예: 큐 서비스 및 이벤트 서비스)에서만 PSI를 직접 호출합니다. 이 정보는 다음과 같은 몇 가지 이유로 문제 해결 상황에서 중요하므로 기억해 두시기 바랍니다.

PWA 사이트는 데이터베이스 컨텍스트(PWA 사이트마다 별도의 초안, 게시, 보관 및 보고 데이터베이스가 있음) 및 사용자 권한을 정의하지만, 일반 사용자 계정에는 PSI 웹 서비스에 대한 액세스 권한이 부여되지 않습니다.
PSI Forwarder는 가장(impersonation) 기능을 지원하지 않으며 PWA 사이트의 응용 프로그램 풀 계정을 사용하여 사용자 대신 PSI 웹 서비스에 액세스합니다.
팜에 여러 응용 프로그램 서버 인스턴스가 포함되어 있는 경우 PSI 호출에서 로컬 PSI 웹 서비스를 사용하지 않아도 됩니다.

SharePoint 통합

이제 MOPS와 SharePoint의 실제 통합에 대해 자세히 살펴보겠습니다. SharePoint 관리자의 관점에서 MOPS는 SharePoint 3.0 SharePoint 3.0 Central Administration에서 팜 서비스로 관리되는 공유 웹 응용 프로그램입니다. 따라서 MOSS 2007의 SSP(Shared Service Provider)에 익숙한 관리자는 비교적 손쉽게 사용할 수 있습니다.

하지만 WSS 3.0 관리자이며 SSP 관리에 대해 잘 모를 경우에는 첨부 자료의 "Project Server 2007 배포" 워크시트에 제공되는 단계별 지침에서 SharePoint 팜의 공유 서비스와 PWA 사이트를 만들고 구성하는 방법을 참조하십시오. MOPS를 설치하고 구성한 다음 IIS 관리자에서 시스템 구현을 분석할 수 있습니다. 그림 2에서 볼 수 있는 것처럼 MOPS 응용 프로그램 서버에 공유 서비스, SSP 관리 및 사이트 모음에 대한 개별 웹 사이트가 표시되어야 합니다.

그림 2 PWA 및 PSI Forwarder를 통해 Project Server 2007 액세스(더 크게 보려면 이미지를 클릭하십시오.)

클라이언트는 PWA 사이트에서 _vti_bin/PSI 가상 디렉터리를 통해 PSI 웹 서비스에 액세스합니다. 하지만 PSI 웹 서비스는 이 가상 디렉터리에 존재하지 않습니다. _vti_bin/PSI 가상 디렉터리는 물리적 경로 %COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI에 매핑됩니다. 이 디렉터리에는 *.asmx 파일에 대한 모든 HTTP 요청(즉, ASP.NET 기반 웹 서비스)을 사용자 지정 HTTP 처리기에 전달하고 Microsoft.Office.Project.Server.PSIForwarderHandlerFactory를 통해 인스턴스화하도록 <httpHandlers> 섹션에 지정된 web.config 파일이 들어 있습니다.

이 사용자 지정 HTTP 처리기가 PSI Forwarder입니다. PSI Forwarder는 실제 PSI 웹 서비스에 대한 새 HTTP 연결을 설정하고 클라이언트의 HTTP 요청을 전달한 다음 그 결과를 클라이언트에 반환합니다.

PSI Forwarder는 Office Server 웹 서비스 사이트에 호스팅되는 공유 서비스 웹 응용 프로그램의 PSI 가상 디렉터리에서 HTTP를 통해 PSI 웹 서비스를 사용할 수 있습니다. 이 가상 디렉터리는 기본적으로 물리적 경로 %PROGRAMFILES %\Microsoft Office Servers\12.0\WebServices\Shared\PSI에 매핑되며 여기서 MOPS 2007 *.asmx 파일을 찾을 수 있습니다.

Office 서버 웹 서비스 사이트에 대해서는 나중에 자세히 설명하겠습니다. 그림 2에서 가장 중요한 내용은 PSI Forwarder는 PWA 사이트에 현재 액세스하는 사용자가 아니라 PWA 사이트의 웹 응용 프로그램 풀 계정 ID를 사용하여 PSI 웹 서비스와 통신한다는 사실입니다.

서버 팜 배포

또한 PSI Forwarder는 시스템 확장성 및 가용성 향상을 위해 개별 웹 프런트 엔드 서버 및 응용 프로그램 서버를 사용하는 서버 팜 배포에서 중요한 역할을 합니다. MOPS 프런트 엔드 서버는 PSI 웹 서비스 또는 다른 MOPS 서비스(예: 큐 서비스 및 이벤트 서비스)를 호스팅하지 않지만 클라이언트가 PSI Forwarder를 포함하는 PWA 사이트에 액세스할 수 있도록 해주는 WSS 3.0 서버입니다(그림 3 참조).

그림 3 중간 규모 MOPS 2007 서버 팜(더 크게 보려면 이미지를 클릭하십시오.)

반면에 응용 프로그램 서버는 MOPS 구성 요소와 서비스를 모두 설치한 WSS 3.0 서버입니다. 응용 프로그램 서버는 PWA 사이트를 호스팅할 수 있지만, 일반적으로 프런트 엔드 서버에 백엔드 서비스만 제공하고 WSS 웹 응용 프로그램 서비스를 실행하지 않습니다. 서버 역할은 MOPS를 설치할 때 선택합니다.

그림 3은 중간 규모 서버 팜의 구성을 보여 줍니다. 조직의 요구 사항에 따라 프런트 엔드 서버를 추가하여 확장성을 높이고 응용 프로그램 서버를 추가하여 가용성을 높일 수 있습니다. PSI Forwarder는 서버 팜에 여러 MOPS 응용 프로그램 서버가 있을 경우 PSI 요청의 부하를 자동으로 조정하므로 MOPS 응용 프로그램 서버에 대한 부하 분산 클러스터를 구성할 필요는 없습니다. MOPS 배포 옵션에 대한 자세한 내용은 "Office Project Server 2007 배포 가이드"를 참조하십시오.

IIS 7 시작

이론은 이것으로 마치고, 이제 MOPS 2007을 배포하는 중에 발생하는 몇 가지 실제 문제에 대해 살펴보겠습니다. 가장 많이 발생하는 문제 중 하나는 PWA 사이트에 대한 호스트 명명 사이트 모음과 관련된 것입니다. 이 시나리오에서는 Project Web Access 사이트 만들기 페이지에서 호스트 헤더 확인란으로 Project Web Access 사용 경로를 선택한 후 전체 PWA URL(예: pwa)을 입력하여 MOPS를 성공적으로 배포하고, SSP를 구성하며, 호스트 헤더 모드로 PWA 사이트를 구축합니다. 모든 리소스를 성공적으로 구축한 후 사이트를 열면 PWA 대신 표준 IIS 7 시작 화면에 연결됩니다.

기본 웹 사이트가 SharePoint 확장이 아니고 PWA URL에 대한 적절한 사이트 바인딩을 가진 다른 웹 사이트가 없는 경우에 이러한 상황이 발생합니다. 명시적으로 사이트가 바인딩되지 않으면 IIS는 pwa 요청을 확장되지 않은 기본 웹 사이트에 연결하므로 시작 화면이 표시됩니다. PWA 사이트를 호스팅하도록 선택한 SharePoint 웹 응용 프로그램에 SharePoint 3.0 Central Administration에서 필요한 바인딩이 추가될 것으로 생각했겠지만 이렇게 되지 않습니다.

IIS 및 PWA 문제 해결 첨부 워크시트에 설명된 것처럼 이 문제를 해결하려면 기본 웹 사이트를 SharePoint 확장한 다음 이 사이트 모음을 사용하여 PWA 사이트를 구축해야 합니다. 또는 IIS 관리자에서 누락된 사이트 바인딩을 PWA에 대해 선택된 웹 응용 프로그램에 수동으로 추가할 수 있습니다. PWA 사이트를 호스팅하는 모든 WSS 서버에서 이 단계를 수행해야 한다는 것을 잊지 마십시오.

세션 데이터베이스 사용 권한

기본 웹 사이트를 확장하려면 응용 프로그램 풀에 대한 도메인 계정을 사용해야 합니다("관리 및 서비스 계정 계획(Office SharePoint Server)" 참조). 그렇지 않으면 그림 4와 같이 PWA 사이트를 구축한 이후에 사용 권한 관련 문제가 발생합니다. 이러한 문제는 일반적으로 자세한 설명이 없는 SharePoint 오류 메시지로 표시됩니다.

그림 4 SSP 데이터베이스 액세스 오류(더 크게 보려면 이미지를 클릭하십시오.)

자세한 정보를 보려면 %COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\LOGS 디렉터리에 있는 추적 로그를 확인해야 합니다. 팜에 부하가 분산되는 여러 개의 웹 프런트 엔드 서버가 있을 경우에는 추적 로그를 확인하는 데 오래 걸릴 수 있습니다.

문제를 해결하려면 PWA 호스트 이름에 대한 DNS 레코드를 변경하여 단일 프런트 엔드 서버를 임시로 가리키도록 하는 것이 좋습니다. 그러면 클라이언트 요청을 처리하는 서버를 알 수 있으므로 해당 서버의 로그 파일만 추적하면 됩니다.

최신 로그 파일을 메모장에서 열고 "Cannot open database." 항목을 검색합니다. 해당 항목이 있으면 데이터베이스 사용 권한 문제임을 나타냅니다. 예를 들어, 그림 4의 추적 로그는 LITWARE\WSS02$ 계정이 데이터베이스 SharedServices1_DB에 대한 액세스 권한이 없음을 보여 줍니다. 이는 PWA 사이트가 네트워크 서비스 ID로 실행되고 있다는 명백한 표시입니다.

LITWARE\WSS02$는 웹 프런트 엔드 서버의 컴퓨터 계정이고 SharedServices1_DB는 공유 서비스 공급자 데이터베이스입니다. 특히, 웹 프런트 엔드 서버는 이 데이터베이스를 사용하여 ASPStateTempSessions 테이블에서 ASP.NET 세션 상태 데이터를 유지 관리하지만, LITWARE\WSS02$는 이 데이터베이스에 대한 액세스 권한이 없습니다.

안정적인 시스템 성능을 보장하려면 주간 데이터베이스 유지 관리 작업에 공유 서비스 공급자 데이터베이스가 포함되어 있는지 확인해야 합니다. 예를 들어, "서버 팜 환경에 Project Server 2007 배포"에 설명된 것처럼 SQL 명령 TRUNCATE TABLE ASPStateTempSessions을 사용하여 만료된 세션 상태 데이터를 ASPStateTempSessions 테이블에서 제거해야 합니다.

네트워크 서비스 관련 구성 문제는 혼동될 수 있으므로 자세히 살펴보겠습니다. 도메인 계정(예: LITWARE\SspConfigAdmin)은 모든 컴퓨터에서 동일하기 때문에 서버 팜의 응용 프로그램 풀에 대해 적용됩니다. 반대로 네트워크 서비스 계정(NT AUTHORITY\NETWORK SERVICE)은 컴퓨터마다 다릅니다. wss02.litware.com이라는 프런트 엔드 서버에서 NT AUTHORITY\NETWORK SERVICE 계정은 LITWARE\WSS02$로 번역됩니다. 이름이 sql01.litware.com인 서버에서는 NT AUTHORITY\NETWORK SERVICE 계정이 LITWARE\SQL01$로 참조됩니다. 여기에 문제가 있습니다.

SQL Server Management Studio에서 SharedServices1_DB에 대한 SQL Server 권한을 조사해 보면 NT AUTHORITY\NETWORK SERVICE 계정에는 네트워크 서비스 계정을 사용하여 공유 서비스 공급자 데이터베이스에 액세스하도록 응용 프로그램 풀에 권한을 부여할 수 있는 db_owner 권한이 있음을 알 수 있습니다. 하지만 이는 단일 서버 설치에만 적용됩니다.

LITWARE\WSS02$ 및 모든 다른 WSS 서버 계정(LITWARE\WSS01$ 등)에 SharedServices1_DB에 대한 db_owner 권한을 명시적으로 부여하여 권한 할당 문제를 해결할 수 있지만, SharePoint에서 필요한 데이터베이스 권한을 부여한 것과 동일한 ID를 모든 프런트 엔드 서버에서 사용하도록 응용 프로그램 풀에 대한 도메인 계정을 대신 사용하는 것이 좋습니다.

공유 서비스 권한

또한 PWA 사이트의 응용 프로그램 풀에서 네트워크 서비스 계정을 사용하는 경우 SSP 관련 권한 문제가 발생합니다. PWA 사이트 응용 프로그램 풀 계정의 컨텍스트에서 PSI Forwarder는 사용자 대신 PSI 웹 서비스에 액세스한다고 앞에서 설명했습니다. 이 계정에 Office 서버 웹 서비스 사이트 액세스 권한이 없는 경우 일반 SharePoint 오류 메시지가 표시되고 다시 원점으로 돌아갑니다. 이 경우 프런트 엔드 서버의 추적 로그에 "The request failed with HTTP status 401: Unauthorized"라고 표시됩니다(그림 5 참조).

그림 5 요청 실패 및 오류 메시지 HTTP 상태 401: 권한이 없음(더 크게 보려면 이미지를 클릭하십시오.)

이 오류가 PWA의 사용자 권한을 나타내지는 않습니다. PWA 사이트에 부여된 SharePoint 사용 권한에 따라 사이트의 _vti_bin/PSI 가상 하위 디렉터리에 액세스할 수 있는 사용자가 결정되지만, 이러한 사용자에게는 응용 프로그램 서버의 PSI 웹 서비스 또는 공유 서비스 웹 응용 프로그램에 대한 액세스 권한이 부여되지 않습니다.

PWA 사이트 모음 관리자라도 PWA 사이트의 응용 프로그램 풀 계정에 PSI 웹 서비스에 대한 액세스 권한이 없는 경우에는 MOPS가 여전히 실패합니다. 서버 팜의 응용 프로그램 풀에 대해 도메인 계정을 사용하고 네트워크 서비스 계정을 대신 사용하라는 권장 사항을 무시하는 경우에는 특히 그렇습니다.

응용 프로그램 서버에 대한 SSP 액세스 권한을 확인하려면 Office 서버 웹 서비스 사이트의 루트 디렉터리(기본값: %PROGRAMFILES%\Microsoft Office Servers\12.0\WebServices\Root)에서 web.config 파일을 확인하십시오. NT AUTHORITY\NETWORK SERVICE 항목이 <authorization> 섹션에 있으면 네트워크 서비스 계정을 사용하는 응용 프로그램 풀에 권한을 부여하는 것으로 간주됩니다. 하지만 이 항목은 프런트 엔드 서버가 아닌 로컬 컴퓨터만 참조하기 때문에 작업은 수행되지 않습니다.

응용 프로그램 풀 구성을 변경하고 도메인 계정을 사용하는 것이 가장 좋습니다. 네트워크 서비스 계정을 사용하려면 프런트 엔드 서버 계정에 명시적으로 권한을 부여해야 합니다.

응용 프로그램 서버에서 web.config 파일을 직접 편집하지 마십시오. 그러면 SharePoint에서 변경 내용을 덮어씁니다. 대신 "공유 서비스 공급자 액세스 권한 테스트" 워크시트에서 설명하는 대로 SharePoint 3.0 Central Administration을 사용하여 필요한 권한을 부여하십시오. 또한 첨부 자료에 포함된 SSPCheck와 같이 PSI 웹 서비스에 대한 직접 HTTP 연결을 설정하는 간단한 ASP.NET 응용 프로그램을 사용하여 구성을 확인하십시오. 안정적인 결과를 얻으려면 PWA 사이트의 응용 프로그램 풀에서 ASP.NET 테스트 응용 프로그램을 실행해야 합니다.

Windows 방화벽

웹 프런트 엔드 서버를 통해 PWA에 액세스하지 않으며 MOPS 응용 프로그램 서버의 Windows 방화벽이 TCP 포트 56737 및 56738을 차단하지 않으면 지금 PWA를 열 수 있습니다. 이러한 포트는 HTTP 및 HTTPS 통신을 위해 Office 서버 웹 서비스에 할당되는 기본 포트입니다.

SharePoint는 Office 서버 웹 서비스 사이트를 만들 때 MOPS 응용 프로그램 서버에서 이러한 포트를 자동으로 열지 않습니다. 응용 프로그램 서버에서 Windows 방화벽을 사용하는 경우 프런트 엔드 서버에서 PSI 웹 서비스에 액세스할 수 있도록 이러한 포트에 대한 트래픽을 허용하는 방화벽 규칙을 수동으로 작성해야 합니다. 방화벽에서 이러한 포트를 차단하는 경우 그림 6과 같은 오류 메시지가 표시되고 프런트 엔드 서버의 추적 로그에 "connected host has failed to respond"라고 기록됩니다.

그림 6 Project Web Access에서 Project Server에 액세스 불가(더 크게 보려면 이미지를 클릭하십시오.)

MOPS 서비스 및 서비스 계정

프런트 엔드/백엔드 통신 문제를 해결한 경우 Project Web Access에 액세스할 수 있어야 합니다. 축하합니다. 이제 보다 어려운 MOPS 특정 문제에 대해 살펴보겠습니다. MOPS 응용 프로그램 서버에서 응용 프로그램 이벤트 로그를 열어 보십시오. 그림 7과 같이 "Queue system could not start"라는 오류 메시지가 수천 또는 수백 개 있더라도 놀라지 마십시오. MOPS 서비스로 인해 CPU 사용률이 약 100%가 될 수도 있습니다.

그림 7 큐 시스템을 시작할 수 없음(더 크게 보려면 이미지를 클릭하십시오.)

큐 시스템은 MOPS 데이터베이스 삽입 및 업데이트 요청 처리, 정리 및 유지 관리 작업 실행, 데이터 분석 작업을 위한 보고 데이터베이스 업데이트 등과 같은 작업을 수행하기 위한 MOPS 응용 프로그램 인프라의 핵심 요소입니다. 자세한 내용은 "Microsoft Office Project Server 2007 Queuing System" 기사를 참조하십시오. 이 기사에 따르면 큐 시스템은 어셈블리 Microsoft.Office.Project.Server.Queuing.exe에서 구현되는 Windows 서비스를 사용하며, SharePoint 구성 관리 및 타이머 서비스 계정의 ID를 사용하여 팜의 구성 데이터베이스에 액세스합니다.

Windows 서비스는 시작할 때 구성 데이터베이스에서 모든 SSP 목록(해당 SSP 관리자 계정 및 암호 포함)을 검색한 후 해당 SSP 관리자 계정의 컨텍스트에서 PWA 사이트에 연결된 각 SSP에 대해 추가 Microsoft.Office.Project.Server.Queuing.exe 프로세스를 시작합니다. 즉, Microsoft.Office.Project.Server.Queuing.exe가 서로 다른 여러 계정에서 여러 인스턴스를 시작하므로, MOPS 응용 프로그램 서버에서 실행 중인 Microsoft.Office.Project.Server.Queuing.exe 프로세스의 총 수는 SSP 수에 1을 더한 값과 같습니다.

추가 프로세스 인스턴스는 큐 작업자 프로세스입니다. 개별 큐 작업자 프로세스에서는 연결된 SSP의 PWA 사이트를 결정하고, PWA 사이트마다 별도의 폴링 스레드를 시작하며, 해당 PWA 사이트 데이터베이스의 큐에 있는 작업을 처리합니다. 큐 시스템은 이렇게 작동하며 Windows 작업 관리자에서 해당 사실을 확인할 수 있습니다.

PWA 사이트에 SSP 하나가 연결되어 있는 팜의 MOPS 응용 프로그램 서버에서는 두 Microsoft.Office.Project.Server.Queuing.exe 프로세스가 실행되고 있습니다. 그 중 하나는 구성 관리 계정으로 실행되고 다른 하나는 SSP 관리자 계정으로 실행됩니다. 그림 8에 표시된 것처럼 이 테스트 환경에서 이 계정은 WssConfigAdmin 및 SspConfigAdmin입니다.

그림 8 액세스 거부로 인한 프로세스 간 통신 실패(더 크게 보려면 이미지를 클릭하십시오.)

큐 시스템이 시작되지 않는 이유는 무엇입니까? 응용 프로그램 이벤트 로그의 오류 항목에는 충분한 정보가 제공되지 않지만, SharePoint 3.0 Central Administration의 "진단 로깅"에서 "작업" 탭의 모든 범주에 대한 "추적 로그에 보고할 최소 중요 이벤트"를 "자세한 정보 표시"로 임시로 설정하여 자세한 정보를 확인할 수 있습니다.

그림 8은 결과 추적 로그를 보여 줍니다. 자세히 살펴보면 ProjectQueueService(전체 Window 서비스)가 QueueExecService(큐 작업자 프로세스)를 시작하지만 액세스 거부로 인해 QueueExecService 프로세스가 실패한다는 사실을 알 수 있습니다. QueueExecService가 실패하면 ProjectQueueService는 이 서비스를 다시 시작하려고 시도하지만 동일한 이유로 다시 실패합니다. 이런 식으로 CPU를 계속 사용하고 이벤트 및 추적 로그에 수천 개의 오류가 기록됩니다. 결국 무한 루프에 빠지게 됩니다.

아무리 자세한 추적 로그라고 하더라도 액세스 거부 오류의 정확한 이유는 표시되지 않습니다. 그러나 걱정하지 마십시오. 제거 프로세스를 통해 근본적인 원인을 빠르게 파악할 수 있습니다.

SharePoint 3.0 Central Administration에서 SSP 관리자 계정을 변경하고 구성 관리 계정(WssConfigAdmin)을 지정하면 큐 시스템이 시작됩니다. 반면, SSP 관리자 계정을 변경하지 않고(SspConfigAdmin) Windows 서비스에 대한 서비스 계정으로 사용하더라도 큐 시스템이 시작됩니다.

구성 관리 계정과 SSP 관리자 계정에 필요한 모든 권한이 갖춰지면 ProjectQueueService와 QueueExecService가 다른 계정을 사용하는 경우 큐 시스템이 시작되지 않습니다.

이는 로컬 컴퓨터에서 상호 작용하려는 개별 프로세스 간에 사용 권한 문제가 있다는 명시적인 표시입니다. ProjectQueueService 프로세스와 QueueExecService 프로세스는 서로를 모니터링하여 서비스 동작이 일관되게 수행되는지 확인해야 합니다(그림 8의 추적 로그에서 ProcessWatcher 항목 참조). 예를 들어, ProjectQueueService Windows 서비스를 종료하면 QueueExecService 작업자 프로세스도 함께 종료되어야 합니다.

다른 보안 컨텍스트에서 실행 중인 프로세스에 액세스하려고 하면 오류가 발생합니다. 다른 보안 컨텍스트의 프로세스에 액세스하려면 추가 권한이 필요합니다. 서비스 계정에 이러한 권한이 있더라도 Windows Server 2008에서는 UAC(사용자 계정 컨트롤)가 기본적으로 사용되어 프로세스가 표준 권한으로 실행되기 때문에 여전히 액세스가 거부됩니다.

UAC를 사용하지 않도록 설정하면 ProjectQueueService 및 QueueExecService 프로세스가 상위 권한으로 실행될 수 있고 큐 시스템이 시작됩니다. 구성 관리 계정을 모든 SSP에 대한 관리자 계정으로 사용하여 모든 큐 프로세스를 동일한 계정으로 실행할지, UAC를 비활성화하여 MOPS 응용 프로그램 서버의 보안을 약화시킬지는 사용자가 직접 판단하여 선택해야 합니다.

SharePoint 리소스

SharePoint 제품 및 기술 웹 사이트
microsoft.com/sharepoint

Windows SharePoint Services TechCenter
technet.microsoft.com/windowsserver/sharepoint

Windows SharePoint Services 개발자 센터
msdn.microsoft.com/sharepoint

Microsoft Office Project 2007 일반 참조
msdn.microsoft.com/library/bb258902

Microsoft SharePoint 제품 및 기술 팀 블로그
blogs.msdn.com/sharepoint

관리 및 서비스 계정 계획(Office SharePoint Server)
technet.microsoft.com/library/cc263445

Analysis Services 통합

"Project Server 2007 Cube Building Service에서 SQL Server 2005 Analysis Services를 사용하기 위한 요구 사항"(기사 작성 시점인 2007-04-05 기준)에 요약된 지침을 따를 때 발생할 수 있는 SQL Server 2005 Analysis Services 문제를 설명하면서 이 칼럼을 마무리하겠습니다. 설명한 것처럼 SQL Server 2005 데이터베이스를 만들어 Analysis Services 리포지토리를 작성하는 단계를 따를 경우 PWA에서 큐브를 작성할 때 그림 9와 같은 오류가 발생합니다.

그림 9 잘못된 Analysis Services 구성으로 인한 큐브 작성 오류(더 크게 보려면 이미지를 클릭하십시오.)

중요한 점은 MOPS 2007이 SQL Server 2000 Analysis Services용으로 설계되었다는 사실입니다. SQL Server 2005 Analysis Services는 이전 버전과의 호환성을 위해 추가 구성 단계를 수행해야 합니다. SQL Server 2000 버전은 큐브 빌드에 대한 리포지토리 정보를 Microsoft Jet 데이터베이스에 저장합니다. Jet 데이터베이스를 마이그레이션하여 SQL Server 2005에서 사용할 수도 있지만 MOPS를 다시 배포할 필요는 없습니다.

필자가 참조한 TechNet 기사에는 Jet 데이터베이스가 실제로 존재하는지 여부에 상관없이 Jet 데이터베이스의 기능을 에뮬레이션하도록 SQL Server 2005를 구성하는 방법이 설명되어 있습니다. 하지만 이 기사에는 Analysis Services가 Jet 데이터베이스를 사용하도록 구성되어 있거나(이전 방법), 사전 구성된 SQL Server 2005 데이터베이스를 사용하도록 구성되어 있거나(기본 방법) 상관없이 MOPS는 데이터베이스 서버의 .dso 파일 공유에서 리포지토리 잠금 정보를 검사한다는 내용이 언급되어 있지 않습니다.

이러한 파일 공유가 설정되어 있지 않고 SSP 관리자 계정에 이 파일 공유에 대한 전체 제어 권한이 부여되어 있지 않으면 큐브 빌드에 실패하고 그림 9와 같은 사용 권한 오류가 발생합니다. SQL Server 2005 Analysis Services가 MOPS Cube Building Service에서 제대로 작동하게 하려면 "큐브 구성" 첨부 워크시트에 요약된 단계를 수행하십시오.

결론

MOPS 2007은 배포하기가 쉽지 않습니다. 아키텍처가 복잡하므로 성공적으로 배포하려면 SharePoint 3.0 Central Administration에서 응용 프로그램 풀, 공유 서비스, SSP 관리 사이트 및 PWA 사이트를 구축하여 적절한 서버 팜 구성 계획, 이진 파일 설치, 응용 프로그램 서버 및 웹 프런트 엔드 서버에서 SharePoint 제품 및 기술 구성 마법사 실행, 등 다양한 단계를 수행하여 SQL Server Management Studio에서 Analysis Services를 최종적으로 구성해야 합니다.

배포 시 Windows 방화벽 및 UAC와 같은 Windows Server 2008의 보안 기능과 SharePoint 관리 도구의 취약성 및 MOPS 배포 설명서에 누락된 내용 등을 조정하고 보강해야 합니다. SharePoint 3.0 Central Administration에서는 응용 프로그램 풀에서 서버 팜의 네트워크 서비스 계정을 사용할 경우 경고하거나, 모든 필요한 구성 변경 사항을 자동으로 적용하거나(예: IIS 사이트 바인딩 및 Windows 방화벽 규칙), 구축된 PWA 사이트의 작업 상태를 검사할 수 없습니다.

아무런 조정이나 보강 없이 그대로 사용할 수 있다는 기대를 버리십시오. 성공적인 배포를 위해서는 MOPS 아키텍처와 종속성을 완벽하게 파악하고, 제품 권장 사항을 준수하며 테스트 프로젝트 계획 및 리소스를 만들어 MOPS 구성과 기능을 철저하게 검증해야 합니다.

이러한 문제에도 불구하고 MOPS는 엔터프라이즈 플랫폼으로서의 SharePoint의 장점을 그대로 제공합니다. MOPS는 SharePoint 및 웹 서비스 기술을 사용함으로써 클라이언트 워크스테이션에서 데이터베이스에 직접 연결해야 할 필요성을 배제했습니다. 모든 프로그램 관리자는 월요일 아침에 프로젝트 계획을 업데이트하는 경향이 있으며 이렇게 사용량이 많은 시간대에도 MOPS는 큐 시스템을 통해 무중단을 보장하며, 추가 MOSS 기술을 통해 MOPS를 기간 업무(LOB) 응용 프로그램과 통합할 수 있습니다.

과거에 Project Server 2003에 대한 비즈니스 솔루션을 개발했던 경험에 비추어 볼 때 MOPS 2007 배포 문제는 과거의 확장성 문제, 느린 네트워크 연결로 인한 구형 ODBC 연결 문제, 데이터베이스 쿼리 작성 문제(너무 많은 JOIN 문이 포함되어 Excel을 사용하여 모든 하위 쿼리 추적) 등에 비해 아주 사소한 수준에 불과합니다. MOPS 2007은 EPM 혁신의 주요한 이정표이며 배포할만한 충분히 가치가 있습니다.

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

목차

추가 리소스