PDA Management With IBM Tivoli Configuration Manager Sg246951

Front cover
PDA Management with IBM Tivoli Configuration Manager

A primer for deployments of any size and proofs of concept Step-by-step installation and how-to instructions Scenario-based PDA management
Edson Manoel Zoltan Veress Szabolcs Barabas
ibm.com/redbooks
International Technical Support Organization PDA Management with IBM Tivoli Configuration Manager May 2003
SG24-6951-00
Note: Before using this information and the product it supports, read the information in Notices on page vii.
First Edition (May 2003) This edition applies to IBM Tivoli Configuration Manager Version 4, Release 2, and IBM Tivoli Access Manager for e-business Version 3, Release 9.
Copyright International Business Machines Corporation 2003. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Part 1. Concepts, planning, and implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. Device management architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Device Management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1 Tivoli Resource Manager and Web Gateway . . . . . . . . . . . . . . . . . . . 4 1.1.2 Device Management internals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Our approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Chapter 2. Getting the environment up and running . . . . . . . . . . . . . . . . . 13 2.1 Planning for the single-box installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.1 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.2 Hardware requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.3 Installation matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Single-box implementation: RS/6000-based . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.1 IBM DB2 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.2 IBM DB2 Fixpack 7 installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.3 IBM WebSphere installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.4 IBM WebSphere Fixpack 3 installation . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.5 IBM Tivoli Configuration Manager installation . . . . . . . . . . . . . . . . . . 26 2.2.6 Tivoli Web Gateway Server installation on AIX . . . . . . . . . . . . . . . . . 33 2.3 Single-box implementation: Intel-based . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.3.1 IBM DB2 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.3.2 IBM DB2 Fixpack 7 installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.3.3 IBM WebSphere installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.3.4 IBM WebSphere Fixpack 3 installation . . . . . . . . . . . . . . . . . . . . . . . 47 2.3.5 IBM Tivoli Configuration Manager installation . . . . . . . . . . . . . . . . . . 47 2.3.6 Tivoli Web Gateway Server installation on WIndows . . . . . . . . . . . . 53 2.4 Tivoli Resource Gateway configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Chapter 3. Implementing security on the PDA management environment65 3.1 General considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Copyright IBM Corp. 2003. All rights reserved.
iii
3.2 Access Manager for e-business installation . . . . . . . . . . . . . . . . . . . . . . . 67 3.2.1 Installing IBM Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.2.2 Installing Access Manager - Policy Server . . . . . . . . . . . . . . . . . . . . 72 3.2.3 Installing Access Manager - Authorization Server . . . . . . . . . . . . . . 74 3.2.4 Installing Access Manager - Application Development Kit . . . . . . . . 76 3.2.5 Installing Access Manager - WebSEAL . . . . . . . . . . . . . . . . . . . . . . 78 3.2.6 Installing Access Manager - Java Runtime Environment . . . . . . . . . 82 3.3 Configuring the secure environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.3.1 Creating a WebSEAL junction to the Web Gateway . . . . . . . . . . . . . 86 3.3.2 Configuring query_contents for WebSEAL . . . . . . . . . . . . . . . . . . . . 89 3.3.3 Installing Tivoli Web Gateway with security enabled . . . . . . . . . . . . 91 3.3.4 Configuring Web Gateway to use WebSEAL junction . . . . . . . . . . . 92 Part 2. Case study scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Chapter 4. Managing pervasive devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.1 Case study overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.2 Managing Nokia 9290 Communicator . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.2.1 Installation and configuration of the Device Agent for Nokia. . . . . . 103 4.2.2 Distributing software packages to Nokia 9290 Communicator . . . . 108 4.3 Managing Palm devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.3.1 Installation and configuration of the Device Agent for Palm . . . . . . 118 4.3.2 Distributing software packages to Palm . . . . . . . . . . . . . . . . . . . . . 122 4.3.3 Performing inventory scan on Palm . . . . . . . . . . . . . . . . . . . . . . . . 131 4.4 Managing WinCE/PocketPC devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 4.4.1 Installation and configuration of the Device Agent for PocketPC . . 138 4.4.2 Distributing software on WinCE/PocketPC . . . . . . . . . . . . . . . . . . . 142 4.4.3 Running inventory on the WinCE/PocketPC . . . . . . . . . . . . . . . . . . 149 4.5 Weekly distribution of the price and stock list . . . . . . . . . . . . . . . . . . . . . 153 Appendix A. Troubleshooting Web Gateway and Device Management . 155 Troubleshooting Web Gateway Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Useful log files for installation troubleshooting . . . . . . . . . . . . . . . . . . . . . 157 Cleaning up a failed Web Gateway installation . . . . . . . . . . . . . . . . . . . . . 160 Common Web Gateway and Device Management problems . . . . . . . . . . . . 161 Problems with starting the Web Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 161 Problems with using the Web Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Problems with registering device classes and job classes . . . . . . . . . . . . 164 Problems with enrolling a device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Problems with connecting the agent to the Web Gateway . . . . . . . . . . . . 164 Problems with publishing and downloading a package. . . . . . . . . . . . . . . 167 Problems with running jobs for devices. . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Receiving return codes from the C language APIs . . . . . . . . . . . . . . . . . . 169 Using a non-standard port number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
iv
Inventory problems . . . . . . . . . . . . . . . . . . . . . . Software Distribution problems . . . . . . . . . . . . . Resource Manager problems . . . . . . . . . . . . . . Tracing the Web Gateway . . . . . . . . . . . . . . . . . . .
...... ...... ...... ......
....... ....... ....... .......
...... ...... ...... ......
. . . .
170 170 171 171
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Contents
vi
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.
vii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Redbooks (logo) ibm.com pSeries AIX DB2 Universal Database DB2 IBM PowerPC Redbooks RS/6000 SecureWay SP SP2 Tivoli Enterprise Tivoli TME WebSphere
The following terms are trademarks of other companies: ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, PowerPC and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service marks of others.
viii
Preface
IBM Tivoli Configuration Manager 4.2 was launched in October 2002. Along with many new functional and performance features, it includes an enhanced Web-based device management capability, called Tivoli Web Gateway, running on top of IBM WebSphere Application Server. This Redbook describes in detail the steps required to install and configure Tivoli Web Gateway and all the prerequisite products. The instructions given in this Redbook are very detailed and explicit. These instructions are not the only way to install the products and related prerequisites. They are meant to be followed by someone with limited experience in the products, to allow them to successfully install and set up the pervasive device management environment. Our approach is to install and configure all the products required for the PDA management on a single box. In order to enable security, we also provide installation and configuration of IBM Tivoli Access Manager for e-business on a separate machine. While the information provided by this Redbook can be used on deployments of any size, it will be particularly useful to enable the management of pervasive devices by small and medium businesses (SMBs). It will also help Business Partners and IBM services in setting up demonstrations and proofs of concept.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center. Edson Manoel is a Software Engineer at the International Technical Support Organization, Austin Center, working as an IT Specialist in the Systems Management area. Prior to joining the ITSO, Edson worked in the IBM Software Group as a Tivoli Technology Ambassador and in IBM Brasil Professional Services Organization as a Certified IT Specialist. He was involved in numerous projects, designing and implementing systems management solutions for IBM customers and Business Partners. Edson holds a BSc degree in Applied Mathematics from Universidade de Sao Paulo, Brazil. Zoltan Veress is an independent consultant currently working for IBM Belgium on a large Tivoli rollout. He has five years of experience with Tivoli products and
ix
eight years of IT experience in total. His major areas of expertise include software distribution, inventory, and remote control, and also has experience with almost all major Framework-based products. Szabolcs Barabas is an independent consultant. Formerly he was an IT Specialist IBM Global Services Hungary for five years. He holds a degree in Information Technologies. He has four years of experience with Tivoli products and eight years of IT experience in total. His major areas of expertise include ITM, TEC, and remote control, but has experience with almost all major Framework-based products. Thanks to the following people for their contributions to this project: Joanne Luedtke, Lupe Brown, Wade Wallace, and Chris Blatchley International Technical Support Organization, Austin Center Tom Ellingwood Device Management Development and Test Team, IBM Software Group Raleigh David Thiessen Technical Evangelist, IBM Software Group Austin Alan Hsu Market Manager - Pervasive Devices, IBM Software Group Austin
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:

redbook@us.ibm.com
Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493
Preface
xi
xii
Part 1
Part
Concepts, planning, and implementation
Chapter 1.
Device management architecture

Pervasive Device Management is a new feature of IBM Tivoli Configuration Manager that is used to perform basic operations on pervasive devices. The functionality provided by this new feature includes software distribution, inventory, and configuration. The type of pervasive devices supported are: Palm WinCE and Windows PocketPC Nokia 9200 Series In this chapter, the following topics are discussed: IBM Tivoli Configuration Manager device management overview and architecture IBM Tivoli Configuration Manager components and supporting applications required for management of pervasive devices
1.1 Device Management overview

By extending its management capabilities to pervasive devices, such as PalmOS, WinCE, Windows PocketPC, and Nokia Communicator devices, IBM Tivoli Configuration Manager allows the update of configuration information and software on these devices using the same tools with which desktops and servers are managed. This allows for better control over the increasing number of pervasive devices being used for business applications across the enterprise. Another advantage is that administrators do not need to learn to use a separate, specialized tool for managing different kinds of pervasive devices. The Tivoli Resource Manager and Resource Gateway components enable you to determine where resources, pervasive devices, or users are associated with the computers in your enterprise and provide all the functionality to manage these resources. In the following section we will go over the concepts of both Tivoli Resource Manager and Resource Gateway components, as well as their role in the management of pervasive devices.
1.1.1 Tivoli Resource Manager and Web Gateway

Tivoli Resource Manager (TRM) is a new service that extends the functionality of the Tivoli Management Framework to manage various type of resources. A fourth tier of resources is added by the Tivoli Resource Manager to the three-tiered Tivoli architecture of Tivoli Management Region (TMR) server, gateway, and endpoint. Resources managed by the Tivoli Resource Manager can be either pervasive devices or users. Tivoli Resource Manager enables you to perform operations on pervasive devices, such as inventory scanning, distribution of software packages, and customizing the devices. Tivoli Resource Managers main roles are to: Create an association between each device and assigned endpoint. Retrieve users information and their endpoints. Determine where resources, pervasive or users, are associated. All the resources intended to be managed need to be grouped into resource groups. Resource groups must contain resources of the same type. There can be two types of resource groups:
Device groups for pervasive devices Users groups for Enterprise Directory users
The members of a resource group can be static or dynamic. The resource group shields applications, such as Software Distribution or Inventory, from knowing
device or user concepts by taking care to create an association between each device or user with its assigned endpoint. Figure 1-1 shows the infrastructure of Tivoli Resource Manager.
dSA
Group
Table1
Group
Figure 1-1 Tivoli Resource Manager infrastructure
Tivoli Resource Manager enables you to work with the resource users that are defined in an Enterprise Directory server, for example, the Lightweight Directory Access Protocol (LDAP) server. Users are associated with endpoints in a one-to-one relationship and the mapping is stored in the LDAP server. Tivoli Resource Manager enables you to view the association between a user and an endpoint. Resource tasks will be carried on by Tivoli Resource Manager. It will use a database interface to address the Device Directory (which is a storing system) and to pull information from the Enterprise Directory server via LDAP (see Figure 1-1). The database interface implementation is resource type-specific. A component of Tivoli Resource Manager resides on the Tivoli Server. A Tivoli Resource Manager gateway component, which is installed at the Tivoli gateway level, connects the Tivoli Resource Manager server with the endpoints that are connected by the pervasive devices in the region. A Web Gateway enables you to manage the devices that connect to it. The Web Gateway is installed at the endpoint level and connects to a centrally installed Tivoli Resource Manager. The Web Gateway can communicate with a large number of devices and connect the Tivoli environment with these resources through the endpoint. In this release of IBM Tivoli Configuration Manager, the only Web Gateway supported is the Tivoli Web Gateway (TWG).
Chapter 1. Device management architecture
yrotcer D yrotcer D yrecticeriiiD o veD ec veD ec veD eciiiveD

5
ecafretnI ecafretnI ecafretnI ecafraettnI ecafraettnI esaB aD esaB aD esaBataD esaBataD esaBataD
P AD L
reganaM reganaM reganaM reganaM reganaM reganaM reganaM reganaM ecruoseR ecruoseR ecruoseR ecruoseR ecruoseR ecruoseR ecruoseR ecruoseR
Each Web Gateway has its own resource database, but the Tivoli Resource Manager keeps a master database. The Tivoli Resource Manager and Web Gateway will notify each other of any changes to their database. This will typically happen when a device connects to a Web Gateway and is automatically enrolled or a device is added to the Tivoli Resource Manager database. Depending on the number of resources, a Tivoli Resource Manager configuration could consist of a cluster of Web Gateways sharing the same database management system. The Tivoli Resource Manager uses a RIM host to access and query the RDBMS server; however, the Tivoli Web Gateway uses standard SQL statement to access and query its database. It is possible for the Tivoli Resource Manager and Tivoli Web Gateway to use the same database server, but at the moment only IBM DB2 is supported for the Tivoli Web Gateway database. Figure 1-2 on page 7 shows the relationship between the Tivoli Resource Manager and the Tivoli Web Gateway components.
TMR Server Tivoli Resource Manager Server
RIM Host
RDBMS
Tivoli Gateway Tivoli Resource Manager GW
Endpoint Tivoli Web Gateway Resource Collector WebSphere Server IBM DB2 Client
IBM DB2 Server
HTTP
HTTP
HTTP
Host PCs with Pervasive device connected
Host PC with Pervasive device connected
Figure 1-2 Tivoli Resource Manager and Web Gateway components
To enable the management of pervasive devices, as shown in Figure 1-2, a number of components should be installed as follows: Tivoli Resource Manager server must be installed on the Tivoli Server and it should also be installed on the managed nodes to run Tivoli Resource Manager commands. Tivoli Resource Manager Gateway should be created on Tivoli Gateways that communicate with endpoints hosting the Web Gateway component. The Tivoli Resource Manager Gateway components are also referred to as Resource Gateways.
Tivoli Web Gateway Version 4.2 must be installed on the Tivoli endpoints that connect to pervasive devices. Before installing the Tivoli Web Gateway component for Resource Management of devices, you must install and configure the following software: IBM DB2 IBM WebSphere Application Server
1.1.2 Device Management internals

As previously mentioned, IBM Tivoli Configuration Manager 4.2 has a new feature that extends management to pervasive devices. Software distributions and inventory scans can now be done against these devices. Imagine sending a weekly price list to the Palm devices of 20,000 business partners or sales representatives. Another scenario would have all the pervasive devices become part of a reference model. You can have a reference model for sales, marketing, executives, accounting, etc., such that when a user changes a role in the organization or group, the software on the device changes and the new role will be reflected on the users pervasive device. Before going into detail about how IBM Tivoli Configuration Manager 4.2 manages pervasive devices, we need to provide the concepts of the following IBM Tivoli Configuration Manager 4.2 internal components: Activity Planner Is a deployment service that enables you to define a group of activities to be submitted as an activity plan, to schedule or to execute the plan and monitor it while it runs. Operations can include software distribution and inventory scans. Activity Planner is also known as Activity Planner Manager (APM). Is a deployment service which, together with Activity Planner, supports software distribution, inventory, and change management. Change Manager works with Activity Planner to manage specified groups of users, workstations, or devices as single subscribers. Subscribers can be users, user groups, or devices groups. Change Manager is also known as Configuration Change Manager (CCM).
Change Manager
In addition to being able to send a profile to a group that contains pervasive devices, Activity Planner extends targets and Change Manager extends subscribers to pervasive devices. The Tivoli Web Gateway (TWG) is extended to allow management actions (inventory, software distribution, and device configuration) to be controlled from a TMR server. In the Tivoli environment, the devices are managed using the Tivoli Resource Manager (TRM) service. Using this application the administrator can define devices, can link them to the endpoints that directly or indirectly manage them, and can create device groups.
Device groups are known to the Tivoli Framework (a device group is a specialized profile manager) and can be used by Tivoli applications to address devices. Figure 1-3 shows an example of an activity flow when performing software distribution to pervasive devices:
Administrator
Configuration Change Manager

3
Inventory DB
4
SWDistManager Object
Activity Planner Manager

5
Tivoli Web Gateway Device Directory

6
Tivoli Server / Gateway
Software Dist Engine

6
Software Distribution Agent
Subagent
7 8
Endpoint
CT Abstraction Layer Result Collector 10
11
Websphere Device Gateway

9
HTTP
Figure 1-3 Data flow using software distribution to push to devices
Based on Figure 1-3, here we detail each step of the software distribution prepared by the Tivoli Administrator using the reference model example mentioned above. The flow shown in Figure 1-3 on page 9 is as follows: 1. The administrator defines a reference model for the marketing people that have been assigned a device of type, for example, Palm OS. The default configuration should have an e-mail client, a browser, and a list of contacts for the main customers installed. The software to be installed to the devices is packaged in a Software Distribution package. Suppose that some new people join the marketing division of the company. To install the right software on the new Palms, the administrator adds them to the device group containing all Palms for marketing people and, using CCM, synchronizes the reference model of marketing people to the new devices. 2. CCM, using information in the inventory database, determines the state of the package on the devices and prepares an APM plan to install it on the devices. 3. CCM submits the plan to APM. 4. Before starting an activity of the plan, APM interacts with TRM to define a temporary group to contain the list of devices to be addressed by the operation. 5. APM submits the request to the Software Distribution engine. The request addresses the new temporary group generated. 6. The Software Distribution engine, once having received the device group, interacts with TRM to know the list of the endpoints that control the target devices and submits the request to the endpoints. The diagram shows a single endpoint, but a distribution could actually spawn across several endpoints. 7. When each endpoint receives the distribution, the Software Distribution Agent decodes the software package and executes the actions on the objects, as described in the software package. In this case, the built-in actions are specific for the Palm device. 8. The built-in action for the Palm device (sub-agent) converts the software package into a group of TWG packages and submits a job, addressing all packages, to the Web Gateway. 9. When a target device connects to the TWG, the TWG executes the requested actions on the devices. 10. TWG sends the result of the job execution to the Results Collector. 11.The Results Collector collects results, and sends multiple results based on how the administrator has configured the Results Collector, and sends them to the SWD Manager. The SWD Manager is responsible for the report management for Software Distribution. After these operations the report is sent to APM to allow the update of the state of the plan on devices. Reports
10
are sent from TWG to the SWD Manager by the MCollect service. MCollect moves data from the endpoint to the TMR.
1.2 Our approach

It is the intention of this redbook to show how to enable the management of pervasive devices by small and medium businesses (SMBs). While the information provided in the following chapters can be used on deployments of any size, our focus is to provide a concise and straight forward approach to the deployment of required components into a single box. This single box will serve all pervasive devices in a small- to medium-sized organization. Of course, the instructions provided by this redbook can also be used and easily adapted to any sized deployment. Figure 1-4 on page 12 shows the basic architecture for managing pervasive devices. Since IBM DB2 is the only supported RDBMS by the Tivoli Web Gateway, it is shown in Figure 1-4 on page 12 as the RDBMS used also by the Tivoli server. Chapter 2, Getting the environment up and running on page 13 provides all steps required to install and configure the components for this single-box approach.
11
TMR Server Tivoli Resource Manager Server
RIM Host
Tivoli Gateway Tivoli Resource Manager GW IBM DB2 Server
Endpoint Tivoli Web Gateway Resource Collector WebSphere Server IBM DB2 Client
HTTP
HTTP
HTTP
Host PCs with Pervasive device connected
Figure 1-4 Single-box approach
To optionally protect the enrollment URLs, you can use IBM Tivoli Access Manager for e-business software. The WebSEAL component of Tivoli Access Manager for e-business lets organizations control access to applications and data, and provides Single Sign-On (SSO) for authorized users. Tivoli Access Manager for e-business integrates with the Tivoli Resource Manager via a junction to deliver a secure personalized e-business experience for authorized pervasive devices users. Chapter 3, Implementing security on the PDA management environment on page 65 also provides additional information on how to protect the Tivoli Resource Manager environment.
12
Chapter 2.
Getting the environment up and running

