test

Sun Java System Messaging Server 6 2005Q4 관리 설명서

사용자 메일함 마이그레이션

이 절에서는 Messaging Server의 사용자 메일함을 다른 Messaging Server로 마이그레이션하는 방법을 설명합니다. 이 절에서는 Messaging Server 5.2를 Messaging Server 6 2005Q4 시스템으로 마이그레이션하는 방법을 중점적으로 설명하지만 모든 5.2 이후 버전의 Messaging Server에 온라인 마이그레이션 프로세스를 적용할 수 있습니다. 온라인 마이그레이션이 가장 편리하지만 대체 마이그레이션 방법에 대해서도 설명합니다.

Messaging Server 5.2를 Messaging Server 6으로 업그레이드하고 전체 메일 저장소 데이터베이스를 업그레이드할 경우 이러한 마이그레이션 절차를 수행할 필요가 없습니다. 이전 절에서 설명한 make_mboxlistdb_changes.sh 스크립트를 사용하여 데이터베이스를 보다 효율적으로 업그레이드할 수 있습니다.

다음 경우에만 이러한 절차를 수행합니다.

이러한 절차를 사용하여 메일함을 마이그레이션할 경우 분할 영역 경로를 Messaging Server 5.2 분할 영역에 매핑하지 마십시오. 또한, make_mboxlist_changes.sh 스크립트를 실행하지 마십시오.

업그레이드 스크립트에 의해 생성된 make_configutil_changes.sh 스크립트는 자동으로 분할 영역 경로를 설정하여 Messaging Server 5.2 분할 영역으로 매핑합니다. 이 작업은 수동으로 변경해야 합니다. 또한, make_mboxlistdb_changes.sh 스크립트 호출을 do_the_upgrade.sh 스크립트에서 제거해야 합니다.

온라인을 통해 Messaging Server 5.2의 사용자 메일함 데이터를 현재 버전의 Messaging Server로 이동하려면 이 절에서 설명하는 단계를 수행하십시오. 데이터를 이동할 때 Messaging Server를 종료하면 안 됩니다.

이 절에서는 다음 항목에 대해 설명합니다.

온라인 상태에서 다른 Messaging Server로 사용자 메일함 마이그레이션

이 절차를 사용하여 메일 저장소를 이전 버전 Messaging Server에서 최신 버전으로 마이그레이션하거나 메일함을 하나의 Sun Messaging Server 메일 저장소에서 다른 메일 저장소로 이동할 수 있습니다. 이 절차는 iPlanet Messaging Server 5.0 이상 버전에 적용됩니다. 이 절차를 사용하여 이전 버전 Messaging Server나 Sun Microsystems가 아닌 메일 저장소에서 메일을 이동할 수는 없습니다.

이 절차로 메일함을 이동할 경우의 장점은 다음과 같습니다.

이 절차로 메일함을 이동할 경우의 단점은 다음과 같습니다.

증분 메일함 마이그레이션

증분 마이그레이션을 사용하면 메일 저장소를 다른 시스템으로 안전하고 효과적으로 이동하거나 새 시스템으로 업그레이드할 수 있는 많은 이점이 있을 뿐만 아니라, 이전 백엔드 메일 저장소는 그대로 두고 새 백엔드 메일 저장소 시스템을 작성할 수 있습니다. 새 시스템을 테스트하고, 일부 친숙한 사용자를 마이그레이션한 다음 새 시스템을 다시 테스트할 수 있습니다. 새 시스템과 구성 및 마이그레이션 절차에 익숙해지면 실제 상용 사용자 마이그레이션을 시작할 수 있습니다. 이러한 사용자를 별개의 백업 그룹으로 분할하여 마이그레이션 중에 이 그룹의 구성원만이 잠시 동안만 오프라인 상태로 전환되도록 할 수 있습니다.

