Dela via

Exchange Server 2013의 OAB

  • Artikel

최초 문서 게시일: 2012년 10월 27일 토요일

OAB의 발전 과정

흔히 OAB라고 하는 오프라인 주소록은 지금까지 오랫동안 Exchange 인프라의 중요한 구성 요소였습니다. OAB는 오프라인일 때 주소록을 검색하기 위해 Microsoft Outlook 클라이언트에서 캐시된 Exchange 모드로 사용됩니다. 또한 OAB는 Exchange 서버의 작업을 줄이는 데도 중요합니다. 캐시된 모드 Outlook 클라이언트는 항상 로컬 OAB를 먼저 쿼리하기 때문입니다.

OAB는 매번 Exchange 릴리스와 함께 발전해 왔으며, OAB 아키텍처의 마지막 대대적 정비는 Exchange Server 2007에서 이루어졌습니다. 여기서 OAB의 배포를 주로 담당하는 CAS 서버 역할과 함께 OAB의 웹 배포를 도입했습니다. 그러나 OAB 생성 프로세스 자체는 큰 변화가 없었습니다.

지금까지는 말입니다

Exchange Server 2013에 도입된 서버 역할 아키텍처 변경에 따라 OAB가 생성되고 클라이언트에 배포되는 방식도 변경했습니다. Exchange 2013의 새로운 OAB를 이전 버전과 비교하면서 살펴보겠습니다.

OAB 생성과 관련된 변경 사항

OAB를 생성하는 서버

모든 이전 Exchange 릴리스에서는 OAB 생성이 Server 속성을 통해 특정 Exchange 서버에 바인딩되었습니다. 첫 번째 Exchange 사서함 서버를 설치하면 이 서버가 OAB 생성 서버로 지정됩니다. 필요에 따라 새로운 OAB를 만들 수 있는데, 새 OAB를 만들 때는 OAB 생성 서버를 지정해야 합니다.

Exchange Server 2010의 OAB:

Get-OfflineAddressBook "Default Offline Address Book" | fl name,server
 
Name : Default Offline Address Book
Server : MBX1

이 방식의 단점은 한 서버만 OAB를 생성하도록 구성되어 단일 실패 지점이 된다는 것입니다. 이 서버를 오랜 기간 사용할 수 없는 경우 OAB 생성이 영향을 받습니다.

Exchange 2013에서는 OAB가 조직 사서함이라고 하는 특정 유형의 중재 사서함을 호스팅하는 각 Exchange 2013 사서함 서버에서 생성됩니다. OAB 생성이 더 이상 Server 매개 변수에 바인딩되지 않습니다.

Exchange Server 2013의 OAB:

Get-OfflineAddressBook "Default Offline Address Book (Ex2012)" | fl name,server
 
Name : Default Offline Address Book (Ex2012)
Server :

특정 서버에서 OAB의 바인딩을 해제하면 동일한 OAB를 여러 사서함 서버에서 생성할 수 있습니다. 이 새로운 아키텍처는 OAB 생성에 있어 한층 뛰어난 유연성을 제공합니다.

OAB를 생성하는 구성 요소

이전 Exchange 버전에서는 Microsoft Exchange System Attendant 서비스가 OAB 생성을 담당하는 주역이었습니다. OAB 생성은 예약된 프로세스로서, 서버의 작업에 관계없이 OAB 속성에 구성된 예약 시간에 시작되었습니다.

Exchange 2013에서는 Microsoft Exchange 사서함 도우미 서비스에 따라 실행되는 사서함 도우미인 OABGeneratorAssistant가 OAB를 생성합니다. 대부분의 다른 사서함 도우미와 마찬가지로 OABGEnerationAssistant는 스로틀되는 프로세스이므로 서버 작업에 따라 실행되거나 일시 중지됩니다.

OAB 파일이 저장되는 위치

이전 Exchange 버전에서는 사서함 서버에서 생성되는 OAB가 %ExchangeInstallPath%\ExchangeOAB 폴더에 있었습니다. 이 폴더는 공유되므로 CAS에서 Outlook 클라이언트에 배포할 OAB 파일을 검색할 수 있었습니다.

Exchange 2013에서는 OAB 파일이 생성된 후 일단 조직 사서함에 저장되었다가 나중에 %ExchangeInstallPath%\ClientAccess\OAB\ 폴더로 복사됩니다.

OAB 배포와 관련한 변경 사항

Exchange 2007과 2010은 웹 배포와 공용 폴더 배포의 두 가지 OAB 배포 방법을 지원했습니다. Exchange 2013에서는 웹 배포 방법만 지원합니다. 그럼 새로운 Exchange에서 변경된 웹 배포 방법을 살펴보겠습니다.

Exchange 2007/2010 CAS는 해당 사서함 서버에서 생성된 OAB 파일을 끌어와서 로컬에 저장했습니다. CAS 역할의 Microsoft Exchange File Distribution Service가 OAB 파일을 끌어오는 작업을 수행했습니다.

클라이언트 쪽에서 OAB 다운로드 흐름은 다음과 같았습니다.

  1. Outlook이 자동 검색에서 OAB URL을 받아 CAS 서버에 연결합니다.
  2. CAS는 사용자를 인증하고 로컬 디스크에서 OAB 파일을 처리합니다.

