Fast path to IBM Prerequisite Scanner Adoption

Transcription

1 Integrated Service Management White paper December 2011 Fast path to IBM Prerequisite Scanner Adoption Planning to adoption in 2 weeks

2 2 Fast Path to IBM Prerequisite Scanner Adoption Table of Contents Introduction...3 Product overview...4 Getting started...5 Step 1: Gather hardware requirements...6 Step 2: Gather software requirements...6 Step 3: Choose distributed or single system deployment...7 Step 4: Create adopter configuration files...8 Step 5: Choose predefined or custom prerequisite checks...10 Step 6: Run and test the prerequisite checks...13 Agile development and fast path adoption...14 More information and contributing to the tool's development...14

3 Integrated Service Management 3 Introduction The process to manually verify and validate that all prerequisites are present in the target environment, before installing a product or solution, can be complicated and time consuming. It often results in oversights, missing prerequisites, or delays in deployments. In addition, customers' ability to thoroughly and successfully complete this process can be impeded by their initial lack of product knowledge or budgetary constraints. Introducing scalability and automation is beneficial and required for complex products that must validate many prerequisites across a potentially large number of target systems. IBM Prerequisite Scanner is a stand-alone prerequisite checking tool that analyzes system environments before the installation or upgrade of a Tivoli product or IBM solution. When Prerequisite Scanner is run, it scans for the specified prerequisites and detects any missing ones before the actual product installation or upgrade takes place; thus, the scan can enable remediation without impacting the deployment schedule. Prerequisite Scanner is designed for adoption by all deployment types, from small proof-of-concepts to large full production rollouts, or from individual Tivoli products to complex solutions. It also provides the ability to extend coverage to other non-ibm products that are part of the overall customer deployment solution. This white paper provides an example of how to add coverage and support for Tivoli Business Service Manager (TBSM) Version 6.1 in Prerequisite Scanner, herein referred to as the TBSM sample adoption. It illustrates the speed and minimal effort required to adopt Prerequisite Scanner. The TBSM sample adoption took about two weeks for the UNIX environment. It was a very similar process for the Windows environment. This white paper provides product adopters and other product experts with helpful tips and techniques to plan and adopt Prerequisite Scanner. It is intended to supplement the IBM Prerequisite Scanner User's Guide that contains detailed instructions on how to the adopt the tool and describes the full set of prerequisite checks available. The white paper first provides a summary of the tool's core components. It then summarizes the main steps to adopt Prerequisite Scanner that includes: gathering the requirements; choosing the installation type; creating configuration files; choosing predefined or custom prerequisite checks; and testing the adoption. While this white paper describes how Tivoli Business Service Manager (TBSM) adopted Prerequisite Scanner, the same principles apply to other IBM and non-ibm products that want to adopt the tool.