온라인 증분 마이그레이션의 또 다른 장점으로 업그레이드에 실패할 경우 시스템 차원 백오프를 계획할 필요가 없습니다. 백오프는 시스템에 대한 변경 내용을 되돌려 시스템을 원래의 작업 상태로 되돌리는 절차입니다. 마이그레이션을 수행하는 경우 실패에 대비해야 합니다. 즉, 마이그레이션의 모든 단계에서 시스템을 이전 작업 상태로 되돌릴 계획을 세워야 합니다.

오프라인 마이그레이션은 모든 마이그레이션 단계를 완료하고 서비스를 다시 켤 때까지 마이그레이션의 성공을 확인할 수 없다는 단점이 있습니다. 시스템이 작동하지 않고 빨리 수정될 수 없는 경우 수행한 모든 단계에 대해 백오프 절차를 수행해야 합니다. 이 작업은 어렵고 많은 시간이 소요될 수 있으며, 작업이 수행되는 동안 사용자가 오프라인 상태로 유지됩니다.

온라인 증분 마이그레이션에서는 다음과 같은 기본 단계를 수행합니다.

1. 두 시스템이 독립적으로 작동하도록 이전 시스템은 그대로 두고 새 시스템을 구성합니다.

2. 새 시스템과 함께 사용할 수 있도록 이전 시스템을 구성합니다.

3. 친숙한 사용자 그룹을 마이그레이션하고 새 시스템을 테스트한 후 이전 시스템과 새 시스템을 함께 사용할 수 있는지 테스트합니다.

4. 이전 시스템의 사용자를 그룹으로 분류하고 원하는 대로 각 그룹을 새 그룹으로 마이그레이션합니다.

5. 이전 시스템을 역어셈블합니다.

두 시스템이 공존하기 때문에 새 시스템으로 마이그레이션하기 전에 새 시스템을 테스트하고 익숙해질 시간적 여유를 가질 수 있습니다. 바람직하지는 않지만 백오프 절차를 수행해야 하는 경우 단계 2와 단계 4에 대해서만 계획해야 합니다. 단계 2는 사용자 데이터에 연결하지 않기 때문에 쉽게 되돌릴 수 있습니다. 단계 4에서 백오프는 사용자를 다시 활성 상태로 되돌리고 사용자의 mailhost 속성을 다시 이전 호스트로 반전시킵니다. 시스템 차원 백오프가 필요하지 않습니다.

온라인 마이그레이션 개요

온라인 상태에서 메일함을 마이그레이션하는 프로세스는 간단합니다. MTA 채널 대기열에서 전달되기를 기다리며 대기하는 메일이 메일함으로 전송되는 동안 마이그레이션 과정에서 손실되지 않게 하려는 경우에는 더 복잡해집니다. 한 가지 해결책은 마이그레이션 프로세스 중에 전송된 메일을 보관 상태로 보관하고 다양한 채널 대기열에서 메일 전달을 대기하는 것입니다. 그러나, 시스템 문제가 발생하거나 특정 사용자가 할당량을 초과할 경우 메일이 대기열에 고착될 수 있습니다. 그럴 경우 메일함을 마이그레이션하기 전에 해당 문제를 해결해야 합니다.

메시지 손실 가능성을 줄이고 메시지가 채널 대기열에 고착되지 않도록 다양한 방법을 수행할 수 있지만 이 경우 절차가 더 복잡해집니다.

절차에서 단계의 순서와 필요성은 배포에 따라 다르며, 모든 메일함에 전달된 모든 메일이 손실되지 않아야 하는지 여부에 따라서도 다릅니다. 이 절에서는 단계에 담겨 있는 이론과 개념에 대해 설명합니다. 특정 배포가 주어지면 각 단계를 이해하고 수행할 단계 및 순서를 결정해야 합니다. 다음은 메일함 이동 프로세스의 개요입니다. 이 프로세스는 배포에 따라 다를 수 있습니다.

  1. 이동 중인 메일함에 대한 사용자 액세스를 차단합니다.

  2. 이동 중인 메일함으로 주소가 지정된 메일을 임시로 보관합니다.

  3. 메일이 채널 대기열에 고착되지 않았는지 확인합니다.

  4. 사용자의 mailhost 속성을 새 메일함 위치로 변경합니다.

  5. 메일함을 새 위치로 이동합니다.

  6. 보관된 메일을 해제하여 새 메일함으로 전달하고 받는 메일을 마이그레이션된 메일함으로 전달합니다.

  7. 이전 메일 저장소를 검사하여 마이그레이션 후에 전달된 메일이 있는지 확인합니다.

