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:
- Make the NTFS partition available to Linux;
- Migrate the users and groups to Linux;
- Configure a Samba domain to replace the Active Directory domain;
- Complete the ACL configuration for the user and shared storage on Linux;
- 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
Figure 1: Active Directory management console showing our 3 test
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
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
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
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
Figure 18: Sharing for the Blues folder on the Windows server.
Figure 19: Share Permissions for the Blues folder on the Windows
Figure 20: Security Permissions for the Blues folder on the Windows
Figure 21: Members for the test group GuitarHeroes in Active
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
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
Figure 27: Disk management console showing the missing Disk 2 after
Right-click on the partition on Disk 1 and select Remove Mirror.
Figure 28: Remove Mirror pop-up window. Make sure you select the
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
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
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:
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
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
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
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
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
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
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
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
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
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
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.