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 PDA Management with IBM Tivoli Configuration Manager

Inventory problems . . . . . . . . . . . . . . . . . . . . . . ...... ....... ...... . 170
Software Distribution problems . . . . . . . . . . . . . ...... ....... ...... . 170
Resource Manager problems . . . . . . . . . . . . . . ...... ....... ...... . 171
Tracing the Web Gateway . . . . . . . . . . . . . . . . . . . ...... ....... ...... . 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 v

vi PDA Management with IBM Tivoli Configuration Manager

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.

© Copyright IBM Corp. 2003. All rights reserved. vii

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:

Redbooks (logo) ™ IBM® SP2®
ibm.com® PowerPC® Tivoli Enterprise™
pSeries™ Redbooks™ Tivoli®
AIX® RS/6000® TME®
DB2 Universal Database™ SecureWay® WebSphere®
DB2® SP™

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 PDA Management with IBM Tivoli Configuration Manager

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

© Copyright IBM Corp. 2003. All rights reserved. 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

x PDA Management with IBM Tivoli Configuration Manager

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 PDA Management with IBM Tivoli Configuration Manager

Part 1

Part 1 Concepts,
planning, and
implementation

© Copyright IBM Corp. 2003. All rights reserved. 1

2 PDA Management with IBM Tivoli Configuration Manager

1

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 Manager’s 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.

ecruoseR
ecruoseR
ecruoseR
ecruoseR
ecruoseR
ecruoseR
ecruoseR
ecruoseR esaBataD ec veD
ec veD
eciiiveD
reganaM
reganaM
reganaM
reganaM
reganaM
reganaM
reganaM
reganaM ecafraettnI
esaB aD
esaBataD
ecafretnI
ecafretnI yrectcer D
yrectiiceriiiD
o veD
o veD
yrotcer D

P AD L
P AD L
P AD L
P AD L
P AD L
P AD L
P AD L
P AD L
P AD L
dSA
Table1
Group

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 5

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 RIM
Tivoli Resource Manager Server Host
RDBMS

Tivoli Gateway
Tivoli Resource Manager GW

Endpoint
Tivoli Web Gateway
Resource Collector
WebSphere Server
IBM DB2 Server
IBM DB2 Client

HTTP HTTP
HTTP

Host PC with Pervasive
Host PCs with Pervasive device connected
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 user’s 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).
Change Manager 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).

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:

1 Configuration
Change
Administrator Manager 2

3 Inventory DB

4
SWDistManager Activity Planner
Tivoli Web Gateway
Object Manager

5
Device Directory

6
Tivoli
Software Dist
Engine Server / Gateway
6

Software
Distribution Subagent
Agent 7

8
Endpoint

CT Abstraction Layer

Result Websphere
Collector Device
11
10 Gateway
9

HTTP

Host PC with Pervasive device connected

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


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.


TMR Server RIM
Tivoli Resource Manager Server 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 PC with Pervasive
Host PCs with Pervasive device connected
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.


2

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


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.


Table 2-1 Memory / disk space requirements for Tivoli Web Gateway
Component Disk Space Memory

Web Gateway database 672 MB 512 MB
Web Gateway server 300 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 Estimated Time 1
(minutes)

IBM DB2 + IBM DB2 Fixpack 7 (V7.2.5) 40

IBM WebSphere Advanced Edition + Fixpack 3 (V4.0.3) 40

IBM HTTP Server 1.3.19.2 (installed with the base -
WebSphere installation + fixpack applied)

IBM Tivoli Configuration Manager 4.2 (using integrated 90
installation, which includes all the Tivoli software
components required for the PDA management solution)

Tivoli Web Gateway 30
1
Total estimated time: 3-4 hours

Intel-based environment is shown in Table 2-3.

Table 2-3 Intel-based installation matrix
Intel-based Tivoli Web Gateway Server Estimated Time 1
(minutes)

IBM DB2 + IBM DB2 fixpack 7 (V7.2.5) 30

IBM WebSphere Advanced Edition + Fixpack 3 (V4.0.3) 40

IBM HTTP Server 1.3.19.2 (installed with the base -
WebSphere installation + fixpack applied)

