Software Preparation on MFCF Windows 2000 Terminal Servers

In this document we will outline procedures for preparing software to be installed on MFCF Windows 2000 Terminal Servers. Our goal is to create standardized and modular installation packages for Windows based applications. These packages can be easily distributed and installed on any MFCF Windows 2000 Terminal Server.
Amungst the advantages of such a plan is that any one application requires configuration only once since it will be installed on similar systems. Systems who's configuration is outlined in the previous document.
In theory, this plan should be extendable to Windows 2000 workstations as well.

Use of Junctions
At the foundation of our installation stratagy is a new Windows NTFS construct called a junction. Junctions are similar to hard links in UNIX where a special folder can redirect the explorer to another directory in the file system. In the case of Windows 2000 this can extend to other logical drives.
This makes it possible to give every software package a standardized form for an installation path regardless of where the package happens to be installed. For example, a software package called package_A has to be installed on a separate hard drive from the rest of the system due to its size. However, in our system design document we want all packages to reside in D:\software. The solution is to create a juction folder at D:\software\package_A which points to the drive and directory path where package_A must reside. Then install package_A into D:\software\package_A. Thus we can expect all software packages to have an installation path of the form D:\software\package_name.
In addition, juctions give us the flexibility of moving packages from one file system location to another without sacraficing the package's absolute installation path. Thus the need for re-installation is avoided.
It is anticipated that juctions will largely be used for package redirection in D:\software. However, juctions may also be useful in the easy and seemless relocation of such user accessible folders as D:\UserProfileCache and D:\Temp if system disk space ever becomes a problem.
Juctions are created using the command linkd. linkd.exe is actually a native feature of the Windows 2000 Resource Kit however we have packaged it into the mfcf_wintse_basics package for use in all of our Windows 2000 Terminal Servers.
NOTE: Juctions are part of the Windows 2000 OS and are not available in Windows NT 4.

Software Packaging (sysdiff)
Firstly, sysdiff.exe is very handy in packaging applications (even ones as complex as MS Office). However, it is not as effective in recording and reapplying anything which integrates with the operating system. This would include patches, service packs default user profiles and Internet Explorer.
sysdiff.exe operates by comparing before and after images of the file system, registry and all ini files. Changes are recorded in files know as diff files. These diff files can be subsequently used on another system to create an identically configured package. Having said this there are some noteworthy limitations to sysdiff.

• On a target system, sysdiff'ed packages will always install themselves into the same installation path as on the development system.
• On the target system, sysdiff'ed packages must be installed by the same user account as on the development system. This is usually the local Administrator since it is the one account name which is common to all Windows systems.
• The system path (D:\WINNT) must be the same on the development system and on the target system

• We expect a package to be installed in D:\software\package_name for all systems.
• We expect local Administrator to install all software packages just as root does on UNIX systems.
• We expect D:\WINNT to be the system path for all servers.

1. On the development system, re-install the basic Terminal Server OS without any software/application packages.
   • This is nessesary because we do not want any influences from other software packages to be recorded into any package created. The best way to ensure this in the Windows world is to purge the OS on the development system and then replace it with a newly installed OS. Hence use the disk imaging software.
   • Using pqdi.exe this stage takes about 15 minutes on a modern computer.
2. Logon as the local Administrator.
3. Open a command prompt and change the directory to D:\Temp.
4. Create a snap shot file: sysdiff /snap pre_inst.snp
5. Place the Terminal Server installation mode. This is done through the Add/Remove Programs applet in the Control Panel or by using the command: change user /install.
6. Install software package from its media (CD, floppy or installation file).
   • MFCF standards require that the installation path be of the form d:\software\package_name-version\distribution. This is consistant (after a fashion) with installation standards found on UNIX systems managed by xhier.
   • Installing the package into a subfolder called distribution is a standard xhier approach for all pre-packaged software in UNIX. We are mearly adopting this method for Windows 2000. This standard also leaves an uncluttered root directory to itemize any documentation, dependancies, licenses and installation scripts which the application may use.
   • Some older applications may not offer a choice for the installation path although these cases are now quite rare.
   • Some applications may also install components in d:\Program Files, d:\WINNT or d:\WINNT\system32. Whenever possible this tendancy should be overidden.
7. Configure any desired default conditions. For example we always switch off the "spell correction while typing" feature in MSWord. This is done to save processor power on Terminal Servers.
8. Take the Terminal Server out of installation mode. Usually by selecting the Finished button in the Add/Remove Programs applet or by using the command: change user /execute.
9. Check to see if the installation process has made any modification to the system PATH variable. This would certainly be the case for any command driven package such as WATFOR77 as opposed to a typical Windows GUI package like XWin32. However there are GUI packages such as Matlab 6 that depend upon both a GUI and system commands. If PATH has been modified, then apply the following sub-procedure.
   1. Create a bin directory for your package at d:\software\package_name-version\bin. This new directory will be at the same level as the distribution directory.
   2. Note the paths for each folder that has been added to the value of PATH.
   3. Remove these additions to the value of PATH. The PATH variable should always remain the same regardless of what package has been installed.
   4. With each folder that was added to PATH find all the executable files (.exe, .cmd, .bat, etc.) and create shortcuts (.LNK files) for all of them.
   5. Copy these shortcuts to the packages bin directory.
   6. Rename all the shortcuts so that the "Shortcut to" expression is removed from the file name.
10. Return to the D:\Temp directory, record the dif file: sysdiff /diff pre_inst.snp post_inst.dif

sysdiff /apply /m post_inst.dif

The /m switch is used to apply the profile changes for the packager (local Administrator) to the Default User profile. However in the case of a Terminal Server, installation mode means that user registry changes are also recorded in a special registry area which is also checked by sysdiff. Similar comments can be made for all ini files. Hence the use of /m is redundant - but we still use it.
Since apply mode will place the package in the same installation directory as on the development system we need juctions to relocated applications to other logical drives. sysdiff will follow juctions - I found that one out the hard way.

If the newly installed package has a bin directory, then copy the existing links from this location to d:\software\mfcf_admin\bins\bin (a path already in the system search rules).

NOTE: There is a file called sysdiff.inf which defines the folder and registry keys which sysdiff will include or avoid. For example there is no need to examine the contents of d:\temp.