Planning a File Server Migration | Migrating from Microsoft Windows NT Server 4.0 to Windows Server 2003

When you migrate files to a new server running Windows Server 2003, you need to plan for hardware and software compatibility and for meeting business goals, as well as planning the migration itself. It is highly recommended that you use the migration opportunity to create or update a standard file server configuration. This involves defining a specific server hardware and software combination that works well for your organization and requires minimal maintenance. A specific standard file server configuration varies from business to business, and the needs of your organization might dictate more than one standard configuration.

Planning and carrying out a file server migration involves the following tasks :

Determine whether to create or update a standard file server configuration.
Select to deploy either general purpose or Windows Powered Network Attached Storage servers.
Determine the amount of RAM and CPU performance you require.
Determine your storage requirements.
Plan for securing data stored on your servers.
Plan and carry out the migration of data to new Windows Server 2003 “based servers.

These tasks are described in the following sections.

Using a Standard File Server Configuration

To maximize the reliability, availability, and performance of file servers, use one or more standard hardware and software configurations for file servers in your organization. Using a standard configuration for file servers provides a number of benefits:

You experience less complexity managing and maintaining the hardware. Instead of learning to perform hardware tasks on multiple types of file servers, you need only learn the task once.
You reduce the amount of testing that must be done when updating drivers or applications on the file server. Instead of testing the fixes on multiple hardware configurations, you can test the updates on one file server and then deploy the updates to the other file servers.
You can keep fewer spares on-site. For example, if you use the same type of hard disks in all file servers, you need fewer spare disks, reducing the cost and complexity of providing spares .

If your organization already has a standard file server configuration, make sure that it is supported on Windows Server 2003. To determine if your standard file server configuration is supported on Windows Server 2003, or to plan for updating your configuration or creating a new one, carry out the remaining tasks described in the following sections.

Choosing the File Server Type

Two types of servers run Windows Server 2003: general-purpose servers and Windows Powered Network Attached Storage.

General-purpose servers

A general-purpose server can function in a number of roles, including domain controller, print server, Windows Internet Name Service (WINS) server, Dynamic Host Configuration Protocol (DHCP) server, application server, or an e-mail or database server. General-purpose servers provide administrators with the flexibility to configure server software and hardware as they choose. Administrators perform the necessary configuration and optimization that the server requires to perform its role.

Windows Powered Network Attached Storage

Windows Powered Network Attached Storage solutions are dedicated file servers running Windows 2000 Server or Windows Server 2003. With built-in support for UNIX and Apple file protocols, Windows Powered Network Attached Storage solutions offer seamless integration in a heterogeneous environment.

Table 4.1 describes the features and capabilities of each file server type.

Table 4.1: Features and Capabilities of File Server Types
Description	General-Purpose Server	Windows Powered Network Attached Storage
Comes preinstalled with Windows 2000 or Windows Server 2003.	X ^[1]	X
Offers the file system, security, reliability, and scalability features of Windows 2000 or Windows Server 2003.	X	X
Can provide services for purposes other than file sharing, such as domain controller or print, WINS, or DHCP server.	X
Can run applications, such as Microsoft SQL Server 2000 or Exchange 2000 Server.	X
Comes preconfigured with NFS, File Transfer Protocol (FTP), AppleTalk, HTTP, WebDAV, UNIX and NetWare protocol support.	X	X
Can be deployed in as little as 15 minutes.		X
Can run Windows SharePoint Services	X
^[1] Some general-purpose servers come preinstalled with the appropriate operating system; however, other general-purpose servers require you to configure the volumes and install the operating system

Some hardware vendors offer Windows Powered Network Attached Storage solutions in a cluster configuration. If your organization requires highly available servers, consult your hardware vendor for more information.

Determining RAM and CPU Specifications

As hardware continues to improve, hardware vendors frequently change the RAM and CPU configurations in the servers they offer. Use the information about performance improvements and scaling factors in the sections that follow to choose the hardware that best meets your organization s needs.

Reviewing Windows Server 2003 CPU Specifications

Table 4.2 describes the recommended CPU speed and number of processors supported by Windows Server 2003.

Table 4.2: CPU Requirements for Windows Server 2003
Specification	Windows Server 2003, Standard Edition	Windows Server 2003, Enterprise Edition
Minimum recommended CPU speed	550 MHz	550 MHz
Number of CPUs supported	1 “4	1 “8

Reviewing Operating System Performance Improvements

Even if you plan to use existing hardware to run Windows Server 2003, you can benefit from performance enhancements available in Windows Server 2003, as well as client and server protocol improvements available when using clients running Windows XP Professional.

