Deploying the Migrated Application


Deploying the Migrated Application

This explains how to deploy your migrated application into a Windows environment. It describes solutions for deploying Win32 and Interix applications.

The standard method of deploying applications in a Win32 environment is to usethe Windows Installer Service. This section looks at the Windows Installer Service and some of the tools that you can use to package your application.

When you deploy applications in the Interix environment, you can use the standard UNIX tools available in Interix for file transfer, remote configuration, and scripting. If you had managed the application before migration by using proprietary UNIX software management tools, it is unlikely that these tools will be available in Interix. If you use standard UNIX tools, such as the remote commands tar , cpio , and shell scripts for application management, you will be able to migrate your deployment tools relatively easily.

With both Win32 and Interix applications, your application will reside either on the desktop or on application servers. In the latter case, you may have to rely on networked file-systems for access to your application executable files. Because of differences in how UNIX and Windows network file systems operate , you will need to take specific action on some migrated applications.

Tools for Deploying Win32 Applications

After you migrate an application to Win32 from UNIX, you should deploy it by using standard Windows software management tools. This section describes someof the tools available, and how you can use them in different deployment scenarios.

Windows Installer Service

The Windows Installer service uses the Windows Installer package, and this is now the way that application developers must deliver software for the Windows platform. By standardizing the format and a common set of actions, Microsoft leaves the tool vendors free to add value in creating, editing, and distributing Windows Installer packages.

The .msi file format contains all of the instructions that a program needs to install itself: the locations of files, movements or deletions of existing files, creation of shortcut icons, a Start menu entry, registry settings, ACL changes, Windows service installation or changes, and COM component registration. The program files maybe contained in the .msi or in one or more .cab (compressed) files. The .msi uses database tables to describe the features and components of the product, the relations between the two, and all of the actions that it requires to install, upgrade,or uninstall the application.

The installer will copy the application s files to their correct locations from an embedded file or from the accompanying .cab file or files. Usually, the Windows Installer is invoked when a computer boots up and logs on to the domain (by using the Microsoft Active Directory directory service computer account) or when auser logs on to the computer. The Group Policy feature of Active Directory is usedto attach .msi installation packages to these events, though you can also invoke the Installer locally by using other means such as scripting or the scheduler service.

The installation process leaves a copy of the .msi instructions on the local computer. Each time an application is launched, it checks the feature and component listingsin the local .msi to see if everything is still intact. Missing or corrupt components can trigger an automatic repair known as self-healing . Self-healing can also be triggered during the operation of an application when a component is dynamically loaded. This feature is useful when .msi files are well architected by the software developer, but it is often turned off by administrators when the .msi has been repackaged. This is because many large applications are, by necessity, built as single feature packages, and self-healing would force the administrator to reinstall the entire application.

Installation on Demand

Install-on-Demand is one of the most useful features of the Windows Installer Service. Install-on-Demand is the feature that prompts for the location of the installation media after selecting an item that you have not used before, when using a product such as Microsoft Office. By using Install-on-Demand, you can leave components that you do not access frequently (grouped into feature sets) uninstalled and on the server until a user invokes them. You can apply this to whole applications in the case of Group Policy software advertisements, where only a desktop shortcut is deployed initially, or you can apply it to application features such as spell checkers, graphic libraries, charting, and so on. To use this feature properly, you must understand how to divide the application into independent chunks (or components), and you must then choose which components you must share across an entire installation and which you can hold back until they are needed. The local .msi database maintains a list of installation points where it can find the necessary filesat the time of installation. You can edit this list by using subsequent patch (.msp) files to update network locations, such as Distributed File System (DFS) shares.

Installation Rollback

As the installation occurs, the service backs up overwritten files and keeps trackof any changes that are made to the system, such as registry entries or ACL changes. If the setup is not run to completion, an automatic rollback restores the original state of the system. You can run Windows Installer with verbose logging options to record these events; however, there are no built-in alert mechanisms in Group Policy. Most large enterprises using Active Directory as their only means of distributing software have developed scripts to query the .msi log files or interrogate the .msi local database by using Windows Management Instrumentation (WMI).

Deployment Auditing Using the Windows Installer Service Database

