Reset Remote/Caching password

Yes, using the standalone GWCHECK utility, assuming you have a modern version.

Whoops. I wasn't clear.

Yes, you probably can, altho the user stands to lose some information. Its kinda messy. Frankly, the architecture expects that Cached/Remote databases are merely convenience and that nothing is going to be stored in them that isn't replicated to the Post Office on a fairly immediate/consistent basis. So the recovery options are limited.

But, you *might* be able to take advantage of the fact that a Remote/Cached mailbox is a miniature of the main Post Office, and uses the same files and database structures. Since the user's mailbox password is stored in the user database (USER.DB), you can try this.

First, after closing the GroupWise client completely (close Notify too!) rename the USER.DB file (be careful not to disturb the WPROF.DC file).

Find the GWCHECK.EXE utility in the Software Distribution Directory that was created when you installed the Primary Domain. Look for the "software" directory under "grpwise". You want the grpwise\software\admin\utility\gwcheck subdirectory.

Run GWCHECK.EXE - you'll need to do this at the machine on which the cached mailbox is located. Select "Remote/Caching" as the Database Type. Point it at the location of the mailbox ("ROFDATA" is the default directory name, but I don't know how its on that user's machine). Under the "Action" pull-down, select "Recreate User Database".

This *should* (as in I think this will work, but confess to never having done this exact thing) rebuild USER.DB, based on the NGWGUARD.DB and the MSG.DB. And since the mailbox password was stored in the USER.DB file, the new one won't have a password.

Note that they will lose all folders, rules, signatures, etc. All their E-Mail will be dumped into one big pile in the Mailbox folder. The need to decide if the mess is worth what they want to retrieve.

Try this:

* Reset the online password with ConsoleOne
* Have user open the mailbox in online mode.
* Set the password to the correct one.
* Change back to Caching mode.

-Mojo

I don't think that'll work, because the existing password will be needed to open the caching database. At least I think that's how it'd go. But hey, give it a spin.

What Mojo posted should work, since it's what TID 10082789 says.

Cool. If so, I'll stand...well, sit...correccted. :-)

Unfortunately, that TID doesn't work.

I created a caching mailbox, changed the password for the caching mailbox, and verified that I was able to log into GroupWise caching mode with the caching password, and into Online mode with the online password.
I then tried the TID.

When I tried to switch to caching mode, I still had to enter the caching password.

I think the TID is assuming you actually know the old password, which makes me wonder why you'd need to reset it.

Even more unfortunately, PsiCop's suggestion doesn't work either. GWCheck doesn't recreate the user.db if it's completely missing. :(

The "rest of the story" as Paul Harvey would say...
This isn't a data recovery situation. A guy I know has a fair-sized post office, and apparently some folks are constantly forgetting their passwords. But instead of just resetting the live password, he also has to log into the workstation and nuke the old database in order to allow a new one to be created. Also, the creation of the new caching database takes many minutes or even hours if the mailbox is big, and generates a lot of traffic. He wanted a way to avoid having to go through this process every time. In other words, he is looking for a shortcut.

Ah. Well, yes, one of the downsides of Caching Mode.

Assuming he's in an eDirectory environment and doesn't need to support IMAP or SMTP-AUTH, has he considered not bothering with GroupWise mailbox passwords? Just set the POs to High Security with eDirectory authentication?

Or is that not an option?

Not an option, as SMTP AUTH is mandatory (it's a university environment, and they've had huge spam problems in the past)

Hmmmm.....OK

I confess I'm not seeing a handy way out of this box. The Caching Mailbox isn't supposed to have anything crucial, its just a convenience. Goven that, is there anything wrong with, when a user's password must be reset, having part of the procedure be blowing away their Caching Mailbox?

Nope, and that's basically what he has been doing all along. It's mostly the time it takes to recreate the cached mailbox that he was hoping to avoid.

However I didn't ask the question only for his benefit, but also because I was interested in knowing about the possibility of recovering messages from a local database, and you've provided an answer to that question. Thanks.