사서함 데이터베이스를 삭제합니다. 대상 포리스트에 사용자 계정 프로비전
준비. 워크스테이션, Outlook 클라이언트, 바이러스 백신의 운영 체제 목록입니다. Exchange 2013 서버용 리소스를 프로비저닝하고 운영 체제를 설치합니다. DNS 레코드를 확인하고 외부 라우터에서 전달 변경 준비 상태를 확인합니다.
설치 Exchange 2010 옆에 있는 Exchange 2013 서버.
설정동시에 두 서버의 협업을 테스트합니다.
스위칭 Exchange 2013의 메일 흐름.
옮기다 Exchange 2013의 사서함.
제거 Exchange 2010 서버의 작동에서.
소개: 모든 Exchange 2010 역할은 동일한 서버에 설치됩니다. 또한 Exchange 2013으로 컴팩트하게 전환해야 합니다.
준비
준비 단계에서는 Exchange 2013 업그레이드를 위해 기업 네트워크의 준비 상태를 확인해야 합니다.
다음과 같은 경우에 가장 좋습니다. 운영 체제워크스테이션에서 - 윈도우 7또는 나중에. Outlook 2007의 Windows XP SP3에서 Exchange 2013이 정상적으로 작동하는 것을 보았지만 XP는 단종되어 믿을 수 없습니다. 클라이언트가 Windows XP에서 작동하는지 확인해야 하는 경우 Exchange 2013을 설치하지 않는 것이 좋습니다. 또는 테스트 환경에서 이 구성에서 작동하도록 하는 안정적인 방법을 찾은 다음 이 벤처로 돌아갑니다. 최후의 수단으로, 이전 운영 체제나 다른 운영 체제를 사용하는 사용자는 항상 OWA를 통해 브라우저를 사용하여 메일에 연결할 수 있습니다.
Outlook 2003 클라이언트는 지원되지 않습니다. 이후 업데이트의 경우 업데이트를 설치하는 것이 좋습니다(WSUS에 제공되므로 승인만 하면 됩니다).
- Outlook 2007용 - KB2687404
- Outlook 2010용 - KB2687623
- Outlook 2013의 경우 - KB2863911(실습에 따르면 SP1의 경우 필요하지 않음)
Outlook이 없다면 Exchange도 필요하지 않을 것입니다.
몇 마디 바이러스 백신에 대해. "웹 컨트롤"이 활성화된 Kaspersky 8은 Outlook을 차단합니다. "웹 컨트롤"을 비활성화하거나 예외를 구성하거나 모든 것을 Kaspersky 버전 10으로 업데이트해야 합니다.
몇 마디 DNS에 대해. 메일 서버에 대한 DNS 설정이 이미 완료되었습니다. 한 번에 기본 MX 레코드가 가리키는 동일한 주소에 외부 CNAME 레코드를 즉시 추가할 수 있습니다. "자동 검색 CNAME 메일"과 같은 것입니다. Outlook 클라이언트가 외부에서 연결하려면 포트 443을 수신해야 하지만 이전과 마찬가지로 IMAP 또는 POP3를 통해 다른 클라이언트를 구성할 수 있습니다.
Exchange 2013을 위한 소규모 조직(사서함 200~300개)의 경우 코어 4~6개, RAM 12GB, HDD: 100~120GB(시스템)를 갖춘 가상 환경에 서버를 할당하는 것이 논리적입니다. 디스크) + 메일 데이터베이스용 디스크. 우리의 경우 Exchange 2010에서는 EDB 데이터베이스 파일이 약 120GB를 차지했습니다. 2013년으로 이적한 후에도 대략 이런 상태였습니다. 우리는 공간을 신경 쓰지 않고 C+D = 120 + 500(성장을 위해)으로 만들었습니다. 사용된 OS는 러시아어(Windows Server 2012 R2)였습니다. 모든 업데이트를 설치하십시오.
중요한! 유효한 인증 기관이 있어야 합니다. 어떤 이유로든 여전히 존재하지 않는다면 이제 올려야 할 때입니다. 게다가 어렵지도 않습니다. Exchange 2013은 인증서 없이 작동하지 않습니다. 그리고 또 다른 미묘한 차이가 있습니다. 표준 Windows 인증 기관(CA)은 하나의 인증서에 여러 이름을 설정하는 기능을 지원하기 위해 약간의 필요가 있습니다. 적어도 Windows 2008 R2에서는 필요했습니다. 아마도 Windows는 그 이후로 현명해졌을 것입니다.
설치
먼저 AD의 백업 복사본을 만듭니다. 그러나 후속 복구 가능성은 매우 의심 스럽습니다. DC의 표준 도구: 시작 - 관리 도구 - Windows Server 백업.
Exchange 2013 설치와 관련된 모든 조작을 편리하게 수행할 수 있도록 한 서버에서 해당 서버(새 Exchange 2013 서버)에 관리 도구를 설치합니다. Windows PowerShell에서:
가져오기 모듈 ServerManager 설치-WindowsFeature RSAT-ADDS 설치-WindowsFeature AS-HTTP-활성화, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, 웹 -관리 콘솔, WAS-프로세스-모델, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http -오류, 웹-Http-로깅, 웹-Http-리디렉션, 웹-Http-추적, 웹-ISAPI-Ext, 웹-ISAPI-필터, 웹-Lgcy-Mgmt-콘솔, 웹-메타베이스, 웹-관리-콘솔 , Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation
(예, 매우 긴 줄입니다. 하지만 모든 것이 간단하고 빠릅니다.)
서버에 설치:
필요한 경우 Exchange 2013 설치 프로그램에서 나머지 사항을 알려줍니다.
사용된 배포판은 MVLS(www.microsoft.com/Licensing/servicecenter)에 게시된 ISO가 아니라 공개적으로 사용 가능한 배포판 - KB2936880이었습니다.
Exchange 2007에서 사용되는 사서함 이동 접근 방식에 대해 설명했습니다. 기본적으로 다음과 같이 작동합니다. 이동-사서함물론 Exchange 관리 콘솔을 사용하여 사서함을 이동할 수도 있습니다. Exchange 2010에서는 Exchange 관리 콘솔과 Exchange 관리 셸을 사용하여 사서함을 이동할 수도 있지만 프로세스에 많은 변경이 있었습니다. 세 부분으로 구성된 이 시리즈에서는 Exchange 2010에서 사서함을 이동하는 방법에 대해 설명하고 새로운 기능에 더 중점을 두겠습니다. 이동요청.
이동 요청
따라서 Exchange 2010에서는 Move-Mailbox 명령을 더 이상 사용할 수 없다는 말로 이 기사를 시작하고 싶습니다. Exchange 2010에서 사서함을 이동하는 전체 접근 방식은 다음과 같은 기능을 중심으로 이루어집니다. 이동 요청. Move-Mailbox 명령은 더 이상 사용되지 않으므로 Exchange 2007 Move-Mailbox 명령을 사용하여 Exchange 2007에서 Exchange 2010으로 사서함을 이동할 수 없다는 결론이 나옵니다. Exchange 2010 제품 이동 요청 기능을 사용해야 합니다.
이동 요청은 Exchange 관리 콘솔이나 Exchange 관리 셸을 사용하여 Exchange 관리자가 만듭니다. 이 문서에서는 단일 포리스트 내에서 사서함을 이동하는 방법에 중점을 둘 것입니다. 이러한 유형의 움직임을 지역 이전 요청. 포리스트 간에 사서함을 이동할 때 이 유형을 호출합니다. 원격 이동 요청. 원격 이동 요청은 MSExchange.org의 향후 문서에서 다루겠습니다.
이동 요청의 일부인 명령은 서비스에 의해 실행됩니다. Microsoft Exchange 사서함 복제 서비스는 클라이언트 액세스 서버 역할에서 실행되는 Exchange 2010의 새로운 서비스입니다. 이 서비스는 그림 1에 나와 있습니다.
그림 1: Microsoft Exchange 사서함 복제 서비스
이동 요청은 사서함 데이터베이스의 시스템 사서함에 특수 시스템 메시지를 배치합니다. Microsoft Exchange 사서함 복제 서비스는 각 사서함 데이터베이스의 시스템 사서함 내용을 검사하여 이동 요청이 포함되어 있는지 확인한 다음 그에 따라 해당 요청을 처리합니다. 이 서비스를 사용하면 사서함을 이동하면 많은 이점이 있습니다. 다음은 이러한 이동 요청으로 해결되는 마이그레이션 프로젝트 중에 일반적으로 접하게 되는 세 가지 주요 영역입니다.
- 이제 사용자가 로그인한 동안에도 사서함을 온라인으로 이동할 수 있습니다. 이 기능은 사서함에서 Exchange 2007 SP2 이상 또는 Exchange 2010을 실행하는 경우에만 사용할 수 있습니다. 그러나 업무 시간 외 시간에 사서함을 이동할 필요가 없도록 도와주기 때문에 전체 사서함 이동 프로세스에 매우 유용한 추가 기능입니다.
- 이제 휴지통에 있는 개체가 프로세스의 일부로 이동할 수 있습니다. 이전 버전의 Exchange에서는 사서함을 이동해도 휴지통 항목이 이동되지 않았기 때문에 사용자는 삭제된 모든 항목을 이동하기 전에 사서함에 다시 복원해야 했습니다. 사용자에게 이 사실을 알리는 것을 잊어버리기 쉬울 수 있으며 경우에 따라 휴지통에서 항목을 복원하려고 시도하는 동안 사서함이 이동된 사용자가 휴지통이 비어 있음을 발견하는 경우도 있습니다.
- 이동 프로세스를 실행하는 컴퓨터에서는 사서함 콘텐츠가 더 이상 처리되지 않습니다. Exchange 2007에서는 Move-Mailbox 명령이나 관련 스크립트가 대상 Exchange 2007 서버가 아닌 관리자 컴퓨터에서 실행되는 경우가 많았습니다. 그러나 이러한 시나리오에서는 사서함의 내용이 다른 컴퓨터에서 이동됩니다. 원본 데이터베이스를 관리자 컴퓨터로, 그런 다음 대상 데이터베이스로. 대상 데이터베이스 서버에서 직접 명령 또는 명령 스크립트를 실행하면 이 시나리오를 피할 수 있습니다. Exchange 2010에서는 클라이언트 액세스 서버에서 실행되는 Microsoft Exchange 사서함 복제 서비스에 의해 사서함 이동이 수행되므로 이러한 상황이 더 이상 발생하지 않습니다.
각 클라이언트 액세스 서버의 Microsoft Exchange 사서함 복제 서비스가 사서함 이동을 처리한다는 내용을 처음 읽었을 때 여러 클라이언트 액세스 서버가 있으면 이동에 어떤 영향을 미칠지 궁금했습니다. 예를 들어 두 클라이언트 액세스 서버가 동시에 동일한 사서함을 이동하려고 합니까? 다행스럽게도 Microsoft는 이러한 상황을 피하기 위해 동일한 Active Directory 사이트에 있는 모든 클라이언트 액세스 서버 간에 공통 메커니즘을 구현했다고 밝혔습니다.
로컬 이동 요청 만들기
이제 이동 요청에 대해 어느 정도 이해했으므로 이 새로운 기능을 사용하여 실제로 사서함을 이동할 수 있는 방법을 살펴보겠습니다. Exchange 관리 콘솔을 사용하여 로컬 이동 요청을 만드는 방법부터 살펴보겠습니다.
- Exchange 관리 콘솔이 로드되면 확장합니다. 수신자 구성콘솔 트리에서. 수신자 구성 노드에서 개체를 선택합니다. 사서함결과 창에 모든 사서함 목록이 표시됩니다.
- 이 시점에서 이동하려는 사서함을 선택해야 합니다. 동시에 이동할 여러 사서함을 선택할 수 있습니다.
- 이동할 사서함을 선택한 후 다음 옵션을 선택하세요. 새로운 로컬 이동 요청"작업 표시줄에서 또는 그림 2에 표시된 것처럼 사서함 개체를 마우스 오른쪽 버튼으로 클릭하고 상황에 맞는 메뉴에서 동일한 옵션을 선택합니다.
그림 2: 새 로컬 이동 요청 생성
- 마법사가 시작됩니다 새 로컬 이동 요청 마법사소개 페이지를 표시합니다. 소개, 그림 3과 같이 이 페이지에는 선택한 사서함과 해당 사서함이 현재 위치한 사서함 데이터베이스를 포함한 중요한 정보가 표시됩니다.
그림 3: 새 로컬 이동 요청 마법사 소개 페이지
- 소개 페이지에서 버튼을 클릭하세요. 검색"사서함 데이터베이스 선택 창이 열립니다. (사서함 데이터베이스 선택), 그림 4와 같이 이 창에는 조직의 모든 서버에서 사용할 수 있는 데이터베이스가 표시됩니다. 내 예에서는 단순히 데이터베이스에서 사서함을 이동하겠습니다. 사서함 데이터베이스 001 V 사서함 데이터베이스 002이름이 지정된 하나의 서버에서 DAG1. 따라서 이 데이터베이스를 선택하고 좋아요.
그림 4: 사서함 데이터베이스 선택 페이지
- 이제 소개 페이지에서 데이터베이스 필드가 대상 데이터베이스의 이름으로 채워져야 합니다. 딸깍 하는 소리 다음.
- 다음으로 이동 옵션 창이 열립니다. (이동 옵션)그림 5와 같습니다. 이전 버전의 Exchange를 사용해 본 적이 있다면 이 창은 익숙할 것입니다. 소스 데이터베이스에 손상된 메시지가 있는 경우 여기에서 손상된 메시지를 처리하는 방법을 지정할 수 있습니다. 여기에는 사서함을 완전히 건너뛰거나 특정 개수의 손상된 메시지를 허용하는 옵션이 있습니다. 여기에는 옳고 그른 설정이 없으며 조직에서 데이터 손실을 어떻게 보는지에 따라 다릅니다. 아래 이미지에서는 사서함을 완전히 건너뛰는 옵션을 선택했습니다. 손상된 물품이 발견된 경우 우편함은 이동되지 않습니다. 그런 다음 ISINTEG와 같은 유틸리티를 사용하여 데이터베이스를 스캔하여 손상을 복구할 수 있는지 확인합니다.
그림 5: 이동 옵션 페이지
- 이동 옵션 페이지에서 적절한 옵션을 선택한 후 더 나아가. 버튼을 클릭하기 전에 구성 요약을 볼 수 있는 마지막 페이지가 표시됩니다. 새로운로컬 이동 요청을 생성합니다.
- 그러면 로컬 이동 요청이 생성되어 클라이언트 액세스 서버로 전송됩니다. 마법사를 닫을 수 있습니다.
PowerShell을 사용하여 이동 요청 만들기
Exchange 관리 셸을 사용하여 로컬 이동 요청을 만들려면 다음 명령을 사용할 수 있습니다. 새로운 이동 요청및 관련 매개변수. 하나의 사서함을 한 데이터베이스에서 다른 데이터베이스로 이동하기 위해 로컬 이동 요청을 만드는 간단한 명령은 다음과 같습니다.
New-MoveRequest "ID neil"TargetDatabase "사서함 데이터베이스 004"
매개변수는 다음과 같습니다. 신원이동할 메일함을 지정하는 데 사용되며 매개변수는 타겟데이터베이스사서함을 이동할 데이터베이스를 지정합니다. 이 명령을 실행하면 그림 6에 표시된 것과 유사한 결과가 생성됩니다.
그림 6: New-MoveRequest 명령
그림 6에서는 열의 일부 정보가 Exchange 관리 셸에서 사용되는 표준 형식으로는 약간 명확하지 않다는 것을 알 수 있습니다. 이 상황을 해결하려면 다음 명령을 통해 New-MoveRequest 명령의 결과를 실행할 수 있습니다. 형식 테이블(아래 예에서는 ft로 단축됨) 또한 매개변수를 사용합니다. "자동 크기그리고 "포장하다, 이 예에 표시된 대로:
New-MoveRequest "ID neil"TargetDatabase "사서함 데이터베이스 004" | ft "자동 크기 -랩
이는 그림 7에 표시된 것과 유사한 결과를 제공하므로 데이터를 훨씬 쉽게 읽을 수 있습니다.
그림 7: 형식화된 New-MoveRequest 명령
여기서는 이 단계에서 발생할 수 있는 오류에 대해서도 언급하고 싶습니다. 이제 동일한 사서함을 다른 데이터베이스로 이동하려고 하면 다음과 같은 오류 메시지가 나타납니다.
사서함(이름)에 연결된 이동 요청이 완료되었습니다. 사서함에 대한 새 이동 요청을 만들기 전에 Remove-MoveRequest cmdlet을 실행하여 완료된 이동 요청을 지웁니다.
이 오류 메시지는 그림 8에 나와 있습니다.
그림 8: New-MoveRequest 오류
오류 메시지에 나와 있듯이 추가 이동 요청을 생성하기 전에 삭제해야 하는 사서함에 대한 전체 이동 요청이 이미 있습니다. 따라서 이는 이동 요청이 완료된 후 즉시 삭제되어야 함을 의미합니다.
메모:사서함 이동에 성공하더라도 이동 요청은 자동으로 삭제되지 않습니다. 이는 이 문서 시리즈의 뒷부분에서 다루게 될 사서함 데이터베이스 삭제에도 영향을 미칩니다. 아래에서도 더 자세히 살펴보겠습니다.
New-MoveRequest 명령에는 이동 요청을 제어하는 데 사용할 수 있는 많은 매개 변수가 포함되어 있습니다. Exchange 2007에 익숙하다면 예상할 수 있듯이 Exchange 관리 셸에는 Exchange 관리 콘솔보다 이동 요청을 제어하는 방법이 더 많습니다. 모든 매개변수의 전체 목록을 찾을 수 있지만 이 문서에서는 가장 중요한 몇 가지 매개변수에 대해 설명합니다.
- BadItemLimit -그림 5에 표시된 것처럼 사서함을 이동할 때 프로그램이 허용할 수 있는 손상된 사서함 항목 수를 결정할 수 있습니다. Exchange 관리 셸에서는 BadItemLimit 매개 변수가 이 설정을 제어합니다.
- 배치 이름 -여러 메일함을 이동할 때 패키지 이름을 지정할 수 있는 유용한 옵션입니다. 그런 다음 명령을 사용할 때 이 패키지 이름을 사용하여 특정 사서함을 검색할 수 있습니다. Get-MoveRequest, 이 시리즈의 세 번째 부분에서 이에 대해 이야기하겠습니다.
- IgnoreRuleLimitErrors -사서함 이동 중에 규칙 제한 오류가 발생하면 사용자 규칙을 사서함의 일부로 이동하지 않는 것이 좋습니다. 이 옵션을 사용하면 이를 수행할 수 있습니다. 예를 들어 이동 요청이 제출된 후 규칙이 처리되지 않도록 해당 요청의 매개변수를 변경할 수 있습니다. 이에 대해서는 시리즈의 세 번째 부분에서도 이야기하겠습니다.
- MRS서버 -일반적으로 이동 요청은 Active Directory 사이트의 단일 클라이언트 액세스 서버에서 처리됩니다. 특정 클라이언트 액세스 서버를 지정하려면 클라이언트 액세스 서버의 FQDN(정규화된 도메인 이름)과 함께 MRSServer 매개 변수를 사용하십시오.
- SuspendWhenReadyToComplete -이 설정은 사서함이 최종적으로 대상 데이터베이스로 이동되기 전에 이동 요청을 일시 중지하는 데 사용됩니다. 즉, 유효한 사서함 데이터는 모두 이동되지만 관리자가 명령을 사용하여 이동을 재개할 때까지 최종 이동은 발생하지 않습니다. 재개-이동 요청. 이 접근 방식을 사용할 수 있는 한 가지 상황은 사서함 이동에 대한 최종 승인을 얻는 것입니다. 이 옵션은 이 기사 시리즈의 세 번째 부분에서 논의됩니다.
대상 데이터베이스 관리
흥미로운 점은 New-MoveRequest 명령의 TargetDatabase 매개 변수가 실제로 선택 사항이라는 것입니다. 이 문서의 시작 부분에 있는 예에서는 사서함이 다음 데이터베이스로 이동되었는지 확인하는 데 이 매개 변수가 사용되었음을 알 수 있습니다. 사서함 데이터베이스 004. TargetDatabase 매개변수를 제외하면 이동 요청 프로세스에서 자동으로 데이터베이스를 선택합니다.
이 선택 프로세스에서 제외하려는 하나 이상의 사서함 데이터베이스가 있는 경우 매개 변수 값을 변경할 수 있습니다. IsExcludedFromProvisioning제외하려는 데이터베이스. 이 매개변수는 그림 9에 표시되어 있으며 기본값으로 표시되어 있습니다. 거짓는 데이터베이스를 사용하여 사서함을 채울 수 있음을 나타냅니다. Mailbox Database 004에 대한 이 매개 변수의 값을 true로 변경하려면 다음 명령을 실행합니다.
Set-MailboxDatabase "사서함 데이터베이스 004" "IsExcludedFromProvisioning $True
그림 9: 이동 요청에서 사서함 데이터베이스 제외
이동 요청 관리
이제 로컬 이동 요청이 생성되었으므로 진행 상황을 추적해야 합니다. Exchange 관리 콘솔에서 개체를 클릭합니다. 이동요청, 노드에 위치 수신자 구성콘솔 트리에서. 그러면 그림 10에 표시된 것과 유사한 창이 나타납니다. 이 그림에서는 명확성을 위해 작업 표시줄을 제거했습니다.
그림 10: 이동 요청 관리
여기서 이동 요청 목록이 표시되는 것을 볼 수 있습니다. 현재 진행 중인 이동 요청은 하나만 있으며 요청 상태 필드는 이동 요청 상태움직임 상태를 보여줍니다 움직이는. 기본적으로 표시 이름, 별칭, 이동 요청 상태 및 이동 요청 유형 필드만 콘솔에 표시됩니다. 귀하에게 제공되는 정보를 확장하는 방법에는 두 가지가 있습니다.
- Exchange 관리 콘솔에서 메뉴를 선택합니다. 보다, 다음 옵션 열 추가 또는 제거(열 추가/제거")창문을 불러오려고 열 추가/제거여기에서는 이름, 원격 호스트 이름, 소스 데이터베이스 및 대상 데이터베이스 필드도 사용할 수 있음을 알 수 있습니다. 화면에서 사용할 수 있는 다양한 버튼을 사용하여 표시할 추가 필드와 표시 순서를 지정할 수 있습니다.
그림 11: 추가 정보 열 추가
- Exchange 관리 콘솔에 정보를 추가하는 또 다른 방법은 이동 요청의 속성을 보는 것입니다. 이렇게 하려면 이동 요청을 마우스 오른쪽 버튼으로 클릭하고 속성상황에 맞는 메뉴에서. 그러면 그림 12에 표시된 것과 유사한 이동 요청 속성 창이 나타납니다.
그림 12: 이동 요청 속성
그림 10과 12에 표시된 가장 흥미로운 필드 중 하나는 상태 필드입니다. 이동 요청 상태. 그림 12에서 상태가 다음과 같이 표시되는 것을 볼 수 있습니다. 완료 중, 그러나 물론 이 필드는 다음과 같은 값을 가질 수도 있습니다. 진행 중, 완전한, 실패한등. 이를 통해 전체 프로세스에서 이동 요청이 어느 단계에 있는지 확인할 수 있습니다.
이동 요청 관리
Exchange 관리 셸에서 다음 명령을 사용하여 이동 요청이 어떻게 진행되고 있는지 확인할 수 있습니다. Get-MoveRequest. 기본 상태에서 Get-MoveRequest 명령은 사용 가능한 모든 이동 요청의 결과를 반환합니다. 예를 들어, Get-MoveRequest 명령에서 반환된 정보의 샘플을 보여 주는 그림 13을 살펴보십시오. 이는 하나의 이동 요청만 표시하며 내 사서함이 TEST라는 대상 데이터베이스로 이동되었음을 보여줍니다. 또한 이동 요청이 완료된 것을 확인할 수 있습니다.
그림 13: Get-MoveRequest 결과
New-MoveRequest 명령과 마찬가지로 이 명령에도 사용할 수 있는 Get-MoveRequest 매개 변수가 많이 있습니다. 전체 옵션 목록을 찾을 수 있습니다. 가장 중요한 몇 가지 매개변수는 다음과 같습니다.
이동상태: 이 매개 변수를 사용하면 Get-MoveRequest 명령의 결과를 사용하여 특정 상태의 이동 요청만 검색할 수 있습니다. 예를 들어 상태와 함께 모든 이동 요청을 확인해야 하는 경우 진행 중, 다음 명령을 사용해야 합니다.
Get-MoveRequest "MoveStatus 진행 중
이러한 명령의 출력 예는 그림 14에 나와 있습니다. 유효한 상태 매개변수는 다음과 같습니다. 없음, 대기 중, 진행 중, 자동 정지, 완료진행중, 완전한, 경고와 함께 완료됨, 정지된그리고 실패한.
소스데이터베이스:이 옵션은 특정 원본 데이터베이스에서 이동된 모든 사서함을 표시하므로 원본 사서함 서버의 부하를 확인하는 데 유용합니다.
SuspendWhenReadyToComplete:이 옵션은 상자가 최종적으로 대상 데이터베이스로 이동되기 전에 이동 요청을 일시 중지하는 데 사용됩니다. 이 매개변수에 대해서는 잠시 후에 이야기하겠습니다.
대상데이터베이스:이 옵션은 대상 데이터베이스를 표시한다는 점을 제외하면 SourceDatabase와 유사합니다.
이동 요청 일시 중단
이 시리즈의 2부와 이전 섹션에서 간략하게 다루었듯이 New-MoveRequest 및 Get-MoveRequest 명령에는 다음이 포함됩니다. 준비가 완료되면 일시중단대상 데이터베이스의 최종 위치가 업데이트되기 전에 이동 요청을 일시 중지하는 데 사용되는 옵션입니다. 이 접근 방식을 사용하면 사서함 데이터가 이동되지만 최종 전환은 일시 중단된 이동 요청이 다시 시작된 후에만 발생합니다. 다음 명령을 사용하여 기존 이동 요청을 일시 중지할 수도 있습니다. 일시 중지 이동 요청.
New-MoveRequest 명령에 SuspendWhenReadyToComplete 매개 변수를 사용하는 방법을 살펴보겠습니다. 실행할 명령의 예는 다음과 같습니다.
New-MoveRequest "ID neil" SuspendWhenReadyToComplete
이 시리즈의 이전 부분을 읽었다면 위 명령에 매개변수가 포함되어 있지 않다는 것을 알 수 있을 것입니다. 타겟데이터베이스상자를 이동할 특정 데이터베이스를 지정합니다. 이 옵션이 없으면 시스템이 데이터베이스를 선택합니다.
이미 말했듯이 사서함 이동 프로세스는 최종 이동이 이루어질 때까지 지연됩니다. 명령을 실행하여 구성할 수 있습니다. Get-MoveRequest. SuspendWhenReadyToComplete 옵션을 사용하여 사서함이 이동되었음을 보여주는 그림 15를 살펴보십시오. 조금 후에 이 이동 요청의 상태는 다음과 같습니다. 진행 중, 사서함의 내용이 이동됩니다. 다음 업데이트 후 Get-MoveRequest 명령은 요청 상태가 다음으로 변경되었음을 표시합니다. 자동 정지이며 SuspendWhenReadyToComplete 매개변수를 사용할 때 표시되는 상태입니다. 마찬가지로 Exchange 관리 콘솔에는 그림 16과 같이 이 상태가 표시됩니다.
그림 15: 일시 중지된 이동 요청 " Exchange 관리 셸
그림 16: 일시 중지된 이동 요청 " Exchange 관리 콘솔
관리자가 이동이 완료될 수 있다고 판단하면 다음 명령을 실행하여 이동 요청을 재개할 수 있습니다. 재개-이동 요청다음 구문을 사용합니다.
Resume-MoveRequest "ID 닐
이 명령이 완료되면 Get-MoveRequest 명령을 다시 실행하면 상태가 표시되어야 합니다. 완전한.
배치 이름
이 시리즈의 이전 부분에서는 New-MoveRequest 명령의 매개변수를 살펴보고 이러한 매개변수 중 하나가 호출되는 것을 확인했습니다. 배치 이름. 이 매개 변수를 사용하면 여러 사서함을 이동할 때 패키지 이름을 지정할 수 있습니다. 그런 다음 이를 Get-MoveRequest 명령과 함께 사용하여 특정 사서함 이동 패키지를 검색할 수 있습니다.
패키지 이름은 한 사서함 데이터베이스의 내용을 다른 사서함 데이터베이스로 이동할 때 매우 유용합니다. 작업을 단순하게 유지하기 위해 동일한 사서함에 대해 두 개의 쿼리를 만들고 각각 다른 패키지 이름을 지정하겠습니다. 그런 다음 Get-MoveRequest 명령을 사용하여 이러한 패키지 이름을 조회하는 방법을 보여 드리겠습니다. 먼저 Exchange 관리 셸을 사용하여 서로 다른 패키지 이름을 지정하는 두 가지 간단한 이동 요청을 만들어 보겠습니다.
New-MoveRequest "ID neil"TargetDatabase "사서함 데이터베이스 003" "BatchName Batch001
New-MoveRequest "ID rob "TargetDatabase "사서함 데이터베이스 004" "BatchName Batch002
이러한 이동 요청을 만든 후 BatchName 매개 변수와 함께 Get-MoveRequest 명령을 사용하여 특정 일괄 처리 이름과 연결된 모든 사서함 이동 요청을 찾을 수 있습니다. 예를 들어 패키지 이름과 관련된 모든 사서함 이동 요청을 보려면 배치001, 다음 명령을 사용해야 합니다.
Get-MoveRequest "배치 이름 Batch001
이 명령의 결과는 그림 17에 나와 있습니다. 두 번째 사서함이 다른 패키지 이름을 사용하여 이동되었기 때문에 두 사서함 중 하나만 반환된 것을 볼 수 있습니다.
그림 17: 패키지 이름으로 필터링
여러 사서함 이동
이 시리즈의 2부에서는 다음 명령을 사용하여 사용자의 사서함을 이동하는 방법을 살펴보았습니다. 새로운 이동 요청. 단일 사서함을 이동하는 것은 해당 사서함의 별칭을 매개 변수에 지정하기만 하면 되기 때문에 간단한 작업입니다. 신원팀 새로운 이동 요청. 여러 개의 사서함을 이동하는 것은 어떻습니까? 이는 여러 가지 방법으로 수행될 수 있으며 그 중 일부는 아래에서 설명됩니다.
첫째, 명령을 전달하기만 하면 모든 사서함을 한 데이터베이스에서 다른 데이터베이스로 이동하는 것이 매우 쉽습니다. Get-MailboxDatabase팀에 새로운 이동 요청. 예를 들면 다음 명령이 있습니다.
Get-Mailbox "데이터베이스 "Mailbox Database 001" | New-MoveRequest "TargetDatabase`
"사서함 데이터베이스 002"
몇 개의 사서함만 이동해야 하는 경우 PowerShell의 배열 기능을 사용할 수 있습니다. Neil, Rob 및 Mark 사용자에게 속한 사서함을 이동해야 한다고 가정해 보겠습니다. 이 예에서 사용자 이름은 사서함 별칭이기도 합니다. 다음 스크립트를 사용하여 이 작업을 수행할 수 있습니다.
$MailboxesToMove = "닐","롭","마크"
ForEach($MailboxesToMove의 $SingleMailbox)(New-MoveRequest "ID $SingleMailbox`
"TargetDatabase "사서함 데이터베이스 002" "BatchName Batch001)
이 시나리오에서는 우리가 처음에 정의한 것을 볼 수 있습니다. $MailboxesToMove이동할 세 개의 사서함 별칭 이름이 포함된 배열로 사용됩니다. 그런 다음 각 사서함 별칭이 명령에 전달됩니다. 새로운 이동 요청원본 사서함 데이터베이스의 위치에 관계없이 처리됩니다.
다음 명령을 사용할 수도 있습니다. 콘텐츠 가져오기, PowerShell에서 사용할 수 있습니다. 먼저 이동하려는 사서함 별칭 목록이 포함된 간단한 텍스트 파일을 만들어야 합니다. 그림 18은 이러한 파일의 예를 보여줍니다. 메일함.txt.
그림 18: 샘플 Mailboxes.txt 파일
그런 다음 Mailboxes.txt 파일에 나열된 사서함을 이동하는 샘플 스크립트는 다음과 같습니다.
$Mailboxes = 콘텐츠 가져오기 ./mailboxes.txt
($Start = 0; $Start -lt $Mailboxes.length; $Start++) (New-MoveRequest "ID `
$Mailboxes[$Start] -TargetDatabase "사서함 데이터베이스 002")
이 시나리오에서는 명령 콘텐츠 가져오기콘텐츠를 가져오는 데 사용됨 메일함.txt파일 및 콘텐츠 할당 $사서함. 그런 다음 콘텐츠를 반복합니다. $사서함각 루프마다 명령이 사용됩니다 새로운 이동 요청.
여러 가지 Exchange 관리 셸 명령을 사용하여 Exchange 2010 사서함을 이동하는 방법은 다양하지만 Microsoft에서는 사서함 이동폴더에서 찾을 수 있는 PowerShell 스크립트 \프로그램 파일\Microsoft\Exchange Server\V14\Scripts Exchange 2010을 설치한 후. 이 스크립트는 단일 Exchange 조직에서 로컬 이동 요청을 실행하며 이동 요청이 완료되는 즉시 삭제된다는 추가 이점이 있습니다. 몇 가지 예제 시나리오를 살펴보기 전에 여기에 사용되는 매개변수를 살펴보겠습니다. 이 스크립트는 이 기사 시리즈에서 이미 논의한 여러 매개변수를 사용하지만 여러 매개변수의 이름은 다릅니다.
첫째로, 자동 일시 중단매개변수와 기능이 동일한 매개변수 준비가 완료되면 일시중단, 명령과 함께 사용됨 새로운 이동 요청그리고 Get-MoveRequest. 또한, 불량항목한도이 매개변수는 MoveMailbox 스크립트와 함께 사용할 수 있습니다. 옵션도 있습니다 사서함데이터베이스그리고 타겟데이터베이스, 소스 및 대상 데이터베이스를 각각 관리합니다. 이 스크립트에서 사용할 주요 매개변수 중 하나는 다음과 같습니다. 데이터베이스지도매개변수. 이는 사서함을 이동해야 하는 위치를 지정할 수 있는 정말 유용한 옵션입니다. 이 매개변수에 대해서는 잠시 후에 자세히 살펴보겠습니다.
지금은 MoveMailbox 스크립트를 사용하여 단일 사서함을 이동하는 간단한 프로세스를 살펴보겠습니다. 사서함을 다음 데이터베이스로 이동하려면 사서함 데이터베이스 002, 다음 매개변수를 사용하여 스크립트를 실행합니다.
./MoveMailbox.ps1 "ID neil "TargetDatabase "사서함 데이터베이스 002"
이 명령을 실행하면 그림 19와 유사한 결과가 생성됩니다. 앞서 말했듯이 이 스크립트의 가장 큰 장점 중 하나는 이동 요청을 자동으로 지운다는 것입니다.
그림 19: MoveMailbox.ps1 명령 스크립트를 사용하여 단일 사서함 이동
MoveMailbox.ps1 데이터베이스 맵
매개변수 데이터베이스지도 MoveMailbox 명령 스크립트는 여러 사서함을 처리하고 해당 사서함을 여러 대상 데이터베이스로 이동하는 데 매우 유용합니다. 명령줄에서 여러 소스/대상 쌍을 지정하면 효율성이 크게 향상됩니다. 이 매개변수를 사용하는 구문은 다음과 같습니다.
DatabaseMap @("원본 데이터베이스"="대상 데이터베이스";"원본 데이터베이스"="대상 데이터베이스")
이 구문에서는 두 개의 소스/대상 매핑이 표시되며 세미콜론으로 구분됩니다. 따라서 데이터베이스 사서함을 이동하려는 예에서 이것을 사용하는 것은 무엇입니까? 사서함 데이터베이스 001데이터베이스에 사서함 데이터베이스 003및 기본 사서함 사서함 데이터베이스 002데이터베이스에 사서함 데이터베이스 004, 다음 DatabaseMap 매개변수 구문을 사용하여 명령을 실행해야 합니다.
DatabaseMap @("사서함 데이터베이스 001"="사서함 데이터베이스 003";"사서함 데이터베이스 002"="사서함 데이터베이스 004")
부서 직원인 사용자가 소유한 모든 사서함을 이동한다고 가정해 보겠습니다. 컨설턴트, 방금 설명한 것과 같은 방식으로 새 사서함 데이터베이스에 추가합니다. 이렇게 하려면 Active Directory의 "부서" 특성이 올바르게 채워졌다고 가정하고 다음 PowerShell 명령을 사용할 수 있습니다.
사용자 가져오기 | Where ($_.Department "eq "Consultants") | Get-Mailbox | ./MoveMailbox.ps1 "DatabaseMap @("Mailbox Database 001"="Mailbox Database 003";"Mailbox Database 002"="Mailbox Database 004")
이 코드는 먼저 Active Directory "부서" 속성이 다음으로 설정된 사용자의 계정에 대한 세부 정보를 얻습니다. 컨설턴트. 이 명령의 결과는 처리를 위해 명령에 제출됩니다. 사서함 가져오기해당 사용자의 사서함에 대한 세부 정보를 얻기 위해. 이러한 사서함 세부 정보는 스크립트에서 처리됩니다. 사서함 이동그에 따라 사서함도 이동됩니다. 그림 20에 표시된 대로 명령은 MoveMailbox 스크립트를 호출하고 이제 스크립트는 이동 프로세스가 완료될 때까지 기다립니다. 이 프로세스가 완료되면 그림 21과 같이 상태 정보가 화면에 표시됩니다. 간단한 테스트 환경에서 이 명령을 실행하면 사서함 하나가 데이터베이스 밖으로 이동되었습니다. 사서함 데이터베이스 001데이터베이스에 사서함 데이터베이스 003, 상자는 데이터베이스에서 가져온 것입니다. 사서함 데이터베이스 002데이터베이스로 이동됨 사서함 데이터베이스 004.
그림 20: 여러 사서함 이동 진행 중
그림 21: 여러 사서함 이동 프로세스가 완료되었습니다.
사서함 복제 서비스 상태
이 기사에서 우리는 이미 서비스에 대해 말했습니다. Microsoft Exchange 사서함 복제전체 이동 요청 프로세스에 매우 중요하므로 이에 따라 이 서비스를 모니터링해야 합니다. msexchange.org의 이전 기사 시리즈에서는 Exchange 2010에 포함된 특정 기능을 테스트하는 데 사용할 수 있는 다양한 Exchange 2007 "테스트" Exchange 관리 셸 명령에 대해 설명했습니다. 테스트-MRSHHealth여기서 MRS는 Mailbox Replication Service의 약어입니다. 특정 클라이언트 액세스 서버의 상태를 확인하려면 간단히 매개변수를 사용하면 됩니다. "신원해당 클라이언트 액세스 서버 이름을 포함합니다. 예:
테스트-MRSHealth "ID DAG1
위 예에서 클라이언트 액세스 서버의 이름은 DAG1입니다. 이 명령의 출력은 그림 22에 표시된 것과 유사합니다.
그림 22: Test-MRSHealth 명령 결과
그림 22에서는 Test-MRSHealth 명령이 메일박스 복제 서비스가 실행 중인지 확인한 다음 RPC가 해당 서비스를 핑하고 마지막으로 메일박스 데이터베이스 큐를 스캔한 후 경과한 시간을 확인하는 것을 볼 수 있습니다.
사서함 데이터베이스 제거
일반적인 관리 업무의 일환으로 기존 Exchange 2010 서버를 서비스 해제하거나 단순히 기존 사서함 데이터베이스를 삭제해야 하는 경우가 있습니다. 이전 부분에서 이동이 완료되더라도 이동 요청이 자동으로 지워지지 않는다는 점을 기억하실 것입니다. MoveMailbox.ps1 스크립트를 사용하는 경우는 예외입니다. 그러나 Exchange 관리 셸 또는 Exchange 관리 콘솔을 사용하여 이동 요청을 수동으로 만든 경우에는 사서함 데이터베이스를 삭제하기 전에 해당 요청을 삭제해야 합니다. 이는 사서함 데이터베이스에 사서함이 포함되어 있지 않지만 여전히 이동 요청이 있는 상황에도 적용됩니다.
기존 이동 요청이 있는 사서함 데이터베이스를 삭제하려고 하면 "이 사서함 데이터베이스는 하나 이상의 이동 요청과 연결되어 있습니다."라는 텍스트로 시작하는 오류 보고서가 표시됩니다. 이 오류는 그림 23에 나와 있습니다. Get-MoveRequest 및 Remove-MoveRequest 명령을 사용하여 기존 이동 요청을 찾아 제거합니다.
그림 23: 데이터베이스 삭제 중 기존 이동 요청
결론
이것으로 Exchange 2010의 로컬 이동 요청에 대한 4부 시리즈를 마칩니다. 모든 명령과 관련 옵션을 다루지는 않았지만 관련 문서에서 이에 대한 정보를 직접 찾을 수 있습니다. 이 기사 시리즈가 Exchange 2010에서 전체 사서함 이동 요청 프로세스가 작동하는 방식에 대한 좋은 기초를 제공했기를 바랍니다.
Neil은 영국의 Microsoft 골드 파트너인 Silverslands(www.silversands.co.uk)의 수석 컨설턴트이며 유럽 전역의 많은 대규모 고객을 위한 애플리케이션 개발, 구현 및 지원을 담당하고 있습니다. 그는 1987년부터 IT 산업에 종사해 왔으며 1995년부터 메시지 전송을 전문으로 했습니다. 그는 Exchange 4.0 작업을 시작했습니다. 그는 또한 Exchange MVP이기도 하며 다양한 Exchange 사용자를 돕고 Exchange에 대한 블로그를 작성하는 데 개인적인 시간을 할애합니다. www.msexchangeblog.com에서 이러한 블로그를 찾을 수 있습니다. Neil에게 연락할 수 있는 주소는 다음과 같습니다.
Exchange 2013 사서함을 한 데이터베이스에서 다른 데이터베이스로 이동하는 것은 EAC(Exchange 관리 센터)를 통해 매우 쉽게 수행할 수 있지만 이 기사에서는 Powershell을 사용하여 전송하는 옵션을 고려할 것입니다. SP1 버전이라 할지라도 웹 인터페이스는 매우 조잡하며 단순히 한 데이터베이스에서 다른 데이터베이스로 상자를 드래그할 때 작업에서 주기적으로 오류가 발생합니다.
내 블로그의 Exchange 2013 설정 및 관리에 대한 자세한 내용은 주제에 대한 주요 기사에서 확인할 수 있습니다.
Exchange 2013 사서함 이동
데이터베이스 간에 상자를 이동하는 요청을 만들려면 cmdlet을 사용하세요. 새로운 이동 요청. 전체 명령의 예는 다음과 같습니다.
C:\Windows\system32> New-MoveRequest -ID " [이메일 보호됨]" -TargetDatabase "대상 데이터베이스 이름" -BatchName "요청 이름을 입력하세요" -BadItemLimit "200"
전송 요청이 완료되었습니다. 그러나 상자의 크기가 크거나 항목 수가 많고 맨 처음에 열에 표시된 작업 진행 상황을 추적하려는 경우에는 어떻게 될까요? 완료율? 작업 진행 상황을 추적하려면 또 다른 cmdlet이 필요하기 때문에 가장 흥미로운 부분은 다음과 같습니다. Get-MoveRequestStatistics.
기사 시작 부분에 있는 명령의 데이터를 기반으로 한 사용 예:
C:\Windows\system32> Get-MoveRequestStatistics -ID [이메일 보호됨]
명령의 출력은 다음과 같습니다.
오른쪽에는 작업 완료율이 표시된 열이 표시됩니다.
매개 변수에 대해서는 별도로 이야기해야합니다. 불량항목한도 cmdlet 새로운 이동 요청: 건너뛸 손상된 요소의 수를 담당합니다. 기본적으로 지정하지 않고 두면 0이 되며, Microsoft에서는 그대로 두는 것을 강력히 권장합니다. 그러나 상자에 손상된 항목이 있으면 쿼리가 실패하고 상자는 동일한 데이터베이스에 유지됩니다. 실제로 한 데이터베이스에서 다른 데이터베이스로 200개의 사서함을 전송할 때(Exchange 2010에서 2013으로 마이그레이션하는 경우) 2010 서버가 실행 중이었음에도 불구하고 최소한 하나의 손상된 요소가 있는 사서함은 2-4개 이하였습니다. 몇 년 동안. 따라서 Exchange를 적절하게 관리하면 요소가 손상되는 경우가 꽤 많다는 결론을 내릴 수 있습니다.
나는 또한 그 가치가 불량항목한도 50개가 넘으면 키를 강제로 지정해야 합니다. 대규모 데이터 손실 수락, 적어도 Technet에서는 그렇게 말하지만 실제로는 항상 요소 수를 200으로 설정했으며 "대량 데이터 손실"에 동의하고 명령 실행을 금지하지 않았는지 아무도 나에게 묻지 않았습니다 (첫 번째 참조 스크린샷, 매개변수 대규모 데이터 손실 수락거기에 나열되어 있지 않습니다).
Exchange 2013의 개념은 관리 센터에 최소한의 기능만 포함한다는 것입니다. 미묘한 매개변수에 액세스하고 종종 일부 기능(예: 오프라인 주소록에 대한 작업, 나중에는 더 많은 작업)에 액세스하려면 Powershell을 단독으로 사용해야 합니다.
입문.
두 개의 AD 포리스트가 있습니다. 각 포리스트는 하나의 도메인으로 구성됩니다. 포리스트1.로컬그리고 숲2.로컬. 사용자 계정은 하나의 포리스트(forest1)에 있습니다. 다른 포리스트(forest2)에는 포리스트1의 사용자 사서함이 포함된 Exchange 2010 SP3 조직이 배포됩니다. 사용자 계정은 미러링되지 않습니다.
일.
Exchange 2010 조직을 포리스트1에 배포하고 사용자 사서함 콘텐츠를 포리스트2에서 포리스트1로 마이그레이션합니다.
인프라에 대한 설명입니다.
숲1
포리스트1.로컬
- 숲1-dc1.forest1.local- 도메인 컨트롤러
- 숲1-cas1.forest1.local
- 숲1-mbx1.forest1.local
- 숲1-tmg1.forest1.local
사용자 명명 원칙은 [이름의 첫 글자][성]입니다. 예를 들어 Ivan Ivanov-iivanov
포레스트2
하나의 도메인으로 구성된 AD 포리스트 - 숲2.로컬
포리스트에는 다음 서버가 배포됩니다.
- 숲2-dc1.forest2.local- 도메인 컨트롤러
- 숲2-cas1.forest2.local- Exchange 2010 SP3 서버(CAS 및 허브)
- 숲2-mbx1.forest2.local- Exchange 2010 SP3 서버(메일박스)
- 숲2-tmg1.forest2.local- 방화벽, 프록시, 역방향(역방향, 역방향 등) 프록시
사용자의 명명 원칙은 [이름].[성]입니다. 예를 들어 Ivan Ivanov - ivan.ivanov
Exchange 조직은 SMTP 도메인을 유지 관리합니다. 포레스트닷컴. 사용자는 Outlook Anywhere, OWA, ActiveSync를 통해 사서함에 액세스할 수 있습니다.
사서함을 전송 중입니다.
네트워크 인프라를 준비합니다.
사서함 마이그레이션 프로세스를 시작하기 전에 몇 가지 전제 조건이 있습니다.
- 두 포리스트(VPN 사이트 간 등) 간의 트래픽 라우팅을 제공합니다.
- 내부 이름의 상호 역참조 구성(영역 전송, 스텁 영역, 조건부 전달 등)
- 두 조직의 Exchange 서버가 서로의 인증서를 신뢰하는지 확인하십시오.
클라이언트 액세스 서버를 준비합니다.
원본 포리스트(예제에서는 Forest2) 또는 대상 포리스트(예제에서는 Forest1)에서 사서함 콘텐츠 전송을 시작할 수 있습니다. 이동 명령이 대상 포리스트에서 시작되면 원본 포리스트에서 해당 옵션을 활성화해야 합니다. 이동 명령이 원본 포리스트에서 시작되면 사서함 복제 서비스 프록시(MRS 프록시)대상 포리스트에서 허용되어야 합니다.
대상 포리스트에서 사서함의 콘텐츠 마이그레이션을 시작할 예정이므로 서버에서 MRS 프록시를 활성화해야 합니다. 숲2-cas1.forest2.local.
Set-WebServicesVirtualDirectory -Identity "Forest2-Cas1\EWS(기본 웹 사이트)" -MRSProxyEnabled $true
Get-WebServicesVirtualDirectory | 설정-WebServicesVirtualDirectory -MRSProxyEnabled $true
대상 포리스트에 사용자 계정을 프로비전합니다.
다음 매개변수를 가진 Semyon Petrov 사용자에게 메일을 전송하겠습니다.
- 두 포리스트의 표시 이름 - Semyon Petrov
- Forest1의 사용자 이름 - spetrov
- Forest2의 사용자 이름 - semen.petrov
- 우편 주소 - [이메일 보호됨]
콘텐츠 마이그레이션을 시작하기 전에 대상 포리스트(forest1)에서 사용자 계정을 준비해야 합니다. 이는 두 단계로 수행됩니다.
첫 번째 단계는 대상 포리스트에 사용자 계정을 프로비전하는 것입니다.
첫 번째 단계는 사서함을 마이그레이션할 대상 포리스트의 모든 사용자를 메일 사용자로 만드는 것입니다.
두 번째 단계는 대상 포리스트에 사용자 계정을 프로비전하는 것입니다.
두 번째 단계에서는 스크립트를 사용하여 필요합니다. 준비-이동요청.ps1, 원본 포리스트에서 일부 사용자 특성을 복사합니다.
준비-이동요청.ps1 -ID ' [이메일 보호됨]’ -RemoteForestDomainController 숲2-dc1.forest2.local -RemoteForestCredential (Get-Credential 숲2\adm) -UseLocalObject
스크립트에 매개변수를 전달합니다. -UseLocalObject. 이 작업을 수행해야 합니다. 대상 포리스트에 메일 사용이 가능한 사용자가 이미 있습니다.
원본 포리스트의 사서함 콘텐츠를 대상 포리스트로 마이그레이션합니다.
cmdlet을 사용하여 콘텐츠가 마이그레이션됩니다. 새로운 이동 요청.
New-MoveRequest -Identity "semen.petrov" -Remote -RemoteHostName Forest2-cas1.forest2.local -RemoteCredential(Get-Credential Forest2\adm) -TargetDeliveryDomain "forest1.local"
현재 사용자에게 무슨 일이 일어나고 있나요?
사서함 콘텐츠가 전송된 후 사용자에게 다음 메시지가 표시됩니다.
Outlook을 다시 시작한 후 사용자는 자신의 포리스트에 있는 Exchange 서버에 연결할 수 있습니다.