IBM Tivoli Configuration Manager 4.2 (using integrated 80
installation, which includes all the Tivoli software
components required for the PDA management solution)

Tivoli Web Gateway 40

IBM Tivoli Access Manager 3.9 (includes all the Access 120
Manager components for securing the PDA management
environment). Optional.
1
Total estimated time: 5-6 hours (including optional components)


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 Estimated Time 1
(minutes)

IBM Tivoli Access Manager for e-business 3.9 (includes all 120
the Access Manager components for securing the PDA
management environment). Optional.

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

/tivoli 1048576

/db 1048576

/dmsdb 1048576

3. We also had to expand some base filesystems, such as those listed in
Table 2-6 on page 18.


Table 2-6 Expanded file systems
File system name Expanded size in 512-byte blocks

/usr 3014656

/home 327680

/tmp 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


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.


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.


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


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


# 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.


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 server’s host name
or IP address. Information about /servlet/snoop is displayed.


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
root’s .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


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 Password Group ID

planner planner db2iadm1

mdstatus mdstatus db2iadm1

invtiv tivoli db2iadm1



tivoli tivoli db2iadm1

dmsadmin db2iadm1

dmsuser 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).


Figure 2-7 ITCM integrated installation start window

4. Select I accept terms in the license agreement and click Next.


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.


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.


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.


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.


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
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


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.


Figure 2-14 Select Type of Installation

3. Select the Custom installation type and click Next.

Figure 2-15 Tivoli Web Gateway Component selection


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 Gateway’s 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.


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:
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.


– 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.
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.


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.


Figure 2-20 Access Manager configuration information

order for the Tivoli Web Gateway installation to be successful. Please refer to

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.



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.


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


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:winntsystems32driversetchosts 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.


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_DIRjava12
usejdbc2
Where DB2_DIR is the DB2 installation directory. The usejdbc2 command will
copy the appropriate version of db2java.zip into the DB2_DIRjava12
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.


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 won’t 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:db2sqllibbin:>db2stop
c:db2sqllibbin:>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_wr21311setup.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


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:WebSphereAppServer 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:db2sqllib
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


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 server’s 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:

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_3install.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


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

planner planner Administrators

mdstatus mdstatus Administrators

invtiv tivoli Administrators

tivoli tivoli Administrators

dmsadmin Administrators

dmsuser 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).


Figure 2-25 ITCM integrated installation start window


Figure 2-26 Installation type selection


5. Select the Typical installation option and click Next.
6. Specify the directory to be used for the installation. Specify c:Program
filesTivoli as the destination directory and click Next.

Figure 2-27 Database vendor specification

7. Select DB2 as the database vendor and c:DB2Sqllib 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.


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.


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.


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


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


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.


Figure 2-32 Select Type of Installation

3. Select the Custom installation type and click Next.

Figure 2-33 Tivoli Web Gateway Component selection


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:
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 Gateway’s 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.


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:
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.


Figure 2-36 Web Gateway Server Information

7. Define the Web Gateway server-related options, shown in Figure 2-36.
Where the Web Gateway Server files will be installed. We used the default
option c:Program FilesTivTwg.
– Web server home
We installed the IBM HTTP server to the c:Program FilesIBM HTTP
Server directory, which is the default option.
– JDBC driver home
The location of the JDBC driver. The default option is
c:DB2SQLLIBjava12db2java.zip.


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.


Figure 2-38 Access Manager Configuration information


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.



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.


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.


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.


3

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.


3.1 General considerations
The usual installation and operation procedures don’t 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


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.


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 FilesIBMGSK, and enter Y to continue.
5. Accept the default value for the IBM Directory Client installation directory,
c:Program FilesIBMLDAP, 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.


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


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


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

The easy install script, ezinstall_pdmgr.bat, sets up a base system with the
IBM Global Security Toolkit (GSKit)
IBM SecureWay Directory client
Access Manager runtime
Policy Server
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.


– 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
you’ve 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.


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


