• 아티클

Post MortemExchange 5.5에서 마이그레이션

Whitney Roberts

프로젝트

켄터키 교육부는 이전에 구현한 Microsoft® Exchange Server 5.5를 Exchange Server 2003으로 마이그레이션해야 했습니다. 기존의 시스템은 매년 600,000명 가량의 교직원, 교수 및 학생을 지원하고 있었습니다.

프로젝트 담당자

이 프로젝트는 KiZAN Technologies 컨설턴트의 지원 하에 켄터키 교육부 산하 교육 기술부(OET)가 담당하였습니다. OET 직원은 기존에 구현된 Exchange 5.5에 대한 관리를 담당했으며 매일 Exchange 서버를 실행하는 작업은 학구의 현지 직원이 담당했습니다.

당면 문제

켄터키 교육부는 켄터키 주 내 178개 학구의 기술적인 방향성을 결정하고 있습니다. 이들 178개 학구는 WAN을 통해 연결되어 있지만 각 학구가 Exchange 5.5 서버를 호스팅하여 자체적으로 관리하고 있으므로 업그레이드도 개별적으로 진행해야 했습니다. 새로운 업그레이드에서는 Outlook® 2003 캐시 모드 클라이언트, 개선된 OWA(Outlook Web Access) 환경, 표준화된 전자 메일 주소 지정 스키마 등을 지원합니다.

당시 많은 학구가 새로운 전자 메일 서버/클라이언트 인프라를 구축하는 동시에 학생들에 대한 전자 메일 지원 기능을 추가하고 있었는데 켄터키 주와 연방 정부의 정책은 학생 신상 정보의 보호와 이러한 정보의 해당 학구 외부 유출 금지를 요구했습니다.

계획

ADC(Active Directory® Connector)를 사용할 수 없었으므로 우리는 새로운 Exchange 조직을 만들어 이 조직으로 마이그레이션했습니다. 전자 메일 주소를 표준화한다는 것은 각 학구와 400개가 넘는 새로운 받는 사람 정책 모두에 대해 이를 식별하는 하위 도메인을 새로 만든다는 것을 의미했습니다. 학생 주소를 보호하기 위해서는 GAL(전체 주소 목록) 시스템을 만든 다음 각 학구의 사용자 지정 주소 목록을 만들어야 했습니다.

실제 마이그레이션 작업에는 새로운 하드웨어를 준비하고, 학구 구성원 자격 및 사용자 유형을 기준으로 사서함을 만들어 구성한 다음 확장 특성을 설정하여 사용자가 적절한 주소 목록에 나타나도록 설정하는 작업이 수반되었습니다.

우리는 잘못 구성된 계정 특성이나 그룹 구성원 자격을 찾고 이를 수정하며 주소 표시 요구 사항을 준수하는 새로운 사서함을 제공하는 Visual Basic® 기반 응용 프로그램을 만들었습니다. 이 응용 프로그램은 178개 학구 모두에 배포되어 학구 서버에서 정기적으로 실행됩니다.

배경

언뜻 봐서는 이러한 작업이 힘이 들거나 기술적으로 어려워 보이지 않을 수도 있습니다. 하지만 이 프로젝트의 비즈니스 규칙과 비즈니스 요구 사항은 상상을 초월했습니다.

과거 수년 동안 표준을 분산해서 관리했을 뿐만 아니라 그 표준이 마구 뒤섞임에 따라서 OET의 관리와 지원이 반드시 필요한 수많은 문제들이 누적되었습니다. 뿐만 아니라 OET는 기존에 구현된 Exchange 5.5가 학구와 교육부의 요구 사항을 동시에 충족하는가라는 문제도 검증해야 했습니다. 이는 학생의 전자 메일을 활용하는 학구의 경우 학생 신상 정보가 주 및 연방 정부의 규정(ed.gov/policy/gen/guid/fpco/ferpa/index.html 참조)에 정해진 대로 해당 학구 외부에는 공개되지 않아야 하며 적절히 보호되어야 한다는 것을 의미했습니다.

Exchange 5.5의 경우, 이러한 규정을 따르게 되면 학구 내의 학생 신상 정보를 다른 학구 또는 GAL 데이터를 공유하는 다른 기관으로 복제할 수 없게 됩니다. 따라서 178개의 Exchange 5.5 사이트 각각에 대해 학생을 숨기고 목록을 복제하고 학생을 다시 표시한 다음 주소 목록을 다시 가져오는 방법으로 가져오기/내보내기 작업을 수동으로 수행해야 했습니다. 이 경우 학생 신상 정보를 소유하는 학구에서는 자기 학구의 학생 데이터와 직원 데이터를 모두 볼 수 있습니다. 하지만 다른 학구에 대해서는 해당 학구의 직원 데이터만 볼 수 있습니다.

