4.1 Custom installation of the Management Server

---

4.1 Custom installation of the Management Server

As explained in the scenario description, we have three zones in our customers environment, as shown in Figure 4-1.

Figure 4-1: Customer production environment

1. The first zone, where the Management Server and the WebSphere Application Servers are, is the intranet zone. The host name of the Management Server is ibmtiv4.

2. The second zone is the DMZ, where the HTTP servers and the WebSphere Edge server are located. In this zone, we will deploy a Store and Forward agent and Management Agents on the rest of the servers. The host name of the Store and Forward agent in this zone is canberra.

3. The last zone is the Internet zone, where we also need to deploy a Store and Forward agent and Management Agents on the client workstations. The host name of the Store and Forward agent in this zone is frankfurt. The canberra Store and Forward agent will be connected directly to the Management Server, while the frankurt Store and Forward agent will be connected directly into the canberra Store and Forward agent. So the Canberra will basically serve as a Management Server for the frankfurt Store and Forward agent.

4.1.1 Management Server custom installation preparation steps

In this section, we will discuss the preparation steps of the Management Server custom installation. We already have installed DB2 Version 8.1 and WebSphere Application Server Version 5.0 with FixPack 1 applied.

Note 

The version number of the WebSphere Application Server changes to 5.0.1 from 5.0 after applying WebSphere FixPack 1.

The following steps will be performed:

1. Operating system requirements check

2. File system creation

3. Depot directory creation

4. DB2 configuration

5. WebSphere configuration

6. Port numbers

7. Generating JKS file

8. Generating KDB and STH files

9. Exchanging certificates

10. Environment variables and last checkups

Here are the steps in more detail:

1. Operating system requirements check

   In our scenario, we are using AIX Version 4.3.3 as the host operating system of the Management Server. The required level of this particular version is 4.3.3.10 or higher. We have previously applied the fix pack for this level. To check if the operating system on the correct level, issue the command shown in Example 4-1 (its output is included as well).

   Example 4-1: Output of the oslevel -r command

    # oslevel -r 4330-10 

2. File system creation

   The installation of the Management Server requires 1.1 GB of free space on AIX: additionally, we also need 1 GB of space for the TMTP database. We have created two file systems, as shown in Table 4-1 on page 89.

   Table 4-1: File system creation

   File system	Size	Function
   /opt/IBM	1.5 GB	The TMTP installation will be performed here.
   /opt/IBM/dbtmtp	1 GB	The TMTP database will reside in this directory.
   /install	4 GB	This will be the root directory of the installation depot and the temporary installation directory during the product installation. This will be removed once the installation is finished successfully.

