exchange_ko

Edge 전송 서버에서 나타나는 기이한 메일 루프: 크기 제한을 확인하십시오!

OfficeLocalization — Thu, 09 May 2013 06:28:38 GMT

최초 문서 게시일: 2013년 3월 29일 금요일

저는 CSS의 지원 엔지니어입니다. 한 고객이 특정 도메인(예: contoso.com)에 대한 메일 루프 오류를 보고했습니다. 이 오류는 대용량 전자 메일에서만 나타났습니다. 왜 이런 현상이 나타나는지 이해하기 힘들었는데 결국 송신 커넥터에 대한 크기 제한 때문에 그렇다는 것을 알아냈습니다. 이 오류는 다소 기이한 만큼 공유하는 것이 좋을 것 같았습니다.

구성 및 문제의 근본 원인 파악:

저는 처음에 Edge 서버가 외부 DNS 서버(외부 호스트를 확인하는 DNS 서버)를 사용하도록 구성되어 있기 때문에 이 오류가 나타났을 수 있다고 생각했습니다. 대개 Edge 전송 서버가 외부 DNS 서버를 사용하도록 구성되어 있으면 Active Directory 사이트의 허브 전송 서버 대신 공용 IP 주소(대개 자체, 외부 방화벽 또는 서비스 공급업체를 가리킴)로 도메인 이름을 확인하므로 메일 루프가 발생합니다.

문제를 재현하면서 Edge 전송 서버가 외부 DNS 서버를 사용하도록 구성되지 않은 것을 발견했습니다. 문제를 재현하기 위해 설정한 환경은 아래 다이어그램과 같았습니다.

이 시나리오에서 발생하는 것은 다음과 같습니다. Edge 전송 서버가 인터넷 발신자로부터 20MB의 전자 메일을 받고 이를 수락합니다. Edge 전송 서버는 이 주소 공간과 일치하는 커넥터 두 개를 갖습니다. Active Directory 사이트에 대한 주소 공간 contoso.com과 일치하는 커넥터 하나와 주소 공간 *와 일치하는 커넥터 하나가 있습니다. 사용 가능한 모든 커넥터를 기반으로 라우팅 결정을 내릴 때 Edge에서 허브로의 커넥터는 크기 제한(10MB 크기 제한)으로 인해 고려되지 않습니다. 최적의 일치는 메시지 크기 제한이 30MB인 Edge에서 인터넷으로의 * 커넥터(메시지 라우팅 이해에 나온 커넥터 선택 알고리즘 검토)입니다.

최종 결과: 메시지가 인터넷으로 다시 라우팅되어 인터넷과 Edge 서버 간에 메시지 루프가 발생합니다.

인터넷에 대한 송신 커넥터가 아웃바운드 메일을 배달하는 데 DNS와 스마트 호스트 중 어느 것을 사용하도록 구성되어 있는지에 따라 다음 NDR 중 하나를 받게 됩니다.

DNS를 사용하는 경우:

#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##

스마트 호스트를 사용하는 경우:

5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop> #SMTP#

해결 방법

이 동작은 설계상 나타나는 동작이며 커넥터에 대한 메시지 크기 제한을 수정하여 손쉽게 해결할 수 있습니다. 요구 사항에 따라 다음 옵션 중 하나를 선택할 수 있습니다.

수신 커넥터(인터넷에서 인바운드 메일을 받음)에 대한 MaxMessageSize 매개 변수를 10MB로 설정하여 인터넷에서 송신되는 메시지가 10MB로 제한되도록 합니다.
Edge에서 허브로의 송신 커넥터에 대한 MaxMessageSize를 30MB로 설정하여 외부 발신자에게서 30MB의 메시지를 받을 수 있도록 합니다.

기이한 문제가 해결되었습니다! 이 문제를 블로그에 올릴 수 있도록 도움을 주신 Arindam Thokder와 Scott Landry 씨에게 감사 드립니다!

Suresh Kumar(XCON)

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Mysterious mail loop on Edge Transport server: Check your size limits!를 참조하십시오.

Microsoft Connectivity Analyzer(MCA) 1.0 및 Microsoft Remote Connectivity Analyzer(RCA) 2.1 발표

OfficeLocalization — Thu, 09 May 2013 06:28:37 GMT

최초 문서 게시일: 2013년 3월 12일 화요일

Microsoft에서는 2012년 11월에 MCA Beta 클라이언트를 발표했습니다. 그 이후로 MCA 클라이언트에서 사용할 수 있는 테스트 옵션을 개선하고자 많은 노력을 기울였으며, 이제 1.0 릴리스를 내놓게 되었습니다.

Microsoft Connectivity Analyzer Tool 1.0

저희는 Microsoft Connectivity Analyzer의 1.0 릴리스를 발표하게 되어 기쁩니다. Microsoft Remote Connectivity Analyzer 웹 사이트를 보조하는 MCA 도구를 사용하면 관리자와 최종 사용자가 5가지 일반적인 연결 문제 증상에 대한 연결 진단을 로컬 컴퓨터에서 직접 실행할 수 있습니다. 사용자가 각자의 연결을 테스트하고 결과를 HTML 형식으로 저장하면 관리자가 RCA 웹 사이트에서 이 결과를 확인할 수 있습니다.

MCA 1.0 도구를 설치할 수 있는 사이트: https://testconnectivity.microsoft.com/?tabid=client

소개 비디오 보기:

MCA 도구는 다음과 같은 5가지 테스트 증상에 대한 진단을 제공합니다.

"Office Outlook에 로그온할 수 없음(I can’t log on with Office Outlook)" – 이 테스트는 "외부에서 Outlook 사용(RPC over HTTP)"에 대한 Exchange RCA 테스트와 동일합니다. 매개 변수 페이지에 SSO 테스트를 실행하는 옵션이 제공됩니다.
"모바일 장치에서 전자 메일을 보내거나 받을 수 없음(I can’t send or receive email on my mobile device)" – 이 테스트는 Exchange ActiveSync에 대한 Exchange RCA 테스트와 동일합니다.
***새로운 MCA 테스트*** "모바일 장치에서 Lync 또는 Lync Windows 스토어 앱에 로그온할 수 없음(I can’t log on to Lync on my mobile device or the Lync Windows Store App)" – 이 테스트는 온-프레미스 도메인에 대한 DNS(도메인 이름 서버) 기록을 검토하여 Mobile Lync 클라이언트를 지원하도록 올바르게 구성되어 있는지 확인합니다. 또한 자동 검색 웹 서비스에 연결하여 이동성을 위한 인증, 인증서 및 웹 서비스가 올바르게 설정되어 있는지 확인합니다.
***새로운 MCA 테스트*** "Outlook에서 전자 메일을 보내거나 받을 수 없음(I can’t send or receive email from Outlook)(Office 365에만 해당)" – 이 테스트는 인바운드/아웃바운드 SMTP 메일 흐름을 확인하며 O365 고객에 대한 도메인 이름 서버 유효성 검사 확인을 포함합니다.
***새로운 MCA 테스트*** "다른 사용자에 대한 약속 있음/없음 정보를 볼 수 없음(I can’t view free/busy information of another user)" – 이 테스트는 Office 365 사서함과 온-프레미스 사서함에서 각각 서로의 약속 있음/없음 정보에 액세스할 수 있는지 확인합니다(테스트 실행마다 한 방향 확인).