Procedure온라인 상태에서 사용자 메일함을 다른 Messaging Server로 마이그레이션하는 방법

시작하기 전에

이 마이그레이션 유형의 요구 사항은 다음과 같습니다.

주 –

일부 단계는 메시징 서버를 이전 버전에서 이후 버전으로 업그레이드한 경우에만 적용됩니다. 이 단계는 메일함을 한 메일 저장소에서 다른 메일 저장소로 마이그레이션하는 경우에는 적용되지 않을 수 있습니다. 전체 시스템을 마이그레이션하는 데 적용되는 단계가 명시됩니다.

단계

  1. 소스 시스템에서 backup-groups.conf 파일을 사용하여 이동할 사용자 항목을 동일한 백업 그룹 수로 분할합니다.

    이 단계는 이 절차의 뒤에 나오는 메일함 마이그레이션 단계 8의 준비 과정입니다. 자세한 내용은 백업 그룹 만들기를 참조하십시오.

    파일에 사용자 이름을 넣고 imsbackup 명령에 -u 옵션을 사용할 수도 있습니다.

  2. 이동할 사용자에게 이동 프로세스가 완료될 때까지 메일함에 액세스할 수 없다는 사실을 알립니다.

    데이터 이동을 수행하기 전에 사용자들이 메일 시스템에서 로그아웃하도록 합니다. ( 사용자 액세스 모니터링 참조)

  3. 백엔드 메일 저장소 및 MMP 시스템에서 인증 캐시 시간 초과 값을 0으로 설정하고 MTA에서 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 0으로 설정합니다.

    1. 이동할 메일함이 포함된 백엔드 메일 저장소에서 인증 캐시 시간 초과 값을 0으로 설정합니다.


      configutil -o service.authcachettl -v 0

      이 단계와 단계 7(mailUserStatus를 hold로 변경)에서는 마이그레이션하는 동안 사용자가 메일함에 액세스하지 못하도록 즉시 조치합니다.

    2. 모든 MMP에서 인증 캐시 시간 초과 값을 0으로 설정합니다.

      ImpProxyAService.cfg 및 PopProxyAService.cfg에서 LdapCacheTTL을 0으로 설정합니다.

    3. 마이그레이션할 메일함에 메일을 삽입하는 MTA를 호스트하는 모든 Messaging Server에서 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 0으로 설정합니다.

      마이그레이션하는 메일함에 메일을 삽입하는 MTA를 호스트하는 Messaging Server가 일반적으로 백엔드 메일 저장소가 됩니다. 그러나, LMTP를 사용하는 시스템은 인바운드 MTA가 됩니다. 구성을 확인합니다.

      /msg_svr_base/config/option.dat에서 ALIAS_ENTRY_CACHE_TIMEOUT을 재설정하면 MTA가 캐시를 건너뛰고 LDAP 항목을 직접 조회하여 중간 채널 대기열(예: conversion 또는 reprocess 채널)에 캐시된 이전 정보 대신 이동 중인 사용자의 새 mailUserStatus(hold)가 표시되도록 합니다. ALIAS_ENTRY_CACHE_TIMEOUT은 option.dat에 있습니다.

    4. 캐시를 재설정한 시스템을 다시 시작합니다.

      변경 사항을 적용하려면 시스템을 다시 시작해야 합니다. 자세한 내용은 서비스 시작 및 중지를 참조하십시오.

  4. 소스 Messaging Server와 대상 Messaging Server가 모두 시작되고 실행 중인지 확인합니다.

    소스 Messaging Server는 받는 메일을 새 대상 서버로 라우팅할 수 있어야 합니다.

  5. 메일함을 이동할 모든 사용자 항목의 LDAP 속성 mailUserStatus를 active에서 hold로 변경합니다.

    속성을 변경하면 받는 메일이 hold 대기열에 보관되고 IMAP, POP 및 HTTP를 통한 메일함 액세스가 금지됩니다. 일반적으로 사용자는 사용자 그룹으로 이동됩니다. 단일 도메인의 모든 메일함을 이동할 경우 mailDomainStatus 속성을 사용할 수 있습니다.

    mailUserStatus에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Schema Reference의 mailUserStatus를 참조하십시오.

  6. 이동 중인 메일함에 전달되는 메일이 ims-ms 또는 tcp_lmtp*(LMTP가 배포된 경우) 채널 대기열에 고착되지 않는지 확인합니다.

    다음 명령을 사용하여 메일이 채널 대기열 디렉토리 트리에 있는지 및 마이그레이션할 사용자에게 전달되는 held 상태(.HELD 파일 표시)인지를 확인합니다.


    imsimta qm directory -to=<user_address_to_be_migrated> -directory_tree

