Unfortunately many companies have left the Novell religion and migrated their systems to a Windows environment. Fortunately, the is a way to redeem yourselves and return to the flock. Novell provides a set of keen migration utilities, included with the Open Enterprise Server 2 SP1 installation.
Migrating from Windows to OES2 SP1 does not provide a simple, straightforward GUI to migrate all the services. File Share migration uses a nice GUI utility, everything is manual and command line based. Not overly difficult, really. There are a few things to that need to be considered before you can start. There are specifics, but here's what I used and suggest to make sure that you don't hit any road blocks.
eDirectory admin or equivalent
Domain Admin or better (Enterprise Admin)
root access for setting up prerequisite packages on the OES 2 SP1 Linux server.
Now, once we've obtained those, we're ready to proceed with what we have to do to start the migration process.
The samba client is installed by default on SLES 10 SP2, unless specified during installation.
The Windows source must be a Domain Controller with PDC-E role or for NT, a PDC. If you're thinking that this isn't for you, you can promote your "file server" to a PDC or PDC-E temporarily for the migration and then demote it when you're done.
The Windows file data to be migrated must be a Share. It probably already is, just make sure that there is a Share for it defined and exported.
You should have created an NSS volume on the OES2 SP1 server following installation.
That's all. If you've completed or met the items listed above, then we're ready to migrate.
Before we start, let's see what the migration utilities cannot do. The current version has the following limitations as well as the ones listed in the text below:
All Windows users and groups are migrated into a single eDirectory container.
Only Windows user and group objects are migrated no other Active Directory objects are migrated.
Windows Encrypted File System (EFS) is not supported.
Only the following user attributes are migrated:
description
mail
facsimileTelephoneNumber
fullName
givenName
initials
language
physicalDeliveryOfficeName
postOfficeBox
postalCode
st
street
telephoneNumber
title
Only Windows Allow rights are supported.
Only user rights assigned in the security permissions are supported, file sharing permissions are not.
Special Windows file types such as DFS junctions are not supported.
Windows File Share Migration
We will be doing most of the migration process from the OES2 SP1 server, since that's where the migration utilities reside.
Run YaST, and select Open Enterprise Server and Migrate Windows Shares.
Click Create a New Migration Project:
By default, the path chooses your home directory and Desktop. If you're root, then it's /root/Desktop/. You can either type in or browse to the location where you want the project.xml file to be saved. Enter a name for the project or you can use newProject.xml (default).
Click Forward
Enter your PDC's IP or DNS name. Enter your credentials for the Windows domain, as specified earlier. The Secure Socket Layer (SSL) box is grayed out because SSL is not an option for Windows as a source server. Weird, I know, but the underlying utility uses this option for other migration scenarios, not related to Windows migrations.
Click Forward to continue.
If you have errors, Authentication Failure or some such, check the availability to the Windows source server and accounts used. We've all mistyped passwords before.
Once you've setup the source connection, let's setup the target.
Enter the OES2 SP1 server's IP or DNS name. Enter the user name and password for the eDirectory tree. Use the LDAP format, using commas as delimiters.
Ex: cn=admin,o=org
If you want to use SSL, ensure that Require TLS for Simple Binds for the LDAP Group associated with this server is checked. Use iManager to perform this task, if needed. Be aware that Windows doesn't support SSL in this scenario.
Click Forward.
Click Add.
Select the Windows Share you wish to migrate from the Source Volumes field.
Select the OES2 SP1 target volume from the list shown. If you do not select any target volumes, the first volume listed will be selected by default.
When you are satisfied with your selections, click Forward.
Select options for migrating the Windows Users and Groups. Determine whether you want only the Windows users and groups that are assigned trustees to the data on the Share or if you want all of the users and groups in the entire domain migrated.
Enter the target context you want these users and groups place in the eDirectory tree. Use LDAP format.
Ex: ou=winobjects,o=org
If the target context does not exist, it will be created.
Selecting Statically Apply Trustee Rights is non-functional with this release of OES migration utilities. Inheritance is selected regardless.
Select other migration options. Whether or not you want to overwrite existing files, a date filter (useful on refreshes of a previous migration), and Type filter, if any.
Click Forward.
Review the migration option summary and expand each to ensure your selections are correct. If not, then click Back and make any necessary corrections. At this point you can save your project file and exit. Perhaps you wanted to make a template for other servers. Your project file is XML so you can copy it to other OES2 SP1 servers and edit it depending on your comfort level.
At this point, you can click Migrate and watch the progress screen.
If there are any errors during the migration process, you can click View Log and review the entries to find where your problem might lie. Then you can correct the issue and re-run the utility. Once you've gotten everything migrated successfully, click Exit.
Wasn't so bad. Now let's look at other services.
DNS and DHCP
Migrating DNS and DHCP from Windows to OES2 SP1 is a manual process, but fairly simple. In a nutshell, you export the zones in DNS and scopes in DHCP, edit them to resemble RFC designated formats, then import them into iManager for that server.
One note of DNS zones: When you import a DNS zone into eDirectory, using the provided utilities, if there is an existing zone defined in eDirectory, it will be deleted and then recreated with the import data, not concatenated. If you want to import a DNS zone, add the existing entries to the import file before importing the zone. This will save you a ton of work if you're not careful. I always export the existing DNS zone prior to any imports.
After you have imported your zones and scopes, assign your OES2 SP1 server to service them. Restart the daemons on the server and done. Test each prior to release into your environment.
Printers
OES 1 Linux had an iPrint utility called iprintmig.exe, that was for migrating Windows printers to iPrint on OES 1 Linux, but it doesn't work well with OES 2 SP1, and it never supported clustering.
Until someone writes something more up to date, printer re-creation is the alternative unfortunately.
Web Services
This is easy. Aside from internal MS-type embedded IIS specific code, true HTML and the related web languages port directly to Apache Web server. Simply define Document Root and and Virtual Hosts as needed, transfer your files and some config tweaking, and you'll be in business. Java-based web services may need a bit more configuration, depending on which Application server you use.
Migrating Windows Shares to OES2 SP1 Linux – Command Line Version
Performing the migration from the command line is performed in a specific order and is critical. The following is a list of utilities and a brief explanation of each.
migfiles – The main migration utility. Actually copies the files from the source (Windows) to the target (OES2 SP1 Linux). It mounts the Windows Share using the CIFS mount and transfers the data using RSync.
ntuserls – Reads the Windows Share and generates a list of users and groups who have rights to the files stored on the Share.
ntfsmls – Reads the ACLs and rights from the Windows Share and outputs a list that can be redirected to a text file.
maptrustees – Maps users and groups from an output file listing in Windows users and groups to eDirectory.
migtrustees – Creates the users and groups from the generated list in eDirectory.
ntfsmap – Map rights and trustees from a generated list to the NSS or NCP trustee rights.
migrights – Assign the rights / trustees to the file structure on the OES2 SP1 Linux server.
These are the steps, in order, to achieve the migration. Note: Because user/group/trustee lists are generated by several utilities and used by others later in the procedure. I'll show examples of each command as we go through the steps.
From a terminal console, run the migfiles utility to copy the source data to the target.
migfiles -n -w -s 192.168.10.200 -v WindowsShare -i -V NSSOES2
When that's complete, run the ntfsmls utility and redirect the output to a text file.
ntfsmls -s 192.168.10.200 -v WindowsShare > sharerights.txt
Run the ntuserls utility to gather the users and groups who have rights to the source files.
ntuserls -g -s 192.168.10.200 sharerights.txt > userrights.txt
Run the maptrustees utility to map eDirectory users and groups from the output file of Windows users and groups.
maptrustees -s 192.168.10.200 -C dc=users,dc=myaddomain,dc=com -k ou=newusers,o=org -S password userrights.txt > maptrustees.txt
In this example, the -S password assigns the word "password" as the eDirectory password. If you want randomly generated passwords, use the -r option and the generated passwords will be shown in the output file, (maptrustees.txt).
Use migtrustees to create the users in the target eDirectory tree.
migtrustees -d 192.168.10.25 maptrustees.txt
Use ntfsmap to map the users and groups in eDirectory to their files on the NSS Volume.
ntfsmap -n -k ou=newusers,o=org -V NSSOES2 sharerights.txt > newmap.txt
Finally, assign rights on the target volume.
migrights -i newmap.txt > migvolrights.txt
For more information on these utilities, use man to see all the options with explanations.
Conclusion
Although these utilities are limited and still in constant development, as with any Open Source project, they provide an avenue to help us in achieving a successful migration. It is up to us to use them and find new ways to improve the process. Perhaps a utility you write might be included in the next OES build!
Enjoy!