4 4 Fast Path to IBM Prerequisite Scanner Adoption Product overview The features and components of the Prerequisite Scanner support quick and easy adoption of the tool and ease of use to run a variety of prerequisite checks. They can be summarized as follows: Product codes are multi character identifiers to indicate which collection of prerequisite checks for a product or separately installable component that the Prerequisite Scanner script must run on a target system. Restriction: The official product codes for IBM Tivoli Monitoring and Tivoli Composite Application Manager agents are used by Prerequisite Scanner; therefore, these product codes are considered reserved. For more information, see the ITM 6.X Product Codes Technote. Prerequisite properties are software and hardware prerequisites and their expected values that are required by a product or solution before its installation. The prerequisite properties are represented as name value pairs, with optional qualifiers. Configuration files are collections of prerequisite properties to check on a target system before product installation occurs. Collectors are native code commands or utilities that collect actual data about the target environment based on the prerequisite properties in the configuration file. Evaluators are scripts that compare the actual data gathered by the collectors and the expected data for the prerequisite properties in the configuration file. Output formats is output to a simple text file for the results, the command-line interface, or debugging and trace log files. The detailed results contain: the version of the Prerequisite Scanner; the version of the operating system on the target system; and the name of the products or components for which the prerequisites checks were run. For each prerequisite property, it also displays: the name of the prerequisite property checked; the PASS or FAIL result; the actual value; and the expected value. The overall PASS or FAIL result is displayed, with any failure of an individual prerequisite check resulting in the failure of the overall scan. prereq_checker script is the primary script, with a set of input parameters, that is executed in a command-line interface and runs a collection of prerequisite checks. The script checks whether the product codes that are passed as input parameters are valid. It checks the actual operating system against the expected operating system in the configuration file, whose file name contains the same product code and the product version as the input parameters. The tool reads the prerequisite properties from the configuration file and uses collectors to gather their actual values. It uses evaluators to compare the actual and expected values of the prerequisite properties. The tool finally returns the results in the relevant output formats. Fast path adoption of Prerequisite Scanner generally involves adding one or many product codes for the new product, creating one or many configuration files, and adding prerequisite properties to those files. Creation of custom prerequisite properties, collectors, and evaluators are only required if the predefined prerequisite properties do not support checks for the adopting product's prerequisites.

5 Integrated Service Management 5 Getting started Before adopting IBM Prerequisite Scanner, obtain the set of hardware and software prerequisites required to successfully install and deploy the product or solution. Generally these prerequisites are outlined in the product's documentation. For example, consult the Installation Guide in the Tivoli Business Service Manager Information Center to obtain the prerequisites for Tivoli Business Service Manager. Adopting IBM Prerequisite Scanner to support a product such as Tivoli Business Service Manager is simple and easy. The steps in the adoption process can be summarized as follows: Step 1: Gather hardware requirements Step 2: Gather software requirements Step 3: Choose distributed or single system deployment Step 4: Create adopter configuration files Step 5: Choose predefined or custom prerequisite checks Step 6: Run and test the prerequisite checks 1 day 1 day 1 day 1 day 2 days 4 days Completing these six steps results in a fully functional Prerequisite Scanner adoption by TBSM in two weeks. A customer's environment can then be scanned and validated early in the planning stages to ensure the target systems satisfy all prerequisites required by the product. Validating that the target systems are ready for deployment before the product's installation can greatly reduce delays and save considerable expense. A good approach is to first use the basic prerequisite properties and ensure that they are operational. Next use more specific or detailed prerequisite properties as you become more familiar with Prerequisite Scanner. As you write Prerequisite Scanner configuration files, keep in mind that the Prerequisite Scanner prerequisite checks not only minimize installation problems, but can also minimize operational problems. For example, a port that needs to be available but is not, might not prohibit the successful completion of the installation, but it might impede subsequent configuration and running of the product. Consider adding operational prerequisite properties as you write the configuration files. For most product implementations, the predefined prerequisite properties are sufficient. Note: If any of predefined prerequisite properties do not meet your needs, you can create custom prerequisite properties, collectors, and evaluators; however, extending Prerequisite Scanner is beyond the scope of this white paper.