3. Depot directory creation

   There are two ways to install the TMTP: either you use the original CDs or you download the installation code. In the second case, you need to create a predefined installation depot directory structure. We are using the second option. The following structure has to be created even if you are using a custom installation scenario; however, you do not have to copy the installation source files into the directories if a product like db2 is already installed.

   1. Create /$installation_root/.

      This will contain the Management Server installation binaries. If you have the packed downloaded version, once you unpack, it will create the following two directories:

      • /$installation_root/lib

      • /$installation_root/keyfiles

      If you are using CDs and you still would like to create a depot, you need to copy the entire content of the CD into the /$installation_root/ directory.

   2. Create /$installation_root/db2.

      This will hold the DB2 installation binaries.

   3. Create /$installation_root/was5.

      This is the location where the WebSphere installation binaries will be copied.

   4. Create /$installation_root/wasFp1

      This is the directory for the WebSphere FixPack 1.

   Important: 

   The directory names are case sensitive.

   For detailed descriptions of the files and directories to be copied into the specific product directories, please consult the IBM Tivoli Monitoring for Transaction Performance Installation Guide Version 5.2.0, SC32-1385.

   In our scenario, we have created a file system named /install and use it to serve as the $installation_root. This file system can be removed after the installation.

   To provide temporary space for the product installation itself, we have also created the /install/tmp directory.

   We have the output shown in Example 4-2 if we execute an ls -l command on the /install directory after unpacking the installation files for the Management Server.

   Example 4-2: Management Server $installation_root

    -rwxrwxrwx   1 nuucp    mail        885 Sep 08 09:57 MS.opt -rwxrwxrwx   1 24       24         1332 Sep 08 09:57 MS_db2_embedded_unix.opt -rwxrwxrwx   1 23       23          957 Sep 08 09:57 MS_db2_embedded_w32.opt -rwxrwxrwx   1 13       13        10431 Sep 08 09:57 MsPrereqs.xml drwxrwsrwx   5 root     sys         512 Sep 12 11:19 db2 -rwxrwxrwx   1 12       12          233 Sep 08 09:57 dm_db2_1.ddl drwxrwsrwx   2 493      493         512 Sep 19 09:26 keyfiles drwxrwsrwx   2 493      493         512 Sep 08 09:57 lib drwxrwxrwx   2 root     system      512 Sep 11 10:08 lost+found -rwxrwxrwx   1 lpd      printq       12 Sep 08 09:57 media.inf -rwxrwxrwx   1 11       mqbrkr     3792 Sep 08 09:57 prereqs.dtd -rwxrwxrwx   1 10       audit     16384 Sep 08 09:57 reboot.exe -rwxrwxrwx   1 12       12      532041609 Sep 08 09:58 setup_MS.jar -rwxrwxrwx   1 16       16      18984898 Sep 08 09:58 setup_MS_aix.bin -rwxrwxrwx   1 15       15           24 Sep 08 09:58 setup_MS_aix.cp -rwxrwxrwx   1 16       16      20824338 Sep 08 09:58 setup_MS_lin.bin -rwxrwxrwx   1 15       15           24 Sep 08 09:58 setup_MS_lin.cp -rwxrwxrwx   1 19       19      19277890 Sep 08 09:58 setup_MS_lin390.bin -rwxrwxrwx   1 18       18           24 Sep 08 09:58 setup_MS_lin390.cp -rwxrwxrwx   1 16       16      18960067 Sep 08 09:58 setup_MS_sol.bin -rwxrwxrwx   1 15       15           24 Sep 08 09:58 setup_MS_sol.cp -rwxrwxrwx   1 15       15           24 Sep 08 09:58 setup_MS_w32.cp -rwxrwxrwx   1 16       16      18516023 Sep 08 09:58 setup_MS_w32.exe -rwxrwxrwx   1 11       mqbrkr     5632 Sep 08 09:58 startpg.exe drwxrwsrwx   2 root     sys         512 Sep 11 11:21 tmp -rwxrwxrwx   1 11       mqbrkr    24665 Sep 08 09:58 w32util.dll drwxrwsrwx   5 root     sys         512 Sep 12 11:12 was5 drwxrwsrwx   7 root     sys         512 Sep 18 18:10 wasFp1 

4. DB2 configuration

   As we already mentioned, DB2 Version 8.1 is already installed. We need to perform additional steps to enable the setup to run successfully.

   1. As we are emulating a production environment, we have already created a separate db2 instance for the TMTP database. The instance name and user is set to dbtmtp.

      Note 

      To create a new DB2 instance, you can either use the db2setup program or the db2icrt command.

   2. We have to create the TMTP database before we start the installation. You can choose any name for the TMTP database. In this scenario, we name the database TMTP. We perform the following commands in the DB2 text console to create the TMTP database in the previously created /opt/IBM/dbtmtp directory:

       create database tmtp on /opt/IBM/dbtmtp DB20000I  The CREATE DATABASE command completed successfully. 

   3. We also need to create the buffpool32k bufferpool. So we first connect to the database:

       connect to tmtp Database Connection Information Database server        = DB2/6000 8.1.0 SQL authorization ID   = DBTMTP Local database alias   = TMTP 

      and create the required bufferpool:

       create bufferpool buffpool32k size 250 pagesize 32 k DB20000I  The SQL command completed successfully 

   4. Now we have finished configuring the DB2.

