Creating a Standard MFCF Windows Terminal Server Disk Image for Distribution

Please be advised that this web page is intended for MFCF internal use only. Ofcoarse, outside observation and comments are welcome however this document is changed and updated on a regular basis as local standards for Terminal Servers are always being revised. We thank you for your understanding.

Table of Contents

Additional Notes

Introduction

Here we have recorded the hard won facts of building, cloning and distributing a Windows 2000 Terminal Server OS based on MFCF (local) standards for software and security. This document begins with an outline of how to install and build the system OS into the desired state. Later on, this document describes how the OS may copied from the master (development) hardware to a desired target system.
The disk image which we will eventually create will serve as a standard MFCF Windows 2000 Terminal Server installation. In having this image, installation of such systems will be faster and uniform.
Building a typical Windows 2000 OS from its installation CD can take as long as two hours per machine (not including applications). During this process an installer may deviate from the desired server design through simple mistakes and omissions.
By creating a standard disk image for terminal server type systems, system installation is reduced to less than 15 minutes. The installer is required to make fewer choices thus there is less oportunity for error. The results will also allow for easier software packaging, distribution and installation. Such as what currently occurs with many UNIX systems managed by MFCF and IST.

Current Versions Developed

Windows 2000 Advanced Server with Terminal Services and SP2 Basic Operating System for the ACPI Processor Family
Windows 2000 Advanced Server with Terminal Services and SP2 Basic Operating System for the MPS Processor Family
Windows 2000 Standard Server with Terminal Services and SP2 Basic Operating System for the ACPI Processor Family

Nessesary Items Required for Building of Master Disk Image

Creating the Desired System State for Cloning

Setup from the Windows 2000 Installation CD

We begin by launching the OS installation procedure on the Windows 2000 installation CD. Place the Windows 2000 Server Installation CD into the CD drive and reboot the server. You will be prompted during startup if you wish to boot from the CD. Bott from the CD. The Windows 2000 Server setup will then begin.

Disk Partitions
This image setup procedure actually requires two physical hard drives on the server where the work is to be done. Drive Device 1 will contain the boot and system partitions only (logical drives C: and D: respectively). Drive Device 2 will serve as the location for recording the completed disk image prior to it being sent to be burned on a CD ROM(s). Drive Device 2 will be formatted as a FAT32 disk since system image files must be readable in Windows 98 DOS. However do not format or otherwise set up Drive Device 2 until the Windows 2000 OS is first installed on Drive Device 1. There is also no need to mount Drive Device 2 into the Windows 2000 OS until it is nessesary to send the completed disk image across the network. Most of the time Drive Device 2 will only be used in DOS mode.

The first hard drive device in the system will have two partitions containing two logical drives.
C: drive will be 2048MB (2GB) in size and will carry the "protected" operating system files such as boot.ini, ntldr and ntdetect.com. A secondary function for this partition is to act as a location for an emergency system OS (like Windows 95) if the primary OS (on D:) were to fail.
D: drive will be set to 4096MB (4GB) in size and will become the system partition (where D:\WINNT resides). It will also serve as the file system root for installed softare packages.
In this way we retain an established stardard in MFCF with the Windows OS on the D: drive and the C: drive serving as the smaller boot partiton.
The D: drive will be formatted as an NTFS drive. Although traditionally the C: drive has been a FAT partition for workstations, C: should be an NTFS partition on Terminal Server systems. This would protect the OS files on C: from malicious (virus) or accidental corruption. However conversion of C: to NTFS will be an optional issue to be done after system installation is complete.

You may note that the initial size of the system partition (D:) is small for a Windows 2000 server. However, what we are creating in this case is a basic Terminal Server configuration which shall be used for system cloning. A Microsoft utility called sysprep can be used to expand an existing system partition into the available (unused) disk space when this system is installed on a target machine. For the purposes of preparing a prototype server a 4GB system partition is more than sufficient and allows us to clone a Terminal Server system onto a hard drive as small as 6GB in size.

Installation of OS and Services
OS installation is quite straight forward and follows from the installation wizard provided by the Windows 2000 installation CD.

