• 아티클

Exchange Queue & AOWA 제한 시간, Cmdlet 문제 해결 외

KC Lemson and Nino Bilic

Q: 최근에 Exchange Server 2003에서 Exchange Server 2007로 마이그레이션했습니다. 그런데 Outlook® Web Access(OWA) 2007에 로그인할 때 "개인 컴퓨터입니다." 옵션을 선택한 Restricted Users 그룹 사용자로부터 OWA의 제한 시간이 초과된다는 불만이 접수되고 있습니다. 개인 컴퓨터의 제한 시간을 확인하는 데 사용할 수 있는 Exchange 관리 셸 명령은 무엇입니까?

A: 잠시 생각해 보겠습니다. 먼저 개인 컴퓨터와 공개 컴퓨터라는 별도의 두 옵션이 제공되는 이유에 대해 설명한 다음(그림 1 참조) 두 옵션이 어떻게 서로 다르게 작동하는지 알려드리겠습니다. 두 옵션이 제공되는 이유는 OWA에 액세스하는 데 공항의 공용 키오스크를 이용하는지 또는 가정의 컴퓨터를 이용하는지에 관계없이 사용자가 필요한 보안 수준을 Exchange에 지정할 수 있도록 하기 위해서입니다. Exchange 관리자는 이러한 세션 유형을 다르게 취급하도록 선택할 수 있습니다. 예를 들어 공개 컴퓨터에서는 인증된 세션의 제한 시간이 개인 컴퓨터(최대 3일)보다 빨리 단 몇 분만에 초과되도록 설정할 수 있습니다. 관리자는 사용자의 선택에 따라 그 밖의 설정도 다르게 구성할 수 있습니다. 예를 들어 개인 로그온에 대해서만 SharePoint® 문서 라이브러리와 Windows® 파일 공유에 대한 액세스를 허용하도록 설정할 수 있습니다. 물론 이는 사용자가 적절한 옵션을 지정한다는 가정하에서입니다. 사용자가 올바른 결정을 내릴지 확신할 수 없을 때는 관리자가 각 옵션에 대해 제한 시간 값 및 기타 구성 옵션을 동일하게 지정할 수 있습니다.

그림 1 다양한 제한 시간 설정 및 기타 구성 옵션을 허용하는 공개 및 개인 컴퓨터 세션 유형

그림 1** 다양한 제한 시간 설정 및 기타 구성 옵션을 허용하는 공개 및 개인 컴퓨터 세션 유형 **(더 크게 보려면 이미지를 클릭하십시오.)

문제의 옵션은 OWA에 폼 기반 인증이 처음 도입되었을 때 Exchange 2003에서 가져온 것입니다. 잠시 폼 기반 인증의 배경에 대해 부연하자면, 이 인증의 최초 구현은 뛰어난 어떤 프로그램 관리자를 통해 일부 설계되었습니다. 여기서 이 프로그램 관리자가 누구인지는 밝히지 않겠지만, TechNet Magazine에 격월로 칼럼을 기고하면서 부와 명성을 쌓았다는 사실을 알려드리고 싶습니다.

설정은 실제로 레지스트리에 저장되지만, Windows PowerShell™에는 레지스트리를 업데이트할 수 있는 인터페이스가 있으므로 Exchange 관리 셸을 사용하여 이 설정을 구성할 수 있습니다. 다음 예에서는 사용자가 로그온 중 개인 컴퓨터 옵션을 선택하는 경우 제한 시간을 1440분 또는 1일로 설정합니다.

set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout 
-value 1440 -type dword

물론 이 설정은 레지스트리에 저장되므로 원한다면 regedit를 사용하여 키를 직접 업데이트할 수 있습니다.

#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>

어떤 방법을 사용하든 IIS를 다시 시작하여 OWA에 새 설정을 적용해야 합니다. 이렇게 하려면 시작 | 실행을 선택한 다음 iisreset /noforce를 실행합니다.

Q: 전체 MAPI Outlook 클라이언트를 사용하는 회사의 모든 사용자에게 긴급하지 않은 필수 항목을 개인 폴더 파일(.pst)에 보관하도록 권장하고 있습니다. 그런데 사용자가 집에서 Outlook Web Access에 로그인할 경우 보관된 항목을 사용할 수 없는 문제가 발생합니다. OWA 인터페이스를 통해 이러한 .pst 파일을 사용하려면 어떻게 해야 합니까?