The easy install script, ezinstall_pdacld.bat, sets up a base system with the
Authorization Server
ezinstall_pdacld.bat
The initial installation window is displayed, as shown in Figure 3-13.


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.


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
Application Development Kit (ADK)
ezinstall_pdauthadk.bat
The initial installation window is displayed, as shown in Figure 3-15 on
page 77.



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


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.
<CD_Drive>:windowsPolicyDirectorDisk ImagesDisk1WebSEALDisk
ImagesDisk1setup.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.


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


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


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.


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:
Server before installing the Access Manager Java Runtime Environment.
2. Delete the IBMJCEfw.jar file in the jvm_pathjrelibext directory. The default
location is C:WebSphereAppServerjavajrelibextibmjcefw.jar.
3. To install the Access Manager JRE component, run the setup.exe command
in the <CDDrive>:windowsPolicyDirectorDisk ImagesDisk1PDJRTEDisk
ImagesDisk1 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.


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


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:WebSphereAppServerjavajrebin;%PATH%
12.You need to configure the Java Runtime Environment provided by IBM Tivoli
Access Manager. Enter the following commands:
cd C:Program FilesTivoliPolicy Directorsbin
pdjrtecfg -action config -java_home C:WebSphereAppServerjavajre
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.


– 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


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


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:TivoliPDWebetc 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


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


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
FilesTivoliPDWebwwwlibquery_contents directory on the Tivoli Access
Manager machine into the C:Program FilesIBM HTTP Servercgi-bin on the
Tivoli Web Gateway machine.


2. Copy the file query_contents.cfg file from the C:Program
Manager machine into the C:WINNT on the Tivoli Web Gateway machine.
3. On the Tivoli Web Gateway machine, edit the file
C:WINNTquery_contents.cfg to define the docroot parameter as follows:
docroot=C:Program FilesIBM HTTP Serverhtdocs
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 FilesIBM HTTP
Serverhtdocs.

Figure 3-29 Query_contents result

Tivoli Web Gateway running on AIX
1. Copy the file query_contents.sh file from the C:Program
Manager machine into the /usr/HTTPServer/cgi-bin on the Tivoli Web
Gateway machine.


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


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.


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.


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.


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
# deviceclass.sh -modify Nokia9200Series -enroll

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
deviceclass.bat -modify Wince -enroll
deviceclass.bat -modify Nokia9200Series -enroll

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.


Figure 3-33 Logging on to the Web Gateway


Part 2

Part 2 Case study
scenario


4

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


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 company’s
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.


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 User’s 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 PDA’s host PCs, and connect them to the Resource
Gateway.

Table 4-1 IBM Device Agents
Device Type IBM Device Agent name IBM Device Agent name
resides on the host PC resides on the device

Nokia 9290 EUPCInstaller.exe N/A

Palm V CondInst.exe DMSAgentResources.PDB
PvcPalm.prc
Config.PDB

Toshiba Pocket PC E335 N/A ceagent.arm.CAB

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 PDF reader software to deploy

Nokia 9290 Communicator PDF+

Palm V Adobe Acrobat Reader for Palm OS

Toshiba Pocket PC E335 Adobe Acrobat Reader for Pocket PC


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 Software Distribution Inventory scan

Nokia 9290 Yes Not supported

Palm V Yes Yes

Toshiba Pocket PC E335 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]agentsNokia, 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.


Figure 4-2 Nokia Device Agent welcome window

3. Click Next to continue.

Figure 4-3 Specify destination folder


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.


Figure 4-5 Progress bar of the installation

Figure 4-6 The finished installation


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 User’s
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:
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


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


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


– Location: c:workredpaper - 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.


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 don’t 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.


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 User’s 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.


Figure 4-14 Subscribing the rg.pervasive_devices.nokia resource group

The Profile Manager will look like Figure 4-15 on page 114.


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.


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


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
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


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.


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 FilesTivTwgagenttools. Chapters 11 and 14 of the IBM Tivoli
Configuration Manager User’s 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; don’t 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;
don’t change it
– PalmUserID: The user name of the Palm user
– SSLOn: We disabled SSL since we don’t 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


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 FilesTivTwgagentspalm 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.


Figure 4-20 Palm OS agent installation progress bar

6. The installation starts automatically.

Figure 4-21 The finished Palm OS agent installation


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 User’s 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


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

FBBWD0039I palm001 EXISTS

13.We list the discovered pervasive devices:
Pervasive_Device:
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


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.