In this chapter, we show how to install the necessary components for PDA management through the Tivoli Web Gateway. Our primary focus is on how to scale down IBM Tivoli Configuration Manager, that is, how to install most of the components on one single server using the model shown in Figure 1-4 on page 12. We will go through the basic installation steps of the components, showing the possible gaps in the installation procedure. The following will be discussed in this chapter: Planning for the single-box installation Single-box implementation: RS/6000-based Single-box implementation: Intel-based Tivoli Resource Gateway configuration
13
2.1 Planning for the single-box installation

In this section, we provide the hardware and software requirements for pervasive management with the Tivoli Web Gateway component of IBM Tivoli Configuration Manager. The information provided here is for reference only. Always consult the IBM Tivoli Configuration Manager Version 4.2 Release Notes, GI11-0934 for up-to-date information.
2.1.1 Software requirements

The following software needs to be installed for the Tivoli Web Gateway: IBM DB2 Universal Database Enterprise Edition Version 7.2 IBM DB2 Universal Database Enterprise Edition Fixpack 7 (Version 7.2.5) IBM WebSphere Application Server Advanced Edition Version 4.0.1 IBM WebSphere Application Server Advanced Edition Fixpack 3 (Version 4.0.3) IBM Tivoli Framework Version 4.1 IBM Tivoli Configuration Manager Version 4.2 IBM Tivoli Access Manager for e-business Version 3.9 or later- Optional IBM Tivoli Access Manager for e-business WebSEAL Version 3.9 or later -
Optional
2.1.2 Hardware requirements

The hardware/operating system requirements for the Tivoli Web Gateway are: For AIX operating systems on pSeries and PowerPC systems, the Web Gateway database and Web Gateway server are supported on IBM AIX 4.3.3 or IBM AIX 5.1 running a 332 megahertz (MHz) or greater processor. For Linux on Intel 486 and Pentium systems, the Web Gateway database and Web Gateway server are supported on Red Hat 7.2 running a 1130 MHz or greater processor. For Solaris operating environment on Sun SPARC systems, the Web Gateway database and Web Gateway server are supported on Sun Solaris 7 or Sun Solaris 8 running a 332 MHz or greater processor. For Windows operating system on Intel 486 and Pentium systems, the Web Gateway database and Web Gateway server are supported on Microsoft Windows NT 4.0 Server with SP 6a, Microsoft Windows 2000 Server with SP2, and Microsoft Windows 2000 Advanced Server with SP2 running a 600 MHz or greater processor.
14
Table 2-1 Memory / disk space requirements for Tivoli Web Gateway
Component Disk Space Memory
Web Gateway database Web Gateway server
672 MB 300 MB
512 MB 1 GB
Bear in mind that the IBM Tivoli Configuration Manager is dependent on some supporting applications, such as IBM DB2 and IBM WebSphere Advanced Edition. The hardware requirements for the system you intend to use also has to meet the minimum hardware requirements of such applications.
Single-box hardware requirements

In order to achieve the single-box approach, here are the hardware specifications used in our lab environment for the Tivoli Web Gateway installation for that particular equipment. We will show the installation procedures for the Tivoli Web Gateway on both AIX and Windows 2000 Advanced server platforms. We use the following hardware and system software: Intel-based Single-box Tivoli Web Gateway Server P4 2.4 GHz processor 1 GB RAM 40 GB hard disk Windows 2000 Advanced Server with Service Pack 3
RS/6000-based Single-box Tivoli Web Gateway Server 2 * POWER3 processor 2 GB RAM 3 * 18 GB hard disk AIX 4.3.3
2.1.3 Installation matrix

This section covers the installation matrixes for the single-box approach on the Intel-based and RS/6000-based platforms. The following tables describe the installation/configuration time requirements for each of the components on each platform. In subsequent sections, we show the installation steps for each server individually. Both the servers will have a separate Tivoli environment. Both the RS/6000-based and Intel-based servers will have only the necessary components of the Tivoli Web Gateway installation. Optionally, a second machine can be used to protect the PDA management environment. In this case, IBM Tivoli Access Manager for e-business and IBM Tivoli Access Manager WebSEAL (WebSEAL) need to be installed. This will be
Chapter 2. Getting the environment up and running
15
covered for the Intel platform only in Chapter 3, Implementing security on the PDA management environment on page 65. The component installation/configuration and estimated times matrix for the RS/6000-based environment is shown in Table 2-2.
Table 2-2 RS/6000-based installation matrix
RS/6000-based Tivoli Web Gateway Server IBM DB2 + IBM DB2 Fixpack 7 (V7.2.5) IBM WebSphere Advanced Edition + Fixpack 3 (V4.0.3) IBM HTTP Server 1.3.19.2 (installed with the base WebSphere installation + fixpack applied) IBM Tivoli Configuration Manager 4.2 (using integrated installation, which includes all the Tivoli software components required for the PDA management solution) Tivoli Web Gateway
1
Estimated Time 1 (minutes) 40 40 90
30
Total estimated time: 3-4 hours
The component installation/configuration and estimated times matrix for the Intel-based environment is shown in Table 2-3.
Table 2-3 Intel-based installation matrix
Intel-based Tivoli Web Gateway Server IBM DB2 + IBM DB2 fixpack 7 (V7.2.5) IBM WebSphere Advanced Edition + Fixpack 3 (V4.0.3) IBM HTTP Server 1.3.19.2 (installed with the base WebSphere installation + fixpack applied) IBM Tivoli Configuration Manager 4.2 (using integrated installation, which includes all the Tivoli software components required for the PDA management solution) Tivoli Web Gateway IBM Tivoli Access Manager 3.9 (includes all the Access Manager components for securing the PDA management environment). Optional.
1
Estimated Time 1 (minutes) 30 40 80
40 120
Total estimated time: 5-6 hours (including optional components)
16
The component installation/configuration and estimated times matrix for the optional security infrastructure - Intel-based environment is shown in Table 2-4.
Table 2-4 Security infrastructure- Intel-based installation matrix
Intel-based Tivoli Web Gateway Server IBM Tivoli Access Manager for e-business 3.9 (includes all the Access Manager components for securing the PDA management environment). Optional. Estimated Time 1 (minutes) 120
2.2 Single-box implementation: RS/6000-based

Prior to installing all the components for the Tivoli Web Gateway and the related software, we need to ensure all the operating system packages are installed and configured at the correct level. On AIX 4.3.3, the following steps need to be performed: 1. We installed the following extra AIX filesets: X11.adt.lib 4.3.3.10 bos.rte 4.3.3.10 devices.isa_sio.baud.rte 4.3.2.1 Note: If you do not have the required level of AIX filesets and you do not have the installation media, you can download the upgrade packages from http://techsupport.services.ibm.com/server/mlfixes/43/. 2. We created and mounted the file systems shown inTable 2-5 to enable a successful installation.
Table 2-5 Created file systems
File system name File system size in 512-byte blocks 1048576 1048576 1048576
/tivoli
/db /dmsdb
3. We also had to expand some base filesystems, such as those listed in Table 2-6 on page 18.
17
Table 2-6 Expanded file systems

File system name /usr /home /tmp Expanded size in 512-byte blocks 3014656 327680 655360
4. We edited the /etc/hosts file to contain both the host name and the fully qualified host name of the Server.
2.2.1 IBM DB2 Server installation

This section describes the IBM DB2 Universal Database Enterprise Edition Server Version 7.2 installation process on AIX. 1. Log in as a user with root authority, move to the directory where the DB2 7.2 Server for AIX CDROM is mounted, and start the DB2 setup utility, as follows:
# ./db2setup
2. The Install DB2 V7 window, shown in Figure 2-1, appears. Select DB2 Administration Client and DB2 UDB Enterprise Edition.
Figure 2-1 Install DB2 V7 components
18
3. A New DB2 instance should be created for the Administration Server database. We specified the DB2 instance name db2inst1, as shown in Figure 2-2. You should also specify /home/db2inst1 as the instance owner directory.
Figure 2-2 Create DB2 Services - DB2 Instance db2inst1
4. The installation process creates the DB2 fenced user. We specified the DB2 instance name db2fenc1, as shown in Figure 2-3 on page 20.
19
Figure 2-3 Create the DB2 fenced user
5. Select the Do not set up DB2 Warehouse Control Database option at the next window and then click OK. 6. Next, Figure 2-4 on page 21 shows the values we used to create the user ID for the DB2 Administration Server.
20
Figure 2-4 Administration Server window
7. The installation process creates and sets the values of several environment variables, for example DB2SYSTEM. 8. At the end of the installation process, you may check the installation log file created at /tmp/db2setup.log. 9. The installed JDBC code level needs to be upgraded to Version 2.0. You should log on to the system with a valid DB2 user ID, and issue the following commands: For bash, Bourne, or Korn shell:
# . INSTHOME/sqllib/db2profile # cd /INSTHOME/sqllib/java12/ # . ./usejdbc2
Where INSTHOME is the home directory of the instance. Verify that the JDBC level is correct by entering the following command:
# echo $CLASSPATH
The output must include the following path:

INSTHOME/sqllib/java12/db2java.zip
21
2.2.2 IBM DB2 Fixpack 7 installation

This session describes the installation of DB2 Fixpack 7 on AIX. Here are the steps for installing IBM DB2 Fixpack 7: 1. Stop all database activity before applying this fixpack. To stop all database activity, issue the commands:
# db2stop # db2admin stop
2. Unzip the fixpack using the following command to get a tar file:
# gzip FP7_U484480.tar.Z
3. Un-tar the fixpack using the following command to extract the fixpack files.
# tar -xvf FP7_U484480.tar
4. Run the following command to install the fixpack from the location where you un-tar the fixpack files.
# ./installFixpack
5. Provide the DB2 instance password if prompted. 6. The installation wizard copies the files and finishes the installation of the fixpack. Note: If you are using a 32-bit IBM DB2 Server, make sure to install the 32-bit Fixpack 7. Or if you are using a 64-bit IBM DB2 Server, make sure to install the 64-bit Fixpack 7.
2.2.3 IBM WebSphere installation

For our environment, we decided to use the IBM WebSphere Application Server Advanced Edition Version 4.0. In this section, we describe the IBM WebSphere Application Server Advanced Edition Version 4.0 installation steps on AIX. In order to install IBM WebSphere Application Server Advanced Edition Version 4.0, perform the following steps: 1. Logged in as a user with root authority, create the WAS40 database on DB2. Next the server and the database need to be cataloged, as shown in Example 2-1, where <hostname> is the host name of your machine.
Example 2-1 Creating and cataloging WAS40 database on DB2
# # # # su - db2inst1 db2 create database was db2 update db config for WAS using applheapsz 256 db2 catalog tcpip node db2svr remote <hostname> server 50000
22
# db2 catalog database was as was40 at node db2svr # db2 connect to was user dmsadmin using dmsadmin
2. Logged in as a user with root authority, issue the following command from the directory where the IBM WebSphere Application Server CD-ROM is mounted:
# ./install.sh
3. You are then prompted to select the type of installation. We have selected Typical Installation, as it will automatically install all the required components, such as the WebSphere Application Assembly Tool (AAT). If you decide to use a different installation method, make sure you select the AAT option. 4. In the next window, the installation wizard asks for the database information. WebSphere Server uses this database repository to store configuration information. In our scenario, we used the local DB2 Server installed on the Server machine.
Database type: DB2
You should also provide the database name:

Database name (SID): was40
The DB2 instance owner home directory:

DB home: /home/db2inst1
And the user ID and password of the DB2 instance owner:

Database user id: db2inst1 Database password: ****
5. In the following window, you need to specify the installation directories. We used the default values /usr/WebSphere/AppServer and /usr/HTTPServer. 6. A final installation window informs you that the setup program has finished. 7. When the installation of WebSphere completes successfully, the window shown in Figure 2-5 on page 24 appears. Select Start the Application Server.
23
Figure 2-5 IBM WebSphere Application Server configuration window
8. Launch the Administrative Console and start the Default Server. 9. Open a Web browser and type in the following URL:
http://WebSphere_Server/servlet/snoop
Where WebSphere_Server can either be the Administration servers host name or IP address. Information about /servlet/snoop is displayed.
24
Figure 2-6 WebSphere Servlet/Snoop information
10.The IBM WebSphere Application Server runs as root and requires access to the IBM DB2 environment. You should insert the following line at the end of roots .profile file:
./home/db2inst1/sqllib/db2profile
Assuming that the db2inst1 is the IBM DB2 instance owner.
2.2.4 IBM WebSphere Fixpack 3 installation

Because the Tivoli Web Gateway Server requires IBM WebSphere Application Server Advance Server 4.0.3, here are the steps for installing IBM WebSphere Fixpack 3: 1. Make sure you stop IBM HTTP Server and IBM WebSphere Application Server before installing the fixpack, as follows: a. To stop the HTTP Server, type the following command:
# cd /usr/HTTPServer/bin # ./apachectl stop
25
b. To stop the IBM WebSphere Application Server:

# cd /WebSphere_AppServer_Install_Directory/bin # ./stopServer.sh
2. Un-tar the fixpack using the following command to extract the fixpack files:
# tar -xvf was40_ae_ptf_3_aix.tar
3. Run the following command to install fixpack from the from the location you un-tar the fixpack files:
# ./install.sh
4. During the installation of this fixpack, the setup asks many questions. These questions allow you to select the modules that the fixpack will update. In our case, we answered No to iPlanet and Apache updates because we were using IBM HTTP Server. 5. Start the WebSphere Server manually:
# cd /<WebSphere_AppServer_Install_Directory>/bin # ./startServer.sh
Where <WebSphere_AppServer_Install_Directory> is the directory where you installed the IBM WebSphere Application Server. Note: In order to have both IBM HTTP Server and IBM WebSphere Application Server, you may add startup entries in the inetd.conf file.
2.2.5 IBM Tivoli Configuration Manager installation

In this section, we will install the IBM Tivoli Configuration Manager 4.2 (ITCM) and the IBM Tivoli Framework 4.1 using the integrated installation option. The integrated installation is a Java-based InstallShield application that guides you through the setup process. We will use the typical installation method in order to simplify the process. In order to make this method work, you must perform the following steps: 1. Create user IDs for the ITCM. The default user IDs and passwords are shown in Table 2-7.
Table 2-7 ITCM default user IDs
User IDs planner mdstatus invtiv Password planner mdstatus tivoli Group ID db2iadm1 db2iadm1 db2iadm1
26
User IDs tivoli dmsadmin dmsuser
Password tivoli
Group ID db2iadm1 db2iadm1 db2iadm1
The users are used by the integrated installation to run the database schema and admin scripts and access the database through the automatically created RIM objects. We also create the required users for the Web Gateway server installation. The dmsadmin DB2 user owns the database tables, and the dmsuser DB2 user accesses and queries the database tables. In our case, we specified the password for those users to be the same as their user IDs. You can use the following command to create the user IDs:
mkuser pgrp='db2iadm1' <userid>
Set the passwords for these users repeating the following command:
passwd <userid>
2. Create the cm_db database performing the following steps:

# su - db2inst1 # db2 create db cm_db
3. Mount the ITCM installation media, go into the FRESH directory and start installation with the following command:
# ./setup_aix.bin
Click Next in the ITCM installation start window (Figure 2-7 on page 28).
27
Figure 2-7 ITCM integrated installation start window
4. Select I accept terms in the license agreement and click Next.
28
Figure 2-8 Installation type selection
5. Select the Typical installation option and click Next. 6. Specify the directory to be used for the installation. Specify /tivoli and click Next.
29
Figure 2-9 Database vendor specification
7. Select DB2 as the database vendor and the /home/db2inst1/sqllib as the Database Client interface home, as shown in Figure 2-9. Note that /home/db2inst1 is the DB2 instance owner directory created during the IBM DB2 installation process. Click Next.
30
Figure 2-10 RDBMS and RIM information specification
8. In the next window (Figure 2-10), specify the RDBMS and RIM information. Most of the information is automatically given by the setup program. Specify the password for the db2inst1 and click Next.
31
Figure 2-11 Review installation settings
9. The Review the Installation Setting window appears. By clicking the Next button, the ITCM installation starts. It will ask frequently for the installation media, such as the Tivoli Framework 4.1 CDs 1 and 2 or the ITCM 4.2 server CD. However, you will not have to look for the specific product directories on the CD, because the installation program finds it automatically.
32
Figure 2-12 Successful installation
10.At the completion of a successful installation, you can check the list of the successfully installed products and database scripts.
2.2.6 Tivoli Web Gateway Server installation on AIX

Important: If you intend to enable security in your pervasive device management environment, you must proceed first with the IBM Tivoli Access Manager for e-business installation. Access Manager must be operational in order to the Tivoli Web Gateway installation be successful. Please refer to Chapter 3, Implementing security on the PDA management environment on page 65 for installation and configuration instructions. The Tivoli Web Gateway Server installation has aJava-based setup program similar to the ITCM4.2 installation. We will use the custom installation type. Before the installation, verify the following: Check if the IBM DB2 server is up and running Verify that IBM HTTP Server is started. In a browser, type the following
http://<hostname>:ihs_http_port
33
Verify that WebSphere Application Server and IBM HTTP Server are started and the Default Server Application server is started. In a browser, type the following:
http://<hostname>:ihs_http_port/servlet/snoop
The following components will be installed by the setup program: Tivoli Endpoint Web Gateway Database Tivoli Web Gateway Server Web Infrastructure Inventory plug-in for Web Infrastructure Software Distribution plug-in for Web Infrastructure For details on each one of the above components, refer to IBM Tivoli Configuration Manager Introduction Version 4.2, GC23-4703. To proceed with the installation, follow these steps: 1. Mount the ITCM installation media and start the installation:
# ./setup_aix.bin
Figure 2-13 Tivoli Web Gateway integrated installation start window
Click Next on the Tivoli Web Gateway installation start window. 2. Select I accept terms in the license agreement and click Next.
34
Figure 2-14 Select Type of Installation
3. Select the Custom installation type and click Next.
Figure 2-15 Tivoli Web Gateway Component selection
35
4. As shown in Figure 2-15 on page 35, select all components to install and click Next.
Figure 2-16 Endpoint Information dialog
5. In the endpoint installation window, specify the following options: Destination directory This is where the endpoint will be installed. Leave this option at the default value, /opt/Tivoli/lcf. Gateway port This is the port of the Tivoli Endpoint Gateway. As the ITCM integrated installation uses the default port for the Gateway, leave this at 9494. Endpoint port This is the port of the installable Tivoli Endpoint. Use the default value, which is 9495. Endpoint options Here, select the lcs.login_interfaces option, which represents the Tivoli Endpoint Gateways IP address and port where the Endpoint will log on at the first time. In our case the full syntax is:
-D lcs.login_interfaces=<IPaddr>+9494
where <IPaddr> is the IP address of the single box.
36
Figure 2-17 Web Gateway Database information specification
6. The next step, shown in Figure 2-17, is to specify the Tivoli Web Gateway database information. The following options need to be specified: Destination directory This is the temporary directory where the database installation files such as sql and shell scripts are unpacked and executed. We used the default option /tmp/TWG. DB2 Instance Name The name of the DB2 instance in our scenario is db2inst1. DB2 port The TCP/IP port of the DB2 server. The default value provided is used (5000). To figure out your DB2 port, look in the /etc/services file. Password for the dmsadmin user We used the dmsadmin as password. Password for dmsuser user We used the dmsuser as password. Database home We used the /dmsdb default option.
37
Database container home The database will be installed in this directory. We used the default option /db/db2.
Figure 2-18 Web Gateway Server Information
7. Define the Web Gateway server- related options shown in Figure 2-18. Destination directory Where the Web Gateway Server files will be installed. We used the default option /usr/TivTwg. Web server home We installed the IBM HTTP server to the /usr/HTTPServer directory, which is the default option. JDBC driver home The location of the JDBC driver. The default option is /home/db2inst1/sqllib/java12/db2java.zip. If you use a different DB2 instance from db2inst1, you have to specify the correct values here.
38
Figure 2-19 Web Gateway Server Configuration Information
8. Specify the RDBMS and Web Gateway connection information in the window shown in Figure 2-19. Using the default options is recommended.
39
Figure 2-20 Access Manager configuration information
Important: If you intend to enable security in your pervasive device management environment, you must proceed first with the IBM Tivoli Access Manager for e-business installation. Access Manager must be operational in order for the Tivoli Web Gateway installation to be successful. Please refer to Chapter 3, Implementing security on the PDA management environment on page 65 for installation and configuration instructions. 9. If you do not wish to enable security with IBM Tivoli Access Manager for e-business, set the Enable Security option to False, as shown in Figure 2-20. Otherwise, refer to 3.3.3, Installing Tivoli Web Gateway with security enabled on page 91 for details on this step.
40
10.The Review the Installation Settings window appears. By clicking the Next button, the installation starts. It will ask frequently for the installation media, such as the Tivoli Framework 4.1 CDs 1 and 2 or the ITCM 4.2 server CD. However, you will not have to look for the specific product directories on the CD, because the installation program finds it automatically. Click Next. 11.At the Successful Installation window, you can check the list of products and components installed.
41
Figure 2-22 Starting the DMS_AppServer
12.To test the installation, start up the DMS_AppServer from the WebSphere Administrative Console. Open the following link in a Web browser:
http://<hostname>/dmserver/ResultsCollector
where <hostname> is the host name of your Tivoli server machine. If the installation was successful, it displays some basic information in the browser window concerning the Web Gateway. Expand the Application Servers folder, right-click DMS_AppServer and select Start.
2.3 Single-box implementation: Intel-based