A: 안타깝게도 OWA에서는 .pst 파일에 액세스할 수 없습니다. OWA는 원래부터 온라인 전용 클라이언트로 만들어졌습니다. Exchange Server 팀은 컴퓨터에 개인 데이터가 조금이라도 남아 있지 않도록 하기 위해 많은 노력을 기울였습니다. 이러한 노력의 일환으로 Exchange 2003에서는 보안 로그오프 메커니즘이 도입되었으며 Exchange 2007에서는 첨부 파일의 캐시된 복사본이 하드 드라이브에 남지 않도록 WebReady 문서 보기 같은 기능도 제공하고 있습니다. 따라서 OWA에서 .pst 파일에 액세스하는 것은 OWA를 배포하기 쉬운 온라인 전용 클라이언트로 만들려는 목적에 부합되지 않습니다.

일반적인 .pst 사용은 기꺼이 논의해 보고 싶은 흥미로운 시나리오입니다. Exchange Server 팀은 사서함 할당량이 200MB 정도이고 거의 모든 사용자가 최소한 하나 이상의 .pst 파일을 보유하고 있는 고객과 만났습니다. 이 회사에서는 최소한의 노력으로 사용자 컴퓨터를 정리하고 교체할 수 있는 정책을 사용하고 있었으므로 모든 사용자가 자신의 .pst 파일을 네트워크 공유에 저장해야 했습니다. 그리고 네트워크 공유는 중앙 시스템에 백업되었습니다.

우선 네트워크 공유에서 .pst 파일에 액세스할 때 알려진 문제가 발생했습니다. OWA가 처음부터 온라인 전용으로 설계된 것처럼 .pst 파일도 원래부터 로컬에 저장되도록 만들어졌습니다. 네트워크 성능이 아무리 우수하더라도 대기 시간이나 여타 문제가 발생할 수 있으며 이는 동시에 수많은 사용자가 액세스해야 하는 원격 데이터 저장소에 많은 문제를 가져올 수 있습니다.

또한 이 회사는 Exchange에 모든 데이터를 보관할 경우 데이터를 모두 백업해야 하므로 이러한 번거로움을 피하기 위해 좀 작은 크기의 사서함을 사용했습니다. 요즘에는 회사 사서함의 크기가 2GB에 이를 정도로 큰 데도 말입니다. 그런데 사용자가 백업된 네트워크 공유의 .pst 파일에 데이터를 저장하고 있음에도 불구하고 관리자의 작업이 실제로는 줄어들지 않았습니다. 사실 여러 가지 요인으로 인해 작업이 오히려 늘어난 것 같습니다. .pst 파일에 대한 단일 인스턴스 저장소의 부재, 암호를 잊는다거나 일반적인 네트워크 오류와 같은 pst 파일로 인한 문제를 해결하는 데 드는 헬프 데스크 비용, 바이러스 공격 후 .pst 파일의 메시지 정리에 따르는 어려움, 법적 문제가 발생할 경우 .pst 파일의 메시지 검색에 따르는 어려움, 다른 백업 시스템의 유지 관리에 따르는 오버헤드 등으로 인해 작업이 증가되었을 수 있습니다.

따라서 구성을 결정할 때는 먼저 구성과 관련된 모든 비용을 고려해 보아야 합니다. 처음에 결정한 구성으로 인해 비용이 오히려 추가되고 다른 구성이 더 적합하다는 사실을 발견하게 될 수도 있습니다.

Q: Exchange 관리 셀 명령을 사용하는 데 문제가 있습니다. 명령이 작동하지 않습니다. 무엇이 문제일까요?

A: 이 질문에 대해 솔직히 어떻게 대답해야 할지 정확히 모르겠습니다. 이러한 경우에는 Windows PowerShell의 기본 제공 cmdlet인 start-transcript를 사용하여 해당 명령과 그 결과를 기록하는 것이 좋습니다. 이렇게 하면 전자 메일 메시지나 블로그 게시물에 정확한 정보를 붙여 넣거나 포럼에서 질문을 제기할 수 있습니다.

Exchange 관리 셸 세션을 열고 그림 2와 같이 start-transcript를 입력합니다. 그러면 Exchange 관리 셸에서 앞으로 실행되는 모든 명령을 그림 3과 같은 텍스트 파일에 자동으로 기록하기 시작하며 이 텍스트 파일의 위치도 보여 줍니다. 기록을 중지하려면 stop-transcript만 입력하면 됩니다.

그림 2 start-transcript cmdlet으로 사용한 명령과 그 결과 기록

그림 2** start-transcript cmdlet으로 사용한 명령과 그 결과 기록  **(더 크게 보려면 이미지를 클릭하십시오.)

그림 3 Windows PowerShell에서 사용한 명령에 대한 기록을 .txt 파일에 저장

그림 3** Windows PowerShell에서 사용한 명령에 대한 기록을 .txt 파일에 저장 **(더 크게 보려면 이미지를 클릭하십시오.)

