• State Verified Answer
  • Replies reply
    1
  • Subscribers subscribers
    16
  • Views views
    283
  • Users 0 members are here

How to Backup GroupWise 8.0 and restore user mailboxes in Windows Server 2003, and use restore areas?

Carly Fleischmann

Hello:

I've recently been playing around with backups, restores, and the like in GW 8 under Windows Server 2003.  I don't have access to a GroupWise aware backup application, so I just use the Windows Backup.

I've set up a restore area and associated it with a post office.  I then send some messages, receive others, etc. then run a backup.  I then completely trash the GW account of the test user and restore the domain to a temporary location from backup and from ConsoleOne choose Tools > GroupWise Utilities > Recover Deleted Mailbox... and browse to the domain files restored from backup and choose the target user.  I click next a couple of times and then finally finish at the success screen.  OK, mailbox recovered, now let's get those mailbox items back as follows:

1. restore the post office to the restore area.

2.  launch the GW8 client and choose File > Open Backup and browse to the restore area

2(a). cannot enter the password as the field is greyed out

3.  Abandon option 2, and from ConsoleOne at the server take the following steps:

3(a). locate the user in the post office

3(b). choose Tools > GroupWise Utilities > Backup/Restore Mailbox and then choose Yes to the question of do I want to restore the mailbox items.

4.  Wait a bit after to job has been sent to the POA (~5 Minutes as there were only less than 40 messages in the mailbox) and return to the client

4(a). don't see any restored mailbox items at all.

Do the above procedures from both a "the admin restores it" and a "then end-user restores it" perspective look right?  If so, then what's not working right?  If that's not right, what step(s) am I missing in order to allow restoration of mailboxes and their contents?

Thanks:

Carly G. Fleischmann

==

Disclaimers: I am often responding from mobile and so I apologize for the bad formatting and any auto-correct mistakes that might happen. 2) I have a team of advocates, assistants, and advisors who assist me in writing, responding to, and managing posts and community engagement; such advocates, assistants and/or advisors will clearly identify themself along with their role. Any opinions expressed by my team are the opinions of that individual and do not necessarily represent my opinions or those of my support team unless otherwise noted.

  • Verified Answer

    +1

    Quick Update as of 2024.06.07:

    I wound up fixing it on my own as follows:

    It turns out that it was a permissions issue with error number 8201.  At first googling lead me to think it had to do with the 8-character limits when it came to file/folder names that were true of older systems like DOS and NetWare but this was a false flag.  After shortening up my UNC (from something like \\melody-edir1\GWiseRestore\HoloMorgan_HM\Post to something like \\melody-edir1\Re\HM\Post it gave me error 8219 that it couldn't reach the network resource, then after browsing the the shortened UNC it still was giving 8201 which proved that the 8.3 thing was a false flag.

    So I then did more digging and something about document libraries came up (completely unrelated to backup/restore) mentioning that permissions could be to blame more specifically it mentioned something along the lines of "make sure the user running the POA at the server has the same login as at the server with the document storage area..." and this put the proverbial idea bulb over my head and I was like "wait a minute... the POA is running as "Local System" for its Windows Service login setting and both the POA and its files are on the same box... wait a minute! share permissions!".  After doing that, back to 8019 then back to 8201 and then I thought to check on the filesystem permissions and that officially fixed it.

    1. Check the share permissions (can the user see and use put things in the share over the network?) set "domain users" to full control ("Read")
    2. Check the FileSystem Permissions (can the user see the folder, make changes, delete things, etc. at an NTFS level?) again set domain users to full control (Read, List Folder Contents)

    It probably should be noted that I probably gave "domain users" way too much permission (as "full control" is effectively the "god mode" and only restoring from backup can save you if someone maliciously gets in there and messes about with things, but that fixed it.)  I will play with the share and FS permissions a bit more and see where that takes me but in case anyone needs this and stumbles across this in the future (more likely me given how likely I am to forget what I did to fix it) via search results, try this solution and see if that fixes it.  I am going to mark my own solution as the answer to ensure that it is easily findable in future (as I don't care about the trophy points... just making sure that my experience isn't lost to time)

    and to answer my own stupid question, yes... the backup tool that comes with Windows Server 2003 is good enough.  While it's not as good as a GroupWise-aware backup program... it gets the job done in a pinch.

    *** SOLUTION UPDATED AT 23:50 on 2024.06.07: Found that the minimum level of permission that domain users needs is as follows:

    • Share: Read
    • NTFS: Read, List Folder Contents

    I left my original statement about full control in place but struck it from the original answer with the formatting tools in the forums software, and placed the updated permissions next to it.  I am still leaving the original statements as follows: 1) I make mistakes and by leaving in my mistakes it shows that not everyone is 100% correct 100% of the time and 2) setting these things to full control is a valid step if even temporarily as a troubleshooting technique to make sure that it's not permissions creating the issue.  Would I recommend leaving the restore area with full control at share and filesystem level on a permanent basis?  no, I would not unless you trust everyone in your environment with your life and the life of your children and possibly your career; thus, only leave the ACLs at full control for domain users as long as it is necessary to troubleshoot the issue.

    Thanks:

    Carly G. Fleischmann

    ==

    Disclaimers: I am often responding from mobile and so I apologize for the bad formatting and any auto-correct mistakes that might happen. 2) I have a team of advocates, assistants, and advisors who assist me in writing, responding to, and managing posts and community engagement; such advocates, assistants and/or advisors will clearly identify themself along with their role. Any opinions expressed by my team are the opinions of that individual and do not necessarily represent my opinions or those of my support team unless otherwise noted.

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.