5. WebSphere configuration

   The most important thing is to make sure that the WebSphere FixPack 1 is applied, because this is a critical prerequisite prior to the installation. To check it out, log on to the WebSphere admin console and click on the Home button in the browser window. We see the window shown in Figure 4-2 on page 92.

   
   Figure 4-2: WebSphere information screen

   Since the version of the WebSphere is 5.0.1, the WebSphere FixPack 1 is applied.

6. Port numbers

   In this scenario we will use the default port numbers for the TMTP installation. These are:

   • Port for non SSL clients: 9081

   • Port for SSL clients: 9446

   • Management Server SSL Console port: 9445

   • Management Server non Secure Console port: 9082

   Important: 

   Since we will perform a custom secure installation, the Management Server non Secure Console port is not applicable in this scenario; however, we mention it to show all the possibly required ports. If you wish to perform a nonsecure installation, the Management Server SSL Console port will not be applicable.

   The following ports are important for observing the already installed products.

   • DB2 8.1:

     DB2_dbtmtp	60000/tcp
     DB2_dbtmtp_1	60001/tcp
     DB2_dbtmtp_2	60002/tcp
     DB2_dbtmtp_END	60003/tcp
     db2c_dbtmtp	50000/tcp

   • WebSphere 5.0.1:

     Admin Console port	9090
     SOAP connector port	8880

7. Generating JKS files

   In order to secure our environment using Secure Socket Layer (SSL) communication, we have to generate our own JKS files. We will use the WebSphere's ikeyman utility. We need to create three JKS files:

   1. prodms.jks: This will be used by the Management Server.

   2. proddmz.jks: This will be used by the Store and Forward agent and for those Management Agents that will connect to the Management Server through a Store and Forward agent.

   3. prodagent.jks: This will be used by those Management Agents that have direct connections to the Management Server.

   We type the following command to start the ikeyman utility on AIX:

    ./usr/WebSphere/AppServer/bin/ikeyman.sh 

   This command will take us to the ikeyman dialog shown in Figure 4-3.

   
   Figure 4-3: ikeyman utility

   • We select the Key Database File → New option once the ikeyman utility starts.

   • We select JKS from the Key Database Type, since this is supported by the TMTP. We name it prodms.jks and set the location to /install/keyfiles to save the file, as shown in Figure 4-4 on page 94.

     
     Figure 4-4: Creation of custom JKS file

   • At the next screen (Figure 4-5), we provide the password for the JKS file. We have to use this password during the installation of the TMTP product.

     
     Figure 4-5: Set password for the JKS file

   • We choose to create a new self signed certificate. We select the New Self Signed Certificate from the Create menu (see Figure 4-6 on page 95).

     
     Figure 4-6: Creating a new self signed certificate

     Note 

     At this point, you have the following options: You can purchase a certificate from a Certificate Authority, you can use a pre-existing certificate, or you can create a self signed certificate. We chose the last option.

   • In Figure 4-7 on page 96, we define the following:

     Key Label	prodms.
     Common name	ibmtiv4.itsc.austin.ibm.com, which is the fully qualified host name of the machine where the Management Server will be installed.
     Organization	IBM.
     Country or Region	US.

     
     Figure 4-7: New self signed certificate options

   We leave the rest of the options on the default setting.

   • In the next step, shown in Figure 4-8 on page 97, we modify the password of the new self signed certificate by selecting Key Database File → Change Password and then pressing the OK button, as in Figure 4-9 on page 97.

     
     Figure 4-8: Password change of the new self signed certificate

     
     Figure 4-9: Modifying self signed certificate passwords

   • Once the password is changed, we are ready to create the JKS file for the Management Server.

     The next step is to create the same JKS files for the Management Agent and for the Store and Forward agent. We use the same steps as above, except for some different parameters, as explained in Table 4-2 on page 98.

     Table 4-2: JKS file creation differences

     File name	Self signed certificate's name
     proddmz.jks	proddmz
     prodagent.jks	prodagent