imsimta qm directory -to=<user_address_to_be_migrated> -held -directory_tree

    메일이 대기열에 있는 경우 나중에 이 명령을 다시 실행하여 MTA가 메일을 대기열에서 제거했는지 확인합니다. 대기열에서 제거되지 않는 메일이 있는 경우 마이그레이션하기 전에 이 문제를 해결해야 합니다. 이런 경우가 드물기는 하지만 가능한 원인으로는 수신자 메일함의 할당량이 초과된 경우, 사용자가 로그인한 상태에서 메일을 이동하여 메일함이 잠긴 경우, LMTP 백엔드 서버가 응답하지 않는 경우 및 네트워크 또는 이름 서버 문제 등이 있습니다.

  7. 이동할 사용자 항목과 모든 메일 그룹 항목에서 LDAP 속성 mailHost를 변경합니다*.

    ldapmodify 명령을 사용하여 항목을 새 메일 서버로 변경합니다. Messaging Server 또는 Directory Server와 함께 제공된 ldapmodify를 사용합니다. Solaris OS ldapmodify 명령을 사용하지 마십시오.

    * 이전 메일 호스트가 종료된 경우 메일 그룹 항목에서 mailHost 속성을 변경하기만 하면 됩니다. 이 속성을 새 메일 호스트 이름으로 변경하거나 속성을 함께 제거할 수 있습니다. 메일 그룹은 mailHost 속성을 선택적으로 가질 수 있습니다. mailHost가 있으면 해당 호스트만 그룹 확장을 수행할 수 있고, mailHost가 없으면(보다 일반적인 경우) 모든 MTA가 그룹 확장을 수행할 수 있습니다. 메일 그룹 항목에는 마이그레이션할 메일함이 없고 일반적으로 mailhost 속성이 없습니다.

    mailhost에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Schema Reference의 mailHost를 참조하십시오.

  8. 메일함 데이터를 소스 Messaging Server 메일 저장소에서 대상 Messaging Server 메일 저장소로 이동하고 시작된 시간을 기록합니다.

    imsbackup 유틸리티를 사용하여 메일함을 백업하고 imsrestore 유틸리티를 사용하여 새 Messaging Server에 복원합니다. 예를 들어, oldmail.siroe.com이라는 Messaging Server 5.2 시스템의 메일함을 newmail.siroe.com으로 마이그레이션하려면 oldmail.siroe.com에서 다음 명령을 실행합니다.


    /server-root/bin/msg/store/bin/imsbackup -f- /instance/group     \
