가용성 계획(Search Server 2008)

  • 아티클

업데이트 날짜: 2009년 3월

적용 대상: Microsoft Search Server 2008

 

마지막으로 수정된 항목: 2015-03-09

이 문서에서는 SharePoint 제품 및 기술 환경의 일반적인 가용성, 비용 및 가용성 관련 문제점과 환경에서 사용할 수 있는 전략 및 솔루션에 대해 설명합니다. 팜에서 Microsoft Search Server 2008을 실행 중인 경우에는 이 문서를 읽어야 합니다. 이 문서와 함께 제공되는 Office SharePoint Server 2007 가용성 모델(https://go.microsoft.com/fwlink/?linkid=122369&clcid=0x412 (영문))을 다운로드 및 인쇄할 수 있습니다. 이 모델에서는 이 문서의 콘텐츠를 포스터 크기로 요약하여 제공합니다.

가용성이란?

가용성은 사용자가 SharePoint 제품 및 기술 환경을 사용 가능하다고 인식하는 정도입니다. 가용성을 보장한다는 것은 시스템을 복원 가능한 상태로 유지하는 것을 의미합니다. 즉, 서비스에 영향을 주는 사고의 발생 빈도를 줄이고, 사고가 발생하는 경우에는 효과적인 조치를 제때 취해야 합니다. 가용성 전략을 사용하면 사용자가 계획되거나 계획되지 않은 가동 중지 시간을 인식하는 정도를 최소화할 수 있습니다.

가용성은 보통 9의 개수로 표현되는 가동 시간 백분율로 측정합니다. 이는 지정된 시스템이 활성 상태이며 작동되는 시간을 백분율로 나타내는 것입니다. 예를 들어 가동 시간 백분율이 99.999인 시스템의 경우 가용성이 '9가 5개'라고 할 수 있습니다.

다음 표에는 9의 개수와 그에 해당하는 실제 시간이 나와 있습니다.

적절한 가동 시간 백분율 일간 가동 중지 시간 월간 가동 중지 시간 연간 가동 중지 시간

95

72.00분

36시간

18.26일

99

14.40분

7시간

3.65일

99.9

86.40초

43분

8.77시간

99.99

8.64초

4분

52.60분

99.999

0.86초

26초

5.26분

전체 가동 중지 시간을 합리적으로 예측할 수 있다면 아래 수식을 사용하여 연간, 월간 또는 주간 가동 시간 백분율을 계산할 수 있습니다.

% 가동 시간/년 = 100 - (8760 - 연간 총 가동 중지 시간)/8760

% 가동 시간/월 = 100 - ((24 * 해당 월의 일 수) - 해당 월의 총 가동 중지 시간)/(24 * 해당 월의 일 수)

% 가동 시간/주 = 100 - (168 - 해당 주의 총 가동 중지 시간)/168

가용성과 동일시하면 안 되는 개념

가용성은 데이터 보호 및 복구나 재해 복구가 아닙니다. 그러나 이러한 개념은 가용성과 관련이 있으며, 모든 고가용성 시스템에는 데이터 보호 및 재해 복구 계획이 마련되어 있어야 합니다. 데이터 보호 및 복구는 다음과 같은 특정 비즈니스 요구 사항의 기본이 되는 일반 비즈니스 요구 사항입니다.

  • 여러 버전의 항목 또는 사이트를 보관하고 검토 가능

  • 실수로 삭제된 항목 또는 사이트 복구

  • 법적, 규정 또는 업무상의 이유로 데이터 보관

  • 예기치 않은 하드웨어 또는 소프트웨어 장애 발생 시 시스템 복원

또한 가용성은 BCM(비즈니스 연속성 관리)이 아닙니다. BCM은 위기 상황을 처리하기 전에 미리 준비해 두는 비즈니스 결정 사항, 프로세스 및 도구로 구성됩니다. 위기 상황은 국지적, 지역적 또는 국가적 상황이거나, 해당 비즈니스에만 관련될 수 있습니다.

SharePoint 제품 및 기술 가용성 및 데이터 보호 관리 전략은 기술 BCM 계획에 포함될 수 있지만 전체 BCM 계획은 훨씬 더 포괄적인 개념으로 다음과 같은 요소를 포함합니다.

  • 명확하게 문서화된 절차

  • 주요 비즈니스 레코드의 오프사이트 저장소

  • 명확하게 지정된 연락처

  • 지속적인 직원 교육

  • 오프사이트 복구 메커니즘

가용성 관련 비용

가용성은 비용이 많이 드는 시스템 요구 사항 중 하나입니다. 가용성 수준이 높고 보호할 시스템 수가 많을수록 가용성 솔루션이 더 복잡해지고 비용이 증가할 가능성이 높습니다. 가용성에 투자하는 경우 다음과 같은 비용이 발생합니다.

  • 종종 장애 조치(failover) 및 복구를 위한 사용자 지정 스크립트와 같은 복잡한 소프트웨어 간 작업이 포함되는 추가 하드웨어 및 소프트웨어

  • 추가적인 운영 복잡성

가용성을 확보하는 데 드는 비용은 비즈니스 요구 사항에 기반하여 평가해야 합니다. 조직 내 모든 솔루션에 동일한 수준의 가용성이 필요한 것은 아닙니다. 여러 사이트, 서비스(예: 검색 및 비즈니스 인텔리전스) 또는 팜에 서로 다른 수준의 가용성을 제공할 수 있습니다.

가용성은 고객 그룹의 기대치를 설정하기 위해 IT(정보 기술) 그룹에서 SLA(서비스 수준 계약)를 제공하는 핵심 영역입니다. 대부분의 IT 조직은 여러 비용 부과 수준(chargeback)과 연결된 다양한 SLA를 제공합니다.

참고

대부분의 조직에서는 가용성을 계산할 때 계획된 유지 관리 작업 시간을 구체적으로 제외하거나 추가합니다.

SharePoint 제품 및 기술의 가용성 관련 문제점

SharePoint 제품 및 기술 배포에서는 가용성 제공과 관련하여 다음과 같은 문제가 발생할 수 있습니다.

  • 패치를 적용하거나 팜을 업그레이드하는 동안 팜을 사용할 수 없습니다.

  • 여러 서버에 인덱스 역할을 설치하여 인덱스 서버 중복을 구현할 수 없습니다. 인덱스 서버의 손실을 막으려면 서버를 다시 설치하고 백업에서 복원하거나 검색이 콘텐츠를 다시 크롤링하는 동안 약간 오래된 결과를 사용해야 합니다. 또는 장애 조치 후 검색 가용성 섹션에 설명되어 있는 기법 중 하나를 사용하여 검색을 복구하는 데 드는 시간을 줄일 수 있습니다.

  • SharePoint 제품 및 기술은 SQL Server 미러링을 인식하지 못합니다. SQL Server 미러링을 가용성 기술로 사용하는 것이 좋지만, 이 방법을 사용하려면 추가 자동화 작업이 필요합니다.

가용성 고려 시기

가용성 요구 사항은 SharePoint 솔루션 핵심 디자인의 일부로 고려하는 것이 좋습니다. 솔루션을 배포한 후 향상된 가용성을 제공할 수도 있습니다. 운영상의 이유로 팜 내에서 핵심 솔루션을 배포 및 조정한 다음 가용성 솔루션을 테스트하는 것이 좋습니다.

가용성 요구 사항 확인

조직의 사이트, 서비스 또는 팜 가동 중지 시간 허용 범위를 측정하려면 사이트, 서비스 또는 팜과 관련된 다음 질문에 답하십시오.

  • 사이트, 서비스 또는 팜을 사용할 수 없는 경우 조직의 직원이 업무를 수행할 수 없습니까?

  • 사이트, 서비스 또는 팜을 사용할 수 없는 경우 비즈니스 및 고객 트랜잭션이 중지되어 사업 기회와 고객을 잃게 됩니까?

위 질문 중 하나라도 예라고 답한 경우 가용성 솔루션에 투자해야 합니다.

가용성 전략 선택

다음을 포함한 여러 가지 방법 중 하나를 선택하여 가용성을 강화할 수 있습니다.

  • 구성 요소의 내결함성

  • 팜 내 서버 역할 간 중복 및 장애 조치

  • 서버 팜 간 중복 및 장애 조치

가용성을 위한 시스템 요구 사항

이상적인 시나리오에서는 장애 조치 구성 요소와 시스템이 플랫폼, 하드웨어, 서버 수 등 모든 측면에서 기본 구성 요소 및 시스템과 일치합니다. 최소한 장애 조치 환경에서는 장애 조치 중 예상되는 트래픽을 처리할 수 있어야 합니다. 장애 조치 사이트에서는 일부 사용자에게만 서비스를 제공합니다. 시스템은 최소한 다음 조건에 일치해야 합니다.

  • 운영 체제 버전 및 모든 업데이트

  • SQL Server 버전 및 모든 업데이트

  • SharePoint 제품 및 기술 버전 및 모든 업데이트

이 문서에서는 주로 SharePoint 제품 및 기술의 가용성을 논의하지만 시스템 가동 시간은 시스템의 다른 구성 요소의 영향을 받기도 합니다. 특히 다음과 같은 점을 고려해야 합니다.

구성 요소 내결함성

모든 시스템에서 RAID(Redundant Array of Independent Disks) 배열을 포함하여 시스템에 적합한 내결함성 하드웨어를 확보하도록 하드웨어 공급업체와 협력하는 것이 좋습니다. 자세한 내용은 성능 및 용량 계획(Windows SharePoint Services)을 참조하십시오.

구성 요소 내결함성을 계획하는 경우 다음을 고려합니다.

  • 서버 내 모든 구성 요소를 완전히 중복하는 것은 불가능하거나 실용적이지 않습니다. 추가 중복을 확보하려면 추가 서버를 사용합니다.

  • 인덱스 서버 역할은 중복될 수 없으므로 인덱스 서버 역할의 구성 요소 중복을 고려합니다.

  • 최대 중복을 확보할 수 있도록 서버의 여러 전원 공급 장치가 서로 다른 전원에 연결되어 있는지 확인합니다.

팜 내 서버 역할 간 중복 및 장애 조치

SharePoint 제품 및 기술에서는 용량을 늘리고 성능을 개선하며 기본 가용성을 제공하도록 팜 내의 중복되는 컴퓨터에서 서버 역할 실행(즉, 확장)을 지원합니다. 용량 및 성능에 따라 팜의 서버 수 및 서버 크기가 모두 결정됩니다. 기본 요구 사항을 만족하면 서버를 더 추가하여 서비스의 전반적인 가용성을 늘릴 수 있습니다.

단일 서버 팜 내의 가용성

단일 팜 가용성

다음 표에서는 SharePoint 중앙 관리 웹 사이트의 서버 제공 서비스 페이지에 표시된 대로 SharePoint 제품 및 기술 환경의 서버 및 서버 역할과 한 팜에서 각각 사용할 수 있는 기본 중복 전략에 대해 설명합니다.

서버 제공 서비스 팜 내의 기본 설정된 중복 전략

SQL Server

클러스터링 또는 동기식 미러링. 클러스터링은 구현이 더 쉽지만 비용이 많이 듭니다.

동기식 미러링을 사용하는 방법에 대한 자세한 내용은 데이터베이스 미러링 사용(Office SharePoint Server)(백서)을 참조하십시오.

웹 서버

여러 서버에 배포하고 소프트웨어 또는 하드웨어 부하 분산을 사용하여 부하를 분산합니다.

중간 규모의 서버 팜용 웹 서버(웹 응용 프로그램 및 검색 쿼리 서비스)

여러 서버에 배포합니다.

검색 인덱싱

여러 서버에 배포할 수 없으며 중복될 수 없습니다. 다른 가용성 전략을 사용해야 합니다. 자세한 내용은 장애 조치 후 검색 가용성을 참조하십시오.

Excel 계산

여러 서버에 배포합니다.

Project 응용 프로그램

여러 서버에 배포합니다.

자세한 내용은 중복 계획(Office SharePoint Server)을 참조하십시오.

단일 팜의 데이터베이스 가용성 전략 비교: SQL Server 장애 조치 클러스터링과 SQL Server 고가용성 미러링

다음 표에서는 장애 조치 클러스터링과 동기식 SQL Server 고가용성 미러링을 비교합니다.

SQL Server 장애 조치 클러스터링 SQL Server 고가용성 미러링

장애 발생 시 즉시 미러링을 수행합니다.

장애 발생 시 즉시 미러링을 수행합니다.

트랜잭션 일관성을 유지합니다.

트랜잭션 일관성을 유지합니다.

트랜잭션 동시성을 유지합니다.

트랜잭션 동시성을 유지합니다.

복구 시간이 짧습니다(수초에서 수분).

복구 시간이 조금 더 깁니다(수초에서 수분).

장애는 데이터베이스 노드에서 자동으로 검색됩니다. SharePoint 제품 및 기술에서는 SharePoint 제품 및 기술 관점에서 장애 조치가 원활하게 자동으로 진행되도록 클러스터를 참조합니다.

SharePoint 제품 및 기술 장애 조치를 수행하려면 스크립팅이 필요합니다.

저장소는 클러스터의 노드 사이에서 공유되므로 장애가 발생한 저장소를 보호하지 않습니다.

주 데이터베이스 서버 및 미러 데이터베이스 서버 모두 로컬 디스크에 데이터를 작성하므로 장애가 발생한 저장소를 보호합니다.

비싼 공유 저장소가 필요합니다.

저렴한 DAS(직접 연결된 저장소)를 사용할 수 있습니다.

서브넷이 동일합니다.

SQL Server와 웹 서버 사이의 대기 시간은 최대 1밀리초(ms)입니다.

SQL Server의 단순 복구 모델을 사용할 수 있습니다. 단, 클러스터가 손실된 경우 마지막 전체 백업만 복구 지점으로 사용할 수 있습니다.

SQL Server의 전체 복구 모델을 사용해야 합니다.

성능 오버헤드가 발생하지 않습니다.

트랜잭션 대기 시간이 나타납니다. 메모리 및 프로세스 오버헤드가 추가됩니다.

운영 부담이 최소로 유지됩니다.

스크립팅 및 SQL Server 별칭 설정을 비롯한 추가 운영 부담이 있습니다.

단일 팜으로 구성된 가까이 위치한 데이터 센터("연장된" 팜) 간 중복 및 장애 조치

일부 기업에서는 단일 팜으로 구성할 수 있도록 고대역폭 연결을 사용하여 데이터 센터를 가까이 배치합니다. 이러한 구성을 "연장된" 팜이라고 합니다. 연장된 팜이 작동하려면 한 방향의 SQL Server 및 웹 서버 간 대기 시간이 1밀리초 미만이고 초당 대역폭 속도가 1기가비트 이상이어야 합니다.

  • 이 시나리오에서는 동기식 미러링을 사용하여 데이터베이스에 대한 중복을 제공할 수 있습니다. 연장된 팜에서는 구성 데이터베이스 및 콘텐츠 데이터베이스를 미러링할 수 있습니다. 한 회사에서 연장된 팜을 사용한 방식의 사례 연구에 대한 자세한 내용은 데이터베이스 미러링을 사용한 SharePoint 고가용성 사례 연구(백서)를 참조하십시오.

  • SAN 공급업체와 상의하여 지리적으로 분산된 여러 서버 클러스터에서 실행하는 SQL Server와 같이 여러 데이터 센터에 걸쳐 가용성을 제공하기 위해 SAN 복제를 사용할 것인지 또는 지원되는 다른 메커니즘을 사용할 것인지 결정합니다. 이때 SAN 복제 솔루션이 충분한 수준의 동시성 및 트랜잭션 일관성을 제공하는지 확인해야 합니다.

연장된 팜에서는 다음을 통해 SSP를 실행하는 응용 프로그램 서버에 대해 내결함성을 제공할 수 있습니다.

  • 여러 쿼리 서버

  • Excel Calculation Services를 실행하는 여러 서버

이 시나리오에서는 인덱스 서버가 단일 장애 지점입니다. 검색을 백업 및 복원하거나 복구 시 검색의 최신 여부가 중요한 경우에는 장애 조치 SSP 팜을 사용할 수 있습니다. 자세한 내용은 장애 조치 후 검색 가용성을 참조하십시오.

"연장된" 팜

"늘어난" 팜

여러 팜을 사용하는 데이터 센터 간 중복 및 장애 조치

기본 팜과는 별개의 데이터 센터에서 가용성을 제공하도록 장애 조치 팜을 설정할 수 있습니다. 별도의 장애 조치 팜을 사용하는 환경의 특징은 다음과 같습니다.

  • 별도의 구성 데이터베이스 및 중앙 관리 콘텐츠 데이터베이스가 장애 조치 팜에서 유지 관리되어야 합니다.

    참고

    기본 팜에 대체 액세스 매핑을 구성한 경우 장애 조치 팜에도 이를 동일하게 구성하는 것이 매우 중요합니다.

  • 모든 사용자 지정 내용은 두 팜에 모두 배포되어야 합니다.

  • 패치는 두 팜에 모두 개별적으로 적용되어야 합니다.

  • 콘텐츠 데이터베이스에서만 비동기식 미러링을 수행하거나 장애 조치 팜으로 로그를 전달할 수 있습니다.

  • 미러링하거나 로그를 전달한 데이터베이스는 전체 복구 모델을 사용하도록 설정되어야 합니다.

  • SSP 데이터베이스는 백업하여 장애 조치 팜에 복원할 수 있습니다.

SAN 공급업체와 상의하여 여러 데이터 센터에 걸쳐 가용성을 제공하기 위해 SAN 복제를 사용할 것인지 또는 지원되는 다른 메커니즘을 사용할 것인지 결정합니다.

하나 이상의 추가 데이터 센터로 SQL Server 로그를 전달하도록 구성한 경우 이 토폴로지를 많은 데이터 센터에 걸쳐 반복할 수 있습니다.

참고

SQL Server 미러링은 하나의 미러 서버에서만 사용할 수 있지만 여러 보조 서버로 로그를 전달할 수 있습니다.

장애 조치 전 기본 팜 및 장애 조치 팜

장애 조치(Failover) 전의 기본 팜 및 장애 조치 팜

다음 표에서는 SharePoint 제품 및 기술 환경의 서버 및 서버 역할과 서버 팜 간에 각각 사용할 수 있는 기본 중복 전략에 대해 설명합니다.

서버 또는 서버 역할 팜 간의 기본 설정된 중복 전략

SQL Server

SQL Server 비동기식 데이터베이스 미러링, SQL Server 로그 전달 또는 기타 비동기식 복제 메커니즘

참고

검색 정보를 호스팅하는 SSP 데이터베이스에는 사용할 수 없습니다.

프런트 엔드 웹 서버

사용자 지정 내용을 포함하여 두 팜에 모두 배포합니다.

중간 규모의 서버 팜용 웹 서버(웹 응용 프로그램 및 검색 쿼리 서비스)

두 팜에 모두 배포합니다.

검색 인덱싱

두 팜에 모두 배포합니다. 원본 팜에서 백업을 복구하여 장애 조치 팜으로 이동합니다.

Excel 계산

두 팜에 모두 배포합니다. SSP에서 검색을 호스팅하지 않으면 비동기식 데이터베이스 미러링, SQL Server 로그 전달 또는 기타 비동기식 복제 메커니즘을 사용하여 장애 조치 팜으로 데이터를 이동할 수 있습니다.

SSP에서 검색도 호스팅하는 경우 원본 팜에서 백업을 복구하여 이동해야 합니다.

Project 응용 프로그램

두 팜에 모두 배포합니다. 원본 팜에서 백업을 복구하여 장애 조치 팜으로 이동합니다.

비동기식 복제 및 검색

검색을 사용하려면 검색 데이터베이스, SSP 데이터베이스 및 인덱스가 완벽하게 동기화되어야 합니다. 이러한 요구 사항 때문에 비동기식 복제 메커니즘(비동기식 데이터베이스 미러링, 로그 전달 또는 비동기식 SAN 복제)을 사용하여 팜 간에 검색을 복제할 수 없습니다. 장애 조치 팜에서 검색 기능을 제공하려면 검색 SSP를 복구해야 합니다.

참고

검색 또는 Project를 사용하지 않고 SSP를 실행하는 경우 비동기식 복제 메커니즘을 사용하여 데이터를 이동할 수 있습니다.

장애 조치 후 검색 가용성

인덱스 서버 역할은 한 팜 내에서 중복될 수 없습니다. 장애 조치 후 검색의 최신 여부에 관련된 비즈니스 요구 사항에 따라 솔루션의 논리 아키텍처가 결정될 수 있습니다.

  • 업무상 장애 조치 후 즉각적인 최신 검색과 가용성이 필요하지 않은 경우 검색 SSP를 장애 조치 사이트로 백업 및 복원할 수 있습니다.

  • 업무상 빠른 최신 검색과 가용성이 필요한 경우 다음 중 하나를 사용할 수 있습니다.

  • 동일한 두 SSP가 포함된 단일 팜 아키텍처

  • 검색 및 기타 SSP를 호스팅하는 중앙 상위 팜. 중앙 팜의 검색 서비스는 다른 모든 팜의 콘텐츠를 크롤링합니다. 이 아키텍처는 하나 이상의 팜을 지원하는 데 사용할 수 있습니다.

중요

업무상 빠른 최신 검색과 가용성을 필요로 하는 경우 프로필을 사용하면 장애 조치 SSP의 프로필이 기본 SSP의 프로필과 동기화되지 않고 처음 가져올 때의 상태로 유지됩니다. 모든 SSP의 프로필을 동기화된 상태로 유지하려면 32비트 SharePoint Administration Toolkit (영문)(https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x412) 또는 64비트 SharePoint Administration Toolkit (영문)(https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x412)에 포함된 User Profile Replication Engine을 사용해야 합니다. 자세한 내용은 User Profile Replication Engine(Office SharePoint Server)을 참조하십시오.

두 SSP가 포함된 단일 팜

다음 아키텍처는 인덱스 서버의 장애로부터 환경을 보호합니다. 이 토폴로지에서 두 SSP는 동일한 규칙을 사용하여 동일한 콘텐츠를 크롤링합니다. 장애 조치 SSP는 장애 조치가 발생하지 않는 한, 기본 웹 사이트와는 분리되어 있습니다.

두 공유 서비스 공급자가 포함된 단일 팜

2개의 SSP가 구성된 팜

이 토폴로지에는 다음과 같은 제한이 있습니다.

큰 데이터 집합을 시기 적절하게 크롤링하는 기능은 인덱스 서버와 웹 서버 사이의 대기 시간 및 대역폭을 포함한 여러 요소의 영향을 받습니다.

이 토폴로지는 대역폭이 제한된 환경에서 성능을 크게 떨어뜨릴 수 있습니다. 콘텐츠를 두 번 크롤링하면 크롤링하는 콘텐츠 저장소에 부하가 가중되고 저장소 성능이 떨어질 수 있습니다. 인덱스를 최신 상태로 유지하는 검색 기능도 성능 저하의 원인이 될 수 있습다.

중앙 SSP 팜

다음 아키텍처에서는 상위 SSP 팜을 사용하여 인덱스 서버의 장애로부터 환경을 보호합니다. 이는 하드웨어를 많이 사용하는 솔루션처럼 보일 수 있지만, 인덱스 서버가 별도의 서버에 있으면 개별 SSP 팜은 클러스터 또는 미러된 데이터베이스 서버와 같은 일부 하드웨어를 공유할 수 있습니다. SSP 팜을 계획하고 구성하는 방법에 대한 자세한 내용은 SSP 아키텍처 계획을 참조하십시오.

이 토폴로지에는 다음과 같은 이점이 있습니다.

  • SSP 관리가 중앙 집중화됩니다.

  • 팜 장애 시 다시 크롤링하지 않아도 됩니다.

중앙 SSP 팜

SSP 장애 조치(Failover) 팜

이 토폴로지에는 다음과 같은 제한이 있습니다.

요약

가용성 요구 사항을 신중하게 검토하십시오. 가용성 수준이 높고 보호할 시스템 수가 많을수록 가용성 솔루션이 더 복잡해지고 비용이 증가할 가능성이 높습니다.

가용성을 확보하는 데 드는 비용은 비즈니스 요구 사항에 기반하여 평가해야 합니다. 조직 내 모든 솔루션에 동일한 수준의 가용성이 필요한 것은 아닙니다. 여러 사이트, 서비스(예: 검색 및 비즈니스 인텔리전스) 또는 팜에 서로 다른 수준의 가용성을 제공할 수 있습니다.

도움 주신 분

Microsoft Office SharePoint Server Content Publishing 팀에서는 이 문서에 도움을 주신 다음 기술 검토자에게 감사를 드립니다.

  • Bill Baer, Microsoft Online Services, Hosted SharePoint, 기술 설계자

  • James Petrosky, Microsoft Consulting Services, 선임 컨설턴트

  • Steve Peschka, Microsoft Consulting Services, IW 선임 설계자

  • Dan Winter, Microsoft Customer Support Services, 에스컬레이션 엔지니어

  • Sean Livingston, Microsoft SharePoint 제품 및 기술, 프로그램 관리자

  • Mike Watson, 기술 설계자

  • Todd Carter, Microsoft Premier Field Engineering, 수석 현장 엔지니어

  • Mike Plumley, Microsoft Office Project Server, 작성자

  • Christophe Fiessinger, Microsoft Office Project, 선임 기술 제품 관리자

  • Sid Shah, Microsoft Search, 프로그램 관리자

  • Luca Bandinelli, Microsoft SharePoint 제품 및 기술, 프로그램 관리자