사용한 명령의 전체 목록과 명령에 대해 반환된 결과가 있으면 문제를 해결하는 데 상당히 도움이 됩니다. 그러나 알지 못하는 사용자나 신뢰할 수 없는 사용자와 로그를 공유하려면 반환된 데이터에 기밀 정보나 중요한 데이터가 있는지 먼저 확인하는 것이 좋습니다.

Q: Exchange 2007 설치 프로그램에서 루트 도메인에 새 OU(조직 구성 단위)를 만듭니다. 이 OU의 이름은 Microsoft Exchange 보안 그룹이고 이 안에는 다섯 개의 새 Exchange 2007 보안 그룹이 있습니다. 이러한 그룹을 다른 OU로 이동할 수 있습니까? 혹시 다른 도메인으로 이동할 수 있을까요?

A: 이 문제는 Active Directory 준비 단계 중 루트 도메인에 만들어지는 다섯 개의 USG(유니버설 보안 그룹)와 관련이 있습니다. 이러한 그룹은 다음과 같습니다.

  • Exchange Organization Administrators
  • Exchange Recipient Administrators
  • Exchange View-Only Administrators
  • Exchange Servers
  • ExchangeLegacyInterop

Exchange 2000 및 Exchange 2003에서는 Exchange Domain Servers와 Exchange Enterprise Servers 등의 기본 보안 그룹을 이동하는 것이 제한되었습니다. 더 정확히 말하면, 기본 보안 그룹을 이동할 수는 있었지만 이로 인해 무언가가 잘못되었습니다. 이 문제에 대한 자세한 내용은 support.microsoft.com/kb/260914를 참조하십시오. 결론적으로 이전 버전에서는 기본 보안 그룹 이동이 매우 제한되었습니다.

Exchange 2007에서는 상황이 달라졌습니다. 다섯 개의 기본 보안 그룹을 이동할 수 있으며, 동일한 도메인 내의 다른 OU 또는 완전히 다른 도메인으로 그룹을 이동할 수 있습니다.

이 다섯 그룹이 없어졌는데 그룹을 어느 OU나 도메인으로 이동했는지 모를 경우에는 다음 컨테이너에서 otherWellKnownObjects 특성 값을 확인하면 정확한 위치를 알 수 있습니다.

CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com

그룹이 이동되면 이 특성에서 그룹 위치가 업데이트되어 언제든지 그룹이 어디에 있는지 알 수 있습니다. 정말 편리하지 않습니까?

Q: 도메인에 "Exchange Install Domain Servers"라는 글로벌 보안 그룹이 있습니다. 이 그룹의 용도는 무엇입니까?

A: Active Directory®의 내용을 굉장히 자세히 살펴보신 것 같습니다. 사실 Exchange 2007 서버가 설치된 모든 도메인에는 Exchange Install Domain Servers 그룹이 있습니다. 이 그룹은 MESO(Microsoft Exchange System Objects) OU에 만들어집니다. 이 그룹을 면밀히 들여다보면 유니버설 보안 그룹인 루트 도메인의 Exchange Servers 그룹 구성원인 것을 알 수 있습니다.

간단히 말해 Exchange Install Domain Servers는 하위 도메인 중 하나에서 Exchange 2007 설치 프로그램을 실행하는 경우 Active Directory 복제 주기가 길어지는 문제를 해결하기 위해 사용하는 그룹입니다. 예를 들어 Root라는 루트 도메인과 Child라는 자식 도메인, 그리고 Grandchild라는 Child 도메인의 자식 도메인이 있다고 가정해 보겠습니다. 이름을 너무 단순하게 지정했는데, 이런 방식이라면 암호도 쉽게 추측하실 수 있겠습니다.

이 조직에서 Exchange 2007 설치를 시작하려면 먼저 스키마를 확장하고 Root 도메인을 준비해야 합니다. 이렇게 하면 앞의 질문에 대한 설명에서 다룬 다섯 개의 USG가 만들어집니다.

그런 다음에는 Grandchild 도메인에서 설치 프로그램을 실행해야 합니다. 로컬 도메인에서 Exchange 2007 서비스를 시작할 수 있도록 설치 프로그램에서는 Root 도메인의 Exchange Servers 그룹에 Exchange 2007 컴퓨터 계정을 저장합니다. 그러나 Grandchild 도메인에서 설치 프로그램을 실행하고 있기 때문에 Exchange Servers 그룹 구성원이 복제되는 데 시간이 걸릴 수 있습니다.