이 방법의 몇 가지 단점:

  1. OAB 다운로드는 CAS의 로컬 위치에 OAB 파일이 없는 경우 실패합니다.
  2. CAS의 파일 배포 서비스가 작동하지 않을 경우 클라이언트가 오래된 OAB 파일을 받습니다. 다시 말해서, 업데이트를 받지 않습니다.

Exchange 2013에서는 OAB 파일이 CAS의 로컬 위치에 저장되지 않습니다. CAS 2013은 해당 Exchange 2013 사서함 서버를 프록시로 사용하여 모든 OAB 다운로드 요청을 처리합니다. 이러한 아키텍처 변경으로 Microsoft Exchange 파일 배포 서비스가 CAS 역할에서 제거됩니다.

Exchange 2013에서 OAB 다운로드 흐름은 다음과 같습니다.

    1. Outlook이 자동 검색에서 OAB URL을 받아 OAB URL을 통해 지정된 CAS 2013에 연결합니다.

CAS 서버가 다음 작업을 수행합니다.

  1. OAB에 대한 초기 인증
  2. Active Directory를 쿼리하여 요청한 사용자의 가장 가까운 조직 사서함 파악
  3. Active Directory를 다시 쿼리하여 조직 사서함을 호스팅하는 사서함 데이터베이스 파악
  4. Active Manager를 쿼리하여 사서함 데이터베이스가 활성 상태인(탑재된) 사서함 서버 파악
  5. 4단계에서 파악한 사서함 서버를 프록시로 사용하여 요청 처리
  6. OAB 파일을 검색하여 클라이언트에 전달

이 새로운 워크플로는 레거시 OAB 다운로드 워크플로의 단점을 해결합니다.

조직 사서함

조직 사서함은 Exchange 2013에 도입된 새로운 유형의 중재 사서함입니다. 지속형 기능 OrganizationCapabilityOABGen이 있는 중재 사서함을 조직 사서함이라고 합니다. 조직 사서함은 OAB 생성, 저장 및 배포에 있어 중요한 역할을 합니다.

조직 사서함을 호스팅하는 각 Exchange Server 2013 사서함 역할은 환경에 정의된 모든 Exchange 2013 OAB를 생성합니다. OAB는 먼저 조직 사서함에서 생성된 후 나중에 디스크로 복사됩니다.

조직 사서함을 식별하려면 다음 명령을 사용합니다.

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"}

예:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"}
 
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
SystemMailbox{bb558c35... SystemMailbox{bb5... mbx1 Unlimited

조직 사서함에 OAB 파일을 저장하면 OAB 파일의 복원력이 향상됩니다.

요약 - 실제 시나리오:

다음 시나리오를 통해 지금까지 살펴본 주요 요점을 정리해 보겠습니다.

  1. MBX1과 MBX2는 Exchange 2013 사서함 서버이고 DAG의 구성원입니다. CAS1은 Exchange 2013 CAS입니다.
  2. 조직 사서함은 사서함 데이터베이스 DB1에 있습니다. DB1에는 MBX1과 MBX2의 복사본이 있습니다.
  3. DB1은 현재 MBX1에서 활성 상태입니다.
  4. MBX1의 Microsoft Exchange 사서함 도우미 서비스가 OAB를 생성합니다.
  5. OAB는 먼저 조직 사서함에서 생성된 후 나중에 MBX1의 디스크로 복사됩니다. 이때 MBX2는 OAB 생성에 있어 어떠한 역할도 수행하지 않습니다.
  6. Outlook 클라이언트가 OAB를 다운로드하려고 OAB URL을 통해 CAS1에 연결합니다.
  7. CAS1이 Active Manager를 쿼리하여 MB1에서 활성 상태인 조직 사서함(DB1)을 호스팅하는 데이터베이스를 찾습니다.
  8. CAS1은 MBX1을 프록시로 사용하여 OAB 다운로드 요청을 처리하고 파일을 다시 클라이언트로 보냅니다.
  9. 이때 정전으로 MBX1이 다운되어 DB1이 MBX2 서버에서 활성화됩니다.
  10. CAS1이 또 다른 OAB 다운로드 요청을 받아 Active Manager를 다시 쿼리하고 이번에는 MBX2를 프록시로 사용하여 요청을 처리합니다. 현재는 DB1이 MBX2에서 활성화되어 있기 때문입니다.
  11. MBX2는 조직 사서함에 있는 OAB 파일을 디스크로 추출하여 최신 파일이 클라이언트에 전송되도록 합니다.
  12. MBX1가 다시 작동되지만 DB1은 계속 MBX2에서 활성 상태로 유지됩니다.
  13. 다음 번 OAB 생성 작업 주기에서는 MBX2의 Microsoft Exchange 사서함 도우미 서비스가 OAB를 생성합니다.

이 블로그 시리즈의 다음 글에서는 Exchange 2013에서 새로운 OAB를 관리하는 방법에 대해 이야기합니다.

Bhalchandra Atre

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 OAB in Exchange Server 2013을 참조하십시오.