Microsoft Lync Connectivity Analyzer Tool: 또한 클라이언트 페이지에는 Lync Connectivity Analyzer Tool이 있습니다. 조만간 MCA와 MLCA를 결합하기 위해 작업 중이지만 현재는 클라이언트 진단 옵션을 개선하기 위해 고객이 이 두 가지 유용한 도구를 모두 사용할 수 있도록 했습니다. MLCA에 대한 자세한 내용은 여기를 참조하십시오.

피드백: 피드백이 있으면 모두 MCA 피드백 별칭으로 보내 주십시오. 이 도구에 대해 어떻게 생각하시는지, 이것이 연결 문제를 해결하는 데 도움이 될 것 같은지 알려 주시기 바랍니다. 또한 향후에 추가되었으면 하는 테스트가 있으면 알려 주십시오.

Microsoft Remote Connectivity Analyzer 2.1

Microsoft Remote Connectivity Analyzer 웹 사이트의 2.1 릴리스가 나왔습니다. 이 도구를 사용하면 관리자와 최종 사용자가 Microsoft 서버에 대한 연결 진단을 실행하여 Exchange, Lync, Office 365에 대한 일반적인 문제를 테스트할 수 있습니다. 새로운 Office 365 도메인 이름 서버 테스트를 추가하고, 기존 테스트를 개선하는 한편, 전반적인 사이트 환경을 향상시켰습니다.

여기서 웹 사이트에 대한 업데이트 사항을 확인하십시오. https://testconnectivity.microsoft.com

2.1 RCA 릴리스의 주요 새로운 기능 및 향상된 기능:

버전 2.1(2013년 3월)

60개 언어에 대한 지역화된 언어 지원 추가
로컬 컴퓨터에서 연결 문제를 해결하기 위한 다운로드 가능한 Microsoft Connectivity Analyzer v1.0 도구의 업데이트된 버전
로컬 컴퓨터에서 Lync 문제를 해결하기 위한 다운로드 가능한 Microsoft Lync Connectivity Analyzer 도구 추가
Office 365 일반 테스트 섹션 추가
Office 365 Exchange DNS(도메인 이름 서버) 연결 테스트 추가

개선된 기능을 유용하게 사용하시기 바랍니다.

감사합니다.

Brian Feck 전체 MCA/RCA 팀 대표
Twitter에서 팀 팔로우 - @ExRCA

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Announcing Microsoft Connectivity Analyzer (MCA) 1.0 and Microsoft Remote Connectivity Analyzer (RCA) 2.1을 참조하십시오.

Exchange Server 2013에 대한 호스팅 및 다중 테넌트 지원 지침 제공

OfficeLocalization — Thu, 09 May 2013 06:28:35 GMT

최초 문서 게시일: 2013년 2월 21일 목요일

자주 요청된 Exchange Server 2013에 대한 호스팅 및 다중 테넌트 지원 지침 문서가 나왔으며, 여기에서 다운로드하여 사용할 수 있습니다.

예리한 독자라면 곧 알아채시겠지만 이 지침은 Exchange Server 2010에 대한 지침과 상당히 비슷합니다. 그 이유는 단지 이전 지침을 찾아 복사하여 붙여 넣었기 때문이 아니라 Exchange 2010에 대해 Microsoft에서 정한 전략이 Exchange 2013에도 해당되기 때문입니다. 즉, 기본 제공 도구, cmdlet 및 인터페이스만 사용하여 솔루션을 구성해야 하며, 어떤 경우에도 원하는 구성을 달성하기 위해 AD의 개체를 직접 조작해서는 안 된다는 것입니다.

또한 일부 기능은 다중 테넌트 지원 같은 구성에서 원하는 대로 작동하지 않을 수 있다는 것입니다. 예를 들어 메일 설명은 표준 온-프레미스 유형 배포에서 동일하게 작동하며, 그에 따라 테넌트 간에 원하지 않는 데이터가 유출되는 경우가 흔히 발생할 수 있습니다. 이 문서에서는 다중 테넌트 지원을 위해 Exchange를 구성할 경우 원하는 대로 기능이 작동하지 않을 수 있다는 점을 지적하며 구성에 대한 권장 사항을 제시하고 필요한 경우 특정 기능을 사용하지 않을 것을 권장합니다.

솔루션의 중요한 디렉터리 구분 요소에는 주소록 정책 기능이 핵심적입니다. 주소록 정책을 활용하기 위해 만들어진 전송 에이전트가 최근 발표됨에 따라 2013 솔루션을 훨씬 더 쉽게 만들고 유지 관리할 수 있을 것으로 생각됩니다.

2013에서 이루어진 중요한 변경 사항이 있으므로 솔루션을 계획하고 만들기 전에 이 지침을 자세히 읽어보고, 문제가 발생할 경우 필요에 따라 이 지침을 다시 참조하시기를 바랍니다.

Exchange 2010의 경우와 마찬가지로, 이 문서의 지침에 따라 만들어진 파트너 솔루션이 있으며, 현재 Microsoft에서 검증한 솔루션이 이 사이트에 나열되어 있습니다. 이 목록은 점차 확장될 예정이므로 사용하려는 솔루션이 현재 이 목록에 없는 경우 나중에 다시 확인하거나 해당 공급업체에 문의하여 검증 계획에 대해 알아보십시오.

다중 테넌트 지원 또는 호스팅을 위해 구성된 Exchange 2013에 대한 업데이트된 확장 지침을 릴리스할 계획이며 이 문서가 나올 때 솔루션 사이트를 업데이트할 예정입니다.

이 문서가 도움이 되었기를 바라며 의견이 있으면 언제든지 알려 주십시오.

Greg Taylor
주임 프로그램 관리자
Exchange Customer Experience

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Hosting and Multi-Tenancy Guidance for Exchange Server 2013 Now Available을 참조하십시오.

Exchange Server 2013의 OAB 관리

OfficeLocalization — Thu, 31 Jan 2013 15:20:00 GMT

최초 문서 게시일: 2013년 1월 15일 화요일

Exchange 팀 블로그 문서 Exchange Server 2013의 OAB를 통해 Exchange Server 2013의 새로운 OAB(오프라인 주소록) 생성 및 배포아키텍처를 소개했습니다. 아직 읽어보지 않으신 분은 이 문서를 잠시 살펴보시고, 이미 읽어보신 분도 내용을 상기할 수 있도록 다시 검토해 보시기 바랍니다.

Exchange 2013에서는 아키텍처 변경으로 인해 OAB 운영과 관리 방식이 이전과 달라졌습니다. 또한 새로운 Exchange 관리 센터에는 OAB를 관리하는 옵션이 아직 없으므로 현재는 OAB 관련 작업에 Exchange 관리 셸을 사용해야 합니다.

이 문서에서는 가장 일반적으로 수행되는 OAB 관리 작업을 설명하고 작업에 대한 이해를 돕기 위해 두 가지 실제 시나리오를 보여 드리려고 합니다.

참고: 다중 포리스트 Active Directory 도메인 환경의 경우 셸 세션에서 ViewEntireForest가 설정되어 있어야 합니다. 그렇지 않으면 이 문서에 나온 일부 명령이 출력을 반환하지 않습니다.

ViewEntireForest를 설정하기 위한 명령:

Set-ADServerSettings -ViewEntireForest $true

새 OAB 만들기

Exchange 2013에서 새 OAB를 만들 때에는 더 이상 -Server 매개 변수가 사용되지 않습니다. 새 OAB를 만들려면 필요한 주소 목록을 지정하기만 하면 됩니다.

다음은 "Global Address List FAB"라는 주소 목록에 대한 OAB를 만드는 예입니다.

New-OfflineAddressBook -Name OAB-FAB -AddressLists "Global Address List FAB"

OAB 생성 서버 식별

Exchange Server 2013의 중재 사서함에는 중재 사서함의 용도/기능을 정의하는 특정 "지속형 기능"이 할당됩니다.

지속형 기능 "OrganizationCapabilityOABGen"을 갖는 중재 사서함은 OAB 생성을 처리합니다. 이 문서의 나머지 부분에서는 이 사서함을 "조직 사서함"이라고 일컫겠습니다.

조직 사서함을 호스팅하는 Exchange Server 2013 사서함 서버는 해당 환경에서 정의되는 모든 OAB를 생성합니다.

비 DAG 환경에서는 다음 명령을 사용하여 OAB 생성 서버를 식별합니다.

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

DAG 환경에서는 다음과 같은 두 단계를 거쳐 OAB 생성 서버가 식별됩니다.

1단계: OABGen 기능을 갖는 조직 사서함이 호스팅된 사서함 데이터베이스를 식별합니다.

다음 명령을 사용하여 지속형 기능 OABGen을 갖는 중재 사서함과 이 사서함이 호스팅된 데이터베이스를 나열합니다.

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

2단계: 조직 사서함을 호스팅하는 데이터베이스가 마운트되어 있는 사서함 서버를 식별합니다.

다음 명령을 사용하여 사서함 데이터베이스의 활성 복사본을 식별합니다.

Get-MailboxDatabaseCopyStatus db1

데이터베이스 상태가 "마운트"되어 있는 서버가 현재 OAB 생성 서버입니다.

OAB 생성 서버 변경

두 가지 방법으로 OAB 생성 서버를 변경할 수 있습니다.

사서함 이동

OAB 생성 서버로 지정할 서버에 있는 사서함 데이터베이스로 조직 사서함을 이동합니다.

예:

DB1은 Exch1 서버에 있는 단일 복사본 데이터베이스이고 조직 사서함을 호스팅합니다. DB2는 Exch2에 있는 사서함 데이터베이스입니다.

다음 명령을 사용하여 조직 사서함을 DB2로 이동하고 Exch2를 OAB 생성 서버로 만들 수 있습니다.

Get-Mailbox -Arbitration -database db1| where {$_.PersistedCapabilities –like “*oab*”} | New-MoveRequest -TargetDatabase db2

조직 사서함을 호스팅하는 사서함 데이터베이스의 복사본이 하나만 있는 환경에는 이 방법이 더 적합합니다.

다른 서버에서 사서함 데이터베이스 활성화

조직 사서함을 호스팅하는 사서함 데이터베이스의 복사본이 여러 개 있는 환경에는 이 방법이 적합합니다.

예:

DB1은 조직 사서함을 호스팅하며 Exch1 및 Exch2 서버에 여러 복사본을 갖습니다. DB1은 현재 Exch1에서 활성 상태입니다.

다음 명령을 사용하여 Exch2에서 DB1을 활성화함으로써 Exch2를 OAB 생성 서버로 만들 수 있습니다.

Move-ActiveMailboxDatabase DB1 -ActivateOnServer Exch2

참고: OAB 생성 서버를 변경하기 전에 아래 "조직 사서함 배치"에 나온 지침을 검토하시기 바랍니다.

새 조직 사서함 만들기

관리자는 내결함성을 구현하거나 지리적으로 분산된 Exchange 배포 환경의 사용자를 지원하기 위해 추가 조직 사서함을 만들 수 있습니다.

새 조직 사서함을 만드는 작업은 다음 두 단계로 이루어집니다.

1단계: 새 중재 사서함을 만듭니다.

New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName “OAB Mailbox for Seattle”

2단계: OABGen 기능을 설정합니다.

Set-Mailbox -Arbitration oabs -OABGen $true

참고: 추가 조직 사서함을 만들기 전에 아래 "조직 사서함 배치"에 나온 지침을 검토하시기 바랍니다.

OAB 생성 일정 변경

Exchange Server 2010까지는 OAB 생성이 OAB 속성에 설정된 "Schedule"을 기반으로 이루어졌습니다. Exchange 2013 OAB의 속성을 확인할 때 정의된 "Schedule"을 볼 수 있습니다. 그러나 Exchange Server 2013 OAB 생성은 OAB 속성에 정의된 "Schedule"에 따라 이루어지지 않습니다.

대신 Exchange Server 2013 OAB 생성은 사서함 서버에 구성된 OABGeneratorWorkCycle 및 OABGeneratorWorkCycleCheckpoint 속성에 따라 이루어집니다.

예:

위 스크린샷의 값은 OAB가 매일 한 번 생성됨을 의미합니다.

OAB 다운로드 요청을 처리한 사서함 서버

Exchange Server 2013 CAS 역할은 적절한 사서함 역할 서버를 프록시로 사용하여 OAB 다운로드 요청을 처리합니다. CAS 역할은 처리하는 각 요청의 로그를 %ExchangeInstallPath%\Logging\HttpProxy\OAB\ 폴더에 있는 로그 파일에 유지합니다.

이러한 로그 파일을 통해 CAS가 요청을 처리하기 위해 선택한 사서함 서버를 쉽게 식별할 수 있습니다.

로그 파일의 몇 가지 중요한 필드에 대한 정보:

필드	설명
UrlStem	다운로드되는 OAB를 식별하고 전체 다운로드인지, 증분 다운로드인지를 확인하는 데 유용
AuthenticatedUser	OAB를 요청하는 사용자의 이름
AnchorMailbox	OAB 요청을 처리하기에 가장 가까운 위치에 있는 것으로 식별된 조직 사서함의 DN
ServerHostName	요청을 처리하는 CAS 서버 이름
HttpStatus	프록시 작업의 상태 코드
ProxyAction	CAS 서버가 요청을 처리하기 위해 수행한 작업. Exchange 2013 OAB의 경우 대개 "프록시"를 사용함
TargetServer	요청을 처리하도록 프록시로 사용된 사서함 역할 서버의 이름

로그 파일을 더 읽기 좋게 Excel로 가져올 수 있습니다.

예:

강제 OAB 생성

다음 두 가지 방법을 사용하여 Exchange Server 2013 OAB 생성이 즉시 시작되도록 강제할 수 있습니다.

방법 1: Update-OfflineAddresBook

아래 명령을 사용하면 모든 조직 사서함에 걸쳐 "Default Offline Address Book"이라는 OAB가 강제로 생성됩니다.

Update-OfflineAddressBook "default offline address book"

참고: 이 명령은 활성 조직 사서함을 호스팅하는 각 사서함 서버에 대한 RPC 요청을 시작합니다.

방법 2: 사서함 도우미 서비스 다시 시작

사서함 역할에 대한 Microsoft Exchange 사서함 도우미 서비스가 OAB 생성을 담당합니다. 이 서비스를 다시 시작하면 활성 조직 사서함을 호스팅하는 특정 사서함 서버에서 해당 환경에 정의되는 모든 OAB가 생성됩니다.

