Peer-to-Peer Questions #10: Terminal Server Profiles, Redesigning Domains, Dual Boot

  • Article

August 23, 1999

Editors Note This article, culled from the TechNet Web site (https://www.microsoft.com/technet), answers the most interesting questions received on the peer -to-peer discussion groups over the past few weeks. To post your own questions, visit the TechNet discussion groups at https://www.microsoft.com/technet/community/newsgroups/default.mspx.

On This Page

How do I move Terminal Server profiles to another drive?

How do I move Terminal Server profiles to another drive?

Say you've just installed Terminal Server and found that the user profiles are located on the C drive. You decide this is not the optimal location since a lot of users will be saving their profiles there and you also want the C drive to only hold Windows NT files. So, how do you move these profiles that may dramatically increase in size to another, larger drive?

Fortunately, there are two Knowledge Base articles that specifically address this:

  • Q186571: User Manager in Terminal Server

  • Q186609: Terminal Server's Application Security discusses the Terminal Server administrator tool, Application Security, which is used by the administrator to decide which programs clients can execute.

And, as an added bonus, at no extra cost, here are some additional information references that address issues of administration, planning, and performance:

  • MS ZAK for Windows NT Server, Terminal Server Edition, version 4.0

Redesigning Domains—Help!

So MS Windows NT 4.0 Resource Kit, Supplement 4, the latest supplement available through Microsoft Press, has a utility that does just what you're looking for. It is called SUBINACL.EXE.

With this command-line tool, administrators can obtain security information on files, Registry keys and services. Administrators can transfer this information from user to user, from local or global group to group, and from domain to domain.

One feature to note is "Migrate security information on objects." This is useful if you have reorganized a network's domains and need to migrate the security information on files from one domain to another.

For example, /changedomain=OldDomainName=NewDomainName replaces all ACEs with a SID from OldDomainName with the equivalent SID found in NewDomainName

Dual Booting Quandaries

Are you looking to create a dual-boot Windows NT Server or Windows NT Workstation system and looking for advice?

Users report that they are able to find a great deal of information on dual booting Windows NT and Windows 9x, but almost nothing on dual booting Windows NT Server and Windows NT Workstation. Some questions:

  • What about disk partitioning? Should NTFS or FAT be used? How large should the partitions be?

  • Any other information that is relevant to the creation of such a system would be useful.

Bottom line: dual booting between Windows NT 4.0 Server and Windows NT 4.0 Workstation is very straightforward. Probably more so than Windows 9x and Windows NT. That is probably why there aren't a lot of documents or Knowledge Base articles on this scenario. Installing Windows NT Server on a machine that is already running Windows NT Workstation and having it run as a dual-boot setup should go very smoothly. Basically, after installing Windows NT Server and rebooting the machine, you will be presented with the available OS system to start up—just like with Windows 9x and Windows NT dual-boot. Just as with the dual-boot configuration with Windows 9x and Windows NT (Server or Workstation), you will need to install the applications that you want to run under the newly installed OS again. Why is that? The applications were installed when running the initial OS; during the installation of the applications, the Registry was updated with information about those applications. Since you are adding another operating system, this will create another Registry which needs to contain the information on what applications are installed and where. Just re-install the applications to the same location as they were originally installed.

Some things to consider when sizing partitions and deciding which file system to use for formatting

Windows NT requires a system partition to store the hardware-specific files needed to boot Windows NT. On Intel machines, the active partition (usually drive C) is the system partition. Windows NT also requires a boot partition to store the operating system files. The boot partition must meet the minimum size requirement. Be sure to consider additional disk space for additional software components, such as RAS, that will be installed. If Windows NT is installed on the system partition, the system partition is also the boot partition.

The System Partition contains the Boot files.

The Boot Partition contains the System files.

Deciding on whether to make the system partition FAT or NTFS depends on additional factors. If you ever plan to add Windows 9x as another bootable OS, then the system partition must be formatted as FAT because Windows 9x doesn't support NTFS. One distinction, in this scenario where multi booting with NT and Windows9x, the system partition must be FAT-16, not FAT-32 because Windows NT doesn't support FAT-32.

Minimum, and I emphasize minimum, disk space for Windows NT 4.0 Server is 125 MB.

A suggestion. Read Chapter 5 - Beginning Installation from the Windows NT 4.0 Server Setup Guide and browse to the Configuring the Disk Partitions section.

Also, the following article on TechNet CD Online is another good read, provided by our friends at Tech Republic. Author Brien M. Posey writes about several practical things to consider in "Choosing Between FAT and NTFS".

And, no worries. If you format with FAT and change your mind after you've setup Windows NT, you can convert a FAT partition to NTFS. But keep in mind that you can not convert NTFS to FAT.

That is it for now.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.