Hi Anthony,

Here's a TID that you may find useful: https://www.novell.com/support/kb/doc.php?id=7004825

It is a little "old" but the principle remains the same. I've done this countless time with tremendous success. I do, however, suggest that you perform this action after hours as I have always had need to restart the POA.

Please let us know how it goes.

Cheers,

Laura,

This worked thanks - and YES - it is recommended out of hours work as it kicked out any webaccess users.

I had to re-initialise the user in GMS and the contacts re-sync'd.:cool:

Hi Anthony,

So glad that PAB is back in place :) I completely forgot about GMS - so sorry! Thank you for the feedback.

Cheers,

Hi Anthony,

So glad that PAB is back in place :) I completely forgot about GMS - so sorry! Thank you for the feedback.

Cheers,

laurabuckley;2421864 wrote:
Hi Anthony,

So glad that PAB is back in place :) I completely forgot about GMS - so sorry! Thank you for the feedback.

Cheers,

I opened an SR on this issue. I ended up corrupting the ngwguard.db in my eagerness to fix the problem. You know what they say... more haste less speed.

The TID is to be amended apparently and hopefully it will be. How did I cause such problems you might ask....

Well when I renamed the users current userxxx.db I renamed it to userxxx_OLD.db IN THE Postoffice\OFUSER folder. copied the restored one in to the OFUSER folder and fired up the POA. This was not a good idea as the POA seemed to get confused over the odd .db file.

I would suggest the following amendments to the TID:

START
Restore a copy of the user database (<post office>\OFUSER\USERXXX.DB) that contains the PAB. TO AN ALTERNATIVE LOCATION
* Exit the GW Client if running and rename the current USERXXX.DB in the <post office>\OFUSER directory - MOVE IT TO A TEMPORARY LOCATION (cut and paste).
* Copy the restored USERXXX.DB into the <post office>\OFUSER directory
* Launch the GroupWise client and export the PAB. (In one incident it was necessary to exit and reload the POA for the deleted PAB to show using the restored USERXXX.DB.)
* Copy the current USERXXX.DB back in place and import the address book. CUT OUT THE RESTORED ONE AND MOVE BACK THE ORIGINAL TO THE OFUSER FOLDER MAKING SURE TO NAME IT CORRECTLY.
* Start the POA

END

If you find that leaving the db files are better in the ofuser folder then when renaming them DO NOT USE A .DB EXTENSION. (for example rename userxxx.db to userxxx.sav and NOT userxxx_OLD.db as I did). :(

Thankfully I am back up and running after spending 2 hours on support chat - no data lost.

Hi Anthony,

Oh gosh - so sorry that you ran into these problems. I totally forgot to warn you about what extension to rename the user db to whilst completing this routine. So glad that you have it sorted though and I do look forward to an updated TID with a warning about this.

Thanks for your feedback.

Cheers,

Anthony,

I assume leaving the .db file extension caused the problem. I usually rename stuff to userxyz.bk or some such.

Uwe