Add the following components. Make sure that the following components are not selected. Continuing with the installation wizard. The installation wizzard will now install all required components and prepare the system. Clicking on the Finish button completes the OS installation and reboots the machine.

System Modification After First Login
Login as Administrator using the password which was set in the installation process. Install the following noting that a system reboot may be required for each step.

Set UsrLogon.cmd and User Network Home Drive
Locate the file D:\WINNT\system32\Usrlogon.cmd. This is a command script which runs for every user at logon time. One of its reponsibilities is to establish a RootDrive for Terminal Server users through substituion of a logical drive letter for the user's home directory - the RootDrive. The existence of a RootDrive allows for easier application configuration when making software compatable in the Terminal Server environment. However since a network drive is always established for the user at logon by the SYSTEM drive substitution is not required.
Edit Usrlogon.cmd such that all lines which begin with the command Subst must be remmed out. As well, the following command line musted be remmed.

net use %RootDrive% /D > NUL: 2>&1

NOTE: The the user's network drive is always the P: drive. This will be the requested RootDrive value when using any Terminal Server Compatibility Scripts. Using P: is consistent with the drive letters given to networked user disk space on other Windows based systems such as Polaris and WinCentre.

Format Drive Device 2
Reboot your server using the DOS floppy. Use the fdisk to create a suitably sized partition on Drive Device 2. Make sure you tell fdisk to switch to Drive Device 2 prior to attempting to create the partition. Do not try to create any other partitions on Drive Device 1. You should allow for several copies of your disk image to be storable on Drive Device 2. In fact, unless you have another purpose for the disk space on Drive Device 2 you should dedicate the entire disk for this purpose. You will need to reboot the server for these changes to take effect. Leave the boot floppy in the floppy drive to return to DOS in order to format Drive Device 2.
Use fdisk again to determine the drive letter of the partition on Drive Device 2 in the DOS. Use the format command to format this disk drive.

Modifications to Key Folders in the File System

From the default file structure on a newly installed system the following folders are to be created.
After UserProfileCache is created, the following subfolders are copied from D:\Documents and Settings. However do not attempt to move any user profile folder such as Administrator. Using regedit.exe, find the following registry key.
HKLM\Software\Mcrosoft\Windows NT\CurrentVersion\ProfileList
Delete all existing subkeys - these keys record the profile cache location for users (like Administrator) which have previously logged in and so must be deleted if the cache location for these user profiles are to change. Then edit the value ProfilesDirectory to read %SystemDrive%\UserProfileCache
The server will need to be rebooted at this point.

After the restart use regedit.exe to find the following registry key.
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
The value Common Documents should be changed to D:\UserProfileCache\All Users\Documents
The server will have to be rebooted once again.

After restart, the D:\Documents and Settings folder and its contents can now be deleted.

System Security Modifications

System Drive (D:) and Sub-Folder Security Modifications
Folder permissions in Windows 2000 are inherited from the parent folder by default. This process follows up all the way to the permissions set on the root of the logical drive. However, as a rule each of the top level folders on the system drive (D:) will not inherit permissions from the D: root. This is due to the fact that each folder's purpose is unique. In particular Temp and UserProfileCache must have special permissions to allow users to add and modify files.
Here we will specify the permissions applied to the root of the system drive (D:) and its imediate list of subfolders. Some of the permissions listed below may appear redundant. When the system is installed Windows provides some greater rights to special user groups such as TERMINAL SERVER USERS and Power Users. These rights have been reduced to simple Read and Execute. It is policy that non-administrative users have no rights to modify the system, the registry or any common software. They only have the right to affect materials which belong to them. The result is a fairly uniform permission structure for the possible exception of the D:\Temp directory.

D:\

D:\Local D:\Program Files D:\Regional D:\software D:\Temp D:\UserProfileCache D:\WINNT (*) Traverse Folder, List Folder, Create Files and Create Folders. Thus Authenticated Users may create files and folders for themselves. These items can be modified and deleted by the creating user and are not accessable to other users (expect the SYSTEM and Administrators).
(**) The SYSTEM caches the user's profile in D:\UserProfileCache not the user however since the profile is owned by the user the CREATOR OWNER permission gives the user Full Control of his profile folder within D:\UserProfileCache
(***) The use of CREATOR OWNER is handy on all folders since it will add the creator's/installer's id to the permission list of any new file or folder. This is a handy mechanism for determining which administrator installed what file.