Prior to installing all the components for the Tivoli Web Gateway and the related software, we need to ensure all the operating system packages are installed and
42
configured at the correct level. On Windows 2000 Advanced Server, the following steps need to be performed: 1. We installed the Service Pack 3 and all the Microsoft critical updates. 2. We stopped and disabled the Internet Information Services (IIS) services because it conflicts with the port to be used by the IBM HTTP server. They both use port 80. Alternatively you can set your IIS server to a different port. If you install a fresh Windows 2000 Advanced Server on your server, you can disable the installation of the IIS when you install the additional services. 3. We edited the c:\winnt\systems32\drivers\etc\hosts file to add the host name and the fully qualified host name of the server machine.
2.3.1 IBM DB2 Server installation

This section describes the IBM DB2 Universal Database Enterprise Edition Server Version 7.2 installation process on Windows. Note: Use the installation media provided with the IBM Tivoli Configuration Manager product. This ensures that you install the correct version and fixpack of DB2.
1. Load the DB2 installation media. 2. Select Start -> Run. Type in D:\setup.exe and click OK to start the installation. From the Installation window, select Install. 3. The Select Products window opens. From this window you can select the component(s) of DB2 for Windows you would like to install. Select DB2 Enterprise Edition as shown in Figure 2-23 on page 44. Click Next.
43
Figure 2-23 Select DB2 Enterprise Edition
4. The Select Installation Type window opens. Select the installation type you prefer. We selected Typical. 5. For the installation directory, we used C:\db2. 6. For the DB2 administrative user, we selected db2admin. 7. After the installation wizard copies the DB2 files onto the machine, the Install OLAP Starter Kit window opens. Select Do not install the OLAP Starter Kit and then click Finish. 8. Update Java. The installed JDBC code level needs to be upgraded to Version 2.0. You should open a DOS-command prompt window and issue the following commands:
cd DB2_DIR\java12 usejdbc2
Where DB2_DIR is the DB2 installation directory. The usejdbc2 command will copy the appropriate version of db2java.zip into the DB2_DIR\java12 directory. 9. Reboot the machine.
2.3.2 IBM DB2 Fixpack 7 installation

This section describes the installation of IBM DB2 Fixpack 7 on Windows.
44
If you are installing the fixpack by using the Administrator account of Windows 2000 Advanced Server, please make sure you complete the following steps: 1. Click Start -> Programs -> Administrative Tools -> Local Security Settings -> User Rights Assignment. 2. In the window, you will see lists of user rights. Make sure the Administrator account has the following rights: Act as part of Operating System Create a token object Increase quotas Replace a process level token
Note: Once you have installed a fixpack, you wont be able to un-install it. 3. Stop all database activity before applying this fixpack. To stop all database activity, on a DB2 command window run:
c:\db2\sqllib\bin:\>db2stop c:\db2\sqllib\bin:\>db2admin stop
4. Unzip and extract the fixpack files to a temporary directory. 5. Run the following command to install fixpack from the fixpack directory:
c:\fp7_wr21311\setup.exe
6. Key in the DB2 instance owner password if the setup prompts for it and click Next. 7. The wizard shows the selection window. Click Next to continue. 8. As soon as the installation ends, reboot the machine.
2.3.3 IBM WebSphere installation

For our environment, we use the IBM WebSphere Application Server Advanced Edition Version 4.0 (plus Fixpack 3). In this section, we describe the IBM WebSphere Application Server Advanced Edition Version 4.0 installation steps on Windows. In order to install IBM WebSphere Application Server Advanced Edition Version 4.0, perform the following steps: 1. Logged in as Administrator, issue the following command from the directory where the IBM WebSphere Application Server CD-ROM is mounted:
setup.exe
2. You are then prompted to select the type of installation. We have selected Typical Installation, because it will automatically install all the required
45
components, such as the WebSphere Application Assembly Tool (AAT). If you decide to use a different installation method, make sure you select the AAT option. 3. In the following window you should specify the installation directories. We used the default values C:\WebSphere\AppServer and C:\IBM HTTPServer. 4. In the next window, the installation wizard asks for the database information. WebSphere uses this database repository to store configuration information. In our scenario we used the local DB2 Server installed on the Runtime server machine.
Database type: DB2
You should also provide the database name to be created:

Database name (SID): was40
Provide the DB2 instance owner user ID, password, and home directory:
Database user id: db2admin Database password: Database Path: c:\db2\sqllib
5. A final installation window informs you that the setup program has finished. 6. When the installation of WebSphere completes successfully, the window shown in Figure 2-24 appears. Select Start the Application Server.
Figure 2-24 IBM WebSphere Application Server configuration window
46
7. Recycle the IBM WebSphere Application Server by clicking Start -> Programs -> IBM WebSphere -> Application Server V4.0 AE ->Stop Admin Server. Then select Start -> Programs -> IBM WebSphere -> Application Server V4.0 AE ->Start Admin Server. 8. Open the services window and set the IBM WS Admin Server 4.0 to start automatically instead of manually. 9. Launch the Administrative Console and start the Default Server. 10.Open a Web browser and type in the following URL:
http://WebSphere_Server/servlet/snoop
Where WebSphere_Server can either be the Administration servers host name or an IP address. Information about /servlet/snoop is displayed. Note: IBM HTTP Server and IBM WebSphere may not start automatically after restarting the machine. In this case, you will have to start it manually. For Windows, you may open the Services window and change the startup option for IBM HTTP Server and IBM WebSphere from Manual to Automatic.
2.3.4 IBM WebSphere Fixpack 3 installation

Since the Tivoli Web Gateway Server requires IBM WebSphere Application Server Advanced Server 4.0.3, here are the steps for installing the WebSphere Fixpack 3: 1. Make sure you stop IBM HTTP Server and IBM WebSphere Application Server before installing the fixpack. 2. Unzip the fixpack named was40_ae_ptf_3.zip to a temporary directory. 3. Run the following command to install the fixpack from the fixpack directory.
c:\was40_ae_ptf_3\install.bat
4. During the installation of this fixpack, the setup asks many questions. These questions allow you to select the modules that the fixpack will update. In our case we answered No to iPlanet updates and Apache updates because we use IBM HTTP Server.
2.3.5 IBM Tivoli Configuration Manager installation

We also need to install IBM Tivoli Configuration Manager 4.2 and Framework 4.1 using the integrated installation option of IBM Tivoli Configuration Manager. The integrated installation is a Java-based InstallShield application, which guides you through the setup process. We will use the typical installation method in order to
47
simplify the process. In order to make this method work, you must perform the following steps: 1. Create user IDs for the ITCM. The default user IDs and passwords are shown in Table 2-8.
Table 2-8 ITCM default user IDs
User IDs planner mdstatus invtiv tivoli dmsadmin dmsuser Password planner mdstatus tivoli tivoli Group ID Administrators Administrators Administrators Administrators Administrators Administrators
The users are used by the integrated installation to run the database schema and admin scripts and access the database through the automatically created RIM objects. We also create the required users for the Web Gateway server installation. The dmsadmin DB2 user owns the database tables, and the dmsuser DB2 user accesses and queries the database tables. In our case, we specified the password for those users to be the same as their user IDs. You can use the following command to create the user IDs:
net user <userid> dmsuser /add net localgroup "Administrators" mdstatus /add
2. Create the cm_db database performing the following steps. Open the DB2 command console by selecting Start -> Programs -> IBM DB2 -> Command Line Processor. Type the following commands:
create db cm_db # su - db2inst1 # db2 create db cm_db
3. Mount the ITCM installation media, go into the FRESH directory and start installation with the following command:
setup.exe
Click Next in the ITCM installation start window (Figure 2-25 on page 49).
48
Figure 2-25 ITCM integrated installation start window
4. Select I accept terms in the license agreement and click Next.
Figure 2-26 Installation type selection
49
5. Select the Typical installation option and click Next. 6. Specify the directory to be used for the installation. Specify c:\Program files\Tivoli as the destination directory and click Next.
Figure 2-27 Database vendor specification
7. Select DB2 as the database vendor and c:\DB2\Sqllib as the Database Client interface home, as shown in Figure 2-27. Note that c:\DB2 is the DB2 instance owner directory created during the IBM DB2 installation. Click Next.
50
Figure 2-28 RDBMS and RIM information specification
8. In the next window (Figure 2-28), specify the RDBMS and RIM information. Most of the information is automatically given by the setup program. Specify the password for the db2admin and click Next.
51
Figure 2-29 Review installation settings.
9. The Review the Installation Setting window appears. By clicking the Next button, the installation starts. It will ask frequently for the installation media, such as the Tivoli Framework 4.1 CDs 1 and 2 or the ITCM 4.2 server CD. However, you will not have to look for the specific product directories on the CD, because the installation program finds it automatically. Click Next. 10.After the Framework installation, you must restart your computer. The installation continues automatically at the reboot. Select the Now option and click Next.
52
Figure 2-30 Successful Installation
11.At the completion of a successful installation, you can see the list of the successfully installed products and database scripts.
2.3.6 Tivoli Web Gateway Server installation on WIndows

Important: If you intend to enable security in your pervasive device management environment, you must proceed first with the IBM Tivoli Access Manager for e-business installation. Access Manager must be operational in order for the Tivoli Web Gateway installation to be successful. Please refer to Chapter 3, Implementing security on the PDA management environment on page 65 for installation and configuration instructions. The Tivoli Web Gateway Server installation has a Java-based setup program similar to the ITCM4.2 installation. We will use the custom installation type. Before the installation, verify the following: Check if the IBM DB2 server is up and running. Verify that IBM HTTP Server is started. In a browser, type the following:
http://<hostname>:ihs_http_port
53
Verify that WebSphere Application Server and IBM HTTP Server are started and the Default Server Application server is started. In a browser, type the following:
http://<hostname>:ihs_http_port/servlet/snoop
The following components will be installed by the setup program: Tivoli Endpoint Web Gateway Database Tivoli Web Gateway Server Web Infrastructure Inventory plugin for Web Infrastructure Software Distribution plugin for Web Infrastructure For details on each one of the above components, refer to IBM Tivoli Configuration Manager Introduction Version 4.2, GC23-4703 . To proceed with the installation, follow these steps: 1. Mount the ITCM installation media and start the installation:
setup.exe
Figure 2-31 Tivoli Web Gateway integrated installation start window
Click Next in the Tivoli Web Gateway installation start window. 2. Select I accept terms in the license agreement and click Next.
54
Figure 2-32 Select Type of Installation
3. Select the Custom installation type and click Next.
Figure 2-33 Tivoli Web Gateway Component selection
55
4. As shown in Figure 2-33, select all components to install and click Next.
Figure 2-34 Endpoint Information dialog
5. In the endpoint installation window (Figure 2-34 on page 56), specify the following options: Destination directory This is where the endpoint will be installed. Leave this option at the default value, /opt/Tivoli/lcf. Gateway port The port of the Tivoli Endpoint Gateway. As the ITCM integrated installation uses the default port for the Gateway left this on 9494. Endpoint port The port of the installable Tivoli Endpoint. Also use the default value which is 9495. Endpoint options Here, specify the lcs.login_interfaces option, which represents the Tivoli Endpoint Gateways IP address and port where the Endpoint will log on the first time. In our case the full syntax is
-D lcs.login_interfaces=<IPaddr>+9494
where <IPaddr> is the IP address of the single box.
56
Figure 2-35 Web Gateway Database information specification
6. The next step, shown in Figure 2-35, is to specify the Tivoli Web Gateway database information. The following options need to be specified: Destination directory This is the temporary directory where the database installation files such as sql and shell scripts are unpacked and executed. We used the default option. DB2 Instance Name The name of the DB2 instance; in our scenario it is db2. DB2 port The TCP/IP port of the DB2 server. The default value provided is used (5000). Password for the dmsadmin user We use dmsadmin as the password. Password for dmsuser user We use dmsuser as the password.
57
Figure 2-36 Web Gateway Server Information
7. Define the Web Gateway server-related options, shown in Figure 2-36. Destination directory Where the Web Gateway Server files will be installed. We used the default option c:\Program Files\TivTwg. Web server home We installed the IBM HTTP server to the c:\Program Files\IBM HTTP Server directory, which is the default option. JDBC driver home The location of the JDBC driver. The default option is c:\DB2\SQLLIB\java12\db2java.zip.
58
Figure 2-37 Web Gateway Server Configuration Information
8. Specify the RDBMS and Web Gateway connection information in the window shown in Figure 2-37. Using the default options is recommended.
59
Figure 2-38 Access Manager Configuration information
Important: If you intend to enable security in your pervasive device management environment, you must proceed first with the IBM Tivoli Access Manager for e-business installation. Access Manager must be operational in order for the Tivoli Web Gateway installation to be successful. Please refer to Chapter 3, Implementing security on the PDA management environment on page 65 for installation and configuration instructions. 9. If you do not wish to enable security with IBM Tivoli Access Manager for e-business, set the Enable Security option to False, as shown in Figure 2-20 on page 40. Otherwise, refer to 3.3.3, Installing Tivoli Web Gateway with security enabled on page 91 for details on this step.
60
10.The Review the Installation Setting window appears (Figure 2-39). By clicking the Next button, the installation starts. It will ask frequently for the installation media, such as the Tivoli Framework 4.1 CDs 1 and 2 or the ITCM 4.2 server CD. However, you will not have to look for the specific product directories on the CD, because the installation program finds it automatically. Click Next. 11.In the Successful Installation window, you can check the list of products and components installed.
61
Figure 2-40 Starting the DMS_AppServer
12.To test the installation, start up the DMS_AppServer from the WebSphere Administrative Console. Open the following link in a Web browser:
http://<hostname>/dmserver/ResultsCollector
where <hostname> is the host name of your Tivoli server machine. If the installation was successful, it displays some basic information in the browser window concerning the Web Gateway. Expand the Application Servers folder, right-click the DMS_AppServer and select Start.
2.4 Tivoli Resource Gateway configuration

The Tivoli Resource Gateway component needs now to be configured in order for it to accept the enrollment of new pervasive devices. The configuration process is the same on both Windows and AIX platforms. Therefore, in this section, we will use the RS/6000-based server as the example. Its host name is itcmpda5.
62
We first need to associate the endpoint itcmpda5 with the Resource Gateway by issuing the wresgw command as follows:
# wresgw add itcmpda5 -C TWG
To check if the association was successful, we display a list of the Resource Gateways issuing the wresgw command as follows:
# wresgw ls itcmpda5
The assigned endpoint itcmpda5 is displayed; thus it is assigned as a Resource Gateway. The next step is to enable auto enrollment of the devices on the just assigned Resource Gateway itcmpda5. Using the Auto Enrollment, the devices are automatically registered in the Resource Manager Database. Issue the wresgw command as follows:
# wresgw autoenroll enable -C TWG itcmpda5 FBBWD0035I Resource gateway itcmpda5 accepted the new settings.
As a last check, we list the configuration of the Resource Gateway itcmpda5 issuing the wresgw command as follows:
# wresgw view_config -C TWG itcmpda5 FBBWD0037I Resource gateway itcmpda5 is configured with the following settings: AUTO_ENROLL = true REGISTER_APP_FOR_DEVICE_CREATE_EVENT = 1148766224#ResourceManager
Alternatively, you can perform the same actions - except associating an endpoint with the Resource Gateway - from the Tivoli Desktop by clicking the Resource Manager icon.
63
64
Chapter 3.
Implementing security on the PDA management environment

In this chapter we will describe the installation and configuration procedures and security considerations for the newly created device management environment. The topics covered include: General considerations IBM Tivoli Access Manager for e-business installation Configuring Access Manager WebSEAL Creating a WebSEAL junction to the Web Gateway Installing Access Manager - Java Runtime Environment Configuring query_contents for WebSEAL Installing Tivoli Web Gateway with security enabled Configuring Web Gateway to use WebSEAL junction Note: Rather than focus on the obvious security-related issues such as protecting the operating system, password handling, or network security, we will focus only on the security issues for ITCM and the Tivoli Web Gateway.
65
3.1 General considerations

The usual installation and operation procedures dont provide you with advanced security possibilities such as: Access control Resources are protected and accessed only by authorized parties. Restricting access on the basis of passwords, IP address, host names, or SSL client authentication ensures access control. Authenticity You know who you are talking to and that you can trust that person. Authentication, using digital signature and digital certificates, user ID and password, or other mechanisms ensures authenticity. Information integrity Messages are not altered while being transmitted. Without information integrity, you have no guarantee that the message you sent matches the message received. Digital signature ensures integrity. Privacy and confidentiality Information conveyed from party to party during a transaction remains private and cannot be read, even if it gets into the wrong hands. Encryption ensures privacy and confidentiality. In order to improve security for the pervasive devices management environment, you could opt for the following: 1. Apply additional security on the Web server running on the single box (for example, secure communnications with SSL, use an advanced authorization method, etc.). 2. You can install IBM Tivoli Access Manager for e-business on a second machine, thus creating a secure domain. The focus of this chapter is to create a secure domain using IBM Tivoli Access Manager for e-business installed on a second machine. The installation procedures for Windows platform will be described in the sections below. For more information on IBM Tivoli Access Manager for e-business architecture and implementation, refer to the following Redbooks:
Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014 Enterprise Business Portals with IBM Tivoli Access Manager, SG24-6556 Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885
66
3.2 Access Manager for e-business installation

In this section, we show you how to install and configure IBM Tivoli Access Manager, and how to integrate it with Tivoli Web Gateway. You will have administrative and configuration tasks on both the IBM Tivoli Configuration Manager/Tivoli Web Gateway and the Access Manager servers. For easier understanding, we describe whether the task should be performed on the Access Manager server or on the IBM Tivoli Configuration Manager/Tivoli Web Gateway server. Since the Access Manager for e-business requires the IBM Directory Server product be up and running, we first proceed with its installation.
3.2.1 Installing IBM Directory Server