Exchange Servers는 유니버설 그룹이므로 그룹 구성원이 포리스트 전체에 복제됩니다. 복제 대기 시간이 발생하면 설치 프로그램이 완료되었을 때 서비스 시작 권한이 복제되지 않을 수 있기 때문에 Grandchild 도메인의 설치 프로그램이 서비스를 시작하지 못할 수 있습니다. 바로 이런 이유 때문에 처음으로 도메인에 Exchange 2007 서버를 설치할 때 로컬 도메인에 Exchange Install Domain Servers 그룹이 만들어지는 것입니다.

설치 중 Exchange 컴퓨터 계정이 이 그룹의 구성원으로 저장됩니다. 이 그룹의 구성원은 설치 프로그램이 끝날 때 서비스를 시작하는 데 충분한 권한을 제공하며, 이는 Exchange Servers 그룹의 구성원이 Root 도메인에서 아직 복제되지 않은 경우에도 마찬가지입니다. 로컬 도메인 복제는 일반적으로 도메인 간 복제보다 빠르다는 점을 기억하십시오.

Q: Exchange 2007 설명서에서는 Exchange 2007에 대한 스키마를 확장하기 전에 /PrepareLegacyExchangePermissions 스위치를 사용하여 설치 프로그램을 실행해야 한다고 설명하고 있습니다. 그 이유가 무엇입니까? 그리고 이 스위치의 이름을 조금 짧게 만들 수는 없었습니까?

A: 설치 프로그램을 실행하기 전에 설명서를 읽어 보셨다니 기분이 좋습니다. 설명서의 내용에 만족하셨습니까?

/PrepareLegacyExchangePermissions(또는 /pl)는 Exchange 정보 및 개인 정보 속성 집합에 쓸 수 있는 권한을 Exchange 2000 및 Exchange 2003 RUS(받는 사람 업데이트 서비스)에 제공하는 스위치입니다. Exchange 2007 스키마 확장 프로세스 중 프록시 주소 같은 몇 가지 특성은 Active Directory 공용 정보 속성 집합에서 Exchange 정보 속성 집합으로 이동됩니다. 기본적으로 Exchange 2000 및 Exchange 2003 RUS에는 Exchange 정보 속성 집합에 쓸 수 있는 권한이 없습니다. 실제 환경에서 이것은 Exchange 2007 스키마 확장을 먼저 실행하면 새 받는 사람을 만들 수 없기 때문에 Exchange 2000 및 Exchange 2003 RUS가 제대로 작동하지 않는다는 것을 의미합니다. 이러한 속성 집합에 대한 자세한 내용은 msexchangeteam.com의 블로그를 참조하십시오.

이러한 이유 때문에 Exchange 2007에 대한 스키마를 확장하기 전에 반드시 /pl 스위치를 실행해야 하는 것입니다. 또한 이 변경 내용을 Exchange 2000 또는 Exchange 2003 받는 사람이 있는 모든 도메인에 복제하여 해당 도메인에 RUS가 있도록 해야 합니다. 나중에 새 도메인이 포리스트에 추가되어 이 도메인에 Exchange 2000 또는 Exchange 2003 RUS를 설치해야 해야 할 경우에는 해당 도메인에서 /pl 스위치를 실행하면 됩니다.

또한 /pl 스위치를 처음 실행할 때 엔터프라이즈 관리자 권한이 있는 계정으로 스위치를 실행하면 이후의 작업이 한결 수월해집니다. 이 경우 루트 도메인의 설치 프로그램이 /pl을 실행해야 하는 도메인을 식별하여 해당되는 모든 도메인에서 /pl 스위치를 실행합니다. 엔터프라이즈 관리자 계정을 사용하지 않을 경우에는 각 도메인에 대해 도메인 관리자 계정을 사용하여 /pl 스위치를 실행해야 합니다. Exchange 2007 설명서에서는 모든 권한 요구 사항을 자세히 보여 줍니다.

마지막으로 이 스위치의 이름을 짧게 만들 수는 없었냐고 질문하셨는데 /PrepareLegacyExchangePermissions라고 세 번만 빨리 말해 보십시오.

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

이 스위치의 이름을 /PrepareLegacyExchangePermissionsWOW로 지을까도 생각했었습니다. 정말 길지요. 하지만 좀 더 친숙하고 짧은 /PrepareLegacyExchangePermissions를 선택했습니다.

이렇게 해서 스위치 이름이 만들어진 것입니다. 원한다면 언제든지 훨씬 짧은 /pl을 사용할 수 있습니다. 정말입니다.

KC Lemson은 Exchange Server 팀의 설치 환경 관리자로, 자녀의 대학 학자금을 운용할 투자처 정보가 있는 전자 메일을 읽는 게 취미입니다.

Nino Bilic은 Exchange Server 팀의 기술 팀장으로, 평일 근무 시간에 몰래 Halo 게임을 얼마나 많이 할 수 있는지 생각하느라 분주한 시간을 보내고 있습니다.

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