Moving Users with GroupWise 6 - This document describes the Move/Rename User procedure for GroupWise 6.
(Last modified: 26Feb2003)
This document (10067358) is provided subject to the disclaimer at the end of this document.
goal
Moving Users with GroupWise 6 - This document describes the Move/Rename User procedure for GroupWise 6.
fact
Novell GroupWise 6
fix
Move/Rename User
This document describes the Move/Rename User procedure for GroupWise 6.
I. Definitions:
A. source · The post office the user is being moved from.
B. target · The post office the user is being moved to.
C. live move · Moving the user·s data using Live Remote technology
D. batch move · Moving the user·s data using individual message files
E. PO · Post Office
F. POA · Post Office Agent
G. MTA · Message Transfer Agent
H. ADA · Administration Agent
I. C/S thread · A thread in the POA that handles C/S requests
J. Worker thread · A thread in the POA that handles message files.
K. FID · file ID of the user
L. Domain database · GroupWise admin database (wpdomain.db) that contains information about all GroupWise objects.
M. Host database · (wphost.db) Replicated copy of domain database that exists in every Post Office
N. userid · user id of user being moved
O. Rename versus Move · A user rename is defined as changing the user·s userid without changing his Post Office. A user move is defined to be a Post Office change.
P. UPD · Internal GroupWise address of the user: userid.postid.domainid
II. Phases
A. There are 2 phases in the Rename procedure
1. Admin Rename · This occurs on all POs in the system.
2. Fixups · Items that need to be updated are processed during this phase.
B. There are 4 phases in the Move procedure:
1. Admin Rename · This occurs on all POs in the system.
2. Inventory List Phase · A list of items in the user·s source database is created and stored in the user·s target database.
3. Item request phase · The target POA requests a list of items from the source POA and those items are sent to the target and added to the user·s database.
4. Source purge phase · Once all items have been moved, the source database is purged and dropped.
III. Detailed description of the Rename Procedure:
A. Phase 1 · Admin Rename
1. Through ConsoleOne a user is selected individually then Right-Clicked and Rename selected.
2. The new userid is entered.
3. A replication message is sent to all Post Offices.
4. The ADA thread of each PO will change the user·s record in the host database for that PO and display a message stating that the user has been renamed.
5. The source POA·s ADA thread will created a message to rename the .user for the source POA·s worker threads.
B. Phase 2 · Fixups
1. The POA will log the message :
(.Move) Initiating: userid
2. The existence of the user·s database will be checked using his FID. If the database doesn·t exist, the message:
(.Move) Complete: No Source Data: userid
will be logged and the rename will be complete.
3. The user·s database will be opened.
4. If the user has granted access rights to other users, or has proxied into other users· mailboxes, messages to fix up the proxy/access records in those users· databases will be sent out (message files).
5. The new userid is updated in the user·s database:
a) Subscriber Record
b) SubscibeTo Record
c) Verification Record
6. Shared Address Books (either the user·s or ones shared with the user) are updated and messages to fixup the distribution lists are sent.
7. Shared Folders are updated just like shared address books.
IV. Detailed description of the Move Procedure:
A. Phase 1 · Admin Rename
1. Through ConsoleOne a user is selected either individually or as a block of users, Right-Clicked and Move selected.
2. The Target PO is selected.
3. If the move would cause Internet Name changes, the administrator is prompted to allow or ignore the name changes.
4. The owning PO for the user is changed in the domain database.
5. A replication message is sent to the target PO.
6. The target POA·s ADA thread will change the user·s record in the host database and display a message stating that the user has been renamed.
7. A replication message is sent to all remaining Post Offices.
8. The ADA thread of each remaining PO will change the user·s record in the host database for that PO and display a message stating that the user has been renamed.
9. When the source POA·s ADA thread has changed the user·s record, it will create a message to move the user for a source POA·s worker thread.
B. Phase 2 · Inventory List Phase
1. The POA will log the message :
(.Move) Initiating: userid
if this is the first attempt at this phase. If it is not the first,
(.Move) ReInitiating: userid
will be logged instead.
2. The existence of the user·s source database will be checked using his FID. If the source database doesn·t exist, the message:
(.Move) Complete: No Source Data: userid
will be logged and the move will be complete.
3. The source database will be opened.
4. If the user has granted access rights to other users, or has proxied into other users· mailboxes, messages to fix up the proxy/access records in those users· databases will be sent out (message files).
5. .; If this is is the first attempt for this phase:
a) A deferred message will be created that will run in 12 hours to check that this phase has completed.
b) The total number of retries (14) will be set in the user·s source database.
6. Attempt Live Move of Inventory List:
a) If the source PO has had Live Move disabled, or the source POA has had Live Move disabled, or the target PO had had Live Move disabled, the move process will fall back to batch mode (step 7).
b) The POA records for the target PO will be read from the host database.
c) For each target POA object that has an IP address and port defined, an attempt will be made to connect. The possible results are:
(1) Server timeout (nothing at that address) ·NO SERVER
(2) Server there, but Live Move not supported · UNSUPPORTED
(3) Server there, but no threads available · TRY LATER
(4) CONNECTED
d) Each time a connection is attempted, the target POA will display if it is up:
C/S Login dos ::GW Id=userid :: ip address of source
e) The target user·s database will be created the first time the target POA receives the connection attempt if it doesn·t exist.
f) The list will be tried 3 times or until a valid connection has been made. If no connection was made, then Live Move will do one of the following:
(1) NO SERVER · Defer the Inventory List Move message for 15 minutes and return. If we have already deferred twice, treat as UNSUPPORTED. The source POA will log the message:
(.Move) Queue Deferred Retry Message: userid
(2) TRY LATER · Defer the Inventory List Move message for 5 minutes and return. This action will be attempted until the server can accept a move or is disabled. The POA will log:
(.Move) Queue Deferred Retry Message: userid
(3) UNSUPPORTED · Fall back to batch mode (step 7).
g) The POA will now create a list in memory of all items to move. The list includes:
(1) Record ID · Unique identifier of item.
(2) Item Type (Folder, rule, mail item, group, setting, etc.).
h) If any shared reference books or shared reference folders are encountered during the creation of the list, fixup messages are created and sent out to update the shared distribution lists with the user·s new UPD.
i) The source POA will display:
(.Move) Sending Inventory List: userid
j) The inventory list will be dispatched to the target POA over the client server connection.
k) The target POA will check 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, this means a move is currently in progress with this databa.se and the target POA will return.
l) The target POA will log:
(Move.) Inventory List Received: userid
m) The list will be stored in the user·s target database as inventory items; one inventory item record for each item to move.
n) If the FID for the user is changing as part of the move, the original FID will be saved for archive fixup.
o) If a prime (replicated database) for the user exists on the target PO, items from it will be moved into the user·s target database.
p) A deferred message will be created that will run in 12 hours to check that the Item Request phase has completed.
q) The total number of retries (14) will be set in the user·s target database.
r) A message will be created for a worker thread on the target POA to start the Item Request Phase and the POA will return.
7. Batch Mode Inventory List Move · If Live Move could not be run or is not enabled and a deferred live retry will not be attempted, Batch Mode will run:
a) The POA will now create a list in memory of all items to move. The list includes:
(1) Record ID · Unique identifier of item.
(2) Item Type (Folder, rule, mail item, group, setting, etc.).
b) If any shared reference books or shared reference folders are encountered during the creation of the list, fixup messages are created and sent out to update the shared distribution lists with the user·s new UPD.
c) The source POA will display:
(.Move) Sending Inventory List: userid
d) The inventory list will be dispatched to the target POA as a message file, transported by the MTA(s).
e) When the target POA receives the inventory list message file, it will log into the user·s target database. If the database does not exist, it will be created.
f) The target POA will check the user·s target database to see if a defer count (number of retries) has been placed in the database. If a defer count is already there, this means a move is currently in progress with this database and the target POA will return.
g) The target POA will log:
(Move.) Inventory List Received: userid
h) The list will be stored in the user·s target database as inventory items; one inventory item record for each item to move.
i) If the FID for the user is changing as part of the move, the original FID will be saved for archive fixup.
j) If a prime (replicated database) for the user exists on the target PO, items from it will be moved into the user·s target database.
k) A deferred message will be created that will run in 12 hours to check that the Item Request phase has completed.
l) The total number of retries (14) will be set in the user·s target database.
m) The target POA will immediately execute the Item Request phase on the same worker thread as the one that stored the Inventory List.
C. Phase 3 - Item request phase
1.&n.bsp; If this is the first attempt to retrieve items, the POA will log:
(Move.) Requesting User Data: userid
If this is a reattempt the POA will log:
(Move.) Re-requesting User Data (XX): userid
where XX is the number of inventory items to retrieve.
2. Attempt a live retrieval
a) If the target PO has had Live Move disabled, or the target POA has had Live Move disabled, or the source PO has had Live Move disabled, the retrieval process will fall back to batch mode (step 3).
b) The POA records for the source PO will be read from the host database.
c) For each source POA object that has an IP address and port defined, an attempt will be made to connect. The possible results are:
(1) Server timeout (nothing at that address) · NO SERVER
(2) Server there, but Live Move not supported · UNSUPPORTED
(3) Server there, but no threads available · TRY LATER. This result will be returned if the source POA won·t accept any more concurrent prime/move connections
(4) CONNECTED
d) Each time a connection is attempted, the source POA will display if it is up:
C/S Login win ::GW Id=userid :: ip address of target
e) The list will be tried 3 times or until a valid connection has been made. If no connection was made, then Live Move will do one of the following:
(1) NO SERVER · Defer the Item Request message for 15 minutes and return. If we have already deferred three times, treat as UNSUPPORTED. The target POA will log the message:
(Move.) Queue Deferred Retry Message: userid
(2) TRY LATER · Defer the Item Request message for 5 minutes and return. This action will be attempted until the source POA can accept a move or is disabled. The target POA will log:
(Move.) Queue Deferred Retry Message: userid
(3) UNSUPPORTED · Fall back to batch mode (step 3).
f) The target POA will form 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.
g) The list is dispatched to the source POA even if it is empty.
h) If the list is empty the item request phase is flagged as complete.
i) On receipt of the list the source POA will clear the retry (defer) count from the source database so that no more attempts will be made to send the inventory list to the target.
j) The source POA will display:
(.Move) Request for User Data Received: userid
k) The source POA will form an array of items matching those requested from the target POA and in blocks of 300 transactions will send those items to the target POA.
l) When there are no more items of a specific type to send to the target POA, the source POA will log one 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.
m) When an item is added to the user·s target database, the target POA will log one of the following 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
If the type of the arriving item is unknown, the target POA will log:
(Move.) Invalid response/request: userid
n) 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.
o) If the item being added is a shared address book or shared folder that the user has shared with others, a fixup message will be created and sent to update recipients of the book/folder with the user·s new UPD.
p) If the item could not be added to the database, or the inventory item could not be removed, the target POA will log:
Error: XX YY User:userid (if verbose)
(Move.) Items Not Received: userid
where XX and YY are the error code encountered. The move process will continue.
q) If the move process has an error causing the current move session to terminate, the target POA will log:
(Move.) Queue Deferred Retry Message: userid
and the process will be restarted at step 1 of the item request phase.
r) If the item request phase is flagged as complete, the target POA will:
(1) log a message on the target POA:
(Move.) Transfer Complete. All Items Received: userid
(2) remove the defer count in the user·s target database,
(3) log a message on the target POA:
(Move.) Sending Purge Notification: userid
(4) dispatch a Purge User action to the source POA
s) When the source POA receives the Purge User action, it will log a message:
(.Move) Purging User Data: userid
t) The source POA will purge the user·s source database and drop it from the Post Office.
3. Batch Mode Item Request · If Live is not enabled or the max number of live attempts were reached, batch mode will be used to request items:
a) The target POA will form 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.
b) The list is sent to the source POA as a message file even if it is empty.
c) If the list is empty the item request phase is flagged as complete.
d) When the source POA receives the list, it will clear the retry (defer) count from the source database so that no more attempts will be made to send the inventory list to the target.
e) The source POA will display:
(.Move) Request for User Data Received: userid
f) The source POA will create a message file for each item that matches an item requested from the target POA will send it to the target POA.
g) When there are no more items of a. specific type to send to the target POA, the source POA will log one 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.
h) When an item is added to the user·s target database, the target POA will log one of the following 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
If the type of the arriving item is unknown, the target POA will log:
(Move.) Invalid response/request: userid
i) 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 target POA will:
(1) log a message on the target POA:
(Move.) Transfer Complete. All Items Received: userid
(2) remove the defer count in the user·s target database,
(3) log a message on the target POA:
(Move.) Sending Purge Notification: userid
(4) dispatch a Purge User action to the source POA.
j) If the item being added is a shared address book or shared folder that the user has shared with others, a fixup message will be created and sent to update recipients of the book/folder with the user·s new UPD.
k) When the source POA receives the purge message, it will log:
(.Move) Purging User Data: userid
and the user·s source database will be purged.
V. Concurrent Moves
A. Starting Concurrent Moves
1. To move multiple users at the same time, simply select a block of users in ConsoleOne, right-click and select Move. Continue as with a single user.
2. There is no theoretical limit to the number of moves that can be started at the same time. It will be difficult to monitor the moves, however. The limiting factor will be the POA (i.e. how many threads are available to do the move).
B. Limiting Concurrent Moves
1. The target POA can accept as many inventory list push attempts as there are C/S worker threads available. If no threads are available, the result will be NO SERVER.
2. The number of threads available for C/S work can be set as follows:
a) ConsoleOne:
(1) Open the Properties of the POA object.
(2) Select GroupWise/Agent Settings
(3) Make sure the Enable TCP/IP (for Client/Server) is checked.
(4) Enter (or scroll) the number of TCP Handler Threads to what is required.
b) Command line parameter to POA · Use the command line switch /tcpthreads-X to set the number of C/S threads.
3. The source POA can also be configured to limit the number of C/S thread.s by setting the number of threads as in V.B.2 above.
4. In addition, the number of C/S threads that the source POA will allow to be used by Live Move Item requests can be limited:
a) ConsoleOne:
(1) Open the Properties of the POA object.
(2) Select GroupWise/Agents Settings.
(3) Verify total # of C/S threads (see V.B.2 above).
(4) Scroll down to Max thread usage for priming and moves.
(5) Enter (or scroll) the percent of C/S threads that priming (Cache mode initial synchronization) and Live Move can use.
b) Command line parameter to POA · Use the command line switch /priming-X where X is the percent to allow to be used.
5. If an attempt is made by the target POA to connect to the source POA to request items, and the source POA won·t accept the connection as too many threads are being used, the result of TRY LATER will be returned and the target POA will defer the attempt for 5 minutes (see IV.C.2.c and IV.C.2.e).
VI. Notes
A. The POA will log messages starting with (.Move) or (Move.). The position of the period is used to denote the source or target side; if the period is in front (.Move) then this POA is the source.
B. All messages/operation that have been deferred can no longer run concurrently and will be processed one at a time by a single worker thread..
document
| Document Title: | Moving Users with GroupWise 6 - This document describes the Move/Rename User procedure for GroupWise 6. |
| Document ID: | 10067358 |
| Solution ID: | NOVL68148 |
| Creation Date: | 08Jan2002 |
| Modified Date: | 26Feb2003 |
| Novell Product Class: | Groupware |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.