test

Sun Java System Messaging Server 6.3 관리 설명서

20.15 메일함을 새 시스템으로 이동 또는 마이그레이션

한 Messaging Server 시스템의 기존 메일함을 다른 Messaging Server 시스템으로 이동해야 할 수 있습니다. 이러한 경우는 다음과 같습니다.

Messaging Server는 한 시스템의 메일함을 다른 시스템으로 이동하는 여러 가지 방법을 제공합니다. 방법마다 장단점이 있으며, 여기에 대해서는 아래 절에서 설명합니다. 이 방법에 대한 자세한 내용은 다음 절을 참조하십시오.

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

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

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

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

20.15.1.1 증분 메일함 마이그레이션

증분 마이그레이션은 메시지 저장소를 다른 시스템으로 안전하고 효율적으로 이동하거나 새 시스템으로 업그레이드할 수 있는 등 다양한 이점을 제공합니다. 증분 마이그레이션을 사용하면 이전 백엔드 메시지 저장소와 함께 새 백엔드 메시지 저장소 시스템을 구성할 수 있습니다. 그런 다음 새 시스템을 테스트하고, 친분이 있는 사용자에게 마이그레이션한 다음 새 시스템을 다시 테스트할 수 있습니다. 새 시스템과 구성이 편리하고 마이그레이션 절차에 익숙한 경우 실제 상업용 사용자를 마이그레이션할 수 있습니다. 이러한 사용자를 개별 백업 그룹으로 분할하여 마이그레이션 중에 이 그룹의 구성원만 잠시 오프라인 상태로 전환할 수 있습니다.

온라인 증분 마이그레이션은 업그레이드가 실패할 경우 시스템 전체에서 백아웃을 계획할 필요가 없다는 또 다른 장점이 있습니다. 백아웃은 시스템에 대해 수행한 변경을 취소하여 원래의 작업 상태로 되돌리는 절차입니다. 마이그레이션을 수행할 때 실패에 대한 계획을 수립해야 합니다. 즉, 마이그레이션의 모든 단계에서 이전 작업 상태로 되돌릴 계획을 세워야 합니다.

오프라인 마이그레이션은 모든 마이그레이션 단계를 완료하고 서비스를 다시 실행할 때까지는 마이그레이션이 성공했는지 확인할 수 없다는 문제가 있습니다. 따라서 시스템이 작동하지 않고 빠르게 수정할 수 없는 경우 수행한 모든 단계에 대해 백아웃 절차를 수행해야 합니다. 이 작업은 매우 힘들고 시간이 많이 소요될 수 있으며, 작업을 수행하는 동안 사용자는 오프라인 상태로 유지됩니다.

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

1. 이전 시스템과 함께 새 시스템을 구축하여 두 시스템이 독립적으로 작동할 수 있게 합니다.

2. 이전 시스템이 새 시스템과 공존하도록 구성합니다.

3. 친분이 있는 사용자 그룹을 마이그레이션하고 새 시스템을 테스트하며 이전 시스템과의 공존 상태를 테스트합니다.

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

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

두 시스템이 공존하기 때문에 새 시스템으로 마이그레이션하기 전에 새 시스템을 테스트하고 익숙해질 시간이 있습니다. 원하지 않더라도 백아웃 절차를 수행해야 하는 경우에는 2단계와 4단계에 대해서만 계획해야 합니다. 2단계는 사용자의 데이터를 건드리지 않기 때문에 쉽게 반전됩니다. 4단계에서는 백아웃을 수행하여 사용자의 상태를 활성 상태로 되돌리고 메일 호스트 속성을 이전 호스트로 되돌립니다. 시스템 차원의 백아웃이 필요하지 않습니다.

20.15.1.2 온라인 마이그레이션 개요

온라인 상태에서 메일함을 마이그레이션하는 프로세스는 매우 간단합니다. 메일함으로 전송 중인 메시지(MTA 채널 대기열에서 전달을 위해 대기 중)가 마이그레이션 중에 손상되지 않도록 하는 과정은 매우 복잡합니다. 한 가지 해결 방법으로 마이그레이션 과정에서 전송된 메시지를 보관 상태로 유지하고 다양한 채널 대기열의 메시지가 전달될 때까지 대기합니다. 그러나 시스템 문제나 특정 사용자의 할당량 초과로 메시지가 대기열에 고착될 수 있습니다. 그럴 경우 문제를 해결한 다음 메일함을 마이그레이션해야 합니다.