기존 시스템의 장단점을 고려해 보았을 때 메시징 인프라를 업그레이드하려면 몇 가지 조건을 충족해야 했습니다. 무엇보다도 켄터키 교육부는 보편적이며 읽을 수 있는 SMTP 명명 구성표를 기반으로 조직 전체의 메시징 인프라를 표준화하고자 했습니다. 이러한 구성표는 교직원과 학생에게 별도의 SMTP 주소 공간을 제공할 수 있어야 했습니다.

또한 새로운 시스템은 개별 학구가 더 이상 메시징을 관리하거나 그 가용성에 대해 책임지지 않도록 중앙 관리 서비스를 제공해야 했습니다. 이는 장애 복구, 메일 흐름, 헬프 데스크 지원 요청 해결 등이 중앙에서 관리된다는 것을 의미했습니다. 따라서 새로운 시스템은 특정 사용자의 지리적 위치나 소속된 학구에 관계없이 모든 학구의 사용자 구성을 표준화하는 중앙 집중화된 방법을 제공해야 했습니다.

더 나아가 새로운 시스템은 모든 학구가 공통된 통합 네임스페이스를 바탕으로 모바일 장치와 웹을 통해 전자 메일에 안전하게 액세스할 수 있도록 지원해야 했습니다.

기존의 Exchange 5.5 시스템에서는 대부분 구현되어 있지 않은 이러한 요구 사항을 고려해 보았을 때 Exchange 2003으로의 업그레이드는 그 여정이 매우 험난해 보였습니다.

솔루션 구성 요소

이러한 비즈니스 요구 사항을 충족하기 위해 Exchange에서 사용할 수 있는 몇 가지 옵션을 배포에 포함하기로 결정되었습니다.

표준화의 부재와 Exchange 5.5 환경의 방대한 규모로 인해 ADC는 사용하지 않기로 했습니다. 대신 새로운 Exchange 조직을 만들어 이 조직으로 마이그레이션했습니다.

각 학구의 교직원 및 학생의 전자 메일 주소를 정리하고 표준화하는 과정에서 400개가 넘는 받는 사람 정책이 만들어졌습니다. 비즈니스 요구 사항을 충족하려면 각 학구를 식별하는 고유한 하위 도메인을 만들 뿐 아니라 학생을 식별하는 규칙도 지정해야 했습니다. 예를 들어 쉘비 카운티의 경우 주 하위 도메인이 shelby.kyschools.us입니다. 각 학구의 학생에게는 stu.라는 하위 도메인이 지정되므로 쉘비 카운티의 학생은 stu.shelby.kyschools.us라는 주소를 사용하게 됩니다.

학생 주소는 해당 학생이 속한 학구 내에서만 표시되어야 하는 반면 직원 주소는 모든 학구에 표시되어야 한다는 조건도 충족해야 했습니다. 이는 그림 1과 그림 2에 나온 것처럼 GAL과 사용자 지정 주소 목록으로 구성된 정교한 시스템을 만들어야 함을 의미했습니다. Exchange 2003으로 마이그레이션할 경우 사용 권한을 통해 주소 목록을 안전하게 보호하고 그룹 구성원 자격을 통해 개별 주소 목록에 대한 액세스를 제어할 수 있다는 장점이 있습니다. 따라서 이 기능을 적절하게 활용하여 직원용과 학생용으로 각각 하나씩 학구 수준 보안 그룹을 두 개 만든 다음 해당 학구 직원과 학생의 GAL 및 주소 목록에 보안을 설정하여 특정 학구 내의 사용자 계정만 특정 주소 목록에 액세스할 수 있도록 설정하였습니다. 기본 GAL과 주소 목록을 제거한 다음 각 주소 목록의 ACL(액세스 제어 목록)에 Everyone과 Authenticated Users 그룹이 표시되지 않도록 만들어 특정 학구의 특정 사용자 유형이 볼 수 있는 주소 목록을 미리 선택할 수 있었습니다.

그림 1 역할 기반 사용자 지정 주소 목록

그림 1** 역할 기반 사용자 지정 주소 목록 **(더 크게 보려면 이미지를 클릭하십시오.)