4. The next step is to add the device file properties. We set the following options:
– Location: c:workredpaper - location of the file on the package builder
– Name: AcroRead.prc - Name of the installation file

Figure 4-26 Device file properties


5. Finally, we save the software package as Acrobat_palm.spb.

Figure 4-27 Saving the software package as an .spb file

pm.pervasive_devices.swd.palm.acrobatreader^2.0. Ensure that you don’t
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.


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.


Figure 4-30 Subscribing the rg.pervasive_devices.palm resource group

The Profile Manager will look like Figure 4-15 on page 114


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.



2. You can check the MDist2 GUI to follow up the distribution status. However,
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


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
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
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




--------------- --------------
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.


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


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.


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
Gateway’s 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



--------------- --------------
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.


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.


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>agentswinceWinCE2.1
For WinCE Version 3.0 and Pocket PC or Pocket PC 2002 devices:
<TWGDIR>agentswinceWinCE3.0

Where <TWGDIR> is the Tivoli Web Gateway installation directory.


Table 4-4 Agent install package per processor type
CPU Type Agent install package

SH-3 ceagent.sh3.cab

SH-4 ceagent.sh4.cab

MIPS ceagent.mip.cab

StrongARM 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


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.


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


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

FBBWD0039I IBMWINCE EXISTS

9. We list the discovered pervasive devices:
Pervasive_Device:
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


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.



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.


Figure 4-47 Saving the software package as an SPB

pm.pervasive_devices.swd.wince.acrobat^1. Ensure that you don’t 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.


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


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.



You can check the MDist2 GUI to follow up the distribution status. However,
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.


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


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


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.


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
Gateway’s 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


--------------- --------------
1148766224.87 1148766224#Inventory


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


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.


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.


A

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.


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.


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:WINNTsystem32driversetcservices 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
TivTwgtmp_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_HOMEtmpAppServerStarted.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_HOMEtmpDMSplugin.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_HOMEtmpWebConfig.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_HOMEtmpWASNodeList.log
This file displays information about running the
TWG_HOMEinstalletcWASNodeList.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:


Example 4-12 WASNodeList.log
"*** Obtain node name list from WAS ***"
"--- Placing list in file: C:Program FilesTivTwgbinWASlist.nodename"
"*** End C:Program FilesTivTwginstalletcWASnodename.bat ***"

WASConfig.log
Location: TWG_HOMEtmpWASConfig.log
This file displays information from the TWG_HOMEinstalletcWASConfig.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 FilesTivTwginstalletccreateDMS_WebAppTMP.bat ***"
"*** End C:Program FilesTivTwginstalletccreateDMS_WebAppTMP.bat ***"


"~~ 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:WebWphereAppserverinstalledApps.

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:swdisworkepsp.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:WebSphereAppServerjavajre):
pdjrtecfg -action unconfig -java_home jre_path


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


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)
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.


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 User’s
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.


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.


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.


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


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
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.


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.


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.


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.


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.


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:WebSphereAppServerlog.

You should also provide the ApiServlet.log in the /tmp directory to your support
representative.


Abbreviations and acronyms
AAT WebSphere Application JRE Java Runtime Environment
Assembly Tool LDAP Lightweight Directory Access
ADK Application Development Kit Protocol
API Application Programming MD5 Message Digest 5
Interface OLAP Online Analytical Processing
APM Activity Plan Monitor PDA Personal Digital Assistant
BA Basic Authentication PDF Portable Document Format
CAB Cabinet files RAM Random Access Memory
CGI Common Gateway Interface RDBMS Relational Database
CPU Central Processing Unit Management System
DB Database RIM RDBMS Interface Module
DIT Directory Information Tree SID Session Identifier
DM Distributed Monitoring SIS Software Installation Services
DNS Domain Name System SP Software Package
GB Gigabyte SPARC Scalable Processor
GSK Global Security Toolkit Architecture

GSO Global Sign On SPB Software Package Block

GUI Graphical User Interface SQL Structured Query Language

HTML Hypertext Markup Language SSL Secure Socket Layer

HTTP Hypertext Transfer Protocol SSO Single Sign On

HTTPS HTTP running under SSL SWD Software Distribution

