Exchange Server 2013 릴리스 정보

아티클
04/04/2023

적용 대상: Exchange Server 2013

Microsoft Exchange Server 2013을 시작합니다. 이 항목에는 Exchange 2013을 성공적으로 배포하기 위해 알아야 할 중요한 정보가 포함되어 있습니다. 배포를 시작하기 전에 이 항목을 자세히 읽으십시오.

이 항목에는 다음 섹션이 포함되어 있습니다.

설정 및 배포
Exchange 관리 셸
메일함
공용 폴더
메일 흐름
클라이언트 연결
Exchange 2010 동시 사용

설정 및 배포

msExchProductId는 설치된 Exchange 2013 릴리스 버전을 반영하지 않습니다 . Exchange에서 Active Directory 스키마를 확장하고 Exchange용 Active Directory를 준비하면 준비가 완료됨을 보여 주는 몇 가지 속성이 업데이트됩니다. 이러한 속성 중 하나는 명명 컨텍스트의 컨테이너 아래에 있는 CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain>msExchangeProductId입니다Configuration. 설치 중인 Exchange 2013 릴리스에서 Active Directory 스키마 변경 내용이 도입되지 않으면 이 속성이 업데이트되지 않거나 예기치 않은 값이 표시될 수 있습니다. 값이 설치된 Exchange 2013 버전과 일치하지 않는 경우 혼동이 발생할 수 있습니다.

msExchProductId 값이 설치된 Exchange 2013 버전을 반영하지 않으므로 이 동작이 예상됩니다. 이 속성은 Active Directory 스키마를 마지막으로 변경한 Exchange 2013 버전을 반영합니다. 혼동을 방지하려면 Active Directory 및 도메인 준비의 이 작업을 어떻게 알 수 있나요? 섹션의 단계에 따라 Active Directory가 업데이트되었으며 설치 중인 Exchange 2013 릴리스가 준비되었는지 확인하는 것이 좋습니다.
설치 .NET Framework 4.0을 잘못 요청: 컴퓨터에 .NET Framework 설치하지 않고 Exchange 2013을 설치하려고 하면 실제로 .NET Framework 4.5 이상이 필요한 경우 설치 .NET Framework 4.0을 설치하도록 잘못 요청합니다.

이 문제를 해결하려면 .NET Framework 4.5 이상을 설치합니다. .NET Framework 4.0을 설치할 필요가 없습니다. 필수 구성 요소의 전체 목록은 Exchange 2013 필수 구성 요소를 참조하세요.
Exchange XML 애플리케이션 구성 파일은 누적 업데이트 설치 중에 덮어씁니다. Exchange XML 애플리케이션 구성 파일에서 사용자 지정된 Exchange 또는 인터넷 정보 서버 설정(예: 클라이언트 액세스 서버의 web.config 파일 또는 사서함 서버의 EdgeTransport.exe.config 파일)은 Exchange 누적 업데이트 또는 서비스 팩을 설치할 때 덮어씁니다. 설치 후 서버를 쉽게 다시 구성할 수 있도록 이 정보를 저장했는지 확인하세요. Exchange 누적 업데이트 또는 서비스 팩을 설치한 후 이러한 설정을 다시 구성해야 합니다.
위임 관리 권한을 사용하여 Exchange를 설치하면 위임된 설치 프로그램 역할 그룹의 구성원인 사용자가 미리 프로비전된 서버에 Exchange를 설치하려고 하면 설치가 실패합니다. 이는 위임된 설치 프로그램 그룹에 Active Directory의 특정 개체를 만들고 구성하는 데 필요한 권한이 부족하기 때문입니다.

이 문제를 해결하려면 다음 중 하나를 수행합니다.
- 사용자가 설치하고 있는 Exchange를 Domain Admins Active Directory 보안 그룹에 추가합니다.
- 조직 관리 역할 그룹의 구성원인 사용자를 통해 Exchange를 설치합니다.

Exchange 2013을 설치하는 방법에 대한 자세한 내용은 계획 및 배포를 참조하세요.

Exchange 관리 셸

