구병국 / MCT, 마이크로소프트 .NET Advisor Exchange 그룹 운영진

1. 들어가는 말

어느 중소기업의 IT 부서에서 익스체인지 뿐만 아니라 여러 가지 서버를 관리해왔던 관리자가 다음과 같은 넋두리를 해왔다. "항상 내가 알고 있는 지식은 빙산의 일각에 불과하다는 느낌과 내가 정말 올바르게 설치하고 운영하고 있는지 등에 대해서 의문을 품고 있었고 내부적인 구조에 대해서도 정말 궁금한 것이 한두 가지가 아닙니다. 원서 등을 봐도 우리나라보다 기술이 뛰어난 것 같지도 않고 기초적인 것들만 언급되어 있는 형편이라 딱히 전체적인 설정 사항에 대해서 물어볼 컨설턴트도 많지 않고 그렇다고 전문 컨설턴트를 불러서 물어보기에는 비용이 너무 많이 들어갑니다. 회사에서는 메일 서버가 이상 없이 돌아가기 때문에 전문 컨설턴트에게 비싼 비용을 들여가면서까지 할 필요가 뭐 있느냐고 이야기를 합니다.

하지만 제가 이 직장에 있을 때까지 만이라도 익스체인지 서버가 아무런 탈이 없이 돌아가기를 매일 기도합니다. 우리 회사 사장님은 보고서를 너무 좋아해서 현재 서버들의 상태에 대한 보고서를 한달에 두 번 제출하고 직접 보고 해주기를 원하고 있습니다. 마땅하게 최적화 방법에 관한 문서나 정보도 없습니다. 그래서 그냥 이벤트 뷰어를 한번 살펴보고 오류나 경고에 대한 마이크로소프트의 고객 지원 문서를 검색하여서 문제점에 대해서 시정하고 성능모니터에서 몇 가지 카운터를 추가해서 나온 결과로 보고서를 만들어 제출합니다. 이것도 제가 익스체인지 관리를 맡은 지 6개월이나 지나서 이루어진 것입니다. 그 전까지는 소위 삽질을 무척했습니다. 제가 익스체인지만 관리하는 것도 아니고 익스체인지가 자주 문제가 생기는 편도 아니니 이것에 매달려 있을 수도 없고 어떻게 해야할지 막막합니다."

필자가 말하길 "예, 그런 어려운 문제들을 많이 질문 받고 있습니다. 우리나라는 외국과 매우 달라서 특히 이런 메시징의 중요함을 알고는 있지만 회사에 직접적으로 수익을 좌우하지 않기 때문에 다른 응용프로그램만큼 값어치를 인정하고 귀하게 대접하는 회사가 많지 않습니다. 그리고 또한 익스체인지에 익숙해질 만큼의 경력이 되면 그런 관리자들은 시스템 관리 능력이 뛰어나기 때문에 회사를 전직을 하는 경향이 있어서 이후에 들어온 사람이 똑같은 문제점을 고민하게 되지요. 이것을 극복하기 위해서는 서버의 관리 및 구성을 철저하게 문서화시켜야 하는데 임원들은 성능등과 같은 결과 값만 요구하기 때문에 과정에 관한 문서화는 덜되어 있는 편이죠. 그런데다가 사람들의 이동도 있고 제품의 주기도 짧아지기 때문에 이전의 기록들이 거의 필요 없는 상황에 이르는 경우도 허다합니다. 이런 문제점에 대해서 조금이라도 해결하기 위해서 나온 것이 바로 ExBPA입니다. ExBPA에 대해서 자세하기 알고 싶으시면 지금 즉시 http://www.microsoft.com/exchange/exbpa"를 방문해 보세요."