IBM International Business TCP Transmission Control
Machines Corporation Protocol

IC Installed and Committed state TCP/IP Transmission Control
Protocol/Internet Protocol
IIS Internet Information Server
TEC Tivoli Enterprise™ Console
IP Internet Protocol
TMR Tivoli Management Region
ITCM IBM Tivoli Configuration
Manager TRM Tivoli Resource Manager

ITM IBM Tivoli Monitoring TWG Tivoli Web Gateway

ITSO International Technical UDB Universal Database
Support Organization URL Universal Resource Locator
JAR Java archive file XML eXtensible Markup Language
JDBC Java Database Connectivity


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
Developer’s Reference, GC23-4688
IBM Tivoli Access Manager WebSEAL Administrator’s 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


IBM Tivoli Configuration Manager Reference Manual for Software Distribution
Version 4, SC23-4712
IBM Tivoli Configuration Manager User’s Guide for Deployment Services,
SC23-4710
IBM Tivoli Configuration Manager User’s Guide for Inventory Version 4.2,
SC23-4713
IBM Tivoli Configuration Manager User’s 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
Sun’s 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


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

Index
Config.PDB 102, 118
Symbols Configuration Change Manager 8
_INTERNAL_RESGRP 169
configuration file 118
cradle 118
A creating RIM object 31
Access Manager java runtime 82
actions 8
Active Sync 137
D
DB sql scripts 37, 57
Activity Planner 8
DB2 18
Activity Planner Manager 8, 10
DB2 admin 20
ADK 76
DB2 fenced 19
admin server user 20
DB2 instance 19
Administrator Suite 103
DB2 setup 18
agent install program 103
DB2 tablespaces 163
AIX filesets 17
DB2 Warehouse 20
APIs 169
DB2SYSTEM 21
ApiServlet.log 172
DEV_CMSTATUS_QUERY 117, 136
APM
Development Kit 76
See Activity Planner Manager
device agent install
Application Development Kit 76
Nokia 103
AppServerStarted 157
Palm 118
Authentication
PocketPC 138
base 87
Device Directory 5
forms 87
device groups 4, 8
Authorization Server 75
device management troubleshooting 155
device_class 158
B deviceclass script 95
ba-auth 87 direct network connection 118
Basic Authentication 87 Directory Client 69
browser 172 directory information tree 69
Directory services 67
discover 107, 122, 141
C DIT 69
C APIs 169
DMS_stdout 161
CCM
dmsadmin 156
See Configuration Change Manager
dmsadmin User ID 27, 48
ceagent.arm.CAB 102
DMSAgentResources.PDB 102
CGI program 89
DMSplugin.device_class 158
Change Manager 8
dmsuser 156
cmstatus 136
dmsuser User ID 27, 48
CondInst.exe 102
DNS 162
condinst.exe 119
docroot parameter 90
conduit 118, 162
dynamic resource groups 4
config.ini 118


E instance 19
enable security 91 INSTHOME 21
endpoint catalog file 160 integrated installation 26
Enterprise Directory server 5 Internet Information Services 43
EUPCInstaller.exe 102–103 inventory query 117
ezinstall_ldap_server.bat 68 Inventory scan
ezinstall_pdacld.bat 75 Palm 131
ezinstall_pdauthadk.bat 76 PocketPC 149
ezinstall_pdmgr.bat 72 invtiv User ID 26, 48
ITCM install 26
ITCM user IDs
F dmsadmin 27, 48
fenced user 19
dmsuser 27, 48
Forms Authentication 87
invtiv 26, 48
forms-auth 87
mdstatus 26, 48
planner 26, 48
G tivoli 27, 48
Global Security Toolkit 67, 69 ivacld process 84
Global Sign-On 69 ivmgrd process 84
GSK 67, 69
GSO 69
J
Java InetAddress 158
H Java Runtime install 82–83
host PC 103 java_home variable 84
HotSync Manager 118 JDBC 2.0 driver 161
HotSync operation 135 JDBC code level 21
htdocs 90 JRE uninstall 160
HTTP docroot 90 jre_path 160
HTTPS access 81 junction 12, 86