Shared Folder Security Modifications
At the present time we have no security standard for permanent shares on MFCF Terminal Servers. The file permissions associated with any shared folder are usually sufficient to protect the contents from unauthorized access (or modification). In addition, the default drive root shares (C$ and D$) are set for administrative access only by the SYSTEM at start up.

Registry Security Modifications
All the registry keys come with a set of default permissions to protect them. This situation is much like the file system after a fresh install. However, the default security on the registry has serious holes which are dangerous on a system used by as many as 1000 different students per week. These holes in the security exist for one of two reasons.

  1. By design. A Terminal Server is suppost to allow users to install their own software for their own purposes. These are called local or personal applications. - as opposed to common applications. In many cases though an application must register components to be run by the system. Thus CLSID keys need to be created in the HKCR hive. HKCR is a commonly accessed area of the registry. New keys may also be required in the HKLM hive.
  2. For software compatibility. Some Windows based applications do not create all required registry keys during the installation process. Some "re-create" these registry keys (as many as a hundred in some cases) when the application is run by the user. On an unprotected system, such as with Windows 95, this is an effective measure for ensuring the integrety of the keys upon which these applications depend. However registry errors can occur for a user if he does not have modification rights on these keys under Windows NT or Windows 2000
For us, allowing users to register their own software components is not desirable. Registered components are run under the SYSTEM authority once the server is rebooted. SYSTEM authority is the highest authorization level on a Windows server and not even administrators are given it. If such components are run at that level then they have full access to all server resources (even personal ones). If they turn out to be viruses or hacker traps then the system if effectively compromized.
Further, applications are not written specificly for the Terminal Server environment. These are usually PC applications which were created under the assumption that they would be used on a single user, single interface console and not on a multi-user, thin-client server. During installation, an application may make general changes which can have an undesired effect on other users - such as unexplained icons on everyone's desktop.

In order to balance system stability and security with the practicle matters of compatability we have targeted certain strategic keys that when secured will effectively protect the registry. This coupled with a general policy of not permitting the users to access the registry editors seems to have prevented all forms of virus attacks, accidents and mischief. This is by no means as good a "lock down" as the file system but it is a happy meadian for the time being. As better registry monitoring/editing tools appear this procedure will be refined. The keys in question are as follows.

Registry key permissions in Windows 2000 are, like the file system, inherited from the parent key by default. This process follows up all the way to the permissions set on the hive root (HKLM, HKCU or HKCR). In every case above the idea is to keep the Special access permissions for subkeys but reduce access to simple Read on the keys themselves. Hence user can not create their own subkeys at important levels of the registry but still retain their freer access at less sensitive levels. The Advanced permissions editor permits this by allowing permissions to be inherited by all subkeys and yet not applied to the key itself. You may then create a new Read Only entry for TERMINAL SERVER USER or Power User which does apply to the key itself. The permissions should read as outlined below.
(*) Special permission, in this case, refers to the following permission attributes. Query Value, Set Value, Create Subkey, Enumerate Subkey, Notify, Delete, Read Control.
(**) Read permission, in this case, refers to limited permission attributes. Query Value, Enumerate Subkey, Notify, Read Control.

Network Port Security Implementations
Windows 2000 Standard and Advanced Servers come with what can be described as a built-in firewall service. It is a mechanism which, amungst other things, can allow an administrator to pick and choose what network locations (IP addresses and ports) may connect to the server or specific ports on the server. This is particularly useful if you desire to limit which specific terminals may connect as terminal server clients. This feature is the IP Security Policy in the Local Security Policy admin tool.

Network Ports of Interest for Terminal Services Client Connections