하지만 사용 권한을 통해서는 주소 표시 문제의 일부만 해결할 수 있었습니다. 이제 어떤 주소 목록에 어떤 사용자가 표시되도록 할지를 제어하는 방법을 알아내야 했습니다. 이에 따라 직원과 학생의 표시 여부를 조회할 수 있게 해 주는 기본 LDAP(Lightweight Direct Access Protocol) 쿼리를 작성한 다음 각 주소 목록과 GAL에 맞게 이 쿼리를 사용자 지정하게 되었습니다. 예를 들어 쉘비 카운티의 직원 GAL을 조회하는 LDAP 쿼리는 쉘비 카운티에 속한 직원과 학생 및 켄터키 주의 다른 모든 학구에 소속된 모든 직원(학생은 제외됨)을 보여 줍니다. 쉘비 카운티의 학생 GAL에는 쉘비 카운티의 직원과 학생만 표시되고 켄터키 주의 다른 학구의 직원이나 학생은 표시되지 않습니다. 이 쿼리를 조직의 모든 학구에 대해 반복해서 실행했습니다. 그림 3은 이 복잡한 마이그레이션을 수행하는 데 사용된 몇 가지 LDAP 쿼리 예를 보여 줍니다.

Figure 3 주소 목록 LDAP 쿼리

직원 GAL LDAP 쿼리

(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))

학구 주소 목록 LDAP 쿼리

(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))

학구 학생 주소 목록 LDAP 쿼리

(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))

학구 직원 오프라인 주소 목록 LDAP 쿼리

(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))

그림 2 직원과 학생을 분리하는 전역 주소 목록

그림 2** 직원과 학생을 분리하는 전역 주소 목록 **(더 크게 보려면 이미지를 클릭하십시오.)

Exchange 사용자 속성 extensionAttribute14(사용자 지정 특성 14)와 extensionAttribute15(사용자 지정 특성 15)에 대한 사용자 지정 값이 이러한 LDAP 쿼리를 가능하게 만든 메커니즘이었습니다. 켄터키 주의 모든 직원과 학생에 대해 extensionAttribute14에는 특정 값을 사용하여 사용자 유형을 지정했고 extensionAttribute15에는 고유 값을 사용하여 직원이나 학생이 소속된 학구를 표시했습니다. 각 학구에는 고유 값을, 그리고 각 사용자 유형에는 동일한 값을 사용함으로써 각 학구의 각 사용자 유형에 필요한 정보를 정확하게 주소 목록에 표시할 수 있었습니다.

이러한 주소 목록은 캐시되지 않은 모드의 Outlook 또는 OWA를 통해 전자 메일에 액세스하는 사용자에게도 올바르게 작동했습니다. 이 프로젝트에서는 msExchQueryBaseDN 특성을 사용함으로써 각 사용자에게 OWA에서 올바른 주소 목록이 표시되도록 할 수 있었습니다. 하지만 캐시 모드에서 Outlook을 실행하는 사용자는 또 다른 문제에 직면했습니다. Outlook에서는 사용자 지정 GAL을 OAB(오프라인 주소록)로 인식하지 않으므로 GAL이 복제된 주소 목록을 추가로 만들어야 했습니다. 그런 다음 Outlook 캐시 모드 사용자를 위해 적절한 OAB 주소록을 사용하여 각 학구의 사서함 저장소를 구성했습니다. 이 솔루션으로 전체 1,500개가 넘는 주소 목록을 관리함으로써 총 178개 학구의 다양한 사용자 유형에 대해 완벽한 기능을 제공할 수 있었습니다.

규정 준수

구조가 실제 환경에서 올바르게 작동하도록 하기 위해 이 구조가 새로 확립된 표준을 철저하게 준수하는지 검증해야 했습니다. 조직에서 Exchange를 사용하는 모든 사용자가 직면하게 되는 몇 가지 어려운 작업이 있었습니다. 이는 모든 학구의 Exchange 서버에서 각 사용자를 정확하게 찾을 수 있어야 할 뿐만 아니라 각 사용자가 정확한 주소 목록에 표시되어야 하기 때문이었습니다.

적절한 주소 목록을 열 수 있는 권한은 보안 그룹을 통해 부여되므로 Exchange 사용자는 학구 도메인 내의 적절한 보안 그룹의 구성원이 되어야 했습니다. 또한 Exchange 사용자의 경우 학구 및 OU(조직 구성 단위) 구성원 자격을 기준으로 msExchQuerybaseDN 특성을 올바르게 설정해야 했습니다. 즉, 사용자의 OU에 따라 사용자 유형이 결정되었습니다.