6 6 Fast Path to IBM Prerequisite Scanner Adoption Step 1: Gather hardware requirements Start with the basic hardware requirements and determine whether any predefined prerequisite properties can automatically instruct Prerequisite Scanner to scan for these hardware requirements. Hardware requirements for a product are generally available in the product documentation. Predefined prerequisite properties for hardware prerequisites checks are described in the Prerequisite Properties reference in the IBM Prerequisite Scanner User's Guide. For the TBSM sample adoption, the hardware requirements were obtained from the Installation Guide in the Tivoli Business Service Manager Information Center, and are summarized in Table 1. TBSM provides multiple deployment options for its server components. For the purpose of this white paper, we focus on 3 installation options to demonstrate how Prerequisite Scanner can easily and quickly support a new product. Not all installation options are covered. Step 3 goes into more detail on multiple deployment options and how to handle them. See Step 3: Choose distributed or single system deployment. Deployment Component CPU Requirements Memory and Disk Requirements Options Minimum Recommended Minimum Recommended Distributed Data Server 2 CPUs 4 CPUs 6 GB RAM 8 GB RAM 3.0 GHz 3.0 GHz 8 GB hard disk 8 GB hard disk processor processor space space Dashboard 2 CPUs 4 CPUs 6 GB RAM 6 GB RAM Server 3.0 GHz 3.0 GHz 6 GB hard disk 6 GB hard disk Single Server All processor 4 CPUs 3.0 GHz processor processor 8 CPUs 3.0 GHz processor space 8 GB RAM 12 GB hard disk space space 8 GB RAM 12 GB hard disk space Temp Disk Space 500 MB 500 MB 500 MB Table 1: Hardware Requirements for Tivoli Business Service Manager Version 6.1 Typically, the product's Recommended values are used; therefore, those values from Table 1 are the expected values for the hardware prerequisite properties for TBSM. These values can be easily changed in the field if needed, by modifying the expected values in the configuration file. Prerequisite Scanner must check whether the required hardware is present on the target systems and at the recommended level. If the actual hardware level does not match the recommended hardware level, the prerequisite check for the hardware prerequisite must fail and Prerequisite Scanner must return a FAIL result. If the prerequisite check is successful, Prerequisite Scanner returns a PASS result. Step 2: Gather software requirements After the basic hardware requirements, obtain the software requirements. Determine whether any predefined prerequisite properties can automatically instruct Prerequisite Scanner to scan for these software requirements. Software requirements for a product are generally available in the product documentation. Predefined prerequisite properties for software prerequisites checks are described in the Prerequisite Properties reference in the IBM Prerequisite Scanner User's Guide.

7 Integrated Service Management 7 TBSM supports Windows and UNIX systems. For the TBSM sample adoption and the purpose of this white paper, assume the target system is a UNIX or Linux operating system. Windows systems can also be scanned, but require a separate configuration file. The configuration file for Windows systems can be downloaded with the latest Prerequisite Scanner installation package from IBM Fix Central. Table 2 shows the variants for UNIX or Linux operating systems that each installable TBSM server component supports, as specified in the Installation Guide in the Tivoli Business Service Manager Information Center. Prerequisite Scanner must check whether the target system is running one of the supported operating systems. If the actual operating system does not match the required operating system, this prerequisite check returns a FAIL result indicating TBSM will not run on that system. If the prerequisite check is successful, Prerequisite Scanner returns a PASS result. Operating Systems Data Server Dashboar d Server Single Server AIX with SP5, or later for PA-RISC platforms, 32-bit and 64-bit Yes Yes Yes AIX 7.1 POWER System 64-bit Yes Yes Yes Red Hat Linux Enterprise Server 5.0 (AS), Intel x86, 32-bit and 64-bit Yes Yes Yes Red Hat Linux Enterprise Server 6.0 (AS), and 6.1 Intel x86, 32-bit and 64-bit Yes Yes Yes SUSE Linux Enterprise Server 10 Intel x86, 32-bit and 64-bit Yes Yes Yes SUSE Linux Enterprise Server Intel x86, 32-bit and 64-bit Yes Yes Yes Solaris 10 for Sun SPARC platforms, 32-bit and 64-bit Yes Yes Yes Table 2: Software Requirements Tivoli Business Service Manager Version 6.1 In addition to the operating system requirements, Prerequisite Scanner can check for other requirements, for example, which database server is installed, whether the logged on user is a member of the Administrator group, whether the DNS entry for the target computer is correct, or whether a UNIX library package is present on the target system. For the TBSM sample adoption and the purpose of this white paper, only a subset of the checks for the UNIX library package prerequisites are included in the configuration file extract in this white paper; however, many UNIX library packages are required to install and operate TBSM successfully. See Step 5: Choose predefined or custom prerequisite checks. Step 3: Choose distributed or single system deployment Many products have components that can, or must, be distributed across multiple systems. When running Prerequisite Scanner, these components must be declared so the appropriate target systems can be scanned for their prerequisites. There are two options available to implement multiple installable components as follows: Multiple configuration files implement a separate configuration file for each installable component of the product. If you install more than one component on a system, simply specify the product codes associated with each configuration file and installable component when you run the Prerequisite Scanner script.