Unfortunately, the interface for the IP security tool is still quite cumbersome and non-intuitive thus development for this kind of policy requires more trial-and-error than other parts of this build process. However here is a basic outline of the steps involved.
  1. Highlight IP Security Policies on Local Machene in the left hand window.
  2. In the Action menu select Create IP Security Policy. A wizard will appear to guide you through the rest of the policy creation process.
  3. Give the new policy a name. In our case, MFCF Standard Network Security. You should also fill in a brief description of the policy's purpose.
  4. Accept all the default characteristics for this new policy including Windows 2000 (Kerbrose V5 protocol) for default Responce Authentication.
  5. At the end click on Finish to create a new blank policy.
A single policy is a list of IP Security Rules. An IP Security Rule is an IP Filter List associated with a particular Filter Action. IP Filter Lists themselves are a list of different network connections; each connection consists of a source and destination IP address, a source and destination network port(s) and a specific network protocol. Usually, the Filter Action is either Permit or Block, accept or ignore a connection respectively.
By associating a list of network connections with a filter action (block or permit) an administrator can dictate what connections a Terminal Server will accept networkwise and which it will simply ignore. Using IP Security Rules in combination it is possible to completely block out (stelth) a network port or series of network ports to the general internet but then allow only specific locations (IP address or seats) to access it.

Below is an outline of how to create a universal block of all connections to TCP port 3389. By default port 3389 is the network port for RDP protocol connections from thin clients. With this block in place, the Terminal Server will ignore all connection attempts to port 3389.

  1. Highlight the new policy now found in the right hand window.
  2. In the Action menu, select properties.
  3. Disable the wizard option in the lower right corner of the Edit Rule Properties applet. The tools are easier to follow this way.
  4. Click on Add to create a new IP Security Rule (IP Filter List - Filter Action combination).
  5. The next applet will appear offering a list of pre-defined IP Filter Lists. Click on the Add key because we intend to create a new IP Filter List.
  6. Again, disable the wizard in the IP Filter List applet.
  7. Fill in the name field, in this case RDP Seats Blocked.
  8. Click on the Add button to create an entry in the filter list.
  9. Set the following.
  10. Click on OK to enter the new filter list entry.
  11. Click OK on the IP Filter List applet.
  12. Returning to the Edit Rule applet select the Filter Action tab.
  13. Select Block for the Filter Action and click on the OK button.
Thus a new IP Security Rule has been created in the policy.
Ofcoarse, this universal block rule is not much good unless there is some mechanism to allow access to specific RDP clients on the network. That is why a second IP Security Rule needs to be added to the policy. The creation of this new rule will follow the same steps listed above except for the three items listed below.
  1. IP Filter List name will be RDP Seats Permitted.
  2. There will be more than one entry (connection) in the Filter List. One IP address for each seat permitted to be an RDP client.
  3. Filter Action will be Permit.
Fortunately Permit Filter Action takes precidence over Block so even though all IP addresses were blocked from port 3389 on the Terminal Server, specificly identified IP addresses in the RDP Seats Permitted Filter List may connect to TCP port 3389.
This provides us with the first part of our security policy with regards to our desire to regulate the location of permitted client seats. We can write similar Block/Permit rule combinations for ICA and x11 client connections to a Terminal Server.

Network Ports of Interest which require special controls

These are network ports used for system information exchange. Such exchanges are file and printer sharing, user authentication and comunication between Windows 2000 and Windows NT systems. Unfortunately, they also may be attacked from outside our networks to gain system and user information which should remain private. These ports could also be attacked in order to break these system services (DoS attack). We wish to make use of these ports localy however there is no need for systems off of campus to access them. Thus we will create IP Security Rule block/permit combinations which will be similar to the RDP connection rules except they will cause all queries that are not from on campus (129.97.*.* in our case) to be ignored. Except for the case of the SNMP ports where we have chosen to be more restrictive. We require that all queries to SNMP ports must come from our local management subnet (MFCF-net) otherwise the connection request is ignored.

NOTE: Windows Universal Plug and Play (UPnP) is listed here due to current security concerns involving UPnP on Windows XP systems. Windows 2000 does not come with UPnP, however Windows.NET (with Terminal Servers) may. When .NET Terminal Servers become more common and if UPnP is used, the UPnP ports will be restricted to on-campus connections only.