다음 단계는 학구 구성원 자격 및 사용자 유형을 기준으로 올바른 서버의 올바른 저장소에 사용자의 사서함을 만드는 것이었습니다. Outlook 캐시 모드가 올바르게 작동할 수 있도록 이 작업은 서비스 수준, 사서함 크기 제한 및 오프라인 주소록의 주소 목록에 영향을 주게 되었습니다. 확장 특성은 사용자가 적절한 주소 목록에만 나타나도록 학구 구성원 자격과 사용자 유형을 기준으로 설정되었습니다.

마지막으로 계정 특성이나 그룹 구성원 자격이 잘못 구성되거나 적절하지 않은 값으로 변경된 경우 이를 자동으로 수정하는 방법을 제공해야 했습니다. 사용자가 학구 도메인 내의 한 OU에서 다른 OU로 이동하면 이는 사용자 유형이 변경된 것이므로 사서함 위치, GAL 선택 및 주소 목록 표시 여부가 업데이트되어야 합니다.

이 문제를 해결하기 위해서는 이러한 작업을 수행하고 Active Directory의 일관성과 정확성을 보장해 주는 프로비저닝 시스템이 필요했습니다. 이에 따라 학구의 Exchange 2003 서버에서 정기적으로 실행되는 콘솔 기반 Visual Basic 응용 프로그램을 만들게 되었습니다. 정책 및 표준의 준수 여부를 확인하고 새로운 개체의 생성과 제공을 처리하는 이 응용 프로그램은 178개 학구 모두에 배포되었습니다.

수행해야 하는 작업은 일련의 스크립트로 신속하고 안정적으로 실행하기에는 지나치게 복잡했습니다. 그 결과 Visual Basic 기반 응용 프로그램이 적절한 솔루션이 될 것으로 보였습니다. Visual Basic 기반 응용 프로그램은 효율적이며 구조화된 오류 및 예외 처리를 지원하고 추후에 MIIS(Microsoft Identity Integration Server) 확장 코드에 맞게 응용 프로그램 내부 코드를 쉽게 수정할 수 있어서 코드를 다시 작성하는 작업이 최소화되기 때문이었습니다.

또한 새로운 조직으로 마이그레이션하는 중이었으므로 과거와 현재의 조직이 공존할 수 있는 방법을 찾아내야 했습니다. 새로운 환경에서 지원해야 할 레거시 SMTP 도메인이 178개가 넘었으며 일부 학구는 기존의 학생 전자 메일 도메인을 갖추고 있는 반면 다른 학구는 그렇지 않았습니다. 하지만 모든 학구를 한 번에 마이그레이션할 수 있었으며 일부 학구의 기존 메시지와 주소를 다른 학구에는 아무런 영향도 주지 않고 새로운 시스템으로 가져올 수 있었습니다. 하지만 Exchange 5.5에서 Exchange 2003으로 학구가 마이그레이션되었으므로 원활하지 않은 전자 메일 흐름이 발생하지 않도록 해야 했으며 이는 Exchange 2003 Active Directory와 레거시 Exchange 5.5 디렉터리 간에 일종의 디렉터리 동기화를 구현해야 함을 의미했습니다. Microsoft는 켄터키 교육부가 마이그레이션 기간 동안에만 MIIS를 사용할 수 있도록 허가해 주었고 이에 따라 사용자 지정 확장 코드를 개발하여 마이그레이션 전후 및 마이그레이션 기간 동안 MIIS를 통해 두 Exchange 조직을 동기화하는 데 사용했습니다.

새로운 Exchange 조직으로 이동하면 당연히 MAPI 클라이언트 구성에 영향을 주게 됩니다. 켄터키 교육부는 마이그레이션 기간 동안 다시 구성해야 할 학구 수준 MAPI 프로필이 수만 개가 넘는다는 사실에 직면하게 되었습니다. 다행히 당시 Microsoft에서 Exchange 프로필 도구(ExProfRe.exe)를 출시하게 되어 학구의 프로필을 마이그레이션하는 데 사용할 수 있었습니다. 이때 미리 로드된 값으로 ExProfRe.exe를 실행하는 패키지된 설치 관리자를 만들어 학구 수준 프로필 마이그레이션을 자동화된 방식으로 수행할 수 있게 하였습니다. 이 프로그램은 그룹 정책을 통해 호출되었으며 두 조직 간의 자동화된 프로필 마이그레이션의 성공률이 거의 100%에 이른다는 것을 확인할 수 있었습니다.

