Wikis - Page

User Move Within GroupWise

ukdtom1

0 Likes

over 3 years ago

By Tommy Mikkelsen

1. Purpose

2. System preparation

   2.1 Loglevel

   2.2 NickName creation

   2.3 Live move

   2.4 Communication

3. User Move Preparations

   3.1 Validate

   3.2 Resources

   3.3 User Reduce amount of items

   3.4 Archive

   3.5 User Database cleanup

   3.6 Admin reduce amount of items

   3.7 Backup

   3.8 Alias

4. Move

5. Monitoring

   5.1 Admin Portion of the Move

   5.2 Transferring the Inventory List

   5.3 Transferring the Items and Finishing the Move Process

   5.4 Source POA Log Reference

6. Errors

   6.1 Detecting Errors in User Moves

   6.2 Fixing User Move Problems

7. Appendix

   7.1 User move flow

   7.2 Useful TIDs

1. Purpose

This document is intended as a guideline in how to move a user from one Post Office to another, since this is a procedure that fails a lot of times.

This document is based on TIDs, LogicSource and Cool Solution articles, that all contributed to the success of a User move, but since I found that no matter where I looked, I could not find a complete solution.....

This document is not my invention, but more a compilation of numerous sources !!!

This document was a work in progress for me, and as such, I have no clue as to where I picked up the different bits, and do also not doubt, that as soon as this document is published, people will start to add stuff that I also forgot

When all above is said, I decided that I, even though I could not give proper credit, it should be published anyway, since this document might be handy for all the GW Admins out there.

2. System preparation

First of all, the system must be configured, so the move will be as transparent as possible for not only the user that is to be moved, but also for all other users in the system.

2.1 Loglevel

Make sure that all involved domains and post offices are running verbose logging.

2.2 NickName creation

In order for users to send emails to each other within the system, the users are using their addressbooks.

The System Addressbook will be updated instantly when issuing a User Move, but the clients will not refresh the addressbooks instantly. Also, personal addressbooks, like the frequent addressbook, will only be updated during the nightly addressbook user upkeep procedure, and users running in Cache mode, default to update the addressbooks every 7 days only.

Click to view.

Due to this, the system should be set, so when a user move is issued, a nickname would automatically be created at the source post office of the user. That way, other users will not fail in sending mails to the user, even if their addressbooks isn’t updated yet.

This is done from within ConsoleOne menu Tools/GroupWise System Operations/System Preferences.

Click to view.

2.3 Live move

Live move means, that after the move has been issued from ConsoleOne, the transfer of the items will go directly from POA to POA.

To use Live moves, the POA must be enabled for this:

Click to view.

Furthermore, one must make sure that there’s enough threads allocated to the moves…

Click to view.

The default is 20% for the move threads, and should be increased if moving a lot of data…. Take care doing this though, since setting it to high will cause a bad performance for the remaining users on the Post Office.

Also make sure that enough Message Handler threads are allocated. (Bump from the default of 24 to 30 during the move)

Changing the above settings, req. that the POA is unloaded and reloaded.

2.4 Communication

Since the post offices are communicating directly with each other, the redirection table of the post office must be checked to insure that it is correct.

This can be seen either on the POA screen, by pressing F10, Configuration Options, Show redirection tables

Click to view.

or by looking at the webpage of the POA like this:

Click to view.

3. User Move Preparations

3.1 Validate

Run a Validate Database operation on each domain that will be participating in the user move. Be sure to do this for the primary, source, and destination domains as shown in the figure below. This will clean up potentially bad data, especially in the user records and their client options records. This bad data could cause the move to fail.

Note: Even when most problems are found and corrected, you will receive a "Database passed validation check" message.

Click to view.

3.2 Resources

The first thing that must be done, is to check if the user is the owner of a Resource.

If so, the resource must be reassigned to another user, since a user can’t own a resource that belongs to another post office. Failing to do so, would cause the move to fail.

3.3 User Reduce amount of items

Tell the user to delete items that they don’t need anymore from their mailbox, and remind them to also check the sent items folder.

3.4 Archive

If possible, the user should archive as much as possible. This can be dearchived after the move has been completed.

3.5 User Database cleanup

The Users database should now be checked for any problems and inconsistency.

This is done by running the following jobs, and wait for one to complete before issuing the next one…

Structure and index check

Click to view.

If the above job returns any errors, try and run the job again.

Do NOT continue with the move until all errors have been resolved

Contents check

Click to view.

Same as the other check……Make sure ALL errors are resolved before the move

Pay attention to the resultant logs from these GWChecks. The following error in the GWCheck log is of particular importance when moving users:

Problem 82- Inaccessible attachment file

If any problem 82s are present, you must correct them with the ATTCLIP option in GWCheck. Any item with a Problem 82 will cause at least one user's move to get stuck.

Duplicate folders

Click to view.

Notice in above check, that the messagedatabase is not checked.

Click to view.

Above job has to be run again and again, until no more duplicate folders are reported.

(Some times up to 10 times)

3.6 Admin reduce amount of items

As the GroupWise Administrator, you should now reduce the databases and amount of items to be transferred. This should be done according to the policies used in the company.

Click to view.

As a minimum, a Reduce only should be run.

3.7 Backup

Make a backup copy of the following files:

Wpdomain.db files from the following domains:

Primary, Source and Target domain.

The User database.

3.8 Alias

If the user has a Gateway Alias, remove this before starting the move.

(For GW7 and above, do not use any Alias for the GWIA, instead, use internet Addressing Override)

4. Move

We are now ready to move the user. This is done by doing the following:

From within ConsoleOne, right-click on the target domain, and select connect.

Then find the user, right-click and select move.

5. Monitoring

Analyzing Moves in Progress

User moves take place in two phases. The first phase is the admin move. This phase takes care of moving the user's mailbox and ensures that all domains and post offices in the system are aware of the user's new location.

The second phase of the move is called the mailbox move or the item move. This phase takes care of moving the contents of the user's mailbox.

The following example analyzes a move of a small mailbox. The move was completed with no errors.

UserA was moved from post office "SourcePO" to post office "DestPO." Both of these post offices exist in the "dom1" domain.

The following log was taken from the destination POA and has been split up into sections and edited for clarity to show only move-related activity.

5.1 Admin Portion of the Move

15:28:15 281 ADM: Completed: Rename object in post office - User dom1.SourcePO.UserA (Administrator: (TREENAME) admin.acme, Domain: dom1)15:28:15 281 ADM: Completed: Update object in post office - Misc dom1.DestPO (Administrator: (TREENAME) admin.acme, Domain: dom1)15:28:15 281 ADM: Completed: Update object in post office - Misc dom1.DestPO (Administrator: (TREENAME) admin.acme, Domain: dom1)

15:28:18 27F Processing admin task: Update Settings 15:28:18 27F Successful merge of settings for UserA 15:28:18 27F Processed OK15:28:18 27F Processing a2b98392.00315:28:18 27F Processing admin task: Update Settings 15:28:18 27F Successful merge of settings for UserA 15:28:18 27F Processed OK

The first log entries shows that the POA received a request to rename dom1.SourcePO.UserA. The POA did so and processed two follow-up requests to update the new object that exists in DestPO. UserA will now receive any new mail at DestPO instead of SourcePO. Following this change, the new user database was created in the destination post office and the user's settings were copied into that database.

Note that the POA shows that it was user admin.acme.TREENAME that requested the change and that dom1 was the domain where ConsoleOne was connected when the move request was initiated.

5.2 Transferring the Inventory List

15:28:28 265 *** NEW PHYS. CONNECTION, Tbl Entry=0, Socket=9715:28:28 265 *** NEW APP CONNECTION, Tbl Entry=0, Check ID=111945216915:28:28 265 C/S Login dos ::GW Id=UserA :: 137.65.55.22015:28:28 265 Remote Request From: UserA15:28:28 265 (TRACKMOVE) BEGIN PHASE - 'MvDstUser_SendRetrievalList_Begin_Live': UserA (wd9) 15:28:28 265 (TRACKMOVE) (Move.) Receiving Inventory List: UserA (wd9) 15:28:28 265 (TRACKMOVE) Receiving and storing INVENTORY list - should only happen once: UserA (wd9) 15:28:28 265 Purge record 02CC 15:28:28 265 (TRACKMOVE) (Move.) Inventory List Received (28): UserA (wd9) 15:28:28 265 (TRACKMOVE) (Move.) Queue First Deferred Retry Message: UserA (wd9) 15:28:28 265 (TRACKMOVE) END PHASE - 'MvDstUser_SendRetrievalList_Begin_Live' (0 0x00000000): UserA (wd9) 15:28:28 265 *** APP DISCONNECTED, Tbl Entry=0, Check ID=111945216915:28:28 265 *** PHYSICAL PORT DISCONNECTED, Tbl Entry=0, Socket=97

Please note the following steps shown in this section:

1. A new physical and application connection are made to the destination POA. The two of these constitute a login to the destination POA. These connections come from the source POA and appear as a remote request from UserA.

1. The inventory list is received from the source post office. UserA's FID is noted to be "wd9".

1. The destination POA notes that the inventory list contains 28 items.

1. The "First Deferred Retry Message" is queued to signal the POA to begin moving items.

1. The remote request mentioned in #1 above is completed and the related connections are cleaned up.

5.3 Transferring the Items and Finishing the Move Process

NOTE: Some of the lines of the log have been removed for clarity.

15:28:38 27F (TRACKMOVE) BEGIN PHASE - 'MvDstUser_SendRetrievalList_LiveRetry': UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) Requesting User Data: UserA (wd9) 15:28:38 27F (TRACKMOVE) Attempting 'MvDstUser_SendRetrievalList': UserA (wd9) 15:28:38 27F (TRACKMOVE) Beginning 'MvAnyUser_LiveMoveLogin': UserA (wd9) 15:28:38 27F (TRACKMOVE) Attempting connection 'MvAnyUser_LiveMoveLogin' to 137.65.55.220:1681: UserA (wd9) 15:28:38 27F (TRACKMOVE) Establish Transfer LIVE: UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) Remaining Inventory Count (28): UserA (wd9) 15:28:38 27F (TRACKMOVE) BEGIN LIVE 'MvDstUser_SendRetrievalList_LiveDispatch': UserA (wd9) 15:28:38 27F (TRACKMOVE) Continue LIVE 'MvDstUser_SendRetrievalList_LiveDispatch' (1 0x00000001): UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) Folder Received: UserA (wd9) . . .15:28:38 27F (TRACKMOVE) (Move.) Folder Received: UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) Bag Record Received: UserA (wd9) . . .

