Michel Bluteau

The goal of this article is to discuss a simplified scenario where user storage (home directories) and shared storage is moved or migrated from Windows NTFS to a SuSE Linux Enterprise Server 10 Samba server providing domain authentication for Windows workstations (XP Pro). The article also provides some links to further information for additional tasks to be completed in order to cover different real-life scenarios.

While there are more than one way to move storage from Windows to Linux, we will discuss an example that can adapt to different situations(same server migration or across the wire) and that is non-destructive(allows a rollback to the original state), and also that can migrate user storage in a batch fashion(smaller groups of users). We also want to make the process transparent for end-users with Windows desktops(XP Pro is used as the example).

While we will not discuss a complete and extensive approach that covers all areas, readers can easily find additional information based on references in this article to come up with a wall-to-wall procedure with automated processes for the migration. The reason why we will limit the discussion to a simplified scenario is to limit the scope and length of this document, and also because extensive documentation and how-tos exist for these peripheral requirements.

Here is a list of what we will do:

1. Make the NTFS partition available to Linux;
2. Migrate the users and groups to Linux;
3. Configure a Samba domain to replace the Active Directory domain;
4. Complete the ACL configuration for the user and shared storage on Linux;
5. Make the Windows desktops join the Samba domain.

We could also use some of the steps of this procedure to migrate a Windows desktop to a Linux desktop like SLED10, but some of the steps take advantage of Windows server capabilities like mirroring of disk partitions.

We are going to use SuSE Linux Enterprise Server 10 in our example because we want to move our user storage to an enterprise grade Linux Server that can be covered by support offerings from Novell, and also that has all the required packages in the box. Other Linux distributions like Red Hat don't include packages like ntfsprogs and offer limited support for NTFS partitions, and are subject to some reliability issues when it comes to NTFS support (check http://wiki.linux-ntfs.org/doku.php?id=ntfs-en#why_don_t_red_hat_fedora_support_ntfs).

Let's start by looking at a simplified Windows storage environment. We are managing access to the NTFS storage through Active Directory. We have a few test users with home directories, and a shared storage folder manage through a test group.

Figure 1: Active Directory management console showing our 3 test users.

Figure 2: Home directory for test user.

Figure 3: UserData (E:) drive that contains user storage.

Figure 4: Properties for the partition containing user storage.

Figure 5: Our NTFS partition for user storage(personal and shared) contains 2 root folders, Home and Shared.

Figure 6: Shared folder named Blues.

Figure 7: Home folder content for test user JLHOOKER.

Figure 8: End-user desktop, Windows XP Pro.

Figure 9: Windows desktop is a member of the domain, so accounts don't need to be maintained locally, they are managed through the Active Directory domain.

Figure 10: Mapped drives for the end-user can be assigned through the profile or logon script.

Figure 11: Personal storage(Home directory) for test user Rjohnson.

Figure 12: Shared folder Blues accessed by a test user.

Figure 13: Properties for the Home folder for test user RJOHNSON on the Windows server.

Figure 14: Sharing properties for the RJOHNSON folder on the Windows server.

Figure 15: Share Permissions for the RJOHNSON folder.

Figure 16: Security Properties for the RJOHNSON folder(NTFS ACL) on the Windows server.

Figure 17: Properties for the Blues shared folder on the Windows server.

Figure 18: Sharing for the Blues folder on the Windows server.

Figure 19: Share Permissions for the Blues folder on the Windows server.

Figure 20: Security Permissions for the Blues folder on the Windows server.

Figure 21: Members for the test group GuitarHeroes in Active Directory.

Figure 22: Partition information for the Windows server.

Now that we have quickly overviewed our Windows environment for delivering user storage, let's work on moving that storage to Linux. Let's leverage Windows mirroring to clone our partition onto a separate partition, on a separate physical disk if we don't plan to do a same server migration(run Linux on a separate box).

First, we need to convert the Disks hosting the partitions that we want to mirror to Dynamic(right-click on each Disk), and then we can create a mirror(right-click on the partition to mirror).

Figure 23: Disk 1 and Disk 2(Unallocated) converted to Dynamic.

Figure 24: Add Mirror pop-up window showing Unallocated space.

Figure 25: Disk management console while storage partitions are being mirrored. Depending on the amount of data on the partition, the mirroring operation could take from minutes to hours to complete.