조직 사서함 배치

Exchange Server 2013 CAS 역할은 활성 조직 사서함이 호스팅된 "가장 가까운" 사서함 서버를 프록시로 사용하여 OAB 다운로드 요청을 처리합니다. 동일한 AD 사이트에 활성 상태의 조직 사서함이 둘 이상 있는 경우 라운드 로빈 방식으로 프록시를 사용하여 요청을 처리합니다. 이로 인해 전체 OAB 다운로드가 자주 이루어질 수 있습니다.

이에 따라 현재의 지침은 한 AD 사이트에 활성 상태의 조직 사서함이 하나만 있도록 조직 사서함 배치를 계획하라는 것입니다. 이는 새 조직 사서함을 만드는 것과 조직 사서함이 호스팅된 사서함 데이터베이스의 복사본을 만드는 데 적용됩니다.

시나리오

새 OAB 관리 방법에 대한 이해를 돕기 위해 다음과 같은 실제 상황 시나리오를 사용하여 좀 더 설명하겠습니다.

시나리오 1: 새 조직 사서함 만들기

Contoso는 달라스와 시애틀 사이트에 Exchange Server 2013 사서함과 CAS 역할 서버를 배포했습니다. Contoso의 Exchange 관리자인 John은 CAS 서버에서 http 프록시 로그 파일을 분석해 본 결과 시애틀 사용자의 OAB 다운로드 요청이 달라스 서버로 전송되는 것을 발견했습니다. 자세히 조사해 보니 조직 사서함이 달라스에 하나만 있어서 모든 사용자의 OAB 다운로드 요청이 달라스로 전송되는 것이었습니다.

John은 다음 명령을 사용하여 시애틀 사이트에 새 조직 사서함을 만들기로 결정합니다.

1단계: 새 중재 사서함을 만듭니다.

New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName “OAB Mailbox for Seattle”

2단계: 이 중재 사서함이 OABGen 기능을 갖도록 설정합니다.

Set-Mailbox -Arbitration oabs -OABGen $true

시나리오 2: OAB 생성 일정 사용자 지정

Ben은 Tail Spin Toys의 Exchange 2013 배포 관리자입니다. 기본 OAB 생성 일정은 적합하지 않으며 매일 대략 4시간에 한 번 OAB를 생성하기를 원합니다.

Ben은 다음 명령을 사용하여 조직 사서함이 호스팅될 사서함 서버의 속성을 변경합니다.

Set-MailboxServer Exch1 -OABGeneratorWorkCycle 01.00:00:00 -OABGeneratorWorkCycleCheckpoint 04:00:00

이틀 후에 John은 응용 프로그램 로그에서 이벤트 ID 17002를 분석하여 OAB가 4시간마다 생성되는 것을 확인합니다.

이 게시물이 유용했기를 바라며, 의견이 있으면 아래에 댓글로 알려 주십시오.

Bhalchandra Atre

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

공용 폴더 복제 문제 해결사

OfficeLocalization — Thu, 31 Jan 2013 15:19:35 GMT

최초 문서 게시일: 2012년 11월 13일 화요일

최근에 Microsoft에서는 Microsoft Exchange 2003의 공용 폴더 복제 문제를 해결하기 위한 GWT(Guided Walk Through)를 배포했습니다. 문제 해결사는 두 가지 방법으로 액세스할 수 있습니다. 이 링크를 사용하여 바로 액세스할 수 있으며, 다음과 같은 공용 폴더 복제 관련 문서에도 포함되어 있습니다. http://support.microsoft.com/kb/842273/ko-kr

더 이상 주류 지원 제품이 아닌 Exchange 2003에 대한 문제 해결사를 지금 내놓은 이유가 궁금하실 것입니다. 여러 가지 이유로 이러한 결정을 내리게 되었습니다. 첫째, Exchange 2003에서 전환하는 Exchange 고객이 아직 상당히 많으며 이러한 고객이 지원되는 보다 최신 제품 버전으로 전환하는 것을 최대한 돕고자 합니다. Exchange 2003에 대해서는 더 이상 전화 지원 옵션이 없기 때문에 이렇게 하는 것이 Exchange 2003 고객을 안내하는 최선의 방법이라고 생각합니다. 둘째, Exchange Server 2003 공용 폴더 문제는 이미 대부분 파악되었으므로 이를 바탕으로 큰 수고 없이 문제 해결사를 만들 수 있었습니다. 마지막으로, 공용 폴더 복제 메커니즘은 한동안(Exchange 2013까지) 크게 변경되지 않았기 때문에 Exchange 2003에 대한 문제 해결사를 만들어 두면 이를 업데이트하여 이후 Exchange 버전에 대한 문제 해결사를 비교적 쉽게 만들 수 있을 것 같습니다.

지원 조직에서는 향후에 2007/2010을 포함하여 이 문제 해결사를 확장할 계획입니다.

이 GWT는 Bill Long의 블로그 게시물 시리즈(여기, 여기, 여기)에 나온 것과 같이 복제 문제 해결을 안내하며, 공용 폴더 복제 프로세스의 이해를 돕는 모든 자료를 대체하기 위한 것이 아니라 복제 문제가 있을 경우 문제를 찾는 데 도움을 주기 위한 간단한 안내 자료입니다.

이 GWT를 만드는 데 도움을 주신 분들께 감사를 표합니다. 제가 아는 한 다음과 같은 분들이 GWT를 만드는 데 참여하셨습니다.

Exchange 지원:

Nick Basile
Rob Whaley
Bill Long
Charlotte Raymundo
Will Duff
Nino Bilic

문서/콘텐츠 작성 팀:

Bobbie DeFault
Geoffrey Crisp(Entirenet)
Jerry Sitser(Entiernet)
Jarrett Renshaw
Star Li(Wicresoft)
Chen Jiang
Victor Zhang(Wicresoft)

감사합니다.

Charlotte Raymundo
메시징 지식 공학 엔지니어

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Public Folder replication troubleshooter를 참조하십시오.

Office 365와 Exchange Online의 받는 사람 비율 제한을 10,000으로 증가

OfficeLocalization — Thu, 31 Jan 2013 15:18:48 GMT

최초 문서 게시일: 2012년 12월 27일 목요일

Microsoft에서는 고객의 의견을 수렴해서 Office 365 Enterprise(E1, E2, E3, E4, K1, K2), Professionals 및 Small Businesses(P1), Government 계획(G1, G2, G3, G4)의 받는 사람 비율 제한을 늘려 일별 최대 10,000명의 받는 사람에게 전자 메일을 보낼 수 있도록 했습니다. 이 새로운 제한은 독립 실행형 Exchange Online 계획(Kiosk, 계획 1, 계획 2)에도 적용됩니다. 이전에는 이러한 계획의 받는 사람 비율 제한이 일별 최대 1,500명의 받는 사람으로 설정되어 있었습니다.

받는 사람 비율 제한은 스팸이라고도 하는 원치 않는 상업성 전자 메일을 대량 발송하지 못하게 하기 위한 것입니다. 이러한 제한은 Microsoft의 온라인 서비스가 스팸 출처가 되지 않도록 방지하며 이러한 보호의 결과로 고객의 전자 메일 메시지가 계속 오고 갈 수 있도록 하기 위한 것입니다. 데이터 센터의 향상 덕분에 동일한 보호 수준을 유지하면서 이 제한을 늘릴 수 있게 되었습니다.

