retsef Absent Member.
Absent Member.
1639 views

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
Labels (1)
0 Likes
6 Replies
Knowledge Partner
Knowledge Partner

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

Hi & welcome to the forums!

retsef;2335418 wrote:
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.


To get a better "feel" of the environment, some questions:

How many post offices are running? Two in total with one on 2012 en the other 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.

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

retsef;2335418 wrote:
Now some of those want some of the emails back...


The best way to do this is (imo), to first move the user back to the original PO, and then use a GroupWise restore area to restore items to the users mailbox. Then run mailbox maintance and if all is well, move the mailbox to the intended PO.

Info on the Restore Area 2012: https://www.novell.com/documentation/groupwise2012/gw2012_guide_admin/data/abcggai.html
and 2014: https://www.novell.com/documentation/groupwise2014/gw2014_guide_admin/data/adm_db_restore_mailbox.html

* when running 2014 it's a rule to always use the 2014 Webadministration tool... for these actions ConsoleOne with the latest 2012 (when working against a 2012 or lower version domain databse) should also work.

Out of curiosity, how much is missing?

retsef;2335418 wrote:

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


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.

FileID's, or FID in short, will only change if an existing account in the destination PO has the same FID. Otherwise it will stay unchanged.

If the FID is different and you move back the account, you'll probably not be able to recover items from a Restore Area as the FID won't match... not sure about this, as I have never hit that particular scenario.

Info on recovering GroupWise accounts 2012: https://www.novell.com/documentation/groupwise2012/gw2012_guide_admin/data/akd3r5f.html
and 2014: https://www.novell.com/documentation/groupwise2014/gw2014_guide_admin/data/adm_db_restore_account.html

You do have the option, depending on important the end user finds this and how much items are missing, to simply rename the current GroupWise account (so it's clear what's what) and then restore the original account on the 2012 GroupWise PO and do the item restore. Both account restore and mailbox restore are options in ConsoleOne as well as in 2014's webadministration console. Then use something like a shared folder to move items from one mailbox to another. Lastly cleanup when done so only one account remains for that user and is named consistently again.

That last bit is only needed if you have indeed "lost" the original FID and due to that, that you are not able to recover items from the restore area.
0 Likes
retsef Absent Member.
Absent Member.

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

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.
0 Likes
Knowledge Partner
Knowledge Partner

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

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
0 Likes
retsef Absent Member.
Absent Member.

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

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.
0 Likes
retsef Absent Member.
Absent Member.

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

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...
0 Likes
Knowledge Partner
Knowledge Partner

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

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 & thanks for feeding it back!

Cheers,
Willem
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.