The following Visual Basic Scripting Edition (VBScript) code interrogates the local .msi database and lists installed packages. You can use this, in conjunction with remote scripting, as the basis of a simple deployment audit.

 Dim installer, product Dim version Dim  productList, productString productList = "" Set installer = Wscript.CreateObject("WindowsInstaller.Installer") For Each product In installer.Products version = CLng(installer.productInfo(product, "Version")) version = (version5366) & "." & _ (version535 Mod 256) & "." & _ (version Mod 65536) productString =installer.productInfo(product, "ProductName")_ & vbCrLf & " ID: " & product _ & " Version: " & version & vbCrLf productList = productList  & productString & vbCrLf Next If productList <> "" Then productList = "Found " & installer.products.Count & _ " applications" & vbCrLf & vbCrLf & productList Else productList = "No .msi applications listed." End If WScript.Echo productList 

The following is an example of output from this script:

 E:\>cscript ListMSIDB.vbs Microsoft (R) Windows Script Host Version 5.1 for Windows Copyright (C) Microsoft Corporation 1996-1999. All rights reserved. Found 7 applications Windows 2000 Administration Tools  ID: {B7298620-EAC6-11D1-8F87-0060082EA63E} Version: 5.0.0 Microsoft Windows Services for UNIX  ID: {E8A81EF0-40DB-4B5B-ABE8-558D69CE2F09} Version: 7.0.1620 Hummingbird Exceed  ID: {CFBD3858-2164-42B0-84A2-576C18C85082} Version: 7.1.0 Microsoft Office XP Professional with FrontPage  ID: {90280409-6000-11D3-8CFE-0050048383C9} Version: 10.0.2627 WebFldrs  ID: {6F716D8C-398F-11D3-85E1-005004838609} Version: 9.0.3501 Windows 2000 Support Tools  ID: {242365CD-80F2-11D2-989A-00C04F7978A9} Version: 5.0.2072 Microsoft Windows 2000 Resource Kit  ID: {4E1F3FCF-B205-427F-B52B-D13BDFB6526C} Version: 5.0.2092 
Security Rights and the Windows Installer Service

The Windows Installer service, when invoked by Active Directory Group Policy, runs a managed installation . This process runs under the Local System account, which has administrative rights. This allows applications to be installed on systems that are locked down (that is, systems on which the end users have limited rights and abilities ).

Patch Files

Another aspect of the Windows Installer service is the .msp or patch file. Thisis a specially formatted .msi that can identify and update existing installations of itself by unique product and version numbering. Many organizations will create build images by using the .msi format so that future patches and upgrades canbe deployed by using Group Policy in Active Directory.

Window Installer Service Transforms

If you have worked with Microsoft Office 2000 or Microsoft Office XP and are familiar with the Resource Kit Custom Installation Wizard, you have seen the Windows Installer s transform technology. Transforms allow you to amend the installation instructions in the .msi file on the fly. These are usually authored by using one of the commercial editing tools such as WinInstall or InstallShield.

A limited variety of user interface widgets are available to the Windows Installer to gather user input during the installation and to look up information in outside files.

Creating New Windows Installer Service Packages

There are many tools available for packaging, distributing, installing, and managing applications in the Windows Installer format (that is, .msi files). Microsoft Visual Studio .NET can create installation packages in the .msi format. In addition, there are third-party tools available that help you create and manage Windows Installer Packages. These products typically provide you with:

  • An Integrated Development Environment (IDE) for developing installation packages.

  • Installation script editors.

  • Installation debuggers .

  • Options for Internet-based installations.

  • Support for password and digital signature security options on installation packages.

  • Support for the Windows Installer patch files (.msp files).

  • Support for the Windows Installer transforms file (.mst files).

  • Source control integration.

The following are three third-party products that you can use:

  • InstallShield Developer ” see http://www.installshield.com

  • Wise for Windows Installer ” see http://www.wisesolutions.com

  • Veritas WinINSTALL ” see http://www.veritas.com

Using a Windows Installer Packaging Tool (later in this chapter) illustrateshow you would use the Wise for Windows Installer product to create and deploya Windows Installer package.

Repackaging Applications

If a software installation process that has already been created does not support the Windows Installer (.msi) standard, you can use a repackaging application. At minimum, a repackaging application will allow you to:

  • Create fully featured Windows Installer setups by capturing installations thatare not based on Windows Installer.

  • Allow installations to be customized.

  • Check and resolve any installation conflicts.

The following are two repackaging applications that you can use:

  • InstallShield AdminStudio ” see http://www.installshield.com .

  • Wise Package Studio ” see http://www.wisesolutions.com .

Deploying Applications with Group Policy Objects

Microsoft Active Directory supports a technology known as Group Policy . You can assign Group Policy Objects (GPOs) to users or computers, and you can associate them with any of the hierarchical containers that make up the directory structure. This means, for instance, that you can apply a policy to all the computers in an engineering department at a particular site or even across the organization whilethe computers in an accounting department have their own policies. GPOs are filtered by the user groups in Active Directory so that you can keep precise control over users applications.