이러한 제한은 조직 내에서 전송되는 전자 메일 메시지와 외부 조직으로 전송되는 전자 메일 메시지에 모두 적용됩니다. 받는 사람 비율 제한을 초과하지 않도록 방지하는 가장 좋은 방법은 다수의 받는 사람에게 메시지를 보낼 때 메일 그룹을 사용하는 것입니다. 공유 주소록에 저장된 메일 그룹은 받는 사람 비율 제한에서 받는 사람 한 명으로 계산됩니다. 자세한 내용은 대량 전자 메일을 보내기 위한 방법을 참조하십시오. 고객 뉴스레터와 같은 합법적인 대량 상업성 전자 메일을 보내야 하는 Office 365 고객은 이러한 서비스에 전문화된 타사 공급업체를 계속 이용하셔야 합니다.

받는 사람 비율 제한에 대한 자세한 내용은 대량 전자 메일 및 일별 받는 사람 비율 제한을 참조하십시오. 이러한 변경은 여러분의 의견을 반영한 것입니다. 많은 의견을 보내 주셔서 감사 드리며, 앞으로도 계속 의견 부탁 드립니다!

Steve Chew

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Recipient Rate Limit Increase to 10K for Office 365 and Exchange Online을 참조하십시오.

Microsoft Remote Connectivity Analyzer의 여러 가지 새로운 기능

OfficeLocalization — Thu, 31 Jan 2013 15:18:12 GMT

최초 문서 게시일: 2012년 11월 20일 화요일

Outlook 클라이언트에서 전자 메일 서버에 연결하는 데 문제가 있다는 전화를 받아보신 적이 있나요? 그러한 사람에게 어떤 도구를 보내서 그들이 직접 도구의 안내에 따라 연결 테스트를 수행하고 그 결과를 간단한 방법으로 여러분에게 돌려 보낼 수 있다면 좋을 것 같지 않으세요?

또는 수년간 Remote Connectivity Analyzer를 사용해서 전자 메일 구성을 확인하는 관리자로서, RCA 웹 사이트와 같은 진단 세부 정보를 제공하는 테스트를 조직 내에서 확인할 수 있다면 좋을 것 같지 않으세요?

저희 팀에서는 고객 여러분으로부터 이같은 요청을 많이 들어 이러한 시나리오만을 위한 도구를 제작했습니다. Remote Connectivity Analyzer 웹 사이트의 휴대용 버전인 Microsoft Connectivity Analyzer(베타)를 소개해 드리고자 합니다. 다음은 Microsoft Connectivity Analyzer를 소개하는 49초 분량의 짧은 비디오입니다.

이 도구에는 웹 사이트와 동일한 테스트가 포함되어 있으며, 여러분의 사용자뿐만 아니라 가족 또는 이웃 등 누구와도 공유할 수 있도록 UI를 좀 더 단순화했습니다.

또한 결과를 두 개의 보기로 분할했습니다. 누구든지 이해할 수 있을 법한 결과만 표시한 단순화된 보기와 여러분과 같은 관리자만 쉽게 이해할 수 있는 상세한 전체 결과 보기로 나뉘어져 있습니다.

또한 관리자가 확인할 추가적인 세부 정보는 "실행한 모든 테스트 검토(Review all the tests we ran)" 아래에 표시됩니다.

또는 사용자에게 자세한 결과를 저장하여 여러분에게 보내 달라고 요청할 수도 있습니다. 자세한 결과는 HTML 파일로 저장되며 브라우저에서 볼 수 있습니다.

Microsoft Connectivity Analyzer 필수 구성 요소

이 도구는 64비트 Windows 7, Windows 7, Windows Server 2008+ 운영 체제를 지원합니다.
Microsoft .NET Framework 4.5가 필요합니다.
브라우저 요구 사항:

모든 최신 브라우저에서 설치가 가능합니다. 하지만…

Google Chrome을 사용하는 경우 ClickOnce for Google Chrome을 설치해야 합니다.

FireFox를 사용하는 경우 Microsoft .Net Framework Assistant for FireFox를 설치해야 합니다.

전체 릴리스 노트는 여기에서 확인할 수 있습니다.

앞으로 더 많은 테스트를 추가할 계획

웹 사이트 버전을 처음 배포했을 때와 마찬가지로 이 첫 번째 Microsoft Connectivity Analyzer 버전은 여전히 개발 중인 상태입니다.

최종 사용자가 자신의 위치에서 도구를 사용할 수 있는 독보적인 기능을 기반으로 모든 연결 유형에서 나타나는 일반적인 문제를 포함하여 테스트를 확장하려고 합니다. 이 초기 버전의 도구는 시작에 불과합니다.

한 곳에서 Lync 연결 테스트도 수행 가능

새로운 도구를 제공할 뿐만 아니라 Lync Remote Connectivity Analyzer와 합쳐 한 곳에서 두 가지 도구를 함께 제공합니다. 보시다시피 이름에서 "Exchange"가 빠졌으며 웹 사이트 주소도 http://testconnectivity.microsoft.com으로 바뀌었습니다. 이제 Lync와 Exchange에 대한 유용한 테스트를 모두 하나의 웹 사이트에서 사용할 수 있습니다.

다음과 같은 테스트가 포함됩니다.

Microsoft Lync Mobile Auto-Discover Web Service Remote Connectivity Test는 Microsoft Lync Mobile Auto-Discover Web Service Server에 대한 원격 연결을 테스트합니다.
Microsoft Office Communications Server Test는 Microsoft Office Communications Server에 대한 원격 연결을 테스트합니다. 액세스 에지와 액세스 에지에 연결되는 포트를 자동으로 검색하거나 수동으로 액세스 에지 서버를 지정할 수 있습니다.
Microsoft Lync Server Remote Connectivity Test는 Microsoft Lync Server에 대한 원격 연결을 테스트합니다. 액세스 에지와 액세스 에지에 연결되는 포트를 자동으로 검색하거나 수동으로 액세스 에지 서버를 지정할 수 있습니다.

새로 추가된 테스트

이것만이 아닙니다. Office 365 탭에 보시면 두 가지 새로운 테스트인 Office 365 Lync DNS 테스트와 약속 있음/없음(Free/Busy) 테스트가 있습니다.

Office 365 Lync DNS 테스트는 Office365의 사용자 지정 도메인 사용자에 대한 외부 도메인 이름 설정을 확인합니다.

Office 365 배포 서비스 팀 덕분에 이제 RCA 웹 사이트에서 Office 365 약속 있음/없음 테스트를 호스팅하게 되었습니다. 이 테스트는 Office 365 사서함에서 온-프레미스 사서함의 약속 있음/없음 정보에 액세스할 수 있는지, 그리고 온-프레미스 사서함에서 Office 365 사서함의 약속 있음/없음 정보에 액세스할 수 있는지를 확인합니다. 여기에는 다음이 포함됩니다.