셸이 Exchange 2007 또는 Exchange 2010 cmdlet을 예기치 않게 로드합니다. 이전에는 Exchange 2013 서버에서 셸을 열면 셸이 로컬 서버 또는 Exchange 2013을 실행하는 다른 서버에 대한 연결을 엽니다. 연결이 완료되면 Exchange 2013 cmdlet이 로드됩니다. Exchange 2013 CU11부터 셸은 로그온한 사용자의 사서함이 있는 Exchange 서버에 연결됩니다. 로그온한 사용자에게 사서함이 없는 경우 셸은 SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} 중재 사서함이 있는 서버에 연결됩니다. 대상 서버는 지원되는 Exchange 버전일 수 있습니다. 즉, 로그온한 사용자의 사서함(또는 사용자가 사서함이 없는 경우 중재 사서함)이 Exchange 2010 서버에 있는 경우 셸은 해당 서버에 연결하고 Exchange 2010 cmdlet을 로드합니다. Exchange 2010 cmdlet은 Exchange 2013 구성 또는 서버를 관리할 수 없으므로 이로 인해 특정 작업을 수행할 수 없습니다.

Exchange 2013 CU11부터 이 동작은 의도적으로 수행됩니다. 셸이 Exchange 2013 cmdlet을 로드하도록 하려면 로그온한 사용자의 사서함을 Exchange 2013으로 이동합니다. 로그온한 사용자에게 사서함이 없는 경우 SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} 중재 사서함을 Exchange 2013 서버로 이동합니다.

중재 사서함을 이동하는 방법에 대한 자세한 내용 및 정보는 Exchange 팀 블로그의 Exchange 관리 셸 및 사서함 앵커링을 참조하세요.

메일함

서로 다른 버전의 Exchange를 실행하는 사서함 서버를 동일한 데이터베이스 가용성 그룹에 추가할 수 있습니다 . Add-DatabaseAvailabilityGroupServer cmdlet 및 Exchange 관리 센터에서 Exchange 2013 서버를 Exchange 2016 기반 DAG(데이터베이스 가용성 그룹)에 추가하도록 잘못 허용하고 그 반대의 경우도 마찬가지입니다. Exchange는 동일한 버전(예: Exchange 2013 대 Exchange 2016)을 실행하는 사서함 서버를 DAG에 추가하는 작업만 지원합니다. 또한 Exchange 관리 센터에는 DAG에 추가할 수 있는 서버 목록에 Exchange 2013 및 Exchange 2016 서버가 모두 표시됩니다. 따라서 관리자가 무심코 호환되지 않는 Exchange 버전을 DAG에 추가할 수 있습니다(예: Exchange 2013 서버를 Exchange 2016 기반 DAG에 추가).

현재 이 문제를 해결할 수 있는 방법이 없습니다. 관리자는 사서함 서버를 DAG에 추가할 때 유심히 살펴야 합니다. Exchange 2013 서버만 Exchange 2013 기반 DAG에 추가하고 Exchange 2016 서버만 Exchange 2016 기반 DAG에 추가합니다. Exchange 관리 센터의 서버 목록에 있는 버전 열만 보고도 각 Exchange 버전을 구분할 수 있습니다. 다음은 Exchange 2013 및 Exchange 2016의 서버 버전입니다.
- Exchange 2013 15.0(빌드 xxx.xx)
- Exchange 2016 15.1(빌드 xxx.xx)
이전 Exchange 버전에서 마이그레이션할 때 사서함 크기 증가: 이전 버전의 Exchange에서 Exchange 2013으로 사서함을 이동하면 보고된 사서함 크기가 30%에서 40%로 증가할 수 있습니다. 사서함 데이터베이스에서 사용하는 디스크 공간은 증가하지 않았으며 각 사서함에서 사용하는 공간의 특성만 증가했습니다. 사서함 크기가 증가하면 모든 항목 속성이 할당량 계산에 포함되어 사서함 내의 항목에서 사용하는 공간을 보다 정확하게 계산할 수 있기 때문입니다. 이 증가로 인해 일부 사용자는 사서함이 Exchange 2013으로 이동될 때 사서함 크기 할당량을 초과할 수 있습니다.