ExBPA(Exchange Best Practice Analyzer)는 해당 익스체인지 조직이 어떻게 구성되어 있는지 그리고 현재 서버의 상태는 어떤지를 면밀하게 관찰할 수 있는 멋진 도구이다. 한글화가 되면 훨씬 우리들 속에 가깝게 와 닿을 만한 도구임에 분명하다. 지난번에는 ExBPA의 내부구조와 설치 방법 그리고 운영방법에 관하여 알아보았다. 이번 달에는 본격적으로 ExBPA를 실행해서 결과는 얻고 분석하는 방법 등에 대해서 살펴보도록 하겠다.

2. ExBPA 실행 옵션

ExBPA의 검사 옵션에는 네트워크 연결성을 검사하는 Connectivity Test, 서버의 상태를 점검하는 Health Check, 기준이 되는 서버와 다른 서버들과 상태를 비교하는 Baseline등 세 가지 종류가 있다. 먼저 ExBPA를 사용할 때 중요한 것이 익스체인지 서버들이 네트워크에서 제대로 연결되어 있는지 상태를 확인하고 그리고 ExBPA를 실행하고 있는 사용자가 권한이 적절하게 있는지 알알 볼수 있는 Connectivity Test를 먼저 실행해야 한다. 그런 다음 Health Check와 Baseline등의 순서대로 검사를 수행하면 된다.

(1) Connectivity Test 결과

Connectivity Test는 네트워크의 연결 상태와 연결할 때 사용하는 사용권한에 대한 테스트를 수행한다. 이것은 하나의 레지스트리 파라미터와 두개의 WMI 클래스에 쿼리를 한다. 첫 번째 WMI 쿼리는 익스체인지에 의해 사용되는 액티브디렉터리의 디렉터리 서버에 하게 된다. 범위 내에서 지정한 모든 익스체인지를 검사한 뒤에 익스체인지가 이용하는 액티브 디렉터리서버에 대한 연결성 및 사용권한이 있는지를 검사하게 된다.

검사 결과는 [표 1]에서와 같은 아이콘으로 나타나게 된다.

아이콘

이름

상태

오류

서버가 현재 다운되었거나 연결할 수 없다는 것을 의미한다. 만일 해당서버의 레지스트리에 액세스할 수 없게 되면 이런 오류를 나타내게 될 수 있다.

경고

레지스트리에 액세스는 성공적으로 했지만 WMI(Windows Management Instrumentation) 질의를 할 수 없을 때 나타난다. 만일 해당 서버에 WMI 서비스가 멈추어 있거나 해당 서버가 WMI 서비스를 지원하지 않는 경우(예를 들면 Windows NT 서버 4.0) 표시된다.

확인

이것은 원격 레지스트리에 성공적으로 연결하고 WMI 질의도 할 수 있는 상태를 표시한다.

아이콘	이름	상태
	오류	서버가 현재 다운되었거나 연결할 수 없다는 것을 의미한다. 만일 해당서버의 레지스트리에 액세스할 수 없게 되면 이런 오류를 나타내게 될 수 있다.
	경고	레지스트리에 액세스는 성공적으로 했지만 WMI(Windows Management Instrumentation) 질의를 할 수 없을 때 나타난다. 만일 해당 서버에 WMI 서비스가 멈추어 있거나 해당 서버가 WMI 서비스를 지원하지 않는 경우(예를 들면 Windows NT 서버 4.0) 표시된다.
	확인	이것은 원격 레지스트리에 성공적으로 연결하고 WMI 질의도 할 수 있는 상태를 표시한다.

[표 1] Connectivity Test의 결과 아이콘의 종류

[그림 1]과 [그림 2]는 이런 연결성검사를 거친 경우의 예시를 나타낸 것이다.

[그림 1] 익스체인지 5.5와 익스체인지 2003이 함께 있는 경우 Connectivity Test결과

익스체인지 5.5 서버가 조직내에 존재하는 경우에는 Windows NT 서버 4.0이 WMI를 지원하지 않기 때문에 [그림 1]과 같이 경고가 나타나게 된다. [View a report of this Best Practices scan]을 선택하여 보고서를 살펴보게 되면 경고에 대한 자세한 메시지가 나타나지 않더라도 당황하지 말기를 바란다.