I K
IBM Agent 121, 137 keystore file 85
IBM DB2 8 keystores 84
IBM DB2 admin 20
IBM DB2 fenced 19
IBM DB2 instance 19
L
lcfd.log 134, 151
IBM DB2 tablespaces 163
LDAP 5, 69
IBM DB2 warehouse 20
server 5
IBM Directory Client 67, 69
LDAP client 69
IBM Directory Server 67
ldap_server 68
IBM Global Security Toolkit 67, 69
Lightweight Directory Access Protocol 5
IBM WebSphere Application Server 8
Linux 14
IBMJCEfw.jar 82
IC state 160
IIS services 43 M
InetAddress 158 managed node 7
installation matrix 15 management actions 8
InstallShield 78 mBrain Software 108


MCollect 11 proxy agent 103
mcollect.log 135, 152 proxy setting 162
MDist2 115, 129, 147 pSeries 14
mdstatus User ID 26, 48 PvcPalm.prc 102
Microsoft Active Sync 137
MIPS processor 138
Q
query 117
N query libraries 136, 153
name resolution 162 query_contents 89
Nokia 9200 Series 3
Nokia 9290 100
Nokia device agent 103
R
Redbooks Web site 177
Nokia programming interface 103
Contact us xi
Resource Gateway 7
O Resource Groups 4
odadmin 171 Resource Manager 5
resources-type 5
Results Collector 10
P RIM 31
Palm 3
RIM host 6
Palm Desktop install tool 121
Palm device 10
Palm device agent 118 S
Palm V 100 sec_master 162
PalmOS 158 Security Toolkit 67, 69
PC Suite 103 servlet 24
PD_ADMIN_PW 161 SH-3 processor 138
pdacld 75 SH-4 processor 138
pdadmin 162 Single Sign-On 12
pdauthadk 76 Single-box approach 11
pdbgene.jar 118 small and medium business 11
PdfPlus software 117 SMB
pdjrte 82 See small and medium business
pdjrtecfg command 84, 160 snoop servlet 24
pdmgr 72 Software Distribution Agent 10
PDWeb 78 Software Distribution engine 10
PDWebADK 78 Software Package 111
Pervasive device management SPARC systems 14
architecture 4 SQL 6
Resource Manager 4 sql scripts 37, 57
pervasive devices 3 SSL junction 86
PERVASIVE_QUERY 135 SSO
pfd_plus.spb 110 See Single Sign-On
planner User ID 26, 48 static resource groups 4
PocketPC 3 StrongARM processor 138
PocketPC device agent 138 sub-agent 10
Policy Server 72 Subscribers 8
Portal Manager 89 Sun SPARC 14

Index 181

T Web Portal Manager 89
tablespaces 163 web.xml 94–95
TDM 10 WebConfig 158
Tivoli commands WebConsole Enterprise 160
discover 107, 122, 141 WebSEAL 12, 15
odadmin 171 ADK 78
wep command 168 basic authentication 87
wresgrp 107 configuration 80
wresgw 107, 122, 141, 164 forms authentication 87
wresource 107 installation 78
wweb 167 junction 86
wwebgw 116 WebSphere snoop 24
Tivoli Framework 9 WebUI_AppServer 160
Tivoli Resource Manager 4, 8 wep command 168
Tivoli Resource Manager Gateway 7 WinCE 3
tivoli User ID 27, 48 WinCE device agent 138
Tivoli Web Gateway 5, 8 WINCE_FILE_QUERY 152
Tivoli Web Gateway installation 33, 53 WinceServlet 140
Toshiba e335 100 Windows CE Service 137
TRM wresgrp 107
See Tivoli Resource Manager wresgw 107, 122, 141, 164
Troubleshooting wresource 107
Resource Manager problems 171 wweb 167
Web Gateway installation 156 wwebgw 116
TWG 5
twgapi component 169
typical problems 161
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


PDA Management with IBM Tivoli Configuration Manager
(0.2”spine)
0.17”<->0.473”
90<->249 pages

Back cover ®

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

Recommended

More Related Content

What's hot (15)

Viewers also liked (19)

Similar to Pda management with ibm tivoli configuration manager sg246951 (20)

More from Banking at Ho Chi Minh city (20)

Recently uploaded (20)

Pda management with ibm tivoli configuration manager sg246951