| rsh newmail.siroe.com /opt/SUNWmsgsr/lib/msg/imsrestore.sh   \
-f- -cy -v1

    여러 백업 및 복원 세션(그룹마다 하나씩)을 동시에 실행하여 새 메일 저장소로의 전송 속도를 최대화할 수 있습니다. imsbackup 및 imsrestore 유틸리티에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 Command Descriptions와 메일 저장소 백업 및 복원를 참조하십시오.

    주 –

    나중에 전달 확인을 위해 imsbackup이 실행된 시간의 타임스탬프를 기록합니다.

  9. (시스템 업그레이드를 위한 조건부 단계) 메일함 마이그레이션이 이전 버전 Messaging Server를 현재 버전으로 업그레이드하는 과정에 포함되는 경우 이 현재 버전 Messaging Server를 시스템의 새 기본 Messaging Server로 설정합니다.

    oldmail.siroe.com의 DNS A 레코드를 변경하여 newmail.siroe.com(이전에 oldmail.siroe.com에서 호스트되던 도메인을 담당하는 서버)을 가리키도록 합니다.

  10. 새 메일 저장소에 대한 사용자 액세스를 활성화합니다.

    LDAP 속성 mailUserStatus 또는 mailDomainStatus(해당되는 경우)를 hold로 변경되기 이전의 값(예: active)으로 설정합니다.

  11. 모든 소스 Messaging Servers에서 held 상태인 메일을 해제합니다.

    받는 메일을 보관 중인 모든 시스템에서 다음 명령을 실행하여 모든 사용자 메일을 해제해야 합니다.


    imsimta qm release -channel=hold -scope

    여기서 scope는 all(모든 메일 해제), user(사용자 아이디) 또는 domain(사용자가 위치한 도메인)입니다.

  12. 인증 캐시 시간 초과 및 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 기본값이나 원하는 값으로 재설정하고 시스템을 다시 시작합니다.

    이제 마이그레이션해야 할 모든 사용자 메일을 마이그레이션했습니다. 계속하기 전에 이전 시스템에서 LDAP에 mailhost로 작성된 새 항목이 있는지 확인하고 있을 경우 해당 항목을 마이그레이션합니다. 또한, 준비 시스템을 수정하여 그런 항목이 만들어지지 않는지 확인합니다.

    preferredmailhost 속성을 새 메일 호스트의 이름으로 변경할 수도 있습니다.

    백엔드 메일 저장소의 경우 인증 캐시 시간 초과를 다음과 같이 설정합니다.


    configutil -o service.authcachettl -v 900

    MMP의 경우 ImpProxyAService.cfg 및 PopProxyAService.cfg에서 LdapCacheTTL 옵션을 0으로 설정합니다.

    MTA의 경우 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 600으로 설정합니다. ALIAS_ENTRY_CACHE_TIMEOUT은 option.dat에 있습니다.

    변경 사항을 적용하려면 시스템을 다시 시작해야 합니다. 자세한 내용은 서비스 시작 및 중지를 참조하십시오.

  13. 사용자 클라이언트가 새 메일 서버를 가리키는지 확인합니다.

    업그레이드가 끝나면 사용자가 메일 클라이언트 프로그램을 통해 새 서버를 가리키도록 합니다. 이 예에서는 사용자가 oldmail.siroe.com에서 newmail.siroe.com을 가리킵니다.

    그 대안은 사용자가 클라이언트에게 새 메일 서버를 직접 가리킬 필요가 없도록 Messaging Multiplexor(MMP)를 사용하는 것입니다. MMP는 LDAP 사용자 항목에 저장되는 mailHost 속성에서 해당 정보를 가져오고 클라이언트를 새 서버로 자동으로 리디렉션합니다.

  14. 모든 작업이 완료되면 마이그레이션 후에 이전 메일 저장소에 전달된 메일이 없는지 확인합니다.

    이전 메일 저장소로 이동하여 mboxutil -l를 실행하여 메일함을 나열합니다. 마지막 메일 전달 타임스탬프를 확인합니다. 마이그레이션 타임스탬프(imsbackup 명령을 실행한 날짜) 이후에 전달된 메일이 있는 경우 backup 및 restore 명령을 사용하여 해당 메일을 마이그레이션합니다. 제공된 준비 단계로 인해 마이그레이션 후에 전달된 메일을 확인하는 것은 매우 드문 경우입니다.

    이론적으로, 메일은 notices 채널 키워드에 지정된 날짜 또는 시간 동안 대기열에 고착될 수 있습니다( 알림 메일 전달 간격 설정 참조).

  15. relinker 명령을 실행하여 새 메일 저장소에서 중복 메일을 제거합니다.

    이 명령은 새 메일 저장소에서 디스크 공간을 비울 수 있습니다. 동일한 메일의 중복 저장에 따른 저장소 크기 줄이기를 참조하십시오.

  16. 마이그레이션한 소스 저장소에서 이전 메일을 제거하고 이전 저장소의 데이터베이스에서 사용자를 삭제합니다.

    mboxutil -d 명령을 실행합니다. ( mboxutil 유틸리티 참조)