Figure 26: Disk management console showing the mirrored(RAID 0) partition on Disk 1 and Disk 2.

Now we are going to shutdown the server, and remove the disk from the server. If Disk 2 is on a SAN, we can re-assign it to our Linux server. After the removal of the disk, we can reboot Windows to make sure that we can bring the server back to its original state.

While it would be possible to do an across the wire file copy, or a disk cloning operation if we are using a SAN, this method provides a faster way for moving a large amount of data if a SAN is not hosting the disks.

Once the Windows server is rebooted, we will find a broken mirror configuration.

Figure 27: Disk management console showing the missing Disk 2 after rebooting.

Right-click on the partition on Disk 1 and select Remove Mirror.

Figure 28: Remove Mirror pop-up window. Make sure you select the Missing disk.

Figure 29: Disk management console showing the partitions after Disk 2 has been removed from the mirror.

Now, our Windows server is pretty much in the same state it was before we started our procedure. We can now move Disk 2 to our Linux server, in production, or in the lab if we want to perform some testing before the real migration.

Let's move to the SuSE Linux Enterprise Server 10 server. We are going to check if some required packages are already installed, and if not, install them. Note that all the packages that we need are part of the distribution(they are on the CDs) so we are going to run Open Source, but supported Open Source(by Novell, if you registered your SLES 10 server for support).

Figure 30: Samba packages installed on SLES10.

Figure 31: ntfsprogs package which includes support for the NTFS file system.

Now let's access the Samba configuration tool in YaST.

Figure 32: Samba configuration tool in YaST.

Figure 33: Samba Installation Step 1 of 2, select Workgroup or Domain Name(default is TUX-NET).

Figure 34: Samba Installation Step 2 of 2, Select Primary Domain Controller for the Samba Server Type.

Figure 35: Samba Configuration screen for Start-up. Note that firewall ports are open only on-demand for the configured services in SLES10, which reduces security risks for network services.

Figure 36: Samba Configuration screen for Identity. You can enable WINS Server Support for one or more SLES10 server if you plan to eliminate your Windows WINS servers.

Figure 37: Samba Configuration LDAP Settings screen.

We will not setup the Samba configuration for our example in order to keep this document shorter, but I recommend that real world configuration include Samba over LDAP, with OpenLDAP or Novell eDirectory. For more information on Samba over LDAP, see the samba.org web site or other examples like: http://www.novell.com/coolsolutions/appnote/11788.html

Next we will create the users on our Linux server. With Samba over LDAP in place, we could use Novell Identity Manager and the driver for Active Directory to move our Active Directory users into Novell eDirectory, and speed up the process. But for the sake of keeping our document shorter, we are just going to create our 3 test users manually in the local Samba file.

Note also that the evaluation version of Identity Manager and the Active Directory driver could be used for a one-time migration of users and groups to eDirectory or OpenLDAP(LDAP Driver) without requiring the purchase of the product. A 30-day evaluation licence is available when you download Identity Manager from http://download.novell.com/.

For more information on Identity Manager, check http://www.novell.com/documentation/idm/index.html.

Figure 38: YaST User Management tool.

Figure 39: Our 3 test users created locally on the SLES10 server.

Figure 40: Setting up a Samba account(-a) and a password for the 3 local users.

Now let's configure access to our NTFS partition for our SLES10 server.

Figure 41: YaST Partitioner tool.

Figure 42: Expert Partitioner screen showing our disk containing the NTFS partition(/dev/sdc1).

Select the device containing the NTFS partition, and click Edit.

Figure 43: Edit Existing Partition screen.

Figure 44: Warning screen asking for validation for our choices.

Figure 45: NTFS Partition accessed locally from our SLES10 server.

Figure 46: By default, the partition will be mounted Read Only(ro).

Figure 47: You can go back to Partitioner and modify the Fstab options for the partition.

Several tools for managing NTFS partitions are available through the ntfsprogs package, and you can get more information by looking at http://wiki.linux-ntfs.org/doku.php.

But in our example we will move the data to a ReiserFS partition instead, where Home directories for our 3 test users is already configured(because we created the users locally on the SLES10 server). If we don't plan to move the partition back to a Windows server, it is a better idea to move the data to ReiserFS or another native Linux filesystem like ext3. But first, let's create our test group.

