How to recover from a stuck user move with D109 Bad Parameter error

  • 7008300
  • 06-Apr-2011
  • 26-Apr-2012

Environment

Novell GroupWise 8 Support Pack 2 Hot Patch 2

Situation

Problem:
User1 from Domain1, Post Office 1 (PO1) is moved to Post Office 2 (PO2), Under Domain2.  The move then becomes "stuck" in the Administrative portion of the move and never completes. 


Symptoms - After the stuck move :
1.  In ConsoleOne, being connected to the Primary domain - Domain1 ( user source ), in the GroupWise view, the user shows up as a member of the source PO1 under Domain1.

2.  In ConsoleOne, being connected to the destination domain - Domain2, in the GroupWise view, the user shows up as a member of the destination PO2 under Domain2.

3.  In the Post Office Address book of PO2, the user shows also as being a member of the destination PO2.

4.  In the post Office Address book of PO1, the user shows as being a member of the source PO1.

5.  No moved messages or calendar items make it to the destination Post Office (PO2) mailbox for User1.

6.  ConsoleOne, "User Move Status" utility shows the "Last Move Status" is "Move in Progress" and the "Error" is listed as "0xD109 Bad Parameter".


Purpose:
To know how to best recover from this "stuck" GroupWise user move with the error "D109 Bad Parameter", listed in the User Move Status utility.  For the purposes of this document the ultimate goal is to get the user back to the original source Domain and Post Office PO1 mailbox and to access the mail successfully.  After this a later attempt to move back to the destination PO2 Post Office can be made, only after first running a “Validate†on the source and destination Post Offices in GroupWise System Operations in ConsoleOne, that likely will help remove the cause for the D109 Bad Parameter error.

Resolution

Resolution:

1.  Verify that User1 mailbox (userxxx.db) is still a member of the source PO1 address book by logging to the GroupWise mailbox for User1 (source PO1) and look in the Address book and verify that User1 is still listed as belonging to PO1.  Also check if all the mail is still present and assessable as it should be.

Also check in the \PO1\ofuser directory and verify that his "full" userxxx.db file is in the directory.  An empty userxxx.db is about 87k in size.  For this type of failed stuck move in the Administration portion of the move, the user normally is still a member of the source post office from the perspective of it's WPHOST.DB file.

2.  While being connected to each respective domain in the GW View (involved in the move) , Source and Destination Domains and the Primary domain ( if the Primary is not the source or destination ) you need to clear any pending operations for the User1 ObjectID in question, AND "Clear Status" in the "User Move Status" utility for User1.

In the User Move Status utility in ConsoleOne, Tools, GroupWise utilities, select the User1 ObjectID and select the "Clear Status" button to remove User1 from the list.

To clear ALL pending operations, select Tools, GroupWise system Operations, "Pending operations...", select the Pending operations and select "UNDO".  Make note of any pending operation that has nothing to do with the failed move and deal with that later.

Again do this while connected to each domain involved in the move which includes the Primary.

3.  Before we make any attempt to further correct the move problem, we need to have at least the source domain (Domain1) (ideally All domains), destination (Domain2)  and primary domains agree with where the user is currently located.  This also would include the source PO1 and destination PO2.  This normally would involve GroupWise Domain and Post Office rebuilds in ConsoleOne, Under Tools, GroupWise Utilities, System Maintenance, while hiliting the desired GroupWise Domain or Post Office in the GroupWise view to be rebuilt, while being connected to the Primary domain of course.

This assumes that the Primary Domain has the correct information about the user move (User1 is a member of the source Post Office). 

If this is not the case, but at least one GroupWise secondary domain (lets say Domain3) does have the correct information about User1 (lists User1 as member of PO1), it may be necessary to “Convert Secondary to Primary†which promotes a secondary domain (Domain3) to a primary domain in the GroupWise system. When you do this, the current primary domain is demoted to a secondary domain. The MTA and POA agents must be running to perform this conversion.

If this is needed, this is accomplished by being connected to the current Primary domain in the GroupWise view, hilite the Secondary Domain Domain3, and selecting Tools, GroupWise Utilities, System Maintenance, “Convert Secondary to Primaryâ€. After this is complete, you now should have a “new†Primary domain that believes User1 is a member of the source Post Office PO1.  At this point it would be required to do a top down rebuild of all Secondary Domains and Post Offices, so the system is in sync with regard to this user USER1.  After the rebuilds when the system is in sync again, you can use this same procedure to promote the old Primary  Domain to again be the current Primary Domain.

4.  At this point to attempt to clear up the cause of the D109 Bad Parameter error , be connected to the Primary Domain in ConsoleOne and in the GroupWise View, hilite the Primary, and select Tools, GroupWise Utilities, System Maintenance, Validate Database.  Now for the purposes of this document , the Primary was the source domain in the move, but if your move was not involving the Primary domain, use this same procedure to hilite the other domains and Post Offices we have discussed and Validate them.


To Validate a Post Office you of course would want to be connected in the GroupWise view to it's owning domain.
At this point you should be in a position to retry the move to the destination Post  Office again.

Additional Information

1.  Should be noted that the GroupWise Administrator did perform the normal required and suggested steps, before the user move, of running the 2 runs of Analyze and Fix, Structure and Fix problems, then Content and Fix problems on both User and Message databases.

2.  The administrator also ran the Miscellaneous options of "Attclip" and "Deldupfolders" when the Gwcheck contents check was run.

3.  The administrator was connected to the destination GroupWise Domain - Domain2, when the move was initiated.