In this section, we describe the IBM Directory Server installation process using the easy install method of IBM Tivoli Access Manager. In our scenario, this step should be performed on the Access Manager system. Important: The easy install scripts do not work when run from any location on the hard drive except the root directory of its drive. There are two options to work around this: 1. Run the scripts from the product CDs. 2. If all the product images are on your hard drive, share the directory containing the easy install scripts. Then mount the share to your own system, so that the easy install scripts are now in the root directory of your share drive. Now you can run the scripts from the share drive. The easy install script ezinstall_ldap_server.bat sets up a base system with the following software packages: IBM DB2 Universal Database Edition IBM Global Security Toolkit (GSK) IBM HTTP Server IBM Directory Client IBM Directory Server Note: Please make sure that there is no other Web servers running on your computer (such as IIS), because that can cause configuration problems during the installation and configuration.
Chapter 3. Implementing security on the PDA management environment
67
1. From the root directory of the IBM Tivoli Access Manager 3.9 Base System installation drive, run the following command:
ezinstall_ldap_server.bat
The initial installation window is displayed as shown in Figure 3-1. Press Enter.
Figure 3-1 Ezinstall initial window
2. The installation process requests the DB2 administrator ID password (Figure 3-2). Supply a password for the DB2 administrator, and press Enter. You have to re-enter the password for verification.
Figure 3-2 IBM DB2 Configuration Options window
3. The installation process requests the IBM HTTP Server administrator ID password (Figure 3-3 on page 69). Supply a password for the IBM HTTP Server administrator, and press Enter.
68
Figure 3-3 IBM HTTP Server Configuration Options window
4. Accept the default value for the IBM Global Security Toolkit (GSK) installation directory, c:\Program Files\IBM\GSK, and enter Y to continue. 5. Accept the default value for the IBM Directory Client installation directory, c:\Program Files\IBM\LDAP, and enter Y to continue. 6. The SecureWay Directory Server Configuration window appears. The following options need to be changed: Option 2 Supply an LDAP Administration password, and then re-enter it for verification. Press Enter to continue. Option 4 Enter the suffix for your LDAP environment. The suffix specifies the distinguished name of where the Global Sign-On (GSO) database is located in the LDAP server directory information tree (DIT). At minimum, enter your organization (o) and country code (c) separated by a comma. For example:
o=tivoli,c=us
After you set it, press Enter to continue. Figure 3-4 on page 70 shows the SecureWay Directory Server Configuration settings. Double-check the configuration options and enter Y and then press Enter to continue. The installation process is then initiated.
69
Figure 3-4 IBM Directory Server Configuration Options window
7. As shown in Figure 3-5, after DB2 is installed, you have to restart your computer. Press Enter to restart the PC. The installation will continue right after restart.
Figure 3-5 IBM Directory Server Installation and Configuration window
70
Figure 3-6 IBM Directory Server installation - restart
8. As shown in Figure 3-6, after restart, the install script continues the installation and configuration of the remaining components. After the installation of IBM SecureWay Directory Server, you have to restart your computer again. Press Enter to continue. 9. After restart, the IBM SecureWay Directory Server gets configured, and the installation finishes. Press Enter to exit from the install script, as shown in Figure 3-7.
Figure 3-7 IBM Directory Server Installation and Configuration window
71
3.2.2 Installing Access Manager - Policy Server

In this section, we describe the Access Manager Policy Server installation process using the easy install method of IBM Tivoli Access Manager. This step should be performed on the Access Manager system. The easy install script, ezinstall_pdmgr.bat, sets up a base system with the following software packages: IBM Global Security Toolkit (GSKit) IBM SecureWay Directory client Access Manager runtime Policy Server 1. From the root directory of the IBM Tivoli Access Manager 3.9 Base System installation drive, run the following command:
ezinstall_pdmgr.bat
The initial installation window is displayed, as shown in Figure 3-8.
Figure 3-8 Response file for ezinstall
This window indicates that a response file was created previously for this process. The response file stores all the parameters of the previously installed software modules of IBM Tivoli Access Manager. This prevents users from reinstalling specific modules or reconfiguring previously configured software. Press Y to use the response file. 2. The installation process will require the following information: The host name of the LDAP Server. Enter the host name of your server.
72
The suffix. Enter the suffix that you specified during the IBM Directory Server installation. Whether SSL communication will be used with the LDAP server. The installation window is shown in Figure 3-9.
Figure 3-9 Access Manager Runtime Configuration Options window
3. As shown in Figure 3-10, enter the LDAP server administrator password that youve specified during the IBM Directory Server installation and press Enter.
Figure 3-10 Access Manager Policy Server Configuration Options window
4. As shown in Figure 3-11 on page 74, the installation requests the computer to be restarted. Press Enter to restart the PC. The installation will continue right after restart.
73
Figure 3-11 Access Manager Policy Server Installation and Configuration window
5. After restart, both the Access Manager Runtime and the Access Manager Policy Server are configured automatically. When they are done, press Enter to exit the install script. This is shown in Figure 3-12.
Figure 3-12 Access Manager Policy Server successful installation
3.2.3 Installing Access Manager - Authorization Server

In this section, we describe the Access Manager Authorization Server installation process using the easy install method of IBM Tivoli Access Manager. This step should be performed on the Access Manager system.
74
The easy install script, ezinstall_pdacld.bat, sets up a base system with the following software packages: IBM Global Security Toolkit (GSKit) IBM SecureWay Directory client Access Manager runtime Authorization Server 1. From the root directory of the IBM Tivoli Access Manager 3.9 Base System installation drive, run the following command:
ezinstall_pdacld.bat
The initial installation window is displayed, as shown in Figure 3-13.
This window indicates that a response file was created previously for this process. The response file stores all the parameters of the previously installed software modules of IBM Tivoli Access Manager. This prevents users from reinstalling specific modules or reconfiguring previously configured software. Press Y to use the response file. 2. The installation process will require the following information: The LDAP administrator password. Enter the LDAP server administrator password that you specified during the IBM Directory Server installation and press Enter. The Security Master user ID password. The user ID sec_master will be created at this time. The sec_master user ID is the highest level of authorization in the Access Manager secure domain. Enter the sec_master password and press Enter.
75
3. As soon as the sec_master password has been specified, the installation proceeds with the configuration of the Authorization Server. 4. The installation process ends as soon as the configuration of the Authorization Server ends, as shown in Figure 3-14. Press Enter to exit the script.
Figure 3-14 Successful installation
3.2.4 Installing Access Manager - Application Development Kit

In this section, we describe the Access Manager Application Development Kit installation process using the easy install method of IBM Tivoli Access Manager. This step should be performed on the Access Manager system. The easy install script, ezinstall_pdauthadk.bat, sets up a base system with the following software packages: IBM Global Security Toolkit (GSKit) IBM SecureWay Directory client Access Manager runtime Application Development Kit (ADK) 1. From the root directory of the IBM Tivoli Access Manager 3.9 Base System installation drive, run the following command:
ezinstall_pdauthadk.bat
The initial installation window is displayed, as shown in Figure 3-15 on page 77.
76
This window indicates that a response file was created previously for this process. The response file stores all the parameters of the previously installed software modules of IBM Tivoli Access Manager. This prevents users from reinstalling specific modules or reconfiguring previously configured software. Press Y to use the response file. 2. The installation process ends as soon as the configuration of the related Access Manager components end, as shown in Figure 3-16. Press Enter to exit the script.
Figure 3-16 Access Manager ADK Installation and Configuration window
77
3.2.5 Installing Access Manager - WebSEAL

In this section, we describe the Access Manager WebSEAL installation process using the easy install method of IBM Tivoli Access Manager. This step should be performed on the Access Manager system. The WebSEAL installation separates file extraction from package configuration. Use an InstallShield program to install the WebSEAL files. Next, use the IBM Tivoli Access Manager configuration utility to configure the WebSEAL Server. 1. From the root directory of the IBM Tivoli Access Manager 3.9 Base System installation drive, run the following command:
<CD_Drive>:\windows\PolicyDirector\Disk Images\Disk1\WebSEAL\Disk Images\Disk1\setup.exe
2. Select the language. We are using the English version. 3. The Access Manager WebSEAL Setup window appears (Figure 3-17). Select Next.
Figure 3-17 Access Manager WebSEAL Setup window
4. Click Yes to accept the License Agreement. 5. Select the installation directory or accept the default value provided. 6. As shown in Figure 3-18 on page 79, select the available components to be installed. They are Access Manager WebSEAL Server (PDWeb) and Access Manager WebSEAL Application Development Kit (PDWebADK). Click Next to accept these components and continue.
78
Figure 3-18 WebSEAL component selection
7. The installation completes with the success window, shown in Figure 3-19. Click Finish to complete the installation.
Figure 3-19 WebSEAL - successful installation
79
Configuring Access Manager WebSEAL

After the installation of WebSEAL has completed, we need to use the Access Manager configuration utility to configure the WebSEAL Server. 1. Select Start -> Programs -> Access Manager for e-business -> Configuration. The Access Manager Configuration window appears. This is shown in Figure 3-20.
Figure 3-20 Access Manager for e-business Configuration
2. Select Access Manager WebSEAL, and click the Configure button. The HTTP properties window appears.
Figure 3-21 Setting WebSEAL HTTP properties
80
Select Allow [unsecure] TCP HTTP access and Allow HTTPS access and specify their port numbers. Note: If you are running any other Web servers on this computer, verify that the TCP HTTP port for the other servers does not conflict with the WebSEAL TCP HTTP port. 3. The Access Manager Administrator Password window appears. Enter the password for the sec_master user ID specified during the Authorization Server installation.
Figure 3-22 Access Manager Administrator Password
Note: if you repeatedly enter an incorrect password, you may see the error message: Error: This account has been temporarily locked out due to too many failed login attempts. If this occurs, obtain the correct password, wait five minutes for the lock to clear, and then restart the configuration program. 4. When configuration completes, a status message states that the configuration was successful. The Access Manager Configuration window appears.
81
Figure 3-23 WebSEAL configured successfully
3.2.6 Installing Access Manager - Java Runtime Environment

Important: This step should be performed on the Tivoli Web Gateway system. To install and configure the Access Manager Java Runtime Environment (pdjrte), follow these steps: 1. Make sure you stop IBM HTTP Server and IBM WebSphere Application Server before installing the Access Manager Java Runtime Environment. 2. Delete the IBMJCEfw.jar file in the jvm_path\jre\lib\ext directory. The default location is C:\WebSphere\AppServer\java\jre\lib\ext\ibmjcefw.jar. 3. To install the Access Manager JRE component, run the setup.exe command in the <CDDrive>:\windows\PolicyDirector\Disk Images\Disk1\PDJRTE\Disk Images\Disk1 directory. 4. Select the language. We are using the English version. 5. The Access Manager Java Runtime Setup window appears (Figure 3-24 on page 83). Select Next.
82
Figure 3-24 Access Manager Java Runtime welcome window
6. Click Yes to accept the License Agreement. 7. Select the installation directory or accept the default value provided. 8. The installation completes with the success window, shown in Figure 3-25. Click Finish to complete the installation.
Figure 3-25 Java Runtime setup installation complete
83
9. When the runtime installation has completed, the system must be rebooted. Select Yes to restart your computer. 10.Make sure the IBM SecureWay Directory, IBM WebSphere Admin Server and IBM HTTP Server services are running. 11.To successfully run Access Manager configuration commands, such as the pdjrtecfg command, the Java binary for the WebSphere Application Server must be the first entry in your PATH statement. On Windows, enter the following command:
set PATH=C:\WebSphere\AppServer\java\jre\bin;%PATH%
12.You need to configure the Java Runtime Environment provided by IBM Tivoli Access Manager. Enter the following commands:
cd C:\Program Files\Tivoli\Policy Director\sbin pdjrtecfg -action config -java_home C:\WebSphere\AppServer\java\jre
This command sets the java_home variable of Access Manager Java Runtime. 13.When the environment variable is set, create the SSL configurations file and keystores. Run the following command on each Web Gateway server:
java com.tivoli.mts.SvrSslCfg application_name security_password policy_server_hostname authorization_server_hostname policy_server_port authorization_server_port configuration_file keystore_file operation
Where: application_name Is the name of the Access Manager application to create and associate with the SSL communication. The application name must be unique. Other instances of the application, which are running on this or other systems, must each be given a unique name. A distinguished name can be used when an LDAP-based user registry is used with Access Manager. security_password Is the sec_master user ID password. policy_server_hostname Is the name of the system where the Access Manager Policy Server process (ivmgrd) is running. authorization_server_hostname Is the name of the system where the Access Manager Authorization Server process (ivacld) is running. In our case, it is the same system as the Policy Server.
84
policy_server_port Is the port used for SSL communication with the Policy Server. The default is port 7135. authorization_server_port Is the port used for SSL communication with the Authorization Server. The default port is 7136. configuration_file Is the URL to the configuration file. The URL must use the file:/// format. The default is <java_home>/PdPerm.properties, where <java_home> is the directory where the Access Manager Java Runtime Environment is installed. keystore_file Is the URL to the keystore file. The URL must use the file:/// format. The default is <java_home>/PdPerm.ks, where <java_home> is the directory where the Access Manager Java Runtime Environment is installed. The PDPerm.properties and PdPerm.ks files must be in the same directory. operation Specify create. Valid operations are create, replace, or unconfig. For example:
java com.tivoli.mts.SvrSslCfg twg_application secmastpw itcmpda3 itcmpda3 7135 7136 file:///C:/WebSphere/AppServer/java/jre/PolicyDirector/PdPerm.properties file:///C:/WebSphere/AppServer/java/jre/PolicyDirector/Pd.ks create
3.3 Configuring the secure environment

This section provides configuration procedures for enabling security in the pervasive devices management environment. Such procedures will enable the integration of IBM Tivoli Access Manager with Tivoli Web Gateway. We describe administrative and configuration tasks on both the IBM Tivoli Configuration Manager/Tivoli Web Gateway and the Access Manager servers. For easier understanding, we describe whether the task should be performed on the Access Manager server or the IBM Tivoli Configuration Manager/Tivoli Web Gateway server
85
3.3.1 Creating a WebSEAL junction to the Web Gateway

Access Manager provides authentication, authorization, and management services for a network. In our environment, these services are provided by the front-end WebSEAL Servers that integrate and protect Web resources and applications located on back-end Web application servers. The back-end Web application server in our scenario is represented by the Tivoli Web Gateway system. The connection between a WebSEAL Server and a back-end Web application server is known as a WebSEAL junction, or junction. A WebSEAL junction is a TCP/IP connection between a front-end WebSEAL Server and a back-end Web application server. Junctions allow WebSEAL to protect Web resources located on back-end servers. A WebSEAL junction over a TCP connection provides the basic properties of a junction but does not provide secure communication across the junction. SSL junctions allow secure end-to-end browser-to-application transactions. You can use SSL to secure communications from the client to WebSEAL and from WebSEAL to the back-end server. The back-end server must be HTTPS-enabled when you use an SSL junction. Figure 3-26 represents the two basic types of junction.
Figure 3-26 Basic types of WebSEAL junctions
86
More information on junctions can be found in the IBM WebSEAL Administration Guide, SC32-1134. WebSEAL supports the following authentication methods: Basic Authentication (ba-auth) Basic authentication is a standard method for providing a user name and password to the authentication mechanism. BA is defined by the HTTP protocol and can be implemented over HTTP and over HTTPS. By default, WebSEAL is configured for authentication over HTTPS via basic authentication. Forms-based Authentication (forms-auth) Access Manager provides forms-based authentication as an alternative to the standard basic authentication mechanism. This method produces a custom HTML login form from Access Manager instead of the standard login prompt resulting from a basic authentication challenge. When you use forms-based login, the browser does not cache the user name and password information as it does in basic authentication. This method can be implemented over HTTP and over HTTPS as well. Note: If the forms-based authentication method is enabled, the basic authentication method settings are ignored. Handheld devices can only use basic authentication. Both base and forms authentication settings are done in the WebSEALd.conf file located in the C:\Tivoli\PDWeb\etc directory. Also in the WebSEALd.conf file there is the use-same-session entry. This option is for enabling or disabling the ability to use the same session data when a client switches between HTTP and HTTPS. More information on authentication can be found in the IBM WebSEAL Administration Guide, SC32-1134. in order to create a junction between the Access Manager WebSEAL Server and the Tivoli Web Gateway Server, on the Access Manager machine, perform the following steps: 1. Start the pdadmin command environment by clicking Start -> Programs -> Access Manager for e-business -> Administration Command Prompt. 2. Log in to the Access Manager by entering the command:
login -a sec_master -p sec_master_password
87
Use the server list command to verify server identification. This will also provide the name of the WebSEAL Server name: webseald-<hostname>.
Figure 3-27 pdadmin utility - server list
Note: Please check in advance that the WebSEAL Server can access the Web Gateway and vice versa, using both simple and fully qualified host names. 3. Create the junction using the server task command as follows:
server task webseald-<hostname> create -j -c all -t tcp -h <webgateway_hostname> -p 80 /twgapp
Example (Figure 3-28 on page 89):

server task webseald-itcmpda3 create -j -c all -t tcp -h itcmpda1 -p 80 /twgapp
88
Figure 3-28 pdadmin utility - creating junction
Type exit to quit the pdadmin command environment.
3.3.2 Configuring query_contents for WebSEAL

To protect the Tivoli Web Gateway resources using the Access Manager security service, we must provide WebSEAL with information about the contents of the Tivoli Web Gateway Web space. A CGI program called query_contents provides this information. The query_contents program searches the Tivoli Web Gateway Web space contents and provides this inventory information to the Web Portal Manager on WebSEAL. The program comes with the WebSEAL installation, but must be manually installed on the Tivoli Web Gateway server. There are different program file types available, depending on whether the third-party server is running UNIX or Windows. In order to make WebSEAL aware of the contents of the Tivoli Web Gateway, perform the steps in the next sections.
Tivoli Web Gateway running on Windows

1. Copy the file query_contents.exe file from the C:\Program Files\Tivoli\PDWeb\www\lib\query_contents directory on the Tivoli Access Manager machine into the C:\Program Files\IBM HTTP Server\cgi-bin on the Tivoli Web Gateway machine.
89
2. Copy the file query_contents.cfg file from the C:\Program Files\Tivoli\PDWeb\www\lib\query_contents directory on the Tivoli Access Manager machine into the C:\WINNT on the Tivoli Web Gateway machine. 3. On the Tivoli Web Gateway machine, edit the file C:\WINNT\query_contents.cfg to define the docroot parameter as follows:
docroot=C:\Program Files\IBM HTTP Server\htdocs
4. Restart the IBM HTTP Server, and test query_contents by entering the following URL into a Web browser:
http://<WebGateway_hostname>/cgi-bin/query_contents?dirlist=/
The result of this URL (shown in Figure 3-29) should be a 100 return code, followed by a listing of the files and directories in C:\Program Files\IBM HTTP Server\htdocs.
Figure 3-29 Query_contents result
Tivoli Web Gateway running on AIX

1. Copy the file query_contents.sh file from the C:\Program Files\Tivoli\PDWeb\www\lib\query_contents directory on the Tivoli Access Manager machine into the /usr/HTTPServer/cgi-bin on the Tivoli Web Gateway machine.
90
2. On the Tivoli Web Gateway machine, remove the .sh extension from the file name. 3. Manually edit the query_contents script file to correctly specify the docroot directory: /usr/HTTPServer/htdocs 4. Enable the execute bit for the administration account of the Web server on the query_contents script. 5. Restart the IBM HTTP Server, and test query_contents by entering the following URL into a Web browser:
http://<WebGateway_hostname>/cgi-bin/query_contents?dirlist=/
Results should be similar to Figure 3-29 on page 90.
3.3.3 Installing Tivoli Web Gateway with security enabled

This section describes the installation step used to enable security during the installation of the Tivoli Web Gateway. Install the Web Gateway component as described in Chapter 2, Getting the environment up and running on page 13, up to the point when the Specify the Access Manager Configuration Information window appears. On the Specify the Access Manager Configuration Information window, complete the entry fields as follows, then click Next. Enable Security: True Host Name: Specify the host name of the Access Manager Server Junction point: /WebSEAL/<hostname>/twgapp, where <hostname> is the host name of the Access Manager server Access Manager user name: sec_master Password: Password of sec_master WebSEAL protocol: HTTPS WebSEAL port: WebSEAL Server HTTPS port, default to 443 Access Manager configuration file: The PdPerm.properties file created when configuring the Access Manager Java Runtime Environment:
C:/WebSphere/AppServer/java/jre/PolicyDirector/PdPerm.properties
Access Manager JAR files home: Directory of the Access Manager Java Runtime Environment:
C:/Program Files/Tivoli/Policy Director/java/export/pdjrte
91
Note: Be very careful with spaces. Under an Access Manager configuration file, PolicyDirector has no spaces. Under Access Manager JAR files home, Policy Director does have a space.
Figure 3-30 Access Manager Configuration Information
The remaining steps of the installation process is the same as described in Chapter 2, Getting the environment up and running on page 13.
3.3.4 Configuring Web Gateway to use WebSEAL junction