다양한 방법으로 메시지 손실 가능성을 줄이고 메시지가 채널 대기열에 고착되지 않도록 할 수 있지만, 그럴 경우 절차가 복잡해지는 단점이 있습니다.

절차에서 수행되는 단계의 순서와 필요성은 모든 메일함에 전달되는 모든 메시지가 손실되는지 여부와 배포에 따라 다릅니다. 이 절에서는 단계와 관련한 이론과 개념에 대해 설명합니다. 사용자는 각 단계를 이해하고 지정된 배포에 대해 수행할 각 단계와 순서를 결정해야 합니다. 다음은 메일함 이동 프로세스의 개요입니다. 이 프로세스는 배포에 따라 다를 수 있습니다.

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

  2. 이동 중인 메일함으로 전달되는 메시지를 임시로 보관합니다.

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

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

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

  6. 전달을 위해 보관 중인 메시지를 새 메일함으로 릴리스하고 마이그레이션된 메일함으로 전달할 받는 메시지를 활성화합니다.

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

  8. 메일함에 대한 사용자 액세스 차단을 해제합니다.

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

시작하기 전에

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

주 –

일부 단계는 Messaging Server를 최신 버전으로 업그레이드하는 경우에만 적용됩니다. 이 단계는 다른 메시지 저장소로 메일함 마이그레이션만 수행하는 경우에는 적용되지 않을 수도 있습니다. 전체 시스템 마이그레이션에 적용되는 단계는 별도의 설명이 있습니다.

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

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

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

  2. 이동 대상인 사용자에게 이동이 완료될 때까지 메일함에 액세스할 수 없음을 알립니다.

    데이터를 이동하기 전에 이동할 사용자가 메일 시스템에서 로그아웃했는지 확인합니다. ( 20.13 사용자 액세스 모니터링 참조)

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

    1. 이동할 메일함이 있는 백엔드 메시지 저장소에서 인증 캐시 시간 초과를 0으로 설정합니다.


      configutil -o service.authcachettl -v 0

      이 단계와 단계 7(mailUserStatus를 hold로 변경)에서는 마이그레이션 중에 사용자의 메일함 액세스를 즉시 차단합니다.

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

      ImapProxyAService.cfg 및 PopProxyAService.cfg는 LdapCacheTTL과 AuthCacheTTL을 모두 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.4 서비스 시작 및 중지를 참조하십시오.

  4. 원본 Messaging Server와 대상 Messaging Server가 모두 실행 중인지 확인합니다.

    원본 Messaging Server는 받는 메시지를 새 대상 서버에 라우팅할 수 있어야 합니다.

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

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

    mailUserStatus에 대한 자세한 내용은 Sun Java Communications Suite 5 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 Communications Suite 5 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- -c y -v 1

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

    주 –

    나중의 전달 확인을 위해 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 Server에서 메시지를 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의 경우 ImapProxyAService.cfg와 PopProxyAService.cfg에서 LdapCacheTTL과 AuthCacheTTL 옵션을 900으로 설정합니다.

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

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

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

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

    대안은 MMP(Messaging Multiplexor)를 사용하는 것입니다. 그러면 사용자가 새 메일 서버를 클라이언트로 직접 가리킬 필요가 없습니다. MMP는 LDAP 사용자 항목에 저장된 mailHost 속성으로부터 정보를 가져와서 클라이언트를 새 서버로 자동으로 리디렉션합니다.

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

    이전 메시지 저장소로 이동한 후 mboxutil -l을 실행하여 메일함을 나열합니다. 마지막 메시지 전달 타임스탬프를 확인합니다. 마이그레이션 타임스탬프(imsbackup 명령을 실행한 날짜 스탬프) 이후에 전달된 메시지가 있는 경우 백업 및 복원 명령을 사용하여 해당 메시지를 마이그레이션합니다. 준비 단계를 수행했기 때문에 마이그레이션 이후에 전달된 메시지가 표시되는 경우는 극히 드뭅니다.

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

  15. 새 메시지 저장소에서 중복 메시지를 제거하고 relinker 명령을 실행합니다.

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

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

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

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

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

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

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

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

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

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

  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로 설정합니다.

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

  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.3 Administration Reference의 MoveUser를 참조하십시오.

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

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

  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로 설정합니다.

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

  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.3 Administration Reference의 imsimport를 참조하십시오.

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

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

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

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