하드웨어 업그레이드

새로운 Exchange 2003 서버가 지리적으로 분산된 Exchange 5.5 서버를 대체하게 될 것이므로 이 솔루션의 하드웨어 측면에서는 Exchange 5.5 배포에서 지원한 사용자 수에 더해 학생 계정이라는 추가적인 로드를 지원해야 했습니다. 모든 학구 간 트래픽(인터넷 및 내부)은 전용 T1 회선(일부 학구의 경우 다중 T1 회선)을 통해 이동하도록 WAN 토폴로지가 설계되어 있으므로 서버는 학구 내에서 로컬로 호스팅되어야 했습니다.

예산, 관리 및 장비 호스팅 등의 제약으로 인해 Exchange 서버에 SAN(저장소 영역 네트워크) 연결 저장소가 없으므로 모든 저장소가 내부에 있거나 직접 연결되어 있어야 했습니다. 대부분의 학구에는 랙 저장소와 중앙 냉각 장치가 있는 데이터 센터가 없었으므로 서버는 가능한 한 독립적이어야 했습니다. 다행히 대부분의 학구는 사용자 수가 5,000명 미만이어서 단일 서버 배포가 가능했습니다. 이보다 사용자 수가 많은 학구는 보다 강력한 서버(또는 다중 서버)와 추가 저장소를 사용했으며 때로는 별도의 프런트 엔드 서버를 두어 학생과 직원의 트래픽을 추가로 분리했습니다.

대부분의 학구에는 최대한의 15,000RPM Ultra320 SCSI 드라이브와 여러 개의 RAID 컨트롤러, 그리고 4GB의 RAM으로 구성된 듀얼 프로세서 서버를 배포할 수 있었습니다. 이보다 규모가 큰 학구는 필요한 경우 보다 작은 프런트 엔드 서버를 사용하여 한 대 이상의 4중 프로세서 서버를 배포했습니다. 배포 전에 수행한 벤치마킹 및 성능 테스트 결과 어떠한 사용성 문제나 로드 문제도 나타나지 않았습니다. 하지만 다양한 수준의 로컬 사용 패턴이 서버의 전반적인 성능을 결정하는 실질적인 요인이 될 것으로 예측되었습니다.

POC(개념 증명) 테스트

프로덕션 환경은 178개의 도메인으로 구성된 Active Directory 포리스트 하나로 이루어지지만 POC(개념 증명) 테스트 환경은 13개의 학구 도메인과 빈 루트 도메인 하나로 그 규모를 축소했습니다. 모든 테스트 도메인은 프로덕션 도메인에서 내보낸 데이터로 채웠습니다. 선택된 몇몇 학구의 데이터베이스 사본을 사용하여 가상 Exchange 5.5 서버를 구축하고 구성함으로써 계획된 환경을 조성하고 마이그레이션 프로세스를 테스트할 수 있었습니다. 전체 POC 테스트 환경은 가상 컴퓨터를 사용하여 구축함으로써 이 환경을 기준으로 만들고 확정한 다음 필요할 때 다시 배포할 수 있도록 했습니다.

스크립트(VBScript 사용), SMS(Systems Management Server) 설치 관리자 패키지 및 콘솔 응용 프로그램을 다양하게 조합해 본 후 이를 코드화하고 테스트하여 최종적인 것으로 확정 지었습니다. 그 결과 받는 사람 정책, GAL 및 사용자 지정 주소 목록, 사용 권한을 비롯하여 Exchange 2003 초기 설정 및 구성 작업을 수행하는 스크립트들이 만들어졌습니다. 이러한 마이그레이션 스크립트로 관리 그룹 구성, 학구 도메인 구성(보안 그룹 생성 및 사용 권한 위임), 배포 후 구성 작업도 처리하였습니다.