Table 4.3 describes performance improvements that can be gained by migrating to new operating systems on identical hardware.

Table 4.3: Operating System Performance Improvements on the Same Hardware
Current Server and Client Operating Systems	New Server and Client Operating Systems	Improvement Factor
Microsoft Windows NT Server 4.0 with Windows NT Workstation 4.0 clients	Windows Server 2003 with Windows XP Professional clients	Up to 2.75X

These figures are based on the following assumptions:

The server is uniprocessor (UP), 2P, 4P, or 8P.
For each comparison, the server hardware is the same.
No memory, disk, or network bottlenecks prevent the processor from performing at full capacity.

Determining RAM Specifications

Using adequate RAM in file servers ensures that Windows Server 2003 can temporarily cache (store) files in memory, reducing the need to retrieve files from disk. Table 4.4 describes the minimum recommended RAM and maximum RAM for Windows Server 2003.

Tip

Increasing the amount of RAM significantly reduces the time required to run Chkdsk.

Table 4.4: Minimum and Maximum RAM for Windows Server 2003
RAM Specification	Windows Server 2003, Standard Edition	Windows Server 2003, Enterprise Edition
Minimum recommended RAM	256 megabytes (MB)	256 MB
Maximum RAM	4 gigabytes (GB)	32 GB

Determining Storage Specifications

It is important to make sure that file servers have adequate, fault-tolerant storage. When determining storage specifications, perform the following tasks:

Estimate the amount of data to be stored.
Plan the amount of storage for each server configuration.
Determine the maximum volume size .
Plan the layout and redundant array of independent disks (RAID) level of volumes.

The following sections describe each of these steps.

Estimating the Amount of Data to Be Stored

When you estimate the amount of data to be stored on a new file server, include the following information:

The amount of data currently stored on any file servers that will be migrated onto the new file server.
The amount of replicated data that will be stored on the new file server, if the file server will be a replica member.
The amount of data that you will need to store on the file server in the future.

A general guideline is to plan for faster growth than you experienced in the past. Investigate whether your organization plans to hire a large number of people and whether any groups in your organization are planning large projects that require extra storage.

You must also take into account the amount of space used by operating system files, applications, RAID redundancy, log files, and other factors. Table 4.5 describes some factors that affect file server capacity.

