Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Userxxx.db not created in PO\ofuser after move

Status
Not open for further replies.
Nov 8, 2001
21
US
I moved a user from one PO to another PO but the userxxx.db was not created in the PO I was trying to move the user to. Now the address book shows that the user is part of the new PO and the log of the new POA shows the user being diverted to the old POA when she logs in. I can move the user back to the old PO and everything is fine but each time I try the move it fails the same way. Any ideas? Oh, I did a structural rebuild on the user database before the move.
 
My understanding is the user will get a new FID thus get a new userxxx.db.

Can the user login and see old mail?
Can users send to the moved person and the mail is delivered?

If the answer to this is yes, check the users FID(Groupwise Client, help about. Username, the three character code in brackets.)

Check for the new userxxx.db. Lee Smith
Xenon Network Services
Snr. Technical Support
LSmith@xenon-uk.co.uk
 
Yes, the user can login and see her email. Though the address book shows her assigned to the new PO she will always be redirected to the old PO. From there she can read her email.

Yes, I believe she gets new email but I'll have to check to again to be certain. The only wierd thing is that the Userxxx.db did not move to the new PO.

We've moved dozens of users from one PO to another and they have always kept the same FID. I confirmed this from one of Novell's how to move a user TID 10023814.
 
Hello - I seems that there was some error in the user move process that has left it in an incomplete state.

I would suggest moving the user back to the old post office so the address list and the data are actually referring to the same location - then, run some check/fix (structural first - then contents - never run these at the same time) procedures on the users databases.

Once those have run through without any errors, try setting the logging level on the POA way up so you can see if there are any errors being generated during the move process - then start the move process.

My apologies if any part of my post is 'teaching you to suck eggs'.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top