| A GroupWise move-user operation is both a GroupWise directory operation and a message-store operation. This section explores what happens in the GroupWise directory when a user object is moved from one post office to the next. Moving a user is actually called a rename by the GroupWise directory processes. The following POA log from the destination post office shows when a user named BSmith is moved from one post office to the next: ADM: Completed: Rename object in Post Office - User DOMAIN2.PO2.BSMITH (Administrator: (WWW_TREE) tkratzer.www.americas, Domain: DOMAIN1)
The directory-level move of a GroupWise object rarely fails. If you make sure that you connect to the destination domain when you perform the move, you will further reduce the likelihood of problems. In a move-user operation, the owning domain, as explained in Chapter 3, "Understanding the GroupWise Directory," isn't readily apparent as in most operations. In a move-user operation in which a user is moved from DOMAIN1.PO1 to DOMAIN2.PO2, the destination domain immediately becomes the owning domain. This means that the destination domain must approve the move/rename operation before anything else will happen. The most important directory processes in a move-user operation are the ones at the destination domain and the destination post office. To ensure a smooth move-user operation at the GroupWise directory level, an administrator should be connected to the destination domain's WPDOMAIN.DB database before issuing the move of the user. Determining When a Move Is Pending When you move a user, eDirectory is updated with the object's post office change, but the GroupWise directory might still be propagating the change. If eDirectory reports that the user's post office is PO2, but the GroupWise directory reports that the user's post office is PO1, the GroupWise snap-in will know that a move is pending. Or if eDirectory reports that a user's post office is still PO1, but the GroupWise directory reports that it's PO2, the GroupWise snap-in will think that a move is pending. This condition will exist until the GroupWise directory has successfully broadcast the user move to all other domains. This condition can exist also when the eDirectory replica that you made changes to when moving the user is not the same replica that ConsoleOne is talking to at a certain moment. Until this condition no longer exists, the GroupWise directory is in a freeze state regarding the user's object. If you attempt to view the details or edit this user's object while in this freeze state, you will see the message shown in Figure 13.1. Figure 13.1. The pending move warning 
This freeze state can be a two-edged sword at times. It sometimes means that the GroupWise directory is waiting to catch up to the eDirectory. Generally, however, it means that eDirectory is behind the GroupWise directory. Follow this fictitious scenario with the following players for an explanation of how this happens: Following is an explanation of how GroupWise and eDirectory can get out of sync during a GroupWise user move: The state of the system at the directory level is as described here: The GroupWise administrator moves USERA to DOMAINB. The immediate state of the system at the directory level becomes this: DOMAINB is the destination domain on the move operation, so DOMAINB approves the move operation. eDirectory PARTITION-A-REPLICA-1 knows about the change to USERA's post office. DOMAINA doesn't know about the change to USERA yet; it's still replicating. eDirectory PARTITION-A-REPLICA-2 is not aware of the change to USERA; it hasn't synced with eDirectory PARTITION-A-REPLICA-1 yet.
The error state is as described here: Another administrator, authenticated to eDirectory PARTITION-A-REPLICA-2, launches GroupWise administrator. The GroupWise administrator is connected to DOMAINB. The NetWare client is communicating with eDirectory PARTITION-A-REPLICA-2. eDirectory PARTITION-A-REPLICA-2 hasn't received the change from eDirectory PARTITION-A-REPLICA-1.
Now a condition exists in which there is a post office mismatch between GroupWise and eDirectory. The result is that the administrator will continue to get the "Pending move" message shown in Figure 13.1. Generally, this condition will rectify itself with time. Sometimes it doesn't, though. In this case, you will have to do something to clean up the directory. For example, you could delete the user's eDirectory account. You could also try removing the link between GroupWise and eDirectory, which is called disassociating GroupWise attributes. This option is in ConsoleOne under Tools, GroupWise Utilities, GW/eDirectory Association. Understanding the Chronology of the Move-User Process The following is an investigation into how a user is moved. The user, USERA, is being moved from the SOURCE post office to the DESTINATION post office. The entire move-user process at both the directory level and the message-store level is mapped out in this section. The GroupWise 6.x and 7 post office agents (POAs) support a much faster move-user method than older versions of GroupWise. The method of moving a user's message store is called a live move. The slower move method is called a message-file move or a batch move. This chapter explains only the live move process. The GroupWise message-file move is the old standby architecture for a move-user operation. GroupWise POAs prefer to use live move, and will attempt to use the live move architecture first. POAs use the message-file move method only when one of the following conditions exists: Either post office object has the Disable Live Move check box checked under the Post Office Settings property page. One POA cannot contact the other via its TCP/IP address and/or client/server port. Either POA is version 5.5.x or older. You attempt to bring down the source POA while a live move is in process.
Moving a GroupWise User via Live Move When performing this move, GroupWise Administration is connected to the WPDOMAIN.DB for the destination domain, DOMAIN2. Table 13.1 lays out the scenario details for this sample user move. Table 13.1. Live User Move Scenario DetailsSOURCE | | | POST OFFICE | POA IP ADDRESS AND PORT | DOMAIN | PO1 | 137.65.55.211:1678 | DOMAIN1 | Destination | | | POST OFFICE | POA IP ADDRESS AND PORT | DOMAIN | PO2 | 137.65.55.211:1677 | DOMAIN2 |
Tip If the user will be moving to a new domain, make sure you're connected to the new domain when issuing the move-user operation.
Tip To show the detail in the GroupWise POA logs as shown in this sample scenario, your POAs must have their logging level set to verbose.
Following is an explanation of a user move scenario in which a file-based/batch move mechanism is used: In ConsoleOne, the GroupWise administrator is connected to DOMAIN2 and moves USERA to DOMAIN2.PO2. The MTA for DOMAIN2 broadcasts the USERA move to PO2. PO2's POA must approve the rename of USERA.PO1.DOMAIN1 to USERA.PO2.DOMAIN2.
Note DOMAIN2 does not broadcast the USERA move operation to the rest of the GroupWise system yet.
PO2 receives the USERA rename and the ADMIN tHRead of the POA updates its WPHOST.DB file with the USERA "rename" operation. Also note that POA reports that the user ADMIN.AMERICAS is the person who performed the rename operation. The ADMIN tHRead of the POA creates a message to be sent back to its domain, DOMAIN2, indicating that PO2 received and approved the rename of USERA. WWWFS1\SYS:/PO2\wpcsout\ofs\2\a2b917b5.001, Size: 1746 07:48:05 2A4 Processing a2b917b5.001 07:48:05 2A4 Processed OK 07:48:06 278 ADM: Completed: Rename object in post office User CORP.PO1.USERA (Administrator: (WWW_TREE) admin.americas, Domain: CORP) 07:48:12 294 MTP: Sender thread started for link CORP: 4 running 07:48:12 294 MTP: Sender thread started for link CORP: 5 running 07:48:12 3BB MTP: CORP: Connection established: 137.65.55.211 07:48:12 3BB MTP: File sent: A2B917B6.001 Queue: 2 Size: 2014 07:48:12 3B9 MTP: CORP: Connection established: 137.65.55.211 07:48:12 3A9 MTP: CORP: Connection established: 137.65.55.211 07:48:12 3B9 MTP: File sent: A2B917B6.005 Queue: 2 Size: 746 07:48:12 3A9 MTP: File sent: A2B917B6.003 Queue: 2 Size: 1654
DOMAIN2 receives the message from PO2 indicating an all-systems-go on the move-user operation. DOMAIN2 broadcasts the rename of USERA to the entire GroupWise system by sending the rename operation to the primary domain and to all the post offices in DOMAIN2. DOMAIN2 also sends a few messages down to the destination post office that contains the client option settings for the user, which are merged into the user database. At this point the USERxxx.db exists on the destination post office. DOMAIN1 receives the message from the primary domain indicating the rename of USERA. DOMAIN1's MTA-ADMIN thread updates the WPDOMAIN.DB file with the rename of USERA. DOMAIN1's MTA transmits the rename of USERA to PO1. PO1 receives the USERA rename operation. PO1's POA updates the WPHOST.DB file with the rename of USERA. PO2 logs into PO1 and requests an inventory list of all of USERA's mailbox items. When the inventory list is received, PO2 determines which items are already at PO2 and do not need to be requested from PO1. PO2 then stores the request for the inventory items it needs in the deferred database at PO2. PO2's POA log reads as shown here: 07:48:24 288 C/S Login dos ::GW Id=USERA :: 137.65.55.211 07:48:25 288 Remote Request From: USERA 07:48:25 288 (TRACKMOVE) BEGIN PHASE 'MvDstUser_SendRetrievalList_Begin_Live': USERA (umz) 07:48:25 288 (TRACKMOVE) (Move.) Receiving Inventory List: USERA (umz) 07:48:25 288 (TRACKMOVE) Receiving and storing INVENTORY list - should only happen once: USERA (umz) 07:48:25 288 Purge record 02CC 07:48:25 288 (TRACKMOVE) (Move.) Inventory List Received (1540): USERA (umz) 07:48:25 288 (TRACKMOVE) (Move.) Queue First Deferred Retry Message: USERA (umz)
PO2 logs in again to PO1 and requests the inventory items that it needs. You will notice that the POA does a good job of giving a detailed log of just where it is in the move-user process. Also notice that after approximately every 70 inventory items received, the POA reports how many inventory items it has remaining. PO2's POA log reads as shown here: 07:48:26 2A4 (TRACKMOVE) BEGIN PHASE 'MvDstUser_SendRetrievalList_LiveRetry': USERA (umz) 07:48:26 2A4 (TRACKMOVE) (Move.) Requesting User Data: USERA (umz) 07:48:26 2A4 (TRACKMOVE) Attempting 'MvDstUser_SendRetrievalList': USERA (umz) 07:48:26 2A4 (TRACKMOVE) Beginning 'MvAnyUser_LiveMoveLogin': USERA (umz) 07:48:26 2A4 (TRACKMOVE) Attempting connection 'MvAnyUser_LiveMoveLogin' to 137.65.55.211:1678: USERA (umz) 07:48:26 2A4 (TRACKMOVE) Establish Transfer LIVE: USERA (umz) 07:48:26 2A4 (TRACKMOVE) (Move.) Remaining Inventory Count (1540): USERA (umz) 07:48:26 2A4 (TRACKMOVE) BEGIN LIVE 'MvDstUser_SendRetrievalList_LiveDispatch': USERA (umz) 07:48:26 2A4 (TRACKMOVE) Continue LIVE 'MvDstUser_SendRetrievalList_LiveDispatch' (1 0x00000001): USERA (umz) 07:48:26 2A4 (TRACKMOVE) (Move.) Folder Received: USERA (umz) 07:48:26 2A4 (TRACKMOVE) (Move.) Folder Received: USERA (umz) 07:48:26 2A4 (TRACKMOVE) (Move.) Folder Received: USERA (umz) <<Several Lines Omitted>> 07:48:27 2A4 (TRACKMOVE) (Move.) Bag Record Received: USERA (umz) 07:48:27 2A4 (TRACKMOVE) (Move.) Bag Record Received: USERA (umz) 07:48:27 2A4 (TRACKMOVE) (Move.) Bag Record Received: USERA (umz) <<Several Lines Omitted>> 07:48:27 2A4 (TRACKMOVE) (Move.) Category Record Received: USERA (umz) 07:48:27 2A4 (TRACKMOVE) (Move.) Category Record Received: USERA (umz) <<Several Lines Omitted>> 07:48:27 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz) 07:48:27 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz) 07:48:27 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz) <<Several Lines Omitted>> 07:48:27 2A4 (TRACKMOVE) (Move.) Remaining Inventory Count (1443): USERA (umz) 07:48:27 2A4 (TRACKMOVE) Continue LIVE 'MvDstUser_SendRetrievalList_LiveDispatch' (2 0x00000002): USERA (umz) 07:48:28 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz) <<Several Lines Omitted>> 07:48:28 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz) 07:48:28 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz) 07:48:28 2A4 (TRACKMOVE) (Move.) Remaining Inventory Count (1372): USERA (umz) 07:48:28 2A4 (TRACKMOVE) Continue LIVE 'MvDstUser_SendRetrievalList_LiveDispatch' (3 0x00000003): USERA (umz) <<Over Seven Hundred Lines Omitted>> 07:48:41 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz) 07:48:41 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz) 07:48:41 2A4 (TRACKMOVE) (Move.) Remaining Inventory Count (533): USERA (umz) 07:48:41 2A4 (TRACKMOVE) Continue LIVE 'MvDstUser_SendRetrievalList_LiveDispatch' (15 0x0000000f): USERA (umz) 07:48:49 2A4 (TRACKMOVE) (Move.) Item Received: USERA (umz) 07:48:49 2A4 (TRACKMOVE) (Move.) AddressBook Component Received: USERA (umz) 07:48:49 2A4 (TRACKMOVE) (Move.) AddressBook Component Received: USERA (umz) 07:48:49 2A4 (TRACKMOVE) (Move.) User Setting Received: USERA (umz) 07:48:49 2A4 (TRACKMOVE) (Move.) User Setting Received: USERA (umz) 07:48:49 2A4 (TRACKMOVE) (Move.) User Setting Received: USERA (umz) 07:48:49 2A4 (TRACKMOVE) (Move.) Remaining Inventory Count: USERA (umz) 07:48:49 2A4 (TRACKMOVE) END LIVE 'MvDstUser_SendRetrievalList_LiveDispatch' (0 0x00000000): USERA (umz) 07:48:49 2A4 (TRACKMOVE) The INVENTORY list is now EMPTY: USERA (umz) 07:48:49 2A4 (TRACKMOVE) Finished retrieval LIVE - will be purging SOURCE database: USERA (umz) 07:48:49 2A4 (TRACKMOVE) (Move.) Transfer Complete. All Items Received: USERA (umz) 07:48:49 2A4 (TRACKMOVE) (Move.) Sending Purge Notification: USERA (umz) 07:48:49 2A4 (TRACKMOVE) Deleting INVENTORY list 07:48:49 2A4 (TRACKMOVE) END PHASE 'MvDstUser_SendRetrievalList_LiveRetry' (0 0x00000000): USERA (umz) 07:48:49 2A4 Processed OK 07:48:49 3A9 MTP: File sent: A2B917DA.001 Queue: 2 Size: 1462 07:48:49 3B9 MTP: File sent: A2B917DB.001 Queue: 2 Size: 1462 07:48:49 3B9 MTP: File sent: A2B917DE.001 Queue: 2 Size: 1462
This step shows what is being processed on PO1 that is happening simultaneous to the actions going on in step 7. The source post office PO1 sends the user's entire inventory in batches. Each batch is numbered with the same batch number indicated in PO2's POA log. PO1's POA processes the live request for inventory items from PO2's POA; the log for PO1's POA reads as shown here: 2WWWFS1\SYS:/PO1\wpcsout\ofs\2\a2b917c1.001, Size: 1738 07:48:17 397 Processing a2b917c1.001 07:48:17 397 Processed OK 07:48:18 39B ADM: Completed: Rename object in post office User CORP.PO1.USERA (Administrator: (WWW_TREE) admin.WWW, Domain: CORP) 07:48:22 387 MTP: Sender thread started for link CORP: 4 running 07:48:22 387 MTP: Sender thread started for link CORP: 5 running 07:48:22 3A1 MTP: CORP: Connection established: 137.65.55.211 <<A Few Lines Omitted>> 07:48:23 3B5 MTP: Received file: WWWFS1\SYS:/PO1\wpcsout\ofs\2\22b917c7.001, Size: 1746 07:48:23 397 Processing 22b917c7.001 07:48:23 397 Processing Admin Task: Rename 07:48:23 397 (TRACKMOVE) BEGIN PHASE 'MvSrcUser_SendInventoryList_Begin': USERA (umz) 07:48:23 397 (TRACKMOVE) (.Move) Initiating: USERA (umz) 07:48:24 397 User USERA moved, terminating current session 07:48:24 397 (TRACKMOVE) (.Move) Queue First Deferred Retry Message: USERA (umz) 07:48:24 397 (TRACKMOVE) Attempting 'MvSrcUser_SendInventoryList': USERA (umz) 07:48:24 397 (TRACKMOVE) Beginning 'MvAnyUser_LiveMoveLogin': USERA (umz) 07:48:24 397 (TRACKMOVE) Attempting connection 'MvAnyUser_LiveMoveLogin' to 137.65.55.211:1677: USERA (umz) 07:48:25 397 (TRACKMOVE) (.Move) Sending Inventory List (1540): USERA (umz) 07:48:25 397 (TRACKMOVE) END PHASE 'MvSrcUser_SendInventoryList_Begin' (0 0x00000000): USERA (umz) 07:48:25 397 Admin Task Completed: OK 07:48:25 397 Processed OK 07:48:26 37F***NEW PHYS. CONNECTION, Tbl Entry=0, Socket=115 07:48:26 37F***NEW APP CONNECTION, Tbl Entry=0, Check ID=1119424940 07:48:26 37F C/S Login dos ::GW Id=USERA :: 137.65.55.211 07:48:26 37F Remote Request From: USERA 07:48:26 37F (TRACKMOVE) BEGIN PHASE 'MvSrcUser_GetMovedUserBoxContent_Live': USERA (umz) 07:48:26 37F (TRACKMOVE) (.Move) Request for User Data Received: USERA (umz) 07:48:26 37F (TRACKMOVE) BEGIN LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (1 0x00000001): USERA (umz) 07:48:26 37F (TRACKMOVE) (.Move) Folders Sent (12): USERA (umz) 07:48:26 37F (TRACKMOVE) (.Move) Bag Records Sent (25): USERA (umz) 07:48:26 37F (TRACKMOVE) (.Move) Category Records Sent (4): USERA (umz) 07:48:26 37F (TRACKMOVE) (.Move) Remaining Inventory Count (1443): USERA (umz) 07:48:26 37F (TRACKMOVE) Continue LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (1 0x00000001): USERA (umz) 07:48:26 37F (TRACKMOVE) END PHASE - 'MvSrcUser_GetMovedUserBoxContent_Live' (0 0x00000000): USERA (umz) 07:48:27 37F Remote Request From: USERA 07:48:27 37F (TRACKMOVE) BEGIN PHASE - 'MvSrcUser_GetMovedUserBoxContent_Live': USERA (umz) 07:48:27 37F (TRACKMOVE) Continue LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (2 0x00000002): USERA (umz) 07:48:27 37F (TRACKMOVE) (.Move) Remaining Inventory Count (1372): USERA (umz) 07:48:27 37F (TRACKMOVE) Continue LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (2 0x00000002): USERA (umz) 07:48:27 37F (TRACKMOVE) END PHASE - 'MvSrcUser_GetMovedUserBoxContent_Live' (0 0x00000000): USERA (umz) 07:48:28 37F Remote Request From: USERA 07:48:28 37F (TRACKMOVE) BEGIN PHASE 'MvSrcUser_GetMovedUserBoxContent_Live': USERA (umz) 07:48:28 37F (TRACKMOVE) Continue LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (3 0x00000003): USERA (umz) 07:48:28 37F (TRACKMOVE) (.Move) Remaining Inventory Count (1301): USERA (umz) 07:48:28 37F (TRACKMOVE) Continue LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (3 0x00000003): USERA (umz) 07:48:28 37F (TRACKMOVE) END PHASE 'MvSrcUser_GetMovedUserBoxContent_Live' (0 0x00000000): USERA (umz) 07:48:29 3A7 MTP: CORP: Connection established: 137.65.55.211 07:48:29 3AD MTP: CORP: Connection established: 137.65.55.211 07:48:29 3AF MTP: CORP: Connection established: 137.65.55.211 07:48:29 3A7 MTP: File sent: A2B917C8.001 Queue: 2 Size: 886 07:48:29 3AD MTP: File sent: A2B917C8.003 Queue: 2 Size: 886 07:48:29 3AF MTP: File sent: A2B917C9.001 Queue: 2 Size: 894 07:48:29 3A7 MTP: File sent: A2B917C9.003 Queue: 2 Size: 886 07:48:29 37F Remote Request From: USERA 07:48:29 37F (TRACKMOVE) BEGIN PHASE 'MvSrcUser_GetMovedUserBoxContent_Live': USERA (umz) 07:48:29 37F (TRACKMOVE) Continue LIVE <<Several Lines Omitted>> 07:48:47 37F (TRACKMOVE) Continue LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (21 0x00000015): USERA (umz) 07:48:47 37F (TRACKMOVE) (.Move) Remaining Inventory Count (46): USERA (umz) 07:48:47 37F (TRACKMOVE) Continue LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (21 0x00000015): USERA (umz) 07:48:47 37F (TRACKMOVE) END PHASE 'MvSrcUser_GetMovedUserBoxContent_Live' (0 0x00000000): USERA (umz) 07:48:48 37F Remote Request From: USERA 07:48:48 37F (TRACKMOVE) BEGIN PHASE 'MvSrcUser_GetMovedUserBoxContent_Live': USERA (umz) 07:48:48 37F (TRACKMOVE) Continue LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (22 0x00000016): USERA (umz) 07:48:48 37F (TRACKMOVE) (.Move) Items Sent (1494): USERA (umz) 07:48:48 37F (TRACKMOVE) (.Move) AddressBook Components Sent (2): USERA (umz) 07:48:48 37F (TRACKMOVE) (.Move) User Settings Sent (3): USERA (umz) 07:48:48 37F (TRACKMOVE) (.Move) Remaining Inventory Count: USERA (umz) 07:48:48 37F (TRACKMOVE) END LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (22 0x00000016): USERA (umz) 07:48:48 37F (TRACKMOVE) END PHASE 'MvSrcUser_GetMovedUserBoxContent_Live' (0 0x00000000): USERA (umz) 07:48:49 37F Remote Request From: USERA 07:48:49 37F (TRACKMOVE) BEGIN PHASE 'MvSrcUser_DeleteMovedUser_Live': USERA (umz) 07:48:49 37F (TRACKMOVE) Sending LIVE 'MvSrcUser_PurgeUser': USERA (umz) 07:48:49 37F (TRACKMOVE) (.Move) Sending LOCAL Purge Notification: USERA (umz) 07:48:49 37F (TRACKMOVE) Sending ACTION_DELETE_USER: USERA (umz) 07:48:49 37F (TRACKMOVE) END PHASE 'MvSrcUser_DeleteMovedUser_Live' (0 0x00000000): USERA (umz)
Now that all the items have been received by PO2, the POA, the message items on PO1 are deleted and purged. Following are excerpts from PO1's POA log: 07:49:09 397 Purge message record 07:49:09 397 Purge item record 07:49:09 397 Purge message record 07:49:09 397 (TRACKMOVE) Moved user deleted 'WpeDeleteUserExt' (0 0x00000000): USERA (umz) 07:49:09 397 (TRACKMOVE) Completed 'WpeDeleteUserExt' (0 0x00000000): USERA (umz) 07:49:09 397 (TRACKMOVE) Sending status MOVE_USER_FINISHED: USERA (umz) 07:49:09 397 (TRACKMOVE) END PHASE 'MvSrcUser_DeleteMovedUser_Batch' (0 0x00000000): USERA (umz) 07:49:09 397 Processed OK
The POA log files are very helpful when you're troubleshooting user moves. If a move becomes bogged down, study the POA logs; they are sure to indicate the problem that was encountered. Key Technical Factors Related to a Move Remember that a user move is a move of both a user's directory object and the user's messages. Moving the GroupWise user's message store tends to be much more problematic than moving the object in the GroupWise directory. An understanding of the move-user architecture can really help you out of a bind. The discussion in this next section still refers to USERA and other terms introduced previously. The 12-Hour, 7-Day Clock When the destination PO receives the inventory list, it puts the inventory list in the USERxxx.DB file for USERA. Note The xxx is replaced with USERA's file ID, or FID, as explained in Chapter 4, "Understanding the GroupWise Information Store."
The USERxxx.DB file should already exist because of the client options that were sent down by the destination domain at the beginning of the move. The POA will place the inventory list within the USERxxx.DB file. The pointer to the inventory list is also placed in the PO\OFMSG\NGWDFR.DB file (the deferred delivery database) on the destination post office. The inventory list in the deferred delivery database serves as a reminder to the destination PO to query the source PO for the items on the inventory list for USERA every 12 hours for 7 days. Items remaining on the inventory list indicate that the destination PO has not received all the items from the source PO. After all of a user's message items have moved across, and the purge notification is sent, the POA on the source PO deletes the pointer to the inventory list. The reminder mechanism was designed to create a fail-safe message-store move operation. Integrity of the Message Store When a user moves from PO1 to PO2, the integrity of the message store on both post offices is important. The integrity of the message store on PO1 is critical. If a customer is implementing message-store maintenance routines on his GroupWise post offices, there is generally little concern about the message store. The move-user task list (in the upcoming section "Moving a GroupWise User") talks about which Mailbox/Library Maintenance/GWCheck routines to run on a user to be moved. With live moves, the recommendation is still to move one user at a time. Multiple simultaneous moves can be successful, but if all client/server threads on the target POA are being used, the user move will be delayed up to 12 hours, unless the administrator intervenes with the User Move Status utility. All GroupWise POAs attempt a live move first, before falling back to a message-store move. When you move a user, you cannot request a live move over a message-store move. The POA is hard-coded to attempt a live move if everything is in place. If for some reason you want to disable live move, do the following: 1. | Go to the destination's post office object in ConsoleOne.
| 2. | Go to the Properties of the post office object.
| 3. | Go to the GroupWise Post Office Settings property page.
| 4. | Check the Disable Live Move check box.
| 5. | Follow steps 14 on the source post office object as well.
|
| 