Table 4.5: Factors That Affect File Server Capacity
Factor	Storage Capacity Required
Operating system files	At least 1.5 GB. To allow space for optional components , future service packs , and other items, allow an additional 3 GB to 5 GB for the operating system volume.
Paging file	1.5 times the amount of RAM, by default.
Memory dump	Depending on the memory dump file option that you choose, the amount of disk space required can be as large as the amount of physical memory, plus 1 MB.
Applications	Varies according to the program, which can include antivirus, backup, and disk quota software; database applications; and optional components, such as Recovery Console, Windows Services for UNIX, and Windows Services for NetWare.
Log files	Varies according to the program that creates the log file. Some applications allow you to configure a maximum log file size. You must make sure that you have adequate free space to store the log files.
RAID solution	Varies. For more information about the RAID solutions, see Planning the Layout and RAID Level of Volumes later in this chapter.
Shadow copies	Ten percent of the volume by default, although increasing this size is recommended. For more information about shadow copies, see Designing and Deploying File Servers in Planning Server Deployments of the Microsoft Windows Server 2003 Deployment Kit (or see Designing and Deploying File Servers on the Web at http://www.microsoft.com/reskit/).

Planning Storage for Each Server Configuration

The amount of disk space that is supported by a file server can be in the terabytes if the server is connected to high-capacity, direct-attached storage arrays or storage area network (SAN) “connected external storage arrays. However, your goal should not be to attach as much storage as possible to a file server. Instead, plan the amount of storage on a file server by examining your current backup solution and answering the following questions:

How quickly do you need to restore data? In other words, do you need to be able to restore data and get the file server up and running within eight hours? Twenty-four hours? Verify that you can restore data within the required time.
How much data can your backup solution contain? Your backup solution should have the capacity to back up the entire file server.
How much time do you have to complete your backup? You must be able to perform a full backup within a period of time that is acceptable to your organization and users. For organizations that use hardware-based snapshots and backup software that can back up open files, the backup window might not be an issue.

If your organization provides file services to groups who have different storage requirements, you can design file server configurations with different amounts of storage. For example, a low-end file server might have 100 GB of storage, but a high-end file server might have 400 GB of storage. Because the high-end server will typically support more users, make sure that the RAM and CPU configuration is more robust than for the low-end server.

Important

If you choose file server hardware that supports future storage expansion, answer the previous questions taking the additional storage into account. In other words, if you add more storage to an existing file server but cannot back up or restore the file server in the required time, you must deploy additional file servers or acquire a backup solution that can handle the extra storage.

Backup solutions are becoming faster and more sophisticated. If your current backup solution is not meeting your organization s needs, investigate new solutions, such as those that provide the following types of benefits:

Many backup programs, including the backup program that is available in Windows Server 2003, can back up files that are open, allowing administrators to back up a server without having to disconnect users or shut down processes that might have files open.
Some backup programs offer software-based snapshots that take point-in-time images of a volume, creating virtual replicas without physically copying the data. Servers running Windows Server 2003 provide a similar feature, known as shadow copies . For more information about shadow copies, see Designing and Deploying File Servers in Planning Server Deployments of the Microsoft Windows Server 2003 Deployment Kit (or see Designing and Deploying File Servers on the Web at http://www.microsoft.com/reskit/).

Determining Maximum Volume Size

Volume sizes often vary, but it is important to set a maximum volume size. NTFS supports volumes up to 256 terabytes minus 64 kilobytes (KB) (2 ³² clusters minus 1 cluster), but it is recommended that you take the following factors into account when you determine the size of volumes in your file servers.

Backup and restoration times

Sizing your volumes to be the same size or smaller than your backup solution s capacity is a good guideline but not an absolute rule. For example, some organizations might back up files on a per- folder basis rather than on a per-volume basis. In this case, the organization would make sure that the size of each folder is smaller than the backup solution. This method, however, requires more backups ” one for every folder. In the event that you must restore the data, this method also requires more restorations to restore all the folders on the volume, increasing the overall complexity and length of the process. Because emergency restorations are often done in a hurry and under pressure, let restoration time and simplicity be your guide for sizing volumes.

Chkdsk times

Although file system errors are rare on NTFS volumes, you need to consider the time required to run Chkdsk to repair any errors that occur. Chkdsk times are determined by the number of files on the volume and by the number of files in the largest folder. Chkdsk performance has improved significantly since Windows NT 4.0 and Windows 2000. As a result, downtime due to Chkdsk should be minimal. However, it is important to avoid having volumes that contain so many files that Chkdsk requires longer to complete than the amount of downtime your users can tolerate .

To determine how long Chkdsk takes to complete, run Chkdsk on a test server with a similar number of files as those stored on a typical file server volume. Based on these results, you can limit the number of files to be stored on a volume so that Chkdsk can complete within the acceptable time limit.

Note

Windows Server 2003 provides some Chkdsk parameters that shorten the time required to run Chkdsk. However, if the volume contains file system errors, you must consider the volume at risk until you are able to run a full Chkdsk. For more information about running Chkdsk, see Chkdsk in Help and Support Center for Windows Server 2003.

If you need to store a large number of files on a file server and are concerned about Chkdsk times, you can distribute the files on separate volumes on the file server. If, however, you need those files to appear as though they are on a single volume, you can use mounted drives . When you create a mounted drive, you mount one local volume at any empty folder on another local NTFS volume. For example, you can create a folder called Data on volume E and then mount volume F to that folder. When you open the Data folder, the contents of volume F appear.

Mounted drives are also useful when you want to add more storage to an existing volume without having to extend the volume. For more information about mounted drives, see Using NTFS mounted drives in Help and Support Center for Windows Server 2003.

Planning the Layout and RAID Level of Volumes

When you design a standard hardware configuration, determine what type of data you plan to store on the file server, the RAID type and level that is appropriate for each data type, and how you plan to divide the disk space into volumes.

Evaluating Data Types

Table 4.6 describes the types of data that are typically stored on file servers and the disk I/O characteristics of the data. Knowing the I/O characteristics can help you choose the RAID level that offers the best performance for that particular type of I/O. If you have other types of data stored on the file server, be sure to estimate their I/O characteristics as well.

Table 4.6: Data Types and Their Characteristics
Data Type	Description	Disk I/O Characteristics
Operating system	The operating system, drivers, and any applications installed on the server, such as antivirus, backup, or disk quota software.	Server startup consists mostly of large reads, because the data required for startup is optimized on the disk. After startup completes, the disk I/O is mostly small reads.
Paging space	Space used by the paging file.	If the server memory is sized correctly, the disk I/O consists of small reads and writes. If the server experiences heavy reads and writes , the server needs more memory.
User and shared data	Documents, spreadsheets, graphics, and other data created by users and stored on the file server.	For user and shared data, disk I/O must be measured on a workload-by-workload basis.
Application files	Software that users install or run from the network.	For application files, disk I/O must be measured on a workload-by-workload basis.
Log files	Files used by database, communications, or transaction applications to store a history of operations (for example, the FRS log file).	Small or large writes, depending on the application.

Choosing Between Hardware and Software RAID

Many computer manufacturers provide server-class computers that support hardware-based RAID. With hardware RAID, you use the configuration utility that is provided by the hardware manufacturer to group one or more physical disks into what appears to the operating system as a single disk, sometimes called a virtual disk or logical unit (LUN) . When you create the virtual disk, you also select a RAID level. Hardware RAID typically provides a choice of RAID-0 (striped), RAID-1 (mirrored), RAID-5 (striped with parity), and in some servers, RAID-0+1 (mirrored stripe). After creating these virtual disks, you use the Disk Management snap-in or the command-line tool DiskPart.exe in Windows Server 2003 to create one or more volumes on each virtual disk.

If your server hardware does not have built-in hardware RAID support, you can use the software RAID provided in Windows Server 2003 to create RAID-0 volumes, RAID-1 volumes, and RAID-5 volumes on dynamic disks. Although software RAID has lower performance than hardware RAID, software RAID is inexpensive and easy to configure because it has no special hardware requirements other than multiple disks. If cost is more important than performance, software RAID is appropriate. If you plan to use software RAID for write-heavy workloads, use RAID-1, not RAID-5.

Note

Before you can use the software RAID in Windows Server 2003, you must convert basic disks to dynamic disks. In addition, dynamic disks are not supported on cluster storage. For more information about basic disks, dynamic disks, software RAID, and disk management, see the Server Management Guide of the Microsoft Windows Server 2003 Resource Kit (or see the Server Management Guide on the Web at http://www.microsoft.com/reskit).

Choosing the RAID Level

Choosing the RAID level involves a trade-off among the following factors:

Cost
Performance
Availability
Reliability

You can determine the best RAID level for your file servers by evaluating the read and write loads of the various data types and then deciding how much you are willing to spend to get the performance, reliability, and availability that your organization requires. Table 4.7 describes four common RAID levels; their relative costs, performance, and availability; and their recommended uses. The performance descriptions in Table 4.7 compare RAID performance to the performance of just a bunch of disks (JBOD) ” a term used to describe an array of disks that is not configured using RAID.

Table 4.7: Comparing RAID Levels
Factors	RAID-0	RAID-1	RAID-5	RAID-0+1
Minimum number of disks	2	2	3	4
Usable storage capacity	100 percent	50 percent	(N-1)/N disks, where N is the number of disks	50 percent
Fault tolerance	None. Losing a single disk causes all data on the volume to be lost.	Can lose multiple disks as long as a mirrored pair is not lost.	Can tolerate the loss of one disk.	Can lose multiple disks as long as a mirrored pair is not lost.
Read performance	Generally improved by increasing concurrency.	Up to twice as good as JBOD ( assuming twice the number of disks).	Generally improved by increasing concurrency.	Improved by increasing concurrency and by having multiple sources for each request.
Write performance	Generally improved by increasing concurrency.	Between 20 percent and 40 percent worse than JBOD for most workloads.	Worse unless using full-stripe writes (large requests ). Can be as low as 25 percent of JBOD.	Can be worse or better depending on request size.
Best use	Temporary data only	Operating system Log files	Operating system User and shared data ^[2] Application files ^[3]	Operating system User and shared data Application files Log files
^[2] Place user and shared data on RAID-5 volumes only if cost is the overriding factor. ^[3] Place application files on RAID-5 volumes only if cost is the overriding factor.

When determining the number of disks to compose a virtual disk, keep in mind the following factors:

Performance increases as you add disks.
Mean time between failure (MTBF) decreases as you add disks to RAID-5 or RAID-0 arrays.
RAID-0+1 almost always offers better performance than RAID-1 when you use more than two disks.
Usable storage capacity increases as you add disks, but so does cost.

Using Dynamic Disks with Hardware RAID

Using dynamic disks with hardware RAID can be useful in the following situations:

You want to extend a volume, but the underlying hardware cannot dynamically increase the size of LUNs.
You want to extend a volume, but the hardware has reached its maximum LUN size.

Before converting hardware RAID disks to dynamic disks, review the following restrictions:

If you plan to use hardware snapshots of dynamic disks, you cannot import the snapshot again on the same server, although you can move the snapshot to other servers.

For more information about dynamic disks, see Dynamic disks and volumes in Help and Support Center for Windows Server 2003. For best practices on using dynamic disks, see article 329707, Best Practices for Using Dynamic Disks on Windows 2000-Based Computers, in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

If a server contains multidisk volumes, review the following issues:

If you are upgrading from Windows NT Server 4.0 to Windows Server 2003, verify that your backup software and hardware are compatible with both Windows NT Server 4.0 and Windows Server 2003. Next , back up and then delete all multidisk volumes (volume sets, mirror sets, stripe sets, and stripe sets with parity) before you upgrade, because Windows Server 2003 cannot access these volumes. Be sure to verify that your backup was successful before deleting the volumes. After you finish upgrading to Windows Server 2003, create new dynamic volumes, and then restore the data.
If you are upgrading from Windows NT Server 4.0 to Windows Server 2003, and the paging file resides on a multidisk volume, you must use System in Control Panel to move the paging file to a primary partition or logical drive before beginning Setup.
If you are upgrading from Windows 2000 Server to Windows Server 2003, you must use Disk Management to convert all basic disks that contain multidisk volumes to dynamic disks before beginning Setup. If you do not do this, Setup does not continue.

Configuring the New File Server

This chapter assumes that you are configuring a new server running Windows Server 2003. Windows Server 2003 allows you to configure the server for single or multiple roles within your organization. One of the basic needs of any organization is the need for file servers. File servers provide a central location for files to be stored and make it easier to backup user s files.

The best way to set up your new Windows Server 2003 “based file server is to use the Configure Your Server Wizard and choose the File Server role from the list of choices. If you are going to combine file and print services on this server, also choose the Print Server role.

Planning File Server Security

Planning for file server security is vital for protecting your organization s sensitive or business-critical files. When planning for file server security, you need to protect not only the data but the physical server as well. In addition, if you plan to implement availability strategies, such as DFS or clustering, you need to take additional steps to secure the resources associated with these features.

Ensuring the Physical Security of Each File Server

For file servers that must maintain high availability, restrict physical access to only designated individuals. In addition, consider to what extent you need to restrict physical access to network hardware. The details of how you implement physical security depend on your physical facilities and your organization s structure and policies. You should also implement methods to restrict access to backup media and any instruction sheets that you create, such as the instructions that go in the recovery manual for a file server. If you allow unauthorized people to study documentation or configuration manuals, they can quickly cause harm to the system if they are able to obtain access.

Even if the physical server is in a secure room, the file server might still be accessible through remote administration tools. Therefore, implement methods for restricting access to remote administration of file servers, and ensure that remote administration tools do not weaken your organization s security model. For example, remote administration tools do not always use strong authentication protocols, such as Kerberos V5, to authenticate users across the network. You might be able to implement weaker protocols, such as NTLM, depending on the remote management tool you use and the operating system that is running on the host you are administering. In addition, certain remote administration tools might transmit unencrypted data (plaintext) across the network. This makes your data vulnerable to network sniffers.

For more information about security and remote administration, see the Server Management Guide of the Microsoft Windows Server 2003 Resource Kit (or see the Server Management Guide on the Web at http://www.microsoft.com/reskit).

Planning Baseline Security

The Windows 2000 Server Baseline Security Checklist provides instructions for configuring a baseline level of security on servers running Windows Server 2003. The checklist contains tasks such as using NTFS, using strong passwords, disabling unnecessary services, disabling unnecessary accounts, and more. For more information about the baseline security checklist, see the Windows 2000 Server Baseline Security Checklist link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Run the Microsoft Baseline Security Analyzer (Mbsa.exe for the graphical user interface version; Mbsacli.exe for the command-line version). For more information about the Microsoft Baseline Security Analyzer, see the MBSA link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

To further enhance security, review the Microsoft Windows Update Web site regularly for patches that fix vulnerabilities and provide security enhancements. For more information about Windows Update, see the Windows Update link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Planning Virus Protection for File Servers

To protect file servers from viruses, plan to take the following precautions :

Use Windows Server 2003 “compatible antivirus software, and regularly update virus signature files.
Back up files regularly so that damage is minimized if a virus attack does occur.

Planning Access to Shared Folders

When you plan access to shared folders, determine the type of permissions to use, who needs access to the folders, and the level of access that users require. You can also disable administrative shares and hide shared folders.

Determining the Type of Permissions to Use

Permissions define the type of access granted to a user or group for a file or folder. Windows Server 2003 offers two types of permissions:

NTFS permissions restrict local and remote access to files and folders on NTFS volumes. When you create a new folder, it inherits permissions from its parent folder. When you create a file in a folder, the file inherits permissions from the parent folder.
Share permissions restrict remote access to shared folders, but share permissions do not restrict access to users who log on to the server locally. Share permissions are available on both file allocation table (FAT) and NTFS volumes.

To simplify administering and troubleshooting permissions, use NTFS permissions to control user and group access to file system resources.

Although NTFS is recommended as the primary method for securing folders, you must keep in mind that default share permissions are assigned when you share a folder, and the default share permissions have changed for Windows Server 2003. Windows 2000 and Windows XP grant the Everyone group the Full Control share permission, but Windows Server 2003 grants the Everyone group the Read share permission. This change increases the security of shared folders and helps prevent the spread of viruses.

Because the more restrictive permissions always apply when you use a combination of share and NTFS permissions, you might need to change the default share permissions if you want users to be able to add or change files in the folder. If you do not change the default share permissions, users will have the Read share permission even if you grant users NTFS permissions such as Write or Modify.

Determining Who Needs Access to the Folders

To increase security and prevent users from browsing through shared folders that are not relevant to their jobs, assign permissions only to groups that require access to the shared folders.

To reduce administrative overhead when assigning permissions, do the following:

Assign permissions to groups rather than to users.
Place users in global groups or universal groups, nest these groups within domain local groups, and then assign the domain local groups permissions to the folder.

You do not need to deny permissions for specific groups. When permission to perform an operation is not explicitly granted, it is implicitly denied. For example, if you allow the Marketing group, and only the Marketing group, permission to access a shared folder, users who are not members of the Marketing group are implicitly denied access. The operating system does not allow users who are not members of the Marketing group to access the folder.

Deny access to folders only in the following scenarios:

You want to exclude a subset of a group (for example, an individual user) that has permissions.
You want to exclude one or more special permissions when you have already granted Full Control to a user or group.

Determining the Level of Access That Users Require

Assign the most restrictive permissions that still allow users to perform required tasks. The following descriptions explain the permissions that are associated with folders on NTFS volumes.

Write . Users can copy or paste new files and subfolders in the folder and change folder attributes. However, users cannot open or browse the folder unless you grant the Read permission. Assigning Write permission is useful for folders where users can file confidential reports , such as timesheets, that only the manager or shared folder administrator can read.
Read . Users can see the names of files and subfolders in a folder and view folder attributes, ownership, and permissions. Users can open and view files, but they cannot change files or add new files. Assign the Read permission if users need only to read information in a folder and they do not need to delete, create, or change files.
List Folder Contents . Users can see the names of files and subfolders in the folder. However, users cannot open files to view their contents.
Read & Execute . Users have the same rights as those assigned through the Read permission, as well as the ability to traverse folders. Traverse folders rights allow a user to reach files and folders located in subdirectories, even if the user does not have permission to access portions of the directory path .
Modify . Users can delete the folder and perform the actions permitted by the Write and Read & Execute permissions. Because Modify gives users the ability to delete the folder, use Modify permission only for administrators or for the group or department owner of the folder.
Full Control . Users can change permissions, take ownership, delete subfolders and files, and perform the actions granted by all other permissions. Because Full Control gives users the ability to delete the folder, use Full Control permission only for administrators or for the group or department owner of the folder.

For more information about permissions and file servers, see Permissions on a file server in Help and Support Center for Windows Server 2003.

Determining Whether to Disable Administrative Shares

Windows Server 2003 creates shared folders, known as administrative shares , by default when you start a server or when you stop and then start the Server service. These folders are shared for administrative purposes, and they allow users and applications with the appropriate administrative rights to gain access to the system remotely. For example, some backup software applications use these shares to remotely connect to systems to back up data.

Administrative shares have default share permissions that restrict access to members of only a few security groups. Each share name is appended with a dollar sign ($), which hides the share from users who browse the server. One type of administrative share is the root folder of every volume (C$, D$, and so on).

You can disable these administrative shares temporarily or permanently. For more information about disabling administrative shares and an overview of remote administration, see the Server Management Guide of the Microsoft Windows Server 2003 Resource Kit (or see the Server Management Guide on the Web at http://www.microsoft.com/reskit).

Determining Whether to Hide Shared Folders

You can hide a shared folder by appending a dollar sign ($) to the shared folder name. Hiding shared folders is useful when you want to make a shared folder available over the network while keeping it hidden from people browsing on the network.

Hiding shared folders does not necessarily make them more secure, because anyone who knows the name of the server and the shared folder can connect to it. Therefore, you must set the correct NTFS permissions on the shared folder so that access is granted only to the appropriate groups.

Migrating File Server Data

Once you have planned how to configure and secure your Windows Server 2003 “based servers, you are ready to plan for the actual migration of existing applications and data to the new servers. To ensure the success of the migration, create a detailed and well- tested migration plan that does the following:

Minimizes the amount of time that data is unavailable to users
Minimizes the impact on network bandwidth
Minimizes the cost of the migration
Ensures that no data loss occurs during the migration

The following sections describe the tasks for creating a migration plan, performing the migration, and enabling Windows Server 2003 features following the migration.

Identifying Data to Migrate

Large organizations rarely have time to take all production data offline before migrating it. Instead, they typically move data gradually, migrating different classes of data in stages. A migration plan should identify which data to move, where to move it, and the order in which it should be moved. File server data can usually be classified in the following classes:

Business-critical data
Application data
Personal data (such as home directories)
Profiles or other configuration data
Departmental or group data

Other data types, such as special projects or temporary data

Important

Be sure to review any legal or copyright issues that might arise when you migrate data. For example, if users are storing MP3 files on the file server, you might violate copyrights by copying those files. If you are copying applications, make sure that doing so does not violate any licensing agreements.

When creating your migration plan, determine whether you want to consolidate different classes of data at different rates, onto different hardware, onto servers with different SLAs, or to different locations. Also, consider the importance of the data when planning your migration. For example, to minimize the impact of any problems during the migration, you might choose to move nonessential data first, followed by business-critical data.

In addition to identifying which data to move, you can also identify data that you do not need to move, such as duplicate, obsolete, or non-business- related files. Eliminating these files from your migration plan decreases the number of files that you need to migrate and increases the amount of available storage on the target server after the migration.

Identifying Migration Risks

The next step is to assess the risks associated with data migration. The best way to identify these risks is to set up a test lab with clients and servers, similar to those in your production environment, and conduct trial migrations. In addition to testing your actual migration method, test any applications that are installed on client computers to determine if the applications are affected by the migration. For example, applications that depend on components stored on a particular file server might not work correctly if the file server or share is renamed after the migration is complete. If you identify problems, update your migration plan so that you prevent or mitigate those problems.

No migration plan is complete until you develop and test back-out procedures to follow if the migration fails at any stage in the process. Verify that you can restore data to its previous state and location in the event that you need to roll back the migration.

If you use domain local groups to assign permissions to files and folders, members of those groups will have the same access to the files and folders after they are moved to the new server. However, if you assign permissions to computer local groups, members of those groups cannot access the files after the migration. Either reconfigure permissions to use domain local groups before the migration, or plan to create new computer local groups on the target server and give those groups the appropriate permissions to the files after the migration is complete.

Migrating Your Data

In addition to identifying the data to migrate and planning to mitigate known migration risks, you need to plan to minimize the impact of the migration on the availability of data. To do that, you need to choose a migration method that is appropriate to the needs of your organization and the scope of your migration. Because many migration methods require downtime to move data, migrating data can be challenging in the following situations:

The data has high uptime requirements as specified by service level agreements (SLAs) in your organization, and the migration method might require more downtime than the SLA allows.
Users expect to be able to access the data throughout their workday or at all times.

The backup and restore migration method involves making a backup of the source server and restoring the data on a target server. Depending on your backup method and hardware, this method might involve moving tapes from one backup device to another (for direct-attached backup hardware) or restoring data from a tape library. There are both advantages and disadvantages to this migration method.

Advantages are:

Large organizations routinely back up and restore data, so you can use existing backups to begin the migration.
Backing up and restoring data does not impact network bandwidth when it is performed on the local servers.

Disadvantages are:

Both the source server and the target server must support the backup device and its related software.
If users are accessing files during the backup, you must make arrangements to migrate files that change while the backup occurs.
Backup programs do not migrate shared folder information to the destination server. As a result, folders that are shared on the source server are not shared when you restore them on the destination server. You must share the destination folders manually or by using scripts, and then use Permcopy.exe, which is available on the Windows Server 2003 Deployment Kit companion CD, to migrate any share permissions. The Permcopy.exe tool is included in Resource Kit Tools for Windows Server 2003, available on the Microsoft Windows Server 2003 Deployment Kit companion CD, or on the Web at http://www.microsoft.com/reskit.

To migrate share permissions for migrated folders, first download and install Permcopy.exe, then use the following procedure.

To migrate share permissions by using Permcopy.exe

Create identical file shares on the new Windows Server 2003 file server that matches your current Windows NT 4.0 file server structure.
Backup the Windows NT 4.0 file server shares and restore the data to the newly created file shares.
At the command prompt run Permcopy.exe using the following syntax:
```
  permcopy  \   SourceServer SourceShare \DestinationServer DestinationShare   
```
SourceServer and SourceShare are the server and share names on the source Windows NT 4.0 file server, and DestinationServer and DestinationShare are the names of the destination Windows Server 2003 file server.

Repeat step three for all file shares on the server.

Note

PermCopy does not follow the Universal Naming Convention (UNC) standard, in which you specify the server name and share name together: \\ ServerName \ ShareName . Instead, PermCopy requires that you type a space character between the server name and the share name. If you do not type the space character, then PermCopy displays a syntax summary and does not copy share permissions.

Completing the Migration

After you migrate the data, verify that users can access it on the new servers by completing the following tasks:

Verify that NTFS and share permissions are migrated correctly.
If logon scripts map drives to the old file servers, update the scripts so that they point to the new file servers.

Tip
You should check the Download Center on www.microsoft.com for tool and documentation updates to help with your migration.

Enabling New Windows Server 2003 File Server Features

After the migration is complete, you might want to enable some new Windows Server 2003 features that make managing your file servers easier. The following sections explain some of these features.

DFS

DFS can be deployed throughout your organization progressively. You do not need to deploy DFS all at once; you can choose to add as much or as little of your physical storage as you need to the DFS namespace, at a pace that works with your overall migration schedule.

A DFS namespace is a virtual view of shared folders on different servers. A DFS namespace consists of a single root and many links and targets. The namespace starts with a root that maps to one or more root targets. Below the root are links that map to their own targets.

Organizations of any size, with any number of file servers, can benefit from implementing DFS. DFS is especially beneficial for organizations in which any of the following conditions exist:

The organization plans to deploy additional file servers or consolidate existing file servers.
The organization has data that is stored in multiple file servers.
The organization wants to replace physical servers or shared folders without affecting how users access the data.
Most users require access to multiple file servers.
Users experience delays when accessing file servers during peak usage periods.
Users require uninterrupted access to file servers.

For more information about DFS, see Planning Server Deployments in the Microsoft Windows Server 2003 Deployment Kit .

Shadow Copies for Shared Folders

Shadow copies are point-in-time copies of files that are located on shared resources, such as a file server. You can use shadow copies to recover files that were accidentally deleted or overwritten, as well as to compare different versions of files.

When you enable shadow copies on a volume, you can specify the maximum amount of volume space to be used for the shadow copies. The default limit is 10 percent of the source volume (the volume being copied ). Increase the limit for volumes where users frequently change files. Also, setting the limit too small causes the oldest shadow copies to be deleted frequently, which defeats the purpose of shadow copies and which will likely frustrate users. In fact, if the amount of changes is greater than the amount of space allocated to storing shadow copies, no shadow copy is created. Therefore, carefully consider the amount of disk space that you want to set aside for shadow copies, while keeping in mind user expectations for how many versions they want to be available. Your users might expect only a single shadow copy to be available, or they might expect three days or three weeks worth of shadow copies. The more shadow copies the users expect, the more storage you need to allocate for storing them.

To enable Shadow Copies for Shared Folders

Open Computer Management.
In the console tree, right-click Shared Folders , select All Tasks , and then click Configure Shadow Copies .

Click the volume on which you want to enable Shadow Copies of Shared Folders, and then click Enable .

Note	It is recommended that you select a separate volume on another disk where shadow copies are not enabled as the storage area for shadow copies. Using a separate volume provides better performance and reduces the possibility of high I/O loads that can cause shadow copies to be prematurely deleted.

To access shadow copies from previous versions of Windows, including Windows 2000 and Windows XP Professional, you can download and install the Shadow Copy Client. For more information and to download the Shadow Copy Client, see the Shadow Copy Client Download link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Note	The Previous Versions Client and the Shadow Copy Client provide the same functionality, but the Shadow Copy Client can be installed on multiple operating systems, such as Windows 2000 and Windows XP Professional, whereas the Previous Versions Client can only be installed on Windows XP Professional.

Although the shadow copy client installs correctly on computers running Windows 98, this configuration is not supported.

For more information about shadow copies for shared folders, see Shadow Copies for Shared Folders overview in Help and Support Center for Windows Server 2003.

Disk Quotas

When you enable disk quotas, you can set two values: the disk quota limit and the disk quota warning level. For example, you can set a user s disk quota limit to 500 MB, and the disk quota warning level to 450 MB. In this case, the user can store no more than 500 MB of files on the volume. If the user stores more than 450 MB of files on the volume, you can configure the disk quota system to log a system event.

To enable disk quotas

Open My Computer
Right-click the volume for which you want to assign default disk quota values, and then click Properties .
In the Properties dialog box, click the Quota tab.
On the Quota tab, click to select the Enable quota management check box, and then select the Limit disk space to option.

Type numeric values for the disk space limit and warning levels, select the appropriate units from the drop-down lists, and then click OK .

Note	If the volume is not formatted with the NTFS file system, or if you are not a member of the Administrators group, the Quota tab does not appear in the Properties dialog box for the volume.

For more information about disk quotas, see Disk quotas overview in Help and Support Center for Windows Server 2003.