제대로해야하는 Exchange Server 설정

마이크로 소프트는 애저와 오피스 365에 수백만 달러를 투자했으며, 경쟁 업체들은 자신들의 진정한 퍼블릭 클라우드 제품을 따라 가고 있습니다. 그러나 퍼블릭 클라우드 솔루션이 모든 사람을위한 것은 아닙니다. 많은 스트라이프로 구성된 조직은 전체 제어 범위를 넘어서는 시스템에서 제한된 데이터를 원하지 않는 정당한 이유가 있습니다.

이러한 많은 엔터티의 경우 온-프레미스 Exchange Server가 메시징 필수입니다. Microsoft는 클라우드 기반 스택에 대한 개선 사항이 결국 감소 할 것이라는 확신으로 소프트웨어를 계속 업데이트하고 있습니다. 이러한 기능은 엔터프라이즈 급 메시징 시스템을 실행하는 이미 어려운 작업에 점점 더 복잡해지고 있습니다. 하드웨어 용량 계획, DAG (데이터베이스 가용성 그룹) 및 사이트 복구 설정, 메일 라우팅 구성, 사용자가 실제로 시스템에 연결할 수 있는지 확인하는 과정에서 길을 잃기 쉽습니다.

이를 염두에두고 새로운 메시징 환경을 열기 전에 반드시 알아야 할 몇 가지 세부 정보를 소개합니다.

생산 능력

Exchange Server를 다운로드하기 전에 시스템에서 지원해야하는 사용자 수, 보유 할 수있는 서비스 수준 계약 및 조직에 필요한 재해 복구 기간에 대해 잘 알고 있어야합니다. 이는이 문서의 범위를 훨씬 벗어나는 매우 심층적 인 주제이지만 Microsoft는이를 계획하는 데 도움이되는 몇 가지 도구를 제공합니다.

먼저 TechNet의 Exchange 2013 크기 조정 및 구성 권장 사항 문서입니다. Active Directory CPU 코어 대 사서함 서버 CPU 코어 비율, 네트워킹 구성, 필수 Windows Server 핫픽스 및 페이지 파일 구성과 같은 기본 사항에 대해 설명합니다. Exchange Server 2010에 익숙하다면이 문서에서 Exchange 2013 구성에 대해 강조된 몇 가지 변경 사항을 확인할 수 있습니다. 예를 들어 더 이상 복제를 위해 별도의 네트워크를 권장하지 않습니다.

핵심 권장 사항을 숙지했으면 용량 계획을 시작해야합니다. Exchange 팀 블로그는 이에 대한 훌륭한 정보 소스이며이 그룹은 환경 크기를 올바르게 조정하는 방법에 대한 포괄적 인 정보를 게시했습니다. 수학적 공식에 실망하지 마십시오. 프로세스를 쉽게 진행할 수 있도록 크기 계산기를 다운로드 할 수 있습니다.

몇 가지 TL; DR 팁 :

  • 데이터베이스 볼륨에 대한 RAID 설정을 엉망으로 만들지 마십시오. 이는 구식이며 Exchange의 성능 향상으로 인해 더 이상 필요하지 않습니다. 고 가용성을 위해 DAG를 사용할 때 특히 JBOD는 괜찮습니다.
  • 8 개의 사서함 CPU 코어마다 하나의 Active Directory CPU 코어를 사용합니다.
  • 물리적 사서함 서버에서 하이퍼 스레딩을 사용하지 마십시오.
  • AD 쿼리 기간, 데이터베이스 디스크의 IOPS, 전체 AD 데이터베이스가 RAM에 들어갈 수 있는지 확인과 같은 중요한 메트릭에 대한 성능 모니터를 설정합니다.

메일 라우팅

모든 것이 설치되었습니다. 데이터베이스가 복제 중입니다. 부하가 균형을 이룹니다. 성능이 모니터링되고 있습니다. 이제 실제로 시스템에 메일을주고받는 단계로 넘어갈 때입니다.

허용 도메인 및 이메일 주소 정책

모든 도메인이 메일 흐름> 허용 도메인 아래에 적절한 도메인 유형으로 나열되고 기본 도메인이 올바른지 확인합니다. 이메일 주소 정책을 사용하려는 경우 지금이 정책을 검토하여 올바른 도메인과 사용자 이름 형식을 선택했는지 확인하는 것이 좋습니다. 메일 흐름> 이메일 주소 정책에서 그렇게 할 수 있습니다.

DNS

Office 365와 마찬가지로 메일이 시스템으로 라우팅되거나 클라이언트가 설정을 자동으로 검색하려면 먼저 DNS 항목을 올바르게 설정해야합니다. 특정 구성에 따라 프런트 엔드 또는 에지 전송 서버에 포트 25 인바운드를 허용하도록 방화벽 규칙을 구성해야하므로 온-프레미스 솔루션에서는 조금 더 어렵습니다.