사용자가 사서함 크기 할당량을 초과하지 않도록 하려면 새 할당량 계산을 수용하도록 데이터베이스 또는 사서함 할당량 값을 늘입니다. 데이터베이스 또는 사서함 할당량 값을 구성하려면 Set-MailboxDatabase 및 Set-Mailbox cmdlet에서 각각 IssueWarningQuota, ProhibitSendQuota 및 ProhibitSendReceiveQuota 매개 변수를 사용합니다.
Outlook 2007 및 Outlook 2010 클라이언트가 오프라인 주소록을 다운로드하지 못할 수 있습니다. 인터넷에서 OAB(오프라인 주소록) 내부 URL에 액세스할 수 없는 경우 Outlook 2007 및 Outlook 2010 클라이언트가 OAB를 다운로드하지 못할 수 있습니다.

Outlook 2007 및 Outlook 2010 클라이언트에 대한 이 문제를 해결하려면 인터넷에서 OAB 내부 URL에 액세스할 수 있도록 합니다. Outlook 2013은 이 문제의 영향을 받지 않습니다.
기존 Exchange 조직에 Exchange 2013을 설치하면 모든 클라이언트가 OAB를 다운로드할 수 있습니다. 첫 번째 Exchange 2013 서버를 기존 Exchange 2007 또는 Exchange 2010 조직에 설치하면 조직의 모든 클라이언트가 OAB의 새 복사본을 다운로드하여 네트워크 포화 및 서버 성능 문제가 발생할 수 있습니다. 이 문제는 Exchange 2013이 Exchange 2007 또는 Exchange 2010 OAB를 대체하는 조직에 새 기본 OAB를 만들기 때문에 발생합니다. 특정 OAB가 할당되지 않았거나 특정 OAB가 할당되지 않은 사서함 데이터베이스에 있는 사서함은 새 기본 OAB를 다운로드합니다.

Exchange 2013이 설치될 때 클라이언트가 OAB의 새 복사본을 다운로드하지 못하도록 하려면 모든 사서함 또는 사서함이 있는 사서함 데이터베이스에 OAB를 할당합니다. 이 작업은 Exchange 2013이 조직에 설치되기 전에 수행해야 합니다.
사용자는 요청된 OAB에 대한 책임이 없는 OAB 세대 사서함으로 라우팅될 수 있습니다. Exchange 2013 CU5 이상 CU는 OAB 생성 사서함에 OAB를 연결하는 방법을 변경했습니다. 이렇게 변경하면 사용자가 요청하는 OAB에 대한 책임이 없는 OAB 세대 사서함으로 사용자를 라우팅할 수 있습니다. 이 문제는 다음이 모두 true인 경우 발생할 수 있습니다.
- 조직에 OAB 세대 사서함이 두 개 이상 있습니다.
- 클라이언트 액세스 서버를 업그레이드하기 전에 OAB 세대 사서함을 호스트하는 사서함 서버를 업그레이드합니다.
- Exchange 2013 서버를 CU5 이전 릴리스에서 이후 릴리스로 업그레이드하고 있습니다(예: Exchange 2013 CU3에서 Exchange 2013 CU6으로 업그레이드).
- 클라이언트 액세스 서버는 CU5 이전에 릴리스를 실행합니다.
이 문제를 해결하려면 사서함 서버를 업그레이드하기 전에 클라이언트 액세스 서버를 Exchange 2013 CU6 이상으로 업그레이드해야 합니다. 이렇게 하면 클라이언트 액세스 서버가 사용자의 OAB 생성을 담당하는 OAB 세대 사서함에 요청을 프록시하는 방법을 알 수 있습니다.

Exchange 2013 CU5의 OAB 변경 내용에 대한 자세한 내용은 Exchange 2013 누적 업데이트 5의 OAB 개선 사항을 참조하세요.

공용 폴더

권한이 없는 보낸 사람이 더 이상 메일 사용 공용 폴더로 메시지를 보낼 수 없습니다. Exchange 2013 CU6 이전에는 권한이 없는 보낸 사람이 메일 사용이 가능한 공용 폴더로 메시지를 보낼 수 있습니다. 이렇게 하면 외부 보낸 사람이 공용 폴더에 설정된 권한에 관계없이 메일 사용이 가능한 공용 폴더로 메일을 보낼 수 있습니다.

Exchange 2013 CU6부터 외부 보낸 사람이 메일 사용이 가능한 공용 폴더로 메일을 보내도록 하려면 적어도 항목 만들기 권한을 익명 사용자에게 부여해야 합니다. 메일 사용 공용 폴더를 설정했는데 이 작업을 수행하지 않은 경우 외부 보낸 사람이 배달 실패 알림을 받게 되며 메일 사용이 가능한 공용 폴더로 메시지가 배달되지 않습니다.