ProcedureIMAP 클라이언트를 사용하여 메일함을 이동하는 방법

메일을 다른 Messaging Server로 마이그레이션해야 하는 경우 언제든지 이 절차를 사용할 수 있습니다. 이 방법으로 메일함을 이동하기 전에 장점과 단점을 고려하십시오.

IMAP 클라이언트를 사용하여 메일함을 이동할 경우의 장점은 다음과 같습니다.

IMAP 클라이언트를 사용하여 메일함을 이동할 경우의 단점은 다음과 같습니다.

단계

  1. 새 Messaging Server를 설치하고 구성합니다.

  2. local.store.relinker를 enable로 설정합니다.

    이렇게 하면 동일한 메일의 중복 저장으로 인한 새 시스템의 메일 저장소 크기가 줄어듭니다. 자세한 내용은 동일한 메일의 중복 저장에 따른 저장소 크기 줄이기를 참조하십시오.

  3. 새 Messaging Server에서 사용자를 준비합니다.

    Delegated Administrator를 사용하여 이 작업을 수행할 수 있습니다. 새 시스템에서 사용자가 준비되면 새로 도착하는 메일이 새 INBOX로 전달됩니다.

  4. 사용자가 메일 클라이언트에서 새 Messaging Server 메일함과 이전 메일함을 모두 표시하도록 구성하게 합니다.

    여기에는 클라이언트에서 새 전자 메일 계정을 설정하는 작업이 포함될 수 있습니다. 자세한 내용은 메일 클라이언트 설명서를 참조하십시오.

  5. 사용자에게 이전 Messaging Server의 폴더를 새 Messaging Server로 끌어다 놓도록 지시합니다.

  6. 모든 메일함이 새 시스템으로 마이그레이션되었는지 사용자에게 확인한 다음 이전 시스템에서 사용자 계정을 종료합니다.

Proceduremoveuser 명령을 사용하여 메일함을 이동하는 방법

메일을 다른 Messaging Server로 마이그레이션해야 하는 경우 언제든지 이 절차를 사용할 수 있습니다. 이 절차는 Sun Messaging Server가 아닌 시스템의 IMAP 메일함을 Sun Java System Messaging Server로 마이그레이션하는 데 유용합니다. 이 방법으로 메일함을 이동하기 전에 장점과 단점을 고려하십시오.

moveuser 명령을 사용하여 메일함을 이동할 경우의 장점은 다음과 같습니다.

moveuser 명령을 사용하여 메일함을 이동할 경우의 단점은 다음과 같습니다.

단계

  1. 새 Messaging Server를 설치하고 구성합니다.

  2. local.store.relinker를 enable로 설정합니다.

    이렇게 하면 동일한 메일의 중복 저장으로 인한 새 시스템의 메일 저장소 크기가 줄어듭니다. 자세한 내용은 동일한 메일의 중복 저장에 따른 저장소 크기 줄이기를 참조하십시오.

  3. Messaging Server로 받는 메일을 중지합니다.

    사용자 속성 mailUserStatus를 hold로 설정합니다.

  4. 필요한 경우 새 Messaging Server에서 사용자를 준비합니다.

    이전 버전의 Messaging Server에서 마이그레이션하는 경우 동일한 LDAP 디렉토리와 서버를 사용할 수 있습니다. moveuser는 각 사용자 항목에서 mailhost 속성을 변경합니다.

  5. moveuser 명령을 실행합니다.

    Directory Server siroe.com의 계정 정보를 기반으로, host1의 모든 사용자를 host2로 이동합니다.


    MoveUser -l \