하이브리드 서버의 시스템 시간이 5분 이상 상쇄되는지 확인. 이 경우 Microsoft Federated Gateway에서 위임 토큰을 요청할 때 오류가 발생합니다.
하이브리드 서버에 대한 인바운드 연결에 방화벽 미리 인증이 필요 없는지, 즉 방화벽에서 통과 인증을 허용하는지 확인
하이브리드 서버가 최소 Exchange Server 버전 요구 사항(Exchange Server 2010 SP1)을 충족하는지 확인
대상 가용성 서비스에 대한 기본 약속 있음/없음 쿼리
하이브리드 배포 구성 오류가 많이 나타나는 하이브리드 구성 마법사에 대한 지침 링크

읽어 주셔서 감사합니다. 새로운 업데이트를 유용하게 활용하시기 바라며, 많은 의견 기다리겠습니다.

Nicole Allen
RCA 팀을 대표하여

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 What’s new with Microsoft Remote Connectivity Analyzer? A lot!을 참조하십시오.

Exchange 2007과 Exchange 2010의 Windows Management Framework 3.0

OfficeLocalization — Thu, 31 Jan 2013 15:17:35 GMT

최초 문서 게시일: 2012년 12월 15일 토요일

최근에 Windows Update에서는 Windows Management Framework 3.0을 선택적 업데이트로 제공하기 시작했습니다. 여기에는 Microsoft Update, WSUS, System Center Configuration Manager 및 기타 메커니즘을 비롯한 모든 형태의 업데이트 배포가 포함됩니다. 중요한 것은 Windows Management Framework 3.0에 PowerShell 3.0이 포함된다는 점입니다.

Windows Management Framework 3.0은 KB2506146 및 KB2506143으로 배포되며, 둘 중 어느 것이 제공되는지는 실행 중인 서버 버전이 Windows Server 2008 SP2인지, Windows Server 2008 R2 SP1인지에 따라 달라집니다.

영향

Windows Management Framework 3.0(특히 PowerShell 3.0)은 이 소프트웨어가 필요한 Exchange Server 2013을 제외하고 어떠한 버전의 Exchange에서도 지원되지 않습니다. Exchange 2007 또는 Exchange 2010을 실행하는 서버에 Windows Management Framework 3.0을 설치할 경우 Exchange 업데이트 롤업이 설치되지 않거나 Exchange Management Shell이 제대로 실행되지 않는 것과 같은 문제가 발생합니다.

다음과 같은 증상을 나타내며 Exchange 업데이트 롤업이 설치되지 않는 경우가 있었습니다.

Microsoft Update를 통해 롤업이 설치되는 경우 오류 코드 80070643이 나타나며 설치 오류가 발생할 수 있습니다.
다운로드에서 롤업이 설치되는 경우 오류 때문에 설치가 중간에 중단되었습니다라는 오류 메시지가 표시됩니다.
두 가지 경우 모두 응용 프로그램 이벤트 로그에 오류 코드 "1603"으로 이벤트 ID 1024가 로깅될 수 있습니다. 예를 들어 Exchange 2010 SP2에 대한 업데이트 롤업 5를 설치하려고 하면 이벤트 ID 1024에 다음과 같은 설명이 나타날 수 있습니다.
제품: Microsoft Exchange Server - 'Exchange Server 2010 서비스 팩 2에 대한 업데이트 롤업 5-v2(KB2785908) 14.2.328.10' 업데이트를 설치하지 못했습니다. 오류 코드 1603. Windows Installer에서는 소프트웨어 패키지의 설치 문제의 해결에 도움을 주는 로그 파일을 만들 수 있습니다. 로깅 지원을 사용하도록 설정하는 방법은 다음 링크를 참조해 주십시오. http://go.microsoft.com/fwlink/?LinkId=23127

현재 저희가 드릴 수 있는 지침은 Exchange 2007 또는 Exchange 2010을 실행하는 서버나 이러한 버전에 대한 Exchange 관리 도구가 설치된 워크스테이션에는 Windows Management Framework 3.0을 배포하지 않아야 한다는 것입니다. 이미 이 업데이트를 배포한 경우에는 제거해야 합니다. 업데이트를 제거하면 기능이 복원될 것입니다.

Ben Winzenz

2012/12/17: 이벤트 ID 1024에 대한 세부 정보가 추가되었습니다.

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Windows Management Framework 3.0 on Exchange 2007 and Exchange 2010을 참조하십시오.

Exchange Server 2013 GA(일반 공급)

OfficeLocalization — Thu, 31 Jan 2013 15:16:00 GMT

최초 문서 게시일: 2012년 12월 4일 화요일

지난 10월 Exchange 팀은 Exchange Server 2013의 RTM(Release to Manufacturing) 빌드가 승인되었다고 발표했으며, 그 이후로 다양한 유통 채널을 통해 비즈니스 고객에게 이 차기 버전의 Exchange를 배포하는 데 주력해 왔습니다.

오늘은 Exchange 팀에게 또 다른 중요한 이정표가 되는 날입니다. 다름 아니라 Exchange Server 2013의 GA(일반 공급)를 알려 드리게 되어 기쁩니다. 오늘부터 TechNet에서 이 소프트웨어 제품을 다운로드하여 180일간 평가해 보실 수 있습니다. 또한 Office 365 Preview에 가입하여 불과 몇 분 내로 클라우드에서 최신 Exchange 환경을 경험해 보실 수 있습니다.

신규 환경이나 랩 및 테스트 환경에서 Exchange Server 2013을 배포하여 새로운 기능을 평가하고 LOB 응용 프로그램과 함께 테스트해 보려는 경우 즉시 시작하실 수 있습니다. Exchange 2010 또는 2007 환경을 실행하는 경우 업그레이드를 위해 Exchange Server 2010 SP3 또는 2007 롤업이 필요합니다. 고객 여러분이 새로운 버전으로 빨리 전환하고 싶어하실 것이므로 저희는 Exchange 2010 SP3와 롤업의 마무리 작업에 힘쓰고 있으며 2010 SP3와 롤업을 2013년 1분기에 예정대로 출시할 예정입니다.

TechNet 문서를 검토하거나 Ignite 교육 세션에 참가하여 Exchange Server 2013에 대한 자세한 정보를 알아보시길 바랍니다. 지금부터 필수 구성 요소와 시스템 요구 사항을 검토하고 Exchange의 단순화된 구성 요소 아키텍처를 숙지하시는 것이 좋습니다. 이렇게 하면 이후에 하드웨어 사이징, 계획 및 구매를 바로 시작하실 수 있습니다.

EHLO 팀에서는 RTM 발표 이후로 새로운 Exchange에 대한 기술 콘텐츠를 계속 추가하고 있습니다.

Exchange Server 2013의 OAB - Bhalchandra Atre
EAC를 사용한 페더레이션 공유 관리 - Elber Ren 및 Robert Mazzoli
Outlook Web App 2013의 오프라인 액세스 기능 - Sara Manning
새로운 Office의 공용 폴더 - Alfons Staerk 및 Nikhil Aggarwal
TMG를 사용하여 Exchange Server 2013 게시 - Greg Taylor
데이터 센터에서 얻은 교훈: Managed Availability - Ross Smith IV 및 Greg Thiel

…앞으로 몇 개월 동안 EHLO에 새로운 Exchange 문서를 꾸준히 게시할 예정이므로 관심을 갖고 확인해 주십시오! 변함없는 성원에 감사드리며, 앞으로도 많은 의견 보내 주시기 바랍니다.