먼저 MTA (Message Transfer Agent)의 IP 주소에 대한 A 레코드를 만들어야합니다. 예를 들어 실습에서는 mail.exampleagency.com을 사용하고 있습니다. A 레코드가 배치되면이를 가리키는 MX 레코드를 만듭니다. DNS 호스팅 제공 업체는 이러한 레코드 생성에 대한 적절한 문서를 가지고 있어야합니다.

자동 검색의 경우 클라이언트 액세스 서버의 IP 주소에 대한 A 레코드를 생성하거나 MTA와 동일한 경우이를 가리키는 CNAME 레코드를 생성해야합니다. 다시 말하지만, 우리의 실험실에 대한 우리의 CNAME 레코드를 사용 그들은 모두 같은 IP 주소를 사용하고 있기 때문에 mail.exampleagency.com에 utodiscover.exampleagency.com 가리키는. 이 레코드는 Outlook 자동 검색에서 찾는 방식이므로 autodiscover.yourdomain.tld 여야합니다.

커넥터

이전 문서에서 다룬 Office 365와 달리 온-프레미스 Exchange는 자동으로 송신 커넥터를 생성하지 않습니다. 이렇게하려면 EAC (Exchange 관리 센터)를 열고 메일 흐름> 송신 커넥터로 이동합니다. 기본 커넥터는 DNS 확인을 통해 인터넷으로 전송됩니다.

Mimecast와 같은 타사 메시징 게이트웨이를 사용하는 경우이를 사용자 지정 커넥터로 구성합니다. 여기에서 다른 MTA에 대한 강제 TLS 연결을 설정할 수도 있습니다. 예를 들어 Bank of America는 공급 업체에 대해 강제 TLS 연결을 요구합니다. 이를 위해 파트너 커넥터를 사용해야합니다.

수신 커넥터를 검토 할 수있는 좋은 기회이기도합니다. 여기에서 최대 수신 메시지 크기 (기본값은 35MB-약 33 % MIME 인코딩 오버 헤드를 고려), 연결 로깅 활성화 여부, 강제 TLS와 같은 보안 설정 및 IP 제한을 설정할 수 있습니다.

클라이언트 액세스

기본 메일 라우팅이 구성되어 있으며 이메일을 보내고받을 수 있습니다. 이제 클라이언트가 실제로 사용할 수 있도록 시스템에 연결해야합니다.

인증서

Office 365에서 Microsoft는 Outlook Autodiscover, Outlook Web App 및 TLS를 통한 SMTP 연결에 자체 네임 스페이스를 사용합니다. 따라서 Microsoft는 자체 인증서를 사용합니다. 온-프레미스 Exchange의 경우 시스템에 대한 신뢰할 수있는 보안 연결을 허용하려면 신뢰할 수있는 CA에서 새 인증서를 구입해야합니다.

다행히 Microsoft는 프로세스를 쉽게 완료 할 수 있도록했습니다. 시작하려면 EAC를 열고 서버> 인증서로 이동합니다. 새 인증서를 추가하고 요청 생성을 선택하십시오. 마법사가 열리고 프로세스를 안내합니다. 각 액세스 유형에 대해 도메인을 선택할 수있는 기회가 제공됩니다. 이 예에서는 주로 모든 것에 webmail.exampleagency.com을 사용했습니다.

마법사를 마치면 인증서 요청 파일을 가져 와서 선호하는 인증 기관 (GoDaddy 사용)에 업로드합니다. 그러면 CER 파일 형식으로 인증서를 받게됩니다. 완료를 클릭하고 CER 파일을 가져 와서 인증서를 가져와 사용자 환경에서 사용할 수 있도록 활성화하십시오.

가상 디렉터리

이제 인증서를 설치 했으므로 Exchange에 어떤 서비스에 사용할 도메인을 알려줄 차례입니다. 서버> 가상 디렉터리로 이동합니다. 여기에서 각각에 대한 외부 액세스를 구성해야합니다. 이 예에서는 webmail.exampleagency.com을 사용하도록 OWA 가상 디렉터리를 구성했습니다.

클라이언트 액세스 배열 및로드 밸런싱과 같은 더 복잡한 주제가 있지만이 기사보다 더 심층적 인 탐색을 위해 남겨 두는 것이 가장 좋습니다. 자세한 내용은 TechNet에서 Microsoft의 Exchange Server 설명서를 참조하십시오.

보안 및 규정 준수

데이터가 퍼블릭 클라우드에 있지 않더라도 보안을 신중하게 고려해야합니다. 우선, Windows Server와 Exchange Server 모두에 정기적 인 업데이트를 적용하고 있는지 확인하세요. 관리자 계정에 대한 동일한 조언도 적용됩니다. 항상 일반 계정과는 별도의 관리자 계정을 사용하십시오.