8 8 Fast Path to IBM Prerequisite Scanner Adoption Single configuration file implement a section containing a collection of prerequisite properties for each installable component in a single configuration file. Environmental variables identify which collection is checked on the target system. The single configuration file is an appropriate option for simple deployment options across a small number of target systems. While a single file eliminates duplication across multiple configuration files, it requires that the environmental variables be set on the target systems before running Prerequisite Scanner. However, if the customer's environment requires scanning hundreds or thousands of systems or endpoints for monitoring agents, a set of configuration files is the most efficient option. Multiple configuration files avoid the need to set environmental variables on all target systems. For the TBSM sample adoption, the set of 3 deployment options for the TBSM server components is implemented by using a single configuration file. An environmental variable represents each deployment option, as shown in Table 3. Option TBSM Data Server installation only TBSM Dashboard Server installation only TBSM Combined Dashboard and Data Server installation Environmental Variable TBSM_PREREQ_DATA TBSM_PREREQ_DASH TBSM_PREREQ_BOTH Table 3: Installable components for the TBSM sample adoption Note: Environmental variables are not used if implementing the multiple configuration files option. Step 4: Create adopter configuration files Prerequisite Scanner uses multi character product codes to indicate which collection of prerequisite checks for a product or separately installable component it must run on a target system. To run Prerequisite Scanner, at least one product code must be passed as an input parameter to the prereq_checker script on the command line. When support for a new product is added to Prerequisite Scanner, a product code must be added to the codename.cfg file to register the product. The codename.cfg file is located in the root Prerequisite Scanner directory. This product code must also be specified in the file name of the associated configuration file. Simply update the codename.cfg file with the product code definition. Ensure that you check whether the product code is already in use. The new 3-character product code definition comprises a name value pair in the following format: Product_Code=Product_Name For the TBSM sample adoption, TBSM uses a single configuration file approach; therefore, only one product code is required and is shown in Sample code 1. #codename.cfg file BSM=Tivoli Business Service Manager Sample code 1: codename.cfg file with one product code Note: If multiple configuration files are required, Sample code 2 registers 3 product codes for multiple configuration files that represent the collection of prerequisite checks for each installable component.

9 Integrated Service Management 9 #codename.cfg file YUK=Tivoli Business Service Manager Data Server BAM=Tivoli Business Service Manager Dashboard Server POW=Tivoli Business Service Manager Single Server Sample code 2: codename.cfg file with multiple product codes After updating the codename.cfg file, create the configuration file and use the product code in the file name to properly identify and consume the new configuration file. Adhere to the following naming convention: Product_Code_[8-digit_VRML_code].cfg For the TBSM sample adoption, TBSM uses the single configuration file option; therefore, only one configuration file is required and is shown in Table 4. Distributable Components Unique Product Code New Configuration File Tivoli Business Service Manager BSM BSM_ cfg Table 4: Unique product codes for single configuration file A common approach is to copy an existing configuration file to start as a base. Note: If multiple configuration files are required, Table 5 summarizes the product codes and configuration files for each deployment option. Distributable Components Unique Product Code New Configuration File TBSM Data Server installation only YUK YUK_ cfg TBSM Dashboard Server installation only BAM BAM_ cfg TBSM Combined Dashboard and Data Server installation POW POW_ cfg Table 5: Unique product codes for multiple configuration files Adding sections to configuration files Prerequisite properties can be grouped under a set of sections in configuration files, with each section representing a data type category, for example, an operating system variant and version, operating system architecture, or environmental variables. The naming convention for the section title is: [category_name:category_value] The category_name can be OSType, OSArch, CPUArch, or Env_Var_Name. You can have multiple data type categories by combining section titles, thereby further restricting prerequisite properties to that set of specified categories only: [category_name:category_value][category_name:category_value] For the TBSM sample adoption, the BSM_ cfg configuration file contains 3 sections for the environmental variables, each one representing the prerequisite properties specific to an installation option. Sample code 3 shows the section and the collection of prerequisite properties for the dashboard server installation option. [@TBSM_PREREQ_DASH:True] is the section title is the environmental variable data category. The TBSM_PREREQ_DASH