[그림 2] 익스체인지 서버 2003으로 이루어진 서버들에 Connectivity Test 결과

[그림 2]는 익스체인지 2000서버나 익스체인지 2003서버로 이루어져 있고 서버들이 네트워크 상에서 제대로 연결되어 있을 경우 이렇게 초록색의 확인 아이콘으로 나타나게 된다. Connectivity Test의 경우 거의 대부분 이런 확인 아이콘이 나타난다. 그럼 [View a report of this Best Practices scan]를 눌러 [그림 3]과 같이 ExBPA에서 검사한 결과 값을 보고서로 본다.

[그림 3] View Best Practice Report 페이지

이 페이지에서는 Connectivity 결과 다양한 형태의 보고서를 다음과 같은 유형별로 볼 수 있다.

• Full Issues List: 여기에는 위에서 말한 Critical Issues, 경고 그리고 밑에 있는 Non-Default Setting 그리고 Recently Change Setting에 나타난 문제점들을 모두 취합해서 보여주는 곳이다. 만일 이런 연결성에 문제점이 없다면 Full Issues List에 아무것도 나타나지 않게 된다.
• Non- Default Settings: 기본적으로 설정된 사항이 아니라 관리자의 필요에 의해서 연결성에서 바꾼 사항들을 나타낸다.
• Recently Changed Settings: 연결 설정에 있어 가장 최근에 변경한 사항들을 표시해준다. Non-Default Settings와 함께 관리자의 변경사항을 추적하는데 요긴하게 사용할 수 있다.
• Baseline Report: Connectivity에서 기준점이 되는 속도와 연결 상태를 유지하고 있지 않다고 하면 기준점이 되는 연결 상태에 대한 설정사항을 보고서로 나타낸다.
• Items Of Interest:
  
  
  [그림 4] Items Of Interest 항목

  여기에는 크게 두 가지 종류의 정보들이 나타난다. 즉 액티브디렉터리에 관한 정보와 익스체인지 서버에 관한 정보인데 이것들은 모두다 액티브디렉터리에 저장되어 있는 정보를 가지고 온다. [그림 4]에서 보면 먼저 나타나는 것은 액티브디렉터리 사이트들의 종류를 나타내고 다음으로 디렉터리에 있는 관리 그룹(익스체인지 5.5의 경우 Site)들의 목록들을 보여주게 된다. 다음으로 액티브디렉터리 서버들 즉 도메인 컨트롤러들을 나타낸다. [Active Directory Sever -서버이름-]은 해당 도메인 컨트롤러의 운영체제 버전들을 나타낸다. 그 이후에 나타나는 것은 서버들의 목록들이 나타난다. 이것은 서버 당 크게 두개씩 나타나는 것으로 하나는 해당 서버의 운영체제가 나타나고 디렉터리에서 익스체인지 서버를 찾았다는 것을 나타낸다.

• Summary View: Summary View에는 관리그룹과 AD서버들을 표시한다. 관리 그룹내 해당 서버들의 목록과 서버들의 운영체제 버전들을 나타낸다. 또한 익스체인지가 작동하는 사이트목록들이 있고 AD Server는 도메인 컨트롤러의 목록들을 나타낸다. 이 목록은 Item of Interest의 목록들을 관리그룹과 도메인컨트롤러로 표시한 것이다.
• Detailed View: [그림 5]는 액티브디렉터리 내 저장된 익스체인지 조직에 대한 전체적인 정보를 제공해준다. 여기에는 각 익스체인지 개체의 DN(Distinguished Name)와 익스체인지 서버의 개체 ID 및 네트워크 주소와 익스체인지의 실제 버전을 자세하게 알려준다. 또한 AD Sites Connectivity에서는 각 사이트 및 도메인 컨트롤러 그리고 그 역할 및 버전에 이르기까지 다양한 정보를 표시한다.
  
  
  [그림 5] Detailed View내용