Local User Groups and User Rights
The most important purpose of this section is to provide an easy mechanism for selecting which users may log in to a Terminal Server. To this end we create a new local user group called Local Accounts. The membership of this group is limited to accounts on the local system which are permitted to login to the Terminal Server. Usually, these accounts are the local Administrator and one test user account.
Then in the Local Security Policy tool Logon Locally rights are granted to the Local Accounts group. At this time Logon Locally rights are removed for the Guest account and the Users group. Once the server is installed and in production Logon Locally rights may be granted to other local (or domain) groups as desired by the server's administrator.
Adjust the Access this computer from the network user right similarly.

MFCF Packages and Policies

This section is still being reworked since recent system updates have rendered some changes redundant.

Install mfcf_wintse_basics Package
To be installed (copied) into d:\software\mfcf_wintse_basics. This pacakge currently has three components.

  1. All sysdiff files from the Windows 2000 Resource Kit CD. The entire resource kit is really not required nor would we be permitted license-wise. sysdiff itself s a freely downloadable application from the Microsoft web site.
    This will give the new system the ability to easily install packaged software in the form of diff files.
  2. All sysprep files required for preparing the new system for cloning. We will discuss system cloning later in this document.
  3. A locally produced script called notice.cmd. This is a script designed to read and display the message of the day (motd) file for a system.
    It is nessesary to define an environment variable called MOTDPATH which will provide the system file or network path of the motd file. Our default setting will be D:\WinNT\system32\config\etc\motd
NOTE: The software for all components of this package will actually be placed in d:\software\mfcf_wintse_basics\distribution and this directory will be added to the system path.

Create a Shortcut (.LNK) Depository
Create the following folder, D:\software\mfcf_admin\bins\bin and add this path to the PATH environment variable as an addition to the search rules. Then add the .LNK suffix to the end of the PATHEXT environment variable string.
By adding .LNK to PATHEXT, shortcut (.LNK) files can be run from a command prompt in the same manner as any other executable. The file that the shortcut is "linked" to will be opened in accordance to it's file extension. That is, a shortcut to an .EXE file will execute.
The folder D:\software\mfcf_admin\bins\bin will serve as a depository for shortcuts linking to executables in command based packages. This will reduce the need to constantly add to the PATH environment variable after the installation of a command based package. This is also a practice consistant with what is done in xhier-ed UNIX systems here at the University of Waterloo.

Create a Local Computer Policies Console

Add MFCF Policy Changes to system.adm File

Configure the Windows Time Service

This will synchronize the Terminal Server clock with that of the local time server here in the Math Faculty. At a command prompt enter the following command. Note that this requires administrative privalages.

net time /setsntp:ntp.math.uwaterloo.ca.

The network name ntp.math.uwaterloo.ca is the alias for our local time server. It is important to use the alias name as opposed to the true host name or IP address since the time service is movable from one server to another.
In order for the time server settings to take effect the Windows Time service must be restarted. In the Services tool of the Administrative Tools group open the properties of the Windows Time service. If the service is already running then stop it. Now start the service. At the same time ensure that service start up is automatic and not manual.

Switch Off All Unnessesary Services
Windows 2000 Servers initially come online with a multitute of services installed and running. Not all of these services are required to be active for a typical Terminal Server to be able to do its job. Therefore, we should switch off any services which are not required in order to save processing power and RAM.
Any of the services llisted below not only must be stopped but there "Start Up" state must be changed from Automatic to either Manual or Disabled.

Creating the Default User Profile

This is the most "fuzzy" stage of the server configuration. In essence, the Administrator modifies his own desktop into a form which he feels is a good default profile for all his users and then he copies it to the Default User folder in UserProfileCache.

things to do.

NOTE: All of these settings are mearly copied to a user's personal Windows profile at the time of his first logon. Unless enforced by a Group Policy Object or a local system policy, a user may change any setting in his personal profile.

Some Final House Keeping

Here are a few things which should be done prior to sysprep-ing the system for cloning.

Prepare the System for Cloning