10 10 Fast Path to IBM Prerequisite Scanner Adoption environmental variable is set to True on the target system. ##### REQUIREMENTS FOR NON-ROOT INSTALLATION WHERE ONLY DASHBOARD SERVER HAS BEEN SELECTED ##### # Note: The next property dir value checks TBSM default install location. Modify if you will be installing in non-default location. os.space.opt=[dir:non_root=/opt/ibm/tivoli]6gb #os.space.opt=[dir:root=/opt/ibm/tivoli]6gb os.ramsize=6gb No of CPUs=4 Sample code 3: section in BSM_ cfg file The configuration file also contains sections that represent the prerequisite properties specific to an operating system variant, architecture, and version; for example, the section title for the collection of prerequisite properties specific to Red Hat Enterprise Linux Server Version 5.0 or later for a 64-bit IBM System Z (System/390) target system is: [OSType:RedHatEnterpriseLinuxServer5.*][CPUArch:s390x][OSArch:64-bit] Step 5: Choose predefined or custom prerequisite checks After the hardware and software prerequisites have been identified, and the deployment options are known, examine the predefined Prerequisite Scanner prerequisite properties. Determine whether Prerequisite Scanner can check for all identified prerequisites on a target system by using them. For most product implementations, the predefined prerequisite properties are sufficient. If a prerequisite property does not exist for any of the product's prerequisites, submit a Prerequisite Scanner product enhancement request at the Tivoli RFE Community. Alternatively, adopters can write custom prerequisite properties with associated custom collectors. Adopters can then submit them to the Prerequisite Scanner product team for reuse and incorporation into the Prerequisite Scanner base product. Note: Writing custom prerequisite properties and collectors lengthens the time to produce an operational scan and consequently to complete the adoption of Prerequisite Scanner. Extending Prerequisite Scanner is beyond the scope of this white paper. For the TBSM sample adoption, all required prerequisite checks already existed as predefined properties in Prerequisite Scanner. No new prerequisite checks were required, thus saving significant time in rolling out the adoption in the field. Using predefined prerequisite properties also guarantees that prerequisite checking is performed by using the same mechanisms across the Tivoli portfolio. Utilizing predefined prerequisite checks After the configuration files have been created, identify the appropriate prerequisite properties in the Prerequisite Properties reference in the IBM Prerequisite Scanner User's Guide. Add these prerequisite properties and their expected values to the configuration file. For the TBSM sample adoption, the prerequisite properties are summarized in Table 6.