• Disabled Item List: WMI서비스나 레지스트리 서비스등 사용하지 않은 상태로 존재하는 항목들을 나타낸다.
• Run Time Log: ExBPA로 검색을 하는 과정에서 발생하는 이벤트들을 기록해 놓은 것이 Run Time Log이다. [그림 6]은 익스체인지 5.5와 함께 사용하고 있는 조직에서 ExBPA을 실행했을 경우 나타나는 것을 Windows NT 서버 4.0에는 기본적으로 WMI를 지원하지 않으므로 몇 가지 오류가 발생한 것을 알 수 있다.
  
  
  [그림 6] Run Time Log 보기

(2) Health Check 결과

Health Check는 ExBPA의 핵심이다. 익스체인지 조직 내에 있는 모든 서버들의 현재 상태와 문제점들을 검사해준다. 그러므로 Health Check를 얼마나 잘 활용하느냐에 따라서 ExBPA의 효용가치가 달려있다고 해도 과언이 아니다. 또한 [그림 7]과 같이 [View Best Practices Report]에서는 Connectivity Test와 마찬가지로 보고서의 종류들이 나타난다.

[그림 7] Health Check Test중의 보고서 종류

그림에서는 Critical Issues List에 오류가 하나 발생했는데 그 오류의 제목은 Virtual PC detected로 나와 있다. 이것을 더블클릭하면 [그림 8]와 같이 해당 서버가 Virtual PC 상에 있다는 것과 이것은 지원이 되지 않은 구성상황이라는 것을 이야기 해준다.

[그림 8] 오류 자세히 보기

그 밑에 나와 있는 하이퍼 링크들은 해당 문제점을 어떻게 처리할지에 대해서 관리자가 선택할 수 있는 내용으로 이것은 공통 사항 부분에서 자세하게 다루기로 하겠다.

선택할 수 있는 보고서의 종류에는 Connectivity Test와 같은 것들이 있는데 그중에서도 중요한 것과 Connectivity Test와 다른 것을 나타내는 몇 가지를 살펴보면 다음과 같다.

• Full Issues List: 여기서는 Critical Issue에서 나타난 오류와 잠재적인 문제점을 나타내는 경고 등이 나열되어 있다. 보면 전체 익스체인지 조직에서 나타나는 문제점들이 먼저 언급(예를 들면 Active Directory Connector등)되어 있고 그 다음 각 서버별로 문제점에 대한 목록들이 나타나 있다. 그리고 해당 목록 중의 특정 아이템을 선택하게 되면 해당 문제점에 대한 자세한 내용과 앞으로의 대처방법을 확인할 수 있는 링크들이 옵션으로 나타난다.
  

  [그림 9] Full Issues List 목록

• Items Of Interest: 이것은 말 그대로 흥미를 가지고 봐야할 항목들을 나열해 놓고 있다. 필자를 비롯하여 많은 관리자나 컨설턴트사 실제 사이트에서 서버의 현재 상태에 대한 보고서를 제출해달라고 요청받는 경우들이 많다. 과연 어떤 목록들이 클라이언트들에게 필요할 것인지 선택하는 것과 그것의 현재 상태를 정리하는 것이 결코 만만한 작업이 아니다. 하지만 이제는 Items of Interest가 있으면 쉽게 해결할 수 있다. [그림 10]과 같이 이것은 전체 익스체인지 조직이 가지고 있는 각 개체 또는 항목들의 개수와 현재 상태들에 대해서 자세하게 이야기 해주고 있다. 또한 조직 전체와 각 서버별로 따로 나타내었기 때문에 필요한 부분을 쉽게 찾을 수 있도록 해준다.
  

  [그림 10] Items of Interest