Using sysprep to prepare the system for cloning
Sysprep is a free Microsoft application package for cloning Windows 2000 systems. It can be downloaded from the Microsoft Web site here. When sysprep is run it simply "strips off" the SIDs from all userids and machine identification. The software has three key files. In order to use sysprep create a directory called %SystemRoot%\sysprep (D:\sysprep). In this folder copy sysprep.exe, setupcl.exe and sysprep.inf. Then run sysprep.exe from this new directory. After confirmation, the preparation process should be "hands off" and no further intervention on the part of the user will be needed. Once sysprep has completed its task, it will shutdown your server. DO NOT restart the server until a disk image has been taken. This will require booting from a floppy - the details are in the next section.
Although the folder %SystemRoot%\sysprep is retained on a prepared system, this folder will be deleted from %SystemRoot% once the mini-setup is completed on the cloned system.

sysprep.inf is the optional setup wizard configuration file. If it is used this file must be located in the %systemdrive%\sysprep folder with sysprep.exe and setupcl.exe. sysprep.inf is an answer file for setupcl.exe, determining the behavior of the setup wizard. sysprep.inf can even fully automate the wizard so that no user intervention is required. In our case we have created our own version of sysprep.inf which contains the following information. 

[Unattended]
[UserInfo]
[Networking]
There is more to this file which has to do with specifying IDE and SCSI drivers in order that this system image can be applied to many different kinds of systems. Click here to view the entire MFCF sysprep.inf file

Copying the Master System Disk Image from the Hard Drive

With the system sysprep'ed and shutdown, the time has come to create a portable disk image of the C: and D: drives created above. It will be this set of image files that will be cloned onto new servers. Usually the image files are burned onto a set of CDs to simplify the installation process - outlined later. Here is our current procedure for creating the image.

Installation of Disk Image to a Target System

Once a disk image is prepared it can be installed on a new system. In order to install the image onto a new system you will require the following items. Below is the established procedure for installing the disk image onto the new server hardware.

Setup of the New Terminal Server Clone

Below is the setup procedure for a newly cloned Terminal Server just after its first startup. A process called mini-setup will begin and attempt to asses and configure the system to its new hardware environemt.
Typically, these servers become members of the MFCF NT domain if they are considered Administrative, Research or Graduate Student (ARG) services. Otherwise these servers are considered Undergraduate (UG) services and would then be members of the MATH-UG NT domain.

Samba (v2.2.x) Configuration for NT Domain Membership

These are basic instructions for setting up a samba server (version 2 or higher) for use as a resource (file and printing) server for Windows within an NT 4 domain. Having a samba server as a member of a domain allows for seemless access of personal file and print resources as well as storage of personal roaming profiles within user UNIX disk space. Some Notes Conserning Certain Samba Configuration File Entries

username map = location of username map file

In order for a user to access his personal disk space on the samba server his username in the NT domain must exactly match his username on the UNIX samba server. It is also MFCF policy to make sure each user has the same username for MFCF systems. However, there are a few cases (usually accidental) where this is not the case. For those cases it is often not practical or possible to establish a new username in either the NT domain or UNIX environments. For these users the username map file is used to map the NT domain username to the corresponding UNIX username.

nt acl support = no

nt acl support is a mapping mechanism for UNIX permissions to NT access control lists. We choose to disable this feature because since the implementation of Windows 2000 Service Pack 2 (SP2) roaming profile loading will not work from a samba share if this feature is enabled.

Some Notes Conserning Samba Client Connection Limits

By default, the SAMBA daemon running on a UNIX system (smbd) has a built in limit of 128 connections per client machine. Or more accurately, each new smbd daemon is spawned specificly for each new machine client and has a connection limit of 128 simultanious file and printer shares. For a single session, single user workstation this is more than enough. Unfortunately for a Terminal Server with more than one user per machine client this is not enough. A single Terminal Server can rapidly exhaust its limit of file share and printer connections during peaks periods.

The solution is to raise the 128 connection limit. However, this change must be done prior to the compilation of the SAMBA software. The smbd daemon connection limit is hard written into the source code. A quick search of the web indicates that the connection limit can be increased by modifying the following line in the conn.c programme in the smbd section of the SAMBA source code. 

#define MAX_CONNECTIONS (128)
We have changed this line to allow for 512 connections. Then the SAMBA source can be compiled.

This page was last updated on Thursday, the 5th day of June in the year 2003 AD.
Contact Clayton Tucker for questions or comments.