At this point, we have the environment up and running. That includes the Tivoli Web Gateway Server and Access Manager Server running in separate machines, with a WebSEAL junction from the Access Manager Server to the Tivoli Web Gateway Server. This section provides information on additional configuration steps to be performed on the Tivoli Web Gateway Server in order to enable pervasive devices to connect to the Tivoli Web Gateway through the WebSEAL junction.
92
In order to test the WebSEAL junction to the Tivoli Web Gateway, perform the following steps: 1. Open a browser in any machine in the network and enter the following URL:
https://<WebSEAL_hostname>/twgapp
You should receive a response similar to Figure 3-31.
Figure 3-31 Unknown certificate alert
2. Click Yes to accept the certificate. The Access Manager Login window will open, as shown in Figure 3-32 on page 94.
93
Figure 3-32 Access Manager Login
3. Enter the username (sec_master) and the password to log in. After you logged in, the IBM HTTP Server Welcome window is displayed. In order to enable pervasive devices to connect to the Tivoli Web Gateway through the WebSEAL junction, we need to perform the following steps on the Tivoli Web Gateway Server: Configure the enrollment URL. Modify the web.xml configuration file of WebSphere for use with junctions.
Configure the enrollment URL

During the installation of the Tivoli Web Gateway component, the default enrollment URL is defined as follows:
http://<WebGW_hostname>/dmserver/DeviceEnrollmentServlet
where <WebGW_hostname> is the host name (or IP address) of the Tivoli Web Gateway Server. We need to change the enrollment URL from the default value to the WebSEAL junction URL. This can be achieved by performing the steps on the Tivoli Web Gateway Server as shown in the following sections.
94
Tivoli Web Gateway running on UNIX

Run the deviceclass.sh script as follows:
# cd <TWG_HOME>/bin # deviceclass.sh -modify Palm -enroll http://<WebSEAL_hostname>/twgapp/dmserver/DeviceEnrollmentServlet # deviceclass.sh -modify Wince -enroll http://<WebSEAL_hostname>/twgapp/dmserver/DeviceEnrollmentServlet # deviceclass.sh -modify Nokia9200Series -enroll http://<WebSEAL_hostname>/twgapp/dmserver/DeviceEnrollmentServlet
where <TWG_HOME> is the installation directory of the Tivoli Web Gateway
Tivoli Web Gateway running on Windows

Run the deviceclass.bat script as follows
cd /Program Files/TivTWG/bin deviceclass.bat -modify Palm -enroll http://<WebSEAL_hostname>/twgapp/dmserver/DeviceEnrollmentServlet deviceclass.bat -modify Wince -enroll http://<WebSEAL_hostname>/twgapp/dmserver/DeviceEnrollmentServlet deviceclass.bat -modify Nokia9200Series -enroll http://<WebSEAL_hostname>/twgapp/dmserver/DeviceEnrollmentServlet
Modify the web.xml file for use with junctions

Edit the web.xml file on the Tivoli Web Gateway Server and perform the following changes. The web.xml file is located in the <WAS_HOME>/installedApps/hostname_DMS_Webapp.ear/dmserver.war/WEB -INF directory, where <WAS_HOME> is the WebSphere installation directory Add the following stanza after the fullyQualifiedHostNameOfServer parameter definition:
<init-param> <param-name>authProxyDmsUrl</param-name> <param-value>NEWURL</param-value> </init-param>
where NEWURL is the Web address of the WebSEAL junction:

http://<WebSEAL_hostname>/twgapp
At this point you can connect the pervasive device to the Tivoli Web Gateway though the WebSEAL junction using HTTP, as shown in Figure 3-33 on page 96.
95
Figure 3-33 Logging on to the Web Gateway
96
Part 2
Part
Case study scenario
97
98
Chapter 4.
Managing pervasive devices

This chapter provides a case study scenario based on a fictitious company. It describes the techniques used to manage Palm, Windows PocketPC, and Nokia 9200 series devices. This scenario should give you a basic understanding of the capabilities of IBM Tivoli Configuration Manager when managing pervasive devices. The topics included in this chapter are: Case study overview Managing Nokia 9290 Communicator Managing Palm devices Managing WinCE/PocketPC devices Weekly distribution of the price and stock list
99
4.1 Case study overview

In this scenario, we model a fictitious pharmaceutical company. Our customer has a requirement to update its sales force with the latest price and stock list and on the three following type of PDAs: Nokia 9290 Communicator Palm V Toshiba Pocket PC e335 All of these PDA devices are given to the traveling sales force. The sales force receives the actual price and stock list in a PDF file. In this case, we also need to deploy the appropriate version of a PDF reader software. The companys objective is that each time users of the sales department connect their devices to their host PCs, which are connected to the company network, they should receive the latest version of the price and stock PDF file, if available. A new PDF file is created on the first business day of each week. The company would like to manage all devices from one central point, preferably the entire device management environment rolled out on one single server, as described in previous chapters. There is no requirement for securing the environment with IBM Tivoli Access Manager, since all operations will be done at the corporate office. The company has a total of 1500 devices in a mix of the three types mentioned above. We used the IBM Tivoli Configuration Manager and the Tivoli Web Gateway component to provide the PDA device management solution. We followed these steps: 1. Since the requirement is to manage all pervasive devices from a centralized location, we installed all the required components on a single box. The following software is installed: IBM DB2 Universal Database Enterprise Edition Version 7.2 IBM DB2 Universal Database Enterprise Edition Fixpack 7 (Version 7.2.5) IBM WebSphere Application Server Advanced Edition Version 4.0.1 IBM WebSphere Application Server Advanced Edition Fixpack 3 (Version 4.0.3) IBM Tivoli Framework Version 4.1 IBM Tivoli Configuration Manager Version 4.2 Tivoli Web Gateway For instructions on how to set up such an environment, refer to Chapter 2, Getting the environment up and running on page 13.
100
2. We created the Policy Region structure shown in Figure 4-1 in the Tivoli environment. The resource groups are subscribed to the relevant Profile Managers to enable us to distribute software packages or inventory profiles to the devices. For information on creating Policy Regions and Profile Managers, please refer to Tivoli Management Framework Users Guide Version 4.1, GC32-0805-003 manual.
Figure 4-1 Policy Region structure
The naming convention presented in Figure 4-1 represents: Pr = Policy region rg = Resource group Pf = Profile
Chapter 4. Managing pervasive devices
101
sp = Software package Pm = Profile Manager The [device_type] variable can be: palm nokia wince (used also for PocketPCs)
Note: According to the naming convention rules of IBM Tivoli Configuration Manager Software Distribution, the software package profile has to have a ^ character in its name (for example, software_name^version_number). 3. Depending on the PDA type, we will set up the IBM Device Agents either on the PDA and or on the PDAs host PCs, and connect them to the Resource Gateway.
Table 4-1 IBM Device Agents
Device Type Nokia 9290 Palm V IBM Device Agent name resides on the host PC EUPCInstaller.exe CondInst.exe IBM Device Agent name resides on the device N/A DMSAgentResources.PDB PvcPalm.prc Config.PDB ceagent.arm.CAB
Toshiba Pocket PC E335
N/A
4. Once the device is connected to the Resource Gateway, we will sort them into the relevant resource groups: Nokia devices - rg.pervasive_devices.nokia Palm devices - rg.pervasive_devices.palm Wince devices - rg.pervasive_devices.wince 5. The devices have no PDF reader software installed yet. We have decided to use Acrobat Reader for Palm and PocketPC PDAs, and PDF+ for Nokia devices. We will create the software packages, import them to the already created Profile Managers and initiate the Software Distribution.
Table 4-2 Platforms and PDF reader software
PDA platform Nokia 9290 Communicator Palm V Toshiba Pocket PC E335 PDF reader software to deploy PDF+ Adobe Acrobat Reader for Palm OS Adobe Acrobat Reader for Pocket PC
102
6. We will initiate an inventory scan on the devices, where applicable, and collect the device hardware and software information.
Table 4-3 Device Tivoli action matrix
Device Type Nokia 9290 Palm V Toshiba Pocket PC E335 Software Distribution Yes Yes Yes Inventory scan Not supported Yes Yes
4.2 Managing Nokia 9290 Communicator

The prerequisites for the Device Agent are the PC and Administrator Suites for the Nokia 9290 Communicator. You need to install the PC Suite before you can install the Administrator Suite. Both these suites are supplied by Nokia or can be downloaded from the Nokia Web site. We have already installed these suites.
http://www.nokia.com/phones/productsupport
The Device Agent does not reside on the device. It is referred to as a proxy agent because it acts on behalf of the device to communicate with the plug-in on the Web Gateway and the interface of the PC and Administrator Suites applications from Nokia. When the device connects to the host PC, the agent contacts the plug-in on the Web Gateway and any pending jobs are processed. The Device Agent uses the Nokia programming interface to perform the jobs on the device. You must install the Device Agent on a host PC that has the PC and Administrator Suites installed. The PC Suite needs to be run at least once to recognize your device before you can install the agent. The agent install program file EUPCInstaller.exe is located on the Tivoli Web Gateway Server in the default directory [TWGdir]\agents\Nokia, where [TWGdir] is the Tivoli Web Gateway installation directory.
4.2.1 Installation and configuration of the Device Agent for Nokia

To install the Device Agent and configure the device: 1. Copy EUPCInstaller.exe to the host PC. 2. Double-click the file to start the installation wizard of the Device Agent.
103
Figure 4-2 Nokia Device Agent welcome window
3. Click Next to continue.
Figure 4-3 Specify destination folder
104
4. Specify the destination folder of the installation and click Next. We use the default destination folder.
Figure 4-4 Device management server URL specification
5. The next step is to specify the device management server URL. The syntax is:
http://<TWG_hostname>/dmserver/NokiaDeviceServlet
where <TWG_hostname> is the Tivoli Web Gateway host name. 6. After clicking Next, the installation starts.
105
Figure 4-5 Progress bar of the installation
Figure 4-6 The finished installation
106
7. The Nokia Device Agent automatically enrolls itself to the Tivoli Web Gateway after the successful installation. Now we open a session. Note: In this part of the scenario, we will use the CLI commands to perform the actions. However, these actions can be performed using the Tivoli Desktop as well. For more information on the wresgw, wresource and wresgrp commands, please consult the IBM Tivoli Configuration Manager Users Guide for Deployment Services, SC23-4710. 8. We run a wresgw, discover command to verify it:
# wresgw discover FBBWD0001I Discover resources FBBWD0002I Resources discovered in itcmpda5 FBBWD0039I UNKNOWN EXISTS
9. We list the discovered pervasive devices:

# wresource ls Pervasive_Device Pervasive_Device: 103 UNKNOWN (Nokia9200Series) itcmpda5 Nokia9200Series:010108/50/236874/8
10.Since the label of the Nokia device is UNKNOWN, we rename the label to Communicator001:
# wresource edit Pervasive_Device UNKNOWN -u -l Communicator001
11.Check if it was renamed correctly:

# wresource ls Pervasive_Device Pervasive_Device: 103 Communicator001 (Nokia9200Series) itcmpda5 Nokia9200Series:010108/50/236874/8
12.We now have to assign the device to a resource group. We assign it to the rg.pervasive_devices.nokia resource group:
# wresgrp subscribe rg.pervasive_devices.nokia Communicator001
13.We list the assigned devices in the rg.pervasive_devices.nokia resource group:

# wresgrp ls rg.pervasive_devices.nokia rg.pervasive_devices.nokia (Static, Pervasive_Device): 103 (Communicator001) total 1
107
4.2.2 Distributing software packages to Nokia 9290 Communicator

In this section we describe the creation and distribution of software packages required by the customer. A software package for the PDF reader software will be created according to the device type. The process for the weekly price/stock list update is described in 4.5, Weekly distribution of the price and stock list on page 153. The software of choice for this particular scenario is the PDF+ viewer for Nokia devices from mBrain Software. It can be downloaded from the following Web site: http://www.mbrainsoftware.com/Nokia/Pdf/Pdf.htm First we will create a Software Package Block from the downloaded PDF+ application. 1. Open the software package editor and create a new package named PDF+ and select the device file object.
Figure 4-7 Device file object selection
108
2. We insert a device file to the already created device object.
Figure 4-8 Inserting device file
3. We set the caption to PDF+ and the Device Type to Nokia9200Series.
Figure 4-9 Device Object Properties window
4. The next step is to add the device file properties. We set the following options: Source
109
Location: c:\work\redpaper - location of the file on the package builder Name: PDF+.SIS - Name of the installation file Destination Location: c:\documents\ - the directory location on the target PDA Name: PDF+.SIS - file name on the target PDA
Note: On the Nokia 9290 Communicator, the directory creation is not supported by the Software Distribution process. You always have to use an existing directory on the target PDA as location on destination.
Figure 4-10 Device file properties
5. Finally, we save the software package as pfd_plus.spb.
110
Figure 4-11 Saving the software package as an .spb file
6. Now we switch to the Tivoli Desktop. Create the Profile Manager named pm.pervasive_devices.swd.nokia.pdf_plus^1.0. Ensure that you dont use the dataless Endpoint Mode upon creation.
Figure 4-12 Profile Manager for Nokia devices
7. Create the Software Package object sp.pervasive_devices.swd.nokia.pdf_plus^1.0 and import the pfd_plus.spb file.
111
Note: In this scenario, since we are focusing on the new features regarding resource management, we will not show the basic steps of Tivoli, such as creating a Profile Manager or importing a Software Package Block. For more information on the basic steps of creating a Profile Manager or importing a software package object, please consult IBM Tivoli Configuration Manager Users Guide for Software Distribution, SC23-4711.
Figure 4-13 sp.pervasive_devices.swd.nokia.pdf_plus^1.0
8. The next step is to subscribe the rg.pervasive_devices.nokia resource group to the pm.pervasive_devices.swd.nokia.pdf_plus^1.0 Profile Manager.
112
Figure 4-14 Subscribing the rg.pervasive_devices.nokia resource group
The Profile Manager will look like Figure 4-15 on page 114.
113
Figure 4-15 The Subscribed rg.pervasive_devices.nokia resource group
Now we are ready to distribute the PDA+ software to the Nokia device. 1. Open the installation window, assign the rg.pervasive_devices.nokia resource group to the Install Software Package On: field, and click Install & Close.
114
Figure 4-16 Install Software Package window
2. You can check the MDist2 GUI to follow up the distribution status. However, when you see that the package distribution was successful, this only indicates that the software package was published to the Tivoli Web Gateway successfully. You can check the location of the published package if you open the Software Distribution log file of the current distribution. Example 4-1
115
shows our log file: /tivoli/bin/swdis/work/sp.pervasive_devices.swd.nokia.pdf_plus^1.0.log.

Example 4-1 sp.pervasive_devices.swd.nokia.pdf_plus^1.0.log
Software Package: "sp.pervasive_devices.swd.nokia.pdf_plus^1.0" Operation: install Mode: not-transactional,not-undoable Time: 2003-03-11 17:48:04 ================= Pervasive Device list: Communicator001 DISSE0074I Operation successfully submitted. Distribution ID is 1148766224.17. ================= Software Package: "sp.pervasive_devices.swd.nokia.pdf_plus^1.0" Operation: install Mode: not-transactional,not-undoable Time: 2003-03-11 17:59:34 ================= Communicator001: DISSE0155I Distribution ID: `1148766224.17' DISSE0029I Current software package status is 'IC---'. DISSE0001I Operation successful. DISSE0538I The TWG metapackage has been published under URL http://itcmpda5:80/twg/device/30311234806729614/__Tivoli.contents__. =================
In this log file you can also see the list of the devices where you have executed the distributions. 3. Using the wwebgw -l @<TWG_hostname> command, we verify the ongoing distributions on the Web Gateway:
# wwebgw -l @itcmpda5 Web Gateway endpoint: @itcmpda5 Distribution ID Application ID ---------------------------1148766224.17 1148766224#SoftwareDistribution
4. Once the sales representative connects a Nokia device to the host PC and starts the Nokia 9290 Communicator software, the PDF+ SIS package starts to install on the host PC. Since the Nokia SIS package has no unattended
116
installation option, the sales rep has to follow the installation steps manually in order to install the PDF+ on the Nokia 9290 device successfully.
Figure 4-17 Installation of the PDF+ SIS package
5. Verify the installation on the Nokia device. You should see the PdfPlus software installed under the extras session.
Figure 4-18 Installed PdfPlus software on the Nokia Device window
Note: On Nokia 9290 devices, the inventory scan is not supported, so you will not be able to send inventory scans to these devices. See the installed software packages using the DEV_CMSTATUS_QUERY inventory query.
117
4.3 Managing Palm devices

The Tivoli Web Gateway supports all devices that use Palm OS 3.1 or higher operating systems. The Device Agent resides on the device and requires HotSync Manager to be at least the same version of the Palm OS version on the device. Connection software called a conduit must be installed on the host PC to synchronize application-specific files. The device can use a cradle, direct network connection, or both to connect to the host PC. A configuration file, Config.PDB, for each of these types of connections can be prepared with a utility called pdbgene.jar from your config.ini of your network settings. It is supplied with the Tivoli Web Gateway and is located in C:\Program Files\TivTwg\agent\tools. Chapters 11 and 14 of the IBM Tivoli Configuration Manager Users Guide for Deployment Services, SC23-4710 have details on the pdbgene.jar utility and the parameters in the config.ini file.
4.3.1 Installation and configuration of the Device Agent for Palm

You can install the Device Agent by means of the cradle using the following steps: 1. Customize the settings in the config.ini file. We are using the following settings in this scenario: ServiceName: DevAgent - This is the default setting; dont change it DMSAddress: The host name of the Tivoli Web Gateway Server DMSPort: The port of the Web server on the Tivoli Web Gateway Server PalmServletName: /dmserver/PalmServlet - This is the default setting; dont change it PalmUserID: The user name of the Palm user SSLOn: We disabled SSL since we dont use it in this scenario AttachmentOption: A value of 0 specifies the device decides which connection option to use automatically Example 4-2 shows the config.ini file in our case study scenario.
Example 4-2 The config.ini file
ServiceName=DevAgent DMSAddress=itcmpda5 DMSPort=80 PalmServletName=/dmserver/PalmServlet PalmUserID=palm001 SSLOn=0
118
AttachmentOption=0
2. You will need to generate a configuration file from the config.ini file. Run the following command to generate the Config.PDB file:
java -cp pdbgene.jar com.tivoli.dms.tool.pdbgene.PDBGenerator Config.INI Config.PBD
3. Copy the Device Agent conduit installation file condinst.exe from the Tivoli Web Gateway located in C:\Program Files\TivTwg\agents\palm to the host PC. 4. The Palm Desktop or HotSync Manager must be installed prior to installing the conduit software. Double-click condinst.exe to start the installation and follow the prompts to complete the installation.
Figure 4-19 Palm OS agent installation welcome window
5. For the Palm OS agent program, click Next to start the installation.
119
Figure 4-20 Palm OS agent installation progress bar
6. The installation starts automatically.
Figure 4-21 The finished Palm OS agent installation
120
7. Copy the following files to the host PC and use the install tool of the Palm Desktop (Figure 4-22) along with the HotSync Manager to copy the files to the Palm device: PvcPalm.prc: Device agent file located on the Tivoli Web Gateway DMSAgentResources.PDB: Palm OS resource file locate on the Tivoli Web Gateway Config.PDB: Configuration parameter database file that you created
Figure 4-22 Palm Desktop Install tool
8. On completion of the file transfer via HotSync, a new icon called IBM agent should now appear on the Palm device. Note: As an alternative, the configuration of the Palm can also be done without the config.ini file. If you run the IBM Device Agent, it will ask you to configure giving the parameters. The parameters are found in the IBM Tivoli Configuration Manager Users Guide for Deployment Services, SC23-4710.
9. When you start the IBM agent on the Palm device for the first time, it asks for connection settings. Since we use the default connection setting, we can discard this step. The next window on the Palm is the user name and password field. Even though we do not use authentication in this scenario, we
121
still have to specify the user name (without the password). We have specified palm001 as user name. 10.Now we press the Connect button on the Palm device and select HotSync as a connection type. 11.The IBM Agent connects to the Tivoli Web Gateway. 12.We run a wresgw, discover command to verify it:
# wresgw discover FBBWD0001I Discover resources FBBWD0002I Resources discovered in itcmpda5 FBBWD0039I palm001 EXISTS
13.We list the discovered pervasive devices:

# wresource ls Pervasive_Device Pervasive_Device: 103 Communicator001 (Nokia9200Series) itcmpda5 Nokia9200Series:010108/50/236874/8 105 palm001 (Palm) itcmpda5 Palm:10EV1A796M8Y
14.When the Palm device is correctly discovered, we assign it to the rg.pervasive_devices.palm resource group.
# wresgrp subscribe rg.pervasive_devices.palm palm001
15.We list the assigned devices in the rg.pervasive_devices.palm resource group.

# wresgrp ls rg.pervasive_devices.palm rg.pervasive_devices.palm (Static, Pervasive_Device): 105 (palm001) total 1
4.3.2 Distributing software packages to Palm

In this section, we describe the creation and distribution of software packages required by the customer. A software package for the PDF reader software will be created according to the device type. The process for the weekly price/stock list update will be described in 4.5, Weekly distribution of the price and stock list on page 153. The software of choice for this particular scenario is the Acrobat Reader for Palm devices from Adobe. It can be downloaded from the following Web site:
http://www.adobe.com/products/acrobat/acrrpalmdload.html
122
In this section, we distribute the Adobe Acrobat viewer software to the Palm device. First we create a Software Package Block from the downloaded Adobe Acrobat application. 1. We open the software package editor and create a new package named Adobe_Acrobat_palm and select the device file object.
2. We create the device object: Caption: Acrobat_Reader_Palm Subtype: Palm
Figure 4-24 Add Device Object Properties window
3. Now we insert a device file.
123
4. The next step is to add the device file properties. We set the following options: Location: c:\work\redpaper - location of the file on the package builder Name: AcroRead.prc - Name of the installation file
Figure 4-26 Device file properties
124
5. Finally, we save the software package as Acrobat_palm.spb.
Figure 4-27 Saving the software package as an .spb file
6. Now we switch to the Tivoli Desktop. Create the Profile Manager named pm.pervasive_devices.swd.palm.acrobatreader^2.0. Ensure that you dont use the dataless Endpoint Mode upon creation.
Figure 4-28 Profile manager for Palm devices
7. Create the Software Package object. sp.pervasive_devices.swd.palm.acrobatreader^2.0 and import the Acrobat_palm.spb file.
125
Figure 4-29 sp.pervasive_devices.swd.palm.acrobatreader^2.0
8. The following step is to subscribe the rg.pervasive_devices.palm resource group to the pm.pervasive_devices.swd.palm.acrobatreader^2.0 Profile Manager.
126
Figure 4-30 Subscribing the rg.pervasive_devices.palm resource group
The Profile Manager will look like Figure 4-15 on page 114
127
Figure 4-31 The subscribed rg.pervasive_devices.palm resource group
Now we are ready to distribute the Adobe Acrobat Reader software to the Palm Device. 1. Open the installation window and assign the rg.pervasive_devices.palm resource group to the Install Software Package On: field and click Install & Close.
128
2. You can check the MDist2 GUI to follow up the distribution status. However, when you see that the package distribution was successful, this only indicates that the software package was published to the Web Gateway successfully. You can check the location of the published package if you open the Software Distribution log file of the current distribution. Example 4-3 on page 130
129
shows our log file /tivoli/bin/swdis/work/sp.pervasive_devices.swd.palm.acrobatreader^2.0.log.

Example 4-3 sp.pervasive_devices.swd.nokia.pdf_plus^1.0.log
================= Software Package: "sp.pervasive_devices.swd.palm.acrobatreader^2.0" Operation: install Mode: not-transactional,not-undoable Time: 2003-03-14 11:12:13 ================= Pervasive Device list: palm001 DISSE0074I Operation successfully submitted. Distribution ID is 1148766224.22. ================= ================= Software Package: "sp.pervasive_devices.swd.palm.acrobatreader^2.0" Operation: install Mode: not-transactional,not-undoable Time: 2003-03-14 11:14:48 ================= palm001: DISSE0155I Distribution ID: `1148766224.22' DISSE0029I Current software package status is 'IC---'. DISSE0001I Operation successful. DISSE0538I The TWG metapackage has been published under URL http://itcmpda5:80/twg/device/30314171215919986/twg-metapackage-1148766224.22-1 .txt. =================
In this log file you can also see the list of the devices where you have executed the distributions. 3. Using the wwebgw -l @<TWG_hostname> command, we verify the ongoing distributions on the Tivoli Web Gateway, as shown in Example 4-4.
Example 4-4 Ongoing distributions
# wwebgw -l @itcmpda5 Web Gateway endpoint: @itcmpda5
130
Distribution ID Application ID ---------------------------1148766224.22 1148766224#SoftwareDistribution
4. Once the sales representative connects a Palm device to the host PC and start a HotSync operation, the Adobe Acrobat package starts to install on your Palm device. There is no need to have manual interaction while installing the Acrobat Reader software. 5. After the successful installation, you should see the Adobe Acrobat Reader icon on your Palm desktop.
4.3.3 Performing inventory scan on Palm

