Migration of Novell to Microsoft

I have performed a ga-zillion Novell to Microsoft migrations. Here are some tips to use from my experience:

When to use a third-party migration tool:

To boil down if you need to purchase a migration tool, such as Quest Software's NDS Migrator, answer these questions:

  • Is your eDirectory tree in good shape?
  • Do you wish to maintain all those user accounts?
  • Are the groups relatively well-maintained?
  • Will you need to build an Active Directory forest?
  • Do you have several hundred or thousands of user objects?
  • Do you have dozens or more NetWare volumes?
  • Is maintaining file ownership important?
  • Will your client PCs need to join an Active Directory domain?
  • Is it important that the Novell Client be removed from the PCs?
  • Do you need to transfer Macintosh files?

If you answered "yes" to any of the above questions, do yourself a favor and purchase a migration tool. DISCLAIMER: I have experience with Quest's NDS Migrator. I will make reference to it in this post, but I don't make any claims, guarantees, or endorse this product or any other migration tool. I have made this product work in my migrations every time. Your results may vary.

Directory Migration:

When using a tool to migrate, you can select the matching criteria for objects from eDirectory to Active Directory. I recommend using (Novell) GUID == SID (Microsoft). A common match many people use is CN == sAMAccountName. The account name is easier to track visually, but if you move eDirectory objects frequently, it breaks the CN match as the eDirectory CN contains the OU and Tree information. If you match on the GUID/SID moving of objects doesn't break the match. This can be very important when many thousands of objects must be migrated. If you only have a few hundred objects or have to match to an exisiting Active Directory domain it is not worth the extra effort to match GUID/SID.

Clean it up or migrate as-is?

Try to avoid the misconception that you should clean things up before you migrate. In past projects, IT leadership has expressed a desire to avoid migrating unneeded data. The problem with that paradigm is that when you hire an outside specialist to run your migration, they are the least qualified to make decisions on what to clean up and what should stay.

Instead, negotiate what you can leave behind. Learn how to make reports on empty groups, accounts which have not been used, and long forgotten test accounts. Beyond that, it is best to just do a wholesale migration of all objects. Once the migration is finished, you can use the more widespread toolset to analyze your Microsoft environment to perform on-going clean-up and maintenance.

I've had migrations where they said they didn't want to migrate anything over five years old. This was easy enough to accomplish. However, there was a legal requirement one month after the project was finished and the NetWare servers were retired. The Windows-centric admins needed to rebuild the Novell infrastructure in a lab and restore some old files. Now, I recommend migrating all the files. If you wish to apply file policies, file deduplication or file life-cycle management, it's easier to manage once it is on a more widely supported platform.

File Migrations:

Moving files and retaining the access rights (ACLs), modified/creation dates, file ownership is a critical step in a successful migration. If your volumes are hundreds of gigabytes or in the terrabyte range, I suggest a hybrid solution for migrating files. Use Microsoft's ROBOCOPY for the file transfer engine then do one or more passes with the migration tool to apply the permissions and file ownership. Robocopy is fast, but it can delete data so be careful.

NOTE: I never use the ROBOCOPY switch /COPYALL when transfering from NetWare to NTFS. It sets the ownership to Everyone which is a security risk as anyone can change the ACL on that file or folder. Instead, use /COPY:DAT

Something to consider when migrating volumes is the future path of file services in your environment. If you plan on implementing DFS, it may be wise to slightly alter your volume sources and target shares to gain some flexibility for the future.

Login Scripts/Mapped Drives:

Every Novell environment I have ever supported or retired has heavily leveraged login scripts and mapped network drives. I typically recommend that environments not rely on login scripts. However, when migrating from Novell, I recommend you develop a login script solution in Active Directory. This sub-topic can be an entire post. If you post comments requesting further input on this, I'd be happy to create a post devoted to this topic. Eventually, you should move to a DFS infrastructure and get rid of login scripts and mapped drives. Keep that in mind when you are designing a login script solution for the Microsoft environment.

Removing the Novell Client:

If you have purchased the NDS Migrator tool, it can help you join workstations to the Active Directory domain, remove the Novell Client, redirect shortcuts, and fix imbedded OLE links inside Office documents.

An option is to suppress the Novell client by switching the Gina with this registry setting:

"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL" as MSGINA.DLL instead of NWGINA.DLL

I don't recommend this as the workstation performance is impacted by the the Novell client. If you have the luxury to remove the Novell client, I would do so as part of the project. You may consider pre-deploying the removal agent. You can subsequently launch it as a shut-down script using the Local Security policy. This ties the forced reboot to a shut down event. Forced reboots are discouraged in most organizations.

Synchronizing

It's important to run frequent synchronizations in the object migrations. This keeps object attributes and group memberships synchronized. This requires maintenance as matching may break for some objects in the case of object moves or deletions. If you have multiple migration consoles such as in multi-national environments, use the import/export feature to keep the remote migration servers up-to-date.

Set-up a test environment

I always run through my migration scenarios in a lab. Then I use dummy data in the production environment before I move any live production data. Take the time to lay it out. I always learn something about the environment by replicating it in a lab. You'll need that lab as you get deeper into the project as well.

"There is always a way"

One of the great things about migrations, is that I always find a way to tackle even the most stubborn of issues. Be creative. You're an IT professional. This is what you get paid to do. I've never failed to get from point "A" to point "B" no matter how painful it was in between. Of course, your results may vary.

Comments

Ranjith S K said…
Thank you for the detailed Post.

I would like to know about your environment,

OS version ( Novel or OES)
The eDirectory Version.
How the novell user groups were migrated to OUs?
How the duplicate user names(in different groups)were migrated to OU?
Does Quest migrator do file server migration perfectly?

Thanks & Regards,
Ranjith
Greg Zook said…
I have migrated NetWare 3.12 to 6.5 and every version in between. The latest project was NetWare 6.5.

Any eDirectory version 6.x or 8.x, but not 7.x. If someone is on eDir 7.x, upgrade eDir to 8.x (or whatever the latest version is).

You can migrate users and groups to target OUs. Duplicates are not allowed in AD, but are allowed in eDir. You have to remediate those issues. I use Quest Reporter to look for duplicate account names in eDir as an early phase of the project. Often, Quest will throw in a 30 day trial of Reporter when you purchase NDS Migrator.

The Quest NDS Migrator will apply permissions very effectively, but I won't say perfectly. You have to set up the traversal rights (Quest professional services or your SME can provide a non-supported script which can assist with this). Also, there is no Rename Inhibit or Delete Inhibit equivalent in NTFS. Another oddity is Supervisor permissions on the NetWare file system are forced inheritance to every object beneath it. The NDS Migrator tool will stamp Full Control to every file and folder on the NTFS side. So be aware of that.

Certain characters such as international vowels, trademark symbols and an apostrophe will generate an error. These files must be remediated by reviewing the logs. In international migrations, this can be a chore.

Another glitch with NDSM is when performing delta migrations, it doesn't track deletions very well.

I use Robocopy or some other utility as the file transfer engine as it moves data quicker and will purge deleted files and folders very well. It also supports nearly every character and language.
lourh said…
Hi Greg,

Thanks for explanations above,
I m working to analyse a migration project from Novell NDS 6.5 to Windows 2008 and from GroupWise to Exchange 2007. I will use Windows 2003 and Exchange 2003 during transition phase. I will use only Microsft Tools, but i have some questions if there are some limitations ? and if it s recommended to use a third party tool like Quest.

it is an important environment with thousants of objects.

Thanks
Chuck said…
One thing you have to be careful with in using NDS Migrator is that if you use Robocopy you should do it at the end of the migration if at all. Using Robocopy does not copy the information to the SQL database and would be a problem if doing partial migrations.

Chuck
Greg Zook said…
Chuck: I use Robocopy when using Quest's NDS Migrator as the file synch doesn't delete folders or read only files if they are deleted on the source. Also Robocopy will transfer files that the more fragile NDS Migrator engine chokes on due to extended ASCII characters in the file or folder names. I have seen issues with mismatches in the SQL database, but those issues are trivial compared to folders not being deleted.
slade1 said…
We are migrating from Novell OES to Microsoft Server 2008R2. We have 16 different Novell servers acros the U.S. with between 10-300 users at each site.

