Showing posts with label migration tools. Show all posts
Showing posts with label migration tools. Show all posts

Friday, July 15, 2011

miggui and OES2 SP3

Have you been seeing this error lately?

Authentication to the server failed. Unable to retrieve the tree certificate. Verify the eDirectory credentials. Refer to the migration.log for more details.


Novell has a TID related to it, #7008691 that notes it has been reported to engineering and that there is a development build of the utility that you can contact Novell support for.  Calling Novell support may not be an option for some (as most of the time you have to open a call that then is "supposed" to be reimbursed - yeah, right).  Good News Everyone!  (Imagine this in Professor Farnsworth's voice - the old guy from Futurama - and it seems much funnier).  I have a work around for this.

Are you ready?  It's really rather annoyingly simple.
  1. Verify logins are enabled on the source server.  Just to save yourself a SMH later on like I did late last night.
  2. Launch the miggui utility on the target Linux server.
  3. Log into the target server FIRST.
  4. Log into the source server LAST.
If you still get the error, then close the miggui (don't save the project) and try again.  It's usually worth the effort and has worked at sites where they're experiencing issues with SLP or DHCP or just some unknown infrastructure issue.

If that still doesn't work and you need to look at the migration.log file, simply click on the "View Logs" icon to the left of the miggui screen.  Or you can find it in the /var/opt/novell/migration//log directory.  Project Name would be whatever you saved it as.  Default names are usually NewProj#, where the # just increments by 1 the more times you launch the utility.

Refer to Novell TID#7002862 for a litany of troubleshooting tips if you're still having issues.  Or feel free to email me - although I may be slow to respond and I'll try to lend a hand.

I was very annoyed with this late last night as I've been using the miggui smoothly for sometime.  It never mattered before which way I logged into a server, and usually I could start a new project without any issues.  I'm currently working on a project where we're consolidating file structures to new servers and I need to run several iterations to attach to different servers.  It's the first project with this particular consolidation pattern on OES2 SP3 that I've had this year. Imagine my surprise when I found I have to close the miggui in between projects simply to be able to attach successfully to the next server in the list to consolidate.  Grrrr.....





Monday, January 25, 2010

Puzzling Password Issues Affecting Migration Tools

I was so hoping for a cooler acryonym, but couldn't think of any.

So, here's the scoop:  we have a PITA of a password policy.  Due in part to PCI regulations, but due mostly to the fact that our users can't "be bothered" to change their passwords beyond once a year.  (Until 2 years ago they NEVER had to change their password - EVER!) 

New policy:  15 characters, at least 2 character sets.
New problem:  The Server Migration Utility and the GroupWise Migration Utility can't handle our root passwords

Symptoms:  Works great in a testbed - where of course I use a much simpler password.  In production the tools will validate the root user account and password just fine.  But when it comes to SSH/Putty processes it fails, with a fairly generic "Failed to Authenticate" error.  When it comes to the Server Migration Utility, it's an eDir/LUM authentication failure, but for GW Migration, it's a root account authentication on the Linux box that fails.

Solution:  Make your root password less than 8 characters, no spaces, no punctuation marks - just alphanumeric characters.  It will work like a charm.  You can change it back after the migration and things will work just fine.

There is no TID on this (I've requested one be made) and you'll only find 1 forum reference (at this time) if you do a Google search on the error message listed in the log files.