하지만 Exchange 2003 서버를 준비하는 동안 몇 가지 중대한 과제에 직면하게 되었습니다. 마이그레이션의 나머지 단계를 위태롭게 만들지 않으면서 모든 178개 도메인에 Exchange 서버를 성공적으로 설치해야 했습니다. Exchange 2003은 도메인의 첫 번째 Exchange 2003 서버가 설치되기 전까지는 도메인의 Exchange Domain Servers 그룹이 조직의 ACL에 추가되지 않는다는 점에서, DomainPrep 프로세스를 실행할 때 이 그룹이 추가되는 Exchange 2000과 다릅니다. 따라서 필요한 모든 보안 그룹이 Active Directory의 조직 개체에 나열되도록 하기 위해 지정된 도메인을 설치하고 이 도메인에서 Active Directory 복제 허브 사이트로 Active Directory를 수동으로 복제한 후 Exchange 2003 서버를 설치할 다음 학구로 해당 복제본을 가져와야 했습니다. 조직 개체의 ACL에 이전 학구의 Exchange Domain Servers 그룹이 있는지 확인한 후에만 다음 학구에서 Exchange 2003 서버 설치를 안전하게 시작할 수 있었습니다. 한 도메인에서라도 이 프로세스가 순서에 맞지 않게 완료될 경우 해당 학구는 적어도 설치 작업을 다시 수행해야 하는 어려움을 겪거나 다른 학구에서 다른 모든 학구가 올바르게 나열되지 않는 조직 개체 ACL로 인해 학구 간 커뮤니케이션을 수행할 수 없게 되었습니다.

우리는 POC 환경 내에서 이 프로세스가 올바르게 작동한다는 것을 충분히 확인할 수 있을 때까지 전체 배포, 구성, 서버 준비, 마이그레이션을 여러 번 테스트했습니다.

마이그레이션 및 늘어나는 작업

프로젝트 팀으로부터 POC 프로세스와 그 결과를 승인받음에 따라 마이그레이션을 시작할 준비가 완료되었습니다. OET는 먼저 OET부터 마이그레이션을 시작하여 그 프로세스와 효과를 경험해 보기로 했습니다. 마이그레이션을 수행할 시점에는 모든 서버의 준비가 완료되었고 초기 환경도 검증을 마쳤습니다. 프런트 엔드 프로토콜 서버와 사서함 서버도 모두 배치되어 프로덕션 환경에서 사용자가 사용할 수 있도록 준비를 마쳤습니다.

마이그레이션 계획은 순조롭게 실행되었고 한 서버에서 다른 서버로 콘텐츠를 전송하는 기나긴 21시간이 지난 후 Exchange 2003에서 OET 시스템이 작동하기 시작했습니다. 다행히 Exchange 5.5에서 Exchange 2003으로 Outlook 프로필을 마이그레이션하는 동안 별다른 문제가 발생하지 않았습니다. 우리는 ExProfRe.exe를 호출한 배치 파일을 몇몇 단순한 논리를 기반으로 하여 다양한 구성으로 패키징했습니다. 그런 다음 배치 파일과 ExProfRe.exe를 각 학구의 DC(도메인 컨트롤러) Netlogon 공유에 배포하고 마이그레이션이 끝날 때 그룹 정책을 사용하여 모든 클라이언트에 대해 배치 파일을 실행했습니다. OET에서 이 과정이 올바르게 수행되었으므로 프로세스가 순조롭게 진행될 것이라는 것을 확신할 수 있었습니다.

이때 OET 배포를 통해 얻은 경험을 바탕으로 마이그레이션 계획을 검토하고 재차 승인을 받았습니다. 마이그레이션을 진행하면서 첫 번째 프로덕션 사이트로 6개의 학구를 선택했습니다. 각 학구를 마이그레이션하기 전에 MIIS에서는 Exchange 5.5에서 학구 사서함에 대한 최신 정보를 읽고 학구 도메인의 해당 사용자를 업데이트했습니다. 실제로 조직 간에 사서함 데이터를 이동하는 데는 Exchange 마이그레이션 마법사(Mailmig.exe)를 사용했습니다. 이 마법사는 사서함 데이터를 이동할 때 원래 MIIS에서 Active Directory로 내보낸 데이터에서 모든 프록시 주소를 가져와 업데이트합니다. 메일은 마이그레이션이 진행되는 동안 프런트 엔드 SMTP 서버의 큐에 놓이고 마이그레이션, 마이그레이션 후 서버 구성과 사용자 테스트가 끝난 후에 학구로 보내졌습니다. 학구는 ExProfRe.exe를 사용하여 대규모 클라이언트 마이그레이션을 수행할 준비가 되었습니다.

RUS 관련 문제 극복