RSA SecurID와 같은 타사 제품을 통해 일부 형태의 다단계 인증을 활성화하려는 경우가 아니라면 내부 네트워크 또는 VPN으로 제한된 관리 작업에 대한 액세스를 유지해야합니다.

적절한 암호 정책이 있는지 확인하십시오. 이에 대한 지침은 계속 변경되지만 우리는 더 복잡한 암호보다 긴 암호를 사용하는 새로운 아이디어에 부분적입니다. 우리 연구실에서는 사용자에게 90 일마다 만료되는 14 자 암호 (복잡성 요구 사항 제외)가 있어야합니다.

또한 소셜 시큐리티 번호 및 신용 카드 번호와 같은 이메일을 통한 민감한 정보 전송을 제한해야하는지 고려해야합니다. 규정 준수 관리> 데이터 손실 방지에서 이러한 제한을 구성 할 수 있습니다. Microsoft는 빠르게 시작하고 실행하는 데 사용할 수있는 다양한 템플릿을 제공합니다. 이 예에서는 US FTC 템플릿을 사용하여 신용 카드 번호 전송을 제한합니다.

다른 소프트웨어에 대한 생각

지금까지 수행했다면 온-프레미스 Exchange 시스템이 작동하기를 바랍니다. 이제이를 보호하고 백업하고 일반적으로 온라인 상태를 유지해야합니다.

바이러스 백신 솔루션의 경우 시스템 전체의 실시간 바이러스 백신 패키지와 전송중인 메시지를 검사하는 패키지가 모두 필요합니다. Microsoft는 Active Directory 도메인 컨트롤러와 Exchange Server 시스템 모두에 대해 필요한 제외 목록을 제공합니다. Microsoft의 권장 사항을 따르고 바이러스 백신 공급 업체에 의존하여 자동으로 구현하지 마십시오. 나는 너무 많은 바이러스 백신 패키지가 사서함 데이터베이스 로그 파일을 즉시 처리하여 사용자를 대신하여 수행하도록 신뢰하는 것을 보았습니다.

지원하려는 백업 및 복원 방법의 유형도 고려해야합니다. 디스크 또는 테이프에 백업하고 있습니까? 세분화 된 복원이 필요합니까 (보통 가치보다 훨씬 더 많은 리소스 집약적)? 백업은 얼마나 뒤로 이동해야합니까? 자신, 팀 및 고위 경영진에게 물어봐야 할 많은 질문이 있습니다.

기타 제품 고려 사항에는 데이터 손실 방지, 스팸 방지 소프트웨어 및 이메일 보관이 포함됩니다. 어떤 경우에는이 모든 것이 단일 패키지에 포함될 수 있습니다. 그러나 Exchange Server 2013에서 작동하도록 인증되었으며 적절한 공급 업체 지원이 있는지 확인하십시오. Exchange Server 2007 용으로 제작되었으며 전자 메일 전용 지원이 있는지 확인하기 위해 제품을 구입하고 싶지는 않습니다.

마지막 생각들

마지막으로 숙제를하세요. 조직이 데이터 보존, 데이터 손실 방지 또는 데이터 액세스에 대한 특정 법률을 따를 필요가 없는지 확인하십시오. 정기적으로 백업 및 복원을 테스트하십시오. EICAR 테스트 파일을 사용하여 바이러스 백신 소프트웨어가 올바르게 실행되고 있는지 확인합니다. 정기적으로 성능 모니터를 확인하여 DAG를 재조정하거나 도메인 컨트롤러를 추가 할 필요가 없는지 확인합니다. 아, 그리고 한 가지 더 : PowerShell을 사랑하는 법을 배우십시오.

온-프레미스 Exchange Server를 실행하는 것은 단순히 Office 365에 등록하는 것보다 훨씬 복잡하지만 IT 전문가로서 훨씬 더 많은 제어권을 갖고 훨씬 더 보람있는 경험을 얻을 수 있습니다. 이 기사에서는 옵션에 대한 좋은 개요와 온-프레미스 Exchange Server를 구성 할 때 반드시 올바르게해야하는 사항을 설명했습니다. 각 조직은 다르며이 지침은 시나리오에 적합하지 않을 수 있습니다. 그러나 빠른 설정을 원하는 대부분의 중소기업 IT 관리자에게는 충분합니다.

관련 기사

  • PowerShell의 힘 : Exchange 관리자를위한 소개
  • 다운로드 : 빠른 가이드 : Office 365로 이동하는 방법
  • 다운로드 : Microsoft Office 365 vs. Google Apps : 최고의 가이드
  • 제대로해야 할 5 가지 Office 365 관리자 설정
  • Office 365 요구 사항에 맞는 10 가지 타사 도구
  • 피해야 할 10 가지 주요 Office 365 마이그레이션 문제
  • Exchange 서버를 Office 365로 마이그레이션하는 방법