8. Generating KDB and STH files

   Once the JKS files are generated, we need to generate a KDB file and its STH (password) file for the correct secure installation of the WebSphere Caching proxy on the Store and Forward agents. The WebSphere Caching proxy gets installed automatically with the Store and Forward agent. We will generate these files:

   prodsnf.kdb	CMS Key Database file
   prodsnf.sth	The Password file for the CMS Key Database file

   We have to use a gskit5 tool (provided with the WebSphere Application Server) in installable format. First, we need to install it. The installation files are located under [WebSphereRoot]/gskit5install/, in our case, it is /usr/WebSphere/AppServer/gskit5install/. We execute the installation with the following command:

    ./gskit.sh 

   The product gets installed to the /usr/opt/ibm/gskkm/ directory. The executable are located in the /usr/opt/ibm/gskkm/bin directory.

   • We start the utility with the following command:

      ./gsk5ikm 

   • We select the New option from the Key Database File menu, as in Figure 4-10 on page 99.

     
     Figure 4-10: GSKit new KDB file creation

   • We select the CMS Key Database file from the menu. The file name will be prodsnf.kdb (see Figure 4-11).

     
     Figure 4-11: CMS key database file creation

   • We set the password and select the Stash the password to a file option. The stash file name will be prodsnf.sth (see Figure 4-12 on page 100).

     
     Figure 4-12: Password setup for the prodsnf.kdb

   • Now we create a New self signed certificate (see Figure 4-13).

     
     Figure 4-13: New Self Signed Certificate menu

   • We name the new certificate prodsnf and the organization IBM. The procedure for the KDB file creation is finished after pressing the OK button (see Figure 4-14 on page 101).

     
     Figure 4-14: Create new self signed certificate

9. Exchanging certificates

   The next step is to exchange the certificates between the JKS and KDB files.

   • In Figure 4-15 on page 102, the.arm files represent the self signed certificates. We have created a self signed certificate for each JKS and KDB file. The next task is to import these certificates into the relevant JKD or KDB files.

     
     Figure 4-15: Trust files and certificates

   • Figure 4-16 on page 103 shows which JKS or KDB file needs to have which self signed certificate:

     prodms.jks	Needs to have all the certificates.
     prodagent.jks	Needs to have the certificate from the Management Server and its default certificate. This file will be used for the Management Agents connecting directly to the Management Server.
     proddmz.jks	Needs to have the certificates from the Management Server and from the prodsnf.kdb file. This file is used for the Store and Forward agent and for its Management Agents in the same zone.
     prodsnf.kdb	Needs to have the certificate from the Management Server and from the Store and Forward agent's JKS files. This file is used by the WebSphere Caching proxy.

     
     Figure 4-16: The imported certificates

   • To exchange the certificates, we have to extract them into .arm files. Start the IBM Key Management tool by executing the following command:

      ./ikeyman.sh 

   • We open the prodms.jks file and press the Extract Certificate button (Figure 4-17 on page 104).

     
     Figure 4-17: Extract Certificate

   • We extract the certificate into the prodms.arm file (Figure 4-18).

     
     Figure 4-18: Extracting certificate from the msprod.jks file

   • Now we add the extracted certificate into the dmzagent.jks file. We open the prodagent.jks file and select the Signer Certificate menu from the drop-down menu and press on the Add button (Figure 4-19 on page 105).

     
     Figure 4-19: Add a new self signed certificate

   • Select the prodms.arm file and press OK to add it to the prodagent.jks file (Figure 4-20).

     
     Figure 4-20: Adding a new self signed certificate

   • After pressing OK, the ikeyman tool asks for the label of the certificate. Use the same name as in the arm file (Figure 4-21 on page 106).

     
     Figure 4-21: Label for the certificate

   • The imported certificate is now on the Signer Certificates list (Figure 4-22).

     
     Figure 4-22: The imported self signed certificate

   We follow these steps to extract and add all self signed certificates into the relevant JSK or KDB files.