GPOs can set and enforce hundreds of settings on desktop computers, includingall of the security settings, but the setting applicable here is the software distribution policy setting. You use the software distribution policy to deploy Windows Installer files (.msi files). The Windows Installer service, msiexec .exe , can be set by Group Policy to run with elevated ( administrator-level ) privileges. Thus an installation program that needs access to resources that a typical user would not have accessto (for example, directories and registry entries) can still operate without the user having power user or administrator privileges.

Deploying Applications with Systems Management Server

Applications can be deployed using Active Directory s Group Policy software distribution feature. However, there are several limitations when using GPOs for software deployment. These are addressed by SMS. Here is a summary of the main reasons for using SMS rather than GPOs for application deployment:

  • Active Directory Group Policy requires that applications be in Windows Installer (.msi) format, whereas SMS can deploy any executable package, including setup programs, scripting, and batch files. Many large applications include legacy setup architectures that are difficult or impossible to replicate in a repackaged .msi installation.

  • SMS has extensive Microsoft SQL Server-based reporting capabilities.

  • Group Policy requires a user to log on or a computer to be rebooted to initiate software deployment policy.

  • SMS includes an extensive hardware and software inventory.

  • SMS allows you to query the client computer prior to installation to ensure adequate disk space, memory, operating system version, and other software dependencies.

  • SMS does not require Active Directory, though SMS can use Active Directoryif it is available.

  • Software installations can be advertised to users through desktop shortcuts,the SMS client icon, and Control Panel. Software installations can also be pushed to a client without user intervention.

  • SMS allows you to define computer groups separately from Active Directory users and groups, based on inventory information.

Deploying Win32 Applications

This section describes different methods of application deployment and how you would go about using them.

Deploying Win32 Applications by Pushing Them to the Desktop

Active Directory Group Policy software deployment or other systems that rely ona user logging on or a computer being rebooted might need to have a second method of delivery that can be deployed without user intervention to client desktops.

SMS and other enterprise level systems can achieve this as part of their normal client-server interaction. Other methods of achieving this include remote scripting or maintaining a service (daemon) on each desktop that checks for updates periodically.

Two-Phase Deployment of Win32 Desktop Applications

When deploying locally installed applications, you might want to avoid the distribution of large installation images over the network over a short period of time.To do so, you can use a two-stage approach, sometimes referred to as a knife -edge installation. In this scenario the two stages are as follows :

  1. Deploy the installation image.

    Deploy an .msi or SMS package that is designed to do nothing more than copya potentially large installation image to each user s local disk, possibly in a partition reserved for this purpose.

  2. Schedule the installation job.

    A second package or job is then scheduled with the actual installation instructions that operate against this local image. This can be an incremental deployment over several days or weeks.

In this way, large numbers of users can simultaneously install a new version of an application without affecting the network and without raising data compatibility issues.

Another benefit of this technique is that multiple versions of an application s installation image could be stored on the local drive for rapid rollback, piloting new versions, and so on. To maintain this rolling cache of images, you would need well- tested install and uninstall jobs, packages, and processes.

If a deployment system such as SMS is in place with some additional Wake-On-LAN support, you can deliver the image deployment and installation packages outside normal working hours.

Large package deployments can also use compression technologies such as WinZip to deploy the package without dependence on the .msi format.

Side-by-Side Deployment of Win32 Applications

Although the Windows platform has been a successful development platformin part because of its built-in component-sharing mechanisms, these same shared components have also caused administrative headaches . Components from Microsoft (which are provided as part of the base operating systems, option packs, service packs , and various add-ons) and numerous third-party sources save developers countless hours. However, true backward compatibility means that shared components must function exactly as they did in previous versions while providing new functionality. In the real world, this is difficult to achieve because all configurations in which the component may be used would need to be tested.

The practical functionality of a component is also not easily defined. Applications may become dependent on unintended side effects that are not considered part of the core function of the component. For example, an application may become dependent on an anomaly in the component, which when fixed causes the application to fail. The fact that dynamic-link libraries (DLLs) have been upgraded to newer internal versions while keeping the same names has also caused confusion.

This lack of backward compatibility can result in the inability to deploy a new application without breaking applications already deployed or compromisingthe functionality of the new application. To provide for successful sharing while enhancing application stability, Microsoft introduced side-by-side sharing startingin Microsoft Windows 98 Second Edition and in Microsoft Windows 2000, creatinga way to share components through isolation.

With side-by-side components, multiple versions of the same component canbe installed, and applications can use the one most suitable version.

