|
|
Administrators often face great challenges in successfully installing applications on a terminal server. Some companies require many applications to be installed on terminal servers. Furthermore, the growing user base demands these installations be distributed to dozens or even hundreds of servers combined in farms. It is therefore important for the installation procedure to be predictable and reproducible.
A good administrator begins to structure and optimize the procedure early on. Because prior planning is so important for creating repeatable installation procedures, this topic will be our focus in the following section.
Simplified administration was one of the key goals in developing Microsoft Windows 2000 and Windows Server 2003. Installing software was supposed to become easier and more transparent to the user as well. These goals were met by Windows Installer, which makes installing software on workstations almost fully automatic. Group Policies distribute the software in the form of an installation package, or the software can be manually installed by double-clicking a file with the .msi suffix.
An .msi file is a clearly defined package that contains all information required to install software in an embedded database such as copied files or previously created registry entries.
| Note |
You can easily provide Framework applications using Windows Installer. Framework applications are generally more simple than conventional 32-bit applications, because Framework applications do not directly depend on other applications or have uncontrolled components. Moreover, they are easy to install. Just copy them to the target system; no registration is required. You need to call on special installation tools only if you want to install a .NET assembly into the GAC. |
Windows Installer version 2.0 is integrated into the Windows Server 2003 operating system. Msiexec.exe, a Windows Installer service, enables you to automatically add applications and application components that are offered as .msi packages. This service can assign delegated rights that surpass the permissions of the installing user. Users interact with application-specific dialog boxes.
| Note |
It is, of course, possible to install a Terminal Services client on the target platform with an .msi package and Windows Installer. However, the target platform must support this method, which is usually true for Windows XP and Windows 2000 Professional. |
Microsoft Windows Server 2003 can use Windows Installer to distribute programs in a company. Computers or users can be assigned certain programs, or they might be released for general use. Because several users can access programs simultaneously in terminal server environments, special preparation is needed.
For terminal servers, applications must be installed per computer so that they are available for every user who can access them. Assigned programs can be installed from the console or via a remote console session. In the latter case, several problems might arise.
Installing an application requires that the system be switched to installation mode and possibly rebooted. The administrator should confirm that no users are logged on to the terminal server interactively before starting the installation.
If the application is installed via a remote console session, the session might end or reset if the system needs to be rebooted. When the server reboots, the session is reset and the administrator might have to log on to the terminal server again to make sure that the program was installed properly.
Windows Installer installs programs on different levels, depending on how the .msi package was created. Many .msi packages perform a minimum installation, that is, of just a few program components. This technology is known as application advertisement. When a user invokes an application, Windows Installer determines which parts of the program are already there and then installs any needed advertised components. Because advertised programs and components are advertised per user, however, terminal servers cannot accept them. If a user tries to install an application component after another user has already started the same application, the system will behave inconsistently.
Furthermore, non-administrators typically cannot launch installations directly from Windows Installer if Terminal Services is running in application server mode. Only administrators can do so. Therefore, it is important from the beginning to install all applications locally so that they run properly on terminal servers.
Some applications require different options for installation on a terminal server versus normal workstations. During an installation, the application must recognize that its target platform is a terminal server—that is, become terminal server-aware. Alternatively, a transformation file (.mst) can be used during installation to adapt the logic of the .msi package to the target platform. Likewise, the .mst file can be used to let Windows Installer know about the additional program components to be installed locally. One example is Microsoft Office 2000, which has certain functions that must be modified in just this way or they are simply not installed.
If the applications to be installed on the terminal server are not terminal-server- aware and if there are no associated .mst files (called transforms), the administrator must ensure that all required components are fully installed or create transforms. If the applications were installed on a terminal server with the correct .msi and .mst files, uninstalling is straightforward, including reversing specific installation steps.
Windows Installer SDK is indispensable for creating professional installation packages for Windows Server 2003 applications. It is part of Microsoft’s Platform SDK and contains documentation, different Windows Installer database tools, examples for user-defined actions (written in C and VBScript), header files and libraries for C, empty .msi databases, and so on.
| Tip |
You can download Platform SDK from this Web site: http://www.microsoft.com/msdownload/platformsdk/sdkupdate. |
Windows Installer SDK contains a number of tools for creating and managing installation packages. The foremost and most essential is Windows Installer 2.0 Table Editor (Orca). This tool helps create and manage installation packages that are based on Windows Installer. Orca lets you open .msi files to view and work on database tables directly. In addition, Orca is an excellent tool for learning about .msi packages.
Microsoft Visual Studio .NET is not only an environment for developing cutting-edge programs. It also allows you to create .msi installation packages through associated project types. The installation package is created when projects are translated and is available immediately.
If the application being developed using Visual Studio.NET was designed specifically for use on a terminal server, you can also adjust the corresponding installation routines here.
Microsoft tools alone do not always suffice to create installation packages. This is especially true in large corporate environments where highly automated installation processes are required to keep costs down. This is particularly true when introducing terminal servers. Consequently, a market for powerful installation tools has developed. Microsoft closely cooperates with InstallShield Software Corporation and Wise Solutions, Inc., to support their tool development.
These programs often work with a so-called “snapshot” mechanism. This means that the system status is recorded before software is installed. Subsequently, the software is installed. Finally, the old status and the new status are compared. The results of the monitored installation and the difference between old and new status are bundled together in an installation package, which is easy to copy to other computers.
Alternatively, you can manually create an .msi package. This requires detailed knowledge of the application being installed. Most commercial installation tools support this procedure as well.
Some companies also offer installation mechanisms that are not based on .msi packages, but are instead based on their own installation engines or script engines. These support platforms that do not have Windows Installer, or that encapsulate the installation logic to prevent it from being viewed or modified with third-party tools.
InstallShield offers several products that focus on software installation. InstallShield Express and InstallShield Developer are based on Windows Installer. InstallShield Professional uses its own installation technology, called InstallScript Engine. The related script language is suitable for creating dialogs and can be used in InstallShield Developer and InstallShield Professional. All InstallShield installation tools can distribute Framework applications and, if required, the .NET Framework. The target platforms of these tools include Windows Server 2003, Windows XP, Windows 2000, Windows NT 4, Windows ME, Windows 98, and Windows 95.
InstallShield Express and InstallShield Developer create .msi databases appropriate for end users. Windows Installer processes these databases when the installation program is executed. InstallShield Help describes where and how to make the project-specific settings in the development environment. By contrast, .msi Help documents all .msi actions and database tables that can be accessed by InstallShield’s Direct Editor or by Orca.
You will find detailed information on InstallShield at http://www.installshield.com.
In its NetInstall product, NetSupport relies on a technology that is completely independent of Windows Installer. This product offers many more functions than Windows Installer. It requires a special agent that needs to be saved to the target platform before any type of installation starts.
Installation and uninstallation procedures are triggered as needed by time, events, or profiles. No manual intervention is required. Automating all installation procedures is key and can even include installing the operating system using an additional tool: Operating System Deploy (OSD).
Before installation comes packaging. Corresponding tools and an independent script language are used, creating a package with the application software files and all definitions for installation and configuration.
NetSupport NetInstall explicitly supports the terminal server as a target platform. NetSupport developed special mechanisms for setting installation schedules, controlled deactivation of the terminal server, user access before installing new software, and reactivation after all installations and reboots have finished. The installation logic also features the separation of computer and user-specific settings, just as terminal servers require.
You will find detailed information on NetSupport at http://www.netinstall.com.
WinINSTALL from OnDemand allows you to create distribution packages by recording changes that are created during each installation procedure. Later adjustments to the resulting package can be made via graphical user interface; no script language is required.
WinINSTALL also allows automatic synchronization of installation packages between distribution servers on the network. The distribution mechanisms are varied: time-controlled, via a Windows service, logon scripts, e-mail, or CD-ROM, or through a hidden partition.
The Windows 2000 Server installation CD-ROM did contain a version of WinINSTALL with reduced functionality. You will find updated information on WinINSTALL at http://www.wininstall.com.
Wise Solutions offers several products to create and manage installations. Wise for Windows Installer allows you to create .msi packages, whereas Wise Installation System uses its own installation technology. Both products are based on a specific script language that allows you to freely define the installation logic to a great extent. Furthermore, a debugger supports creating dialog boxes to guide users and validate results.
You will find detailed information on Wise Solutions products at http://www.wise.com.
Cloning or imaging programs are used to write all data on a hard drive to another data carrier, regardless of the operating system installed. Cloning creates an image of the source system that can be replicated on any number of targets. With this method, you can quickly distribute complete reference installations to many servers as well as conserve production systems before making a change.
Many cloning programs are based on MS-DOS and the corresponding drivers for hard drives, SCSI adapters, CD drives, backup drives, or network cards. As a result, these programs are quite small and usually fit on one disk. The disk is used to start up and secure a computer. The hard drive image is copied to an empty computer the same way, except that the data is written to the local hard drive from the backup data carrier. Most cloning programs have an optional additional Windows- based application only for backup purposes.
The cloning process might sound relatively easy, but there are several problems that related programs need to address.
If source and target drives are not 100 percent identical in terms of size, partitions, and sectors, the cloning program must adjust the data structure accordingly. Target partitions must not be smaller than source partitions.
Boot managers and master boot records (that is, operating system starting areas) must not be deleted, damaged, or modified.
MS-DOS file limit sizes defined by the file allocation table (FAT) file system must be observed. The maximum size is often only 2 GB for downward compatibility with older DOS versions. For this reason, images of larger partitions must be distributed to several files.
| Important |
Some manufacturers offer only limited support if their systems or applications were installed through cloning. You should therefore check whether the installation you are planning affords you the support that you are used to. |
Even though a cloning program can read and write partitions by sector, it helps if it recognizes the NTFS file system. This way, only occupied sectors are considered, often reducing the size of the image significantly. Data compression is another way to reduce the backup space required.
The security identifiers (SIDs) that uniquely identify an installation are a specific problem in Microsoft Windows NT, Windows 2000, and Windows Server 2003. Duplicate SIDs can severely hamper network operation, especially under Windows 2000 and Windows Server 2003. Either the cloning program must change the SID, or the free NewSID tool from Systems Internals (http://www.sysinternals.com) can be used for this purpose.
| Important |
When you clone a terminal server installation to distribute to other servers, the source and target hardware should be identical. Otherwise, hardware recognition errors might occur on the target system during system start. |
In spite of all these obvious issues, several successful cloning programs for terminal servers have become established on the market. Among the best known are PowerQuest DriveImage and Symantec Ghost.
|
|