11 Integrated Service Management 11 Requirements Prerequisite Property Categories Prerequisite Property Hardware Recommended number of CPUs Common No of CPUs Recommended CPU speed Common intel.cpu risc.cpu Recommended physical memory OS os.ramsize Recommended hard disk space OS os.space.opt Recommended temporary disk space Common Temp Software Valid operating system, version, and service pack level Common OS Version Required UNIX library packages OS os.package.package_name, for example, os.package.libxp Table 6: Predefined prerequisite properties Sample code 4 is an extract of the single BSM_ cfg configuration file for TBSM Version 6.1. It contains 3 sections for the environmental variables, each one representing the prerequisite properties specific to an installation option. The configuration file also contains sections that represent the prerequisite properties specific to an operating system variant, architecture, and version. Note: Many of the sections and prerequisite properties for UNIX library packages are not contained in the extract. The complete configuration file can be downloaded with the latest Prerequisite Scanner installation package from IBM Fix Central. The single BSM_ cfg configuration file can be split into three separate files, as specified in Table 5. They can be run independently without having to set environmental variables on the target systems or use the associated environmental variable sections in the configuration files. # Configuration file for Tivoli Business Service Manager 6.1 on Unix/Linux # Using environment variables and a configuration file to cover the 3 deployment scenarios # Supported operating systems and versions, as outlined in Table 2 OS Version=RedHat Enterprise Linux Server 5.*, RedHat Enterprise Linux Server 6.*, SUSE Linux Enterprise Server 10 (*), SUSE Linux Enterprise Server 11 (*), AIX V6.1, AIX V7.1, Solaris V10 (SPARC) # Temp disk space needed, as outlined in Table 1 Temp=500MB # CPU Speed, as outlined in Table 1 intel.cpu=3ghz risc.cpu=3ghz ####################### # These sections specify the prerequisites TBSM components with variables, as outlined in # Table 5 # TBSM_PREREQ_BOTH: if set to "true", TBSM DATA and DASHBOARD servers are installed on the # same system # TBSM_PREREQ_DASHBOARD: if is set to "true", TBSM DASHBOARD servers is installed on the # system # TBSM_PREREQ_DATA: if set to "true", TBSM DATA servers is installed on the system # The 3 sections are exclusive, thus only one of the environmental variable must be set to # "true"

12 12 Fast Path to IBM Prerequisite Scanner Adoption ##### REQUIREMENTS FOR NON-ROOT INSTALLATION WHERE BOTH DATA AND DASHBOARD ##### SERVERS HAVE BEEN SELECTED # Note: The next property dir value checks TBSM default installation location. Modify if you will # be installing in a non-default location. os.space.opt=[dir:non_root=/opt/ibm/tivoli]12gb #os.space.opt=[dir:root=/opt/ibm/tivoli]12gb os.ramsize=8gb No of CPUs=8 ##### REQUIREMENTS FOR NON-ROOT INSTALLATION WHERE ONLY DASHBOARD SERVER HAS ##### BEEN SELECTED [@TBSM_PREREQ_DASH:True] # Note: The next property dir value checks TBSM default installation location. Modify if you will # be installing in a non-default location. os.space.opt=[dir:non_root=/opt/ibm/tivoli]6gb #os.space.opt=[dir:root=/opt/ibm/tivoli]6gb os.ramsize=6gb No of CPUs=4 ##### REQUIREMENTS FOR NON-ROOT INSTALLATION WHERE ONLY DATA SERVER HAS BEEN ##### SELECTED [@TBSM_PREREQ_DATA:True] # Note: The next property dir value checks TBSM default installation location. Modify if you will # be installing in non-default location. os.space.opt=[dir:non_root=/opt/ibm/tivoli]8gb #os.space.opt=[dir:root=/opt/ibm/tivoli]8gb os.ramsize=8gb No of CPUs=4 #### Prerequisites for all Red Hat Variants### [OSType:RedHat] os.selinux=[source:command]disabled #### Prerequisites for Red Hat Enterprise Linux Server bit [OSType:RedHatEnterpriseLinuxServer5.*][OSArch:32-bit] os.package.compat-libstdc++-33=compat-libstdc os.package.compat-db=compat-db os.package.libxp=libxp ### complete set of library checks have been removed for this white paper ### #### Prerequisites for Red Hat Enterprise Linux Server bit i686& x86_64 [OSType:RedHatEnterpriseLinuxServer5.*][CPUArch:i686 CPUArch:x86_64][OSArch:64-bit] os.package.compat-libstdc++-33.i386=compat-libstdc os.package.compat-libstdc++-33.x86_64=compat-libstdc os.package.compat-db.i386=compat-db ### complete set of library checks have been removed for this white paper ### #### Prerequisites for Red Hat Enterprise Linux Server bit x86_64 [OSType:RedHatEnterpriseLinuxServer5.*][CPUArch:x86_64][OSArch:64-bit] os.package.compat-libstdc++-296=compat-libstdc ### complete set of library checks have been removed for this white paper ### #### Prerequisites for Red Hat Enterprise Linux Server bit s390x [OSType:RedHatEnterpriseLinuxServer5.*][CPUArch:s390x][OSArch:64-bit] os.package.xorg-x11-xauth=xorg-x11-xauth os.package.compat-libstdc++-33.s390=compat-libstdc os.package.compat-libstdc++-33.s390x=compat-libstdc ### complete set of library checks have been removed for this white paper ### ### complete set of sections for OS variants have been removed for ### this white paper Sample code 4: Extract from the TBSM BSM_ cfg configuration file