Outlook 클라이언트가 올바르게 작동하려면 프로비저닝 솔루션이 특성 값을 설정하는 데 있어서 최종적인 권한을 가지도록 해야 했습니다. 또한 RUS(받는 사람 업데이트 서비스)가 계정 설정 시 이 작업을 마치도록 해야 했지만 RUS는 프로비저닝이 끝난 후에만 실행되어야 합니다. 이 두 가지 목적을 달성하기 위해 178개 학구 모두의 RUS 인스턴스 일정을 "Never"(업데이트 안 함)로 설정하고 프로비저닝이 완료된 후에 시작되도록 RUS를 트리거하는 코드를 프로비저닝 솔루션에 포함했습니다.

대부분의 학구는 사용자 수가 5,000명 미만이었고 매일 수행되는 업데이트 횟수는 이보다 훨씬 적었습니다. 프로비저닝 시스템은 매일 실행이 끝날 때 다시 빌드되는 대신 업데이트를 시작했으므로 RUS가 신속하게 완료되었습니다. 하지만 사용자가 10,000명이 넘는 학구도 몇 곳 있었습니다. 이러한 대규모 환경에서는 업데이트를 수행하는 데 보다 많은 시간이 소요되었으며 대규모 도메인에서 RUS를 다시 빌드해야 할 경우 이를 실행하는 데 일주일 이상이 걸릴 수도 있었습니다. RUS는 실행될 때 모든 개체 유형을 평가하므로 대규모 도메인에서 RUS를 다시 빌드하는 것은 시간과 노력이 많이 드는 일이었습니다.

이 문제를 해결하기 위해 Exchange 제품 그룹의 구성원들과 협력했지만 마땅한 마이그레이션 전략을 찾아내지 못했습니다. 대신 RUS가 일반적으로 수행하는 작업의 많은 부분을 처리하도록 프로비저닝 코드를 개선했습니다. 초기 프로비저닝이 시작될 때 showInAddressBook과 proxyAddresses 특성이 이미 채워져 있도록 설정되었으므로 사용자는 RUS의 작업이 완료될 때까지 기다리지 않고 곧바로 로그인할 수 있습니다. 이 외에도 정기적으로 LDIFDE를 가져오고 RUS gatewayProxy 주소를 정리함으로써 받는 사람 정책이 환경에 실수로 적용되었더라도 조직 내 모든 RUS의 할 일 목록에 들어가지 않도록 하는 수동 작업을 만들어 프런트 엔드 Exchange 2003 프로토콜 서버 중 하나에서 실행되도록 했습니다.

분류기 문제

학생 신상 데이터가 학구 외부로 새어 나가지 않게 하는 것과 맥락을 함께 하는 것이 바로 학생이 소속 학구 외부의 사용자 또는 시스템 외부의 인터넷 주소로 전자 메일을 보낼 수 없도록 제어하는 기능을 구현하는 것입니다. 이를 위해 커넥터 및 관련 항목들로 구성된 정교한 시스템을 만드는 대신 Exchange 2003의 잘 알려지지 않은 기능을 구현하기로 결정했으며 이에 따라 학구의 기존 라우팅 그룹 커넥터에 대한 커넥터 제한을 프런트 엔드 프로토콜 서버가 있는 중앙 허브에 적용했습니다. 각 도메인에 직원용과 학생용으로 각각 하나씩 두 개의 보안 그룹을 만들었으며 이 두 그룹을 커넥터 제한에 추가했습니다.

하지만 레지스트리에 커넥터 제한 검사를 설정한 후 매우 중대한 몇 가지 성능 저하 문제가 발견되기 시작했습니다. 메시지가 분류기와 로컬 배달 큐에 여러 시간 동안 정체되었으며 이는 동일한 서버의 받는 사람에게로 가는 메시지의 경우에도 마찬가지였습니다. 이 문제는 다른 학구가 차츰 마이그레이션됨에 따라 더욱 악화되었습니다. 임시 해결책으로 커넥터 제한 검사 기능을 해제했고 그 결과 메일 배달 성능이 개선되었습니다. 그 후 문제를 좀 더 면밀하게 조사한 결과 메시지가 전송될 때 분류기가 자체 도메인 내의 두 그룹뿐만 아니라 나머지 177개 도메인에 있는 동일한 두 그룹에 대해서도 그룹 구성원 자격을 검사하고 있음이 드러났습니다. 이 작업은 서버로 들어오거나 서버에서 나가는 모든 메시지에 대해 수행되었습니다.