Shell 또는 Outlook을 사용하여 익명 사용자에 대한 권한을 설정할 수 있습니다. 익명 사용자에 대한 사용 권한을 설정하는 방법에 대한 자세한 내용은 공용 폴더 메일 사용 또는 메일 사용 안 함을 참조하세요.
레거시 Exchange 서버에서 Exchange 2013으로 마이그레이션할 수 있는 공용 폴더의 최대 수는 500,000개입니다. 공용 폴더 마이그레이션에 대한 자세한 내용은 일괄 마이그레이션을 사용하여 이전 버전에서 Exchange 2013으로 공용 폴더 마이그레이션을 참조하세요.

메일 흐름

클라이언트 액세스 서버의 TransportAgent cmdlet에는 로컬 Windows PowerShell 필요합니다. 이러한 cmdlet이 Exchange 관리 셸을 사용하여 클라이언트 액세스 서버에 전송 에이전트를 설치, 제거 및 관리하지 못하도록 하는 *-TransportAgent cmdlet에 문제가 있습니다. 클라이언트 액세스 서버에서 전송 에이전트를 설치, 제거 및 관리하려면 Exchange Windows PowerShell 스냅인을 수동으로 로드한 다음 *-TransportAgent cmdlet을 실행해야 합니다. Exchange 관리 셸을 사용하여 전송 에이전트를 설치, 제거 또는 관리하려고 하면 변경 내용이 연결된 Exchange 2013 사서함 서버에 적용됩니다.

클라이언트 액세스 서버에서 전송 에이전트를 설치, 제거 또는 관리하려면 관리하려는 클라이언트 액세스 서버에서 다음을 수행합니다.

경고

Microsoft.Exchange.Management.PowerShell.SnapIn -TransportAgent cmdlet 이외의 Windows PowerShell 스냅인 및 실행 cmdlet을 로드하는 것은 지원되지 않으며 Exchange 배포에 돌이킬 수 없는 손상을 초래할 수 있습니다.

전송 에이전트를 설치, 제거 또는 관리하려는 클라이언트 액세스 서버의 로컬 관리자여야 합니다. Exchange 파일, 디렉터리 또는 Active Directory 개체의 ACL(액세스 제어 목록) 수정은 지원하지 않습니다.

중요

클라이언트 액세스 서버에서만 다음 절차를 수행합니다. 사서함 서버에서 전송 에이전트를 관리하려는 경우 Exchange Windows PowerShell 스냅인을 로드할 필요가 없습니다.
1. 새 Windows PowerShell 창을 엽니다.
2. 다음 명령을 실행합니다.
```
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
```
3. 정상적으로 전송 에이전트 관리 작업을 수행합니다.
4. 관리하려는 각 클라이언트 액세스 서버에서 이 절차를 반복합니다.

클라이언트 연결