We completed our first migration last week at 1 office. We had to leave the novell client on- incase they need to get another server that is still on Novell.

Users in this office can see their migrated data- but when they access a folder - the files do not appear all the time . Also, when they open a file via Win Explorer- they may get not responding or they have to select the file again.

We have moved the old servers nds replica to new server, put the machines in 1 gb port, removed novell client, ran a defrag but we still see slowness.

Have experienced this? We don't wan to continue if we still have this issue?

Thank you.
KaRS
slade1 said…
We are migrating from Novell OES to Microsoft Server 2008R2. We have 16 different Novell servers acros the U.S. with between 10-300 users at each site.

We completed our first migration last week at 1 office. We had to leave the novell client on- incase they need to get another server that is still on Novell.

Users in this office can see their migrated data- but when they access a folder - the files do not appear all the time . Also, when they open a file via Win Explorer- they may get not responding or they have to select the file again.

We have moved the old servers nds replica to new server, put the machines in 1 gb port, removed novell client, ran a defrag but we still see slowness.

Have experienced this? We don't wan to continue if we still have this issue?

Thank you.
KaRS
Ranjith S K said…
Dear KaRS,

The slowness of the file access are usually because of the following reasons.
'Microsoft windows network' has less priority compared to Novell.
Netware handles the request for microsoft servers and hands over the request only after timeout.

First issue can be solved by changing the provider order from network properties.

There are two workaround for second issue.
a) Set the microsoft servers as 'bad servers' in novell client configuration.
b) set the timeout value too low.

I have done these through a vbscript and applied once to my users and are not complaining about slowness now,

Ranjith
Ranjith S K said…
Dear KaRS,

The slowness of the file access are usually because of the following reasons.
'Microsoft windows network' has less priority compared to Novell.
Netware handles the request for microsoft servers and hands over the request only after timeout.

First issue can be solved by changing the provider order from network properties.

There are two workaround for second issue.
a) Set the microsoft servers as 'bad servers' in novell client configuration.
b) set the timeout value too low.

I have done these through a vbscript and applied once to my users and are not complaing about slowness now,

Ranjith
kk said…
LOGIN SCRIPTS
"If you post comments requesting further input on this, I'd be happy to
create a post devoted to this topic"

Yes Please.
Can I have some help on this
Greg Zook said…
Thanks for your comment, kk! Login Scripts are so 1990s! Use Group Policy Preferences (GPP) instead: http://technet.microsoft.com/en-us/library/cc731892(WS.10).aspx

If for some reason you cannot use GPP,such as a Windows 2003 domain, you can create a VBS login script that will map drives. You can locate login scripts inside GPO or on the user account "Profile tab." You may find you will need to use both for "one-offs" if you have them in Novell. Personal login scripts can be re-written and launched from the "Proflie Tab" while container scripts in eDirectory should use a shared login script in a GPO. Read this link for an excellent FAQ on Windows-based Login scripts: http://www.rlmueller.net/LogonScriptFAQ.htm

Try to use GPP! It gets rid of that old technology and is worth the time to learn and implement.
Ricky Mitchum said…
Thanks for sharing the useful information. Advance Novell GroupWise to Exchange migration software is a perfect and quick migration utility which efficiently moves unlimited no of mailboxes from Novell Groupwise to Microsoft Exchange Server. You can securely movel all your emails and other data from GW to MS Exchange Server/ MS Outlook. It also allows to migrate GroupWise Archives into MS Outlook PST files.

thanks
banlin mithra said…
HI Greg,

Thanks for sharing this great information.I am working on these migrations.This info is very much useful.
Exchange Migration

Popular posts from this blog

ADMT fails to migrate SID History

Exchange 2010 event errors 2601, 2604, 2501

Robocopy Error 31 A device attached to the system is not functioning