15:28:38 27F (TRACKMOVE) (Move.) Bag Record Received: UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) Category Record Received: UserA (wd9) . . .15:28:38 27F (TRACKMOVE) (Move.) Category Record Received: UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) Item Received: UserA (wd9) . . .15:28:38 27F (TRACKMOVE) (Move.) Item Received: UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) User Setting Received: UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) User Setting Received: UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) User Setting Received: UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) Remaining Inventory Count: UserA (wd9) 15:28:38 27F (TRACKMOVE) END LIVE 'MvDstUser_SendRetrievalList_LiveDispatch' (0 0x00000000): UserA (wd9) 15:28:38 27F (TRACKMOVE) The INVENTORY list is now EMPTY: UserA (wd9) 15:28:38 27F (TRACKMOVE) Finished retrieval LIVE - will be purging SOURCE database: UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) Transfer Complete. All Items Received: UserA (wd9) 15:28:38 27F (TRACKMOVE) (Move.) Sending Purge Notification: UserA (wd9) 15:28:38 27F (TRACKMOVE) Deleting INVENTORY list 15:28:38 27F (TRACKMOVE) END PHASE - 'MvDstUser_SendRetrievalList_LiveRetry' (0 0x00000000): UserA (wd9)

Please note the following steps shown in this section:

1. Now that the inventory list has been stored successfully, the destination POA attempts to log in to the source POA. The IP address and port (137.65.55.220:1681, in this example) are logged.

1. The POA begins to retrieve items. As it receives each item, it removes the corresponding entry in the inventory list. The log will show each item as being of type "Folder," "Bag Record," "Category," "Item," or "User Setting."

1. The POA logs that there is no remaining inventory count, signalling the end of the move process.

1. The POA sends a notice to the source POA to delete the user's data.