Exchange 팀

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Exchange Server 2013 Reaches General Availability를 참조하십시오.

새로운 Exchange의 현재 위치 eDiscovery 및 원본 위치 유지 기능 - II부

OfficeLocalization — Wed, 05 Dec 2012 09:15:00 GMT

최초 문서 게시일: 2012년 9월 29일 토요일

이 게시물의 I부에서는 새로운 Exchange의 현재 위치 eDiscovery 기능을 소개했으며, 이 게시물에서는 새로운 Exchange가 데이터를 변경 불가능하게 유지하는 방식을 살펴보도록 하겠습니다.

소송 가능성이 예상되거나 eDiscovery 요청을 받는 경우 우선적으로 수행해야 할 단계는 메시징 레코드를 유지하여 필요 시 제시할 수 있도록 하는 것입니다. Exchange 2010 이전에는 대개 다양한 방법을 사용하여 메시지가 유지되었습니다. 외부 시스템에 데이터를 보관하거나, 자동 삭제 메커니즘(예: Exchange의 메시징 레코드 관리)을 일시 중단하거나, 경우에 따라 사용자에게 레코드를 삭제하지 않도록 지시하는 방법이 사용되었습니다.

소송에 필요한 레코드를 유지하지 않으면 조직이 법적 위험 및 재정적 위험에 처할 수 있습니다.

Exchange 2010과 Office 365에서는 소송 보존을 사용하여 메시징 레코드를 유지할 수 있습니다. 소송 보존은 사서함 속성입니다. 사서함을 소송 보존으로 설정하면 사서함의 모든 항목이 무기한( 또는 보존을 해제할 때까지) 유지됩니다. 이로 인해 대량의 데이터가 쌓이게 되는데, 이러한 모든 데이터를 유지할 필요는 없을 수 있습니다.

새로운 Exchange에서는 원본 위치 유지를 사용하여 항목을 변경 불가능하게 유지할 수 있습니다. 원본 위치 유지는 현재 위치 eDiscovery와 통합되어 있어 동일한 인터페이스와 쿼리 매개 변수를 사용하여 검색과 유지를 동시에 수행할 수 있습니다. 다음과 같은 시나리오로 원본 위치 유지를 사용할 수 있습니다.

무기한 유지: 쿼리 매개 변수와 유지 기간 없이 원본 위치 유지를 만들어 사서함의 모든 항목을 무기한 또는 유지가 해제될 때까지 유지할 수 있습니다. 이는 소송 보존의 동작을 에뮬레이트하는 것입니다.
쿼리 기반 유지: 원본 위치 유지를 사용하여 검색 쿼리를 만들고 원본 사서함과 키워드, 보낸 사람, 받는 사람, 시작 날짜, 종료 날짜와 같은 매개 변수를 지정할 수 있습니다. 또한 전자 메일 메시지, 모임 및 약속과 같은 일정 항목, 작업, 메모, Exchange 사서함에 보관된 Lync 콘텐츠 등의 검색할 항목 유형을 지정할 수 있습니다.
시간 기반 유지: 소송 보존에서는 사서함의 모든 콘텐츠가 무기한 또는 유지를 해제할 때까지 유지된 반면, 원본 위치 유지에서는 항목을 유지할 기간을 지정할 수 있습니다. 기간은 받은 날짜 또는 항목이 사서함에 만들어진 날짜(약속, 작업 및 메모와 같은 보내거나 받지 않는 항목의 경우)를 기준으로 계산됩니다.

Exchange 2010에서 가장 많이 요청된 기능 중 하나는 항목이 유지되는 한정된 기간을 지정하는 기능이었습니다. 보존 정책을 사용하여 전자 메일 수명 주기를 지정하고 지정된 기간에 도달하면 자동으로 항목을 삭제할 수 있지만 해당 기간 동안 항목이 유지되는 것을 보장할 수 없습니다. 예를 들어 항목이 최대 7년 동안 유지되도록 지정할 수 있지만 이 기간이 되기 전에 사용자 또는 프로세스에 의해 항목이 삭제되지 않도록 보장하는 방법이 없습니다.

이 요구를 충족하기 위해 흔히 권장된 해결 방법은 지운 편지함 복구 기간을 항목을 유지할 최소 기간으로 구성하는 것이었습니다. 이 예에서 삭제된 항목 보존 기간을 7년으로 설정하는 경우 사용자가 7년이 되기 전에 항목을 삭제할 경우 해당 항목이 복구 가능한 항목 폴더에 7년 동안 유지됩니다. 그러나 삭제된 항목 보존 기간은 삭제 날짜로부터 계산됩니다. 사용자가 6년 후에 항목을 삭제할 경우 복구 가능한 항목 폴더에 추가로 7년 동안 유지되어 총 보존 기간이 13년이 됩니다. 다시 말해서, 항목이 최소 7년 동안 유지되는 것은 보장할 수 있지만 최대 보존 기간 동안 유지되는 것은 보장할 수 없습니다.

새로운 Exchange에서는 시간 기반 원본 위치 유지를 만들 때 유지 기간이 항목을 받은 날짜 또는 만든 날짜로부터 계산되므로 항목이 해당 기간을 넘어 유지되지 않도록 보장할 수 있습니다. 시간 기반 원본 위치 유지와 하나의 기본 정책 태그를 갖는 보존 정책을 함께 사용하면 사서함의 항목이 7년 후에 MFA(관리되는 폴더 도우미)를 통해 삭제되며 이 기간 전에 사용자 또는 프로세스에 의해 삭제된 항목은 최소한 지정된 기간 동안 유지됩니다.

쿼리 기반 원본 위치 유지와 시간 기반 원본 위치 유지를 함께 사용하여 쿼리와 일치하는 항목을 지정된 기간 동안 유지할 수 있습니다. 또한 한 사용자에 대해 여러 원본 위치 유지를 설정할 수 있습니다. 예를 들어 한 사서함에 여러 사례 또는 조사와 관련된 레코드가 포함되어 있을 수 있습니다.

원본 위치 유지와 권한

현재 위치 eDiscovery와 마찬가지로, 위임된 검색 관리 권한이 부여된 사용자가 원본 위치 유지를 사용할 수 있습니다. 그러나 약간의 차이가 있습니다. 검색 관리 역할 그룹에는 사서함 검색과 소송 보존 관리 역할이 할당됩니다. 사서함 검색 관리 역할은 현재 위치 eDiscovery와 원본 위치 유지를 위한 사서함 검색을 만들 수 있고 소송 보존 관리 역할은 실제로 사서함 콘텐츠를 원본 위치 유지로 설정할 수 있습니다.

사용자 지정 RBAC(역할 기반 액세스 제어) 역할 그룹을 만들거나 소송 보존 역할이 할당된 조직 관리와 같은 역할 그룹의 멤버 자격을 통해 사용자에게 소송 보존 역할만 할당된 경우, 해당 사용자는 원본 위치 유지를 사용할 수 있지만 사서함의 모든 콘텐츠를 원본 위치 유지로 설정할 수만 있고 쿼리 매개 변수를 지정할 수는 없습니다. 다시 말해서, 이 사용자는 쿼리 기반 원본 위치 유지를 만들 수 없습니다.

원본 위치 유지 만들기