도메인에 가입되지 않은 클라이언트에 대한 NTLM 인증 실패: 다음과 같은 조건이 충족되면 Windows Live 메일 및 Exchange 2013과 같은 클라이언트 간의 인증이 실패할 수 있습니다.
- 그런 다음 클라이언트에서 사용하는 인증 방법은 NTLM입니다.
- 컴퓨터가 도메인에 가입되지 않았습니다.
이 문제를 해결하려면 다음 중 하나를 수행할 수 있습니다.
- 클라이언트가 실행 중인 컴퓨터를 도메인에 조인합니다.
- 클라이언트에서 사용하는 인증 유형을 TLS를 통해 NTLM에서 기본 인증으로 변경합니다.
Send-MailMessage cmdlet과 함께 사용하면 GSSAPI 인증이 실패합니다. GSSAPI(일반 보안 서비스 애플리케이션 프로그램 인터페이스) 인증은 기본 Windows PowerShell 설치에 포함된 Send-MailMessage cmdlet을 사용하여 인증된 메일을 Exchange 2013으로 보내는 데 사용될 때 실패할 수 있습니다. 이 경우 Exchange 2013 클라이언트 액세스 서버의 애플리케이션 이벤트 로그에 다음 정보로 연결을 받은 항목이 표시됩니다.
- 원본: MSExchangeFrontEndTransport
- 이벤트 ID: 1035
- 설명: 수신 커넥터 클라이언트 프런트 엔드 <서버 이름>에 대한 오류 IllegalMessage 로 인바운드 인증이 실패했습니다. 인증 메커니즘은 Gssapi입니다. Exchange에 인증하려고 시도한 클라이언트의 원본 IP 주소는 [<클라이언트 IP 주소>]입니다.
이 문제를 해결하려면 Exchange 2013 클라이언트 액세스 서버의 클라이언트 수신 커넥터에서 인증 방법을 제거 Integrated 해야 합니다. 클라이언트 수신 커넥터에서 인증 방법을 제거 Integrated 하려면 Send-MailMessage cmdlet을 실행하는 컴퓨터에서 연결을 받을 수 있는 각 Exchange 2013 클라이언트 액세스 서버에서 다음 명령을 실행합니다.
```
Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS
```
EXCHANGE 2013 SP1로 업그레이드할 때 HTTP를 통한 MAPI 성능 저하가 발생할 수 있습니다. Exchange 2013 누적 업데이트에서 Exchange 2013 SP1로 업그레이드하고 HTTP를 통해 MAPI를 사용하도록 설정하면 프로토콜을 사용하여 Exchange 2013 SP1 서버에 연결하는 클라이언트의 성능이 저하할 수 있습니다. 이는 누적 업데이트에서 Exchange 2013 SP1로 업그레이드하는 동안 필수 설정이 구성되지 않기 때문입니다. Exchange 2013 RTM에서 Exchange 2013 SP1로 업그레이드하거나 새 Exchange 2013 SP1 이상 서버를 설치하는 경우에는 이 문제가 발생하지 않습니다.

참고

클라이언트 액세스 서버에서 HTTP 프로토콜을 통한 MAPI를 사용하도록 설정한 경우에만 문제가 됩니다. 기본적으로 사용하지 않도록 설정됩니다. HTTP를 통한 MAPI를 사용하지 않도록 설정하면 클라이언트는 대신 RPC over HTTP 프로토콜을 사용합니다.

이 문제를 해결하려면 다음을 수행합니다.
1. 클라이언트 액세스 서버 역할을 실행하는 서버에서 Windows 명령 프롬프트에서 다음 명령을 실행합니다.
```
set AppCmdLocation=%windir%\System32\inetsrv
set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiFrontEndAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiFrontEndAppPool"
```
2. 사서함 서버 역할을 실행하는 서버에서 Windows 명령 프롬프트에서 다음 명령을 실행합니다.
```
set AppCmdLocation=%windir%\System32\inetsrv
set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiMailboxAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiMailboxAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiMailboxAppPool"

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiAddressBookAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiAddressBookAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiAddressBookAppPool"
```

Exchange 2010 동시 사용

Exchange 2013 클라이언트 액세스 서버를 통해 프록시할 때 Exchange 2010 사서함에 대한 액세스 요청이 작동하지 않을 수 있습니다. 경우에 따라 업데이트 롤업이 설치되지 않은 Exchange 2013과 Exchange 2010 SP3(서비스 팩 3) 클라이언트 액세스 서버 간의 프록시 요청이 제대로 작동하지 않을 수 있으며 오류가 나타납니다. 이 문제는 다음 조건이 모두 충족되는 경우에 발생할 수 있습니다.
- Exchange 2013 사서함이 있는 사용자는 다음 방법 중 하나를 사용하여 Exchange 2010 사서함을 열려고 합니다.
  - Outlook Web App 다른 사서함 열기 옵션 -OR-
  - Exchange 관리 센터의 다른 사용자 옵션
  - 사용자가 연결된 클라이언트 액세스 서버가 Exchange 2013을 실행하고 있습니다.
  - Exchange 2010 클라이언트 액세스 서버는 릴리스에서 Exchange 2010 또는 이전 Exchange 2010 서비스 팩의 RTM(제조) 버전으로 Exchange 2010 SP3으로 업그레이드되었습니다.
위의 모든 조건이 true이면 사용자가 다른 사용자의 Exchange 2010 Outlook Web App 옵션에 액세스할 수 없으며 빈 페이지가 나타날 수 있습니다.

이 문제를 해결하려면 각 Exchange 2010 서버에 Exchange 2010 SP3 업데이트 롤업 1 이상을 설치합니다.

다음을 통해 공유