By wnfrost

Over the years things change, from corporate add user policies or lack of, to the administrator who is adding the users with his or her own self-made policy. For this example we’ll use the fictitious name Another User and standardize on first initial and last name. At one time this name might have been added in all caps like AUSER and at another time this user might have been added mixing cases like AUser, and yet another time it might be all lower case auser.

While technically not a problem with administering GroupWise users, there may be instances where third party applications are case sensitive, or a thorough admin just wants to tidy up and make it pretty. Here is where the problem starts. ConsoleOne does not recognize a case change so we have to toggle it by appending a 1 (or something) to the end and then retyping the correct name in the proper case. So basically, it will have to be renamed twice. Let’s continue with the example and standardize on changing names to lower case.

Take AUSER and rename it to AUSER1 and then rename it again to auser. Seems simple enough but if there is a lag in GroupWise to eDirectory synchronization you may get an error during the second rename causing the account to be in a stuck state as AUSER1. You may not even know this error exists until the user tries to log in and can’t.

At this point if you run a gwcheck on the user on the user you’ll probably see the error…
Searching for User/Post Office information for auser
Processing Post Office = po, Store Catalog Path = /gw/po
Error 16- User auser does not exist on this Post Office
Suggestion- Supply valid name

Or if you run a gwcheck on the Post Office you’ll probably see the error…
Error 44- Database userXXX.db is invalid due to security breach!
- Verification USER_ID is "AUSER1", should be "auser"
- Please try to recover correct database from backup

A workaround for this would be to disassociate GroupWise attributes and then re-associate after the rename, but this would be a lot of overhead if we are dealing with thousands of users. The best option is to just motor through the renaming process in small batches and IF you run into the above mentioned trouble you can fix it by running a standalone gwcheck and follow these steps…

1. Point it to the Post Office that houses the user with the problem.

• For the user don't use username, use userXXX.db (fill in XXX with the File ID which can be found in ConsoleOne>User>Properties>GroupWise tab)

• Under the databases tab check off Message and User.

• Under Misc tab/Support Options type: VERIFYMODE

• Run Analyze/Fix Databases with Structure and Index checked.

• Using the same settings run Analyze/Fix Databases with Contents and Fix checked. This should fix it.

• Repeat step six a second time just to be sure there are no errors.