열린 구름(Public Cloud), 닫힌 구름(Private Cloud)의 공존, Hybrid Cloud… Office 365와 Exchange Server의 공존

image

2011년 5월 5일 포스팅이었던 열린 구름(Public Cloud), 닫힌 구름(Private Cloud)의 공존, Hybrid Cloud… Office 365 + 액티브 디렉터리, Exchange Server 2010에서 Office 365와 Active Directory를 연동하는 시나리오를 소개해드렸습니다. 그리고 마지막에…

image

Exchange Server 2010 Deployment Assistant에 대한 언급과 함께(그 당시엔 릴리즈되지 않았죠 미소), 사내의 Exchange Server ORG와 Office 365의 Exchange 서비스를 연계하는 시나리오를 소개하겠다고 말씀드렸습니다. 사실 지난 6월 11일에 Exchange Server 2010 시나리오가 포함된 Deployment Assistant가 업데이트되었고, 언 1달이 다되서야 정리 포스팅을 올리네요.

Exchange Server와 Office 365의 공존(Coexistant) 시나리오는 앞선 포스팅에서 소개해드린 SSO(Single Sign On)을 위한 페더레이션 구성(Federation), 그리고 상호 사용자 정보에 대한 동기화를 구성하는 디렉터리 동기화를 완료한 이후에 진행하실 수 있습니다.

자 그럼, 이제 Deployment Assistant을 활용한 공존 시나리오를 구성해보시죠.

image

먼저, https://technet.microsoft.com/en-us/exdeploy2010/default.aspx#Index에 접속하여, 시나리오를 선택합니다.(en-us 부분을 ko-kr로 바꾸면 한글판에 접속할 수 있습니다만, 아직 한글판에는 Exchange Server 2010 관련 내용은 업데이트되지 않았습니다.) 오늘 포스팅은 하이브리드 클라우드에 관련된 공존 시나리오이므로, Coexistence를 선택합니다. 사용중인 Exchange Server의 버전을 선택하고, 시나리오 관련 질문에 대한 답변을 선택합니다.(사서함 접속시 사용 계정, OWA에 대한 접속 URL 일원화, 메일 흐름에 관련된 질문등) 해당 질문의 답변에 따라 관련 시나리오의 구성 가이드가 화면에 나오고, 이를 차례대로 진행하면 됩니다. 본인이 선택한 옵션에 따라 구성이 맞는지 해당 아키텍쳐 그림을 확인해보는 것도 좋습니다. 미소

image

몇가지 주의 사항만 유의하시면 될 것으로 보입니다.

image

먼저 Office 365내 Exchange 서비스에 대한 구성은 Exchange 관리 콘솔(EMC), 혹은 원격 PowerShell을 이용해서 적용합니다. EMC의 경우, Office 365에 대한 관리 추가는 구성 시나리오내 Configure management interfaces의 How do I configure the EMC 항목을 참고하시면 되고, 이때 사용하는 계정은 Office 365 관리자 계정을 이용하면 됩니다.

원격 PowerShell에 대한 부분은 도움말이 약간 잘못(?) 되어져 있습니다. 큰 틀의 형태는 맞습니다만, Exchange Cmdlet을 로컬 Exchange에 내리는 것인지, 원격 Office 365에 내리는 것인지에 대한 구분을 명시해놓지 않아서, 혼돈하기 좋게 되어져 있네요.(조금 아쉬운 부분이라, 본사 팀으로 건의를 한 상태입니다.)

image

해당 항목의 내용을 보면, PowerShell에서 먼저 접속 계정에 대한 정보를 변수에 넣은 후, 관련 사항을 이용하여 세션을 연결하고, 로컬 cmdlet을 불러오는 절차로 되어져 있는데, 큰 틀은 맞습니다. 다만 마지막 Import-PSSession $session에 한가지 속성을 추가하시면 편리합니다. 바로 ?Prefix입니다.

image

Import-PSSession $session ?Prefix Koalra 이런식으로 명령을 내리시면 로컬 Exchange에 대한 cmdlet, 원격 Office 365에 대한 cmdlet을 구분하실 수 있습니다. 예를 들어 사서함을 불러오는 cmdlet은 get-mailbox입니다만, Office 365내 사서함을 불러오는 cmdlet은 get-koalramailbox가 되게 됩니다. 바로 동사-(Prefix)명사 형태가 되는 것이죠.

image

두번째 주의사항은 바로 구성 시나리오에 대한 이해입니다. 내용을 쭉 보다보면,

image

위의 그림과 같이, On-Premises에 관련된 설정, Cloud-Based에 대한 설정으로 나눠집니다. 이 경우, On-Premises는 EMC를 사용하는 구성에선 상단부의 로컬 Exchange 설정이나 그냥 일반적인 Exchange Cmdlet.. Cloud-Based에 대한 설정은 EMC 하단의 Office 365 설정 부분이나 원격 PowerShell Cmdlet(앞서 언급한 Prefix를 추가한)을 사용해야 합니다.

image

위 그림의 예제에서 설명은 New-RemoteDomain이라는 cmdlet을 사용하지만, 실제 명령어를 내릴 때는, New-KoalraRemoteDomain과 같이 Prefix를 추가해야 한다는 의미입니다. 이해가 되셨죠? 저도 처음에 이를 잘못 이해해서 모든 설정을 로컬 Exchange에 내려서, 난리가 났던 경험이 있습니다. ㅜㅜ

image

Exchange Server의 송, 수신 커넥터에 대한 지식이 좀 있으시다면 MX 레코드에 대한 명시, 그리고 Office 365의 ForeFront Online Protection for Exchange(FOPE), 마지막으로 로컬 Exchange의 Hub Transport, Edge를 설정 변경하여 원하는 형태의 메일 흐름을 구성할 수 있습니다.

image

구성이 완료되면, 기존에 안보이던 여러 설정이 보입니다. 대표적으로 계정은 로컬 액티브 디렉터리, 사서함은 Office 365에 배치하는 원격 사용자 사서함을 생성할 수 있기도 하며, 로컬 사서함을 Exchange Mailbox Replication Service 프록시 서버를 통해 클라우드 기반으로 이동시킬 수 있습니다. OWA는 당연히 어느쪽에 위치하던 해당 위치로 리디렉션되는 것이고요.

image

다른 SaaS(Software as a Service)와 다르게 Microsoft의 클라우드 서비스는 조직내 인프라(On-Premises)와 연결할 수 있는 하이브리드 시나리오를 제공합니다. 비즈니스 시나리오에 따라 특정 위치에 배치를 하고, 필요시 상호 이동이 가능한 유연성은 여타 클라우드 서비스들에 비해 강점으로 자리잡을 수 있다고 생각합니다.