"ldap://siroe.com:389/o=siroe.com???(mailhost=host1.domain.com)" \
-D "cn=Directory Manager" -w password -s host1 -x admin \
-p password -d host2 -a admin -v password

    moveuser 명령에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 MoveUser를 참조하십시오.

  6. 새 메일 저장소에 대한 사용자 액세스를 활성화합니다.

    1. mailUserStatus LDAP 속성을 active로 설정합니다.

    2. 다음 명령을 실행하여 인증 캐시 시간 초과 값을 0으로 설정하고 메일 저장소에 즉시 액세스할 수 있도록 합니다.


      configutil -o service.authcachettl -v 0

  7. 이전 시스템을 종료합니다.

Procedureimsimport 명령을 사용하여 메일함을 이동하는 방법

이 절차는 특히 UNIX /var/mail 형식 폴더의 메일함을 Sun Java System Messaging Server 메일 저장소로 이동하는 데 사용됩니다. 그러나 마이그레이션하는 Messaging Server에서 IMAP 메일 저장소를 UNIX /var/mail 형식으로 변환할 수 있으면 imsimport 명령을 사용하여 메일을 Sun Java System Messaging Server로 마이그레이션할 수 있습니다. 이 방법으로 메일함을 이동하기 전에 장점과 단점을 고려하십시오.

imsimport 명령을 사용하여 메일함을 이동할 경우의 장점은 다음과 같습니다.

imsimport 명령을 사용하여 메일함을 이동할 경우의 단점은 다음과 같습니다.

단계

  1. 새 Messaging Server를 설치하고 구성합니다.

  2. local.store.relinker를 enable로 설정합니다.

    이렇게 하면 동일한 메일의 중복 저장으로 인한 새 시스템의 메일 저장소 크기가 줄어듭니다. 자세한 내용은 동일한 메일의 중복 저장에 따른 저장소 크기 줄이기를 참조하십시오.

  3. 필요한 경우 새 Messaging Server에서 사용자를 준비합니다.

    Delegated Administrator를 사용하여 이 작업을 수행할 수 있습니다. 아직 새 시스템으로 전환하지 마십시오.

  4. 새 메일 저장소와 이전 메일 저장소에 대한 사용자 액세스를 모두 비활성화합니다.

    mailUserStatus LDAP 속성을 hold로 설정합니다. 사용자 메일이 보관 대기열로 전송되고 IMAP, POP 및 HTTP를 통한 메일함 액세스가 차단됩니다. 저장소 서버의 MTA 및 메일 액세스 서버는 이 요구 사항을 따라야 합니다. 이 설정은 다른 모든 mailDeliveryOption 설정을 대체합니다.

  5. 기존 메일 서버의 메일 저장소가 /var/mail 형식이 아니면 메일 저장소를 /var/mail 파일로 변환합니다.

    타사 메일 서버 설명서를 참조하십시오.

  6. imsimport 명령을 실행합니다.

    예를 들면 다음과 같습니다. 


    imsimport -s /var/mail/joe -d INBOX -u joe

    imsimport 명령에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 imsimport를 참조하십시오.

  7. 메일 저장소에 대한 사용자 액세스를 활성화합니다.

    1. mailUserStatus LDAP 속성을 active로 설정합니다.

    2. 다음 명령을 실행하여 인증 캐시 시간 초과 값을 0으로 설정하고 메일 저장소에 즉시 액세스할 수 있도록 합니다.


      configutil -o service.authcachettl -v 0

  8. 새 메일 저장소와 이전 메일 저장소에 대한 사용자 액세스를 활성화합니다.

  9. 이전 시스템을 종료합니다.