먼저 환경에 대한 설명부터 시작하겠습니다.
우리는 하나의 AD 도메인(de***.co.uk)을 가지고 있습니다.
사용자가 속한 부서에 관계없이 모든 사용자는 이메일 주소가 있더라도 도메인 계정(user@de***.co.uk) 또는 (de***\user)를 사용하여 모든 시스템(교환 포함)에서 인증합니다. ~이다[이메일 보호됨](이건 흔한 일이야, 나도 알아)
우리는 한 번에 한 부서씩 Office 365 E3로 점진적으로 전환할 계획입니다. 직원은 300명, 허용되는 이메일 도메인은 47개, 사서함 수는 600개 이상입니다(일부는 로컬에서 pst에 보관될 수 있음). IT 부서에서는 de***s****.co.uk를 소유한 도메인으로 365 E3를 테스트하고 사용자/사서함을 수동으로 설정했습니다.
이제 한 부서를 평가판 365(사용자 20명)로 이동할 준비가 되었지만 온프레미스 AD와 연결하고 싶습니다. 이 사용자 하위 집합은 이메일 주소 도메인 @le************.com을 갖게 됩니다.
제가 수집한 바에 따르면 이것이 제가 수행해야 할 단계라고 믿습니다. (틀린 경우 정정해 주세요.)
- ADFS 설정
- @le*************.com 도메인을 365 계정에 추가하세요 ********(사용자를 어떻게 확보할지는 잘 모르겠습니다)********
- le*************.com의 DNS 레코드가 Office 365를 가리키도록 변경
- 각 사용자 pst를 365 계정으로 가져오시겠습니까, 아니면 다른 방법으로 가져오시겠습니까?
혼란을 일으키는 것은 ADFS 부분입니다. 지금까지 여러 가지 자습서를 읽었습니다(하나는 DC에 ADFS를 설치하라는 것이고 다른 하나는 3개의 새 서버를 설정하라는 것입니다 - 하나는 ADFS 프록시, 하나는 ADFS 서버 및 하나는 DirSync 서버). - 어느 것이 가장 좋나요?
ADFS를 설정하는 동안 IIS에 SSL 인증서를 설치해야 한다고 합니다. 이 인증서는 호스트 이름.de***.co.uk 또는 호스트 이름@le*********.com입니까? 서로 자신의 SSL이 필요한 이메일 도메인을 수락합니까?
온프레미스 교환에 거주하는 다른 사용자가 이 프로세스의 영향을 받습니까?
문안 인사
답변1
귀하가 제공한 정보를 바탕으로 계속 진행할 수 있는 최상의 시나리오는 다음과 같습니다.
사용자 인증: 여기서 작업할 수 있는 모델은 다음과 같이 3가지입니다.
- Office 365 사용자(클라우드 계정): 사용자 관리는 전적으로 클라우드에서 이루어집니다. Office 365 포털을 사용하여 사용자를 생성하고, 비활성화하고, 비밀번호를 재설정하고 모든 설정을 구성할 수 있습니다. 이를 위해 로컬 AD가 필요하지 않습니다. 분명히 Exchange와 로컬 AD가 있으므로 이 옵션은 사용자 환경에서 작동하지 않습니다. 사용자 관리를 AD에서 로컬로 제어하고 싶습니다.
- Office 365와 단방향 동기화를 사용하는 AD 사용자(반연합 계정): 이 모듈을 사용하면 계정을 생성하고 사내 AD 서버에서 전체 사용자 관리를 수행할 수 있습니다. "DirSync" 또는 최신 버전의 "ADD Sync"라는 도구를 설치하여 사용자의 복사본을 생성합니다. 로컬 AD에서 클라우드로, 도구에는 로컬 AD에서 클라우드로 사용자 계정 암호를 동기화하는 옵션도 있습니다. 이를 통해 사용자는 동일한 사용자 자격 증명을 사용하여 도메인의 로컬 리소스와 Office 365에 로그인할 수 있습니다. 세미 SSO 환경에서는 사용자가 Office 365의 리소스에 액세스할 때 사용자 이름과 암호를 제공해야 하며 사용자 인증/확인은 클라우드 측에서 발생합니다. 이 모듈의 요구 사항은 로컬 네트워크의 모든 서버에 앞서 언급한 도구를 설치하는 것입니다. ADFS 또는 ADFS 프록시가 필요하지 않습니다. 구현 및 지원이 가장 쉽기 때문에 이 옵션을 사용해야 합니다.
- Office 365와 양방향 동기화를 사용하는 AD 사용자(완전 통합 계정): 이것은 세 가지 옵션 중 가장 고급 옵션입니다. 이 옵션은 이전 옵션인 "Office 365에 단방향 동기화를 사용하는 AD 사용자"의 모든 설정을 활용하고 로컬 AD에서 강제로 사용자 인증/확인을 수행하는 기능을 추가합니다. ADFS 및 ADFS 프록시 서버를 사용하는 서버의 경우 로컬 네트워크 또는 Azure 하이브리드 네트워크에 ADFS/ADFS 프록시 및 AAD 동기화를 배포해야 합니다. 도메인의 사용자로서 이 옵션을 사용하여 전체 SSO 환경을 얻을 수 있습니다. 사용자 이름과 암호를 제공할 필요 없이 Office 365에 액세스할 수 있습니다. 이 옵션을 설치, 구성 및 지원하는 것은 IT 끔찍한 이야기이므로 이 옵션을 사용하지 않는 것이 좋습니다.
추가 참조를 위해 여기에서 읽어야 할 수많은 정보가 있습니다.https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/
이메일 마이그레이션: 네트워크에 Exchange 2010이 있으므로 이메일을 마이그레이션하는 지원되는 방법은 다음과 같습니다.
- 컷오버 이메일 마이그레이션: Office 365 포털을 사용하여 마이그레이션 일괄 작업을 생성하면 해당 작업은 Exchange 자동 검색을 사용하여 사용자 사서함을 검색하고, 로컬 Exchange 서버의 사용자 사서함에 액세스하고 사서함 콘텐츠를 클라우드에 복사하기 시작합니다. 사용자가 로컬 서버의 사서함을 계속 사용하는 동안 발생합니다. 모든 이메일이 클라우드에 성공적으로 복사되면 마이그레이션 일괄 처리를 중지하고 DNS 레코드를 변경하여 새 이메일/자동 검색이 로컬 네트워크의 메일 서버 대신 클라우드 메일 서버를 가리키도록 합니다. 그러면 사용자를 순서대로 재구성해야 합니다. 새 서버에 액세스하려면 더 이상 사용되지 않으므로 로컬 서버에서 사용자 사서함을 제거할 수 있습니다. 개인적으로 이 옵션을 사용하는 것을 선호합니다.
- 사용자를 대신하여 .pst 파일 대량 내보내기/가져오기: 도구를 사용하여 사용자 사서함을 .pst 파일로 내보내거나, 해당 파일을 디스크에 저장하고 Microsoft로 보내 가져오거나, .pst 파일을 로컬 폴더에 저장한 다음 Office로 가져올 수 있습니다. Office 365의 마이그레이션 마법사를 사용하여 365를 직접 사용하는 경우 메일 상자 크기가 비교적 작지 않은 한 이 옵션을 사용하지 않을 것입니다.
- 사용자에게 .pst 가져오기/내보내기를 수행하도록 요청하세요.: 완벽한 세상에서는 사용자에게 사서함을 .pst 파일로 내보내고, 컴퓨터에 로컬로 파일을 저장하고, 클라우드의 새 사서함과 작동하도록 Outlook을 구성하고, 컴퓨터에서 .pst 파일을 가져오도록 요청할 수 있습니다. 새 사서함을 사용하는 경우에는... 음... 최종 사용자이기 때문에 이 옵션을 어떻게 해서든 피하겠습니다.
이메일 마이그레이션에 대한 추가 정보는 여기에서 확인할 수 있습니다.https://support.office.com/en-us/article/Ways-to- migration-multiple-email-accounts-to-Office-365-0a4913fe-60fb-498f-9155-a86516418842
인증에 옵션 2를 선택하고 이메일에 옵션 1을 선택하면 마이그레이션을 완료하는 데 ADFS나 인증서가 필요하지 않으며 최종 사용자는 컷오버 마이그레이션의 마지막 단계에서만 영향을 받습니다.
도움이 되었기를 바랍니다.
편집하다:
마이그레이션 단계는 쉬울 것입니다. 다음 팁을 따르십시오.
- 모든 허용 도메인을 Office 365 포털에 추가하고 확인합니다.
- Microsoft IDFix 도구를 사용하여 로컬 계정 형식 및 데이터가 Office 365와 호환되는지 확인하세요.
- ADFS 통합 생성(어디에나 설치할 수 있고 하드웨어가 필요하지 않기 때문에 여전히 DirSync를 사용하겠습니다. SSO 자동 로그인 없이도 ADFS와 동일하게 실행되지만 ADFS는 필수인 것 같습니다. 너의 경우)
- 로컬 메일 서버와 Office 365 간에 페더레이션 트러스트를 만듭니다.
- (선택 사항) 더 나은 바이러스 백신/스팸 처리를 위해 먼저 수신 이메일을 클라우드로 리디렉션합니다.
- Office 365로 이동하려는 사용자에게 라이선스를 할당합니다.
- 적절하다고 판단되는 대로 각 부서의 사용자 이동을 시작하세요.
- 모든 사용자 계정이 클라우드로 이동한 후에는 Office 365와 로컬 메일 서버 간의 페더레이션 트러스트를 제거하고 ADFS 또는 DirSync를 유지하십시오. 단, ADFS 또는 DirSync는 항상 있어야 합니다.
- 적합하다고 판단되는 경우 로컬 메일 서버를 제거하고 가상화한 다음 꺼두는 옵션이 있습니다.