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.
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.
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.
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.