내보내기(0) 인쇄
모두 확장
이 문서는 기계로 번역한 것입니다. 원본 텍스트를 보려면 포인터를 문서의 문장 위로 올리십시오.
번역
원본

Exchange Server 2013 릴리스 정보

 

적용 대상: Exchange Server 2013

마지막으로 수정된 항목: 2015-03-10

Microsoft Exchange Server 2013 시작! 이 항목에는 Exchange 2013 에 대 한 누적 업데이트 8을 성공적으로 배포를 알고 있어야 하는 중요 한 정보가 들어 있습니다. 배포를 시작 하기 전에이 항목을 완전히 참조 하십시오.

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

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

    This behavior is expected as the value of msExchProductId doesn't reflect the version of Exchange 2013 being installed. This property reflects the version of Exchange 2013 that last made changes to the Active Directory schema. To avoid confusion, we recommend that you follow the steps in the How do you know this worked? section of Active Directory 및 도메인 준비 to verify that your Active Directory has been updated and is ready for the release of Exchange 2013 you're installing.

  • 설치 프로그램 .NET Framework 4.0을 올바르게 요청.NET Framework 컴퓨터에 설치 하지 않고 Exchange 2013 를 설치 하려고 하면 설치 프로그램 올바르게을 요청 하지 .NET Framework 4.5 이상이 필요은 실제로 가장 편리한 때 .NET Framework 4.0을 설치 합니다.

    To work around this issue, install .NET Framework 4.5 or later. You don’t need to install .NET Framework 4.0. For a complete list of prerequisites, see Exchange 2013 필수 구성 요소.

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

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 C u 5 및 이상 cu로 Oab OAB 생성 사서함에 연결 되는 방법을 변경 되었습니다. 이 변경으로 인해 사용자가 요청 하는 OAB에 대 한 책임을 집니다 없는 OAB 생성 사서함에 라우팅할 수를 사용자에 대 한 가능한 합니다. 이 다음과 같은 경우에 발생할 수 있습니다.

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

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

    • 이후 버전 (예: Exchange 2013 c u 3에서에서 Exchange 2013 CU6로 업그레이드)을 CU5 이전 릴리스에서 Exchange 2013 서버를 업그레이드 하는 경우.

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

    이 문제를 해결 하려면 Exchange 2013 CU6에 대 한 클라이언트 액세스 서버를 업그레이드 하거나 사서함 서버를 업그레이드 하기 전에 나중에 했는지를 확인 합니다. 이 클라이언트 액세스 서버는 알고 있는지 확인 합니다 어떻게 프록시 OAB 생성 사서함에 대 한 요청 횟수가 4 사용자의 OAB 생성을 담당 합니다.

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

  • 허가 되지 않은 보낸 사람은 메일 사용이 가능한 공용 폴더에 메시지를 보낼 수 없습니다   Exchange 2013 CU6 하기 전에 무단으로 보낸 사람은 메일 사용이 가능한 공용 폴더에 메시지를 보낼 수 있습니다. 이 외부의 보낸 사람이 공용 폴더를 사용 하는 권한과 상관 없이 메일 사용 가능 공용 폴더에 메일을 보낼 수에 대 한 가능성을 허용 합니다.

    익명 사용자 항목 만들기 권한이 최소한 부여 해야하는 외부의 보낸 사람이 메일 사용이 가능한 공용 폴더에 메일을 보낼 수를 원하는 경우 Exchange 2013 CU6로 시작 합니다. 메일 사용이 가능한 공용 폴더를 설정 했을 때이 작업을 수행 하지 않은 경우 외부 보낸 사람이 배달 실패 알림을 받게 됩니다 및 메일 사용이 가능한 공용 폴더에 메시지를 배달 하지 않습니다.

    You can use the Shell or Outlook to set the permissions on the Anonymous user. To read more about how to set permissions on the Anonymous user, see 메일 사용이 가능한 또는 공용 폴더 메일-사용 안 함.

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

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

    주의주의:
    Microsoft.Exchange.Management.PowerShell.SnapInWindows PowerShell 스냅인을 로드하고 *-TransportAgent cmdlet 외의 cmdlet을 실행하는 것은 지원되지 않으며, 이 경우 Exchange 배포에 복구할 수 없는 손상이 발생할 수 있습니다.
    전송 에이전트를 설치, 제거 또는 관리할 클라이언트 액세스 서버에서 로컬 관리자여야 합니다. Exchange 파일, 디렉터리 또는 Active Directory 개체에 대한 ACL(액세스 제어 목록)의 수정은 지원되지 않습니다.
    중요중요:
    클라이언트 액세스 서버에서만 다음 절차를 수행합니다. 사서함 서버에서 전송 에이전트를 관리하려는 경우 ExchangeWindows 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 클라이언트 액세스 서버의 응용 프로그램 이벤트 로그에 다음 정보가 포함된 항목이 표시됩니다.

    • SourceMSExchangeFrontEndTransport

    • 이벤트 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 2010Outlook Web App 옵션에 액세스할 수 없으며 빈 페이지가 표시될 수 있습니다.

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

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