Two different processes can load different versions of a Win32 or COM component at the same time and, independently, unload those components as required.

As outlined in the Windows 2000 logo certification guidelines, the best practice isto develop new applications and components with side-by-side use in mind, but there is also a way to selectively isolate the majority of existing components by using a Windows redirection mechanism. While redirection doesn t require changing any code, it does need to be thoroughly tested to ensure that the applications on the system continue to operate normally. Because these components may now be distributed into many application s directories, there is also an increase in the complexity of administering the components.

Creating new components for side-by-side use is the best way to guarantee that applications can load them independently. In this case, the component must be developed with careful attention to where global data and state information are stored. Any other factors that could affect having multiple versions of components in memory simultaneously must also be addressed. For instance, instead of storinga particular setting using a registry key such as:

 HKEY_CURRENT_USER\Software\Vendor\ComponentName\RegKeyName = SomeValue 

the component would be better isolated using a version-specific key such as:

 HKEY_CURRENT_USER\Software\Vendor\ComponentName\VersionNumber\ RegKeyName = SomeValue 

or even a version- and application-specific key:

 HKEY_CURRENT_USER\Software\Vendor\ComponentName\VersionNumber\Application SpecificName\RegKeyName = SomeValue 

Shared memory structures such as memory-mapped files and named pipes also need to be taken into account and renamed or relocated on a per version basis. Better still, a component should be designed to be as stateless as possible and to let the client application handle state and user-specific data as much as possible. Where the component really does need to store its own state information; it should use a method or property of the client software instead of modifying memory structures or registry settings directly.

Windows 2000 allows administrators to take advantage of side-by-side loading with existing components as well using a feature called DLL redirection . The operating system changes its default method of locating components if it finds a special filein the directory with the application that is loading the component. The file itself is empty but is specifically named to match the application executable name and hasa .local suffix. For instance, myapp.exe would have an empty file next to it named myapp.exe.local . When Windows 2000 encounters this file, it looks for a requested component in the directory where the calling application is located or in the subdirectories below it. It will use the version of the component it finds there no matter what path the system has registered for that component. If it can t find a version in the application s directory structure, the system will revert to using the path that s registered. Applications without a .local file continue to use the system registered path .

This method works for most components, but it needs to be tested to ensure that applications that use different versions actually can coexist. Components that store global state in registry keys that are not tied to a particular application or application version or shared memory structures may not operate correctly side by side. Sometimes this can be overcome simply by not running two applications simultaneously that load different versions, but each administrator must decide if that is acceptable to their user base. Other components may use relative paths to access system resources or other components ” assuming they are located in a particular directory. Some things can be safely moved or copied to satisfy this, but Windows system components, especially those protected by Windows file protection, should neverbe moved.

Tools for Deploying Interix Applications

When migrating from UNIX to Interix, one of the main benefits is the similarityof the two platforms. This makes migrating an application to Interix relatively easy. The similarity between the two platforms also extends to the tools available. If you previously created your own deployment scripts using these tools, it should be straightforward to migrate your deployment tools to Interix.

If, however, you have used deployment tools specific to your UNIX distribution, you have to either port these or write scripts using the tools available.

Berkeley Remote Shell Commands (r Commands)

Distributing your application into the Interix environment is likely to require the transfer of files over the network. Typically, you would use the rsh , \rcp , or ftp command to achieve this. These are available as standard in Interix. More detailscan be found in Chapter 6, UNIX and Windows Interoperability.

Scripts

You have a wide range of scripting languages and tools available to you in Interix for the creation of deployment tools. These have been described in Shells and Scripting in Chapter 2, Windows and UNIX Compared. Interix includes Cand Korn Shell Scripts and UNIX Practical Extraction and Report Language (Perl) version 5.6.

Deploying Interix Applications

To deploy your applications to Interix, you will need to develop your own deployment scripts. Typically, you would use the approach described in the next section.

Deploying Interix Applications by Pushing Them to the Desktop

The push application delivery mechanism in UNIX environments is typically implemented by using scripted ftp or rcp commands that copy the application binaries to a computer running UNIX and then activate the application by pointing a symbolic link at the new application binary.

From a management standpoint, remote managed computers contain a selection of management scripts (Perl, C, or Korn Shell) that can be invoked remotely to initiate an application image deployment, enumerate some performance metrics, or audit for security or asset management.

Deploying Interix Applications Using the Berkeley r Commands (later in this chapter) illustrates remote deployment using the rcp and rsh commands.

Using the r Commands for Remote Management in Interix

