2012->2014 migration completed .... but ...

The migration went OK, as an Exchange guy this whole Groupwise thing is new to me.
Our consultant that worked through with us was great for the build, left the mailbox moves to me. Consultant is on holidays this week so I've gone and had a looksee myself to fix this up and learn the software a bit better.

But we had about 15% of the mailboxes with a stuck email or more. In order to flush them through I needed to Force Complete.

Now some of those want some of the emails back...

How would I achieve this? I have restored the userxxx.db files already from backup tapes, ready to go. I also can restore the 2012 server to pre-migration in a vmware sandbox if needed.

Cavaets:
- Cannot push mailboxes back to 2012 as we als cut over from e-Directory to Active Directory and the 2012 server doesn't have those LDAP connections.
- It appears the FileIDs changed, and I don't have a list of the FileID's prior to move
  • Righto - Let's see how we go with some answers.

    How many post offices are running? Two in total with one on 2012 en the other on 2014?

    I think 5 total, 3 on 2012 (2two used, on unused) and 2 on 2014 - though this move process was from 1 on 2012 to 1 on 2014.

    Did the consultant give you the steps needed to run through for each move (like mailbox maintenance jobs that can/should be run before a move)?
    Sometimes one has to skip a couple of items that won't transfer, which is a softer approach to the force complete.

    The consultant had run all the pre-checks and pre-move jobs prior to him leaving when we did the build.

    I'm also curious as to how many users needed items restored.

    At this point I have 2 users wanting items back, but we are just returned from school holidays today and I expect that number to increase significantly.
    Of course, all the email they want back they can easily get again (emails from the person sitting next to them etc) but instead I'm being dragged through the restore process - and yes, I have suggested they attempt to talk to that person instead of ruining a week of my life, but to no avail... users!

    You could put the 2012 PO on low security so the accounts that get moved back can be logged in to using a GroupWise password vs LDAP password. LDAP connections are not needed per se. That also makes me wonder, how were the accounts getting logged into prior to the move? But that last question is not relevant for the mailbox content restore.

    Up to this point we had e-directory as the LDAP authentication method.

    I am confident the FID's changed - the first person I tried to restore didnt have their current FID in the backup set from the 2012 server.

    Thanks for your ideas - I will try some of those and see how it works out for me.
  • retsef;2335639 wrote:
    ..Thanks for your ideas - I will try some of those and see how it works out for me.


    You are welcome, let us know how you go. :)

    Cheers,
    Willem
  • Well - I've gone and kept looking. Many of the FIDs haven't changed, but some have.
    In particular one user that has had their mailbox wiped and FID changed on the destination PO.

    I have tried bringing up the old userxxx.db on a new account (editing the FID to match) and hit a D115 Security breach (logs show its looking for the old user). I then pulled the account back to 2012, disassociated, recreated the e-directory account, and changed the FID to the old userxxx.db file and cannot get it to load - it cannot "find the file" . GWChecks aren't getting me anywhere.

    Got the consultant coming in today to give me a hand - but I'm fairly confident we will both still be hitting google on this one.
  • For googlers going forward:

    I ended up deleted the user's account, changed the FID to the userxxx.db file I was trying to use, renamed the backup to userxxx.old, logged in to create empty file (and config NGWGUARD.db file), stopped PO service, renamed files so the wanted .db is the right file.
    Ran a full GWCHECK on everything, all good.

    2012->2014 move worked fine.

    Now to look at restoring single emails from other staff's mailboxes...
  • retsef;2335774 wrote:
    I have tried bringing up the old userxxx.db on a new account (editing the FID to match) and hit a D115 Security breach (logs show its looking for the old user). I then pulled the account back to 2012, disassociated, recreated the e-directory account, and changed the FID to the old userxxx.db file and cannot get it to load - it cannot "find the file" . GWChecks aren't getting me anywhere.


    Renaming the database file to match the FID won't work indeed. Would not be very secure :)

    You indeed need to (re)create an account and edit the fid "before* trying to login to the account. The database will get created upon fist user login, not during the account creation in ConsoleOne or the Webadmin. That just creates the user entry in the main domain and po databases.

    Using the restore account option in ConsoleOne/the Webadmin will do that for you.

    Good you got things going