10. Environment variables

    Prior to the installation we have to source the DB2 and WebSphere environment variables as follows:

     . /usr/WebSphere/AppServer/bin/setupCmdLine.sh . /home/dbtmtp/sqllib/db2profile 

    This will enable you to set up the program to detect the location and perform actions on DB2 and WebSphere.

    Also, set up the variable $TMPDIR to define the new temporary installation directory which will be used by the setup program:

     export TMPDIR=/install/tmp/ 

    Note 

    Before you start the installation, make sure that both the DB2 server and the WebSphere server are up and running.

4.1.2 Step-by-step custom installation of the Management Server

In this section, we will go through the steps of the Management Server installation. As in the previous section, we have prepared our environment for the installation.

• We launch the shell setup program using the following command:

   ./setup_MS_aix.bin -is:tempdir $TMPDIR 

  The $TMPDIR variable represents the directory where the temporary installation files will be copied.

• Press Next in Figure 4-23 on page 108 to proceed to the next window.

  
  Figure 4-23: Welcome screen on the Management Server installation wizard

• We accept the license agreement in Figure 4-24 on page 109 and press Next.

  
  Figure 4-24: License agreement panel

• We leave the installation directory on the default setting (Figure 4-25 on page 110). We have previously created the /opt/IBM file system to serve as installation target.

  
  Figure 4-25: Installation target folder selection

• In the next window (Figure 4-26 on page 111), we enable the SSL for Management Server communication. We previously created the prodms.jks file, which serves as the trust and key files. We leave the port settings as the defaults.

  
  Figure 4-26: SSL enablement window

• The installation wizard automatically detects the location of the installed WebSphere if the environment variables are set correctly. In our environment, the WebSphere Application Server security is not enabled, so we unchecked the check box and set the user to root (Figure 4-27 on page 112). Since the WebSphere Application Server security is not enabled, the user you specify here must have root privileges to perform the operation. The installation automatically switches the WebSphere Application Server security on once the product was installed and the WebSphere Server has been restarted.

  
  Figure 4-27: WebSphere configuration panel

• As the DB2 database is already installed, we choose for the Use an existing DB2 database option (Figure 4-28 on page 113).

  
  Figure 4-28: Database options panel

• As we already created the dbtmtp db2 instance and the TMTP database on the DB2 level. We choose tmtp for the Database Name, and the database user will be the DB2 instance user dbtmtp. The JDBC path is /home/dbtmtp/sqllib/java/ (see Figure 4-29 on page 114).

  
  Figure 4-29: Database Configuration panel

  Tip 

  The JDBC path is located under $instance_home/sqllib/java/. So for example, if you use the default instance of the DB2, which is db2inst1, the JDBC path will be /home/db2inst1/sqllib/java/.

• After the DB2 configuration, the setup program reaches the final summarization window (Figure 4-30 on page 115). We press Next and the installation of the Management Server starts (Figure 4-31 on page 116).

  
  Figure 4-30: Setting summarization window

  
  Figure 4-31: Installation progress window

• The installation wizard now creates the TMTP database tables two additional tablespaces: TMTP32K and TEMP_TMTP32K. It also registers the TMTPv5_2 application in the WebSphere Server.

• Once the installation is finished (Figure 4-32 on page 117), the WebSphere Server must be restarted, because the WebSphere Application Server security will now be applied. To stop and start the WebSphere server, we use the following commands. These scripts are located in the $was_installation_directory/bin/. In our case, it is /usr/WebSphere/AppServer/bin/.

  
  Figure 4-32: The finished Management Server installation

   ./stopServer.sh server1 -user root -password [password] ./startServer.sh server1 -user root -password [password] 

• Once the WebSphere server is restarted, we log on to the TMTP server by typing the following URL into our browser:

  https://[ipaddress]:9445/tmtpUI/

• As the installation was successful, we see the following logon screen in the browser window (Figure 4-33 on page 118).

  
  Figure 4-33: TMTP logon window