이 게시물의 I부에서 Robin이 만든 쿼리로 돌아가 보겠습니다. Robin은 원본 위치 유지를 만들 때 사서함(Mailboxes) 페이지에서 검색할 사서함 지정(Specify mailboxes to search)을 선택하고 사서함 또는 배포 그룹을 선택해야 합니다. 모든 편지함 검색(Search all mailboxes)을 선택하는 경우 콘텐츠를 원본 위치 유지로 설정하는 옵션을 사용할 수 없습니다.

원본 위치 유지로 설정할 사서함 또는 배포 그룹을 지정해야 합니다. 모든 편지함 검색(Search all mailboxes)을 선택하는 경우 콘텐츠를 원본 위치 유지로 설정하는 옵션을 사용할 수 없습니다.

그림 1: 원본 위치 유지를 만들려면 검색할 사서함 지정을 선택해야 함

참고: 배포 그룹을 선택하는 경우 원본 위치 유지를 만들 때 해당 그룹의 구성원인 사서함 사용자에게 원본 위치 유지가 적용됩니다.

Robin은 검색 쿼리(Search query) 페이지에서 현재 위치 eDiscovery를 위해 사용한 쿼리를 그대로 사용할 수 있습니다.

그림 2: 쿼리 매개 변수와 일치하는 메시지가 유지됨

또한 원본 위치 유지로 설정할 메시지 유형을 선택할 수 있습니다.

그림 3: 유지할 메시지 유형을 지정하거나 모든 메시지 유형을 지정할 수 있음

보관된 Lync 콘텐츠를 원본 위치 유지로 설정

새로운 Lync에서 인스턴트 메시징 및 모임 콘텐츠를 새로운 Exchange에 보관하도록 설정한 경우 Lync 콘텐츠가 사용자의 사서함에 보관되어 자동으로 원본 위치 유지로 설정됩니다. 이 기능을 사용하려면 Lync과 Exchange 간에 OAuth 인증을 구성해야 합니다. 또한 사서함이 새 Exchange의 사서함 서버에 있어야 합니다.

Robin은 원본 위치 유지 설정(In-Place Hold settings) 페이지에서 검색 쿼리와 일치하는 콘텐츠를 선택한 사서함에 유지(Place content matching the search query in selected mailboxes on hold) 옵션을 선택합니다. 그런 다음 콘텐츠를 무기한(또는 원본 위치 유지가 해제되거나 사서함이 검색에서 제외될 때까지) 유지하도록 무기한 보류(Hold indefinitely)를 선택합니다. 특정 기간 동안 항목을 유지하려는 경우 받은 날짜를 기준으로 항목을 유지할 일 수 지정(Specify number of days to hold items relative to their received date)을 선택하고 일 수를 지정할 수 있습니다.

그림 4: 유지 기간을 지정하거나 무기한 항목을 유지할 수 있음

다시 한 번 강조하면, 시간 기반 유지의 경우 메시지를 받거나 만든 날짜를 기준으로 기간이 계산됩니다.

원본 위치 유지의 작동 방식

그럼 원본 위치 유지가 어떤 방식으로 작동하는지 살펴보겠습니다.

사용자가 메시지를 삭제하면 메시지는 지운 편지함 폴더로 이동합니다. 지운 편지함 폴더를 비우거나, 이 폴더에서 메시지를 삭제하거나, 사용자가 Shift-Delete를 사용하여 메시지를 삭제하는 경우 메시지가 복구 가능한 항목\Deletes 폴더로 이동합니다. 이 폴더의 콘텐츠는 사용자가 Outlook 또는 Outlook Web App에서 지운 편지함 복구를 사용하면 표시됩니다.

사용자가 아무 작업도 수행하지 않으면 사서함 데이터베이스 또는 사용자에 대해 구성한 삭제된 항목 보존 기간이 만료될 때 Deletes 폴더의 메시지가 제거됩니다.

사용자가 이 보기에서 메시지를 삭제하면 다음과 같은 몇 가지 현상이 발생할 수 있습니다.

사서함에 단일 항목 복구를 사용하도록 설정한 경우 항목이 복구 가능한 항목\Purges폴더로 이동하여 삭제된 항목 보존 기간이 만료될 때까지 유지됩니다. 이를 통해 관리자가 백업에서 복구할 필요 없이 항목을 복구할 수 있습니다.
사서함에 소송 보존이 설정된 경우 항목이 복구 가능한 항목\Purges폴더로 이동하여 유지가 해제될 때까지 유지됩니다.
사서함에 원본 위치 유지가 설정된 경우 항목이 복구 가능한 항목\DiscoveryHolds 폴더로 이동합니다.

그림 5: 삭제된 항목과 수정된 항목의 원래 복사본이 각 사서함의 복구 가능한 항목 폴더에 유지됨

사서함을 처리하고 콘텐츠를 만료시키는 사서함 도우미인 MFA는 사서함을 처리할 때 메시지가 사용자가 설정한 원본 위치 유지의 쿼리 매개 변수를 충족하는지 확인합니다. 이 평가는 최대 5개의 쿼리에 대해 수행되며, 5개가 넘으면 모든 항목이 유지됩니다. 즉, 이 경우 소송 보존과 동일한 동작이 에뮬레이트됩니다. 유지 개수가 5개 미만이 되면 MFA는 다시 쿼리 기반 원본 위치 유지 동작으로 되돌아갑니다.

원본 위치 유지가 해제되면 사용자에게 설정된 다른 원본 위치 유지의 쿼리 매개 변수와 일치하지 않는 한 원본 위치 유지가 설정되었던 메시지가 제거됩니다.

원본 위치 유지와 불변성

유지에 관해 이야기할 때 항상 떠오르는 개념은 불변성입니다. 불변성은 원본 위치 유지가 설정된 메시지가 변경 없이 유지되어야 함을 의미합니다. 메시지가 삭제되지 않도록 하는 것(원본 위치 유지가 설정된 사용자는 메시지를 성공적으로 삭제했다고 생각할 수 있음)은 물론 변조 또는 변경되지 않도록 해야 합니다. 불변성은 제품 기능이 아니라 기능과 조직에서 구현한 유지 프로세스가 결합된 것입니다.

또한 원본 위치 유지를 사용하면 콘텐츠가 의도적으로 변조되거나 수정되지 않도록 보호할 수 있습니다. 이 기능은 COW(기록 중 복사)를 수행하여 구현됩니다. 사용자 또는 프로세스가 메시지를 수정하려고 하면 수정된 메시지가 저장되기 전에 원본 메시지의 복사본이 만들어져서 복구 가능한 항목\Versions 폴더에 저장됩니다. 또한 Versions 폴더에 캡처된 항목은 인덱싱되어 현재 위치 eDiscovery 검색에서 반환됩니다. 유지가 해제되면 Versions 폴더에 만들어진 복사본도 관리되는 폴더 도우미에 의해 제거됩니다.

원본 위치 유지와 현재 위치 eDiscovery는 권한이 부여된 법률, 인사 또는 기타 비기술직 담당자가 메시징 레코드를 손쉽게 검색하고 변경 불가능하게 유지할 수 있도록 하는 간편한 메커니즘을 제공합니다.

Bharat Suneja와 Julian Zbogar-Smith

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 In-Place eDiscovery and In-Place Hold in the New Exchange – Part II를 참조하십시오.