내보내기(0) 인쇄
모두 확장

Exchange Server 2013 릴리스 정보

 

적용 대상: Exchange Server 2013

마지막으로 수정된 항목: 2014-08-25

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

이 항목에서 다루는 섹션은 다음과 같습니다.

  • Setup 설치 프로그램이 .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 누적 업데이트 또는 서비스 팩을 설치하면 Exchange XML 응용 프로그램 구성 파일(예: 클라이언트 액세스 서버의 web.config 또는 사서함 서버의 EdgeTransport.exe.config 파일)의 모든 사용자 지정 서버 단위 설정을 덮어씁니다. 설치 후에 서버를 다시 구성하기 쉽도록 이 정보를 저장해야 합니다. Exchange 누적 업데이트 또는 서비스 팩을 설치한 후에 이러한 설정을 다시 구성해야 합니다.

  • 서버 복구 중에 MAPI 가상 디렉터리가 만들어지지 않음   클라이언트 액세스 서버 역할이 설치된 서버에서 RecoverServer 스위치를 사용하여 Setup.exe를 실행하면 MAPI 가상 디렉터리가 만들어지지 않습니다. MAPI 가상 디렉터리가 없으면 MAPI over HTTP 프로토콜을 사용하여 Exchange 서버에 연결하는 Outlook 등의 클라이언트가 연결할 수 없게 됩니다.

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

    이 문제를 해결하려면 기술 자료 문서 KB2931223(MAPI 가상 디렉터리가 기본 웹 사이트 노드에서 누락됨)의 단계를 수행하세요.

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

  • 이전 Exchange 버전에서 마이그레이션할 때 사서함 크기 증가   사서함을 이전 버전의 Exchange에서 Exchange 2013으로 이동하면 사서함 크기가 30~40% 증가하여 보고될 수 있습니다. 사서함 데이터베이스에 사용되는 디스크 공간은 증가하지 않고 각 사서함에 사용되는 공간 속성만 증가되었습니다. 사서함 크기의 증가는 할당량 계산에 모든 항목 속성이 포함되어 사서함 내의 항목이 사용하는 공간을 보다 정확히 계산하기 때문에 발생합니다. 이러한 증가로 인해 사서함을 Exchange 2013으로 이동할 때 일부 사용자의 사서함 크기 할당량이 초과될 수 있습니다.

    사용자의 사서함 크기 할당량이 초과되지 않게 하려면 새 할당량 계산을 수용하도록 데이터베이스 또는 사서함 할당량 값을 늘립니다. 데이터베이스 또는 사서함 할당량 값을 구성하려면 Set-MailboxDatabaseSet-Mailbox cmdlet에서 각각 IssueWarningQuota, ProhibitSendQuotaProhibitSendReceiveQuota 매개 변수를 사용합니다.

  • Outlook 2007 및 Outlook 2010 클라이언트가 오프라인 주소록을 다운로드하지 못할 수 있음   OAB(오프라인 주소록) 내부 URL을 인터넷에서 액세스할 수 없는 경우 Outlook 2007 및 Outlook 2010 클라이언트가 OAB를 다운로드하지 못할 수 있습니다.

    Outlook 2007 및 Outlook 2010 클라이언트에 대해 이 문제를 해결하려면 인터넷에서 OAB 내부 URL에 액세스할 수 있도록 설정합니다. Outlook 2013은 이 문제의 영향을 받지 않습니다.

  • 기존 Exchange 조직에서 Exchange 2013을 설치하면 모든 클라이언트가 OAB를 다운로드할 수 있음   기존 Exchange 2007 또는 Exchange 2010 조직에 Exchange 2013 서버를 처음으로 설치하면 조직의 모든 클라이언트가 새 OAB 복사본을 다운로드하여 네트워크 포화 상태 및 서버 성능 문제가 발생할 수 있습니다. 이 문제가 발생하는 이유는, Exchange 2013에서 Exchange 2007 또는 Exchange 2010 OAB보다 우선하는 새 기본 OAB를 조직에 만들기 때문입니다. 특정 OAB가 할당되어 있지 않은 사서함 또는 특정 OAB가 할당되지 않은 사서함 데이터베이스에 있는 사서함은 새 기본 OAB를 다운로드합니다.

    Exchange 2013 설치 시 클라이언트가 새 OAB 복사본을 다운로드하지 않도록 하려면 모든 사서함 또는 사서함이 있는 사서함 데이터베이스에 OAB를 할당합니다. 이 작업은 조직에 Exchange 2013을 설치하기 전에 수행해야 합니다.

  • 사용자들은 요청된 OAB를 담당하지 않는 OAB 생성 사서함으로 라우팅될 수 있음   Exchange 2013 CU5는 OAB가 OAB 생성 사서함에 연결되는 방식을 변경합니다. 이렇게 변경하면 사용자는 요청 중인 OAB를 담당하지 않는 OAB 생성 사서함으로 라우팅될 수 있습니다. 이러한 상황은 다음 모든 조건에 해당하는 경우 발생할 수 있습니다.

    • 조직에 여러 개의 OAB 생성 사서함이 있는 경우

    • 클라이언트 액세스 서버를 업그레이드하기 전에 OAB 생성 사서함을 호스팅하는 사서함 서버를 업그레이드하는 경우

    • CU5 이전 릴리스에서 CU5 이상으로 Exchange 2013 서버를 업그레이드하는 경우(예를 들어 Exchange 2013 CU3에서 Exchange 2013 CU5로 업그레이드)

    • 클라이언트 액세스 서버가 CU5 이전 릴리스를 실행하고 있는 경우

    이 문제를 해결하려면 사서함 서버를 업그레이드하기 전에 클라이언트 액세스 서버를 Exchange 2013 CU5로 업그레이드해야 합니다. 이렇게 하면 클라이언트 액세스 서버는 사용자의 OAB 생성을 담당하는 OAB 생성 사서함으로 요청을 프록시하는 방법을 알게 됩니다.

    Exchange 2013 CU5의 OAB 변경 내용에 대한 자세한 내용은 Exchange 2013 누적 업데이트 5의 향상된 OAB를 참조하세요.

  • 권한이 없는 보낸 사람이 공용 폴더로 메시지를 보낼 수 있음   Exchange 2013 SP1 이상을 실행하는 서버에 있는 공용 폴더는 공용 폴더의 구성에 관계없이 Exchange 조직 외부의 보낸 사람이 보내는 메시지를 수락합니다. 이 문제로 인해 공용 폴더에 스팸 및 기타 원치 않는 메시지를 받을 수 있습니다.

    현재 이 문제에 대한 해결 방법은 없습니다.

  • Exchange 웹 서비스를 통해 레거시 공용 폴더에 액세스할 수 없음   Exchange 2007 또는 Outlook 2010 서버에 있는 공용 폴더에는 EWS(Exchange 웹 서비스)를 사용하여 Exchange 2013에 연결하는 클라이언트가 액세스할 수 없습니다. EWS를 사용하는 클라이언트에는 Mac Outlook 및 Outlook Web App이 포함됩니다. EWS 클라이언트가 레거시 공용 폴더에 액세스하려고 하면 오류가 발생합니다.

    현재의 유일한 해결 방법은 레거시 공용 폴더를 Exchange 2013으로 마이그레이션하는 것입니다. 그렇지만 공용 폴더를 마이그레이션하기 전에 고려해야 할 몇 가지 문제가 있습니다. 자세한 내용은 공용 폴더를 참조하세요.

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

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

    주의주의:
    Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell 스냅인을 로드하고 *-TransportAgent cmdlet 외의 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 Mail 등의 클라이언트와 Exchange 2013 간의 인증이 실패할 수 있습니다.

    • 클라이언트가 사용하는 인증 모드가 NTLM인 경우

    • 컴퓨터가 도메인에 가입되어 있지 않은 경우

    이 문제를 해결하려면 다음 중 하나를 수행하면 됩니다.

    • 클라이언트를 실행 중인 컴퓨터를 도메인에 가입시킵니다.

    • 클라이언트가 사용하는 인증 유형을 NTLM에서 TLS를 통한 기본 인증으로 변경합니다.

  • Send-MailMessage cmdlet과 함께 사용할 때 GSSAPI 인증 실패Windows PowerShell의 기본 설치에 포함된 Send-MailMessage cmdlet을 사용하여 Exchange 2013에 인증된 메일을 보낼 때 GSSAPI(   Generic Security Service Application Program Interface) 인증이 실패할 수 있습니다. 이 경우 연결을 수신한 Exchange 2013 클라이언트 액세스 서버의 응용 프로그램 이벤트 로그에 다음 정보가 포함된 항목이 표시됩니다.

    • Source 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로 업그레이드하면 MAPI over HTTP의 성능이 저하될 수 있음   Exchange 2013 누적 업데이트에서 Exchange 2013 SP1로 업그레이드하고 MAPI over HTTP를 사용하도록 설정하면 해당 프로토콜을 사용하여 Exchange 2013 SP1 서버에 연결하는 클라이언트의 성능이 저하될 수 있습니다. 누적 업데이트에서 Exchange 2013 SP1로 업그레이드하는 동안 필수 설정이 구성되지 않기 때문입니다. Exchange 2013 RTM에서 Exchange 2013 SP1로 업그레이드하거나 Exchange 2013 SP1 이상 서버를 새로 설치하는 경우에는 이 문제가 발생하지 않습니다.

    참고참고:
    이 문제는 클라이언트 액세스 서버에서 MAPI over HTTP 프로토콜을 사용하도록 설정된 경우에만 발생합니다. 이 프로토콜은 기본적으로 사용하지 않도록 설정됩니다. MAPI over HTTP가 사용하지 않도록 설정된 경우 클라이언트에서 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 2013 클라이언트 액세스 서버를 통해 프록시 처리되면 Exchange 2010 사서함 액세스 요청이 작동하지 않을 수 있음   업데이트 롤업이 설치되지 않은 Exchange 2013과 Exchange 2010 SP3(서비스 팩 3) 클라이언트 액세스 서버 간의 프록시 요청이 정상적으로 작동하지 않고 오류가 표시되는 경우가 있습니다. 이러한 상황은 다음 모든 조건에 해당하는 경우 발생할 수 있습니다.

    • Exchange 2013 사서함을 소유한 사용자가 다음 방법 중 하나를 사용하여 Exchange 2010 사서함을 열려고 시도하는 경우

      • Outlook Web App의 다른 사서함 열기 옵션 또는

      • Exchange 관리 센터의 다른 사용자 옵션

    • 사용자가 연결한 클라이언트 액세스 서버에서 Exchange 2013을 실행 중인 경우

    • Exchange 2010 클라이언트 액세스 서버가 Exchange 2010 RTM(Release To Manufacturing) 버전 또는 이전 Exchange 2010 서비스 팩에서 Exchange 2010 SP3으로 업그레이드된 경우

    위의 모든 조건에 해당하는 경우에는 다른 사용자의 Exchange 2010 Outlook Web App 옵션에 액세스할 수 없으며 빈 페이지가 표시될 수 있습니다.

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

 
이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.
표시:
© 2014 Microsoft