4.1.3 Deployment of the Store and Forward Agents

In this section, we will deploy the Store and Forward agents into the DMZ and the intranet zone. The following preparations are needed for the installation of the Store and Forward agents:

1. Copy the installation binaries to the local systems. We already did that task. We created the c:\install folder, where we copied the installation binaries for the Store and Forward agent. We copied the binaries of the WebSphere Edge Server Caching proxy to the c:\install\wcp folder.

2. Check to see if the Management Server and Store and Forward agents' fully qualified host names are DNS resolvable.

3. The Store and Forward agents platform will be Windows 2000 Advanced Server with Service Pack 4. The required disk space for all platforms is 50 MB, not including logs.

   The installation wizard will install the following components:

   1. WebSphere Edge Server Caching proxy

   2. Store and Forward agent

   3. We start the installation executing the following command on the Canberra server:

       setup_SnF_w32.exe -P snfConfig.wcpCdromDir=C:\install\wcp 

      where the -P snfConfig.wcpCdromDir=directory specifies the location of the WebSphere Edge Server Caching proxy installation binaries.

   Figure 4-34 should appear. Click on Next.

   
   Figure 4-34: Welcome window of the Store and Forward agent installation

4. In the next window, we accept the License agreement (Figure 4-35 on page 120).

   
   Figure 4-35: License agreement window

   • Figure 4-36 on page 121 specifies the installation location of the Store and Forward agent. We leave this on the default setting.

     
     Figure 4-36: Installation location specification

5. In the first field of Figure 4-37 on page 122, we can specify the Proxy URL. This URL can be either the Management Server itself or in a chained environment and another Store and Forward agent. This specifies the URL where the Store and Forward agent connects to. We specify the Management Server, since this Store and Forward agent is in the DMZ.

   
   Figure 4-37: Configuration of Proxy host and mask window

   As the Management Server has security enabled, we have to specify the protocol as https and the connection port as 9446. The complete URL will be the following:

   https://ibmtiv4.itsc.austin.ibm.com:9446

   In the Mask field, we can specify the IP addresses of the computers permitted to access the Management Server through the Store and Forward agent. We choose the @(*) option, which lets all Management Agents connect to this Store and Forward agent in this zone.

6. In Figure 4-38 on page 123, we specify the SSL Key Database and its password stash file. This is required for the installation of the WebSphere Caching proxy. The SSL protocol will be enabled using these files. We are using the custom KEY and STASH files prodsnf.kdb and prodsnf.sth.

   
   Figure 4-38: KDB file definition

7. In Figure 4-39 on page 124, we have to specify the following things:

   • SnF Host Name: The Store and Forward agent fully qualified host name. In our case, it is canberra.itsc.austin.ibm.com.

   • User Name/User Password: We have to specify a user that has an agent role on the WebSphere Application Server, which is the same as the Management Server in our environment. We specify the root account.

   • Enable SSL: We select this option, since we have a secure installation of the Management Server.

   • We use the Default Port Number, which is 433. This will be the communication port for the Management Agents connecting to this Store and Forward agent.

   • SSL Key store file / SSL Key store file password: We use the previously created JKS file, which is proddmz.jks, and its password.

   
   Figure 4-39: Communication specification

8. In Figure 4-40 on page 125, we have to specify a local administrative user account what will be used by the Store and Forward agent service. We specify the local Administrator account, which already exists.

   
   Figure 4-40: User Account specification window

9. We press Next in the window shown in Figure 4-41 on page 126, and the installation starts to install the Store and Forward agent first (Figure 4-42 on page 127).

   
   Figure 4-41: Summary before installation

   
   Figure 4-42: Installation progress

10. Once the installation of the Store and Forward agent is completed (Figure 4-43 on page 128), the setup installs the WebSphere Caching proxy. After that, the machine needs to be rebooted. Click on Next on the screen shown in Figure 4-43 on page 128.

    
    Figure 4-43: The WebSphere caching proxy reboot window