In this section, we explain how to perform an inventory scan on the Palm device. The following steps need to be followed: 1. We have already created the InventoryConfig profile for the Palm devices as shown in the Policy Region structure diagram in Figure 4-1 on page 101. The profile name is pf.pervasive_devices.inv.palm and it is created under the Profile Manager pm.pervasive_devices.inv.palm. We also subscribed the rg.pervasive_devices.palm resource group to the Profile Manager.
131
Figure 4-33 Inventory Profile Manager for Palm
2. To customize the InventoryConfig profile, we disabled all scanning options other than related pervasive devices, such as the PC hardware and software scans and UNIX and OS/400 hardware and software scans. We selected only the following options in the Pervasive Devices window: Hardware Scan - ON Software Scan - ON Device Configuration Scan - ON
132
Figure 4-34 Pervasive Devices scan window
3. Once the InventoryConfig profile is customized, we perform the inventory scan on rg.pervasive_devices.palm resource group.
133
Figure 4-35 Inventory scan on the rg.pervasive_devices.palm resource group
4. You can follow the inventory scan by checking the lcfd.log on the Tivoli Web Gateways lcf directory and on the MDist2 console. However, a successful status only means that the Tivoli Web Gateway has received the request.
Example 4-5 lcfd.log on the Tivoli Web Gateway
Mar 14 11:34:24 1 lcfd Spawning: /opt/Tivoli/lcf/dat/4/cache/bin/aix4-r1/TME/INVENTORY/inv_config_ep_pvd_meths, ses: 0bedf0b3
5. By issuing the wwebgw -l @<TWG_hostname> command, we can see if the Tivoli Web Gateway has scheduled the inventory scan for the Palm device.
Example 4-6 The scheduled inventory scan
# wwebgw -l @itcmpda5
134
Web Gateway endpoint: @itcmpda5 Distribution ID Application ID ---------------------------1148766224.23 1148766224#Inventory
6. Once the Palm device is performing a HotSync operation, the inventory scan starts to run and you see the following message on the device:
inventory information is being scanned. Please be patient, as this may require up to a few minutes
7. Once the inventory scan has been performed, the Palm device automatically starts a new HotSync operation and sends the scanned information back to the Framework level. 8. When the inventory scan is done, you get a pop-up message on the Palm device saying:
Inventory job has completed
9. Alternatively, you can verify the $DBDIR/mcollect/mcollect.log for the success of the inventory scan:
Example 4-7 mcollect.log successful inventory scan
Mar 14 11:47:14 1 [pid:00017102 tid:536928744] debug_level:1 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] depot_location:depot Mar 14 11:47:14 1 [pid:00017102 tid:536928744] depot_size:41943040 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] depot_chunk:1048576 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] thread_idle_down_time:60 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] thread_sleep_time:5 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] max_input_threads:5 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] max_input_retries:10 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] max_output_threads:5 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] retry_delay_time:1 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] router_cache_lines:0 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] temp_dir:/tivoli/db/itcmpda5.db/mcollect Mar 14 11:47:14 1 [pid:00017102 tid:536928744] depot_load - begin loading index cache. Mar 14 11:47:14 1 [pid:00017102 tid:536928744] depot_load - end loading depot index cache.
10.We execute the PERVASIVE_QUERY from the Tivoli desktop to verify if the device is added to the database correctly. The PERVASIVE_QUERY is located in the PERVASIVE_QUERY library.
135
Figure 4-36 The result of the PERVASIVE_QUERY
Note: Since we used the integrated installation of IBM Tivoli Configuration Manager 4.2, the inventory query libraries are created automatically during the installation. To locate them on the Tivoli Desktop, go to the default created Policy Region (in our case it is itcmpda-region). 11.We execute the DEV_CMSTATUS_QUERY to verify the installation of the Adobe Acrobat Reader. However, this part of the inventory database is automatically updated whenever a Software Distribution is performed on the device. So you do not need to run an inventory scan to receive this data.
136
Figure 4-37 Result for query: DEV_CMSTATUS_QUERY
4.4 Managing WinCE/PocketPC devices

The Tivoli Web Gateway supports all devices that use WinCE and Windows PocketPC. The Device Agent resides on the device and requires some sort of synchronization software between the host PC and the device in order to synchronize application-specific files. In our scenario, we will use Microsoft Active Sync V3.5 that ships with the Toshiba Pocket PC e335. The Device Agent (IBM Agent) is a Tivoli software component that polls and processes jobs in the polling queue that have been submitted by the plug-in. A Windows CE Service must be installed on the host PC to establish communication between the host PC and the device. For each CPU type, there is a different Device Agent installation package. These are located on the Tivoli Web Gateway in the following directories: For WinCE Version 2.11:
<TWGDIR>\agents\wince\WinCE2.1
For WinCE Version 3.0 and Pocket PC or Pocket PC 2002 devices:

<TWGDIR>\agents\wince\WinCE3.0
Where <TWGDIR> is the Tivoli Web Gateway installation directory.
137
Table 4-4 Agent install package per processor type

CPU Type SH-3 SH-4 MIPS StrongARM Agent install package ceagent.sh3.cab ceagent.sh4.cab ceagent.mip.cab ceagent.arm.cab
Since our device uses the StrongARM processor, we will use the ceagent.arm.cab installation package.
4.4.1 Installation and configuration of the Device Agent for PocketPC

You can install the Device Agent by means of the cradle using the following steps: 1. Open the device synchronization software, in our case Microsoft Active Sync, and click Explore.
Figure 4-38 Device connected
138
2. The directory structure of the handheld device will be displayed.
Figure 4-39 Mobile Device directory structure
3. Copy the appropriate Device Agent installation package from the Tivoli Web Gateway to the host PC and then to the device. Active Sync converts the file to the mobile device format, and copies it to the PDA.
Figure 4-40 Copying Device Agent install file
4. Locate the file on your handheld, and tap on the CAB file to start the installation.
139
Figure 4-41 IBM Device Agent is copied to the PDA
5. When the installation is complete, click Start -> Programs -> IBM agent to configure the agent. The following should be specified: User ID: This will serve as a secondary device ID. Server URL: This is the Tivoli Web Gateway URL. http://<TWG_hostname>/dmserver/WinceServlet Check Poll automatically.
Figure 4-42 IBM Device Agent configuration
140
Depending on the device and the network setup, you must set the appropriate settings in the Connection tab. Click the Save button when you are ready. 6. The Device Agent will now connect to the server.
Figure 4-43 IBM Device Agent main window
7. The IBM Agent connects to the Tivoli Web Gateway. 8. We run a wresgw, discover command to verify it:
# wresgw discover FBBWD0001I Discover resources FBBWD0002I Resources discovered in itcmpda5 FBBWD0039I IBMWINCE EXISTS
9. We list the discovered pervasive devices:

# wresource ls Pervasive_Device Pervasive_Device: 103 Communicator001 (Nokia9200Series) itcmpda5 Nokia9200Series:010108/50/236874/8 105 palm001 (Palm) itcmpda5 Palm:10EV1A796M8Y 107 IBMWINCE (WinCE) itcmpda5 WinCE:30226204125775976_10462920
10.When the PocketPC device is correctly discovered, we assign it to the rg.pervasive_devices.wince resource group.
# wresgrp subscribe rg.pervasive_devices.wince IBMWINCE
141
11.We list the assigned devices in the rg.pervasive_devices.wince resource Group.

# wresgrp ls rg.pervasive_devices.wince rg.pervasive_devices.wince (Static, Pervasive_Device): 107 (IBMWINCE) total 1
4.4.2 Distributing software on WinCE/PocketPC

In this section, we describe the creation and distribution of software packages required by the customer. A software package for the PDF reader software will be created according to the device type. The process for the weekly price/stock list update will be described in 4.5, Weekly distribution of the price and stock list on page 153. The software of choice for this particular scenario is the Acrobat Reader for PocketPC devices from Adobe. It can be downloaded from the following Web site:
http://www.adobe.com/products/acrobat/acrrppcdload.html
1. We open the software package editor and create a new package for the Adobe Acrobat named IBM-WINCE and select the device file object.
142
2. We create the device object: Caption: IBM-WINCE Subtype: WinCE
Figure 4-45 Add Device Object Properties window
3. Now we insert a device file.
4. The next step is to add the device file properties. Use the install package of Adobe Acrobat for PocketPC. 5. Finally, we save the software package as Acrobat.spb.
143
Figure 4-47 Saving the software package as an SPB
6. Now we switch to the Tivoli Desktop. Create the Profile Manager named pm.pervasive_devices.swd.wince.acrobat^1. Ensure that you dont use the dataless Endpoint Mode upon creation.
Figure 4-48 Profile manager for WinCE devices
7. Create the Software Package object sp.pervasive_devices.swd.wince.acrobat^1 and import the Acrobat.spb file.
144
Figure 4-49 sp.pervasive_devices.swd.wince.acrobatr^1
8. The next step is to subscribe the rg.pervasive_devices.wince resource group to the pm.pervasive_devices.swd.wince.acrobat^1 Profile Manager.
Figure 4-50 Subscribing the rg.pervasive_devices.wince resource group
145
Now we are ready to distribute the Adobe Acrobat Reader software to the PocketPC Device. 1. Open the installation window and assign the rg.pervasive_devices.wince resource group to the Install Software Package On: field and click Install & Close.
146
You can check the MDist2 GUI to follow up the distribution status. However, when you see that the package distribution was successful, this only indicates that the software package was published to the Web Gateway successfully. You can check the location of the published package if you open the Software Distribution log file of the current distribution. In order to check the status of the distribution using the MDist2 GUI, click the Distribution Status icon on the Tivoli Desktop. This will open the MDist2 program in a separate window. If you click All Distributions in the navigation bar, you will see the status of the distribution you submitted.
Figure 4-52 Checking Distribution Status in MDist2
You also can follow the distribution on the PDA display. If you connect to the server, it will find a job that has been submitted, and starts the installation automatically. Figure 4-53 on page 148 shows a sequence of windows of the installation procedure.
147
Figure 4-53 IBM Device Agent - performing software distribution
After the installation procedure is finished, start Acrobat Reader to check if it is working.
Figure 4-54 Software up and running
148
4.4.3 Running inventory on the WinCE/PocketPC

In this section, we explain how to perform an inventory scan on the WinCE/PocketPC device. The following steps need to be followed: 1. We have already created the InventoryConfig profile for the WinCE/PocketPC devices as shown in the Policy Region structure diagram in Figure 4-1 on page 101. The profile name is pf.pervasive_devices.inv.wince and it is created under the Profile Manager pm.pervasive_devices.inv.wince. We also subscribed the rg.pervasive_devices.wince resource group to the Profile Manager.
Figure 4-55 Inventory Profile Manager for Palm
2. To customize the InventoryConfig profile, we disabled all scanning options other than related pervasive devices, such as PC hardware and software scans and UNIX and OS/400 hardware and software scans. We selected only the following options in the Pervasive devices window: Hardware Scan - ON Software Scan - ON Device Configuration Scan - ON
149
Figure 4-56 Inventory profile administration - Pervasive Devices
3. Once the InventoryConfig profile is customized, we perform the inventory scan on rg.pervasive_devices.wince resource group.
150
Figure 4-57 Inventory scan on the rg.pervasive_devices.wince resource group
4. You can follow the inventory scan by checking the lcfd.log on the Tivoli Web Gateways lcf directory and on the MDist2 console. However, a successful status only means that the Tivoli Web Gateway has received the request. 5. By issuing the wwebgw -l @<TWG_hostname> command, we can see if the Tivoli Web Gateway has scheduled the inventory scan for the PocketPC device.
Example 4-8 The scheduled inventory scan
# wwebgw -l @itcmpda5 Web Gateway endpoint: @itcmpda5 Distribution ID --------------1148766224.87 Application ID -------------1148766224#Inventory
151
6. Once the PocketPC device is performing a synchronization operation, the job gets scheduled, and the inventory scan starts to run. Figure 4-58 shows this sequence.
Figure 4-58 Inventory scan -being scheduled and performed
7. Alternatively, you can verify the $DBDIR/mcollect/mcollect.log for the success of the inventory scan:
Example 4-9 mcollect.log successful inventory scan
Mar 14 11:47:14 1 [pid:00017102 tid:536928744] debug_level:1 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] depot_location:depot Mar 14 11:47:14 1 [pid:00017102 tid:536928744] depot_size:41943040 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] depot_chunk:1048576 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] thread_idle_down_time:60 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] thread_sleep_time:5 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] max_input_threads:5 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] max_input_retries:10 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] max_output_threads:5 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] retry_delay_time:1 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] router_cache_lines:0 Mar 14 11:47:14 1 [pid:00017102 tid:536928744] temp_dir:/tivoli/db/itcmpda5.db/mcollect Mar 14 11:47:14 1 [pid:00017102 tid:536928744] depot_load - begin loading index cache. Mar 14 11:47:14 1 [pid:00017102 tid:536928744] depot_load - end loading depot index cache.
8. We execute the WINCE_FILE_QUERY from the Tivoli Desktop to verify the installation of the Adobe Acrobat Reader on the PocketPC device and if the
152
Adobe Acrobat software has been added to the Tivoli Inventory database correctly. The WINCE_FILE_QUERY is located under the PERVASIVE_QUERY library. Note: Since we used the integrated installation of IBM Tivoli Configuration Manager 4.2, the inventory query libraries are created automatically during the installation. To locate them on the Tivoli Desktop, go to the default created Policy Region (in our case it is itcmpda-region).
Figure 4-59 Results of the WINCE_FILE_QUERY
4.5 Weekly distribution of the price and stock list

This section describes the methodology of the weekly upgrade of the price and stock list PDF file. In order to update all the pervasive devices with a new price and stock list every week, it is necessary to create and distribute a software package containing the proper price and stock list every week. After that it is also necessary to verify the success of the process. Since we have already shown how to create, distribute, and verify the distribution of a software package for each of the devices, we will talk only about the high-level design here. On the Friday before the first business day of the week, we receive one PDF file containing the price and stock information. The naming convention for this PDF file is pricelist[yyyymmdd].pdf. As requested, we do not overwrite the old price list files, because the sales department sometimes has to refer to information from the previous weeks. We also would like to keep the history of the distributions and the weekly distributed packages on track by not deleting the old packages for a six-month period of time.
153
Therefore, the following tasks need to be performed by the Tivoli operations team: Create the software packages containing the pricelist[yyyymmdd].pdf file. You need to create one software package for each device platform, since the file device object settings are different. Alternatively, this step can be sped up by using a software package definition file as a template. Copy the ready-made .spb file to the source host or, where applicable, import it directly from the preparation site. Create the new Profile Managers for the new software packages, one Profile Manager per device platform. Following the naming convention in this case study, the name of the Profile Managers will be:
pm.pervasive_devices.swd.[plaform_type].pricelist^yyyymmdd
Create the software package objects and import the software packages. Following the naming convention in this case study, the name of the software package objects will be:
sp.pervasive_devices.swd.[plaform_type].pricelist^yyyymmdd
Subscribe the relevant resource group to the already created Profile Managers. Test the distribution. Check and assign the newly registered devices to the existing resource groups. Initiate the distributions. Follow up the result by checking the Software Distribution log files, issuing the wwebgw -l @<TWG_hostname> command. Alternatively most of these steps can be automated by using scripts instead of performing these operations manually.
154
Appendix A.
Troubleshooting Web Gateway and Device Management

