최초 문서 게시일: 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!를 참조하십시오.

최초 문서 게시일: 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을 참조하십시오.

최초 문서 게시일: 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 팀 블로그 문서 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가 요청을 처리하기 위해 선택한 사서함 서버를 쉽게 식별할 수 있습니다.

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

로그 파일을 더 읽기 좋게 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을 참조하십시오.

최근에 Microsoft에서는 Microsoft Exchange 2003의 공용 폴더 복제 문제를 해결하기 위한 GWT(Guided Walk Through)를 배포했습니다. 문제 해결사는 두 가지 방법으로 액세스할 수 있습니다. 이 링크를 사용하여 바로 액세스할 수 있으며, 다음과 같은 공용 폴더 복제 관련 문서에도 포함되어 있습니다. https://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를 참조하십시오.

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을 참조하십시오.

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 필수 구성 요소

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

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

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

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

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

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

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

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

새로운 도구를 제공할 뿐만 아니라 Lync Remote Connectivity Analyzer와 합쳐 한 곳에서 두 가지 도구를 함께 제공합니다. 보시다시피 이름에서 "Exchange"가 빠졌으며 웹 사이트 주소도 https://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!을 참조하십시오.

최근에 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에서는 소프트웨어 패키지의 설치 문제의 해결에 도움을 주는 로그 파일을 만들 수 있습니다. 로깅 지원을 사용하도록 설정하는 방법은 다음 링크를 참조해 주십시오. https://go.microsoft.com/fwlink/?LinkId=23127

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

Ben Winzenz

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

지난 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를 참조하십시오.