Figure 48: Creating our test group GuitarHeroes through YaST.

Figure 49: Local Home directories on our SLES10 server for our 3 test users.

Figure 50: Permissions for the personal folder for test user JLHOOKER, assigned at creation.

Next, we need one command to copy all our test users Home folders from NTFS to ReiserFS, if the folder names are identical(case sensitive) between the NTFS partition and the ReiserFS partition.

Figure 51: Copying the Home folders from the NTFS partition to our ReiserFS partition.

Figure 52: The content for the Home folder for user RJOHNSON after the copy from NTFS to ReiserFS.

Now let's create our Shared folder on the ReiserFS partition. Let's also copy the Blues subfolder under this new /home/Shared folder.

Figure 53: Creating our Shared folder under the home directory.

Figure 54: Permissions for the Blues Shared folder.

Now we need to configure a Samba share for our Blues shared folder.

Figure 55: Samba Configuration showing Shares in YaST.

Figure 56: New Share assistant.

Now we are ready for the last step, which is to configure our Windows XP desktop to authenticate into the Samba domain versus the Active Directory domain.

Figure 57: Joining the Samba domain from the Windows XP desktop(My Computer/Properties) After authenticating to the Samba domain using the root account, you should see a successful status window for joining the domain. Make sure the root account on SLES10 has a Samba account and password. You can verify through /etc/samba/smb.conf.

Figure 58: Welcome to the tux-net domain pop-up window.

Before users can authenticate against the Samba domain, some changes are required on the Windows desktop, including a registry key, a policy, and the configuration of a WINS server if it is not provided by DNS.

Figure 59: Registry key to modify for the XP desktop to be able to authenticate against the Samba domain.

You can save the modified registry key to a file, and then execute it on other XP desktops in order to apply the same changes. This could be easily automated through the logon script or a batch file.

Figure 60: Starting the Group Policy Editor on Windows XP.

Figure 61: Enabling a Policy Setting in order to allow user to authenticate against the Samba domain.

Figure 62: Configuring the WINS service on the Windows desktop if not provided by DNS.

Figure 63: Optionally, one can setup name resolution through the lmhosts file.

Now, our test users can authenticate to the Samba domain using our Windows XP desktop. If we need to configure many desktops for authenticating against the Samba domain, a central management tool like Novell ZENworks could be used to push these settings to all desktops and avoid to have to manually configure each one by hand.

Once authenticated against the Samba domain, the end-user experience can be made similar to the experience they had while authenticating against the Active Directory domain, to the point where the end-users won't be able to tell the difference.

Figure 64: Browsing shared network folders in the Samba domain.

Figure 65: Mapping a network drive for the test user Home folder.

Figure 66: Mapping a network drive for the Blues shared folder.

While the above 2 figures illustrate how to manually map the network folders(with the Reconnect at logon option selected), it is possible to create logon scripts, to handle network profiles, and to accomplish most peripheral requirements through a Samba domain, in order to make the user experience as transparent as possible.

For more information on these additional steps and other configuration topics like printing for your Samba service, see: http://www.samba.org/

Below are some direct links to some relevant sections:

Profiles and Logon Scripts: http://us5.samba.org/samba/docs/man/Samba-Guide/happy.html#id2584910

Windows Client configuration: http://us5.samba.org/samba/docs/man/Samba-Guide/Big500users.html#ch5wincfg

LDAP directories and Computer Accounts: http://us5.samba.org/samba/docs/man/Samba-Guide/happy.html#id2574938

While this article does not cover all the requirements for a migration of user storage from Windows NTFS to Linux, I hope this will help you to get started and formulate your own procedure. Again, I want to emphasize that there are many ways to move network services from Windows to Linux, and sometimes what is ideal for a given scenario may not be for a different one. But the good news is that if you are considering the move, you are not the first one, there are tons of recipes out there and real-life experiences shared by others. And most importantly, services like Samba have achieved enterprise grade level over the past few years with manufacturers like Novell which offer an extensive list of support options for those who want to move their businesses over to Linux, so really this is not restricted to enthusiasts and self-supported organizations anymore.

Please do not hesitate to send me your feedback, questions, or improvements on the procedure I described in this article, or even alternative procedures to get from A to B.