IBM Tivoli Configuration Manager 4.2 aims to make distributed systems and application management relatively easy. It achieves this through a consistent interface and the use of models, such as management by subscription. While the systems administrator can perform many tasks with relative ease, the code Tivoli provides to achieve those tasks is extraordinarily complex. With the solid foundation of the Tivoli Management Framework, this complexity can remain largely masked from the administrator. However, with such a sophisticated set of products, there will be occasions when those designing, testing, and implementing Tivoli solutions will encounter situations that are not resolved by reference to product manuals alone. In problem-solving situations, you need to understand what is going on between the product components, what messages and trace output means, and what extra actions you can take to try to resolve a problem. This Appendix provides troubleshooting tips for both the Tivoli Web Gateway and Device Management components.
155
Troubleshooting Web Gateway Installation

In this section we cover troubleshooting the Web Gateway installation. Review the error message shown in the failed installation and review the log file cmsummary.log. The example error message (Figure 4-60) indicates that the installation program is failing to install the Web Gateway database.
Figure 4-60 Failed TWG installation message
You can check the following in this case: Ensure that the dmsadmin and dmsuser user IDs were successfully created on the Web Gateway database server. Verify that the passwords provided to the Web Gateway database installation are correct. Verify the passwords by connecting to DB2 with the user name and password specified. From a DB2 environment, issue:
db2 connect to dms using dmsadmin using password
Note: This command works only if the Web Gateway database was created during the database installation.
156
Ensure that the directories specified during the Web Gateway database installation have sufficient disk space. These directories are database home and database container home. Ensure that the DB2 instance specified during the Web Gateway database installation is correct. To list the valid DB2 instances, run db2ilist from a DB2 command environment. Ensure the DB2 port is correct. Open the services file and locate the following line (for readability, the line below appears on two lines):
db2cinstance port/tcp #Connection port for DB2 instance instance
For UNIX, the services file is located in the /etc/services file. For Windows, it is located in the drive:\WINNT\system32\drivers\etc\services file. You can review the log files for more information. The log files are located in the /tmp/dms_top/logs/pid/ directory on the Web Gateway database server. For Web Gateway installation problems, you can also check for the existence of the log files TWGinst_stdout.log and TWGinst_stderr.log on the Web Gateway Server. Review the log files to determine where the install is failing. If the files do not exist, run the TWG_inst_driver.bat file from the TivTwg\tmp_inst directory and pipe the output to a file. Review the output file to determine the point of failure.
Useful log files for installation troubleshooting

The installation process uses several log files for tracking the result of a successful or unsuccessful procedure. They are: AppServerStarted.log
Location: TWG_HOME\tmp\AppServerStarted.log
This file displays information from the script to test if WebSphere Administration Server was running before installing Web Gateway. Use this log file to debug installation errors. If WebSphere Application Server was not running, the installation stops before the product files are copied. A message is written to this log file specifying that WebSphere Application Server is not running or is not in an acceptable runtime state. If WebSphere Application Server is running and this message appears in the log file, you need to view the WebSphere Application Server trace file to identify which exceptions occurred. When successful, the log file contains the following:
Example 4-10 AppServerStarted.log
"*** Test of Application Server Start ***"
Appendix A. Troubleshooting Web Gateway and Device Management
157
"~~ import the test XML file ~~" "Successful test: Application Server is running!
DMSplugin.device_class.log
Location: TWG_HOME\tmp\DMSplugin.device_class.log
This file displays information about the device classes that are created and configured during installation. Use this log file to debug database connection errors or errors when the DMS_AppServer application server starts. The device_class values are: PalmOS Wince Nokia9200Series If a device class was not created properly, or if no default job types were created for a device class during installation, then this log file lists the problems. WebConfig.log
Location: TWG_HOME\tmp\WebConfig.log
This file contains information for dynamically updating the Web Gateway WAR file (dmserver.war) during installation. Use this file to debug problems with DMS_AppServer application server when the initialization parameters of the servlets have variable values instead of fixed values. For example, there is a variable value for the hostname.domain parameter. For a successful Web Gateway installation on Windows, the log file contains the following:
Example 4-11 WebConfig.log
"*** Configuration of web.xml for TWG ***" "~~ dmserver.war jar update ~~" "Successful update of dmserver.war!"
WASNodeList.log
Location: TWG_HOME\tmp\WASNodeList.log
This file displays information about running the TWG_HOME\install\etc\WASNodeList.bat script file during installation. This script file determines the node value for the local WebSphere Application Server, and uses that value when formatting the host name value for the client. This script file is needed because for Windows NT the WebSphere Application Server node name is often in lowercase, even though the Java InetAddress object returns the node value in all uppercase characters. In a successful installation on Windows, this log file contains the following:
158
Example 4-12 WASNodeList.log

"*** Obtain node name list from WAS ***" "--- Placing list in file: C:\Program Files\TivTwg\bin\WASlist.nodename" "*** End C:\Program Files\TivTwg\install\etc\WASnodename.bat ***"
WASConfig.log
Location: TWG_HOME\tmp\WASConfig.log
This file displays information from the TWG_HOME\install\etc\WASConfig.xxx script. This script does the following: Creates the client_host virtual host object within WebSphere Application Server. Creates the DMS_AppServer application servers within WebSphere Application Server to run the Web Gateway servlets. Creates the enterprise applications within WebSphere Application Server to install and configure the Web Gateway servlets. It imports the dmserver.war file into WebSphere Application Server. In a successful installation on Windows for Web Gateway, this log file contains the following:
Example 4-13 Sample WASConfig.log file
"*** Configuration of WAS for TWG ***" "***************************************************" "** XML imports and WebApp .bat executions follow **" "***************************************************" "***************************************************" "~~ createSMdefault_host.xml import ~~" [3/4/03 15:37:35:266 CST] 6752c301 VirtualHostCo A XMLC0053I: Importing VirtualHost : itcmpda1_host "~~ createDMS_AppServerTMP.xml import ~~" [3/4/03 15:37:43:047 CST] 6752c30d NodeConfig A XMLC0053I: Importing Node : itcmpda1 [3/4/03 15:37:43:297 CST] 6752c30d ApplicationSe A XMLC0053I: Importing ApplicationServer : DMS_AppServer [3/4/03 15:37:43:328 CST] 6752c30d ApplicationSe X XMLC0009E: Failure to delete ApplicationServer : DMS_AppServerXMLC0067I: DMS_AppServer Does not exist. [3/4/03 15:37:43:328 CST] 6752c30d ApplicationSe A XMLC0053I: Importing ApplicationServer : DMS_AppServer "~~ createDMS_WebAppTMP.bat invocation ~~" "*** Begin C:\Program Files\TivTwg\install\etc\createDMS_WebAppTMP.bat ***" "*** End C:\Program Files\TivTwg\install\etc\createDMS_WebAppTMP.bat ***"
159
"~~ starting DMS_AppServer ~~"
Cleaning up a failed Web Gateway installation

If you do need to reinstall the Web Gateway, there are several cleanup steps to be done. First, un-install the application from Windows by selecting Start -> Settings -> Control Panel -> Add/Remove Programs -> Web Gateway 4.2 and click the Remove button. Now stop and remove WebSphere Application Server modules and Enterprise Applications. Click Start -> Programs -> IBM WebSphere -> Application Server 4.0 AE -> Administrator's Console. In the window that appears, expand the Nodes and Enterprise Application branches to expose the WebUI_AppServer and WebConsole Enterprise Application. Tip: If you cannot remove one component, try to move them to another, unused application server, or delete the files from drive:\WebWphere\Appserver\installedApps. The endpoint catalog will still reflect the software packages that comprise the Web Gateway as being in an installed and committed (IC) state. The easiest way to clean this up is to rename the endpoint catalog (epsp.cat) file. On our example system, the location of the file to rename is:
C:\swdis\work\epsp.cat
Un-installing Java Runtime Environment

If you want to un-install Access Manager Java Runtime Environment from your Web Gateway server, first you have to un-configure it. To un-configure the Access Manager Java Runtime Environment, use the pdjrtecfg command. For example, enter the following to un-configure the JRE specified by the jre_path variable (default =C:\WebSphere\AppServer\java\jre):
pdjrtecfg -action unconfig -java_home jre_path
160
Common Web Gateway and Device Management problems

Here are some typical problems when using the Web Gateway and Device Management components.
Problems with starting the Web Gateway

The following are possible problems and solutions with starting the Web Gateway:
Problem:The following message appears in the DMS_stdout.log file when

Web Gateway is starting in WebSphere Application Server:
java.lang.ClassCastException
Solution: The wrong JDBC driver is being used. Web Gateway requires the JDBC 2.0 driver. You must configure DB2 to use the JDBC 2.0 driver and reinstall Web Gateway with the JDBC driver home installation parameter set to the JDBC 2.0 driver. Problem: The following message appears in the DMS_stdout.log file when
Web Gateway is starting in the WebSphere Application Server:
DYM2794E: Failed to create the database connection pool. COM.ibm.db2.jdbc.DB2Exception: [IBM][JDBC Driver] CLI0616E Error opening socket. SQLSTATE=08S01
Solution: Ensure that DB2 is started and that the DB2 client is configured
correctly.
Problem: When starting Web Gateway in the WebSphere Application Server,

the following message appears in the DMS_stdout.log file:
DYM2718E: An error occurred while trying to initialize the Policy Director environment.
Solution: This message occurs when the IBM Tivoli Access Manager Java Runtime Environment is not installed and configured correctly on the Web Gateway server. Verify that the IBM Tivoli Access Manager Java Runtime Environment is installed on the Web Gateway server. Problem: When starting Web Gateway on the WebSphere Application Server,
the following message appears in the DMS_stdout.log file:
DYM2719E: An error occurred while trying to create a Policy Director context.
Solution: The Web Gateway server is not configured correctly. Open the twgConfig.properties file to verify that the PD_ADMIN_USERID and PD_ADMIN_PW values are correct. To verify these values, log on to the
161
pdadmin command-line utility on the IBM Tivoli Access Manager Server. Then type the following:
pdadmin a sec_master p password
This message also occurs when the IBM Tivoli Access Manager Java Runtime Environment is not installed and configured correctly on the Web Gateway Server.
Problem: When starting Web Gateway on the WebSphere Application Server,

the following message appears in the DMS_stdout.log file.
com.tivoli.pd.jutil.PDExceptionjava.io.FileNotFoundException: pd_config_file (No such file or directory)
Solution: The Web Gateway server is not configured correctly. Open the twgConfig.properties file to verify that the PD_CONFIG_FILE value exists on the Web Gateway Server. Problem: Unable to log in to Web Gateway Server. Solution: Do the following:
Use the IP address instead of the host name for the Web Gateway Server to check if it is a DNS issue. For a Palm OS device, check the settings in the config.ini used to create the Config.PDB file. You can regenerate a corrected Config.PDB and install it on the Palm device or, alternatively, modify the settings on the device. If you are using a IBM Access Manager WebSEAL Server, make sure to include the WebSEAL_hostname and junction_name in the URL for the server. HTTP 400 error when connecting. Check name resolution. Make sure the host PC can contact the Web Gateway server. Conduit returns an error/HTTP error code 500. Make sure the service IBM WebSphere Admin Server 4.0 is started. Could not connect to the server. Check the proxy setting and port number. The port number should be 80. HTTP error 404. Check the servlet name. Palm OS device using network/modem connection when device is attached to host PC with a cradle. Use AttachmentOption=2 to specify that the Palm device should always use the cradle connection. A new Config.PDB file will need to be generated and copied to the Palm device.
162
Problems with using the Web Gateway

The following are problems you may encounter with using the Web Gateway, and their solutions.
Problem: The Web Gateway Server started without errors, then the following
message appeared in the DMS_stdout.log file:
SQL0973N Not enough storage is available in the "APP_CTL_HEAP" heap to process the statement.
Solution: To address this problem, refer to Part 4, the Managing Resources section, Troubleshooting, in the IBM Tivoli Configuration Manager Users Guide for Deployment Services, SC23-4710. Problem: The Web Gateway Server started without errors, then DB2 creates
messages saying the ISPB_DATA or ISPB_INDEX tablespaces are full.
Solution: To address this problem, refer to IBM Tivoli Configuration Manager

Planning and Installation Version 4.2, GC23-4702.
You also need to reorganize the database tables; refer to the IBM Tivoli Configuration Manager Release Notes (which comes with the product) for information.
Problem: On AIX, the Web Gateway Server started without errors. Then, the
following message appears in the DMS_stdout.log file:
Could not fork process
Solution: Increase the maximum number of file descriptors in AIX. Setting this value to 5000 should be sufficient.
Run ulimit -a to determine how many file descriptors are currently in use. Use the following command to set the value to 5000 in the terminal in which WebSphere Application Server is started.
ulimit -n 5000
Problem: The Web Gateway Server started without errors, then the following
message appears in the DMS_stdout.log file:
java.lang.OutOfMemory
Solution: This message indicates that the maximum heap size for the DMS_AppServer Application Server process has been reached.
The default heap size is 256 MB. Use the WebSphere Application Server Administrative Console to increase the maximum value of the heap to a number larger than the default, such as 512 MB.
163
Problems with registering device classes and job classes

Problem: When installing Web Gateway on AIX, the device classes and job
types are not registered.
Solution: This is a known problem. It occurs with versions of WebSphere Application Server earlier than Version 4.0.3. Web Gateway requires Version 4.0.3. Verify that the WebSphere Application Server is at the required level and reinstall Web Gateway.
Problems with enrolling a device

Problem: When trying to automatically enroll a device in Web Gateway, the
following message appears in the DMS_stdout.log file:
DYM2043E: A device entry was not inserted into the database because the server setting indicates AUTO_ENROLL is set to false.
Solution: You must register Web Gateway with the Tivoli Server and enable auto-enrollment for that Web Gateway. To fix the problem, do the following:
1. Set up the Tivoli command prompt environment on the Tivoli Server. 2. Run this command on the Tivoli Server:
wresgw add endpoint -C TWG
3. Run this command on the Tivoli Server:

wresgw autoenroll enable endpoint
Problems with connecting the agent to the Web Gateway

The following reviews some problems and solutions with connecting the agent to the Web Gateway.
Problem: The Nokia 9200 Communicator Series agent cannot connect to the
Web Gateway Server.
Solution: To try enrolling or processing a job, disconnect and reconnect the Nokia 9200 Communicator Series device to the host PC. If there is a RS_NO_JOBS_TO_RUN or RS_JOB_COMPLETED message near the end (last 10 or so lines) of the JavaAgentLog.txt file, the Device Agent has successfully connected.
If the connection failed, the log file contains a Connection failed or Unable to connect string near the end of the file. The trace contains the Web addresses that the Device Agent tried to connect to for the plug-in and the enrollment servlet. If the Web addresses are incorrect, the connection fails. Verify that the Web addresses are correct.
164
Note: Whether logging is enabled or disabled, if there is a TNIERROR.txt file in the installation directory, there have been some serious startup problems. If the TNIERROR.txt file is present, it contains information about the problem
Problem: The Device Agent cannot connect to the Web Gateway Server. Solution: The Device Agent must be able to resolve and reach the following server addresses:
Initial connection Web address or server URL Server redirect host name Enrollment server Web address If any of these Web addresses are set up with host names instead of the IP address and you do not have DNS set up on the device (or if there is some other TCP/IP connection issue with reaching the Web address from the device), the agent is unable to connect to the management server. For PalmOS and Windows CE agents, if the host name or address cannot be resolved or reached, the host name or address is displayed. To change the initial connection Web address or Server URL, do the following: For Palm OS and Windows CE devices, this address is configured with the Device Agent configuration user interface. The Nokia 9200 Communicator Series agent stores this address in the NokiaInterfaceSettings.cfg file, which is located in the default installation directory on the host PC.
Problem: A return code occurs when attempting to connect a device to the

Web Gateway.
Solution: There are several return codes displayed on the device screen or written to log files when a connection between the device and Web Gateway is not working properly.
Generally, the Palm OS agent displays the HTTP return codes on the device screen. The Windows CE and Nokia 9200 Communicator Series agents only indicate a connection failure message. For any type of agent-to-server communication, the access log file on the HTTP server, which is being connected to, also tracks these return codes in the second-to-last field in each log file entry. The last field in each log file entry is the number of bytes being sent in the body of the response.
165
The following are some common HTTP return codes used during Web Gateway Device Agent-to-server communications: 200 In general, a 200 return code indicates successful connection to the particular URL. However, this return code is also used when the HTTP server has returned an HTML content page with error messages in the body of the response. The Device Agents do not show HTML content pages. 401: Access to URL is not authorized If IBM Tivoli Access Manager or some other HTTP authentication front end is used, this return code occurs if the user ID or password configured in the Device Agent is incorrect. 403: Access to URL is forbidden This return code occurs if there is a problem with the security configuration of the HTTP server or client. 404: URL not found This return code occurs if the path portion of the servlet name that was configured on the client or in the enrollment server Web address is incorrect. This return code also identifies when the Web Gateway Application Server is not running within WebSphere. Use the WebSphere Administration Console to verify the status of the DMS_AppServer Application Server. 405: Method not allowed This return code occurs if the client connection URL path or enrollment server Web address is configured to an incorrect Web Gateway servlet path, for example if the client was configured to connect to an HTML Web page. 500: Internal server error This return code indicates that the WebSphere Application Server is not running. This return code also occurs if there is an error within the processing servlets. Use the DMS_stdout.log and DMS_stderr.log files to obtain more details. For additional details, enable tracing for the plug-in and dmserver components. 502 If this return code occurs when connecting to the DeviceEnrollmentServlet, it usually indicates incorrect or missing
166
parameters. To obtain more details, use the DMS_stdout.log and DMS_stderr.log files. 925 Refer to Receiving return codes from the C language APIs on page 169.
Problems with publishing and downloading a package

See below for problems and solutions:
Problem: When publishing a package using the wweb command, the following
message appears in the DMS_stdout.log file:
DYM2725E: Received a Policy Director error while assigning users to a package: package
Solution: The Web Gateway server is not configured correctly. Open the twgConfig.properties file to verify that the WEBSEAL_MOUNT_POINT value is correct.
To verify this value, start the pdadmin utility and type the following command:
object list /WebSEAL
Using the host name of the WebSEAL server returned in the previous command, type the following command to find the junction point:
object list /WebSEAL/hostname
Use the exact output, both format and case, to specify the appropriate junction point. The format of this command is the following:
/WebSEAL/hostname/junction_point
Problem: When using the Web Interface, packages can be downloaded by

one user for another user, which shows a lack of security.
Solution: The Web Gateway Server is not configured correctly. Open the twgConfig.properties file to verify that the WEBSEAL_ENABLED parameter is set to true. Problem: When using the Web Interface, I cannot download a package
published to a user using the wweb command.
Solution: The Web Gateway Server is not configured correctly. Open the twgConfig.properties file to verify that the WEBSEAL_PROTOCOL, WEBSEAL_HOST_NAME, and WEBSEAL_PORT parameters have the correct values.
167
Problems with running jobs for devices

Problem: A job runs on a device successfully, but the results do not appear on
the Tivoli Server.
Solution: Verify that the endpoint on the Web Gateway is successfully communicating with the Tivoli Server. To verify this, type the following on the Tivoli Server:
wep endpoint status
Problem: A job is submitted to a device. When the device connects to the

Web Gateway, the following message is displayed:
No job is submitted for your device
Solution: Verify that the target devices for the distribution included that device. To list the devices for the distribution, type the following from the Tivoli Server:
wwebgw -d dist_id @Endpoint:web_gw_target
If the device is not listed, resubmit the job to your device and then rerun the wwebgw command. If the device is listed, verify that the job types are properly registered. Type the following command to list the registered device classes and their job types:
TWG_HOME/bin/deviceclass.sh list
Problem: When trying to run a job on devices in a clustered Web Gateway

