SUSE Conversations


Open Enterprise Server 2 SP1 Migration Guide – Windows NT/2K+

mfaris01

By: mfaris01

March 9, 2009 4:33 pm

Reads:92

Comments:0

Rating:0

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.

Note: NCP/POSIX volume listed indicates NetWare Core Protocol volume on a Linux system. NSS is listed accordingly. Also, the Remove All button is just for show. Not really, it doesn’t work and is intended for future use.

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.

Note: The migration utility does not preserve Active Directory structure and will place all users and groups in a single container. It also only migrates User and Group objects only.

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 
Note: if you have spaces in any of the contexts, i.e., ou=Salt Lake City,o=org, be sure you put quotes around the parameter. “ou=Salt Lake City,o=org”

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!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags:
Categories: Open Enterprise Server on SLES, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

Comment

RSS