11. After the reboot, the installation resumes and configures the WebSphere Caching proxy and the Store and Forward agent. Click on Finish (Figure 4-44 on page 129) to finish the installation.

    
    Figure 4-44: The final window of the installation

12. We will now deploy the Store and Forward agent for the Internet zone (frankfurt.itsc.austin.ibm.com). This Store and Forward agent will connect to the Store and Forward agent in the DMZ (canberra.itsc.austin.ibm.com). We follow the same installation steps for the previous Store and Forward agent. The different parameters can be found Table 4-3.

    Table 4-3: Internet Zone SnF different parameters

    Parameter	Value
    Proxy URL	https://canberra.itsc.austin.ibm.com:443
    SnF Host Name (fully qualified)	frankfurt.itsc.austin.ibm.com

Note 

The User Name/user password fields are still referring to the root user on the Management Server, since this user ID needs to have access to the WebSphere Application Server.

4.1.4 Installation of the Management Agents

We will cover the installation of the Management Agents in this section. As we have the mentioned, we have three zones, and each Management Agent will log on to the Management Server using its zone's Store and Forward agent, or, if the Management Agent is located in the intranet zone, it will log on directly to the Management Server. We first install the Management Agent for the intranet zone. The following pre-checks are required:

1. Check if the Management Server and Store and Forward agents' fully qualified host names are DNS resolvable.

2. The Management Agent's platform will be Windows 2000 Advanced Server with Service Pack 4. The required disk space for all platforms is 50 MB, not including logs.

3. The installation wizard will install the following components:

   • Management Agent

4. We start the installation wizard by executing the following program:

    setup_MA_w32.exe 

   You should get the window shown in Figure 4-45.

   
   Figure 4-45: Management Agent installation welcome window

5. We accept the license agreement and click on the Next button (Figure 4-46).

   
   Figure 4-46: License agreement window

   • We leave the default location for the Management Agent target directory. Click Next (Figure 4-47 on page 132).

     
     Figure 4-47: Installation location definition

6. In Figure 4-48 on page 133, we specify the parameters for the Management Agent connection.

   
   Figure 4-48: Management Agent connection window

   • Host Name: As we are in the intranet zone, the Management Agent will directly connect to the Management Server. We specify the Management Server's host name as ibmtiv4.itsc.austin.ibm.com.

   • User Name / User Password: We have to specify a user that has the agent role on the WebSphere Application Server, which is the same as the Management Server in our environment. We specify the root account.

   • Enable SSL: We select this option, since we have a secure installation of the Management Server.

   • Use default port number: As the Management Server is using the default port number, we select Yes at this option.

   • Proxy protocol/Proxy Host/Port number: As we are not using proxy, we specify the No proxy option.

   • SSL Key Store file/password: We previously created a custom JKS file to serve the agent connections, so we specify the prodagent.jks file and its password.

7. In Figure 4-49 on page 134, we specify a local administrative user account that will be used by the Management Agent service. We specify the local Administrator account, which already exists.

   
   Figure 4-49: Local user account specification

8. We press Next on the installation summary window (Figure 4-50 on page 135).

   
   Figure 4-50: Installation summary window

   Press the Finish button in the window shown in Figure 4-51 on page 136 to finish the installation.

   
   Figure 4-51: The finished installation

9. All Management Agents must be installed with the same parameters in the intranet zone. Table 4-4 summarizes the changed parameters for the Management Agent installation in the DMZ and the Internet zone.

   Table 4-4: Changed option of the Management Agent installation/zone

   Parameter	DMZ	Internet zone
   Host Name (The host name of the Store and Forward agent in the specified zone)	Canberra	Frankfurt
   Port Number (The default port number of the Store and Forward agent)	443	443
   SSL Key Store File/password	dmzagent.jks	dmzagent.jks

Note 

The User Name/user password fields are still referring to the root user on the Management Server, since this user ID needs to have access to the WebSphere Application Server.

---