environment, the job fails because the software package or inventory profile cannot be accessed.
Solution: Verify that the IBM HTTP Server on the primary server in the cluster is running. Software packages and inventory profiles reside on the primary server. Problem: The distribution was successful (profiles successfully distributed)
but no inventory scan or software distribution operation was performed on the device.
Solution:
a. Check the DB2 database of the Web Gateway to confirm that jobs have been created on it. Open a DB2 command line and run:
db2 connect to dms user dmsadmin using dmsadmin password db2 select * from submitted_job
If there are jobs in the database, you should get an output similar to what is shown in Figure A-1 on page 169.
168
Figure A-1 Inventory scan job in Web Gateway database
b. Check to make sure that the device is a member of the resource group that you have distributed the profile to. The dynamic resource group will only define its members at runtime. c. Check to make sure that the conduit is installed on the host PC. d. Do not use resource groups with names that begin with _INTERNAL_RESGRP. These groups are automatically created by Resource Manager during its operation and are automatically deleted when it is no longer required.
Question: The Web Gateway server was configured incorrectly. Before I fixed
the configuration in the twgConfig.properties file, I submitted jobs to devices. Will those jobs still run on the devices?
Answer: No. You must resubmit the jobs to the devices.
Receiving return codes from the C language APIs

Problem: A return code of 925 occurs when attempting to create or delete a
device, publish or unpublish a package, or submit a job. What does this mean and how can it be debugged?
Solution: A 925 return code means there is a problem contacting the Web Gateway. Verify that the Web Gateway is started in the WebSphere Application Server. Problem: A return code occurs when attempting to create or delete a device,
or publish or unpublish a package, or submit a job. The return code value was not 925.
Solution: Verify that the Web Gateway is started in the WebSphere Application Server. You need to enable the twgapi component trace to obtain debugging information.
169
Using a non-standard port number

Question: If the Web Gateway server is running on a non-standard HTTP port,
are there any post-installation steps that need to be followed?
Answer: Yes. Refer to IBM Tivoli Configuration Manager Planning and Installation Version 4.2, GC23-4702.
Inventory problems
Problem:The inventory scan completed successfully on the devices but there is
no data in the database.
Solution: The scanned data is stored on the Web Gatewaym and the Web Gateway component makes an upcall to the gateway to request data collection. The data is collected in the same way as for inventory scans of PCs and UNIX boxes. Check the mcollect.log on the gateway. Refer to the redbook All About IBM Tivoli Configuration Manager Version 4.2, SG24-6612, for more details on troubleshooting the inventory data collection. Enable tracing of the traceEnabled.resultscollector component as detailed above and review the output log file.
Software Distribution problems

Problem: Software profiles distribution is failing for both endpoint and pervasive
device resource groups.
Solution: When there are problems distributing to devices because there are several components involved, the first step is to understand where the distribution has failed. When a package is distributed, it arrives at the endpoint where the Web Gateway is installed, and there it is converted in the TWG jobs. If jobs are not created, the problem was in the Software Distribution code (for example, the path specified as the destination is too long and the file was not created at the endpoint). If jobs are generated but there were errors executing them, the problem can be at the TWG or device level.
For the reporting flow, reports are generated by TWG code and sent to the SWD notification manager. If a report related to the distribution was not received, the problem can be due to the TWG code (Result Collector). Possible problems are: The report was not built The report was built but not yet sent. The Notification Manager says the report was received, but the report has not yet been processed by the Mcollet service Problem determination is different for all steps.
170
A good starting point is to check the swd_profile_name. log for the details of the failure. Refer to the redbook All About IBM Tivoli Configuration Manager Version 4.2, SG24-6612, for more detail on tracing failed distributions.
Resource Manager problems

A general failure when trying to register the resource type could be due to a communication failure with the Web Gateway or the Web Gateway is not functioning. These errors should show up in the TRMRDBMS.log and TRMResourceManager.log in the $DBDIR directory. There are also other TRM*.log for the various components of Resource Manager on the TMR Server under the $DBDIR directory. Review the appropriate log relating to the problem you are encountering to further determine the cause of the problem. The logs for the various components of Resource Manager are: TRMDGMAppMgr.log TRMDGMAppMgrUI.log TRMDGMDowncalls.log TRMDGMRegistry.log TRMGroup.log TRMGroupUI.log TRMRDBMS.log TRMResourceManager.log TRMResourceManagerUI.log TRMUserDB.log TRMUserUI.log Log information can be changed by setting the variable in the Tivoli environment (odadmin environ get/set):
TRM_DEBUG_LEVEL = (LEVEL_DBG_MIN/LEVEL_DBG_MID/LEVEL_DBG_MAX) TRM_MAX_LOG_SIZE = log files max size TRM_LOG_PATH = path to store log files
Tracing the Web Gateway

On the Web Gateway, locate the file traceConfig.properties file in the directory app_server_dir/installedApps/dmsserver_hostname_DMS_WebApp.ear/dmserv er.war/WEB-INF/classes. To turn on tracing, change EnableTrace=false to EnableTrace=true. The other components that need to be turned on (changed to true) are traceEnable.dmserver and traceEnabled.twgapi.
171
Depending on the situation, your support representative may request turning on tracing for the other components. If the servlets are not running, start them to put the new trace settings into effect. If the servlets are running, do one of the following to put the new trace setting into effect without restarting the servlets: On any Tivoli Web Gateway (TWG) machine, perform the following:
server -app dmserver -trace set -host dmserver_hostname
On any TWG UNIX machine, perform the following command:

./server.sh -app dmserver -trace set -host dmserver_hostname
From any machine with a browser, go to the following URL:

http://dmserver_hostname/dmserver/TraceServlet?trace=set
The output files of the tracing are DMS_stdout.log, DMS_stderr.log, and DMSMsg1.log, which are located in the app_server_dir/log directory. The default for the Windows installation is C:\WebSphere\AppServer\log. You should also provide the ApiServlet.log in the /tmp directory to your support representative.
172
Abbreviations and acronyms

AAT ADK API APM BA CAB CGI CPU DB DIT DM DNS GB GSK GSO GUI HTML HTTP HTTPS IBM IC IIS IP ITCM ITM ITSO JAR JDBC WebSphere Application Assembly Tool Application Development Kit Application Programming Interface Activity Plan Monitor Basic Authentication Cabinet files Common Gateway Interface Central Processing Unit Database Directory Information Tree Distributed Monitoring Domain Name System Gigabyte Global Security Toolkit Global Sign On Graphical User Interface Hypertext Markup Language Hypertext Transfer Protocol HTTP running under SSL International Business Machines Corporation Installed and Committed state Internet Information Server Internet Protocol IBM Tivoli Configuration Manager IBM Tivoli Monitoring International Technical Support Organization Java archive file Java Database Connectivity SPB SQL SSL SSO SWD TCP TCP/IP TEC TMR TRM TWG UDB URL XML RIM SID SIS SP SPARC MD5 OLAP PDA PDF RAM RDBMS JRE LDAP Java Runtime Environment Lightweight Directory Access Protocol Message Digest 5 Online Analytical Processing Personal Digital Assistant Portable Document Format Random Access Memory Relational Database Management System RDBMS Interface Module Session Identifier Software Installation Services Software Package Scalable Processor Architecture Software Package Block Structured Query Language Secure Socket Layer Single Sign On Software Distribution Transmission Control Protocol Transmission Control Protocol/Internet Protocol Tivoli Enterprise Console Tivoli Management Region Tivoli Resource Manager Tivoli Web Gateway Universal Database Universal Resource Locator eXtensible Markup Language
173
174
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see How to get IBM Redbooks on page 177. Note that some of the documents referenced here may be available in softcopy only.
Tivoli Enterprise Internals and Problem Determination, SG24-2034 Tivoli Inventory Version 4.0 Migration Guide from Version 3.6.2, SG24-7020 Tivoli Software Distribution 4.1: NetView DM Migration, SG24-6040 Tivoli Software Distribution 4.1: New Features and Scenarios, SG24-6045 All About IBM Tivoli Configuration Manager Version 4.2, SG24-6612 Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014 Enterprise Business Portals with IBM Tivoli Access Manager, SG24-6556 Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885
Other publications
These publications are also relevant as further information sources:
IBM Tivoli Access Manager for e-business Authorization Java Classes Developers Reference, GC23-4688 IBM Tivoli Access Manager WebSEAL Administrators Guide Version 4.1, SC32-1134 IBM Tivoli Access Manager WebSEAL Installation Guide Version 4.1, SC32-1133 IBM Tivoli Configuration Manager Introduction Version 4.2, GC23-4703 IBM Tivoli Configuration Manager Planning and Installation Version 4.2, GC23-4702 IBM Tivoli Configuration Manager Version 4.2 Release Notes, GI11-0934
175
IBM Tivoli Configuration Manager Reference Manual for Software Distribution Version 4, SC23-4712 IBM Tivoli Configuration Manager Users Guide for Deployment Services, SC23-4710 IBM Tivoli Configuration Manager Users Guide for Inventory Version 4.2, SC23-4713 IBM Tivoli Configuration Manager Users Guide for Software Distribution, SC23-4711 Tivoli Configuration Manager Messages and Codes Version 4.2, SC23-4706 Tivoli Management Framework User s Guide Version 4.1, GC32-0805-003 Tivoli Management Framework Enterprise Installation Guide Version 4.1, GC32-0804 Tivoli Management Framework Reference Manual Version 4.1, SC32-0806 Tivoli Management Framework Release Notes Version 4.1, GI11-0890 (comes with the product)
Online resources
These Web sites and URLs are also relevant as further information sources: Microsoft Web site
http://www.microsoft.com
Nokia support Web site

http://www.nokia.com/phones/productsupport
Nokia Web site

http://www.nokia.com
OrbData Web site

http://www.orb-data.com
Suns Java Web site

http://java.sun.com/j2se/
Palm Inc. Web site

http://www.palm.com/us/
mBrain Software Web site

http://www.mbrainsoftware.com
176
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site:
ibm.com/redbooks
Related publications
177
178
Index
Symbols
_INTERNAL_RESGRP 169 Config.PDB 102, 118 Configuration Change Manager 8 configuration file 118 cradle 118 creating RIM object 31
A
Access Manager java runtime 82 actions 8 Active Sync 137 Activity Planner 8 Activity Planner Manager 8, 10 ADK 76 admin server user 20 Administrator Suite 103 agent install program 103 AIX filesets 17 APIs 169 ApiServlet.log 172 APM See Activity Planner Manager Application Development Kit 76 AppServerStarted 157 Authentication base 87 forms 87 Authorization Server 75
D
DB sql scripts 37, 57 DB2 18 DB2 admin 20 DB2 fenced 19 DB2 instance 19 DB2 setup 18 DB2 tablespaces 163 DB2 Warehouse 20 DB2SYSTEM 21 DEV_CMSTATUS_QUERY 117, 136 Development Kit 76 device agent install Nokia 103 Palm 118 PocketPC 138 Device Directory 5 device groups 4, 8 device management troubleshooting 155 device_class 158 deviceclass script 95 direct network connection 118 Directory Client 69 directory information tree 69 Directory services 67 discover 107, 122, 141 DIT 69 DMS_stdout 161 dmsadmin 156 dmsadmin User ID 27, 48 DMSAgentResources.PDB 102 DMSplugin.device_class 158 dmsuser 156 dmsuser User ID 27, 48 DNS 162 docroot parameter 90 dynamic resource groups 4
B
ba-auth 87 Basic Authentication 87 browser 172
C
C APIs 169 CCM See Configuration Change Manager ceagent.arm.CAB 102 CGI program 89 Change Manager 8 cmstatus 136 CondInst.exe 102 condinst.exe 119 conduit 118, 162 config.ini 118
179
E
enable security 91 endpoint catalog file 160 Enterprise Directory server 5 EUPCInstaller.exe 102103 ezinstall_ldap_server.bat 68 ezinstall_pdacld.bat 75 ezinstall_pdauthadk.bat 76 ezinstall_pdmgr.bat 72
F
fenced user 19 Forms Authentication 87 forms-auth 87
G
Global Security Toolkit 67, 69 Global Sign-On 69 GSK 67, 69 GSO 69
instance 19 INSTHOME 21 integrated installation 26 Internet Information Services 43 inventory query 117 Inventory scan Palm 131 PocketPC 149 invtiv User ID 26, 48 ITCM install 26 ITCM user IDs dmsadmin 27, 48 dmsuser 27, 48 invtiv 26, 48 mdstatus 26, 48 planner 26, 48 tivoli 27, 48 ivacld process 84 ivmgrd process 84
J
Java InetAddress 158 Java Runtime install 8283 java_home variable 84 JDBC 2.0 driver 161 JDBC code level 21 JRE uninstall 160 jre_path 160 junction 12, 86
H
host PC 103 HotSync Manager 118 HotSync operation 135 htdocs 90 HTTP docroot 90 HTTPS access 81
I
IBM Agent 121, 137 IBM DB2 8 IBM DB2 admin 20 IBM DB2 fenced 19 IBM DB2 instance 19 IBM DB2 tablespaces 163 IBM DB2 warehouse 20 IBM Directory Client 67, 69 IBM Directory Server 67 IBM Global Security Toolkit 67, 69 IBM WebSphere Application Server 8 IBMJCEfw.jar 82 IC state 160 IIS services 43 InetAddress 158 installation matrix 15 InstallShield 78
K
keystore file 85 keystores 84
L
lcfd.log 134, 151 LDAP 5, 69 server 5 LDAP client 69 ldap_server 68 Lightweight Directory Access Protocol 5 Linux 14
M
managed node 7 management actions 8 mBrain Software 108
180
MCollect 11 mcollect.log 135, 152 MDist2 115, 129, 147 mdstatus User ID 26, 48 Microsoft Active Sync 137 MIPS processor 138
proxy agent 103 proxy setting 162 pSeries 14 PvcPalm.prc 102
Q
query 117 query libraries 136, 153 query_contents 89
N
name resolution 162 Nokia 9200 Series 3 Nokia 9290 100 Nokia device agent 103 Nokia programming interface 103
R
Redbooks Web site 177 Contact us xi Resource Gateway 7 Resource Groups 4 Resource Manager 5 resources-type 5 Results Collector 10 RIM 31 RIM host 6
O
odadmin 171
P
Palm 3 Palm Desktop install tool 121 Palm device 10 Palm device agent 118 Palm V 100 PalmOS 158 PC Suite 103 PD_ADMIN_PW 161 pdacld 75 pdadmin 162 pdauthadk 76 pdbgene.jar 118 PdfPlus software 117 pdjrte 82 pdjrtecfg command 84, 160 pdmgr 72 PDWeb 78 PDWebADK 78 Pervasive device management architecture 4 Resource Manager 4 pervasive devices 3 PERVASIVE_QUERY 135 pfd_plus.spb 110 planner User ID 26, 48 PocketPC 3 PocketPC device agent 138 Policy Server 72 Portal Manager 89
S
sec_master 162 Security Toolkit 67, 69 servlet 24 SH-3 processor 138 SH-4 processor 138 Single Sign-On 12 Single-box approach 11 small and medium business 11 SMB See small and medium business snoop servlet 24 Software Distribution Agent 10 Software Distribution engine 10 Software Package 111 SPARC systems 14 SQL 6 sql scripts 37, 57 SSL junction 86 SSO See Single Sign-On static resource groups 4 StrongARM processor 138 sub-agent 10 Subscribers 8 Sun SPARC 14
Index
181
T
tablespaces 163 TDM 10 Tivoli commands discover 107, 122, 141 odadmin 171 wep command 168 wresgrp 107 wresgw 107, 122, 141, 164 wresource 107 wweb 167 wwebgw 116 Tivoli Framework 9 Tivoli Resource Manager 4, 8 Tivoli Resource Manager Gateway 7 tivoli User ID 27, 48 Tivoli Web Gateway 5, 8 Tivoli Web Gateway installation 33, 53 Toshiba e335 100 TRM See Tivoli Resource Manager Troubleshooting Resource Manager problems 171 Web Gateway installation 156 TWG 5 twgapi component 169 typical problems 161
Web Portal Manager 89 web.xml 9495 WebConfig 158 WebConsole Enterprise 160 WebSEAL 12, 15 ADK 78 basic authentication 87 configuration 80 forms authentication 87 installation 78 junction 86 WebSphere snoop 24 WebUI_AppServer 160 wep command 168 WinCE 3 WinCE device agent 138 WINCE_FILE_QUERY 152 WinceServlet 140 Windows CE Service 137 wresgrp 107 wresgw 107, 122, 141, 164 wresource 107 wweb 167 wwebgw 116
X
X11.adt.lib 17
U
ulimit 163 update JDBC level for DB2 21 user rights 45 Users groups 4 use-same-session 87
V
vendor specification 30, 50 viewer for Nokia 108 viewer for Palm 123 viewer for PocketPC 142
W
WASConfig 159 WASNodeList 158 Web Gateway 6 Web Gateway installation troubleshooting 156 Web Gateway troubleshooting 155
182
(0.2spine) 0.17<->0.473 90<->249 pages
Back cover

A primer for deployments of any size and proofs of concept Step-by-step installation and how-to instructions Scenario-based PDA management
IBM Tivoli Configuration Manager 4.2 was launched in October 2002. Along with many new functional and performance features, it includes an enhanced Web-based device management capability, called Tivoli Web Gateway, running on top of IBM WebSphere Application Server. This IBM Redbook describes in detail the steps required to install and configure the Tivoli Web Gateway and all the prerequisite products, to allow a successful implementation of a pervasive device management environment. While the information provided by this redbook can be used on deployments of any size, it will be particularly useful to enable the management of pervasive devices by small and medium businesses (SMBs). It will also help Business Partners and IBM services when setting up demonstrations and proofs of concept.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks

SG24-6951-00 ISBN 0738453390

PDA Management With IBM Tivoli Configuration Manager Sg246951

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PDA Management With IBM Tivoli Configuration Manager Sg246951

Uploaded by

Copyright:

Available Formats

Front cover

PDA Management with IBM Tivoli Configuration Manager

Edson Manoel Zoltan Veress Szabolcs Barabas

Copyright IBM Corp. 2003. All rights reserved.

PDA Management with IBM Tivoli Configuration Manager

...... ...... ...... ......

....... ....... ....... .......

...... ...... ...... ......

170 170 171 171

PDA Management with IBM Tivoli Configuration Manager

Copyright IBM Corp. 2003. All rights reserved.

PDA Management with IBM Tivoli Configuration Manager

The team that wrote this redbook

Copyright IBM Corp. 2003. All rights reserved.

Become a published author

PDA Management with IBM Tivoli Configuration Manager

Send your comments in an Internet note to:

PDA Management with IBM Tivoli Configuration Manager

Concepts, planning, and implementation

Copyright IBM Corp. 2003. All rights reserved.

PDA Management with IBM Tivoli Configuration Manager

Device management architecture

Copyright IBM Corp. 2003. All rights reserved.

1.1 Device Management overview

1.1.1 Tivoli Resource Manager and Web Gateway

PDA Management with IBM Tivoli Configuration Manager

Figure 1-1 Tivoli Resource Manager infrastructure

Chapter 1. Device management architecture

yrotcer D yrotcer D yrecticeriiiD o veD ec veD ec veD eciiiveD

PDA Management with IBM Tivoli Configuration Manager

TMR Server Tivoli Resource Manager Server

Tivoli Gateway Tivoli Resource Manager GW

IBM DB2 Server

Host PCs with Pervasive device connected

Host PC with Pervasive device connected

Figure 1-2 Tivoli Resource Manager and Web Gateway components

Chapter 1. Device management architecture

1.1.2 Device Management internals

PDA Management with IBM Tivoli Configuration Manager

Configuration Change Manager

Activity Planner Manager

Tivoli Web Gateway Device Directory

Tivoli Server / Gateway

Software Dist Engine

Software Distribution Agent

CT Abstraction Layer Result Collector 10

Websphere Device Gateway

Host PC with Pervasive device connected

Figure 1-3 Data flow using software distribution to push to devices

Chapter 1. Device management architecture

PDA Management with IBM Tivoli Configuration Manager

1.2 Our approach

Chapter 1. Device management architecture

TMR Server Tivoli Resource Manager Server

Tivoli Gateway Tivoli Resource Manager GW IBM DB2 Server

Host PCs with Pervasive device connected

Host PC with Pervasive device connected

Figure 1-4 Single-box approach

PDA Management with IBM Tivoli Configuration Manager

Getting the environment up and running

Copyright IBM Corp. 2003. All rights reserved.

2.1 Planning for the single-box installation

2.1.1 Software requirements