• Summary View: Summary View는 현재 익스체인지 조직에 대한 진단 결과를 요약 정리해서 표시해준다. 여기에는 크게 Summary, ADC Server(익스체인지 5.5와 함께 사용하고 있을 경우), Domain, Exchange Organization, Domain Controller등으로 나누어져서 나타난다.
  

  [그림 11] Summary View

  그리고 문제점이 있는 곳에서는 오류나 경고로 표시되어 관리자가 한눈에 현재 어디서 문제점이 발생했는지를 파악할 수 있도록 해준다. 트리 구조를 하부로 내려가게 되면 오류나 경고를 발생시킨 원인되는 항목을 찾을 수 있고 트리구조의 상부에 나타나는 아이콘은 문제가 있을 경우[그림 1]과 같이 오류아이콘>경고 아이콘>확인 아이콘의 순서로 표시된다. 즉 만일 해당 트리에 오류가 하나라도 있으면 트리의 구조전체에서 오류 아이콘으로 표시되게 된다.

• Detailed View: 이것은 Summary View보다 좀더 자세한 정보를 나타낸다. 즉 ExBPA의 결과 익스체인지 조직과 Active Directory에 대한 철저한 분석들을 제공해 주며 좀더 Active Directory내 익스체인지 관련 정보에 대한 깊은 관찰을 필요로 하는 관리자나 컨설턴트에 알맞다. 이것은 Summary View에서와 마찬가지로 각 아이콘별로 트리의 앞에 나타내어주므로 문제점이 있는 곳을 쉽게 파악할 수 있다.
  

  [그림 12] Detailed View

• Rum Time Log: ExBPA의 Health Check Test의 과정에 대한 로그를 남겨서 실행과정 자체에 문제가 발생했는지 여부를 파악할 수 있도록 해준다.

(3) Baseline결과

Baseline 테스트는 현재 조직 내 서버가 여러 대가 있으며 특별히 기준이 되며 정상적으로 작동하며 오류가 없는 서버가 한대가 있고 그 외 다른 서버들이 있다고 하면 기준이 되는 서버와 다른 익스체인지 서버들을 서로 비교해서 설정 상에 문제점들을 파악할 수 있도록 해주는 기능이다. 만일 다국적기업에서 서버가 각 나라나 지역별로 흩어져 있거나 ISP업체나 대기업 등 익스체인지 서버가 여러 대 존재하는 곳에서 한꺼번에 많은 서버들의 상태를 비교할 때 Baseline을 이용할 수 있다. Baseline을 이용하기 위해서는 먼저 [Start a New 익스체인지 Scan]페이지의 [Select the type of scan to perform]에서 [Baseline]을 선택한다. 그러면 밑에 있는 [Baseline Options]가 활성화되고 이것을 선택하면 [그림 13]와 같이 비교 기준이 되는 Control Server와 비교대상이 되는 서버를 선택할 수 있는 선택난이 나온다.

[그림 13] Baseline Options 선택서버

Control Server 서버에서는 서버를 하나 또는 그 이상의 기준이 되는 서버를 선택할 수 있다. Control 서버에서 선택하게 되면 그 나머지 익스체인지 서버들은 비교대상이 되는 서버가 된다. 사용할 때는 비슷한 기능을 하는 서버들(예를 들면 사서함 서버, 브리지 헤드 서버 등)끼리 설정을 비교해야 한다. 전체 서버에 대하여 일관성을 유치하는 것은 서버의 복잡성과 문제해결 시간을 줄여준다. Baseline을 사용하여 비교를 할 때 익스체인지 서버들의 각기 다른 버전끼리도 비교할 수 있으나 그것은 기준이 되는 서버와 비교하는 것은 큰 의미를 가지지 못한다. Baseline을 이용하는 것은 Connectivity Test와 Health Check를 거친 후에 실행하는 것이 좋다.

비교를 하게 되면 [그림 14]와 같이 기준이 되는 서버(Control Server)에 대한 정보는 적은 반면 대상이 되는 서버의 정보는 다양하게 제공이 된다.

[그림 14] Baseline 테스트의 결과 Summary View

3. 공통사항

(1)오류 및 경고 해결방법

