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,

To add to Laura's:
On my POs, I allow C/S and direct access. Without granting file rights to the PO structure, it doesn't cause any harm.
But this way you can restore a backup of the PO to a different location, connect the GW client to it using the /ph switch and access the backed up address book. Then export as NAB and import to the live mailbox.
No need to down the POA.

Uwe

--
Novell Knowledge Partner
Please don't send me support related e-mail unless I ask you to do so.

Unfortunately the user now has a D107 error and is "missing" the emails for the difference in the days between the two DB files ?

When he opens an email in the mailbox it appears as a different email.

I'm going to do a rebuild of their mail and hopefully this helps

any further ideas?

ahennessy wrote on 07.03.2016 10:46:
> Unfortunately the user now has a D107 error and is "missing" the emails
> for the difference in the days between the two DB files ?

You did replace the backup user.db with the previous "live" db, right?
The backed up db should only be in the PO for the short time when you export the NAB.

Uwe

--
Novell Knowledge Partner
Please don't send me support related e-mail unless I ask you to do so.

Hi UWE, I did alright,

I went back in and had a look at the user.db files Both the old one and the correct one are there (oldone named userxxx_OLD.db) I don't know if this is causing an issue so I've scheduled a down of the POA to copy this out and leave the correct DB file there. They both have timestamps of today but the old one was renamed on Friday and I didn't think it would be accessed/modified once renamed.?

I'm grasping at straws now as this is the head of IT mailbox and doesn't look too good.

cheers

Problem now is C05d error on the client and the user cannot access their email at all.

I had left the old DB file in the user folder (albeit renamed) and this seems to have caused an issue. I've cut it out now and I am getting this C05D error.

The original DB file is still in the user folder.

Any thoughts or should I go down the route of an SR?

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.

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