Reset Remote/Caching password

I got an interesting question I couldn't answer recently, and figured I'd ask it here.

Is there a way to reset the password for a caching mode database? It seems like
this should be possible somehow, but I can't find a way.

LVL 19
billmercerAsked:
Who is Participating?
 
PsiCopCommented:
Well, fudge.

If you have a support contract with Novell, or are willing to fork out whatever it is they're charging per-incident these days, they can crack the encryption on the USER.DB and blank the password. They'll probably need a copy of the USER.DB and the WPDOMAIN.DB databases, but they'll let you know if you go this route.

Most folx don't have anything in their Caching mailbox that isn't in their Online mailbox - generally, if there's a problem with the Caching mailbox, most folx just delete and re-create it. What's the story here?

If you have GWAVA or some other tool that functions as a "Trusted Application" under GroupWise, it may be possible to access the mailbox that way. Altho I can't say that'll work, if you have a tool like that, it won't hurt to look at that ("Trusted" apps can bypass a lot of the GroupWise internal security features).
0
 
PsiCopCommented:
Yes, using the standalone GWCHECK utility, assuming you have a modern version.
0
 
PsiCopCommented:
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.
0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
waybadmojoCommented:
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
0
 
PsiCopCommented:
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.
0
 
ShineOnCommented:
What Mojo posted should work, since it's what TID 10082789 says.
0
 
PsiCopCommented:
Cool. If so, I'll stand...well, sit...correccted. :-)
0
 
billmercerAuthor Commented:
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.

0
 
billmercerAuthor Commented:
Even more unfortunately, PsiCop's suggestion doesn't work either. GWCheck doesn't recreate the user.db if it's completely missing. :(
0
 
billmercerAuthor Commented:
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.
0
 
PsiCopCommented:
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?
0
 
billmercerAuthor Commented:
Not an option, as SMTP AUTH is mandatory (it's a university environment, and they've had huge spam problems in the past)

0
 
PsiCopCommented:
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?
0
 
billmercerAuthor Commented:
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.


0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.