13 Integrated Service Management 13 Step 6: Run and test the prerequisite checks You can debug and test the prerequisite checks and configuration files at any time by running the Prerequisite Scanner script. The basic syntax is as follows: prereq_checker "Product_Code [Product_Version]" [detail] [debug] [trace] Product_Code set at least one Product_Code parameter to identify the product or component for which to run the prerequisite check and the associated configuration file. Product_Code is the product code that was specified in the codename.cfg file, as outlined in Step 4: Create adopter configuration files. Product_Version optionally set to identify the version of the product associated with the Product_Code parameter. It is the 8-digit code to represent the version, release, modification, and level, with two digits for each part of the code. If it is not set, Prerequisite Scanner checks the latest available version. detail optionally set to indicate whether to display the detailed results of the scan in the command-line interface window. The tool saves the results to the result.txt file regardless of whether the detail parameter is set. debug optionally set to indicate whether to turn on debugging while running the Prerequisite Scanner. The tool outputs detailed processing information, warning and error messages, and the scan results in the log file. The file name is prs.debug on UNIX systems and precheck.log on Windows systems. trace optionally set to indicate whether to turn on trace logging while running the Prerequisite Scanner on UNIX systems only. The tool outputs trace information in the prs.trc trace file. For example, to scan a target UNIX system for the TBSM Version 6.1 Dashboard server, run the tool as follows:./prereq_checker.sh "BSM " detail The root Prerequisite Scanner directory contains the result.txt file. Illustration 1 shows the results of the scan after setting the TBSM_PREREQ_DASH environmental variable to True on the target system.

14 14 Fast Path to IBM Prerequisite Scanner Adoption Illustration 1: Results of the scan Agile development and fast path adoption IBM Prerequisite Scanner can support new products at any time. Major release cycles are not required, unless Prerequisite Scanner requires embedding into the product's installation program. Adoption of the stand-alone Prerequisite Scanner can be completed and rolled out at any time. Fast path adoption is a good candidate for inclusion in an iteration within an agile development environment. More information and contributing to the tool's development IBM Prerequisite Scanner is available at no-charge from the Prerequisite Scanner page on IBM Support Portal or from IBM Fix Central. New products are constantly being added to the Prerequisite Scanner. For the current list of supported products, visit the Prerequisite Scanner page on IBM Support Portal. Interact with our experts at Service Management Connect. After adopting and deploying Prerequisite Scanner, the adopter's configuration files can submitted to the Prerequisite Scanner framework and maintained in a single tool supporting multiple products and solutions.

15 Copyright IBM Corporation 2011 IBM Global Services Route 100 Somers, NY U.S.A. Produced in the United States of America December 2011 All Rights Reserved IBM, the IBM logo and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at Copyright and trademark information at ibm.com/legal/copytrade.shtml Other company, product and service names may be trademarks or service marks of others. References in this publication to IBM products and services do not imply that IBM intends to make them available in all countries in which IBM operates. Please Recycle