이후 Microsoft에 이 문제에 대한 지원을 요청했습니다. 이 문제에 대한 평가를 마친 후 현재 Microsoft는 토폴로지 복잡도가 감소된 모드에서 분류기를 실행할 수 있도록 하고 있으며 이 문제를 해결하기 위한 핫픽스를 개발 중입니다. 핫픽스에 대한 자세한 내용은 아직 알 수 없지만 핫픽스 개발 목적은 분류기가 라우팅 토폴로지에 대해 특정 상황을 가정하도록 만들어 모든 커넥터에서 그룹 구성원 자격을 검사하지 않도록 하는 설정을 제공하는 것입니다.

교훈

이 프로젝트에서 얻은 교훈이 한 가지 있다면 비즈니스 요구 사항이야말로 컨설턴트가 수행하는 모든 작업을 결정하는 요소라는 것입니다. 컨설팅을 하다 보면 비즈니스 요구 사항의 실현 가능성과 솔루션의 복잡함 중에서 어느 것에 무게를 두어야 할지를 결정해야 할 때가 많습니다. 이 칼럼에서 제가 제안한 결정과 선택은 시간이 부족해서 여기에서는 다루지 못한 여러 가지 요소를 포함하여 주어진 환경, 리소스, 그리고 비즈니스 요구 사항에 가장 적합하다고 판단한 것이었습니다. 물론 독자 여러분은 다른 결정을 내릴 수도 있습니다. 하지만 이 칼럼에서 제가 제시한 아이디어가 도움이 되는 것이기를 바랍니다. 다행히 Exchange 2003과 Active Directory는 이 복잡한 마이그레이션의 모든 요구 사항을 충족하기에 충분할 정도로 융통성이 뛰어났습니다. 켄터키 교육부 배포 프로젝트의 엄청난 규모를 알고 나면 실제 솔루션은 오히려 단순하다고 느낄 것입니다. 또한 솔루션이 Active Directory 및 Exchange 2003의 충분히 활용되고 있지 않은 기능을 기반으로 구축되었다는 사실도 알 수 있을 것입니다.

두 번째 귀중한 교훈은 문제 해결 및 위험/문제 관리에 대해 균형 잡힌 접근 방법을 취해야 한다는 것입니다. 자체적으로 문제를 해결하는 것이 적절할 때도 있고 Microsoft 기술 지원 서비스의 고급 리소스로부터 도움을 요청하는 것이 필요할 때도 있습니다.

향후 예상

켄터키 교육부의 환경은 분명히 고유한 것입니다. 이 솔루션을 배포하는 과정에서 Exchange의 거의 모든 기능이 바로 사용되거나 교육부의 요구 사항에 맞게 수정되었습니다. 이제 전체 환경이 성공적으로 배포되고 마이그레이션되었으므로 추가 기능을 구현할 수 있는 준비가 되었습니다. 켄터키 교육부는 이미 Windows Mobile® 플랫폼에 대한 학구의 관심을 알고 있으며 모바일 장치로의 이동이 계속될 것으로 예상하고 있습니다.

서버 통합을 통해서도 많은 혜택을 얻을 수 있습니다. 현재 켄터키 교육부는 Active Directory 환경의 몇 가지 측면을 가상화하는 문제를 검토하고 있습니다. 또한 Exchange 2007이 곧 출시될 것이라는 전망과 함께 켄터키 교육부는 자체 메시징 시스템의 업그레이드 요구 사항을 검토하기 시작했습니다.

이 외에 켄터키 교육부는 Live Communication Server, Live Meeting Server 등에서 제공하는 공동 작업 기능도 검토하고 있습니다. Microsoft Operations Manager 2005도 현재 Exchange 및 Active Directory 서버에 대한 관리와 모니터링을 위해 배포 중에 있습니다.

결과

제 자녀와 이 프로젝트에서 함께 작업한 동료들의 자녀를 비롯하여 켄터키 주 공립 학교에 재학 중인 모든 어린이들은 구현된 솔루션의 품질과 보급에 따른 영향을 크게 받을 것입니다. 이 솔루션 구현은 켄터키 교육부가 이전보다 안전하고 표준화된 방식으로 선진 기술을 발 빠르게 활용할 수 있는 입지를 마련해 주었습니다. 필자는 개인적으로 이 프로젝트에 참여한 것을 매우 자랑스럽게 생각합니다.

Whitney Roberts는 KiZAN Technologies(www.kizan.com)의 수석 컨설턴트로, Exchange 4.0이 출시된 이후로 Exchange 작업을 담당해 왔습니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..