You can remotely manage Interix systems by using the Berkeley r commands. These commands, such as rsh and rcp , have been described in Chapter 6, Unixand Windows Interoperability. Before you can use these commands for remote administration, you will need to configure the Interix daemon rshd to permit remote access between computers. This is because rcp uses a remote shell at the remote computer (source or destination of the copy) to start a shell to launch the rcp process with the appropriate arguments.

For example, when Interix is the source of the directory copy:

 rcp -r <Interix hostname>:ProgDir <destination hostname>:ProgDir 

Interix has two processes associated with the rcp , as follows:

 user1   9281   1025 20:41:48 -    0:00.03 sh -c rcp -r -f ProgDir user1   9345   9281 20:41:48 -    0:00.26 rcp -r -f ProgDir 

When Interix is the destination (sink) of the directory copy:

 rcp -r <source hostname>:ProgDir <Interix hostname>:ProgDir 

Interix has two processes associated with the rcp , as follows:

 user1   9729   1025 20:41:48 -    0:00.03 sh -c rcp -r -t ProgDir user1   9793   9729 20:41:48 -    0:00.26 rcp -r -t ProgDir 

Notice that the remote rcp is passed a different argument that depends on whetherit is the source ( -f ) or the destination ( -t ) of the copy.

To automate configuring the host equivalent files

  1. Create necessary configuration files and set appropriate permissions:

    /etc/ hosts .equiv.

     $HOME/.password $HOME/.rhosts 
  2. Set appropriate permissions:

     #!/bin/csh # # Does the hosts.equiv file exist? # If not, create an empty one. # if ( ! -f "/etc/hosts.equiv" ) then     #     # create /etc/hosts.equiv     #     touch /etc/hosts.equiv     #     # Set the permissions on /etc/hosts.equiv     #     chmod 755 /etc/hosts.equiv     #     # Set the owner of /etc/hosts.equiv     #     chown +Administrators /etc/hosts.equiv endif # # If environment variable HOME is defined then see if the users  .password file exists. # If not, create it. # if ( $?HOME) then     if ( ! -f "$HOME/.password" ) then         touch $HOME/.password         chmod 600 $HOME/.password     endif       #     # See whether the users .rhosts file exists.     # If not, then create it.     #     if ( ! -f "$HOME/.rhosts" ) then         touch $HOME/.rhosts         chmod 600 $HOME/.rhosts     endif endif 
Note  

You should be aware that the use of the r commands may be restricted for security reasons. If this is the case, you will need to modify the preceding script to reflect your security policies.

Installing MSI Packages Remotely by Using Interix rsh

To launch Win32-based applications from an Interix shell remotely, it is importantto keep in mind that there are no stdin/stdout/stderr file handles on which to read and write. This is because the remote process is connected to pseudo terminals that do not have any corresponding Win32 object. Therefore, Win32-based applications must be wrapped so that they are provided with stdin/ stdout /stderr file handles. The following code shows the remote execution of the ipconfig.exe command:

 $ rsh remotesystem "/dev/fs/C/WINNT/system32/ipconfig.exe  < /dev/null 2>&1  cat" 

You can also execute Win32 command shell ( cmd.exe ) commands. Execution of a remote dir command is:

 $ rsh remotesystem "/dev/fs/C/WINNT/system32/CMD.EXE /c dir  < /dev/null 2>&1   cat " 

When passing Win32 paths by using Interix shells, the \ s must be escaped witha backslash ( \ ). For example, to execute the MSI package installer from an Interix Korn shell, double backslashes (\\) must be passed in the paths to msiexec.exe .The following example shows this for the installation of the Windows 2000 support tools (for example, < drive > :\SUPPORT\TOOLS\2000 RKST.MSI ):

 $ /dev/fs/C/WINNT/system32/msiexec.exe /I <drive>:\SUPPORT\TOOLS\2000RKST.MSI  /Lv C:\Temp\msi.log /qn 

Installing this same MSI package remotely is interesting because rsh also requires that Win32 path backslashes be escaped, and the command path being passed over the remote shell must also have its \ s escaped. So the following rsh command will install the Windows 2000 Support Tools remotely by using an rsh command:

 $ rsh remotesystem "/dev/fs/C/WINNT/system32/msiexec.exe /I  <drive>:\\SUPPORT\\TOOLS\\2000RKST.MSI /Lv C:\\Temp\\msi.log /qn  < /dev/null 2>&1  cat" 

where < drive > is a drive letter available on the remote system.




UNIX Application Migration Guide
Unix Application Migration Guide (Patterns & Practices)
ISBN: 0735618380
EAN: 2147483647
Year: 2003
Pages: 134

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net