오류나 경고가 나타나고 그것을 더블클릭하게 되면 [그림 7]과 같이 처리 방법에 대해서 선택할 수 있는 링크가 나타나는데 옵션은 다음과 같다.

• Tell me more about this issue and how to resolve it: 이것을 더블클릭하게 되면 [그림 15]과 같이 ExBPA의 Help파일 속에 있는 해당 문제에 대한 내용이 나타난다. 그리고 여기서 해당 문제점을 해결할 수 있는 방안이 나타난다.
  

  [그림 15] ExBPA의 문제 진단 및 해결방법

  이것은 ExBPA의 핵심이라고 할 수 있다. 즉 문제점을 진단하는데 그치는 이벤트 뷰어나 성능 모니터의 기능에다 마이크로소프트의 고객 지원 사이트(http://support.microsoft.com)내에 있는 KB(Knowledge Base)를 합쳐 놓은 형태이다. 하지만 더 중요한 것이 바로 여기서는 해당 문제점 진단과 해결방법이 연결되어 있다는데 큰 의미를 부여할 수 있다. 해당 서버의 이벤트 뷰어나 성능 모니터를 통해서 수동적으로 얻은 결론들의 해결책을 찾기 위해서 KB를 뒤적여야 했던 부분을 일시에 해결해 놓았다. 그러므로 ExBPA를 사용하는 관리자라고 하면 오류나 경고 부분에 대해서 이것을 클릭하여 좀더 자세하게 문제점의 원인을 이해하고 이것을 해결할 수 있는 방법을 습득하여 해당서버에 적용하는 것이 중요하다. 말그대로 자신이 컨설턴트의 역할을 수행하는 것이다.

• Do not show me this item again for this instance only: 이것은 해당항목에 대해서 앞으로 다시는 표시하지 않는다는 것을 의미한다. 예를들면 [그림 7]과 같이 Virtual PC에 관한 오류들은 테스트 환경을 위해서 만들어져 있기 때문에 바꿀 수가 없다. 그러므로 계속적으로 오류가 나타난다고 하면 관리자로써는 상당히 귀찮은 부분일 것이다. 이때 이 옵션을 선택해서 해당 인스턴스에서만 다시는 나타나지 않도록 하는 것이다.
• Do not show me this item again for all instances: 이것은 해당 항목에 대해서는 전체 인스턴스에서 나타내지 않도록 하겠다는 것이다. 이것을 선택하게 되면 다른 보고서에서도 해당 항목이 나타나지 않을 수 있다. 그리고 오류나 경고와 같은 것이 중요한 부분이기 때문에 가능하면 이 옵션을 선택하지 않는 것이 좋다.

(2) 보고서 처리 옵션

• ExBPA의 수행결과 나타나는 보고서에서 원하는 부분을 검색하거나 해당 정보를 다른 곳으로 옮기나 전체내용을 인쇄해서 볼 수 있다. 이렇게 함으로 검색 결과를 재가공하여 사용하며 커스터마이징을 통해서 관리자가 필요한 정보만 추출할 수도 있다. 이런 보고서를 처리하는 데는 다음과 같은 옵션들이 존재한다.
  

  [그림 16] Find 페이지

• Export Report: Export Report는 해당 보고서를 XML형태로 저장하도록 해준다. 이것으로 이후 필요할 때마다 해당파일에서 필요한 정보만 추출하여 재가공이 가능하다. ExBPA를 실행하게 되면 항상 Output.검사이름 검사일시 .xml파일과 로그파일이 자동으로 만들어진다. 그러므로 나중에 언제든지 재활용이 가능하다. 그리고 자세히 보면 UIErrors.txt라는 파일이 존재함을 알 수 있는데 이것은 ExBPA실행 시 발생하는 오류에 대한 내용을 기록해서 마이크로소프트에 제출할 때 사용하는 것이다. 이 파일에는 발생하는 오류와 디버깅 정보들이 저장되어 있다.
• Print Report: 이것은 보고서를 외부로 인쇄할 때 사용한다.

4. 단일 서버에서의 Health Check 결과분석 및 해결방법 예시

우리나라의 중소기업에서는 단일 서버에 Active Directory를 설치하고 익스체인지 서버를 함께 설치해서 운영하는 경우가 많다. 이런 경우 ExBPA를 실행하여 얻을 수 있는 결과를 예측해보고 해결방법에 대해서 살펴보도록 하겠다.

[그림 17]는 단일서버에서 ExBPA를 Health Check로 실행해서 얻게 되는 결과를 나타낸 것이다.

[그림 17] 단일 서버에서 ExBPA 실행결과

[그림 17]는 Virtual PC에서 한 작업이므로 첫 번째 나타난 Virtual PC는 실제 서버에서는 나타나지 않고 나머지 6개가 ExBPA결과 나타날 것이다(물론 서버의 상태와 업데이트 그리고 이전에 관리자가 수행한 작업에 따라 내용이 달라질 수 있다). 각각의 내용을 살펴보면 다음과 같다.

• MaxDSNSize not set: 이것은 먼저 MAXDSNSize라는 항목에 대해서 알아야 한다. 익스체인지에서 메시지가 외부 서버로 전달하기 위해서는 큐에 대기하였다가 원격지 서버와 연결음 맺고 나서 메시지의 전송이 일어난다. 만일 원격지 SMTP서버가 응답하지 않아서 대기하는 상태가 되거나 메시지를 보낼 수 없는 상황이 되면 서버는 보낸 사람에게 DSN(Delivery State Notification)메시지를 보내게 된다. 대기 중에서는 메시지가 대기상태에 있다는 것을 알려주고 메시지를 보낼 수 없는 상황이 되면 NDR(Non Delivery Report)를 보내주게 된다. 이때 보내지는 DSN의 첨부물로써 원본 메시지를 추가해서 보내게 되는데 이 메시지의 크기가 일정크기가 넘어가면 첨부물을 없애도록 하여 사서함에 부담을 줄여주도록 하는 방법이다. 이것은 HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing\MaxDSNSize에서 해당 DSN메시지의 크기를 정할 수 있다. 익스체인지 2000 SP2부터 MaxDSNSize가 적용되기 시작했으므로 서버들은 SP2를 설치한 후에 사용할 수 있다. 그리고 익스체인지 2003의 경우 SP1을 설치하였다면 레지스트리에는 나타나지 않지만 기본적으로 10MB의 크기로 제한되어 있다는 것을 명심하라. 10MB에서 변경하기 원할 때만 레지스트리에서 추가하면 된다.
• Exchange resident on domain controller: 이것은 단일 시스템에서 항상 나타나는 경고인데 익스체인지 시스템과 도메인 컨트롤러는 성능상의 문제 때문에 같은 서버에 설치하는 것을 권장하지 않고 있다. 그러므로 단일 서버라는 가정 하에서는 이것은 항상 나타나는 오류이므로 특별한 추가 설정이 필요없다. 이 경고가 다시 나타나는 것을 막기 위해서는 앞에 설명한 바와 같이 Do not show me this item again for this instance only를 선택하면 다시는 나타나지 않는다.
• SMTP performance warning: 이것은 SMTP 큐가 시스템 파티션과 같은 파티션에 설치되어 있으면 성능상의 문제가 발생할 수 있다고 해서 나타나는 경고이다. 즉 SMTP 큐는 일반적으로 익스체인지가 설치되는 C:\Program Files\exchsrvr\mailroot\vsi 1에 저장되게 된다. 익스체인지 2003의 경우 ESM을 이용하여 쉽게 옮길 수 있고 익스체인지 2000의 경우 ADSI edit를 이용해서 옮길 수 있다. 성능을 위해서 다른 파티션으로 옮기도록 하는 것이 권장사항이므로 디스크의 여유상황에 따라 옮길지 여부를 결정하면 된다.
• System cache optimization: ExBPA는 레지스트리 내에 있는 HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache 항목을 검색해서 그 값을 알아본다. 익스체인지 Server나 SQL서버가 설치된 서버의 경우 해당 응용프로그램 설치과정에서 LargeSystemCache의 값을 0으로 만들어서 응용프로그램이 메모리의 사용을 최대로 만들게 된다. ExBPA는 Active Directory내에 있는 여러 가지 개체들에 질의를 해서 사서함의 개수를 파악하고 위의 레지스트리 정보에 또한 질의를 하여 그 값을 알아낸 뒤에 만일 사서함의 개수가 20개 이하이면서 LargeSystemCache값을 0으로 두고 있다면 응용프로그램이 필요 없이 캐시메모리를 많이 소유할 필요가 없다고 판단하여 Crash upload logging disabled 라는 경고를 내보내고 해당 익스체인지 응용프로그램을 위해 최적화된 메모리를 파일 공유를 위해 할당하도록 바꾸도록 추천한다. 이때 레지스트리에서 0대신 1으로 그 값을 변경할 수 있고 네트워크 환경의 속성정보에서 [마이크로소프트 네트워크용 파일 및 프린트 공유]→[속성]→[서버 최적화]→[파일 공유를 위해 데이터량 최대화]를 선택해도 된다. 이것은 사서함이 20개 이상인 서버에서는 나타나지 않는 오류이다.
• Crash upload logging disabled: 이것은 시스템에 중대한 문제가 발생했을 경우 마이크로소프트로 보고를 하도록 Exchange System Manager의 서버 개체 특성 정보에 설정할 수 있다. 기본적으로 보고를 하지 않도록 되어 있으며 마이크로소프트에서 익스체인지의 문제점을 파악하는데 도움을 주고 향후 핫픽스나 서비스팩등 업데이트될 시에 문제점이 해결될 수 있을 가능성이 있으므로 필요에 따라 선택할 수 있다.

5. 맺는말

ExBPA는 익스체인지를 구축한 조직에서 현재의 상황을 분석하고 문제점을 발견하고 최적화하기 위한 도구이다. ExBPA를 통해서 분석할 수 있는 것은 네트워크 연결성을 검사하는 Connectivity Test, 서버의 상태를 점검하는 Health Check, 기준이 되는 서버와 다른 서버들과 상태를 비교하는 Baseline등 세 가지 종류가 있다. 자신이 필요로 하는 요구 조건에 따라 선택해서 사용하면 되지만 일반적으로 Connectivity Test→Health Check→Baseline의 순서로 서버를 점검하는 것이 좋다. 이것은 단일 서버일때도 유용하지만 서버가 여러 개가 있다면 간단한 조작으로 엄청난 정보를 제공해준다. 그냥 단순하게 정보만 제공해주는 것이 아니라 상세한 원인 및 해결책까지 그리고 관련된 KB의 위치까지 링크로 알려주니 관리자에게는 더없이 반가운 도구이다. 그리고 무엇보다 중요한 것은 ExBPA가 만능 도구가 아니라는 사실을 기억하기 바란다. 이 것은 현재의 서버의 구축 상태와 문제점에 대해서 모든 것을 제공해주지는 못한다. 단지 일부분만을 제공해주고 있다. 그러므로 지속적으로 이벤트 뷰어와 성능 모니터 그리고 큐를 검사해야 한다. 편식을 하게 되면 결국 우리의 건강을 해치게 되는 것과 같다.

2005년 상반기에 V2가 나올 예정이다. Microsoft Operations Manager를 위한 Management Pack도 제공될 예정이다. 이때 한글화가 추진되어 쉽게 한글로 된 ExBPA를 접할 수 있으면 더 많은 관리자가 추가적인 비용 지출 없이 익스체인지 서버의 문제점을 진단하고 사장님에게 좋은 보고서를 제출할 수 있을 것이다. 물론 이런 도구가 있는지는 사장님에게는 비밀로 하는 것이 자신의 능력을 좀더 돋보이게 하는 효과가 있다고 믿는다.