1. The POA deletes the inventory list (it's empty anyway) and the move is complete.

5.4 Source POA Log Reference

The log file for the source POA appears below as a reference. Note that it does not go into as much detail as the log for the destination POA. In general, it is preferable to watch the destination POA log when actively monitoring a user move. Notice that the activity on the source POA mirrors the activity shown above on the destination POA.

15:28:14 2BB ADM: Completed: Delete object from post office - Misc dom1.DestPO (Administrator: (GAWTREE) gwheeler.greg, Domain: dom1)15:28:14 2BB ADM: Completed: Delete object from post office - Misc dom1.DestPO (Administrator: (GAWTREE) gwheeler.greg, Domain: dom1)15:28:19 2BB ADM: Completed: Rename object in post office - User dom1.SourcePO.UserA (Administrator: (GAWTREE) gwheeler.greg, Domain: dom1)15:28:28 2B3 Processing 22b9839c.00115:28:28 2B3 Processing Admin Task: Rename 15:28:28 2B3 (TRACKMOVE) BEGIN PHASE - 'MvSrcUser_SendInventoryList_Begin': UserA (wd9) 15:28:28 2B3 (TRACKMOVE) (.Move) Initiating: UserA (wd9) 15:28:28 2B3 User UserA moved, terminating current session 15:28:28 2B3 (TRACKMOVE) (.Move) Queue First Deferred Retry Message: UserA (wd9) 15:28:28 2B3 (TRACKMOVE) Attempting 'MvSrcUser_SendInventoryList': UserA (wd9) 15:28:28 2B3 (TRACKMOVE) Beginning 'MvAnyUser_LiveMoveLogin': UserA (wd9) 15:28:28 2B3 (TRACKMOVE) Attempting connection 'MvAnyUser_LiveMoveLogin' to 137.65.55.220:1679: UserA (wd9) 15:28:28 2B3 (TRACKMOVE) (.Move) Sending Inventory List (28): UserA (wd9) 15:28:28 2B3 (TRACKMOVE) END PHASE - 'MvSrcUser_SendInventoryList_Begin' (0 0x00000000): UserA (wd9) 15:28:28 2B3 Admin Task Completed: OK15:28:38 29D *** NEW PHYS. CONNECTION, Tbl Entry=0, Socket=10515:28:38 29D *** NEW APP CONNECTION, Tbl Entry=1, Check ID=111945218015:28:38 29D C/S Login dos ::GW Id=UserA :: 137.65.55.22015:28:38 29D Remote Request From: UserA15:28:38 29D (TRACKMOVE) BEGIN PHASE - 'MvSrcUser_GetMovedUserBoxContent_Live': UserA (wd9) 15:28:38 29D (TRACKMOVE) (.Move) Request for User Data Received: UserA (wd9) 15:28:38 29D (TRACKMOVE) BEGIN LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (1 0x00000001): UserA (wd9) 15:28:38 29D (TRACKMOVE) (.Move) Folders Sent (12): UserA (wd9) 15:28:38 29D (TRACKMOVE) (.Move) Bag Records Sent (5): UserA (wd9) 15:28:38 29D (TRACKMOVE) (.Move) Category Records Sent (4): UserA (wd9) 15:28:38 29D (TRACKMOVE) (.Move) Items Sent (4): UserA (wd9) 15:28:38 29D (TRACKMOVE) (.Move) User Settings Sent (3): UserA (wd9) 15:28:38 29D (TRACKMOVE) (.Move) Remaining Inventory Count: UserA (wd9) 15:28:38 29D (TRACKMOVE) END LIVE 'MvSrcUser_GetMovedUserBoxContent_Live' (1 0x00000001): UserA (wd9) 15:28:38 29D (TRACKMOVE) END PHASE - 'MvSrcUser_GetMovedUserBoxContent_Live' (0 0x00000000): UserA (wd9) 15:28:38 29D Remote Request From: UserA15:28:38 29D (TRACKMOVE) BEGIN PHASE - 'MvSrcUser_DeleteMovedUser_Live': UserA (wd9) 15:28:38 29D (TRACKMOVE) Sending LIVE 'MvSrcUser_PurgeUser': UserA (wd9) 15:28:38 29D (TRACKMOVE) (.Move) Sending LOCAL Purge Notification: UserA (wd9) 15:28:38 29D (TRACKMOVE) Sending ACTION_DELETE_USER: UserA (wd9) 15:28:38 29D (TRACKMOVE) END PHASE - 'MvSrcUser_DeleteMovedUser_Live' (0 0x00000000): UserA (wd9) 15:28:38 29D *** APP DISCONNECTED, Tbl Entry=1, Check ID=111945218015:28:38 29D *** PHYSICAL PORT DISCONNECTED, Tbl Entry=0, Socket=10515:28:48 2B3 (TRACKMOVE) BEGIN PHASE - 'MvSrcUser_DeleteMovedUser_Batch': UserA (wd9) 15:28:48 2B3 (TRACKMOVE) (.Move) Purging User Data: UserA (wd9) 15:28:48 2B3 (TRACKMOVE) Attempting 'WpeDeleteUserExt': UserA (wd9) 15:28:48 2B3 Delete user/resource: UserA 15:28:48 2B3 Purge item record 15:28:48 2B3 Purge item record 15:28:48 2B3 Purge item record 15:28:48 2B3 Purge item record 15:28:48 2B3 (TRACKMOVE) Moved user deleted 'WpeDeleteUserExt' (0 0x00000000): UserA (wd9) 15:28:48 2B3 (TRACKMOVE) Completed 'WpeDeleteUserExt' (0 0x00000000): UserA (wd9) 15:28:48 2B3 (TRACKMOVE) Sending status MOVE_USER_FINISHED: UserA (wd9) 15:28:48 2B3 (TRACKMOVE) END PHASE - 'MvSrcUser_DeleteMovedUser_Batch' (0 0x00000000): UserA (wd9)

6. Errors

6.1 Detecting Errors in User Moves

There are three main ways to determine whether or not a user move has completed.

1. The User Move Status Utility in ConsoleOne. After waiting enough time for the move to process, any user who does not show status of "Move completed" (shown below) may have a problem with the move. The advantage to this monitoring method is its simplicity. You can quickly get a "yes or no" answer as to whether the move was successful. In addition, if you have moved several users, you can see several statuses at once. The disadvantage of this method is that the Move User Status utility is only updated after the source POA has finished purging the user's mailbox entirely. If the user has a large mailbox, this could take a significant amount of time and you will have to wait longer to see the status of the move. For more "real time" monitoring of the move, see points 2 and 3 below.
  
  A completed move in the User Move Status Utility

1. The log files for the source POA. Watch for the log entries listed below. If you see these, this means that the source POA has finished deleting the user and has sent a "MOVE_USER_FINISHED" status message to the Move User Status utility. If the move is successful, all of these entries will be present. These three are singled out because they are easy to see if you are watching the log scroll by.
  
  l (TRACKMOVE) Completed 'WpeDeleteUserExt' (0 0x00000000): UserA (wd9)
  
  l (TRACKMOVE) Sending status MOVE_USER_FINISHED: UserA (wd9)
  
  l (TRACKMOVE) END PHASE - 'MvSrcUser_DeleteMovedUser_Batch' (0 0x00000000): UserA (wd9)

1. The log files for the destination POA. Watch for the log entries listed below. If these entries are present, the move completed successfully. If the move is successful, all of these entries will be present. These four are singled out because they are easy to see if you are watching the log scroll by.
  
  l (TRACKMOVE) (Move.) Remaining Inventory Count: UserA (wd9). The remaining inventory count is not listed because it is zero and all items have been received.
  
  l (TRACKMOVE) (Move.) Transfer Complete. All Items Received: UserA (wd9).
  
  l (TRACKMOVE) (Move.) Sending Purge Notification: UserA (wd9). The destination POA is telling the source POA to delete the user's mailbox in the source post office.
  
  l (TRACKMOVE) END PHASE - 'MvDstUser_SendRetrievalList_LiveRetry' (0 0x00000000): UserA (wd9).

If you determine that an error has occurred in the user move, the first step is to determine what the problem was. Typically, the source POA will provide the best information as to the cause of the error. An easy way to separate the log entries that pertain to a particular move is to use the HTTP console of the POA. To do this,

1. With a web browser, go to http://<IP address of POA>:<port number of POA>. You can use the HTTP port or the client/server port. If you hit the client/server port with your browser, you will be automatically redirected to the HTTP port.

1. Click the Log Files link. Alternatively, you can go directly to http://<IP address of POA>:<port number of POA>/eventlog.

1. In the Events Containing box, enter the userID of the user in question.

1. Select which log files to search and click View Events. A list of all the log events that contain the search string from step 3 will appear.

1. Watch for anything that would not normally appear for successful move. The most common error is a D107 error, which is logged as follows:
  
  (TRACKMOVE) Could not '_NgwrepFixItem' (53511 0x0000d107): UserA (wd9)

6.2 Fixing User Move Problems

If you have a user move that appears to have not worked, these steps will help you sort things out.

1. Be patient. If the POA is busy serving other requests, it may have delayed processing move traffic.

1. Use the Move User Status utility to determine the status of the move. Commonly, the utility will return the Send Item Request state, as shown below:
  
  Example of a Common Status for a Stuck Move

1. Determine how many items remain in the inventory list. If traffic is stuck towards the end of the move, the destination POA will log something like this:
  
  14:32:14 280 (TRACKMOVE) (Move.) Remaining Inventory Count (2): UserA (wd9)
  
  Most of the time this number will be in the 1-10 items range. If more than a few items are left in the inventory list, there is a good chance that the move is not stuck, but just waiting. You can jump start the move retry by clicking Retry/Restart | Retry the last step of the mailbox move button from the User Move Status utility.

1. Determine if the user is important enough to continue. In some environments, it may be acceptable to move 998 out of 1,000 messages. Of course, this depends on organizational policy and the importance of the user being moved. If the number of items moved is "good enough," then use the Force Complete button on the User Move Status utility. Otherwise, proceed to the next step.

1. Highlight the user in question and click the Pending Items button. In the box that comes up, select Request. This causes the source POA to ask the destination POA for information regarding items that are still in the inventory list. Keep in mind that this process takes a few seconds and that there is a limit of 25 inventory list items that can be displayed. Once the process is done, a dialog similar to the one below will be presented.
  
  The Pending Items Dialog

1. In the example above, you can see that two items remain in the inventory list. Basic information about each item is also displayed. If more information is desired (especially for working with support), the "Info" button will provide more detailed properties. In nearly all cases, the basic properties will be sufficient.

1. Evaluate the contents of the inventory list to determine if the items seem important. If you determine that one of the inventory list items is critical to retain, do the following:
  - - Use the Clear Status button in the Move User Status utility to delete the move user status.
  - - Move the user back to the source post office.
  - - Have the user log in (or you log in on their behalf) and print/archive/save the critical item(s) from step 6.
  - - Delete the item in question and empty it from the trash.
  Warning: Make sure any items dealt with here are both deleted and removed from the trash so they will not interfere with the move again.

1. Re-move the user to the destination post office. Now that all of the offending items have been eliminated, the move should go through without trouble.
  
  If you determine that the remaining items in the inventory list are NOT important (for example, SPAM), you can do the following:
  - - Use the Force Complete button in the User Move Status utility. This will delete all remaining items in the inventory list, mark the move completed, and purge the user's data from the source mailbox.
  - - Try the Skip retry on the current mailbox item option. You reach this option by going to the User Move Status Utility and clicking the Retry/Restart button. This will cause the first item in the inventory list to be deleted and the move process to be retried. Sometimes one item can't be moved and other items "pile up" behind it. Removing the offending item can thus enable other items to be moved. This option is a more precise option than "Force Complete."
  - - Do nothing and wait for the 7-day retry period to expire.

7. Appendix

7.1 User move flow

Move User

The Move User process is illustrated in the following flowcharts. With GroupWise 6, Novell enabled a routine with the Move User process that allows the source POA to connect directly with the target POA and complete the move process via TCP/IP, a "Live Move". With GroupWise 6.5, that feature can be controled through the admin, ConsoleOne, snap-ins.

1. Phase 1 - Admin Rename.

1. Through ConsoleOne, either right-click an individual user, or select a block of users and right-click the block. Click Move. Select the target PO.

1. If the move will cause Internet Name changes, you are prompted to allow or ignore the name changes.
  
  Will the Internet Name change?
  
  If Yes, go to step 4.
  
  If No, go to step 6.

1. ColsoleOne prompts you to change the Internet Name:
  
  If you choose to change the name, go to step 5.
  
  If you choose not to change the name, go to step 6.

1. The user's E-Mail Address attribute in NDS is changed and replicated through the NDS Tree.

1. The owning PO for the user is changed in the source domain database.

1. An admin message is sent to the target domain with the user's new post office, domain, and userid update.

1. The target domain's MTA admin thread updates the target domain databases (wpdomain.db).

1. The target domain's MTA admin thread then creates and sends the update message to the target post office.

1. The target POA's administration handler thread changes the user's record in the host database.

1. The target POA logs and displays a message that the user has been renamed.

1. A replication message with the user update is created by the target domain's MTA. This message is sent to the rest of the GroupWise system, including all domains and post offices.

1. Each domain and post office is updated by the admin thread of its respective MTA or POA.

1. When the source POA's admin thread has changed the user's record, it creates a message to move the user.

1. The move message is moved to the source POA's input queue (post_office_directory\wpcsout\ofs\4 directory) and a POA worker thread is started for the next phase.
  
  The Admin Rename phase is complete.

1. Phase 2 - Inventory List

1. The source POA logs the move request from its admin thread.

1. The existence of the user's source database is checked by the source POA using the user's File ID (FID):
  
  If it exists, go to step 21.
  
  If it does not exist, go to step 19.

1. The POA logs the following error:
  
  (.Move) Complete: No Source Data: userid

1. The move process is terminated.

1. The user's database is checked to see if this is the first attempt at sending the inventory list.
  
  This is done by the POA, it looks for a deferred record in the user's database on the source post office.
  
  If Yes, go to step 25.
  
  If No, go to step 22.

1. The POA logs the following message:
  
  (.Move) ReInitiating: userid

1. The deferred record is incremented by 1 in the user's database.

1. The source POA worker thread creates a deferred message in the ngwdfr.db on the source post office. The message is set with a 12-hour delay.

1. The source POA logs the following message:
  
  (.Move) Initiating: userid

1. The source POA creates a deferred record in the user's database to track the number of times the inventory list is sent. The POA sets the value of this record to 0 (zero).
  
  The total number of retries is 14. Because each retry is delayed for a 12-hour period, the move process could take up to 7 days before it gives up.

1. The source POA then creates a deferred message in the ngwdfr.db on the source post office. The message is set with a 12-hour delay.

1. The user's database on the source post office is opened.

1. The POA checks to see if the user has granted access rights to other users or has proxied other users' mailboxes.
  
  This is determined by the POA, it looks for Access records and Access_To records in the user's database.

1. Are there any proxy or access records?
  
  If Yes, go to step 31.
  
  If No, go to step 33.

1. The POA creates and sends messages to fix up the proxy/access records in those users' databases.

1. The POA at the destination of each "fixup" message updates the associated user's database with the moved user's new domain.post office.userid (DPU).

1. The source POA attempts a Live Move of the inventory list.

1. The source POA checks the source post office database to see if the source or the target post offices have Live Move enabled.
  
  If Yes, go to step 35.
  
  If No, go to step 41.

1. The source POA reads the POA records for the target post office from the source post office database.

1. The source POA builds a list of all target POAs.

1. The source POA reads the first POA record from the list.

1. The source POA looks for an IP address and port defined for the target POA:
  
  If the IP address and port are found, go to step 42.
  
  If the IP address and port are not found, go to step 39.

1. Is there another POA in the list to be checked?
  
  If Yes, go to step 40.
  
  If No, go to step 41.

1. The source POA reads the record for the next POA on the list.
  
  Loop back to step 38.

1. The source POA assumes that a Live Move is not available; it will perform the move in Batch Mode instead of a Live Move.
  
  Go to step 54.

1. The source POA makes an attempt to connect to the target POA with a TCP/IP connection.

1. The attempt to connect results in 1 of 4 responses. Each will take the attempt down a different path. The possible responses are
  
  No Server
  
  Unsupported
  
  Try Later
  
  Connected

1. "No Server": A server timeout indicates no response from the target POA.

1. The source POA checks the user's database for a retry count on the deferred record.

1. The list is tried up to 3 times:
  
  If the retry count was less than or equal to 2, go to step 47.
  
  If the retry count was greater than 2, go to step 52.

1. The retry count in the user's database is incremented by 1.

1. A deferred message is created in the ngwdfr.db and set with a 15-minute delay.
  
  The source POA logs the following message:
  
  (.Move) Queue Deferred Retry Message: userid
  
  Go to step 42.

1. "Try Later": The server is there, but no threads are available.

1. The source POA rechecks the target POA record to see if Live Move has been disabled since the last check.
  
  If it has been disabled, go to step 52.
  
  If it has not been disabled, go to step 51.

1. A deferred message is created in the ngwdfr.db, at the source post office, and set with a 5-minute delay.
  
  This action is attempted until the server can accept a move or is disabled.
  
  The POA logs the following message:
  
  (.Move) Queue Deferred Retry Message: userid

1. "Unsupported": The server is there, but Live Move is not supported.
  
  The target POA is disabled or is not available for a Live move. A Batch Mode move will be executed.
  
  Go to step 41.

1. "Connected": The source POA was able to established a Client/Server connection to the target POA via TCP/IP.
  
  Each time a connection is attempted, the target POA displays the following message if it is up:
  
  C/S Login win ::GW Id=userid :: <ip address of source POA>

1. The target POA checks the user's File ID (FID) for duplicates.

1. Are there any duplicates?
  
  If Yes, go to step 56.
  
  If No, go to step 58.

1. The original FID is saved for archive fixup.

1. The user's FID is changed to be unique in the target post office.
  
  This is a rare occurrence because a post office can have up to roughly 45,000 unique FIDs.

1. The target POA checks to see if the user's database exists.

1. Does it exist?
  
  If it exists, go to step 60.
  
  If it does not exists, go to step 62.

1. The target POA creates and sends a message to the source POA to let it know that a move for this user is already in progress.

1. This Move User request is terminated.

1. The target user's database doesn't already exist, it is created the first time the target POA receives the connection attempt.

1. The source POA creates a list in memory of all items to move. The list includes
  
  Record ID - Unique identifier of item
  
  Item Type (folder, rule, mail item, group, setting, etc.)

1. The source POA checks for any shared reference books during the creation of the list.

1. Are there shared address books?
  
  If Yes, go to step 66.
  
  If No, go to step 68.

1. The shared address books are updated with the user's new DPU.

1. Fixup messages are created and sent out to update the shared distribution lists with the user's new UPD.

1. The source POA checks for any shared reference folders during the creation of the list.

1. Are there shared folders?
  
  If Yes, go to step 70.
  
  If No, go to step 72.

1. The shared folders are updated with the user's new DPU.

1. Fixup messages are created and sent out to update the shared distribution lists with the user's new UPD.

1. The source POA sends the inventory list items to the target POA.
  
  The source POA displays the following message:
  
  (.Move) Sending Inventory List: userid

1. The target POA checks the user's target database to see if a Defer Count (number of retries) has been placed there. If a Defer Count is already there, a move is currently in progress with this database and the target POA ignores the list.
  
  The target POA logs the following message:
  
  (Move.) Inventory List Received: userid
  
  The list is stored in the user's target database as inventory items-one inventory item record for each item to move.

1. The target POA checks for a prime user database (replicated database used for shared folders) on the target post office for the user being moved.

1. Was a prime user database found for the user being moved?
  
  If Yes, go to step 76.
  
  If No, go to step 78.

1. The items are moved from the prime user database into the user's database on the target post office.

1. All users on the target post office that pointed to the prime user database are updated to point to the user's database.

1. A deferred message is created that will run in 12 hours to check if the Item Request phase has been completed.
  
  The total number of retries (14) is set in the user's target database.

1. A message is created for a worker thread on the target POA to start the Item Request phase.
  
  The Inventory List phase is complete.

1. Phase 3 - Item Request

1. Is this the first attempt to retrieve items?
  
  If Yes, go to step 83.
  
  If No, go to step 82.

1. The target POA logs the following message:
  
  (Move.) Re-requesting User Data (XX): userid
  
  Where XX is the number of inventory items to retrieve.
  
  Go to step 84.

1. The target POA logs the following message:
  
  (Move.) Requesting User Data: userid

1. The target POA attempts a live retrieval of the items.

1. The target POA checks the target post office database to see if the source post office has Live Move enabled:
  
  If Yes, go to step 86.
  
  If No, go to step 87.

1. The target POA checks the target post office database to see if the target post office has Live Move enabled:
  
  If Yes, go to step 88.
  
  If No, go to step 87.

1. Do a "Batch Mode" retrieval of the items.
  
  Go to step 93.

1. The POA records for the source post office are read from the target post office database.

1. The target POA builds a list of all source POAs.

1. The target POA reads the first POA record from the list.

1. The target POA reads the record for the first POA on the list.

1. Does the source POA have an IP Address?
  
  If Yes, go to step 95.
  
  If no, go to step 92.

1. Is there another source POA in the list?
  
  If Yes, go to step 94.
  
  If no, go to step 93.

1. Retrieve the items via "Batch Mode.".
  
  Go to step 107.

1. Check the next POA in the list.
  
  Go back to step 91.

1. The target POA makes an attempt to connect to the source POA with a TCP/IP connection.

1. The attempt to connect will result in 1 of 4 responses-each will go down a different path. The possible responses are
  
  No Server
  
  Unsupported
  
  Try Later
  
  Connected

1. "No Server": The server timed out or there was no response from the target POA.

1. The target POA checks the user's database for a retry count on the deferred record.

1. The list is tried up to 3 times:
  
  If the retry count was less than or equal to 2, go to step 100.
  
  If the retry count was greater than 2, go to step 105.

1. The retry count in the user's database is incremented by 1.

1. The target POA creates a deferred message in the ngwdfr.db and set with a 15-minute delay.
  
  The target POA logs the following message:
  
  (Move.) Queue Deferred Retry Message: userid
  
  Go to step 95.

1. "Try Later": The server is there, but no threads are available.

1. The source POA rechecks the target POA record to see if Live Move has been disabled since the last check:
  
  If it has been disabled, go to step 105.
  
  If it has not been disabled, go to step 104.

1. A deferred message is created in the ngwdfr.db at the source post office and set with a 5-minute delay.
  
  This action is attempted until the server can accept a move or is disabled.
  
  The POA logs the following message:
  
  (Move.) Queue Deferred Retry Message: userid
  
  Go to step 95.

1. "Unsupported": The server is there, but Live Move is not supported.
  
  The source POA is disabled or is not available for a Live move. A Batch Mode move will be executed.
  
  Go to step 93.

1. "Connected": The source POA was able to establish a Client/Server connection to the target POA via TCP/IP.
  
  Each time a connection is attempted, the source POA displays the following message if it is up:
  
  C/S Login win ::GW Id=userid :: ip address of target

1. The target POA forms a list of all items to retrieve from the source. This list is based on the remaining inventory items in the user's target database.

1. The target POA builds the list into a message file.

1. The target POA sends the message to the source post office. The list is dispatched to the source POA, even if the list is empty.

1. Is the list is empty?
  
  If Yes, go to step 111.
  
  If no, go to step 113.

1. The target POA flags the Item Request phase as complete.

1. On receipt of the list, the source POA clears the retry (defer) count from the source database so that no more attempts are made to send the inventory list to the target.
  
  Go to step 134.

1. The source POA displays the following message:
  
  (.Move) Request for User Data Received: userid

1. The source POA forms an array of items matching those requested from the target POA.

1. The source POA sends the items (in blocks of 300 transactions) to the target POA.

1. When there are no more items of a specific type to send to the target POA, the source POA logs 1 of the following messages:
  
  (.Move) Folders Sent (XX): userid
  
  (.Move) Bag Records Sent (XX): userid
  
  (.Move) Items Sent (XX): userid
  
  (.Move) AddressBook Components Sent (XX): userid
  
  (.Move) Rules Sent (XX): userid
  
  (.Move) User Settings Sent (XX): userid
  
  where XX is the number of items sent to the target POA.

1. The target POA checks each item to make sure it is valid:
  
  If it is valid, go to step 119.
  
  If it is not valid, go to step 120.

1. When an item is added to the user's target database, the target POA logs 1 of the following messages, depending on the item type:
  
  (Move.) Folder Received: userid
  
  (Move.) Bag Record Received: userid
  
  (Move.) Item Received: userid
  
  (Move.) Rule Received: userid
  
  (Move.) AddressBook Component Received: userid
  
  (Move.) User Setting Received: userid
  
  Go to step 123.

1. If the type of the arriving item is unknown, the target POA logs the following message:
  
  (Move.) Invalid response/request: userid

1. The target POA checks the error to see if it is critical enough to terminate the process. This is rare but can happen on occasion.
  
  If the move is terminated, go to step 122.
  
  If the move is not terminated, go to step 123.

1. If the move process has an error causing the current move session to terminate, the target POA logs the following message:
  
  (Move.) Queue Deferred Retry Message: userid
  
  Go to step 80.

1. As each arriving item is added to the user's target database, the matching inventory item is deleted. If there are no more inventory items in the user's target database, the Item Request phase is flagged as complete.
  
  If the item could not be added to the database or if the inventory item could not be removed, the target POA logs the following message (if it is in verbose logging):
  
  Error: XX YY User:userid
  
  (Move.) Items Not Received: userid
  
  where XX and YY are the error code encountered. The move process continues.

1. The target POA checks to see if the item being added is part of a shared address book or a shared folder.

1. Is the item being added part of a shared address book or shared folder?
  
  If Yes, go to step 126.
  
  If No, go to step 127.

1. A fixup message with the user's new UPD is created and sent to update recipients of the books or folders.

1. Are all requested items accounted for?
  
  If Yes, go to step 128.
  
  If No, go to step 117.

1. The Item Request phase is flagged as complete and the target POA logs the following:
  
  (Move.) Transfer Complete. All Items Received: userid

1. The target POA removes the Defer Count in the user's target database.

1. The target POA logs the following message on the target POA:
  
  (Move.) Sending Purge Notification: userid

1. The target POA dispatches a Purge User action to the source POA.

1. When the source POA receives the Purge User action, it logs the following message:
  
  (.Move) Purging User Data: userid

1. The source POA purges the user's source database and drops it from the post office.

1. The Item Request phase is complete

1. The Move Process is complete.

7.2 Useful TID's

The following TID's might come handy, when doing a User move:

3020749 Queue Live Deferred Retry Message

3047279 Server too busy message during a priming of caching mailbox

3128933 Move User Guide (GroupWise 6.5, 6, 5.5)

3182760 Problem 96- Invalid duplicate field found

3246808 Unable to move user - DB08 non unique name

3438770 User move stuck in "Retry mailbox item retrieval" state

3998453 How to use GWAFE510 (Archive FID Editor) (In case the FID changes during the move)

10099453 Error on source POA 'WpeModifyItem' moving users

10097236 Unable to move user (D11B error)

10095890 C067 Data Store number is invalid

10092882 Moved Users are showing up in both Post Offices Membership Tab

10092661 Error: D70E Duplicate entry in that database

10089648 Source POA not sending mail to target post office

10087175 Users will not move (D919 on MTA)

10085451 Notify alarms don't work after moving a user to another post

10082832 GroupWise user is stuck in a Pending Move and can not be edited

10082823 Preparing for GroupWise moves

10070702 GWIA Access Rights not valid for user after a user move.

10065345 D115 after a GroupWise user was moved

10057711 Duplicate Entry (D70E) is reported when trying to move user

10022776 Known GroupWise Move Issues

Labels:

How To-Best Practice

Comment List

Parents

MigrationDeletedUser over 15 years ago

Hi Tommy,

Very nice and detailed document. Compliments!

Since moving users to whom folders, address books and calendars have been shared causes problems too (those folders will be 'orphaned' then), it's also wise to run a Folders and Address Books report with GWAVA Vertigo and unshare them before you do the move.

regards,

Roel van Bueren
- Cancel
- Vote Up 0 Vote Down
- Sign in to reply
- More
- Cancel

Comment

MigrationDeletedUser over 15 years ago

Hi Tommy,

Very nice and detailed document. Compliments!

Since moving users to whom folders, address books and calendars have been shared causes problems too (those folders will be 'orphaned' then), it's also wise to run a Folders and Address Books report with GWAVA Vertigo and unshare them before you do the move.

regards,

Roel van Bueren
- Cancel
- Vote Up 0 Vote Down
- Sign in to reply
- More
- Cancel

Children

No Data

Recommended

Menu

GroupWise Tips & Information

User Move Within GroupWise

1. Purpose

2. System preparation

3. User Move Preparations

4. Move

5. Monitoring

6. Errors

7. Appendix

Labels:

Resources