SRVR Inst

SIEBEL eBUSINESS APPLICATIONS
SIEBEL SERVER
INSTALLATION GUIDE
SIEBEL 2000
VERSION 6.3.1
10PA1-SI00-06310
MAY 2001
Siebel Systems, Inc., 2207 Bridgepointe Parkway, San Mateo, CA 94404
Copyright © 2001 Siebel Systems, Inc.
All rights reserved. Published 2001
Printed in the United States of America
No part of this publication may be stored in a retrieval system, transmitted, or reproduced in any way, including
but not limited to photocopy, photographic, magnetic or other record, without the prior agreement and written
permission of Siebel Systems, Inc.
The full text search capabilities of Siebel eBusiness Applications include technology used under license from
Fulcrum Technologies, Inc. and are the copyright of Fulcrum Technologies, Inc. and/or its licensors.
Siebel, the Siebel logo, TrickleSync, TSQ, Universal Agent, and other Siebel product names referenced herein
are trademarks of Siebel Systems, Inc., and may be registered in certain jurisdictions.
Windows® is a registered trademark of Microsoft Corporation.
All other product names, marks, logos, and symbols may be trademarks or registered trademarks of their
respective owners.
U.S. GOVERNMENT RESTRICTED RIGHTS. Programs, Ancillary Programs and Documentation, delivered
subject to the Department of Defense Federal Acquisition Regulation Supplement, are “commercial computer
software” as set forth in DFARS 227.7202, Commercial Computer Software and Commercial Computer Software
Documentation, and as such, any use, duplication and disclosure of the Programs, Ancillary Programs and
Documentation shall be subject to the restrictions contained in the applicable Siebel license agreement. All
other use, duplication and disclosure of the Programs, Ancillary Programs and Documentation by the U.S.
Government shall be subject to the applicable Siebel license agreement and the restrictions contained in
subsection (c) of FAR 52.227-19, Commercial Computer Software - Restricted Rights (June 1987), or
FAR 52.227-14, Rights in Data—General, including Alternate III (June 1987), as applicable. Contractor/licensor
is Siebel Systems, Inc., 2207 Bridgepointe Parkway, San Mateo, CA 94404.
Proprietary Information
Siebel Systems, Inc. considers information included in this documentation and
in Siebel Online Help to be Confidential Information. Your access to and use of
this Confidential Information are subject to the terms and conditions of: (1) the
applicable Siebel Systems software license agreement, which has been executed
and with which you agree to comply; and (2) the proprietary and restricted
rights notices included in this documentation.
Siebel Server Install Guide
Contents
Introduction
Who Should Use This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-2
How This Guide Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-3
Sequence of Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-3
Other Books You Will Need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-4
What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-5
Additional Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-6
Contacting Siebel Technical Support . . . . . . . . . . . . . . . . . . . . . . . . Intro-7
Siebel Welcomes Your Comments . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-8
Chapter 1. Overview
About the Siebel Server Installation Guide . . . . . . . . . . . . . . . . . . . . . . 1-2
The Siebel Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Siebel Client Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Siebel eBusiness Application System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Siebel File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-12
Siebel Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-12
Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Useful Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Chapter 2. Preparing for the Installation

About This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
An Overview of the Installation Process . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Planning Your Siebel Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Deployment Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Sizing Your Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Version 6.3.1 Siebel Server Installation Guide iii

Contents
Grouping Your Siebel Servers Into Siebel Enterprise Servers . . . . . . . . . . . 2-9

Planning the Topology of Your Siebel Deployment . . . . . . . . . . . . . . . . . .2-10
Planning the Siebel Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Preparing the Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Creating Siebel Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Creating Siebel Accounts Under Windows NT . . . . . . . . . . . . . . . . . . . . 2-18
Creating Siebel Accounts Under UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . .2-21
Planning Port Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
RDBMS Installation and Configuration Planning . . . . . . . . . . . . . . . . . 2-24
Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
PART 1. Installing Central Dispatch and the Siebel

Gateway Server
Chapter 3. Installing Central Dispatch Under Windows NT

Pre-Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Reviewing Resonate Installation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Verifying Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Assigning the Virtual IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Assigning Static IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Verifying Network Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Post-Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Configuring Central Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10
Choosing a Scheduling Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Choosing a Load-Balancing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Reconfiguring Central Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Reinstalling Central Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
iv Siebel Server Installation Guide Version 6.3.1

Contents
Chapter 4. Installing Central Dispatch Under UNIX

Verifying Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Assigning a Virtual IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Verifying Network Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Configuring Central Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
Configuring Server Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13
Choosing a Scheduling Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14
Choosing a Load-Balancing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14
Reconfiguring Central Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14
Reinstalling Central Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16
Chapter 5. Installing the Siebel Gateway Server

Under Windows NT
Installing a Redundant Disk Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Creating a File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Reviewing the Use of Connection Brokering . . . . . . . . . . . . . . . . . . . . . . . 5-6
Verifying Gateway Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Chapter 6. Installing the Siebel Gateway Server Under UNIX

Installing a Redundant Disk Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Creating a File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Version 6.3.1 Siebel Server Installation Guide v

Contents
Reviewing the Use of Connection Brokering . . . . . . . . . . . . . . . . . . . . . . . 6-5

Verifying Gateway Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Starting the Gateway Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Configuring the Gateway Server for Automatic Start . . . . . . . . . . . . . . . . 6-12
PART 2. Installing the Siebel Server
Chapter 7. Installing the Siebel Server Under Windows NT

Verifying Siebel Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Configuring Database Connectivity Software . . . . . . . . . . . . . . . . . . . . . . 7-3
Verifying Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Verifying Central Dispatch Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Installing the Siebel Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Starting the Siebel Server NT Service . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Verifying the Siebel Server ODBC Data Source . . . . . . . . . . . . . . . . . . . . 7-18
Establishing Network Connectivity for Mobile Users . . . . . . . . . . . . . . . . 7-19
Enabling Siebel Server Component Groups . . . . . . . . . . . . . . . . . . . . . . 7-19
Troubleshooting Central Dispatch Timeout Errors . . . . . . . . . . . . . . . . 7-20
Chapter 8. Installing the Siebel Server Under UNIX

Verifying Siebel Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
vi Siebel Server Installation Guide Version 6.3.1

Contents

Verifying Central Dispatch Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Installing Siebel Server Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Creating Additional Servers Within an Existing Enterprise Server . . . . . . .8-19
Verifying the Siebel Server ODBC Data Source . . . . . . . . . . . . . . . . . . . . .8-22
Managing Siebel Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . .8-23
Configuring the Siebel Server for Automatic Start . . . . . . . . . . . . . . . . . . .8-23
Establishing Network Connectivity for Mobile Users . . . . . . . . . . . . . . . . .8-25
Enabling Siebel Server Component Groups . . . . . . . . . . . . . . . . . . . . . . .8-25
PART 3. Configuring and Installing the Siebel

Database Server
Chapter 9. Configuring the DB2 UDB for UNIX

and Windows NT
Database Sizing Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Database Layout Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
DB2 Database Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 9-5
DB2 Database Manager Configuration Parameters . . . . . . . . . . . . . . . . . . 9-6
DB2 Set Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
DB2 Database Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
Allocating Space in Your DB2 Database for Siebel Data . . . . . . . . . . . . . . .9-10
Physical Device Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10
Logical Device Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Allocating Sufficient DB2 Database Log Space . . . . . . . . . . . . . . . . . . . . . 9-11
Version 6.3.1 Siebel Server Installation Guide vii

Contents
Log File Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12

Using Bufferpools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
Temporary Tablespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
DB2 Database Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
DB2 Administration Tasks Before Installation . . . . . . . . . . . . . . . . . . . . . 9-13
Updating Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
Chapter 10. Installing the Siebel Database Server with DB2

UDB for UNIX and Windows NT
About This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Pre-Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Installing the Database Server Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4
Reviewing the Software Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7
Creating Tableowner and Administrator Accounts . . . . . . . . . . . . . . . . . . .10-8
Installing the Stored Procedures and User-Defined Functions . . . . . . . . . 10-10
Overriding Default Storage Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15
Testing the ODBC Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16
Installing the Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17
Executing the Database Server Installation Script . . . . . . . . . . . . . . . . . . 10-17
Importing the Siebel Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-23
Post-Installation Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28
Populating the Siebel File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28
Chapter 11. Configuring the DB2 UDB for OS/390

Database Server
Estimating DB2 Storage Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Database Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Physical Device Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
Logical Table Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
vii i Siebel Server Installation Guide Version 6.3.1

Contents
Database Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6

DB2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Choosing the Database Codepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Allocating Storage Space for Siebel Tables and Indexes . . . . . . . . . . . . . . . 11-8
Verifying and Correcting Index Key Length . . . . . . . . . . . . . . . . . . . . . . . . 11-9
Allocating Log Space for Siebel Transactions . . . . . . . . . . . . . . . . . . . . . . 11-9
Enhancing Database Performance With Bufferpools . . . . . . . . . . . . . . . . 11-10
Temporary Tablespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10
Partitioning Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
DB2 Administration Tasks Prior to Installation . . . . . . . . . . . . . . . . . 11-13
Configuring your DB2 Database Server . . . . . . . . . . . . . . . . . . . . . . . . . 11-13
Updating Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14
Configurable Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Chapter 12. Installing the Siebel Database Server with DB2

UDB for OS/390
Creating Security Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10
Testing the ODBC Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11
Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12
Creating the Database Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13
Editing the Table Group Configuration File . . . . . . . . . . . . . . . . . . . . . . .12-17
Creating the Siebel Database Schema . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18
Importing Seed Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-24
Creating and Validating Database Objects . . . . . . . . . . . . . . . . . . . . . . .12-28
Importing the Siebel Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-32
Populating the Siebel File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-36
Version 6.3.1 Siebel Server Installation Guide ix

Contents
Chapter 13. Migrating Customizations From Development

to OS/390 Production
Pre-Migration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4
Customizing Siebel for Your Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . 13-4
Migration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5
Generating the List of Invalid Objects Report . . . . . . . . . . . . . . . . . . . . . 13-5
Migrating Customizations from Development to the Target Database . . . . 13-10
Modifying the Siebel Schema on the Target Database . . . . . . . . . . . . . . .13-15
Validating the Target Database Against the Source Repository . . . . . . . . .13-18
Post-Migration Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-22
Chapter 14. Configuring the Oracle Database Server

Database Sizing Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
Database Layout Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
Database Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
Oracle Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
Allocating Space in Your Oracle Database for Siebel Data . . . . . . . . . . . . 14-9
Database Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10
Pre-Installation Administration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10
Post-Installation Administration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . .14-12
Chapter 15. Installing the Siebel Database Server with Oracle

Database Server Scripts Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4
Installing the Database Server Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4
Reviewing the Software Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-7
Creating Tableowner and Administrator Accounts . . . . . . . . . . . . . . . . . . 15-7
Overriding Default Storage Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 15-8
Testing the ODBC Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-9
x Siebel Server Installation Guide Version 6.3.1

Contents

Executing the Database Server Installation Script . . . . . . . . . . . . . . . . . . 15-10
Editing the Database Installation Script . . . . . . . . . . . . . . . . . . . . . . . . . 15-11
Running the Database Installation Script . . . . . . . . . . . . . . . . . . . . . . . .15-13
Reviewing the Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-15
Populating the Siebel File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-21
PART 4. Installing CORBA
Chapter 16. Installing CORBA Under Windows NT

Verifying Siebel Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3
Configuring Database Connectivity Software . . . . . . . . . . . . . . . . . . . . . .16-3
Verifying Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5
Installing the CORBA Object Manager . . . . . . . . . . . . . . . . . . . . . . . . 16-7
Post-Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10
Setting Up the Object Request Broker in Persistent
and Shared Server Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10
Registering Multiple Object Managers for Better Performance . . . . . . . . .16-14
Chapter 17. Installing CORBA Under UNIX

Verifying Siebel Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-3
Configuring Database Connectivity Software . . . . . . . . . . . . . . . . . . . . . .17-4
Managing Siebel Environment Variables . . . . . . . . . . . . . . . . . . . . . . 17-10
Version 6.3.1 Siebel Server Installation Guide xi

Contents

PART 5. Installing and Configuring Siebel Thin Clients
Chapter 18. Thin Client Network Requirements

Accessing Siebel Thin Clients From Outside a Firewall . . . . . . . . . . . . . 18-2
Firewall Requirements in a Load-Balanced Environment . . . . . . . . . . . . . 18-2
Firewall Requirements in a Non-Load-Balanced Environment . . . . . . . . . 18-3
Accessing HTML Thin Clients from Outside a Firewall . . . . . . . . . . . . . 18-4
HTML Thin Client Firewall Configuration . . . . . . . . . . . . . . . . . . . . . . . 18-5
Browser to Web Server Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-6
Web Server Extension to Application Object Manager Connection . . . . . . 18-7
Firewall Requirements in a Load-Balanced Environment . . . . . . . . . . . . . 18-7
Firewall Requirements in a Non-Load-Balanced Environment . . . . . . . . . 18-8
Chapter 19. Editing Siebel Thin Client for Windows Files

About Siebel Thin Client for Windows . . . . . . . . . . . . . . . . . . . . . . . . 19-2
Browser Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2
Stand-Alone Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2
Verifying the Siebel Enterprise Server . . . . . . . . . . . . . . . . . . . . . . . . . . 19-3
Editing the Browser-Mode Startup Files . . . . . . . . . . . . . . . . . . . . . . . 19-4
Internet Explorer Client Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-5
Netscape Communicator Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-9
Sharing Thin Client Startup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-10
xii Siebel Server Installation Guide Version 6.3.1

Contents
Chapter 20. Installing and Configuring the .COM Applications

Under Windows NT
Planning the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-3
Verifying the Siebel Enterprise Server . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5
Verifying .COM Application Requirements . . . . . . . . . . . . . . . . . . . . . . . .20-5
Installing the Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5
Installing .COM Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-6
Review Installation Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-11
Editing the .COM Applications Configuration File . . . . . . . . . . . . . . . . . . 20-12
Services You Must Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-18
Chapter 21. Installing and Configuring the .COM Applications

Under UNIX
Planning the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-3
Granting User Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-4
Verifying the Siebel Enterprise Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-5
Verifying .COM Application Requirements . . . . . . . . . . . . . . . . . . . . . . . . 21-5
Installing the Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-5
Review Installation Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-13
Setting the LATCH Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . 21-14
Configuring iPlanet to Accept Siebel .COM Applications . . . . . . . . . . . . . 21-22
Shell Scripts You Must Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-23
Running the IBM HTTP Server and Siebel Web Companion . . . . . . . . . . 21-23
Version 6.3.1 Siebel Server Installation Guide x iii

Contents
PART 6. Installing and Configuring the Report Server
Chapter 22. Installing the Siebel Report Server

Under Windows NT
Siebel Report Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-2
Siebel Report Server Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-3
Installing Actuate ReportCast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-4
Installing Actuate e.Reporting Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-5
Installing Siebel Report Server Access . . . . . . . . . . . . . . . . . . . . . . . . . . 22-8
Installing Actuate Administrator Desktop . . . . . . . . . . . . . . . . . . . . . . . .22-12
Installing Actuate Developer Workbench . . . . . . . . . . . . . . . . . . . . . . . .22-13
Installing Actuate e.Report Designer . . . . . . . . . . . . . . . . . . . . . . . . . . .22-15
Enabling the Report Server for Use With a Client . . . . . . . . . . . . . . . . . .22-16
Testing Siebel Report Server on the Client . . . . . . . . . . . . . . . . . . . . . . .22-18
Editing Repository Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-19
Chapter 23. Installing the Siebel Report Server

Under UNIX
Pre-Installation Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-2
Installing Actuate ReportCast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-2
Installing Actuate e.Reporting Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-4
Installing Siebel Report Server Access . . . . . . . . . . . . . . . . . . . . . . . . . . 23-5
Enabling the Report Server for Use with a Client . . . . . . . . . . . . . . . . . . 23-10
xiv Siebel Server Installation Guide Version 6.3.1

Contents
PART 7. Uninstalling Siebel eBusiness Applications
Chapter 24. Uninstalling Siebel eBusiness Applications

Uninstalling Siebel eBusiness Applications Under Windows NT . . . . . . 24-2
Uninstalling Siebel eBusiness Applications Under UNIX . . . . . . . . . . . . 24-4
Migrating to a New Software Version or a New Database Platform . . . . . 24-4
Appendix A. Deployment Planning Worksheet

Appendix Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Master Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Team Lead Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Enterprise Server Names and Installation Directories . . . . . . . . . . . . . . . . A-3
Siebel Accounts, VIPs, and Static IPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
Ports and RDBMS Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
Appendix B. DB2 UDB for OS/390 Tablespace and

Table Group Configuration Worksheet
Index
Version 6.3.1 Siebel Server Installation Guide xv

Contents
xvi Siebel Server Installation Guide Version 6.3.1

Introduction
Who Should Use This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-2
How This Guide Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-3

Sequence of Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-3
Other Books You Will Need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-4
What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-5
Additional Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-6
Contacting Siebel Technical Support . . . . . . . . . . . . . . . . . . . . . . . . Intro-7
Siebel Welcomes Your Comments . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-8
Version 6.3.1 Siebel Server Installation Guide I n tr o - 1

Introduction
Who Should Use This Guide
Who Should Use This Guide Intro
This guide provides information, instructions, and guidelines for installing your
Siebel eBusiness Applications product.
The audience for this guide consists of:
Siebel System Persons responsible for the whole system, including installing,
Administrators maintaining, and upgrading Siebel products.
Database Persons who administer the database system, including data
Administrators loading; system monitoring, backup, and recovery; space
allocation and sizing; and user account management.
Installers Persons responsible for setting up Siebel systems for initial use. An
installer is typically a system administrator, a database
administrator, or someone from the Information Services
department.
Configurators Persons responsible for planning, implementing, and configuring
Siebel applications. A configurator is typically a consultant or
someone from the Information Systems department.
In t ro - 2 Siebel Server Installation Guide Version 6.3.1

Introduction
How This Guide Is Organized
How This Guide Is Organized Intro
This guide provides information that is necessary to install Siebel Server and Client
applications. It is organized to provide a logical and sequential explanation of the
steps necessary to install Siebel software.
Each chapter is devoted to a different topic. Except for Chapter 1, “Overview,” and
Chapter 2, “Preparing for the Installation,” the material in this book is divided into
parts that focus on particular types of installations. To make the best use of this
manual, read Chapter 1 and Chapter 2 first.
Sequence of Installation Intro
The chapters on the installation of individual components appear in the order in

which these components should be installed. For example, you cannot install the
Siebel Server until you have installed the Siebel Gateway Server since installation
of the former requires that the latter be already installed and started. Likewise, if
your organization intends to take advantage of the connection-brokering features of
Resonate Central Dispatch, Siebel Systems strongly recommends that you install
this product before you install the Siebel Gateway and Siebel Servers. And, while
the configuration of your database, and the installation and execution of the Siebel
Database Server scripts must also be performed in the sequence in which these
chapters appear, you obviously need only read the chapters that apply to your own
RDBMS.
At the beginning of each chapter is a section titled “About This Chapter,” which
covers information you will need if you are responsible for the part of the
installation process covered in that chapter.

Introduction
How This Guide Is Organized
Other Books You Will Need Intro
When you need to refer to outside documentation, you will find specific
information about what you should read and where. For example, there are several
junctures within the installation process that will require you to refer to the Siebel
Client Installation and Administration Guide and the Siebel Server Administration
Guide to complete the instructions provided in this guide.
In other instances, you will be asked to refer to third-party documentation; for

example, if you are installing Central Dispatch to provide connection brokering for
your site. This guide will, in such cases, will provide instructions, should Siebel
eBusiness Applications installation require you to input particular information to
enable the installed third-party software to function properly with Siebel eBusiness
Applications.

Introduction
What’s New in This Release
What’s New in This Release Intro
Version 6.2 of Siebel eBusiness Applications has the following new features:
Feature Description
AIX UNIX support Supports the AIX UNIX platform at mid-tier for the Siebel
at mid-tier Gateway and Siebel Servers. Installation of the Siebel
Gateway and Siebel Server on the AIX platform is identical
to previous installation instructions for the Solaris
platform. Installation instructions particular to AIX users
can be found in Chapter 21, “Installing and Configuring the
.COM Applications Under UNIX” and Chapter 23,
“Installing the Siebel Report Server Under UNIX.”
IBM HTTP Server Supports use of IBM HTTP Server for use by customers
support working on the AIX UNIX platform. For information, see
Chapter 21, “Installing and Configuring the
.COM Applications Under UNIX.”
UTF-8 UNICODE Supports use of UTF-8 UNICODE for the Oracle 8i
support on the Enterprise Server. For information, see Chapter 14,
Oracle RDBMS “Configuring the Oracle Database Server.”
Your Siebel implementation may not have all the features described in this guide,
which documents all features of all available configurations or platforms. Your
system will have the features provided by the software modules you have
purchased.
Because all versions of the UNIX operating system are case-sensitive, if you are
running your Siebel eBusiness Applications under UNIX, treat all filenames,
directory names, pathnames, parameters, flags, and command-line commands as
lowercase, unless you are instructed otherwise in the product.
If you currently run under Windows NT, but may switch to a UNIX environment at
some time in the future, it is a good idea to follow this same practice.
If you are running under IBM’s OS/390, you will want to make sure that these file
names, pathnames, parameters, and flags are all uppercase.

Introduction
Additional Documentation
Additional Documentation Intro
The following documentation also provides information on the topics addressed in

this guide:
Siebel Applications Administration Guide

Siebel Client Installation and Administration Guide
Siebel Enterprise Integration Manager Administration Guide
Siebel Release Notes
Siebel Server Administration Guide
Siebel System Requirements and Supported Platforms
Siebel Release Notes provide the most up-to-date installation information and
supplemental instructions, as well as other useful information unavailable at the
time of printing for this Siebel Server Installation Guide. Siebel System Requirements
and Supported Platforms describes system requirements and supported platforms.
This guide does not provide information about installing Siebel components on a
dedicated client; general software concepts, such as records and queries; or using
Windows and UNIX. Neither does it provide instructions for basic navigation of
Siebel applications. For instructions on how to install Siebel on a dedicated client,
refer to the Siebel Client Installation and Administration Guide. For general
concepts about Siebel applications, refer to Siebel Basics.
Administrators and developers, such as marketing administrators, call center

administrators, and application developers, should also read the Siebel Applications
Administration Guide for information on how to set up and maintain Siebel
applications features.
For copies of these documents, please use Siebel Books Online, accessible through
the Global Services tab on the Siebel Systems Web site
(http://www.siebel.com). Through Siebel Books Online, you can order
additional Siebel documentation and copies of the Bookshelf for Siebel eBusiness
Applications CD-ROM.
For the most current and accurate documentation, see the Documentation Updates
section of the Siebel SupportWeb site (http://supportweb.siebel.com). The
SupportWeb page contains changes that we have made to the documentation since
it was released.

Introduction
Contacting Siebel Technical Support
Another source of information is the Siebel Online Help Developers Guide.
You will find information about Siebel Technical and Professional Services in the
Guide to Siebel Global Services.
Contacting Siebel Technical Support Intro
Do you know how to access Siebel Technical Support? It is crucial that you
understand the requirements for getting support before you encounter technical
issues that require Siebel Technical Support’s assistance. This will facilitate smooth
resolution of any issues. If you have questions, please do not hesitate to contact us.
To maximize your knowledge of Siebel products and your return on investment:
You must attend Siebel training to become a designated contact.

Your Siebel-trained designated contacts provide technical support to your users.
Siebel Technical Support provides support to your designated contacts only.
To provide efficient and timely support, and to empower you in the process:
Siebel Technical Support is primarily Web-based, accessed through Siebel

SupportWeb (http://supportweb.siebel.com). Please submit new
service requests to us through SupportWeb, where you can also search the
knowledge base for solutions.
Designated contacts receive read/write access to SupportWeb. All other project

team members at your company receive a read-only account to ensure they can
reap the benefits of the support knowledge base.
To register for Siebel training, please access http://www.siebel.com/

education/ and choose Implementation Team Training.
Please submit your technical issues and updates to Siebel SupportWeb (http://
supportweb.siebel.com). If you do not have a SupportWeb account, or if you
have a question, please contact us at suppor@siebel.com or call your local Siebel
Support Center below:
North America: +800 214 0400 or +1 650 295 5724

Brazil: +55 11 5110 0800
UK (London): +44 (0) 800 072 6787 or +44 (0) 1784 494949

Introduction
Siebel Welcomes Your Comments
Germany (Munich): +49 89 957 18 400

France (Paris): +00 +800 - 21 40 40 04
Japan (Tokyo): 0120 606 750 (Japan domestic only)
+81 3 5469 3811 (outside of Japan)
Singapore: +65 320 8533
Outside of local support center hours, Gold and Rollout Support Option customers
can call +1 800 214 0400 or +1 650 295 57 24.
We appreciate your business and look forward to working with you.
Siebel Welcomes Your Comments Intro
To help us with future versions, we want to know about any corrections or

clarifications that you would find useful. Please include in your message:
The title and version of this guide

Your name, your company name, your job title or functional area, your
telephone number, and your email address
Write to us through regular mail or email at:
Siebel Systems, Inc.

Technical Publications Department
2207 Bridgepointe Parkway
San Mateo, CA 94404-5009
doc@siebel.com
We appreciate your feedback.

Overview 1
About the Siebel Server Installation Guide . . . . . . . . . . . . . . . . . . . . . . 1-2
The Siebel Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Siebel Client Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Siebel eBusiness Application System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Siebel File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-12
Siebel Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Useful Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Version 6.3.1 Siebel Server Installation Guide 1-1

Overview
About the Siebel Server Installation Guide
About the Siebel Server Installation Guide 1
This guide provides information and instructions for installing your Siebel
Enterprise Server components.
A successful installation requires:
Familiarity with the basic conventions of Microsoft Windows NT or the

supported UNIX operating system under which your Siebel Servers will run.
Familiarity with the Windows platform (Windows 95, Windows 98, or Windows
NT) under which your Siebel Dedicated Clients will run.
Expertise in network connectivity, disk and file sharing, and software

installation on your chosen application server and client operating systems.
User accounts with administration privileges under NT or appropriate access

under UNIX to do the installations.
Expertise in database installation, tuning, and administration in your chosen

relational database management system (RDBMS).
The guide also explains how to install your Siebel application on several databases,
operating system, and application server platforms. However, specific database and
operating system platforms, as well as certain combinations of them, may not be
supported in the current release. For a list of all operating system platforms and
RDBMS products supported by this release, consult Siebel Release Notes and Siebel
System Requirements and Supported Platforms, included with your Siebel product.
1-2 Siebel Server Installation Guide Version 6.3.1

Overview
The Siebel Environment
The Siebel Environment 1
This chapter contains an overview of your Siebel application and how it works.
Below is a summary of the entities that make up the Siebel eBusiness Applications.
In the following sections are a diagram that illustrates the architecture of a Siebel
deployment and, following that, detailed descriptions of each type of server and
client.
The Siebel eBusiness Applications environment includes the following:
The Siebel Gateway Server. The Gateway Server, as its name suggests, handles
connections between clients and servers in a Siebel deployment. The Gateway
Server consists of the Name Server and optional Resonate Central Dispatch
servers.
The Siebel Server. A Siebel Server, depending on which Siebel components are
installed on it, manages one or more components of the Siebel application. One
or more of these servers provides both batch mode and interactive services to
Siebel clients.
NOTE: A group of Siebel Servers that may be administered and configured

collectively is called a Siebel Enterprise Server—the Siebel Enterprise Server is
not a separate type of server.
The Siebel Database Server. The database server stores your business data in a set
of predefined tables and provides that data to Siebel Servers and dedicated
clients on request.
The Siebel File System. This is a network-accessible hard disk directory tree that
stores the files used by Siebel clients that the database does not manage.
Siebel Clients. Siebel Clients provide the interface for accessing data managed by
the Enterprise Server. Siebel clients include dedicated clients, mobile clients, and
thin clients of several different types.

Overview
Figure 1-1 is a logical diagram of the entities that make up the Siebel eBusiness
Applications environment.
Application Web Browser/ Application

Application
Dedicated Mobile
Client Thin Client Client
Siebel Enterprise Server
Siebel Gateway Server and Name Server

Resonate
Application
Server Manager
Siebel Siebel Siebel

Server Server Server
Siebel File
System
Siebel
Database
Figure 1-1. Logical Diagram of the Siebel eBusiness Applications Environment
You can deploy a mixture of dedicated, mobile, and thin clients. In addition to these
Siebel clients for individual users, you will need to install and configure one Siebel
dedicated client to be used as the server manager to administer the servers.

Overview
As you can see in Figure 1-1 on page 1-4, all Siebel eBusiness Applications
installations consist of the following four functional parts:
Siebel Clients
Siebel Enterprise Server (consisting of one or more Siebel Servers and one Siebel
Gateway Server)
Siebel Database Server

Siebel File System
The Siebel Gateway Server stores persistent and dynamic configuration information
for the Siebel Servers. It also provides optional load balancing services, which
distribute client requests for certain Enterprise Server components across multiple
Siebel Servers.
The various Siebel clients connect to various servers (depending on the type of
client) to request data and analyze it in a wide variety of ways. Each of the Siebel
eBusiness entities is discussed in detail in the sections that follow.

Overview
Siebel Client Types 1
The Siebel client is a computer that operates the Siebel Sales, Call Center, Field
Service, and/or Marketing client applications, accessing data and services from one
or more servers.
Siebel eBusiness Applications supports two types of clients:
Dedicated client. The dedicated client (also known as the Siebel client and the
connected client) can operate in two modes:
Dedicated mode. Connects directly to the Siebel Database Server and the
Siebel File System. The dedicated client may also interact with Enterprise
Server components for additional functionality. A dedicated client does not
store any Siebel data locally.
Mobile mode. Makes use of a local database. The mobile client (typically a
laptop computer used by a field sales or service representative) operates
without a real-time connection to any of the servers. The mobile client
downloads a portion of the Siebel Database and the Siebel File System to the
laptop so that users access the data locally. The mobile client periodically
accesses the Siebel Server by a dial-up, WAN, or LAN connection to
synchronize data changes with the Database Server and File System.
Thin client. Siebel thin clients run inside a standard Web browser from the client
PC, or (in the case of the Java Thin Client) are invoked through the Web browser,
but run in an independent window. Like the dedicated client, thin clients do not
store data locally. Unlike the dedicated client, thin clients connect directly to the
enterprise server and, in some cases, the Web server, but not to any other server.
The Siebel Server executes all business logic for the thin client.

Overview
Siebel eBusiness Application System 1
A Siebel eBusiness Applications system contains several types of servers, a number

of clients, and a dedicated file system:
Siebel Clients
Siebel Enterprise Server (consisting of one or more Siebel Servers and a Siebel
Gateway Server)

Siebel File System
Siebel Gateway Server

The Siebel Gateway Server is a logical entity consisting of the Name Server and, for
systems with connection brokering installed, the Resonate Central Dispatch
Scheduler. Together, they coordinate the work of the Siebel Servers within the
Enterprise. The Gateway Server provides enhanced scalability, load balancing, and
high availability across the Enterprise Server.
Name Server
The Name Server provides persistent backup storage of the configuration
information for all Siebel Servers within the Siebel Enterprise Server group or
groups it supports, including component definitions and assignments, operational
parameters, and connectivity. As this information changes—for example, during the
installation of a Siebel Server or as the Siebel Server is configured through the
Server Manager—the configuration information is written to the Name Server.
When starting up, the Siebel Server obtains its configuration information from the
Name Server.
On the Windows NT platform, the Name Server is installed as a Windows NT

Service, controlled through the NT Services Control Panel. On UNIX platforms, the
Name Server operates as a daemon, or an independent background process.
Only one Name Server exists for each Siebel deployment. Siebel supports the high-
availability features of some platforms to ensure high availability of the Name
Server.

Overview
Connection Brokering and Resonate Central Dispatch

Connection brokering delivers scalability and high availability for mission-critical
server components by balancing load across Siebel Servers under an Enterprise
Server to make the best use of available resources. When connection brokering is
implemented, Resonate’s Central Dispatch product monitors the CPU utilization on
your Siebel Servers in real time. It uses that and your server configuration to
determine the optimal server for any new connection.
The Resonate Central Dispatch product consists of two software components:
Scheduler. Brokers Siebel connection requests across Siebel Servers and also
monitors the load of each Siebel Server.
Dispatch Manager. As a GUI configuration tool, configures and manages the

scheduler.
Central Dispatch does not require dedicated server hardware; its components are
installed on all application servers that will support a Siebel Server or a Siebel
Gateway Server.
NOTE: For best system performance and availability, Siebel Systems recommends
that you install the primary scheduler on one dedicated application server that does
not run any other Siebel components.
The primary scheduler performs all connection brokering unless it becomes

unavailable, in which case a secondary scheduler operating on another server
transparently assumes control so that brokering continues uninterrupted.
In version 6.x, the Siebel Gateway Server can provide connection brokering for the
following client connections to Siebel Server components:
Connections from all Siebel Thin Clients or the Siebel Web Engine.
Siebel Dedicated Client requests to the Request Processor or Request Agent
server components, which provide interactive access to the Assignment
Manager and other server components.

Overview
These clients are referred to in the remainder of this document as connection-

brokered Siebel clients. If your Siebel implementation will include one or more of
these clients and multiple Siebel Servers, you should make use of connection
brokering in your implementation. Connection brokering is supported on both the
Windows NT and UNIX Enterprise Server platforms.
When Central Dispatch is installed, connection-brokered Siebel clients are not

configured to connect directly to a specific Siebel Server. Instead, they connect to a
virtual IP address (VIP), a logical address operated by the Resonate scheduler,
which, in turn, brokers connections from these addresses to the real addresses of
the Siebel Servers.
NOTE: One Siebel Gateway Server can support multiple Siebel Enterprise Servers,
but Siebel Systems does not recommend this except for development and test
environments due to possible impact on system availability and performance.
Siebel Servers are fully integrated with the Central Dispatch scheduler. The
configuration information that the Gateway Server uses to broker connections is
automatically updated as Siebel Servers are started or stopped, or as their
configurations are modified.

The Siebel Enterprise Server is a logical entity that allows the management of one
or more Siebel Servers as a single system. Using a single Enterprise-wide command,
a Siebel Administrator can configure, manage, and monitor related Siebel Servers as
a single logical group. All these tasks can be accomplished centrally from a single
workstation.
All Siebel Servers that connect to a common database must be installed within the
same Enterprise Server; that Enterprise Server can support only that single database
and the Siebel Servers connected to it.
The Enterprise Server itself has no processes and hence cannot have a state.
However, start and stop operations can be executed at the Enterprise level to apply
to all Siebel Servers within the Enterprise.

Overview
Siebel Server
Each Siebel Server is part of an Enterprise Server consisting of at least itself. The
Siebel Server supports both back-end and interactive processes for all the Siebel
eBusiness Applications clients.
The Siebel Server itself is an NT Service (under Windows NT) or a daemon, (a

background shell process) under UNIX. The Siebel Server supports both
multiprocess and multithreaded components and can operate components in batch,
service, and interactive modes.
Many of the Siebel Server components are multithreaded, and multiple instances of
components can run on multiple Siebel Servers simultaneously to support increased
numbers of users or larger batch workloads. The Siebel Server Manager, discussed
in the next section, allows the Siebel Administrator to modify the parameters
governing the operation of each component and to determine on which Siebel
Servers a given component can operate.
Siebel Server Manager

The Siebel Server Manager is a Siebel client workstation configured to allow the
Siebel administrator to administer the Siebel Servers within an Enterprise Server
and to monitor the status of the various server components and component tasks.
Use the Server Manager to perform the following tasks:
Start, stop, pause, and resume Siebel Servers, components, and tasks.
Monitor status and collect statistics for all multiple tasks, components, and
Siebel Servers within an Enterprise.
Configure the Siebel Enterprise Server, individual Siebel Servers within the
Enterprise, individual components, and tasks.
Operate the Server Manager through one of two interfaces:
The graphical user interface, or GUI—through the Server Administration views

of the Siebel eBusiness Applications client.
The command-line interface.

Overview
The Siebel Server Manager can be installed on the following:
The Siebel administrator's workstation, running as part of the dedicated

client GUI.
Any server or other machine that uses the command-line version for automating
control of the Enterprise Server.
On Windows NT–based systems, the Server Manager GUI should be used for most
administrative duties. The GUI offers a more intuitive view into the operation of the
Siebel Servers than the command-line interface. For customers with Windows-only
servers and clients, the GUI provides the only administration option.
For customers using Windows clients and UNIX servers, a Windows client can still
be used to administer the Siebel Server. To administer Siebel Servers directly from
a supported UNIX system, you will need to use the command-line interface.
Customers using only UNIX servers and clients will use only the UNIX command
line tool.
The command-line interface is particularly well suited to batch-mode processing

and may be invoked from batch or shell scripts. The command-line interface can be
used to invoke script files with administration commands that need to be run on a
regular basis. For more information on the Server Manager, see the Siebel Server
Administration Guide.
When the Server Manager is invoked, it connects to the Siebel Gateway Server,
which knows exactly what each of the Siebel Servers in the Enterprise is doing,
which clients are connected to which servers, and which servers are available to
handle new connections. It retrieves the information it needs, and then connects
with each of the Siebel Servers in the Enterprise and starts an Administration
Manager component task.
The Administration Manager task on each Siebel Server handles administration

commands from the Server Manager, executes the requested functions, and returns
the result of each operation directly to the Server Manager.

Overview
Siebel File System 1
The Siebel File System is a network-accessible directory located on an application

server. It stores all the physical files created by Siebel eBusiness Applications,
including Marketing Encyclopedia items, correspondence, proposal and
presentation templates, and file attachments, except for the actual data stored in the
database.
All files in the Siebel File System are compressed and stored using a specialized
naming convention. Users should never access files directly from the File System.
Instead, these are manipulated through the Siebel client, which automates the
compression and naming tasks. When these files are initially accessed, they may
take longer to display because they must first be decompressed. Once opened, an
uncompressed file is cached, and its subsequent display will be faster.
Siebel Dedicated Clients read and write files directly to and from the Enterprise’s
File System. Siebel Mobile Clients have a local File System, which they synchronize
with the server-based File System periodically. Siebel Thin Clients access the File
System through the Siebel Server.
All files in the File System are stored in a single directory and are distinguished by
filename prefix.
Siebel Database Server 1
The Siebel Database Server stores the data used by Siebel eBusiness Applications.
Siebel eBusiness Applications supports several popular relational database
management systems (RDBMSs); the Siebel Database Server scripts configure the
database automatically. Siebel dedicated clients and Siebel Server components,
including those that operate in conjunction with the Siebel Thin Client, connect
directly to the Database Server and make changes in real time. Siebel Mobile Clients
download a subset of the server’s data to use locally, and periodically synchronize
with the Database Server through the Siebel Server to update both.

Overview
Before You Start
Before You Start 1
Before you start your Siebel installation, complete the following steps:
1 Carefully read Chapter 2, “Preparing for the Installation,” and fill out the
Deployment Planning Worksheet. A master copy of the Deployment Planning
Worksheet is located in Appendix A, “Deployment Planning Worksheet.” You
should photocopy this and fill out the copy as instructed.
2 Carefully read the relevant server installation chapters in this guide to ensure
that you understand the complete installation process for your operating system
and RDBMS platform combination.
3 Carefully read the relevant client installation chapters in Siebel Client

Installation and Administration Guide for those Siebel clients you plan to install.
4 Read the Siebel System Requirements and Supported Platforms and Siebel Release
Notes to be sure you know the supported computer and operating system
platforms and supported third-party programs for this release of your Siebel
application and for last-minute information.
5 Prepare a comprehensive installation schedule that includes a timeline for

completing specific pre-installation and post-installation tasks, including
thorough testing of the Siebel environment.

Overview
Useful Resources
Useful Resources 1
Your Siebel implementation team will perform a number of actions to install and
implement your Siebel application and will use several different Siebel documents
in the process:
This guide for installation and configuration instructions.

Siebel System Requirements and Supported Platforms and Siebel Release Notes for
system requirements, supported platforms, and updated information that this
guide does not contain.
The Siebel Server Administration Guide for advanced configuration information

and details on how to administer, maintain, and expand your Siebel application.
If you are upgrading an existing Siebel deployment, you will need the Siebel
Upgrade Guide as well. If you have licensed Siebel Tools, you will find information
about configuring Siebel eBusiness Applications in the Siebel Tools Guide and the
Siebel Configuration Concepts Guide.

Preparing for the Installation 2
An Overview of the Installation Process . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Planning Your Siebel Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Deployment Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Sizing Your Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Grouping Your Siebel Servers Into Siebel Enterprise Servers . . . . . . . . . . . 2-9
Planning the Topology of Your Siebel Deployment . . . . . . . . . . . . . . 2-10
Planning the Siebel Directory Structure . . . . . . . . . . . . . . . . . . . . . 2-13
Preparing the Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Creating Siebel Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17

Creating Siebel Accounts Under Windows NT . . . . . . . . . . . . . . . . . . . . .2-18
Creating Siebel Accounts Under UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . .2-21
Planning Port Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
RDBMS Installation and Configuration Planning . . . . . . . . . . . . . . . . . 2-24
Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24

Preparing for the Installation
About This Chapter
About This Chapter 2
This chapter provides the preparation steps you must take before you begin
installing Siebel eBusiness Applications software. It also introduces you to the
Deployment Planning Worksheet, an integral part of the installation process.
Before proceeding, turn to Appendix A, “Deployment Planning Worksheet,” and

make a photocopy of the worksheet. Using the copy, the person in charge of the
deployment effort should fill out the first section. Members of the team should fill
out the information in the sections for which they are responsible.
As you work through the preparation steps in this chapter, you will be prompted to
record specific information you will need while installing and configuring Siebel
eBusiness Applications at your site.
In subsequent chapters, you will be prompted to refer to Appendix A, “Deployment

Planning Worksheet,” for specific information about your site and deployment. You
will also use it to record other important information for future installations,
upgrades, reconfiguration, and expansion of your deployment.

An Overview of the Installation Process
An Overview of the Installation Process 2
The installation process consists of several steps:
1 Preparing for the installation.

2 Installing the Siebel Gateway Server.
a Installing the Resonate Central Dispatch product (optional).
b Installing the Gateway Server itself. (This includes the Name Server.)
3 Installing the Siebel Dedicated Client (described in the Siebel Client Installation
and Administration Guide).
4 Creating an Enterprise Server and installing one or more Siebel Servers.

5 Configuring and installing the Siebel Database Server with your choice of
RDBMS software.
6 Installing the CORBA Object Manager (optional).

7 Installing the Siebel Thin Client Applications (optional).
8 Installing the Siebel Report Server (optional).

An Overview of the Installation Process
Siebel components should be installed in the sequence in which they are introduced
in this book and illustrated in Figure 2-1.
Prepare for the

Start
Installation
Install Central Yes Install Central

Dispatch Dispatch?
No
Install Siebel
Gateway Server
Install Siebel
Server(s)
Install Siebel
Dedicated Client
Install Siebel Yes

Install CORBA? Install CORBA
Database Server
No
Yes
Install Web Server Install Web Server ?
No
Install Thin Client Yes

Install Thin Client
Components?
No
Finish Install Report

Server
Legend Mandatory Step Optional Step Decision Beginning/End
Figure 2-1. Installing the Siebel Server and Associated Software

Planning Your Siebel Deployment
Planning Your Siebel Deployment 2
A successful installation of Siebel eBusiness Applications requires considerable

preparation. First, you will need to determine the following:
Who will be on the deployment team.

How many overall users, and how many different groups, you will need to
support.
For each Enterprise Server you install:

Which operating system will you use on the servers for this enterprise—
Microsoft Windows NT or a supported UNIX version?
How many different Siebel Servers your Enterprise will need, and what
services will they provide? (Read about dedicating Siebel Servers for specific
services under “Dedicating Siebel Servers for Specific Services” on page 2-8.)
Will you need to install connection brokering to manage this enterprise

effectively? (Read about connection brokering under “Connection Brokering
and Resonate Central Dispatch” on page 1-8.)
If installing on the Microsoft Windows NT platform, do you want to install

the Siebel Enterprise Server components in a Microsoft Cluster Server
environment? (For installation instructions on this, refer to Technical Note
213 on the Siebel Technical Support website at http://www.siebel.com/
worldwide-services/ts.html.)
If so, do you want to co-locate these components all on one node, or to

distribute them over multiple clusters?
How many computers will you need to run the different servers your
enterprise will require? (Read about planning the number and types of
servers you deploy under “Planning the Topology of Your Siebel
Deployment” on page 2-10.)
Where to locate the servers for best connectivity and maintenance. (Read about
planning the layout of your servers also under “Planning the Topology of Your
Siebel Deployment” on page 2-10.)

Whether you will deploy CTI (computer telephony integration).

What types of clients you will install? In other words, decide how many clients
will be dedicated, how many will be thin clients, and how many will be mobile.
(For more information on choosing client types, see the Siebel Client Installation
and Administration Guide.)
Deployment Team 2
Your deployment team should include:
A deployment team lead.

An experienced system administrator to determine what resources, in addition
to the Siebel eBusiness Application itself, will be needed for your site. The
system administrator will also plan and implement the actual installation.
An experienced database administrator to assist in determining the proper

servers and setup for the database, and to configure the database server after it
is installed.
Write this information down in the copy you have made of Appendix A,
“Deployment Planning Worksheet.”
Sizing Your Installation 2
After you have determined which Siebel environments you will install, you must
determine:
Which relational database management system (RDBMS) you will use.

How many Siebel Servers you will need to connect to a database through a single
Siebel Enterprise Server.
On which machines and under which directory you want to install Siebel
components.
You should direct further sizing questions to your Siebel TAM (technical account
manager) or to Siebel Expert Services. For more information, see also the Siebel
Guide to Technical Services.

Selecting Your RDBMS Server

Determine which relational database management system (RDBMS) you will use
with your Siebel application and what computer platform to run it on.
Verify which RDBMS products, versions, and patch levels are supported, check
Siebel System Requirements and Supported Platforms.
Choose the platform on which your database server will run, consult your
RDBMS manufacturer’s documentation and Siebel System Requirements and
Supported Platforms to determine which platforms are supported and what
issues must be addressed.
NOTE: No more than one RDBMS platform can exist within an enterprise. For
example, you cannot run both the Oracle and DB2 UDB databases.
When you have determined which RDBMS you will use, check off the proper choice
in Section 2: Deployment Overview on page A-2.
Planning Your Siebel Environments

Determine how many Siebel environments you will support, and what kind. Siebel
Systems recommends that you install at least three environments:
Production environment. Your live Siebel operational environment.
Development environment. For developing customized applications and

configurations.
Test environment. For testing customized application configurations and upgrades

for compatibility before upgrading your production environment.
Do not make your production environment share servers with development and test
environments. While less intensively used Siebel environments, such as
development and test environments, may share the same physical equipment, your
production environment should have its own dedicated servers. In general, do not
load any one application server too heavily, or your Siebel system performance will
suffer.
For more information on establishing and using Siebel environments, see the Step-
by-Step Guide: An Example Implementation.

When you have determined which environments you will install on your site and
how many people each will support, write this information on your copy of
Appendix A, “Deployment Planning Worksheet.”
Dedicating Siebel Servers for Specific Services

There can be numerous Siebel Servers, each of which provides a different type of
service. Most consist of the same basic product, but are configured to provide
specific information and functions needed by a variety of sales representatives, call
centers, customer service representatives, and marketing staff.
The installation process for all these servers is the same, with one exception—
Siebel Marketing. For this reason, installation instructions for Siebel Marketing are
located in the Siebel Marketing Guide rather than in this guide. Otherwise, you must
simply determine which Siebel products you will install, provide appropriate
computers for them, and include them in your planning. For example, you may
want to provide a dedicated server for Siebel Enterprise Integration Manager (EIM),
Siebel Remote, or other Siebel products.
When you have determined the number and types of Siebel Servers you require, and
how many people each will support, record this information in the copy you made
of Appendix A, “Deployment Planning Worksheet.”

Grouping Your Siebel Servers Into Siebel Enterprise Servers 2
A Siebel Enterprise Server consists of a logical group of Siebel Servers configured to

share a single Siebel Gateway Server, Database Server, and File System. These Siebel
Servers can, as a result, be administered collectively rather than individually.
The Siebel Enterprise Server has the following components:
One Siebel File System. Each file system must belong to one and only one
Enterprise Server.
Multiple Siebel Servers. Each Enterprise Server must have at least one Siebel
Server. Each Siebel Server must belong to one and only one Enterprise Server.
Siebel Servers execute business logic for Siebel clients, particularly for thin
clients, and access the database server on the clients’ behalf.
One Siebel Gateway Server. The Gateway Server does not have to be reserved for
the exclusive use of a single Enterprise Server, but each Enterprise Server can
only be connected to one Gateway Server.
Siebel Systems recommends that you have one dedicated Gateway Server with
only one Enterprise Server in a production environment.
One Siebel Database Server. Each database instance can only support one
Enterprise Server, and each Enterprise Server can support only one database
platform.
Larger installations may also include:
Multiple Resonate Central Dispatch Servers. Resonate’s Central Dispatch product

provides connection-brokering services for Siebel eBusiness Applications. If
your deployment is configured to use connection brokering, you must install
Resonate Central Dispatch on all machines supporting Siebel Servers or Gateway
Servers.
One application server must be configured to act as the primary Central Dispatch
scheduler and another to act as a secondary, or backup scheduler. Siebel
Systems strongly recommends that these two application servers be dedicated
for this purpose and that no Siebel components operate from them.

Planning the Topology of Your Siebel Deployment 2
The topology of your Siebel deployment—the number, type, and capacity of your
computers (also referred to as application servers in this guide), and the distribution
of Siebel components across them—will vary considerably depending on the
number and type of Siebel clients that you are deploying.
The following guidelines apply to all deployments:
Give each Siebel Server its own dedicated application server for best performance.
While you can install all the Siebel components—the Database Server, File
System, Gateway Server, and Siebel Server—on a single computer, the Siebel
architecture is expressly designed to scale by distributing these components
across multiple application servers. For maximum performance and scalability,
each Siebel Server should be installed on a dedicated application server.
Give the Database Server its own high-performance application server. Your RDBMS
must be sized appropriately for your deployment. For information on sizing and
tuning your RDBMS for optimum performance, refer to the documentation
provided by your RDBMS vendor.
Install enough Siebel Servers to run the components you need for the number of users
you will support. If you install several Siebel Servers, the workload can be
distributed among them to support larger numbers of Siebel Server components
and users. Resonate Central Dispatch can be used to balance requests for specific
server components automatically across multiple Siebel Servers.
Microsoft SQL Server users should not include brackets [] in their Siebel
Server and Enterprise Server names.
Caution: If Microsoft SQL Server users include brackets in the

names they give to their Siebel Servers and Enterprise Servers,
they will get error messages in two places:
In the SVRsetup.log file, "5000: Bad key name.,

exiting..."
In Microsoft SQL Server DSN Configuration, "completed

with error(s):2000046," in the server field.
The installation will fail.

If you will use Siebel’s connection-brokering feature, reserve a dedicated application

server for the Central Dispatch scheduler. The server that acts as the Central
Dispatch scheduler performs best if you install it on a dedicated application
server.
If you do not install the Central Dispatch scheduler on a dedicated server, install
it on an application server that will not support connection-brokered Siebel
Server components. Otherwise, the Central Dispatch scheduler attempts to route
connections away from the server on which it operates. If that server is operating
connection-brokered components, poor load balancing will result; the Siebel
Server on the primary scheduler will not be optimized, although load-balancing
will still occur, based on the rules established in Central Dispatch.
Note the IP address or host name of the servers that will support the primary
and secondary schedulers, and record this in a copy of Appendix A,
“Deployment Planning Worksheet.” This information will be required when you
are configuring Central Dispatch.
When using connection-brokering for large numbers of users, put the Central Dispatch
primary scheduler on one separate, dedicated application server and the Central
Dispatch secondary scheduler on a second. If your enterprise will make extensive
use of connection-brokering, Central Dispatch performs best if you locate the
primary and secondary Central Dispatch schedulers on their own dedicated
computers.
If you operate either object manager or request manager components on multiple

application servers, use connection brokering to ensure both high availability and
scalability of these components. Client connection requests for these components
are sent to a Gateway virtual IP (VIP) address, rather than directly to the actual
application server, or servers. The Siebel Gateway then directs the client requests
to the least-laden server available that is running the desired component. In the
event that one or more servers are unavailable, connections are automatically
routed to the remaining servers.
Connect the computers on which your Siebel applications will run to fast LANs. Siebel
Servers require high-speed local area network (LAN) connectivity. Siebel
Systems strongly recommends an FDDI, Fast Ethernet, or other high-speed LAN
to connect the Gateway Server, Siebel Servers, and Database Server.

Make sure that the LAN or mobile connections are adequate for your Siebel clients. All
dedicated clients require full-time network connectivity to the Siebel Database
Server and File System, and may also sometimes connect with the Enterprise
Server for additional functionality. Mobile clients must periodically connect to
the Siebel Server to synchronize data and files and can connect through a LAN
or through dial-up.
For information regarding supported network protocols for Siebel clients, see
To provide both dynamic load balancing and high availability, implement both MSCS and
connection brokering in the same Siebel eBusiness Applications deployment. In this
hybrid installation scenario, the Siebel Gateway Server operates under MSCS for
high availability, as do those Siebel Servers operating non-connection-brokered
components. Other Siebel Servers operating connection-brokered components
such as the Application Object Manager can be installed on cluster nodes, but
do not operate under Microsoft clusters. Instead, connection brokering ensures
high availability and scalability for these components by distributing requests
between these components running on both cluster nodes.
If you will be implementing Microsoft Cluster Server (MSCS) and the connection-
brokering features of the Siebel Gateway Server, be aware that the two technologies
address very different operational requirements. You must plan your deployment
carefully to take advantage of the benefits of each technology.
MSCS only provides high availability. It automatically migrates and restarts

resources, such as Siebel Servers, between two nodes of a cluster. Clients
connect to these application resources through virtual network names or
addresses that are also moved between the cluster nodes, ensuring the
availability of resources regardless of the cluster node on which they are
currently operating. A given resource can only execute one cluster node at a
time, and MSCS does not provide facilities for distributing requests between
multiple resources. Therefore, MSCS does not ensure load balancing across
cluster nodes.
MSCS is best suited to ensure the availability of those Siebel Enterprise Server
components that must be accessible on a specific physical server.
NOTE: Siebel strongly recommends that you operate the Siebel Gateway Server
on a cluster for high availability. You may also choose to operate Siebel Remote
or other Siebel Server components on a cluster, depending on your operational
requirements.

The Siebel Gateway Server can coexist with a Siebel Server or can be installed on
another physical machine. The only precondition is that the Gateway Server meet
the hardware, operating system, and other requirements detailed in Siebel
System Requirements and Supported Platforms. There is always only one Siebel
Gateway Server communicating with multiple Siebel Servers.
When planning server names, remember the following:
Under UNIX, Siebel Server names must be 30 characters or less in length and
must not contain spaces or punctuation.
Siebel Server and Enterprise Server names must be unique on the Gateway
Server.
Planning the Siebel Directory Structure 2
Plan where to install the various Siebel components on your servers.
NOTE: If you are installing multiple versions of Siebel eBusiness Applications, each
must be installed in a unique directory. Siebel Systems recommends that, in this
case, you use a naming convention that reflects the components and the version
number being installed.
Planning the Directory Structure Under Windows NT

Under Windows NT, each server or other component of a Siebel Enterprise Server
on a single computer must be installed in a unique directory.
The Gateway Server must be installed in its own directory; similarly, each Siebel
Server installed on an application server must also be installed in a unique
directory.
Caution: The Siebel Enterprise Server entity installers for Windows

NT use C:\sea6xx\siebsrvr as the default installation directory.
You must choose a unique directory name to override this default
during the installation of each component, or all your components
will be installed in the same directory and your installation will fail.

When installing Siebel applications, make administration, maintenance, and upgrades

as easy as possible by choosing a naming convention that identifies both the
component instance and its version. Siebel Systems also recommends that you
install all Siebel components in subdirectories under a common directory. For
example, you might use the directory C:\sea6xx\gtwy for version 6.x of the
Siebel Gateway Server, and C:\sea6xx\dbsrvr for version 6.x of the Siebel
Database Server scripts.
NOTE: If you will be installing Resonate Central Dispatch, you must install it in
a directory separate from Siebel entities.
If you will be installing the CORBA Object Manager, consider installing it on a dedicated
application server. The CORBA Object Manager may be installed on an
application server that also supports the Siebel Enterprise Server components,
although for best performance and scalability you should install the CORBA
Object Manager onto a dedicated application server.
Record the directory names you decide on in the copy you made of Appendix A,
Planning the Directory Structure Under UNIX

Under UNIX platforms, the Enterprise Server entities—the Gateway Server, Siebel
Server, and Database Server installation scripts—are automatically installed under
a common directory, referred to as SIEBEL_ROOT. The SIEBEL_ROOT directory is
created during the installation of the first Enterprise Server entity (for example,
Siebel Gateway Server) on an application server.
The UNIX Enterprise Server component installers use /siebel as the default for
SIEBEL_ROOT. Unless otherwise specified, all other Enterprise Server entities
subsequently installed on the application server will be installed under this same
SIEBEL_ROOT directory.

For improved administration, maintenance, and recovery of Siebel Enterprise

components, Siebel Systems recommends that you install each Siebel Enterprise
component in a different SIEBEL_ROOT directory. After the installer script has been
executed, no further prompts for an installation directory occur. Therefore, to
enable installation of each Siebel Enterprise component in a different root directory,
you must open a new session for the installation of each new component, so that
the installer script prompts you with the default directory name. You must then
override this default value with a unique name that identifies the Database Server
environment and the version of the Siebel Enterprise Server components being
installed.
You should also locate each SIEBEL_ROOT directory under a common Siebel
directory. For example, you might use /siebel6xx/gtwy/ as the SIEBEL_ROOT
directory for the version 6.x Siebel Gateway Server supporting your production
environment.
Record the SIEBEL_ROOT directory names for your installation in your copy of
Appendix A, “Deployment Planning Worksheet,” under the
Enterprise Server/Siebel root field, and leave the other installation directory
information blank for entities you will install on the same application server.
If you will be installing Resonate Central Dispatch, you must install it in a directory
separate from Siebel entities. Siebel Systems recommends that you install the
Central Dispatch software in a separate directory under a common directory
shared by Siebel entities. For example, you might use the directory
/siebel6xx/resonate6xx for the version of Resonate Central Dispatch shipped
with version 6.x of Siebel Applications.
Record the directory names you decide on in Appendix A, “Deployment

Planning Worksheet.”
If you will be installing the CORBA Object Manager, consider installing it on a dedicated
application server. The CORBA Object Manager may be installed on an
application server that also supports the Siebel Enterprise Server components,
although for best performance and scalability you should install the CORBA
Object Manager onto a dedicated application server.
Record the directory names you decide on in the copy you made of Appendix A,

Preparing the Hardware 2
Verify that the computers you have chosen meet all requirements for running your
Siebel application, as well as the required third-party software, and are able to
support the Siebel File System, the Siebel Gateway Server, the Siebel Server, Siebel
Database Server, and the Siebel Server Manager administrator’s workstation. For
size limitations and information on required third-party software, refer to Siebel
System Requirements and Supported Platforms.
Regardless of the types of Siebel clients that you plan to deploy, you must install at
least one Siebel Dedicated Client for use by the Siebel administrator to run the
Server Manager.

Creating Siebel Accounts
Creating Siebel Accounts 2
The Siebel Enterprise Server requires two standard Windows NT or UNIX-based

system user accounts, as follows:
Siebel Service Owner Account. This is the user account on your Siebel Servers
under which all Siebel processes and components operate. The Siebel Service
Owner Account is required whether or not you are using Resonate Central
Dispatch for connection brokering.
Under Windows NT, this must be an account that is part of a Windows NT

domain and have Administrator privileges in each one of application servers in
which Central Dispatch, the Siebel Gateway, and the Siebel Servers will run. For
this reason, this is also known as the Administration mode account.
Under UNIX, this account should be a regular user account with appropriate
permissions set; the account will also be used to start and stop Siebel processes.
Siebel Monitoring Account. This account is required for the Resonate Central
Dispatch connection brokering server. Therefore, you only need this account if
you install connection brokering.
Under both Windows NT and UNIX, this account must have login privileges on
each application server, but requires no additional privileges.
Both of the accounts mentioned above must exist on each host on which Central
Dispatch has been installed.

Creating Siebel Accounts Under Windows NT 2
If you will be installing the Siebel Enterprise Server under Windows NT, complete
the following steps to create the required Siebel accounts.
Preparing for Setting Up Siebel Accounts

Before you set up Siebel accounts, review the following guidelines for the Windows
NT platform:
Set up the accounts so that the user does not have to change the password at the
next logon. This precaution prevents the user from changing the password. It
also allows you to create a password that never expires.
Do not disable the accounts. They must be enabled to connect to the node where
the accounts were created.
Creating the Siebel Service Owner Account

Under Windows NT, the Siebel Server and Gateway Server services operate under
the Service Owner account. When you use connection brokering, these accounts
must also function as the Administration account.
To create the Siebel Service Owner account

1 Determine what the account name and password will be, and record this
information in Appendix A, “Deployment Planning Worksheet.” (For security
reasons, you may prefer not to record the password, since this account will have
administrative privileges.)
2 Access the Windows NT User Manager under

Start Programs Administrative Tools User Manager.
3 Create a Siebel Service Owner account using this user ID and password on the
domain server with the following characteristics:
The account must be part of a Windows NT domain, so that services can be

operated under the same account on all Windows NT servers. (The Windows
NT system account or local system cannot be used, because that account
does not have network access.)
The account name cannot contain embedded spaces.

The account password must not require a change on next logon and must be
set not to expire. Because the Siebel Server components store the password
in encrypted format, any change to the password will require that these
components be reconfigured.
NOTE: Be sure to use the same user ID and password for the service owner
account on each application server.
4 Add this user to the Administrators’ group in each application server that will
run a Siebel Server, on the application server that will run the Gateway Server,
and on the primary and backup Central Dispatch scheduler, if these are separate
machines.
This account must have the following characteristics:
The account must have the advanced user right “Log on as a service” on each
Windows NT application server.
If you will be using Siebel eMail Response, this account must correspond
with the accounts on your corporate email system.
NOTE: To add or verify Windows NT account privileges, from the User Manager
click Policies User Rights.
To add logon as a service privilege to the account
1 From the Windows Start menu, choose Programs Administrative Tools User
Manager.
2 Select the user who requires the service privilege, and then choose

Policies User Rights.
3 Select the Show Advanced User Rights check box.

4 From the Right list, select Logon as a Service.
5 Select the user from the Grant To: list.
6 To add a user to the Grant To: list, click Add.
7 Select the user from the Add Users and Groups dialog box. Click Add, and then
click OK.
8 From the User Rights dialog box, click OK.

Creating the Siebel Monitoring Account

If you will use connection brokering, you must also create one Windows NT user-
level account for Resonate Central Dispatch. Central Dispatch uses this account to
monitor the load on your Siebel Servers and incoming connection requests.
Caution: If the Service Owner/Administration mode account and the

Monitor mode account have the same password, all users who enter
that password from Dispatch Manager have full administration
privileges, allowing them to modify the functioning or the
configuration of the site. To prevent this, do two things:
Assign different passwords to both accounts.
Limit knowledge of the administration mode account

password to those who need to administer the site.
To create the Monitoring account

1 Determine the account name and password for the Service Owner/
Administration account, and record this information in Appendix A,
“Deployment Planning Worksheet.” (You will be prompted for this information
when you are installing Resonate Central Dispatch.)
2 Create the Windows NT account.
This one should be user-level—it should not have administrative privileges. Be

sure that this account is a member of the Users group on each Siebel Server.
As with the Windows NT Administrator account you created for Siebel Services,
this account password must be set not to change or expire.

Creating Siebel Accounts Under UNIX 2
If you will be installing the Siebel Enterprise Server under a supported UNIX
version, complete the following steps to create the required Siebel accounts.
Preparing for Setting Up Siebel Accounts

Before you set up Siebel accounts, review the following guidelines for the UNIX
platform:
Prevent users from being able to actually log on using either the
Administration mode account or the Monitor mode account. You can do this
by not assigning a login shell to that account. (If you do not assign a login
shell to the account, you also do not need to assign a home directory to the
account.)
The account name cannot contain embedded spaces.
The account password must not require a change on next logon and must be
set not to expire.
NOTE: Be sure to use the same user ID and password for the Service Owner
account on each application server.
The login name and password for the administration account must be the
same on all the computers in the Central Dispatch site, including the monitor
mode account.
NOTE: The “Central Dispatch site” includes the entire deployment network
controlled by any one Siebel Gateway Server.
Set up the accounts, so that users neither have to change the password at the
next logon, nor can they change it, and so that the password never expires.
Do not disable the accounts. They must be enabled to connect to the node
where the accounts were created.

Creating the Siebel Service Owner Account

Under UNIX, the Siebel Gateway Server and Siebel Server processes must operate
under a common account. All Siebel Enterprise Server software is also installed
under this account, and the Service Owner account must be used to start or stop
Siebel Enterprise Server components.
To create the Service Owner account

1 Determine what the account name and password will be, and record this
information in Appendix A, “Deployment Planning Worksheet.”
2 Create a new Siebel group to which this account belongs.

3 Create the account using an appropriate administration tool for your UNIX
platform, or by editing /etc/passwd directly, using your favorite text editor, and
then running the pwconv utility.
Create the Service Owner account at the network level, so that the same account
can be used on all UNIX application servers within the Siebel Enterprise.
Creating the Siebel Monitoring Account

If you will use connection brokering, you must also create an account used by
Central Dispatch to monitor the Siebel Servers and incoming connection requests.
Determine all the account names and passwords for your Siebel Administrator
accounts, and record this information in Appendix A, “Deployment Planning
Worksheet.” When you have done this, create the account just as you did the other
one.
This account does not require “superuser access”; it should be a normal user
account. Therefore, it should not belong to the same group as the previous
accounts.
NOTE: Never log into Dispatch Manager accounts directly as a user. The accounts
exist on each machine so that Dispatch Manager can validate the password you
enter when connecting to your Central Dispatch site before granting administration
or monitoring privileges.

Planning Port Assignments
Planning Port Assignments 2
If your site’s network requires static port assignments for correct configuration,
determine which ports you want to assign to the Synchronization Manager, Request
Manager, and each Application Object Manager component, and note these in
Appendix A, “Deployment Planning Worksheet,” for each Siebel Server in your
deployment.
NOTE: This step is optional; unless your network requires static ports, use dynamic
ports for simplified installation and configuration.
If you use Resonate Central Dispatch, the default port used by the scheduler is 2320.
If you want to reconfigure the scheduler onto another port, you must do so using
Siebel Server Manager after you install Siebel Enterprise Server components.

RDBMS Installation and Configuration Planning
RDBMS Installation and Configuration Planning 2
Ensure that Siebel supports the exact version of your chosen RDBMS, as specified
in Siebel System Requirements and Supported Platforms, and that the RDBMS has
been installed on the machine to be dedicated as the Siebel Database Server. This
server will hold the database tables containing your business data, such as sales
(personnel, territories, opportunities, and activities), marketing, and customer
service information.
Verify that the network names of the servers that will support the Siebel Database
Server and Siebel File System are properly recorded in Appendix A, “Deployment
Planning Worksheet.”
Finally, you will need to determine certain details about your RDBMS configuration.
Siebel will create the ODBC data source name during installation. The name will
be SiebSrvr_enterpriseservername. For example, if your Siebel Enterprise
Server name is the default, Siebel, the ODBC data source name will be
SiebSrvr_Siebel. Using this pattern, determine what your ODBC data source
name will be and fill in the Deployment Planning Worksheet.
Complete the appropriate RDBMS-specific information in Appendix A,

Prior to installing the Siebel Database Server, refer to the configuration chapter
specific to your RDBM later in this guide for sizing and configuration
information.
Next Steps 2
Your environment is now ready for installation and configuration of the Siebel
Server entities. If you are installing Central Dispatch, see Chapter 3, “Installing
Central Dispatch Under Windows NT,” or Chapter 4, “Installing Central Dispatch
Under UNIX,” depending on your operating system.
If you are not installing Central Dispatch, see Chapter 5, “Installing the Siebel
Gateway Server Under Windows NT,” or Chapter 6, “Installing the Siebel Gateway
Server Under UNIX.”

Installing Central Dispatch and
the Siebel Gateway Server Part 1
Chapter 3. Installing Central Dispatch Under Windows NT
Chapter 4. Installing Central Dispatch Under UNIX
Chapter 5. Installing the Siebel Gateway Server Under Windows NT
Chapter 6. Installing the Siebel Gateway Server Under UNIX
Version 6.3.1 Siebel Server Installation Guide

Siebel Server Installation Guide Version 6.3.1
Installing Central Dispatch Under Windows NT 3

Verifying Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Assigning the Virtual IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Verifying Network Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6

Configuring Central Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Choosing a Scheduling Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Choosing a Load-Balancing Policy . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Reconfiguring Central Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13

Installing Central Dispatch Under Windows NT
About This Chapter
This chapter describes installation of the Resonate Central Dispatch server for those
who will implement connection brokering under Windows NT.
Pre-Installation Tasks 3
If you plan to use Siebel’s connection-brokering feature, you must now install the
Resonate Central Dispatch software before proceeding with the installation of the
Siebel Gateway Server and Siebel Enterprise Server. If you choose not to use
connection brokering, page to Chapter 5, “Installing the Siebel Gateway Server
Under Windows NT.”
Caution: If you do not install Central Dispatch now, but later decide
to use connection brokering, you will be required to reinstall all
Siebel Enterprise Server entities after you have installed Central
Dispatch.
Before proceeding, be sure to review the Resonate Central Dispatch User Guide,
provided on the Bookshelf for Siebel eBusiness Applications CD-ROM.
The pre-installation tasks consist of the following:
“Reviewing Resonate Installation Rules” on page 3-3

“Verifying Accounts” on page 3-3
“Assigning the Virtual IP Address” on page 3-4
“Assigning the Virtual IP Address” on page 3-4
“Verifying Network Routes” on page 3-6

Pre-Installation Tasks
Reviewing Resonate Installation Rules 3
To determine where to install the following software components, review the

following guidelines:
Central Dispatch must be installed on all application servers that will support
Gateway or Siebel Servers.
One application server on which Central Dispatch is installed should be

designated as a primary scheduler and another as a secondary scheduler. For
best results, Siebel Systems strongly recommends that neither of these two
servers run any other Siebel components.
Dispatch Manager can run on Central Dispatch nodes or on any Windows NT

Server.
NOTE: Before proceeding with the installation of Central Dispatch, review the
Resonate Central Dispatch and Resonate Commander Site Preparation Guide,
available in pdf format on the Siebel Bookshelf.
Verifying Accounts 3
Central Dispatch requires two accounts, which you created in “Creating Siebel
Accounts” on page 2-17. Before proceeding with the installation, verify that you
have the proper accounts, as follows:
A Siebel service owner account. This must be a domain account that is a member
of the Administrators group on all Windows NT application servers that will run
the Siebel Gateway Server, Siebel Servers, and Resonate Central Dispatch. It
must also have the “logon as a service” privilege.
A Siebel monitoring account. This account must be a member of the Users’ group
on application servers.

Assigning the Virtual IP Address 3
When you install Central Dispatch, connection-brokered Siebel clients are no longer
virtual IP (VIP), a logical address operated by the Resonate scheduler, which in turn
connects these clients to the most appropriate, and least loaded, Siebel Server
available.
In brokered mode, the Siebel Gateway Server requires a VIP, or logical IP address.
Siebel clients are then configured to connect to this VIP, rather than to Siebel Servers
directly, for access to brokered server components. This so-called Gateway VIP is
owned by the primary scheduler.
automatically updated as Siebel Servers are started or stopped or as their
configuration is modified.
The Gateway VIP must be on the same IP subnet as the addresses of all application
servers in the Siebel Enterprise. Select these addresses from the appropriate subnet
and record this information in a photocopy of Appendix A, “Deployment Planning
Worksheet.”
NOTE: Register the VIP with the appropriate name service, such as DNS or NIS, just
as you register any real host’s IP address. However, unlike standard IP addresses,
the VIP denotes the entire Siebel site, not just a particular application server.
Tips for Defining the VIP

Follow the guidelines below in setting up your VIP.
To plan your Central Dispatch site

Never assign a VIP to a real physical host, or computer. A VIP is only a logical
IP address managed by the schedulers in a Central Dispatch site.
List all the hostnames of the servers that make up your site and the resources
and content they provide. Decide which servers to group together based on that
information.

Under UNIX, make sure that the netmasks file or NIS/NIS+ database contains
every network number/network mask pair used in your network.
Caution: Central Dispatch relies on this information. If it is

incomplete, some servers may not be integrated into your site.
Make sure that the VIP is unique. Never use an IP address as a VIP if that IP
address is already assigned to a computer.
Make sure that the IP address of the scheduler nodes (primary and backup), the
Siebel Gateway, and Siebel Server nodes are on the same subnet as the VIP. This
means that each primary scheduler, the VIP assigned to it, and the backup
scheduler for that primary are all part of the same subnet. The network ID
portion of the scheduler IP address (as defined by the subnet mask) must be
identical to the network ID portion of the VIP.
Updating the Name Service

You must register your VIP with the appropriate name services. Register the VIP
exactly as you would any other IP address:
If your site can be reached from the Internet, register with the appropriate DNS
server for your site.
If a group of servers is cut off from the rest of the network and visible only to
each other, resolve their names either by modifying the DNS database records or
by modifying the entries in the local host file:
%System Root%\system32\drivers\etc\hosts

Assigning Static IP Addresses 3
You must also assign static IP addresses to each of your application servers. Select
these addresses from the appropriate subnet, and record this information in
Central Dispatch also requires that static IP addresses be assigned to each of the
machines with which it interacts. These IP addresses must all be on the same
subnet and use the same subnet mask. You will also need to know the default
Gateway address for this subnet.
To configure the static IP address on each Windows NT application server

1 Double-click the Network icon in the Control Panel.
2 In the Network dialog box, click the Protocols tab, select the TCP/IP Protocol
icon, and click Properties.
3 On the IP Address tab of the Microsoft TCP/IP Properties dialog box, make sure
that the correct Adapter (the physical network interface card) is selected.
4 Click Specify an IP Address and do the following:

a Type the values for the fields IP Address, Subnet Mask, and Default Gateway
for the static IP address for this server.
b Click OK.
5 Click Close to close the Network dialog box.
The driver will be installed, and you will see the TCP/IP Properties dialog box.
Verifying Network Routes 3
Use the ping utility to make sure that all application servers have TCP/IP
connectivity to one another, as well as to the servers that will support the Siebel
Database Server and the Siebel File System.
You also need to make sure that the routes between all application servers are
symmetric. Symmetric routes are routes that, step for step, traverse the same
computers and the same network nodes in exactly the opposite order with respect
to each other.

To verify that routes between application servers are symmetric

1 On the computer that will support the primary Central Dispatch scheduler, open
an MS-DOS command prompt.
2 Use the tracert command to display the route from it to one of your application
servers, as follows:
C:\> tracert appserver
where:
appserver = The name or IP address of one application server machine.
3 In the same way, on that application server, open an MS-DOS command prompt,
and use the tracert command to display the route from it back to the machine
that will host the primary Central Dispatch scheduler.
4 Compare the results of each tracert and verify that the routes between these
servers are symmetric.
Following is an example of a set of symmetrical tracert results between two

servers named demaine and windsor. The first set of results shows the network
route from demaine to windsor, and the second shows the route from windsor
to demaine:
C:\>tracert windsor
Tracing route to windsor [10.0.16.9] over a maximum of 30 hops:
1 <10 ms <10 ms <10 ms demaine [10.1.24.250]

2 <10 ms <10 ms <10 ms 10.1.24.221
3 <10 ms <10 ms <10 ms windsor [10.0.16.9]
Trace complete.
C:\>tracert demaine
Tracing route to demaine [10.1.24.250] over a maximum of 30

hops:
1 <10 ms <10 ms <10 ms windsor [10.0.16.9]

2 <10 ms <10 ms <10 ms 10.1.24.221
3 <10 ms <10 ms <10 ms demaine [10.1.24.250]
Trace complete.

5 Repeat these steps from your primary Central Dispatch scheduler for each
application server machine you have.
6 From the secondary Central Dispatch scheduler, repeat this process with each
application server.
If you find asymmetric routes between any two servers, you need to adjust your
routing so that the routes are symmetric. You might have to delete static route tables
and redo the routes, or restart the router in order to get a symmetric route.
After you have verified network routes on all application servers, you are ready to
install Central Dispatch.

Installation Tasks
Installation Tasks 3
You must install Central Dispatch on each computer that will support a Siebel Server
or Siebel Gateway Server, and the Central Dispatch primary scheduler and backup
scheduler. Complete the following steps to install Central Dispatch.
To install Central Dispatch

1 Insert the Siebel eBusiness Applications CD-ROM into the CD-ROM drive of a
Siebel Server, and in Windows NT Explorer, navigate to the following directory
on the Siebel Windows NT Server CD-ROM:
\Thirdpty\language\resonate\winnt
where:
language = the three-letter code for the language of your Siebel eBusiness
Applications product; for example, enu for U.S. English.
2 Double-click setup.exe to start the Resonate installer, and when the Welcome
dialog box appears, click Next.
3 For installation steps specific to the Central Dispatch installer, see the Resonate
Central Dispatch and Resonate Commander Installation Guide, available on the
Siebel Bookshelf in pdf format.
4 Install only the following Resonate components from the Select Component
screen:
Central Dispatch Node
Management Tools
CDAction
Dispatch Manager
NOTE: Do not try to enable Resonate’s “shadow scheduling” feature; Siebel

eBusiness Applications does not use Central Dispatch’s persistent sessions
feature.

Post-Installation Tasks
Post-Installation Tasks 3
The post-installation tasks are:
“Configuring Central Dispatch”

“Choosing a Scheduling Policy” on page 3-13
“Choosing a Load-Balancing Policy” on page 3-13
“Reconfiguring Central Dispatch” on page 3-13
“Reinstalling Central Dispatch” on page 3-15
Configuring Central Dispatch 3
After you have completed the installation of Central Dispatch on all application
servers, you need to configure it using the Resonate Dispatch Manager application.
During this configuration step, you will define a Central Dispatch site that includes
the static IP addresses used by the application servers and the Gateway VIP.
You will configure the Central Dispatch site only once, from any application server
within the Enterprise Server. Central Dispatch automatically shares and updates
configuration information across all Central Dispatch nodes in the site.
Caution: You must have already installed Central Dispatch on each

of these application servers according to the instructions in the
previous section, or you will not be able to configure Central
Dispatch.

To configure Central Dispatch

1 From the Windows NT Start menu, choose Programs Resonate Dispatch
Dispatch Manager.
2 In the Dispatch Manager Welcome dialog box, leave the Connect to Node field
empty and click OK.
NOTE: The Connect to Node field is left blank only the first time that you start
Dispatch Manager. After you have configured the Central Dispatch site, you must
specify the IP address of one of the system nodes or the Gateway VIP to connect
to the site when starting Dispatch Manager.
3 In the Site Monitor dialog box, click Site Setup.

4 On the System Nodes tab, add the static IP addresses of all application servers
that will support a Siebel Server, Siebel Gateway Server, Central Dispatch
Primary Scheduler, or Central Dispatch Backup Scheduler. After entering each IP
address, click Add.
These IP addresses can be found in Appendix A, “Deployment Planning

Worksheet.” Accept the default values for Server Weight, Server Enable, and
Server Auto-enable.
NOTE: Type the static IP address, not the name of the machine to which it is
assigned, in the Node Name field. The use of hostnames can cause
inconsistencies in routing, depending on the operation of your DNS servers.
5 On the Virtual Hosts tab, add the Gateway VIP to the site:
a In the Virtual Host Name field, type the VIP address.
b In the Primary Scheduler list, select the static IP address of the application
server that will serve as the primary Scheduler node.
c In the Alternate Scheduler list, select the static IP address of a second

application server to serve as the alternate Scheduler node.
d To add the VIP, click Add.

6 On the Licensing tab, type the license key in the New Key field.
The license key is stored in the license.txt file in the
\Thirdpty\language\resonate subdirectory of your Siebel Windows Server
CD-ROM.
Be sure to press ENTER after entering the license key.
7 On the Operation tab, click Start Site.

8 Type the password for the Siebel service owner account.
9 After the Central Dispatch software has started, close Dispatch Manager.
Central Dispatch Configuration Tips

Review the following configuration tips when setting up your Central Dispatch site:
Do not change the server weight to redistribute the Central Dispatch connection
weight by entering a value in the Server Weight field of Dispatch Manager, as
described in the Resonate Central Dispatch User Guide. Instead, use the Siebel
parameter MaxTasks for an asymmetric distribution of connections. For
information on the use of this parameter, see the Siebel Server Administration
Guide.
If you have a dedicated scheduler, do not enable it as a server.

You do not need to configure Resonate’s class of service (COS) or thresholds to
configure scheduling rules since Siebel eBusiness Applications does this
dynamically.
You do not need to mark a node that does not need Resonate software installed
as an affiliate node, as described in the Resonate Central Dispatch User Guide.
Siebel software does not support affiliated nodes.
Do not enable Central Dispatch’s shadow scheduling feature.

Choosing a Scheduling Policy 3
When the Central Dispatch scheduler receives an incoming request, it determines

which node or set of nodes is qualified to respond to the request. Central Dispatch
allows you to choose between two types of scheduling policy to determine this—
round-robin or resource-based scheduling. You must select resource-based
scheduling to take advantage of Central Dispatch’s load-balancing features with
Siebel eBusiness Applications.
For more information on Central Dispatch scheduling policy, see the Resonate
Central Dispatch User Guide.
Choosing a Load-Balancing Policy 3
When you select Central Dispatch resource-based scheduling, you must also select
a load-balancing policy. (Round-robin scheduling does not require load balancing.)
Select CPU Load and Connections (enhanced) as your load-balancing policy.
For more information on Central Dispatch load-balancing policy, see the Resonate
Reconfiguring Central Dispatch 3
After Central Dispatch has been installed and configured, its ongoing configuration
and operation are handled primarily by the Siebel Server software. You can use
Dispatch Manager to monitor the operation of your Central Dispatch server, as
described in the Resonate documentation, but you will not need to change the
configuration manually during normal operations.
The exception to this occurs if you need to add application servers to your
Enterprise Server or to remove them. In this case, follow the procedure below.

To remove an application server

1 If you are removing a static IP address assigned to an application server running
a Siebel Gateway or Siebel Server:
a Stop the Siebel Server, the Siebel Gateway, or both (in that order) in that node
before removing the IP address.
b Using Resonate Dispatch Manager, verify that none of the scheduling rules
contain the static IP address, or node, you want to remove. If it does, you
must manually remove the node. To do so, refer to the Resonate Central
Dispatch User Guide under “Changing and Deleting Scheduling Rules.” This
book is available in pdf format on your Siebel eBusiness Applications Server
Installation CD-ROM under Thirdpty\language\Resonate.
NOTE: Under normal circumstances, manual removal of the node from a

scheduling rule should not be necessary and would primarily be required only
if a server did not shut down properly.
2 Remove the static IP addresses assigned to each server from the System Nodes
tab of the Site Setup dialog box in Dispatch Manager, as described in
“Configuring Central Dispatch” on page 3-10.
To add an application server

1 Add the static IP addresses assigned to each server from the System Nodes tab
of the Site Setup dialog box in Dispatch Manager, as described in “Configuring
Central Dispatch” on page 3-10.
2 Verify that the correct static IP address is assigned to each server and that no
static IP address is used more than once.

Reinstalling Central Dispatch 3
You will need to reinstall Central Dispatch if you change your network or hardware
configuration.
To reinstall Central Dispatch

1 Stop all Siebel services and any Central Dispatch services on all nodes.
2 Uninstall any Siebel components already installed on the node (or nodes) where
reconfiguration will occur. (For information regarding uninstalling Siebel
programs, see Chapter 24, “Uninstalling Siebel eBusiness Applications.”)
3 Uninstall Central Dispatch. See the Resonate Central Dispatch Installation Guide,
available on the Siebel Bookshelf in pdf format.
4 Perform the required network or hardware configuration on the affected node

(or nodes.)
5 Reinstall Central Dispatch on the node (or nodes) on which you formerly had it
installed, following the instructions provided earlier in this chapter.
NOTE: Use the same Resonate Administrator password that was used previously.
6 Verify that the installer has installed Resonate in the correct location.
7 Verify that the reconfigured node is part of the Central Dispatch site.
If it is not, refer to “Configuring Central Dispatch” on page 3-10.
8 Start the Central Dispatch site, according to instructions in “Configuring Central

Dispatch” on page 3-10.
9 Reinstall any Siebel components that you had previously uninstalled. (Refer to
the other chapters in the guide for information on their installation.)
10 Restart all Siebel services on all nodes.


Installing Central Dispatch Under UNIX 4

Verifying Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Assigning a Virtual IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Verifying Network Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

Configuring Central Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Configuring Server Components . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Choosing a Scheduling Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14
Choosing a Load-Balancing Policy . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Reconfiguring Central Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14

Installing Central Dispatch Under UNIX
About This Chapter
This chapter describes installation of the Resonate Central Dispatch server for those
who will implement connection brokering under UNIX.
If you plan to use Siebel’s connection-brokering feature, you must now install the
Resonate Central Dispatch software before proceeding with the installation of the
Siebel Gateway Server and Siebel Enterprise Server. If you choose not to use
connection brokering, page to Chapter 6, “Installing the Siebel Gateway
Server Under UNIX.”
Caution: If you do not install Central Dispatch now, but later decide
to use connection brokering, you will be required to reinstall all
Siebel Enterprise Server entities after you have installed Central
Dispatch.
Before proceeding, be sure to review the Central Dispatch documentation provided

on the Resonate man pages provided on the Siebel Server UNIX CD-ROM. (On UNIX
systems, a man page is a document explaining how to use a particular program or
software package.)
The pre-installation tasks consist of the following:
“Reviewing Resonate Installation Rules” on page 4-3

“Verifying Accounts” on page 4-3
“Assigning a Virtual IP Address” on page 4-4
“Verifying Network Routes” on page 4-6
“Installation Tasks” on page 4-9

Reviewing Resonate Installation Rules 4
To determine where to install the following software components, review these

guidelines:
Central Dispatch must be installed on all application servers that will support
Gateway or Siebel Servers.
One application server on which Central Dispatch is installed should be

designated as a primary scheduler and another, as a secondary scheduler. For
best results, Siebel Systems strongly recommends that neither of these two
servers run any other Siebel components.
Dispatch Manager can run on Central Dispatch nodes or on any UNIX Server.
NOTE: Before proceeding with the installation of Central Dispatch, review the
Resonate Central Dispatch and Resonate Commander Site Preparation Guide,
available in pdf format on the Siebel Bookshelf.
Verifying Accounts 4
Central Dispatch requires two accounts, which you created in “Creating Siebel
Accounts Under UNIX” on page 2-21. Before proceeding with the installation, verify
that you have the proper accounts, as follows:
A Siebel Service Owner account. This is the user account on your Siebel Servers
under which all Enterprise Server processes and components operate. This
account should be a regular user account with appropriate permissions set; it
will also be used to start and stop Enterprise Server processes.
A Siebel monitoring account. This account is required for the Resonate Central
Dispatch connection brokering server and is, therefore, needed only on systems
that have connection brokering installed. This account must have login
privileges on each application server, but requires no additional privileges.
Both of the accounts mentioned above must exist on every host where Central
Dispatch is installed. These are standard UNIX-based system user accounts.

Assigning a Virtual IP Address 4
When you install Central Dispatch, connection-brokered Siebel clients are no longer
virtual IP (VIP), a logical address operated by the Resonate scheduler, which
connects these clients to the most appropriate, and least loaded, Siebel Server
available.
In brokered mode, the Siebel Gateway Server requires a VIP, or logical IP address.
Siebel clients are then configured to connect to this VIP, rather than to Siebel Servers
directly, for access to brokered server components. This so-called Gateway VIP is
owned by the primary scheduler.
automatically updated as Siebel Servers are started, stopped, or as their
configuration is modified.
The Gateway VIP must be on the same IP subnet as the addresses of all application
servers in the Siebel Enterprise. Select these addresses from the appropriate subnet
and record this information in a photocopy of Appendix A, “Deployment Planning
Worksheet.”
NOTE: Register the VIP with the appropriate name service, such as DNS or NIS, just
as you register any real host’s IP address. However, unlike standard IP addresses,
the VIP denotes the entire Siebel site, not just a particular application server.

Tips for Defining the VIP

Follow the guidelines below in setting up your VIP.
To plan your Central Dispatch site

Never assign a VIP to a real physical host, or computer. A VIP is only a logical
IP address managed by the schedulers in a Central Dispatch site.
List all the hostnames of the servers that make up your site and the resources
and content they provide. Decide which servers to group together based on that
information.
Under UNIX, make sure that the netmasks file or NIS/NIS+ database contains
every network number/network mask pair used in your network.
Caution: Central Dispatch relies on this information. If it is

incomplete, some servers may not be integrated into your site.
Make sure that the IP address of the scheduler nodes (primary and backup) are
on the same subnet as the VIP. This means that each primary scheduler, the VIP
assigned to it, and the backup scheduler for that primary are all part of the same
subnet. The network ID portion of the scheduler IP address (as defined by the
subnet mask) must be identical to the network ID portion of the VIP.
Updating the Name Service

You must register your VIP with the appropriate name services. Register the VIP
exactly as you would any other IP address:
If your site is reachable from the Internet, register with the authoritative DNS
server for your site.
If you use NIS or NIS+ inside a firewall, edit the NIS files or update the
database.
If a group of servers is cut off from the rest of the network and visible only to
each other through the /etc/hosts files, edit those files.
Make sure that all the nodes in your Central Dispatch site are registered with the
naming service you are using. For example, if you use /etc/hosts files, each
file must contain entries for all the nodes in the site.

Assigning Static IP Addresses 4
You must also assign static IP addresses to each of your application servers. Select
these addresses from the appropriate subnet, and record this information in
Central Dispatch also requires that IP addresses be assigned to each of the machines
with which it interacts. These IP addresses must all be on the same subnet and use
the same subnet mask.
To assign static IP addresses to your servers

1 Follow the documentation provided by your hardware and operating system
vendors to configure each network adapter card with the appropriate static IP
address that you recorded on the Deployment Planning Worksheet.
2 Double-check to verify that each static IP was assigned to the correct machine
and that no static IP was assigned to more than one computer.
3 Verify the Gateway VIP was not assigned to any network adapter card.
Verifying Network Routes 4
Use the ping utility to ensure that all application servers have TCP/IP connectivity
to one another, as well as to the servers that will support the Siebel Database Server
and the Siebel File System.
You also need to make sure that the routes between all application servers are
symmetric. Symmetric routes are routes that, step for step, traverse the same
computers and the same network nodes in exactly the opposite order with respect
to each other.

To verify that routes between application servers are symmetric

1 On the computer that will support the primary Central Dispatch scheduler, open
a command shell window.
2 Use the traceroute command to display the route from that computer to one
of your application servers, as follows:
$ traceroute appserver
where:
appserver = the name or IP address of one application server machine.
3 From that application server, use the traceroute command to display the route
from it back to the machine that will host the primary Central Dispatch
scheduler.
4 Compare the results of each traceroute and verify that the routes between
these servers are symmetric.
Following is an example of a set of symmetrical traceroute results between two

servers named demaine and windsor. The first set of results shows the network
route from demaine to windsor, and the second shows the route from windsor
to demaine:
$ traceroute windsor
traceroute to windsor [10.0.16.9] 30 hops max, 40 byte packets
1 demaine [10.1.24.250] <10 ms <10 ms <10 ms

2 10.1.24.221 <10 ms <10 ms <10 ms
3 windsor [10.0.16.9] <10 ms <10 ms <10 ms
$ traceroute demaine
traceroute to demaine [10.1.24.250] 30 hops max, 40 byte

packets
1 windsor [10.0.16.9] <10 ms <10 ms <10 ms

2 10.1.24.221 <10 ms <10 ms <10 ms
3 demaine [10.1.24.250] <10 ms <10 ms <10 ms
NOTE: On different UNIX platforms, the format of the traceroute command’s

output may vary slightly.

5 Repeat these steps from your primary Central Dispatch scheduler for each
application server machine you have.
6 From the secondary Central Dispatch scheduler, repeat this process with each
application server.
If you find asymmetric routes between any two servers, you need to adjust your
routing so that the routes are symmetric. You might have to delete static route tables
and redo the routes or restart the router in order to get a symmetric route.
After you have verified network routes on all application servers, you are ready to
install Central Dispatch.

Installation Tasks
You must install Central Dispatch on each computer that will support a Siebel Server
or Siebel Gateway Server, and the Central Dispatch primary scheduler and backup
scheduler. Complete the following steps to install Central Dispatch.
NOTE: You must log on as root or superuser to install Central Dispatch; it cannot be
installed from a normal user account.
To install Central Dispatch

1 Insert the Siebel Server UNIX CD-ROM into the CD-ROM drive of the application
server on which you will install Central Dispatch.
2 Log onto the application server as root.

3 Open a terminal window on the application server and navigate to the following
directory on the CD:
/seaunix6xx/unix/thirdpty/language/resonate/operating_system
4 Type ./install-cd-commander and press ENTER to start the Resonate

installation script.
The Resonate installation script will prompt you to fill in the information it needs
to install Central Dispatch properly on your system.
If you have further questions, see the Resonate Central Dispatch Installation
Guide, available on the Siebel Bookshelf in pdf format.
5 Install only the following Resonate components when prompted by the Resonate
installation script:
Central Dispatch Node
Management Tools
CDAction
Dispatch Manager
NOTE: Do not try to enable Resonate’s “shadow scheduling” option; Siebel does
not use Central Dispatch’s persistent sessions feature.

Do not proceed with this section until you have installed Central Dispatch on all
application servers in your deployment, using the instructions in “Installation
Tasks” on page 4-9.
The post-installation tasks consist of the following:
“Configuring Central Dispatch”

“Configuring Server Components” on page 4-13
“Choosing a Scheduling Policy” on page 4-14
“Choosing a Load-Balancing Policy” on page 4-14
“Reconfiguring Central Dispatch” on page 4-14
“Reinstalling Central Dispatch” on page 4-16
Configuring Central Dispatch 4
After you have completed the installation of Central Dispatch on all application
servers, you need to configure it using the Resonate Dispatch Manager application.
During this configuration step, you will define a Central Dispatch site that includes
the static IP addresses used by the application servers and the Gateway VIP.
You will configure the Central Dispatch site only once, from any one Siebel Server
within the Enterprise Server. Central Dispatch automatically shares and updates
configuration information across all Central Dispatch nodes in the site.
The Dispatch Manager application is the same on the Windows NT and UNIX
platforms; this one set of instructions applies regardless of the platform on which
you are running Dispatch Manager.

To configure Central Dispatch

1 Start Dispatch Manager by navigating to the /bin subdirectory of your Resonate
installation and typing ./dispatch-manager to start the Dispatch Manager.
Dispatch Manager is a GUI-based program and therefore opens in a separate GUI

window.
2 In the Dispatch Manager Welcome dialog box, leave the Connect to Node field
empty and click OK.
NOTE: The Connect to Node field is left blank only the first time that you start
Dispatch Manager. After you have configured the Central Dispatch site, you must
specify the IP address of one of the system nodes or one of the VIPs in order to
connect to the site when starting Dispatch Manager.
3 In the Site Monitor dialog box, click Site Setup.

4 On the System Nodes tab, add the static IP addresses of all application servers
that will support a Siebel Server, Siebel Gateway Server, Central Dispatch
primary scheduler, or Central Dispatch backup scheduler. After entering each IP
address, click Add.
These IP addresses should have been recorded on a copy of the Appendix A,

“Deployment Planning Worksheet.” Accept the default values for Server Weight,
Server Enable, and Server Auto-enable.
Caution: You must have already installed Central Dispatch on

each of these application servers according to the instructions in
the previous section, or you will not be able to configure Central
Dispatch.
NOTE: Enter the static IP address, not the name of the machine to which it is
assigned, in the Node Name field. The use of hostnames can cause
inconsistencies in routing, depending on the operation of your DNS servers.

5 On the Virtual Hosts tab, add the Gateway VIP to the site:
a In the Virtual Host Name field, enter the VIP address.
b From the Primary Scheduler list, select the static IP address of the application
server that will serve as the primary Scheduler node.
c In the Alternate Scheduler list, select the static IP address of a second

application server to serve as the alternate Scheduler node.
d Click Add to add the VIP.

6 On the Licensing tab, enter the license key in the New Key field.
The license key is stored in the license.txt file in the
/thirdpty/language/resonate subdirectory of your Siebel eBusiness
Applications CD-ROM.
Be sure to press ENTER after entering the license key.
7 On the Operation tab, click Start Site.

8 Type the password for the Siebel service owner account.
9 After the Central Dispatch software has started, close Dispatch Manager.
Central Dispatch Configuration Tips

Review the following configuration tips when setting up your Central Dispatch site:
Do not change the server weight to redistribute the Central Dispatch connection
weight by entering a value in the Server Weight field of Dispatch Manager, as
described in the Resonate Central Dispatch User Guide. Instead, use the Siebel
parameter MaxTasks for an asymmetric distribution of connections. For
information on the use of this parameter, see the Siebel Server Administration
Guide.
If you have a dedicated scheduler, do not enable it as a server.

You do not need to configure Resonate’s class of service (COS) or thresholds to
configure scheduling rules, since Siebel eBusiness Applications does this
dynamically.

You do not need to mark a node that does not need Resonate software installed
as an affiliate node, as described in the Resonate Central Dispatch User Guide.
Siebel software does not support affiliated nodes.
Do not enable Central Dispatch’s shadow scheduling feature.
Configuring Server Components 4
All Siebel components that can take advantage of load balancing are enabled by
default to make use of connection brokering.
If, for any reason, you need to disable connection brokering on a particular
component, follow the instructions below after you complete installation of the
Siebel Enterprise Server and Siebel Server. To do this, set the Load Balanced
parameter for the component to FALSE.
To modify the component parameters

1 From the Siebel Administration client, choose Screens

Server Administration Components Component Parameters.
2 In the Server Components list, select the component you want to modify.
3 In the Component Parameters list, choose Load Balancing and change its value
to FALSE.
4 To save your changes, step off the row by selecting a different record. This will
force the server to implement your changes.

Choosing a Scheduling Policy 4
When the Central Dispatch scheduler receives an incoming request, it determines

which node or set of nodes is qualified to respond to the request. Central Dispatch
allows you to choose between two types of scheduling policy to determine this—
round-robin or resource-based scheduling. You must select resource-based
scheduling to take advantage of Central Dispatch’s load-balancing features with
Siebel eBusiness Applications.
For more information on Central Dispatch scheduling policy, see the Resonate
Choosing a Load-Balancing Policy 4
When you select Central Dispatch resource-based scheduling, you must also select
a load-balancing policy. (Round-robin scheduling does not require load balancing.)
Select CPU Load and Connections (enhanced) as your load-balancing policy.
For more information on Central Dispatch load-balancing policy, see the Resonate
Reconfiguring Central Dispatch 4
After Central Dispatch has been installed and configured, its ongoing configuration
and operation are handled primarily by the Siebel Server software. You can use
Dispatch Manager to monitor the operation of your Central Dispatch server, as
described in the Resonate documentation, but you will not need to change the
configuration manually during normal operations.
The exception to this occurs if you need to add application servers to your
Enterprise Server or to remove them. In this case, follow the procedure below.

To remove an application server

1 If you are removing a static IP address assigned to an application server running
a Siebel Gateway or Siebel Server:
a Stop the Siebel Server, the Siebel Gateway, or both (in that order) in that node
before removing the IP address.
b Using Resonate Dispatch Manager, verify that none of the scheduling rules
contain the static IP address, or node, you want to remove. If it does, you
must manually remove the node. To do so, refer to the Resonate Central
Dispatch User Guide under “Changing and Deleting Scheduling Rules.” This
book is available in pdf format on your Siebel eBusiness Applications Server
Installation CD-ROM under Thirdpty\language\Resonate.
NOTE: Under normal circumstances, manual removal of the node from a

scheduling rule should not be necessary and would primarily be required only
if a server did not shut down properly.
2 Remove the static IP addresses assigned to each server from the System Nodes
tab of the Site Setup dialog box in Dispatch Manager, as described in
“Configuring Central Dispatch” on page 4-10.
To add an application server

1 Add the static IP addresses assigned to each server from the System Nodes tab
of the Site Setup dialog box in Dispatch Manager, as described in “Configuring
Central Dispatch” on page 4-10.
2 Verify that the correct static IP address is assigned to each server and that no
static IP address is used more than once.

Reinstalling Central Dispatch 4
You will need to reinstall Central Dispatch if you change your network or hardware
configuration.
To reinstall Central Dispatch

1 Stop all Siebel and any Central Dispatch services on all nodes.
2 Uninstall any Siebel components already installed on the node (or nodes) where
reconfiguration will occur. (For information regarding uninstalling Siebel
programs, see Chapter 24, “Uninstalling Siebel eBusiness Applications.”)
3 Uninstall Central Dispatch. See the Resonate Central Dispatch Installation Guide,
available on the Siebel Bookshelf in pdf format.
4 Perform the required network or hardware configuration on the affected node

(or nodes.)
5 Reinstall Central Dispatch on the node (or nodes) on which you formerly had it
installed, following the instructions provided earlier in this chapter.
NOTE: Use the same Resonate Administrator password that was used previously.
6 Verify that the installer has installed Resonate in the correct location.
7 Verify that the reconfigured node is part of the Central Dispatch site.
If it is not, refer to “Configuring Central Dispatch” on page 4-10.
8 Start the Central Dispatch site, according to instructions in “Configuring Central

Dispatch” on page 4-10.
9 Reinstall any Siebel components that you had previously uninstalled. (Refer to
the other chapters in the guide for information on their installation.)
10 Restart all Siebel services on all nodes.

Installing the Siebel Gateway Server
Under Windows NT 5

Installing a Redundant Disk Array . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Creating a File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Reviewing the Use of Connection Brokering . . . . . . . . . . . . . . . . . . . 5-6
Verifying Gateway Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . 5-6

Installing the Siebel Gateway Server Under Windows NT
About This Chapter
This chapter explains how to set up a Siebel File System and install the Siebel
Gateway Server on the Windows NT server platform.
You must create a separate File System for each Siebel database tableowner. For
example, if you have development and test databases, you must have two separate
File Systems. When you configure the Siebel client to point to these different
databases, be certain that it points to the correct File System for each database.
This chapter assumes you are familiar with the Siebel File System and Siebel
Gateway Server and their functions. See Chapter 1, “Overview,” for introductory
information if you are unfamiliar with these components and their functions within
the Siebel product.
NOTE: Siebel Systems does not support running different versions of Siebel
eBusiness Applications concurrently through the same Gateway Server.

Perform the following tasks before running the Gateway Server installation
program:
“Installing a Redundant Disk Array” on page 5-3

“Creating a File System” on page 5-4
“Reviewing the Use of Connection Brokering” on page 5-6
“Verifying Gateway Server Prerequisites” on page 5-6
Installing a Redundant Disk Array 5
The Gateway Server maintains the configuration information for all Siebel Servers
in all the Enterprise Servers it manages. Loss of the Gateway Server due to a disk
crash could bring your Siebel software to a halt while the system is restored.
Similarly, the Siebel Server temporarily stores transaction files synchronized to and
from Siebel Remote mobile users. The loss of these files will result in the need to
re-extract the database for all affected mobile users.
Siebel Systems strongly recommends that you install a redundant disk array (RAID)
or some other type of redundant disk configuration on your Siebel Gateway Server
and on those Siebel Servers that will support the Siebel Remote product. (Siebel
Remote supports synchronization of data between Siebel Mobile Clients and the
Siebel Database Server through a dial-up connection.) A redundant disk
configuration substantially reduces the risk of data loss and minimizes the difficulty
of error recovery for both types of server. Refer to your hardware vendor’s
documentation and your operating system documentation for instructions on how
to install and configure a redundant disk array.
Verify that the network names of the servers that will support the Siebel Gateway
Server and all Siebel Servers are recorded in Appendix A, “Deployment Planning
Worksheet.” You will require this information later when installing the Siebel
Servers and Siebel clients.

Creating a File System 5
The Siebel File System consists of a shared directory that is network-accessible to

Siebel Dedicated Clients and to Siebel Servers. The File System may be installed on
the same server as a Siebel Server or Siebel Database Server, or it may be on another
network server using any operating system that supports Windows NT–type long,
case-sensitive filenames, and directory sharing with both Siebel clients and Siebel
Servers.
You must create a separate File System for each Siebel database tableowner, also
known as the database owner. For example, if you have development and test
databases, you must have two separate File Systems. When you configure a Siebel
Dedicated Client to point to one of these databases, you must also configure it to
point to the correct File System for the database it uses.
NOTE: You must install and start only one Gateway Server for each Siebel Enterprise
Server and Database Server that you are implementing.
You can name this directory anything you like, except that the name must contain
neither special characters nor spaces. Siebel Systems recommends that you use an
UNC (Universal Naming Convention) sharename.
The remainder of this document refers to this directory as
\\SiebelFS\siebel6xx
where:
SiebelFS is the host name of the machine (assuming that a dedicated machine is
used for the Siebel File System)
and
siebel6xx is the name of the share.
You will need to specify the UNC sharename when installing the Siebel Server and
Siebel Dedicated Clients.

To set up the File System

1 Create the directory in the location listed in Appendix A, “Deployment Planning
Worksheet.”
2 Run Windows Explorer.

3 Choose File Properties Sharing, and select Shared As.
4 Type a name for the shared volume.
You may want to type the number of the Siebel release you are installing in the
Comments field for future identification. However, completion of the field is not
required.
NOTE: When installing a new file system, do not change the default setting for
Maximum Allowed.
5 To grant UNC access to every Siebel Server and Client, click Permissions and
choose the appropriate group name.
This group name will be “Everyone” on many systems.
6 From the Type of Access list, choose Full Control.

7 From the Security tab, click Permissions.
8 To grant NT access to each Siebel Server and Client, click Permissions and
choose the appropriate group name.
This group name will be “Everyone” on many systems.
9 From the Type of Access list, choose Full Control.

10 To close the Permissions and File Properties dialog boxes, click OK.

Reviewing the Use of Connection Brokering 5
You must be certain that you will not use connection brokering before you proceed
with the Gateway Server installation without Central Dispatch installed. If Central
Dispatch is not installed prior to installing the Gateway Server and you later elect
to use connection brokering, you will have to remove and reinstall the Gateway
Server and all Siebel Servers after installing Central Dispatch.
Verifying Gateway Server Prerequisites 5
Verify that the application server computer that will host the Gateway Server meets
hardware and operating system requirements for your chosen platform, as detailed
in Siebel System Requirements and Supported Platforms. If the application server
will also support a Siebel Server, it must also have all the required third-party
products installed, as listed in Siebel System Requirements and Supported Platforms.
Each application server that will support a Siebel Server must have TCP/IP network
connectivity to the machine on which the Gateway Server will be installed. Verify
network connectivity between all application servers, using the ping utility.
If you are using connection brokering, make sure that Resonate Central Dispatch is
installed on the application server that will support the Gateway Server, as well as
on all application servers that will support Siebel Servers.

Installation Tasks
This section provides instructions for installing and starting the Gateway Server on
the Windows NT platform.
Caution: Install the Gateway Server only once for each Siebel
installation using a common database owner. Only one Gateway
Server may be installed on a physical application server.
To install the Siebel Gateway Server

1 Insert the Siebel Windows Server Programs CD-ROM into the CD-ROM drive of
the chosen application server (assumed here to be D:).
2 In Windows NT Explorer, navigate to the directory D:\gtwysrvr and double-

click Setup.exe.
The Welcome screen appears.
3 Read the Welcome screen and click Next to continue with the setup program.
If you do not yet have Resonate Central Dispatch installed, the installer prompts
you as to whether you would like to continue installation without it.
NOTE: Siebel Systems strongly recommends that you install Resonate Central
Dispatch to take advantage of the higher availability and scalability its
connection brokering features offer enterprise deployments.

Installation Tasks
4 Indicate whether or not you want to continue with the installation without
Resonate Central Dispatch being installed:
To continue without installing Central Dispatch, click Yes.
To stop the installation to install Central Dispatch, click No.
Caution: If you install the Gateway Server without having Central

Dispatch installed and later elect to enable connection
brokering, you will need to reinstall the Gateway Server and all
Siebel Servers after you have installed Central Dispatch.
The Select Destination Directory screen appears.
By default, the setup program installs Gateway Server software in the

C:\sea6xx\gtwysrvr directory.
5 If desired, choose a different directory:

a Click Browse.
b Type the directory you recorded in Appendix A, “Deployment Planning
Worksheet.”
NOTE: This directory name must not contain spaces.
c Click Next.
The Gateway Server NT Account Information screen appears.
6 Accept the default NT Account Administrator name and domain account or type
new ones, based on the information you recorded in Appendix A, “Deployment
Planning Worksheet,” using the format DOMAIN\username.
The Gateway Server NT Services screen appears.

Installation Tasks
7 On the Gateway Server NT Services screen, click the Start Automatically check
box if you want the Gateway Server NT service to start automatically whenever
the Windows NT operating system starts up. To continue, click Next.
Caution: The Gateway Server NT service must be running before

any Siebel Server in the enterprise can be started. If you do not
set the Gateway Server to start automatically, you must
manually start it each time you restart your machine.
The Start Copying Files screen appears.
8 Use the Back button to review the settings you have selected. Click Next when
you are satisfied.
The Setup Status screen appears to show you installation progress.
When all required files have been installed, the Event Log screen appears.
9 Review the installation information to make sure everything is right, and click
Next to begin installing.
When the Gateway Server installation has completed installing and configuring
files, the Setup Complete screen appears.
10 To quit the installer, click Finish.
NOTE: As of version 6.0, the Siebel Gateway Server no longer appears in your
Windows NT Start menu under Programs.
The installer prompts you about whether or not you want to restart your
machine now or later.
11 Restart your machine before attempting to start the Siebel Gateway Server.
12 After restarting your machine, start the Siebel Gateway Server by navigating to

the Windows NT Start menu and choosing Settings Control Panel Services.
Select the Siebel Gateway Server and click Start.

Installation Tasks

Installing the Siebel Gateway
Server Under UNIX 6

Installing a Redundant Disk Array . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Creating a File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Reviewing the Use of Connection Brokering . . . . . . . . . . . . . . . . . . . 6-5
Verifying Gateway Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . 6-5

Starting the Gateway Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Configuring the Gateway Server for Automatic Start . . . . . . . . . . . . 6-12

Installing the Siebel Gateway Server Under UNIX
About This Chapter
This chapter describes how to set up a Siebel File System and install the Siebel
Gateway Server on a supported UNIX platform.
This chapter assumes you are familiar with the Siebel File System and Gateway
Server and their functions. See Chapter 1, “Overview,” for introductory information
if you are not.
Siebel Systems does not support running different versions of Siebel concurrently
through the same Gateway Server. You must install and start one, and only one,
Gateway Server for each Siebel Enterprise Server and Database Server that you are
implementing.
NOTE: Siebel Systems does not support running different versions of Siebel
concurrently through the same Gateway Server.

Perform the following tasks before running the Gateway Server installation
program:
“Installing a Redundant Disk Array” on page 6-3

“Creating a File System” on page 6-4
“Reviewing the Use of Connection Brokering” on page 6-5
“Verifying Gateway Server Prerequisites” on page 6-5
Installing a Redundant Disk Array 6
The Gateway Server maintains the configuration information for all Siebel Servers
in all the Enterprise Servers it manages. Loss of the Gateway Server due to a disk
crash could bring your Siebel software to a halt while the system is restored.
Similarly, the Siebel Server temporarily stores transaction files synchronized to and
from Siebel Remote mobile users. The loss of these files will result in the need to
re-extract the database for all affected mobile users.
Siebel strongly recommends that you install a redundant disk array (RAID) or some
other type of redundant disk configuration on your Siebel Gateway Server and on
those Siebel Servers that will support the Siebel Remote product. (Siebel Remote
supports synchronization of data between Siebel Mobile Clients and the Siebel
Database Server through a dial-up connection.) A redundant disk configuration
substantially reduces the risk of data loss and minimizes the difficulty of error
recovery for both types of server. Refer to your hardware vendor’s documentation
and your operating system documentation for instructions on how to install and
configure a redundant disk array.
Verify that the network names of the servers that will support the Siebel Gateway
Server and all Siebel Servers are recorded in Appendix A, “Deployment Planning
Worksheet.” You will require this information later when installing the Siebel
Servers and Siebel clients.

Creating a File System 6
The Siebel File System consists of a shared directory that is network-accessible to

Siebel connected clients and to Siebel Servers. The File System can be installed on
the same server as a Siebel Server or Siebel Database Server, or it can be on another
network server, using any operating system that supports Windows NT–type long
case-sensitive file names and directory sharing with both Siebel clients and Siebel
Servers.
Although you are installing the Siebel Enterprise Server on UNIX, the Siebel
Dedicated Client and Siebel Tools workstations will run under Windows 95,
Windows 98, or Windows NT, and must be able to access the file system, so it must
use Windows NT-compatible file names.
You can name this directory anything you like. However, the name must contain
neither special characters nor spaces. Siebel Systems recommends that you use an
UNC (Universal Naming Convention) sharename.
The remainder of this document refers to this directory as
\\SiebelFS\siebel6xx
where:
SiebelFS is the host name of the machine (assuming that a dedicated machine is
used for the Siebel File System)
and
siebel6xx is the name of the share.
You will need to specify the UNC sharename when installing the Siebel Server and
Siebel Dedicated Clients.
For more information on installing Siebel Dedicated Clients, see Siebel Client
Installation and Administration Guide.

To set up the File System

1 Create the directory on the server and path you recorded in the copy you made
2 Use the appropriate administrative tools for your UNIX platform to set the
appropriate individual and group access parameters for the directories.
If an appropriate GUI-based administrative tool does not exist on your platform,

you can use the chmod and chgrp utilities to set these parameters. Consult your
UNIX documentation for more information.
Reviewing the Use of Connection Brokering 6
Before proceeding with the Gateway Server installation without installing Central
Dispatch, you must be certain that you will not use connection brokering. If Central
Dispatch is not installed prior to installing the Gateway Server and you later elect
to use connection brokering, you will have to remove and reinstall the Gateway
Server and all Siebel Servers after installing Central Dispatch.
Verifying Gateway Server Prerequisites 6
Verify that the application server computer that will host the Gateway Server meets
hardware and operating system requirements for your chosen platform, as detailed
in Siebel System Requirements and Supported Platforms. If the application server
will also support a Siebel Server, it must also have all the required third-party
products listed in Siebel System Requirements and Supported Platforms installed.
Each application server that will support a Siebel Server must have TCP/IP network
connectivity to the machine on which the Gateway Server will be installed. Verify
network connectivity between all application servers using the ping utility.
If you are using connection brokering, make sure that Central Dispatch is installed
on the application server that will support the Gateway Server, as well as on all
application servers that will support Siebel Servers.

Installation Tasks
This section provides instructions for installing and starting the Gateway Server on
supported UNIX platforms. The installation procedure is complex, especially if you
are using Resonate Central Dispatch, so follow it carefully.
Caution: The Gateway Server must be installed only once for each
Siebel installation that uses a common database and tableowner.
Only one Gateway Server can be installed on a physical application
server.
To install the Siebel Gateway Server installation script

1 Insert the Siebel eBusiness Applications version 6.x UNIX CD-ROM into the
CD-ROM drive of the chosen application server.
2 Log onto the server using the Siebel service owner account, and enter ksh to run
a Korn shell. Mount the CD-ROM, if required, to make it accessible.
The user ID and password should have been recorded in the copy you made
earlier of Appendix A, “Deployment Planning Worksheet.”
3 At the prompt, enter umask 027.

This ensures that the permissions mask for your installation shell is set
appropriately.
Caution: If you skip this step, the permissions will be set

incorrectly on your Siebel application’s installation files; this
will require you to reset them properly before continuing with
the installation.

Installation Tasks
4 Navigate to the following directory on the CD-ROM:

/seaunix6xx/operating_system/gtwysrvr
where:
operating_system is your specific UNIX operating system, such as Solaris.
NOTE: The volume label for the CD-ROM is seaunix6xx; it may not be required,
depending on how you access the CD-ROM.
5 To start the Gateway Server installation script, use either of the following
commands:
To install without creating an installation log, enter

./install/install_gateway
If you would like to generate an installation log to review after installation,

enter the following command, rather than the one above:
./install_gateway -d /usr/temp/gateway.log
The installation script has now been started. To complete the installation, you must
understand how to respond to the different types of prompts you will observe in the

Installation Tasks
Understanding the Prompts

The script uses three different styles of prompts:
The first prompt type. This type of prompt asks you to type the desired value for
a given parameter; the default value is shown in square brackets [ ].
Please specify the directory into which Siebel should be
installed [/siebel]
To accept the default value, press ENTER.
To change the default value, type the desired value, and then press ENTER.
The second prompt type. This type of prompt displays a list of one or more
parameter values and asks you whether you want to modify any of them:
To accept all of the existing values, press ENTER.
To change any of the values, enter Y.
You will see a series of prompts that allow you to change the value. For
example,
The indicated packages are selected for installation
[X] Siebel Server Executables
Would you like to accept these settings?

(Y to install files, N to change) [Y]
The third prompt type. This type of prompt provides a numbered list of options;
the default choice is shown in square brackets [ ].
To change the default value, enter the desired number.

Installation Tasks
To complete the installation using the script and prompts

1 At the first prompt, enter the desired installation directory (overriding the
default value of /siebel).
If the specified directory does not already exist, you will be prompted to confirm
that it should be created.
2 At the next prompt, indicate whether Resonate Central Dispatch has been
installed on this application server.
If it has, enter Y.
If it has not, press ENTER to accept the default of N.
If you indicated that Resonate Central Dispatch was installed, the installation
script will prompt you for the Resonate installation directory. If you did not
install Resonate Central Dispatch, proceed to Step 6 on page 6-10.
3 Fill in the value you recorded for the Gateway VIP in the copy you made of
The installation script prompts you for the Siebel service owner account
password.
4 Enter the Siebel service owner account password.

The script prompts you for the password again to confirm it.
The installation script next prompts you for the Gateway Server VIP.
5 Enter the Gateway Server VIP recorded in the copy you made of Appendix A,
The script prompts you to accept the default software packages you want to
install.

Installation Tasks
6 At the next prompt, install the Siebel packages you require.

If you need only the default packages, enter Y and continue with the
installation.
If you need additional packages, enter N.
If you enter N, you need to indicate that you accept (Y) or reject (N) each
package on the list; each package will be presented to you for your response.
The Siebel Gateway Server installation script then copies all the required files to
the application server, displaying a series of messages to indicate its progress.
The installation script prompts you to configure the Gateway Server for
automatic startup.
7 If you would like to configure the Gateway Server to start automatically, enter Y,
and then Y again to enable autostart.
If you do not want to configure the Gateway Server to start automatically,

enter N.
NOTE: This setting only enables the Gateway Server to accept additional
configuration instructions to start automatically each time the host machine
restarts. For automatic startup to actually execute, you must complete the
configuration steps described in “Configuring the Gateway Server for Automatic
Start” on page 6-12 after the Gateway Server installation is complete.
The installation script displays the message that the appropriate shell scripts
were created in your root directory, which enables setup of the environment
variables needed by Siebel eBusiness Applications. The installation script then
displays the message that Gateway Server installation is complete.

Perform the following tasks after running the Gateway Server installation program:
“Starting the Gateway Server”

“Configuring the Gateway Server for Automatic Start” on page 6-12
Starting the Gateway Server 6
The Gateway Server installation will automatically start the Gateway Server. The
Gateway Server must be started and available for you to continue with the Siebel
installation process. Complete the following steps to verify that the Gateway Server
has been properly installed and started.
To verify Gateway Server operation

1 Open a UNIX shell window and enter ksh to run a Korn shell.
2 Navigate to the SIEBEL_ROOT directory and enter . ./siebenv.sh to execute
the Siebel environment script in your terminal window.
NOTE: Be sure there is a space between the first period and ./siebenv.sh.
This sets the Siebel environment variables and path information required to use
Siebel utilities.
NOTE: You may wish to set the Siebel environment script to be automatically
executed when a Siebel administrator logs on. To do this, specify the Korn shell
as the default shell for administrator accounts and add this command to the
startup file for the administrator’s account.

3 Enter ./bin/list_ns to verify that the Gateway Server is running.

You should receive a response similar to this:
started at Fri Apr 21 15:33:26 2000, pid: 4024, autostart: yes
If the Gateway Server is stopped, do the following:
a Execute the ./bin/start_ns command to start the Gateway Server.

b Execute ./bin/list_ns to verify that it is operating correctly.
Configuring the Gateway Server for Automatic Start 6
If, during installation, you elected automatic restart of the Gateway Server every
time your system starts, follow the procedure below to implement this under UNIX.
To configure the Gateway Server to start automatically

1 Log on as root to the application server on which the Gateway Server was
installed.
2 Copy the file $SIEBEL_ROOT/bin/siebel_server to the /etc/init.d

directory as shown below:
cp $SIEBEL_ROOT/bin/siebel_server /etc/init.d
3 Set the appropriate permissions by executing the following command:

chmod 744 /etc/init.d/siebel_server
4 Create a hard link from:

/etc/rc3.d/S72siebel
to:
/etc/init.d/siebel_server
by executing the command:
ln /etc/init.d/siebel_server /etc/rc3.d/S72siebel


/etc/rc0.d/K32siebel
to:
ln /etc/init.d/siebel_server /etc/rc0.d/K32siebel
NOTE: You must use the actual path for SIEBEL_ROOT when copying the file and
creating the links.
You have now enabled the Siebel Gateway Server to start automatically when you
restart your system, and to stop automatically when you shut down.
NOTE: Remember that the host where the Siebel Gateway Server is installed must be
the first to start up and the last to be shut down.
You are now ready to proceed with the Siebel Server installation.


Installing the Siebel Server
Part 2
Chapter 7. Installing the Siebel Server Under Windows NT
Chapter 8. Installing the Siebel Server Under UNIX

Installing the Siebel Server Under Windows NT 7

Verifying Siebel Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Verifying Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Verifying Central Dispatch Installation . . . . . . . . . . . . . . . . . . . . . . . 7-8
Starting the Gateway Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Starting the Siebel Server NT Service . . . . . . . . . . . . . . . . . . . . . . . . . 7-17

Verifying the Siebel Server ODBC Data Source . . . . . . . . . . . . . . . . 7-18
Establishing Network Connectivity for Mobile Users . . . . . . . . . . . . . . . . .7-19
Enabling Siebel Server Component Groups . . . . . . . . . . . . . . . . . . . 7-19

Installing the Siebel Server Under Windows NT
About This Chapter
This chapter describes the tasks involved in installing the Siebel Server software on
a Windows NT server and configuring the Enterprise Server for this platform.
Perform the following tasks before running the Siebel Server installation programs:
“Verifying Siebel Server Prerequisites”

“Configuring Database Connectivity Software” on page 7-3
“Verifying Network Connectivity” on page 7-6
“Verifying Central Dispatch Installation” on page 7-8
“Starting the Gateway Server” on page 7-8
Verifying Siebel Server Prerequisites 7
Be sure that all application servers onto which the Siebel Server will be installed
meet the hardware and software requirements detailed in Siebel System
Requirements and Supported Platforms.
The Siebel Server installation process must be completed on each application server
that will operate a Siebel Server.
Every Siebel Server that supports a given Database Server must belong to the same
Enterprise Server. When you install the first Siebel Server within an Enterprise
Server, you will be prompted to configure the Enterprise Server. Additional Siebel
Servers installed into that Enterprise Server automatically inherit the Enterprise
Server parameters.
The Windows NT Server installation process must be run once for each Siebel
Server. The Enterprise Server, if it does not already exist, and the Siebel Servers are
configured automatically during this installation process.

Configuring Database Connectivity Software 7
Microsoft SQL Server. No configuration is required after the Microsoft SQL Server
ODBC driver specified in Siebel System Requirements and Supported Platforms has
been installed on each application server. Siebel automatically creates an ODBC
data source using connectivity parameters that you will specify during installation
of the Siebel Server.
Oracle. Verify that the Oracle SQL*Net database connectivity software is installed on
each application server, according to the Oracle documentation. See Siebel System
Requirements and Supported Platforms for database connectivity software
requirements.
Prior to installing the Siebel Server and Siebel Enterprise Server, you must use the
Oracle SQL*Net Easy Configuration utility to define a database alias with the proper
connection information for your Siebel Database Server, if you have not already
done so. Record the connect string in Appendix A, “Deployment Planning
Worksheet.” You will specify this connect string when installing the Siebel Server.
DB2 UDB. Define a database alias with the proper connection information for your
database. This alias will be the connect string used when installing the Siebel
Server. Record the connect string in Appendix A, “Deployment Planning
Use either the DB2 Client Configuration Assistant or the Command Line Processor
to define your database alias. For more information, see the IBM DB2 Universal
Database Quick Beginnings manual for NT or the IBM DB2 Universal Database
Command Reference.
DB2 UDB for OS/390. To install the Siebel database server on DB2 UDB for
OS/390, you must execute scripts for this purpose on a client application server and
transfer the sql file output to the mainframe. To accomplish this, you may use one
of the two following methods from your Siebel installation at mid-tier to transfer the
files to DB2 UDB for OS/390:
Install DB2 Connect and configure ODBC to transfer files to the mainframe, and
use an ODBC utility, such as odbcsql.exe, or a version control tool for file
execution.
Install TCP/IP and use ftp to transfer files to the mainframe. Use an IBM utility
such as SPUFI for file execution.

DB2 Connect. Two configuration methods exist for using DB2 Connect to connect
to DB2 UDB for OS/390 from the mid-tier. The configuration method you choose
will depend on whether you are connecting from an application server or from
a Siebel dedicated client.
A Siebel dedicated client can use either the DB2 Connect Personal or Enterprise
Edition, while the application server will always use the DB2 Connect Personal
Edition.
You can use a two-tiered connection by installing DB2 Connect Personal Edition
on the DB2 client machine to connect directly to the mainframe host.
For high-volume network traffic, you can, instead, use a three-tiered connection
by installing DB2 Connect Enterprise Edition on a gateway and DB2 runtime
clients on the Siebel clients. For more information about DB2 Connect, refer to
the “DB2 Connect: Planning and Installation” chapter in IBM’s Quick Beginnings
for DB2 Connect.
To connect to DB2 UDB for OS/390 from a Siebel application server

1 Install DB2 Connect Personal Edition on your application server, following the
vendor’s instructions.
2 Upgrade DB2 Connect Personal Edition to the appropriate fixpack. For

information regarding the supported fixpack version, refer to Siebel System
If you have previously installed a runtime client, the DB2 Connect installer
upgrade adds only that functionality required for the existing client. (This is also
the case if you have a DB2 server or SDK installed on your workstation.)
3 Catalog your DB2 UDB for OS/390 databases, using the DB2 Command Line
Processor or the Client Configuration Assistant.

To connect to DB2 UDB for OS/390 from a gateway

1 Install DB2 Connect Enterprise Edition on a gateway machine. (This machine
functions essentially as a DB2 UDB server with protocol support for DB2 UDB
for OS/390.)
You can also add DB2 Connect to an existing server with DB2 already installed.
2 On the gateway machine, upgrade DB2 Connect Enterprise Edition to the

appropriate fixpack. For information regarding the supported fixpack version,
refer to Siebel System Requirements and Supported Platforms.
3 Catalog your DB2 UDB for OS/390 databases on the gateway machine, if desired,
using the DB2 Command Line Processor or the Client Configuration Assistant.
(After installation, you can use your standard DB2 UDB client to access the
gateway.)
NOTE: This gateway can coexist in the same instance as a DB2 UDB server.
4 On the client, catalog the DB2 UDB for OS/390 database you cataloged in Step 3,
using either the DB2 Command Line Processor or the Client Configuration
Assistant, against the gateway machine.
Defining a database alias. Define a database alias with the proper connection
information for your database. This alias will be the connect string used when
installing the Siebel Server. Record the connect string in the copy you made of
Appendix A, “Deployment Planning Worksheet.” You will specify this connect
string when installing the Siebel Server.
Use either the DB2 Client Configuration Assistant or the Command Line
Processor to define your database alias. For more information, see the DB2
Universal Database for OS/390 Administration Guide.

Enabling ODBC. If you are connecting to the mainframe, using DB2 Connect, you
must enable ODBC to point to DB2 UDB for OS/390.
To enable ODBC to point to the mainframe, bind the CLI/ODBC Support

packages, using the Client Configuration Assistant’s Bind option.
TCP/IP and ftp. For instructions on installing TCP/IP, refer to IBM’s DB2 for
OS/390 Installation Guide.
Verifying Network Connectivity 7
You must verify that your servers are properly connected to the network and,
through the network, to each other.
To verify network connectivity between Siebel Servers and the Gateway Server,
Database Server, and File System
1 Verify network connectivity to the Gateway and Database Servers from the
application servers, using the test utility for your network type. For TCP/IP
networks, use the ping utility to verify network connectivity to the Database
and Gateway Servers.
2 Verify connectivity to the Database Server:

Microsoft SQL Server. Use the Control Panel - ODBC icon to verify that the
proper ODBC driver has been installed and to create and test a data source
to your database server.
Oracle. Use the tnsping utility and SQL*Net database alias from a Command
Prompt window to make sure that you can connect to the database, using the
network connect string that you defined in the previous step.
DB2 UDB for UNIX, Windows NT, and OS/390. Use a DB2 Command Window to
ensure that you can connect to your database.

Choose Start Programs DB2 for Windows NT Command Window, and

type:
DB2 connect to database alias user user_ID using password
where:
user_ID is a valid user name on DB2, and password is the appropriate

password for that user name.
If your connection is valid, you should see a message that looks like the
following:
Database Connection Information
Database server = DB2/6000 6.x.x

SQL authorization ID = SIEBEL
Local database alias = SIEBELDB
If your connection is not valid, verify your configuration.
Caution: Be sure to use the Command Window for this

procedure and not the Command Line Processor window that
appears directly above it. The Command Line Processor
window looks similar to a Command Window, but it uses
slightly different syntax. For this procedure, the commands
will not work in a Command Line Processor window; they
must be issued in a Command Window.
To close the connection, type db2 terminate.
NOTE: You can also use the DB2 Command Center GUI tool to do this.
The Siebel Server installation will create its own ODBC data source.

3 The Siebel Server must also have a network connection to the File System. Use
one of the following methods to configure network connectivity:
Access to the Siebel File System directory as a network shared drive or

device. The syntax for this connection will vary depending on the operating
system of the server on which the File System is deployed. For Windows NT
UNC shares, for example, the syntax is \\servername\sharename.
A drive letter (for example, K:\) on the application server that is mapped to
the Siebel File System directory.
Caution: If this method is used, the drive letter must be

permanently mapped to the File System, and the same drive
letter must be mapped on all application servers that will
support a Siebel Server. Because of these requirements, Siebel
Systems strongly recommends that you use an UNC sharename,
rather than a mapped drive letter, to connect to the File System.
Regardless of the method used to connect to the File System, verify that the File
System directory is visible and that the Siebel service owner account can copy
files to and from it.
Network connectivity to the Gateway Server, Database Server, and File System
is now verified.
Verifying Central Dispatch Installation 7
If you will be using connection brokering, make sure that Central Dispatch has been
installed and configured on each application server that will support a Siebel Server.
You will be unable to complete the Siebel Server installation if the Gateway Server
is not running. Make sure that the Gateway Server has been started by checking the
Services dialog box, reached through the Windows NT Control Panel.

Installing the Siebel Server 7
Run the Siebel Server installation program for each Siebel Server that will be
installed on a Windows NT application server.
The Siebel Server installation program performs the following tasks:
Sets up its own directory structure.

Copies the software to the disk.
Installs the Siebel Server NT service and the Siebel Server components.
Configures the Enterprise Server (if required) and the Siebel Server.
NOTE: The term Enterprise Server is used by Siebel to refer to a group of Siebel
Servers that can be administered and configured as a unit rather than individually.
It does not refer to a separate computer or separate program.
Therefore, when you install the first Siebel Server in your deployment, you
automatically configure the Siebel Enterprise Server. All subsequent Siebel Servers
installed that connect to the same database must be installed under this Enterprise
Server.
To install the Siebel Server

1 Make sure that you have installed the Siebel Gateway Server and that it is
running.
2 Shut down all open programs running on the application server.

3 Stop any active Siebel Server NT services, except the Siebel Gateway Server.
4 Start the Server Installation Program:
a Insert the Siebel Windows Server Programs CD-ROM in the CD drive of the
application server (assumed in these instructions to be D:\).
b In Windows NT Explorer, navigate to the D:\siebsrvr directory and double-

click Setup.exe to start the server installation program.

If you do not yet have Resonate Central Dispatch installed, the installer prompts
you as to whether you would like to continue installation without it.
NOTE: Siebel Systems strongly recommends that you install Resonate Central
Dispatch to take advantage of the higher availability and scalability its
connection-brokering features offer enterprise deployments.
6 Indicate whether or not you want to install Resonate’s Central Dispatch at this
time:
To continue without installing Central Dispatch, click Yes.
To stop the installation to install Central Dispatch, click No.
Caution: If you install the Siebel Server without having Central

Dispatch installed and later elect to enable connection
brokering, you will need to reinstall the Gateway Server and all
Siebel Servers after you have installed Central Dispatch.
For instructions on how to install Central Dispatch, see Chapter 3, “Installing

Central Dispatch Under Windows NT.”
The Start the Siebel Gateway Server screen appears.
7 The installer prompts you to verify that the Siebel Gateway Server is running.
The Siebel Gateway Server must be running to continue with the Siebel Server
installation.
If the Gateway Server is already running, click Next.
If it is not, start it, return to this prompt, and click Next to continue.
The Setup Type screen appears.

8 Choose the type of Siebel Server installation to execute from the following
options, and then click Next to continue:
Typical. This setup option will install all Siebel Server components except
those for Siebel Marketing and the configuration files for Siebel Data Quality.
See the Siebel Marketing Guide for more information on Siebel Marketing
components.
Compact. This setup option will install a minimal subset of only those
components necessary to run the Siebel Server, but no additional
components or help.
Custom. This setup option lets you customize your installation by choosing
the specific components you want to install.
NOTE: If you want to install Siebel Marketing, you must first choose Custom
Setup and then choose it from the list of options.
Setup installs the applicable files in the default directory C:\sea6xx\siebsrvr

unless you specify a different directory, using the Browse button.
If you specified the location of an existing Siebel Server installation, the installer
prompts you to remove the previous installation.
9 To remove the previous installation, from the Windows Start menu, select

Settings Control Panel Add/Remove Programs.
Select the appropriate Siebel Server and remove it.
The Gateway Server Address screen appears.
10 On the Gateway Server Address screen, type the host name or the static IP
address of the application server on which the Gateway Server was installed and
is running.
To continue, click Next.
The Enterprise Server Information screen appears.

11 Type the following parameters in the Enterprise Server Information screen:

a Name. The name of the Enterprise Server. All Siebel Servers connecting to a
common database server must be installed under the same Enterprise Server.
Its name must be unique on the Gateway Name Server.
b Description. If this is a new Enterprise Server, add a description for it.

c To continue, click Next.
This name must not contain special characters or spaces and must be unique
within the Siebel Enterprise Server.
If this is a new Enterprise Server, Setup prompts you that the specified Enterprise
Server was not found.
If you are installing into an existing Siebel Server, proceed to Step 16 on

page 7-14.
12 To create the new Enterprise Server, click Yes.
NOTE: If you receive an error message that the Gateway Server could not be
found, it has probably not been started. Start the Gateway Server from the

Windows Services dialog box, by navigating to Start Settings

Control Panel Services. Then, continue with installation.
The Siebel File System Location screen appears.
13 Specify the path to the Siebel File System.

This directory will contain files associated with your Siebel components. You
may either use an UNC share name or specify a drive letter. This should be the
directory you recorded in Appendix A, “Deployment Planning Worksheet.”
NOTE: This directory name must not contain spaces.
The Server Database screen appears.

14 Choose the database server you will be using, and then click Next.
The Database Identification screen appears.
15 Complete the Database Identification screen as follows, using the information

you recorded in Appendix A, “Deployment Planning Worksheet.”
Oracle:
Database Alias. Type the SQL*Net connect string for your Siebel database
server.
Tableowner. Type the name of the database account that owns the Siebel
tables.
Microsoft SQL Server:
Server Name. Type the network name or IP address of the database server
on which you are installing the Siebel database.
Database Name. Type the name of the SQL Server database where the
Siebel tables and indexes will reside.
DB2 UDB:
Database Alias. Type the database alias cataloged for your DB2 database.
Tableowner. Type the name of the database account that owns your Siebel
tables and indexes.
DB2 UDB for OS/390:
Database Alias. Type the database alias cataloged for your DB2 UDB for OS/
390 database.
tables and indexes.
SQL ID. Type the SQL ID that defines your RACF (or other security control
product) group. This grants ordinary user privileges for most users. The
default is SSEROLE.
The Server Database Account Information screen appears.

16 In the Server Database Account Information screen, type the administrator name
and password for the Siebel database account.
The default administrator name is SADMIN. If you want to change this, you must
create a new Siebel database account, using the grantusr.sql script, as
described in Part 3, “Configuring and Installing the Siebel Database Server.”
This account must be assigned to a Siebel account employee that has

administrator privileges.
The information gathered from this screen is used to verify version numbers and
to start Siebel Server components automatically.
The Siebel Server Information screen appears.
17 Specify a unique name and description for the Siebel Server you are installing.
This name must not contain special characters or spaces and must be unique
within the Siebel Enterprise Server.
The Siebel Server NT Service screen appears.
18 Specify whether you want service to start automatically. You may do one of two
things:
Accept the default for automatic startup.
Specify manual startup by deselecting this option.
The Synchronization Port Assignment screen appears.
19 Specify a unique port number for the default Synchronization Manager. To

continue, click Next.
All other default components will be configured to use dynamic ports.
The eBriefings and eContent Services screen appears.

20 Indicate whether you have bought Siebel eBriefings alone, Siebel eBriefings
together with Siebel eContent Services, or neither.
If you purchased a license for these options, the License Agreement screen
appears.
If you did not, after selecting “Neither,” continue to Step 24 on page 7-15.
The License Agreement screen appears.
21 Read the License Agreement screen and click Yes to continue.

The eBriefings Content Hostnames screen appears.
22 Complete the eBriefings Content Hostnames screen.

Type the full primary content hostname for your Siebel eBriefings Content
Server.
If applicable, type the secondary hostname. It is optional.
If you selected both eBriefings and eContent Services, the eBriefings Content
Host Username and Password screen appears.
23 Type the user name and password for the Siebel eBriefings content hosts. A user
name and password are issued to your company by Siebel Systems with your
purchase of Siebel eBriefings.
The Java Thin Client Help File URL screen appears.
24 If you are deploying the Java Thin Client, type the URL of the Java Thin Client
Online Help that your client will access.
This should be accessible to all Java Thin Client machines, for example:
http://www.siebel.com/JavaClient/help/start.html
If you do not have Java Thin Client installed on your system, leave this blank.

25 To continue, click Next.

The Start Copying Files screen appears.
26 On the Start Copying Files screen, review the settings you previously selected
from the list.
When you are satisfied with the settings, click Next to continue. Installation
starts.
The Setup Status screen appears, showing you the progress of installation.
When the installer finishes installing the required files, the Event Log appears.
27 Review the results of the installation in the Event Log screen, and then click
Next.
The Setup Complete screen appears.
28 To finish installation, click Finish.

29 Restart your machine.
NOTE: As of version 6.0, the Siebel Enterprise Server no longer appears in your
Windows NT Start menu under Programs.
Proceed to “Starting the Siebel Server NT Service” on page 7-17 to verify successful
installation of the Siebel Server.

Starting the Siebel Server NT Service
Starting the Siebel Server NT Service 7
After you have completed the installation of the Siebel Server, you must start the
Siebel Server NT service.
To start the Siebel Server NT service

1 From the Windows NT Start menu, choose Settings Control Panel Services.
2 On the Services screen, scroll to the Siebel Server service. The name of the
Service has the following format:
Siebel Server[enterprise server_siebel server]
where:
enterprise server = the name of your Enterprise Server.
siebel server = the name of the Siebel Server you have just installed.
3 To start the service, click Start.
Caution: If the Siebel Server NT service does not start, look in the NT
System, Application Event, and installation logs for error messages.
The installation log is called SVRsetup.log and is located in the
Siebel Server root directory.
To administer the Enterprise Server and all its Siebel Servers, you must install the
Server Manager administrator’s client software on the client PCs used by your Siebel
administrator. See the Siebel Client Installation and Administration Guide for
instructions on installing the Siebel Dedicated Client with the Server Manager
option.

Perform the following tasks after running the Siebel Server installation program:
“Verifying the Siebel Server ODBC Data Source”

“Establishing Network Connectivity for Mobile Users” on page 7-19
“Enabling Siebel Server Component Groups” on page 7-19
Verifying the Siebel Server ODBC Data Source 7
The Siebel Server installation program automatically creates an ODBC system data
source name (DSN) that it uses to connect to the Siebel Database Server.
To verify the ODBC data source

1 From the Windows NT Control Panel, choose ODBC Data Sources System
DSN. Review this data source; its default name is SiebSrvr_EnterpriseName.
2 Record the name of the ODBC data source in Appendix A, “Deployment

Planning Worksheet,” if you have not already done so.
You will need this information when you are installing the Siebel Database
Server.
NOTE: Siebel Systems does not recommend changing the default settings created
automatically with the ODBC data source.

Establishing Network Connectivity for Mobile Users 7
Siebel Mobile Client users must be able to connect to the Siebel Remote Server,
using TCP/IP to synchronize with the master database. Make sure that you have the
correct network software and hardware installed to support this connectivity, and
that your remote users are able to establish a TCP/IP connection to the server using
the ping utility.
Enabling Siebel Server Component Groups 7
Before you can operate Siebel component groups, you must enable them. Please
refer to the chapter “Using the Server Manager UI” under Component Group and
Server Component Administration in the Siebel Server Administration Guide for
instructions.
You are now ready to proceed with the installation of the Siebel Database Server.

Troubleshooting Central Dispatch Timeout Errors
Troubleshooting Central Dispatch Timeout Errors 7
If a Siebel Enterprise Server component does not start and you receive a Central
Dispatch command timeout error in the log file for that component, you can
increase your Central Dispatch timeout value, using the Siebel parameter
SCBtimeout.
NOTE: The default setting of this parameter is 300 seconds.
To verify the current SCBtimeout parameter setting

From the DOS Command Prompt window, enter the following command:
srvredit -g gateway address -e Siebel Enterprise name -s Siebel
Server name -c $server.SCBTimeout
where:
gateway address=the IP address of your Siebel Gateway Server
Siebel Enterprise name = the alias of your Siebel Enterprise Server
Siebel Server name = the alias of the Siebel Server in which the components
failed to start
If the default value has never been changed, the command will fail with the
following error:
Exited with error 5004

To increase the timeout value for a failed component

From the DOS Command Prompt window, increase the value of the parameter
by 60 seconds for each failed component by entering the following command:
Server name -r $server.SCBTimeout=new value -d int -f
where:
new value= the new timeout value that you want to apply in seconds, for
example, 360.
If, after trying this procedure, the component still does not start, contact Siebel
Technical Support.


Installing the Siebel Server Under UNIX 8

Verifying Siebel Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Configuring Database Connectivity Software . . . . . . . . . . . . . . . . . . . 8-3
Verifying Central Dispatch Installation . . . . . . . . . . . . . . . . . . . . . . . 8-8
Starting the Gateway Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8

Installing Siebel Server Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Creating Additional Servers Within an Existing Enterprise Server . . . 8-19

Verifying the Siebel Server ODBC Data Source . . . . . . . . . . . . . . . . 8-22
Managing Siebel Environment Variables . . . . . . . . . . . . . . . . . . . . . 8-23
Configuring the Siebel Server for Automatic Start . . . . . . . . . . . . . . 8-23
Establishing Network Connectivity for Mobile Users . . . . . . . . . . . . 8-25
Enabling Siebel Server Component Groups . . . . . . . . . . . . . . . . . . . 8-25

Installing the Siebel Server Under UNIX
About This Chapter
This chapter explains how to install the Siebel Server software on supported UNIX
platforms and how to configure the Enterprise Server.
The Siebel Server installation process must be completed on each UNIX application
server that will operate a Siebel Server. “Planning Your Siebel Deployment” on
page 2-5 provides guidance on determining the number and configuration of Siebel
Servers.
Enterprise Server, regardless of the platform on which the Siebel Servers are
operating. When you install the first Siebel Server within an Enterprise Server, you
will be automatically prompted to configure the Enterprise Server. Additional Siebel
Servers installed in that Enterprise Server automatically inherit its parameters.
On UNIX platforms, the Siebel Server software is installed only once on each
application server. As many Siebel Servers as desired are then configured to operate
from that single software installation. The Siebel Server and Enterprise Server can
be configured independently of software installation on UNIX platforms.

Perform the following tasks before running the Siebel Server installation programs:

“Configuring Database Connectivity Software”
“Verifying Central Dispatch Installation” on page 8-8
“Starting the Gateway Server” on page 8-8
Be sure that all application servers onto which the Siebel Server will be installed
meet the hardware and software requirements detailed in the Siebel System
The Siebel Server installation process must be completed on each application server
that will operate a Siebel Server.
Enterprise Server.
Oracle. Verify that the Oracle SQL*Net database connectivity software is installed on
each application server, according to the Oracle documentation. See the Siebel
System Requirements and Supported Platforms for database connectivity software
requirements.
Prior to installing the Siebel Server and the Siebel Enterprise Server, you must use
the Oracle SQL*Net Easy Configuration utility to define a database alias with the
proper connection information for your Siebel Database Server, if you have not done
so already. Record the connect string in the copy you have made of Appendix A,
“Deployment Planning Worksheet.” You will specify this connect string when
installing the Siebel Server.

DB2 UDB. Define a database alias with the proper connection information for your
database. This alias will be the connect string used when installing the Siebel
Server. Record the connect string the Appendix A, “Deployment Planning
Use the DB2 Command Line Processor (CLP) to define your database alias. For more
information, see the IBM DB2 Universal Database Command Reference.
DB2 UDB for OS/390. To install the Siebel database server on DB2 UDB for
OS/390, you must execute scripts for this purpose on a client application server and
transfer the sql file output to the mainframe. To accomplish this, you may use one
of the two following methods from your Siebel installation at mid-tier to transfer the
files to DB2 UDB for OS/390:
Install DB2 Connect and configure ODBC to transfer files to the mainframe, and
use an ODBC utility, such as odbcsql.exe, or a version control tool for file
execution.
Install TCP/IP and use ftp to transfer files to the mainframe, and use an IBM
utility such as SPUFI for file execution.
Installing DB2 Connect. Two configuration methods exist for using DB2 Connect
to connect to DB2 UDB for OS/390 from the mid-tier. The configuration method
you choose will depend on whether you are connecting from an application
server or from a Siebel dedicated client.
A Siebel dedicated client can use either the DB2 Connect Personal or Enterprise
Edition, while the application server will always use the DB2 Connect Personal
Edition.
You can use a two-tiered connection by installing DB2 Connect Personal Edition
on the DB2 client machine to connect directly to the mainframe host.
Alternatively, you can use a three-tiered connection by installing DB2 Connect
Enterprise Edition on a gateway for high-volume network traffic.

To connect to DB2 UDB for OS/390 from a Siebel application server

1 Install DB2 Connect Personal Edition on your application server, following the
vendor’s instructions.
2 Upgrade DB2 Connect Personal Edition to the appropriate fixpack. For

information regarding the supported fixpack version, refer to Siebel System
3 Catalog your DB2 UDB for OS/390 databases, using the DB2 Command Line
Processor.
To connect to DB2 UDB for OS/390 from a gateway

1 Install DB2 Connect Enterprise Edition on a gateway machine. (This machine
functions essentially as a DB2 UDB server with protocol support for DB2 UDB
for OS/390.)
You can also add DB2 Connect to an existing server with DB2 already installed.
2 On the client, upgrade DB2 Connect Enterprise Edition to the appropriate

fixpack. For information regarding the supported fixpack version, refer to Siebel
3 Catalog your DB2 UDB for OS/390 databases on the gateway machine, if desired,
using either the DB2 Command Line Processor or the Client Configuration
Assistant. (After installation, you can use your standard DB2 UDB client to
access the gateway.)
NOTE: This gateway can coexist in the same instance as a DB2 UDB server.

4 On the client, catalog the DB2 UDB for OS/390 database you cataloged in Step 3
on page 8-5, using either the DB2 Command Line Processor or the Client
Configuration Assistant, against the gateway machine.
Defining a database alias. Define a database alias with the proper connection
information for your database. This alias will be the connect string used when
installing the Siebel Server. Record the connect string in Appendix A,
“Deployment Planning Worksheet.” You will specify this connect string when
installing the Siebel Server.
Processor to define your database alias. For more information, see the DB2
Universal Database for OS/390 Administration Guide.
Enabling ODBC. If you are connecting to the mainframe, using DB2 Connect, you
must enable ODBC to point to DB2 UDB for OS/390.
To enable ODBC to point to the mainframe, bind the CLI/ODBC Support

packages, using the Client Configuration Assistant’s Bind option.
TCP/IP and ftp. For instructions on installing TCP/IP, refer to IBM’s DB2 for
OS/390 Installation Guide.

You must verify that your servers are properly connected to the network and,
through the network, to each other.
To verify network connectivity between Siebel Servers and the Gateway Server,
Database Server, and File System
1 Verify network connectivity to the Gateway and Database Servers from the
application servers, using the ping utility.

DB2 UDB for UNIX, Windows NT, and OS/390. Use the CLP to ensure that you
can connect to your database. Open a UNIX shell and enter:
DB2 connect to database alias user user_ID using password
where:
user_ID = a valid user name on DB2.
password = the appropriate password for that user name.
following:

Enter db2 terminate to close the connection.
3 Verify that the File System is visible and that the Siebel service owner account
can copy files to and from it.
Network connectivity to the Gateway Server, Database Server, and File System
is now verified.

Verifying Central Dispatch Installation 8
If you will be using connection brokering, make sure that Central Dispatch has been
installed and configured on each application server that will support a Siebel Server.
You will be unable to complete the Siebel Server installation if the Gateway Server
is not running. Make sure that the Gateway Server has been started, using the
procedure described in “Starting the Gateway Server” on page 6-11.

Installing the Siebel Server 8
This section provides instructions for executing the Siebel Server installation.
The Siebel Server installation program performs the following tasks:
Sets up its own directory structure.

Copies the software to the disk.
Configures the Enterprise Server (if required) and the Siebel Server.
NOTE: The term Enterprise Server is used by Siebel to refer to a group of Siebel
Servers that can be administered and configured as a unit rather than individually.
It does not refer to a separate computer or separate program.
Therefore, when you install the first Siebel Server in your deployment, you will also
automatically create your first Siebel Enterprise Server—your first group of Siebel
Servers. When you install subsequent servers, you can include them in this
Enterprise Server or create a new one.
Installing Siebel Server Software 8
This process will install the Siebel Server installation script and the Siebel software
on the Siebel Server computer. Next, the process will use the software to configure
the Enterprise Server, if it does not already exist, and the first Siebel Server.
Installation consists of three steps:
1 Installing the Siebel Server software. The Siebel Server software is installed by
executing the install_server script from the Siebel CD-ROM. This must be
run once for each application server on which you are installing the Siebel
Server software.
The install_server script automatically performs all three steps of the

installation process: it copies the Siebel Server software to the application server,
configures the Enterprise Server if it is not already defined in the Gateway Server,
and configures a Siebel Server using that software installation.

2 Selecting a Siebel Enterprise for the server. The script prompts you to provide the
name of the new Siebel Enterprise Server.
3 Configuring Siebel Servers. The config_server script is also executed from the
Siebel Server software installation on the application server. The
config_server script is used to edit the definition of an existing Siebel Server
or to add an additional Siebel Server to an existing Enterprise Server using the
existing software installation.
To install the Siebel Server

1 Insert the Siebel version 6.x UNIX Server Programs CD-ROM into the CD-ROM
drive of the chosen computer and mount it, if required by your UNIX
configuration.
2 Log onto the server, using the Siebel service owner account that you recorded in
the copy you made earlier of Appendix A, “Deployment Planning Worksheet,”
then enter ksh to run a Korn shell. Mount the CD-ROM, if required, to make it
accessible.

This ensures that the permissions mask for your installation shell is set
appropriately.

incorrectly on your Siebel application’s installation files; this
will require you to reset them properly before continuing with
the installation.
4 Verify the environment variables:

If the Siebel Gateway Server is installed on this application server, enter env
to review the Siebel environment variable settings, and ensure that
SIEBEL_ROOT (the installation path name) and SIEBEL_GATEWAY (the host
name or IP address) are set correctly, if already set.
If the variable definitions were already defined, but not correct, you must
redefine them.
NOTE: If these variables were not already defined, you will be prompted later by
the installation script for their definitions.


/seaunix6x/operating_system/siebsrvr/install
where:
operating_system = your specific UNIX operating system, such as Solaris.
NOTE: The volume label for the CD-ROM is seaunix6x; it may not be required,
6 Enter ./install/install_server to start the Siebel Server installation script.

If you would like to generate an installation log to review after installation, enter
the following command, rather than the one above:
./install_server -d /usr/temp/server.log
The installation script has now been started. To complete the installation, you must
understand how to respond to the different types of prompts you will observe in the
Understanding the Prompts

The script uses three different styles of prompts:
The first prompt type. This type of prompt asks you to enter the desired value for
a given parameter; the default value is shown in square brackets [ ].
installed [/siebel]
To change the default value, enter the desired value.

The second prompt type. This type of prompt displays a list of one or more
parameter values and asks you whether you want to modify any of them:
example,
Would you like to accept these settings? (Y to install files,

N to change) [Y]
The third prompt type. This type of prompt provides a numbered list of options;
the default choice is shown in square brackets [ ].
To change the default value, enter the desired number.
To complete the installation using the script and prompts

1 At the first prompt, enter the desired installation directory (overriding the
default value of /siebel).
If the specified directory does not already exist, you will be prompted to confirm
that it should be created.
The installation script prompts you for the host name or IP address for the
Gateway Server.
2 Enter the host name or IP address of the Siebel Gateway Server.

The installation script prompts you as to whether Resonate Central Dispatch was
installed.

3 Verify that Resonate Central Dispatch is installed:

If Central Dispatch is already installed, enter Y.
If Central Dispatch is not installed and you do not plan to install it, enter N.
If Central Dispatch is not installed and you want to install it, press CTRL+C to
terminate the Siebel Server installation and go to Chapter 4, “Installing Central
Dispatch Under UNIX,” to install Central Dispatch. You will also need to reinstall
the Gateway Server.
NOTE: All Siebel Servers in an Enterprise Server must have the same Central
Dispatch configuration: Central Dispatch must be installed on all of them or
none of them.
If you are installing with Central Dispatch, the next prompt asks for the Resonate
installation directory.
If you are not installing with Central Dispatch, proceed to Step 6 on page 8-13.
4 Enter the full path for the directory in which you installed Central Dispatch.
The installer prompts you to indicate whether or not you want to configure this
section.
5 Confirm that you want to continue with installation.

6 At the next prompt, install the Siebel packages you require.
The list of packages you will see is:

[X] Siebel Server Core Components
[X] Siebel Remote Components
[X] Siebel Object Manager
[ ] Siebel Marketing Enterprise Components
[X] Siebel Field Service Components
If you need only the default packages, enter Y and continue with the
installation.
If you need additional packages, enter N.
If you enter N, you need to indicate that you accept (Y) or reject (N) each
package on the list; each package will be presented to you for your response.

After you have confirmed the packages to install, the Siebel Server installation script
installs the files on the hard disk. It then brings up a series of prompts, as described
below, to allow you to configure the Enterprise Server and Siebel Server.
Enterprise Server Configuration Prompts

The Siebel Server installation prompts you for the following information only when
you are installing the first Siebel Server into an Enterprise Server. Complete these
steps, using the information recorded in the photocopy you made of Appendix A,
“Deployment Planning Worksheet,” and then return to this section.
To complete the Enterprise Server configuration prompts

1 Enter the name for the new Enterprise Server or accept the default name
(siebel).
2 The script prompts you to confirm whether or not you want to enter new
configuration values:
To enter new configuration values, enter Y.
To accept the default values displayed, enter N.
3 Enter the appropriate connect string or database alias, as appropriate for your
RDBMS.
DB2 UDB. Enter the database alias for your Siebel database server.
DB2 UDB for OS/390. Enter the database alias cataloged for your DB2 UDB for
OS/390 database server.
Oracle. Enter the SQL*Net connect string for your Siebel Server Database.
(This connect string must be defined in the Oracle tnsnames.ora file.)
4 Enter the database tableowner name.

DB2 UDB. Enter the name of the database account that owns the Siebel tables.
Proceed to Step 6.
DB2 UDB for OS/390. Enter the name of the database account that owns your
Siebel tables and indexes.
Oracle. Enter the name of the database account that owns the Siebel tables.
Proceed to Step 6.

5 Enter the SQL ID that defines your RACF group. This grants ordinary user
privileges for most users. The default is SSEROLE.
6 Enter the Siebel database username to be used by Siebel Server for version
checking, auto-starting server components, and operation of the
Synchronization Manager.
Alternatively, you may accept the default user name sadmin.
7 Enter the Siebel database administrator’s password.

The script prompts you to re-enter the password to confirm it.
The Siebel Server uses this password to connect to the Database Server.
The installer displays the parameters and current values for the File System
directory and the JTC Help files.
8 Confirm whether or not you want to configure this section of the script:
To accept the configuration values as shown, press ENTER.
If you do not want to accept the configuration values displayed, enter N.
9 Enter the full path for the Siebel File System, or accept the default.
10 If your clients will be accessing Java Thin Client Online Help, enter the URL of
the main HTML help file (start.html).
This URL should be accessible to all Java Thin Client machines.
11 If you are not using Central Dispatch, specify which type of listening port should
be used by the Siebel Server components to accept client requests:
Dynamic ports to be used as each component is started.
Static ports that are permanently allocated.
Static ports are useful if your network devices, such as firewalls, must be
configured using this port information.
However, if your system does not require static ports, use dynamic ports; they
are easier to maintain.

12 Specify a unique port number not used by any other components or

applications. You may also accept the default port number.
The installer script displays the parameters you selected, and prompts you to
review and approve them.
13 Carefully review all the parameters set in the previous steps:

If any are incorrect, enter N to return to the previous prompts so that you can
re-enter the information.
If the settings are correct, enter Y to finish the installation.
The installer script displays information regarding the parameters being set. It
then displays the message that your Enterprise Server configuration is complete.

Configuring the Siebel Server

When you configure the Siebel Server, the installer connects to the Gateway Server.
To configure the Siebel Server

1 Enter a name for the new Siebel Server.
The installation script lists the directories it is creating, the name you gave to the
new Siebel Server, the creation date, and the default setting for the autostart
parameter.
The script prompts you to enter a description for the server.
2 Enter a description or alias for the new Siebel Server. Use the server name you
recorded in the photocopy you made of Appendix A, “Deployment Planning
Worksheet.”
This alias must be unique to the Gateway Server that connects to this Siebel
Server. A Siebel Server name must be 30 characters or less in length. It must
contain only alphanumeric characters and it may not contain spaces or
punctuation.
3 Select the appropriate licensing option for Siebel eBriefing and eContent
Services.
The script displays the current value for the static port configuration.
4 Indicate whether you accept the value displayed or want to reconfigure it.
The script prompts you to set the Autostart parameter.

5 Indicate whether or not you want to configure the Siebel Server to start
automatically when the application server is restarted:
If you want to configure the Siebel Server to start automatically on restart,

enter Y. Then, enter Y again to confirm your choice.
If you want to start the Siebel Server manually each time the machine
restarts, enter N.
NOTE: This setting only enables the Siebel Server to accept additional
configuration instructions to start automatically each time the host machine
restarts. For automatic startup to actually execute, you must complete the
configuration steps described in“Configuring the Siebel Server for Automatic
Start” on page 8-23 after Siebel Server installation is complete.
The installer prompts you to review the parameters for the Siebel Server before
applying them.
6 Review the settings carefully:

If any setting is incorrect, enter N to return to the previous prompts and
change the values.
If all the settings are correct, enter Y.
The installer finishes installing the Siebel Server software and then terminates,
returning you to the UNIX shell command line.
7 Indicate whether or not you want to start the Siebel Server you just created now:
To start the Siebel Server, press ENTER.
To defer startup of the newly created Siebel Server, enter N.
This completes the installation of the Siebel Server software on this application
server.
If your enterprise will operate multiple Siebel Servers from one Enterprise Server
installation, proceed to “Creating Additional Servers Within an Existing Enterprise
Server” to configure those servers.
If do not have any additional servers to configure, proceed to “Post-Installation

Tasks” on page 8-22.

Creating Additional Servers Within an Existing Enterprise Server 8
The config_server script is also used to create additional Siebel Servers in an

existing Enterprise Server. The config_server script is run from an existing Siebel
Server software installation on the application server.
NOTE: Typically, you will create multiple Siebel Servers on an application server only
for test or development purposes. Siebel Systems strongly recommends that you
create only one Siebel Server per application server in your production
environment.
To configure a Siebel Server

1 Log onto the application server where the Siebel Server software is installed
either as the Siebel service owner or as a Siebel administrator.
2 In the shell window, enter env and verify that the environment variables
SIEBEL_GATEWAY and SIEBEL_ROOT are correctly set, as detailed below.
SIEBEL_GATEWAY must be set to the IP address or network name of the

application server on which the Gateway Server is operating.
SIEBEL_ROOT must be set to the directory in which the Siebel Server software
is installed.
NOTE: The config_server script uses the values for these environment
variables unless they are overridden by command-line arguments.

3 If the Siebel environment variables are not set or are set incorrectly, navigate to
the SIEBEL_ROOT directory and enter . ./siebenv.sh to set them.
Caution: Before sourcing siebenv.sh, make sure you have your

database environment set up correctly. Specifically, verify that
your database client library directory is in the LD_LIBRARY_PATH
environment variable. If you did not set up the database
environment properly, you will receive an error message stating,
"An internal error with the Connector DLL has
occurred."
NOTE: Make sure there is a space between the period and ./siebenv.sh.
4 Enter config_server to start the Enterprise Server configuration script.

The config_server script accepts the command-line flags provided in the
following table.
Flag Parameter Description
-r siebel_root The full path to the Siebel root directory. This

argument is required; if it is not specified, it is the
value of the SIEBEL_ROOT environment variable.
-g siebel_gateway The IP address or network name of the application

server on which the Siebel Gateway Server is
operating. This argument is required; if it is not
specified, the value of the SIEBEL_GATEWAY
environment variable is used.
-e enterprise_server The Siebel Enterprise Server in which to operate.

This argument is optional; if it is not specified and
multiple Enterprise Servers are defined, you will be
prompted with a list of the Enterprise Servers.
-c Not applicable. Tells the installation script to install another server.
-s siebel_server The existing Siebel Server to configure. This

argument is optional; if it is not specified, you will
be prompted with a list of existing Siebel Servers and
given the option of defining new Siebel Servers.

5 If you did not specify a Siebel Server with a command line flag, you must choose
an existing server in order to edit it or select the option to create a new server:
If you choose to edit an existing server, the config_server script prompts

you with the current settings for the Siebel Server and allows you to modify
them.
If you choose to create a new Siebel Server, the config_server script

prompts you for the new values it needs to configure the Siebel Server.
NOTE: You can install your second Siebel Server in the same root directory as
your Gateway and first Siebel Server, if these are installed in the same directory.
6 Repeat the steps described under “To configure the Siebel Server” on page 8-17.
For more information on these prompts and parameters, refer to “Understanding
the Prompts” on page 8-11.
The config_server script will exit after it has completed the chosen task.

Perform the following tasks after you have completed the Siebel Server installation
program and configured all the Enterprise Servers and Siebel Servers that will be
supported from this installation.
“Verifying the Siebel Server ODBC Data Source”

“Managing Siebel Environment Variables” on page 8-23
“Configuring the Siebel Server for Automatic Start” on page 8-23
“Establishing Network Connectivity for Mobile Users” on page 8-25
“Enabling Siebel Server Component Groups” on page 8-25
Verifying the Siebel Server ODBC Data Source 8
The Siebel Server installation program automatically creates an ODBC system data
source name (DSN) that it uses to connect to the Siebel Database Server.
To verify the ODBC data source for DB2

1 Open the db2cli.ini file, which is found in your DB2 instance installation
sqllib/cfg directory, and ensure that there is a section called
[siebsrvr_enterprisename], where enterprisename is the name given the
enterprise during installation; its default name is siebel.
2 Verify that the following two values are present in the section: dbaalias =
aliasname (the database alias cataloged for your DB2 UDB for OS/390 database
server) and txnisolation = 1.
If the section is missing, run the $SIEBEL_SERVER/bin/configdb2 script to

have Siebel set it. Then reverify that the section is present.
NOTE: Siebel Systems does not recommend changing the default settings created
automatically with the ODBC data source.

Managing Siebel Environment Variables 8
As described in the previous sections, the Siebel environment variables

SIEBEL_GATEWAY and SIEBEL_ROOT must be set when you are executing the Siebel
installation and configuration scripts. These environment variables must also be set
in order to execute the Gateway Server and Siebel Server management utilities
documented in the Siebel Server Administration Guide.
During the Siebel Server installation process, the script files siebenv.csh (for the
C shell and its variants) and siebenv.sh (for the Bourne and Korn shells and their
variants) are automatically created in the SIEBEL_ROOT directory. When executed,
these shell scripts set the environment variables. You may wish to add a call to the
appropriate script of the logon files of all Siebel administrator UNIX accounts, so
that these variables are set automatically whenever a Siebel administrator logs on.
Configuring the Siebel Server for Automatic Start 8
If, during installation, you elected automatic restart of the Siebel Server every time
your system starts, follow the procedure below to implement this under UNIX.
To configure the Siebel Server to start automatically

1 Log on as root to the application server on which the Siebel Server was installed.
2 Copy the file $SIEBEL_ROOT/bin/siebel_server to the /etc/init.d
directory as shown below:
cp $SIEBEL_ROOT/bin/siebel_server /etc/init.d
3 Set the appropriate permissions by executing the following command:

chmod 744 /etc/init.d/siebel_server

/etc/rc3.d/S72siebel to /etc/init.d/siebel_server
ln /etc/init.d/siebel_server /etc/rc3.d/S72siebel


/etc/rc0.d/K32siebel
to:
ln /etc/init.d/siebel_server /etc/rc0.d/K32siebel
NOTE: You must use the actual path for SIEBEL_ROOT when copying the file and
creating the links.
The siebel_server script requires you to set the appropriate environment

variables for database connectivity before it can start the Siebel system services.
Review and, if necessary, edit the section of the siebel_server script called
“Setting Up Database Connectivity” to ensure that the appropriate commands are
invoked.
If you have multiple SIEBEL_ROOT directories on the application server for which
you want to enable automatic startup, you must edit
/etc/init.d/siebel_server by adding the new SIEBEL_ROOT to the
SIEBEL_SERVER_ROOT variable. (Use spaces to separate the directories.) For
example, suppose that the first Siebel Server in the directory /usr/local/siebel
has the following variable values for the SIEBEL_SERVER_ROOT:
SIEBEL_SERVER_ROOT="/usr/local/siebel"
If, after following the steps described above, you later decide that you want to install
a new server in the directory /vol1/siebel and enable it for autostart, you must
modify the SIEBEL_SERVER_ROOT variable as follows:
SIEBEL_SERVER_ROOT="/usr/local/siebel /vol1/siebel"
NOTE: Remember that the host where the Siebel Gateway Server is installed must be
the first to start up and the last to be shut down.

Establishing Network Connectivity for Mobile Users 8
Siebel Mobile Client users must be able to connect to the Siebel Remote Server,
using TCP/IP to synchronize with the master database. Make sure that you have the
correct network software and hardware installed to support this connectivity, and
that your remote users are able to establish a TCP/IP connection to the server using
the ping utility.
Enabling Siebel Server Component Groups 8
Before you can operate Siebel component groups, you must enable them. Please
refer to the chapter “Using the Server Manager UI” under Component Group and
Server Component Administration in the Siebel Server Administration Guide for
instructions.
You are now ready to proceed with the installation of the Siebel Database Server.

Troubleshooting Central Dispatch Timeout Errors 8
If a Siebel Enterprise Server component does not start and you receive a Central
Dispatch command timeout error in the log file for that component, you can
increase your Central Dispatch timeout value, using the Siebel parameter
SCBtimeout.
NOTE: The default setting for this parameter is 300 seconds.
To verify the current SCBtimeout parameter setting

From a UNIX shell, enter the following command:
Server name -c \$server.SCBTimeout
where:
gateway address=the IP address of your Siebel Gateway Server
Siebel Enterprise name= the alias of your Siebel Enterprise Server
Siebel Server name = the alias of the Siebel Server in which the components
failed to start
If the default value has never been changed, the command will fail with the
following error:
Exited with error 5004

To increase the timeout value for a failed component

1 From the command line of a UNIX shell, display the parameter by entering the
following command:
Server name -r \$server.SCBTimeout=new value -d int -f
where:
new value= the new timeout value that you want to apply in seconds, for
example, 360.
2 Increase the value of the timeout parameter by 60 seconds for each failed
component.
If, after trying this procedure, the component still does not start, contact Siebel
Technical Support.


Configuring and Installing the
Siebel Database Server Part 3
Chapter 9. Configuring the DB2 UDB for UNIX and Windows NT
Chapter 10. Installing the Siebel Database Server with DB2 UDB for UNIX and Windows NT
Chapter 11. Configuring the DB2 UDB for OS/390 Database Server
Chapter 12. Installing the Siebel Database Server with DB2 UDB for OS/390
Chapter 13. Migrating Customizations From Development to OS/390 Production
Chapter 14. Configuring the Oracle Database Server
Chapter 15. Installing the Siebel Database Server with Oracle

Configuring the DB2 UDB for UNIX and
Windows NT 9
Database Sizing Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Database Layout Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
DB2 Database Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 9-5

DB2 Database Manager Configuration Parameters . . . . . . . . . . . . . . . 9-6
DB2 Set Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
DB2 Database Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . 9-8
Allocating Space in Your DB2 Database for Siebel Data . . . . . . . . . . . . . . .9-10
Physical Device Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
Logical Device Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Allocating Sufficient DB2 Database Log Space . . . . . . . . . . . . . . . . 9-11
Log File Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
Using Bufferpools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
Temporary Tablespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
DB2 Database Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13

DB2 Administration Tasks Before Installation . . . . . . . . . . . . . . . . . 9-13
Updating Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15

Configuring the DB2 UDB for UNIX and Windows NT
About This Chapter
This chapter is written for database administrators who will set up the DB2
Universal Database. It provides an overview of Siebel database configuration and
sizing recommendations for the DB2 database server. The parameter settings
offered in this chapter are intended as starting points. You may need to increase
these, depending on your enterprise requirements.
This chapter consists of the following sections:
“Database Sizing Guidelines”

“Database Layout Guidelines” on page 9-4
“DB2 Database Configuration Guidelines” on page 9-5
This section explains how to configure a DB2 database.
“DB2 Database Administration” on page 9-13

This section details tasks involved before and after installing the Siebel Database
Server on a DB2 database.
Database Sizing Guidelines 9
One of the most important factors to determine about your database is its overall
size. In your planning, you will need to allocate space for system storage, rollback
or temporary storage space, log files, and other system files required by DB2, as well
as space for Siebel data and indexes. If you allocate too little space for your system,
performance will be affected and, in extreme cases, the system itself may be halted.
If you allocate too much, you waste space.
The space needed by DB2 will vary primarily based on the total number and types
of users supported. Siebel Systems recommends that you consult the IBM DB2
technical documentation for more information on these requirements.
The space required for Siebel data and indexes will vary depending on what Siebel
functionality you will implement and the amount and nature of data supporting it.
At a minimum, Siebel version 6.x requires that you size your DB2 database at from
500 to 700 MB.

Database Sizing Guidelines
The process for making accurate database size calculations is a complex one
involving many variables. The following guidelines will assist you in the process:
Determine the total number, and types, of users of Siebel eBusiness Applications
(for example, 500 sales representatives and 75 sales managers).
Determine the Siebel functionality that you will implement and the entities
required to support them. Typically, the largest entities are as follows:
Accounts
Activities
Contacts
Forecasts
Opportunities
Service Requests
Estimate the average number of entities per user (for example, 100 accounts per
sales representative) and calculate an estimated total number of records per
entity for your total user base.
Using standard sizing procedures for your specific database, and the Siebel Data
Model Reference, calculate the average record size per entity and multiply by the
total number of records. Typically, these entities span multiple physical tables,
all of which must be included in the row size calculation. This will determine
the estimated data sizes for the largest entities.
You must add additional space for the storage of other Siebel data. A rough
guideline for this additional amount would be one-half the storage required for
these key entities.
Indexes typically require approximately the same amount of space as data.

Be sure to allow for a margin of error in your total size calculation.
Be sure to factor growth rates into your total size calculation.

Database Layout Guidelines
Database Layout Guidelines 9
As with most client-server applications, the overall performance of Siebel eBusiness

Applications is largely dependent on the I/O performance on the Database Server.
To ensure optimal I/O performance, it is critical that the tables and indexes in the
database be arranged across available disk devices in a manner that evenly
distributes the I/O load.
The mechanism for distributing database objects varies by RDBMS, depending on

the manner in which storage space is allocated. Most databases have the ability to
force a given object to be created on a specific disk.
A redundant array of independent disks, or RAID, can provide large amounts of

I/O throughput and capacity, while appearing to the operating system and RDBMS
as a single large disk (or multiple disks, as desired, for manageability). The use of
RAIDs can greatly simplify the database layout process by providing an abstraction
layer above the physical disks while ensuring high performance.
Regardless of the RDBMS you implement and your chosen disk arrangement, be
sure that you properly distribute the following types of database objects:
Database log or archive files.

Temporary work space used by the database.
Tables and indexes. In most implementations, the tables and corresponding
indexes in the following list tend to be the most heavily used and should be
separated across devices. In general, the indexes listed below should be on
different physical devices from the tables on which they are created.
S_ACCNT_POSTN S_OPTY
S_ADDR_ORG S_OPTY_POSTN
S_CONTACT S_POSTN_CON
S_DOCK_TXN_LOG S_POSTN_RPT_REL
S_EMPLOYEE S_SRV_REQ
S_EVT_ACT S_OPTY
S_ORG_EXT
If you will make extensive use of the Enterprise Integration Manager (EIM), you
may want to put the interface tables (names beginning with EIM_ or ending in _IF)
on different devices from the Siebel base tables, because both are accessed
simultaneously during EIM operations.

DB2 Database Configuration Guidelines
DB2 Database Configuration Guidelines 9
This section contains guidelines for obtaining optimum performance from a DB2
Universal Database, version 6.1. The guidelines described here provide suggestions
that will be useful to a broad segment of customers. However, you should choose
values for the parameters described in this guide that reflect conditions in your
particular environment. Refer to your IBM DB2 technical documentation for
additional information.
Caution: Never make changes to your Siebel database schema unless

instructed on how to do so for a specific purpose by Siebel
eBusiness Applications documentation. Otherwise, you may
corrupt your entire system and thereby render it unsupportable.
The following guidelines are covered in this chapter:
“DB2 Database Manager Configuration Parameters” on page 9-6

“DB2 Database Configuration Parameters” on page 9-8
“Allocating Space in Your DB2 Database for Siebel Data” on page 9-10
“Physical Device Layout” on page 9-10
“Logical Device Layout” on page 9-11
“Mirroring” on page 9-11
“Allocating Sufficient DB2 Database Log Space” on page 9-11
“Log File Sequencing” on page 9-12
“Using Bufferpools” on page 9-12
“Temporary Tablespaces” on page 9-13

DB2 Database Manager Configuration Parameters 9
The database configuration parameters can be set using the update database
manager configuration command of the DB2 Command Line Processor or using
the DB2 Control Center.
NOTE: See the IBM DB2 technical documentation for more information on modifying
the database configuration parameters.
Table 9-1 lists DB2 database manager configuration parameters that differ from the
default settings. Set these parameters for each DB2 instance.
Use the configuration information below for the listed parameters. For parameters
not listed in this table, accept the default settings.
Table 9-1. DB2 Database Manager Configuration Parameters (1 of 2)
Parameter Explanation Setting/Comment
UDF_MEM_SZ UDF shared memory set size (4 KB) 1024
SHEAPTHRES Sort heap threshold (4 KB) 100000
DIR_CACHE Directory cache support YES
ASLHEAPSZ Application support layer heap size (4 KB) 15
RQRIOBLK Maximum requestor I/O block size (bytes) 65535
QUERY_HEAP_SZ Query heap size (4 KB) 16384
MAXAGENTS Maximum number of existing agents 1000

NUM_INITAGENTS Initial number of agents in pool 0
MAX_COORDAGENTS Maximum number of coordinating agents MAXAGENTS
INDEXREC Index re-creation time RESTART
MAX_QUERYDEGREE Maximum query degree of parallelism 1
INTRA_PARALLEL Enable intra-partition parallelism NO
FCM_NUM_BUFFERS Number of internal communication buffers (4 KB) 4096

Table 9-1. DB2 Database Manager Configuration Parameters (2 of 2)
FCM_NUM_RQB Number of FCM request blocks 1024
FCM_NUM_CONNECT Number of FCM connection entries (FCM_NUM_RQB * 0.75)
FCM_NUM_ANCHORS Number of FCM message anchors (FCM_NUM_RQB * 0.75)
DB2 Set Parameters 9
Use the db2set command of the DB2 Command Line Processor to set the
parameters (for example, db2set DB2_RR_TO_RS = YES) referenced in Table 9-2.
NOTE: After changing any of these settings, you must perform a

db2stop/db2start to implement the changes in your DB2 database.
Table 9-2. DB2set Parameters
Parameter Explanation Setting
DB2_HASH_JOIN Turns off hash joins in Optimizer. NO
DB2_RR_TO_RS Improves DB2 performance with Siebel. YES

Note that you set to YES only in production environment
servers.1
DB2_MMAP_WRITE Recommended setting only; you should evaluate this setting OFF
for your particular configuration and environment.
DB2_MMAP_READ Recommended setting only; you should evaluate this setting OFF
for your particular configuration and environment.
DB2_CORRELATED_PREDICATES When set to YES, the optimizer is able to determine whether YES
predicates in a query are related, which permits DB2 to
calculate the filter factor more accurately.
1. The tools check-out process requires an isolation level of “repeatable read.” Turning this parameter on
disables all repeatable reads, causing an application to use “read stability.” This status is unacceptable for
tools check-out and, therefore, development environments.

DB2 Database Configuration Parameters 9
The database configuration parameters can be set using the update database
configuration command of the DB2 Command Line Processor or using the DB2
Control Center.
NOTE: See the IBM DB2 technical documentation for more information on modifying
the database configuration parameters.
Table 9-3 lists DB2 database configuration parameters that differ from the default
settings. However, these are guidelines only.
Set these parameters for each database on which you run your Siebel application.
Use the configuration information below. For other parameters, accept the default
settings.
Table 9-3. DB2 Database Configuration Parameters (1 of 2)
DFT_DEGREE Degree of parallelism 1

(1=turn query parallelism off)
DFT_QUERYOPT Default query optimization class 5
DBHEAP Database heap (4 KB) 7429
CATALOGCACHE_SZ Catalog cache size (4 KB) 5558
LOGBUFSZ Log buffer size (4 KB) 512 (for AIX, set this to 128)
UTIL_HEAP_SZ Utilities heap size (4 KB) 5000
LOCKLIST Maximum storage for lock list (4 KB) 5000 (The setting should never be
smaller than this, but may be
increased.)
APP_CTL_HEAP_SZ Maximum applications control heap size (4 KB) 304
SORTHEAP Sort list heap (4 KB) 20,000 (Recommended size; this

may increase or decrease
depending on the amount of
memory in the database server
machine and the size of the
database.)

Table 9-3. DB2 Database Configuration Parameters (2 of 2)
STMTHEAP SQL statement heap (4 KB) 8192 (This value represents the
minimum setting; if you will use
EIM to import a large amount of
data, set the parameter to 10000
as a starting point.)
APPLHEAPSZ Default application heap (4 KB) 2500
PCKCACHESZ Package cache size (4 KB) 2048
STAT_HEAP_SZ Statistics heap size (4 KB) 8000
MAXLOCKS Percentage of lock lists per application 20
LOCKTIMEOUT Lock timeout (sec.) 300 or higher
CHNGPGS_THRESH Changed pages threshold 60
NUM_IOCLEANERS Number of asynchronous page cleaners Number of CPUs
NUM_IOSERVERS Number of I/O servers Number of disks
INDEXSORT Index sort flag YES
SEQDETECT Sequential detect flag YES
DFT_PREFETCH_SZ Default prefetch size (4 KB) 128
LOGRETAIN Sequential or circular log files YES
MAXAPPLS Maximum number of active applications Based on the number of users plus
at least 20 for Application Server
connections
AVG_APPLS Average number of active applications Depends on the environment
MAXFILOP Maximum DB files open per application 500
LOGFILSIZ Log file size (4 KB) 8000
LOGPRIMARY Number of primary log files 10
LOGSECOND Number of secondary log files 100
SOFTMAX Percent log file reclaimed before soft checkpoint 80

Allocating Space in Your DB2 Database for Siebel Data 9
The scripts you will run during your Database Server installation specify the
tablespaces in which to store your Siebel tables and indexes. A Siebel DB2 database
consists of four tablespaces using database managed space (DMS). A detailed
description of the tablespaces is provided in the table under Step 4 on page 9-14.
Each tablespace may have one or more tablespace containers to store the data.
For a test (small, non-production) installation, store the Siebel objects in a single
container per tablespace.
To manage objects (tables and indexes) that you anticipate to be large or to be

points of contention, you may want to create separate additional tablespaces and
containers for them, preferably on separate disk devices.
After installing the Database Server installation scripts on the Siebel Server
machine, modify the database table and index creation scripts to specify the
tablespace names you created for Siebel tables and objects.
Physical Device Layout 9
When you are using a UNIX database server, all containers should reside on raw
UNIX disk partitions, except the containers used for LONG VARCHAR data.
Containers for LONG VARCHAR data should reside on the UNIX file system to take
advantage of the operating system’s buffering capabilities. To ensure that your
database will perform well, create one container for each available logical or
physical disk device.
Data and log devices should reside on different disk spindles to reduce contention
between random and serial I/O. Ideally, all DB2 devices should reside on different
disk spindles to minimize I/O contention. When this approach is not possible,
spread devices that contain database objects that are often used together across
different spindles. These objects include tables, their indexes, and commonly joined
tables.

Logical Device Layout 9
You can use tablespaces to place objects on logical containers, creating tablespaces
to span one or more containers. Tablespaces can be used to place objects on
multiple physical containers to promote parallel I/O. Spreading the data and index
information across several containers (physical devices) can improve the
performance of queries.
Mirroring 9
At a minimum, the transaction log should be mirrored to guarantee complete

database recovery in the event of a single device failure. The instance home
directory must be mirrored, if resources are available. Hardware or operating system
mirroring generally provides the best performance.
Allocating Sufficient DB2 Database Log Space 9
You must create database transaction logs large enough to support various large
transactions used by the Siebel software. On DB2, three parameters affect the
amount of log space reserved:
LOGFILSIZ. The size of the log file.
LOGPRIMARY. The number of log files to preallocate and use.
LOGSECOND. Extra log files that are allocated only if they are needed for a large
transaction.
To run on a large system, create approximately 1 GB of total log space. Siebel

Systems recommends creating 10 primary log files with 32 megabytes (MB) each.
This is accomplished by setting the LOGFILSIZ database configuration parameter
to 8000 and the LOGPRIMARY parameter to 10. In addition, to support very large
transactions, set the LOGSECOND parameter to 100.
Smaller systems may use less log space.

Log File Sequencing 9
The database parameter LOGRETAIN is not on/enabled by default; this parameter

may be important for certain Siebel customers. When LOGRETAIN is set to NO, the
log files are reused in a circular fashion. This means that roll-forward recovery
cannot be used. When LOGRETAIN is set to YES, all log files are kept on the system
for the administrator to archive and delete.
If LOGRETAIN is set to NO, you can only do backup/restore recovery and cannot do
roll-forward recovery. This may have implications for your disaster recovery process
related to your production Siebel Database Servers.
Siebel Systems recommends that your DBA review the setting for this parameter.
Using Bufferpools 9
A bufferpool is an area of main system memory that is used for holding pages of
data that have been fetched from the tablespace. In DB2, each tablespace is
associated with a bufferpool. Adding more space to a bufferpool will enhance the
performance of the database.
You must create at least four bufferpools for the Siebel tablespaces. You can use the
default bufferpool (called IBMDEFAULTTBP) to buffer data pages from all the Siebel
tablespaces except for the SIEBEL_16K tablespace and the temporary tablespaces.
You must also create additional bufferpools with 4-KB, 16-KB, and 32-KB page sizes
for sorting and other SQL processing. A sample configuration is shown in Table 9-4.
Table 9-4. Sample Bufferpool Configuration
Bufferpool Suggested Bufferpool Size Pagesize
IBMDEFAULTTBP 50% of available memory 4 KB
BUF4KTEMP 100-200 MB 4 KB
BUF32KTEMP 32 MB 32 KB
BUF16K 25% of available memory 16 KB

DB2 Database Administration
Temporary Tablespaces 9
You must create 4-KB, 16-KB, and 32-KB temporary tablespaces for sorting and
other SQL processing.
Siebel Systems recommends that you use system managed space (SMS) for all
temporary tablespaces, and that each temporary tablespace be expandable to 2GB
for storage purposes.
DB2 Database Administration 9
Several database administration tasks are required before you install the Siebel
Database Server. These tasks will help ensure that you obtain optimum
performance from your DB2 database working with your Siebel application.
DB2 Administration Tasks Before Installation 9
Before installing your Siebel application on a DB2 platform

1 Make sure that a user that has administrative privileges has been created in your
own local domain.
NOTE: You do not need to be logged into this administrator account; you just
need to make sure that it exists.
2 Set the database manager and database configuration parameters. (See “DB2
Database Manager Configuration Parameters” on page 9-6 and “DB2 Database
Configuration Parameters” on page 9-8.)
3 Create the DB2 database.

Performance may be improved by using code set 1252 and the binary
(IDENTITY) collating sequence. Users may also choose other collating
sequences so that data will sort in dictionary order.

4 Create the tablespaces.

a Create the four required DB2 tablespaces for tables of various sizes as shown
in the table below.
Siebel Systems recommends that you use the default tablespace names
shown in the table.
The tablespaces must be created as database managed space and have an

extent size of 16 pages.
Create the SIEBEL_16K tablespace with a page size of 16-KB. All of the other
tablespaces should have a page size of 4-KB.
DB2 Min. Disk

Tablespace Space Required
Name Bufferpool Name for Creation Description
SIEBEL_4K IBMDEFAULTTBP 372 MB Tablespace name for

tables with row sizes
< 4005 bytes.
SIEBEL_16K BUF16K 91 MB Tablespace name for

tables with row sizes
from 4006 bytes through
16,293 bytes.
SIEBEL_4KL IBMDEFAULTTBP 14 MB Tablespace name for

data stored in
LONG VARCHAR
columns.
SIEBEL_IDX IBMDEFAULTTBP 312 MB Tablespace name for

storing the index data
for the Siebel tables.
b Create any additional tablespaces that may be used for storing individual
tables, such as S_DOCK_TXN_LOG.
c Record the tablespace names on the Deployment Planning Worksheet.
Caution: You must configure three temporary tablespaces, one each

for 4-KB, 16-KB, and 32-KB page sizes. Otherwise, your database
will experience serious performance and stability problems.

5 Create 4-KB, 16-KB, and 32-KB temporary tablespaces to use for sorting and
other SQL processing, as shown in the following table.
Temporary Tablepace Name Bufferpool Name
TEMP4K BUF4KTEMP
TEMP16K BUF16K
TEMP32K BUF32KTEMP
Temporary tablespaces should be created as system-managed space (SMS), and

be expandable to 2 GB for storage purposes.
6 Add one or more containers per table.

Create the containers from the SIEBEL_4KL tablespace in the file system to take
advantage of file system buffering. These can be created using the LONG
TABLESPACE option of the CREATE TABLESPACE command.
7 Size the logs.

See “Allocating Sufficient DB2 Database Log Space” on page 9-11.
Updating Statistics 9
On DB2, statistics are updated using the runstats database utility. Siebel provides
a Korn shell script, the updatestats.ksh script, to run this utility properly on the
Siebel Database.
The updatestats.ksh script scans the database tables and indexes to gather
information about each table, such as the number of rows in the table, and the
number of unique values in the index attributes. The Database Optimizer uses the
information gathered by the updatestats.ksh script to pick the best method for
solving queries.

You should update statistics on tables when there has been a change of 20% or
more in the row distribution. It is not usually necessary to update statistics on all
of the tables, but only on those that have changed. Siebel Systems recommends that
you edit a version of this script that updates the tables that change frequently in
your installation. See the Siebel Data Model Reference for information on how tables
relate to each other.
NOTE: As far as possible, run the updatestats.ksh script only for changed tables,
not for all tables, to save time and prevent locking problems.
Caution: Never use the runstats utility to update statistics for the
S_DOCK_INIT_ITEM or the S_ESCL_LOG tables.
The updatestats.ksh script should be run only when there is little activity on the
system, particularly activity by Siebel eBusiness Application clients, for instance, at
midnight or later. If you run this utility while users are accessing and updating the
Siebel Database, lock contention may occur. When this happens, an error message
like this will be generated:
ODBC error S1000 in SQLExecDirect: [IBM][CLI Driver][DB2/6000]

SQL2310N The utility could not generate statistics. Error "-911"
was returned.
This will not harm your database, but the updatestats.ksh script will have to be
run again for any table for which this type of error was generated, because statistics
were not updated for that table. You must also update statistics on any tables that
were missed.
A DBA can split the updatestats.ksh script into a series of smaller scripts to
update only those tables that have changed. For example, the table S_ZIPCODE
does not change very often, and therefore you will not need to update statistics on
this table except when you add new ZIP codes to it. After your DBA has created
separate scripts to update your tables separately, you should run these scripts
frequently on those tables that change frequently.
NOTE: The User-Defined Functions (UDF) module requires 30 seconds to fully

terminate and release resources after DB2 terminates.

Installing the Siebel Database
Server with DB2 UDB for UNIX and Windows NT 10

Installing the Database Server Scripts . . . . . . . . . . . . . . . . . . . . . . 10-4
Creating Tableowner and Administrator Accounts . . . . . . . . . . . . . . 10-8
Installing the Stored Procedures and User-Defined Functions . . . . . . . . . 10-10
Overriding Default Storage Parameters . . . . . . . . . . . . . . . . . . . . . 10-15
Testing the ODBC Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16

Executing the Database Server Installation Script . . . . . . . . . . . . . 10-17
Importing the Siebel Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-23

Populating the Siebel File System . . . . . . . . . . . . . . . . . . . . . . . . 10-28

Installing the Siebel Database Server with DB2 UDB for UNIX and Windows NT
About This Chapter
This chapter is written for system administrators who will install the Siebel
Database server.
To install the Siebel Database server, you will first install the Database Scripts on a
Windows NT or UNIX Siebel Server. Then you will run the Database Scripts to
create the following in your Siebel Database:
A database role/group with appropriate access to the Siebel Database objects

The Siebel administrator’s user account
Tables
Indexes
Triggers and stored procedures
Seed data
File attachments to be copied to the Siebel File System

Before installing the Siebel Database server, you must complete the following tasks:
Obtain the services of a qualified database administrator who will assist you
during your installation.
Complete all the steps in the appropriate chapters of Part 1, “Installing Central
Dispatch and the Siebel Gateway Server,” and Part 2, “Installing the Siebel
Server,” to install at least one Siebel server.
Make sure that DB2 is properly configured, as documented in Chapter 9,

“Configuring the DB2 UDB for UNIX and Windows NT.”
Allocate and configure disk space appropriate to your installation requirements

and DB2.
If you have not already done so, copy the Deployment Planning Worksheet,
located in Appendix A, and fill out the appropriate page with the following:
DB2 Database Alias. This is the appropriate DB2 database alias that you
created when installing the DB2 software.
Tableowner/Database Owner Account User Name and Password. DB2 requires

that you assign a user name and password to each database table you create.
Prior to installing the database server, you will edit the grantusr.sql script
and enter this information. SIEBEL is the default tableowner account user
name and password for Siebel applications.
Siebel Data Tablespace. The name of the tablespace on the DB2 server where
the 4-KB Siebel data tables are stored.
Siebel Long Tablespace. The name of the tablespace on the DB2 server where
tables reside whose row length equals less than 4006 bytes.
Siebel 16-KB Tablespace. The name of the tablespace on the DB2 server where
tables reside whose row length equals greater than 4005 bytes.
Siebel Index Tablespace. The name of the tablespace on the DB2 server where
the Siebel indexes are stored.

In addition, perform the following tasks, discussed in this section before executing
the Database Server installation scripts:
“Installing the Database Server Scripts”

“Reviewing the Software Installation” on page 10-7
“Creating Tableowner and Administrator Accounts” on page 10-8
“Installing the Stored Procedures and User-Defined Functions” on page 10-10
“Overriding Default Storage Parameters” on page 10-15 (optional)
“Testing the ODBC Data Source” on page 10-16 (optional)
Installing the Database Server Scripts 10
Complete the steps below to complete the Database server installation scripts on
one Windows NT application server. You must have a Siebel Server already installed
on this application server.
To install the database scripts under Windows NT

1 Start the Database Scripts Installation Program:
b In Windows NT Explorer, navigate to the D:\dbsrvr directory and double-

3 Choose the type of database script installation that applies:

Typical. This setup option will install all Siebel components for the most
common options.
Compact. This setup option will install a minimum subset of all components.

the specific database platform scripts you want to install.
Review the destination directory (by default C:\sea6xx\dbsrvr) and, if you

need to change the default, navigate to the correct directory by using the
Browse button.
The Setup Status screen appears and shows the progress of database script
installation.
Next.
5 To complete the Database server script installation, click Finish.
To install the database scripts under UNIX

1 Insert the Siebel UNIX Server CD-ROM into the CD-ROM drive of the chosen
application server and mount it, if this is required by your UNIX configuration.
2 Log onto the application server using the Siebel service owner account recorded
in Appendix A, “Deployment Planning Worksheet.”
3 Enter ksh to start a Korn shell.

4 Enter env to review environment variable settings, and ensure that the Siebel
environment variable SIEBEL_ROOT is set correctly to the directory where the
Siebel server software is installed.
If the Siebel environment variable is not set, navigate to the SiebSrvr_Home

directory (on UNIX installations, SiebSrvr_Home is SIEBEL_ROOT) and enter:
. ./siebenv.sh
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
Also verify that the appropriate RDBMS environment variables have been set.
For information on what these are, consult your RDBMS vendor’s
documentation.

5 Navigate to the following directory on the CD:

/seaunix6xx/operating_system/dbsrvr/install
where:
NOTE: The volume label for the CD-ROM is seaunix6xx, and may not be
required, depending on how you access the CD-ROM.
6 Enter install_dbsrvr to start the Siebel Database server software installation

script.
7 At the next prompt, review the packages selected for installation.

At a minimum, the package for DB2 and the Sample File Attachments package
must be selected.
If you need to make changes to the package selection, enter N at the prompt and
make the necessary changes; otherwise, enter Y at the prompt to proceed with
the installation.
The Database server software installer will copy the necessary files to disk and
exit when it has completed the installation.
The Database Server scripts are now installed.

Reviewing the Software Installation 10
Review the directory structure created by the Database Server installation. The
directory structure is located under the directory specified during the installation.
The directory structure should match the one shown below.
bin
files
db2udb
enu
siebproc
aix
hpux
solaris
winnt
ctiproc
aix
hpux
solaris
winnt
bin. Contains files used by the database scripts.
files. Contains sample file attachments. These should be copied to the File System.
See “Post-Installation Task” on page 10-28.
db2udb. Contains the scripts for the DB2 Universal Database server.
enu. Language-specific files in U.S. English.
siebproc. Contains User-Defined Functions (UDFs) and stored procedures.
aix. UDFs and stored procedures for DB2 AIX systems.
hpux. UDFs and stored procedures for HP-UX systems.
solaris. UDFs and stored procedures for DB2 Solaris systems.
winnt. UDFs and stored procedures for Windows NT systems.
ctiproc. Contains Computer Telephony Integration (CTI) source code, makefiles,

and stored procedures.
aix. CTI source code, makefiles, and stored procedures for DB2 AIX systems.

hpux. CTI source code, makefiles, and stored procedures for HP-UX systems.
solaris. CTI source code, makefiles, and stored procedures for DB2 Solaris
systems.
winnt. CTI source code, makefiles, and stored procedures for Windows NT
systems.
NOTE: For DB2, db2udb includes the source code and compiled libraries for each
supported database platform of the CTI stored procedures for both the Genesys and
Aspect CTI middleware products. Please see Siebel Release Notes for more
information about modifying and using these stored procedures.
Creating Tableowner and Administrator Accounts 10
On DB2, you must manually create the tableowner account (default: SIEBEL), the
Siebel Administrator account (default: SADMIN), and the sse_role group. You must
then add the two accounts to the sse_role group. In addition, the stored
procedures fence ID (default: db2fenc1) requires read access on the Siebel tables.
This ID should be a member of the sse_role group.
Then you must execute the grantusr.sql script against your database server to
grant the appropriate privileges to these users. The grantusr.sql script must be
run before you install the Siebel Database server.
This script is located in the appropriate subdirectory for your database platform.
Your database administrator should review and run this script, which performs the
following functions:
Grants the appropriate permissions to the Siebel tableowner account that will
“own” all the database objects for your Siebel deployment
Creates a role (sse_role) with create session privileges

The default user name and password for the logon are listed in the grantusr.sql
script, located in the database server directory. If you want another logon, edit the
grantusr.sql script and change all the references to your preferred name.
NOTE: Do not change the name of the Siebel Administrator Account, SADMIN. This
account must be created for you to log onto Siebel as the Siebel Administrator.

To run the grantusr.sql script

1 Run the grantusr.sql script from a DB2 Command Window, using an account
with DBA privileges.
The usual DB2 System Administration account will be called db2admin on

Windows NT and db2inst1 on UNIX.
Caution: If you are running the grantusr.sql script under

Windows NT, be sure to use the Command window, not the
Command Line Processor. The Command Line Processor
different syntax. These commands will not work as given in a
Command Line Processor window; they must be issued in a
Command Window.
If you are installing under Windows NT, use the following commands:
db2 connect to [DB2database Alias] user
[Instance Owner Username] using [password]
db2 -vf c:\dbsrvr\db2udb\grantusr.sql
If you are installing under UNIX, use the following commands:

db2 connect to [DB2database Alias] user
[Instance Owner Username] using [password]
db2 -vf /dbsrvr/db2udb/grantusr.sql
NOTE: You must specify the full path to the dbsrvr directory.
The script prompts you for the default tablespace in which your Siebel objects
are to be created.
2 Enter the tablespace name you recorded in the copy you made of Appendix A,

Installing the Stored Procedures and User-Defined Functions 10
To install the stored procedures and user-defined functions on your Database Server,
you must first transfer them to the Database Server and then run the installation
script.
The UDFs and stored procedures must be transferred to and installed on the Siebel
Database Server to support the Siebel product. You may do this by copying the files,
if your Database Server’s hard disk is NFS-mounted to the computer from which
you are installing the Siebel Database Server, or by using the ftp command if the
Database Server’s hard disk is not NFS-mounted to that computer.
Under Windows NT servers, you would normally log on to the source installation
machine and copy the files from it to the NFS-mounted Database Server hard disk.
Under UNIX, you would normally ftp the files from the source installation
computer to the Database Server. You may choose to use ftp with Windows NT
servers, though, or copy between NFS-mounted hard disks with UNIX servers. Any
method that transfers the necessary files to the correct location on the Database
Server is acceptable.
Installing the Stored Procedures and UDFs Under Windows NT

Before installing the stored procedures and user-defined functions on a Windows
NT-based database server, you must create the Siebel administrator account that
your administrator will use to configure and manage the Enterprise Server
components.
The default account name and password are both SADMIN, and you can safely use
this default if you wish. This account will be created while you are installing the
Siebel Database Server; you cannot create it now.
By default, DB2 for Windows NT runs under the System user ID, which would
mean that the UDF would also need to run under the System user ID. However, the
System user ID is not allowed to connect to the database, so the user ID for DB2
must not be System. To run DB2 on Windows NT, you must create a user account
under Windows NT called db2admin that has at least the following Advanced User
Rights:
Act as part of the operating system

Create a token object

Increase quotas
Log on as a service
Replace a process-level token
If you already have a db2admin account, continue to the procedure called “To
configure DB2 to use the DB2ADMIN account under Windows NT” on page 10-12.
To create the DB2ADMIN account under Windows NT

1 From the Windows NT Start Menu, choose Programs

Administrative Tools (Common) User Manager.
2 In User Manager, choose User New User.

3 In the screen that appears, fill out the following items as shown:
Username: db2admin
Full Name: DB2 Administrative Account
Description: Administrative account for DB2 Universal
Database Server
Password: db2admin
Confirm Password: db2admin
User must change Unchecked
password at next login:
User cannot change Unchecked
password:
Password never expires: Checked
Account disabled: Unchecked
NOTE: All DB2 batch files (.bat), .ksh files, and SQL scripts (.sql) use
uppercase passwords, so you must assign only uppercase passwords to any
accounts or logons used by these files.
4 Click Groups, and assign the db2admin account to the Administrators group, or
whichever group at your site holds administrative privileges.
5 To quit the Groups and New User screens, click OK, and then close the User
Manager.


After you have created this account, you must set the DB2 User ID to db2admin by
using the Services icon in the Windows NT Control Panel.
Caution: Complete the steps as described below; otherwise, your

results will be unpredictable.
To configure DB2 to use the DB2ADMIN account under Windows NT

1 Go to the database server machine.
2 Select the Windows Start menu, and then choose Settings Control Panel
Services.
A dialog box with a list of available DB2 services appears. Each service will have
a name similar to:
DB2-instance_name
where instance_name = the name of the DB2 instance to which this service
connects.
NOTE: The service that requires change to the user ID is the database manager,
usually called DB2 - DB2. This change is not necessary for the administration
server, usually called DB2 - DB2DAS00, because the administration server
already uses the user ID db2admin.
3 Highlight the DB2 service and click the Startup... button.

4 In the Log On As: box, click the This Account: button.
5 Click the ellipsis button (...) beside the account name.
6 Choose the local computer in the List Names From: picklist.
7 Highlight db2admin, click Add, and then click OK.
8 Type the password for db2admin.
9 Click Close.
To copy and install the stored procedure under Windows NT

1 Log onto the Siebel source installation machine, and navigate to the source
installation subdirectory that contains the Siebel Database install objects.
The directory that contains the files to install is

dbsrvr install directory/db2udb/siebproc/dbserver OS.
2 Copy all files in this directory to a temporary directory, such as c:\temp, on the
target install machine.
3 On the Database Server, open a DB2 Command Window by choosing Start

Programs DB2 for Windows NT Command Window.
4 In the DB2 Command Window, navigate to the temporary directory to which you
transferred the installation script and files, and enter installsiebel.
Installing the Stored Procedures and UDFs Under UNIX

Installing the stored procedures and user-defined functions (UDFs) under UNIX is
a three-part procedure. You must first transfer the TAR (tape archive) file containing
the stored procedures and UDFs to the database server, and then uncompress the
archive to extract the files into their proper location, and finally run the installation
script.
To copy and install the stored procedure code under UNIX

1 Log onto the Siebel source install machine, and navigate to the source install
subdirectory that contains the Siebel Database install objects.
The directory that contains the files to install is
dbsrvr install directory/db2udb/siebproc/dbserver OS.
2 Invoke the ftp client on the source install computer and connect to the Database
Server.
If you are using a standard command-line ftp client, enter ftp -i database
server machine name .
NOTE: There are a number of GUI client implementations of ftp that do the same
thing as standard command-line ftp clients. The instructions provided are for
the command-line ftp clients, but you may use a GUI client to perform the
following steps provided you know how to do so.

3 Log on as the DB2 UDB instance owner.

4 Using binary transfer mode, move the siebel.tar file to the home directory of
the database instance owner.
If you are using a standard command-line ftp client, issue the following
commands:
a At the ftp prompt, enter bin to change to binary mode.

b Enter put siebel.tar and press ENTER to move the file to the home
directory of the database owner.
5 Close the ftp client.

6 If you are using a standard command-line ftp client:
a Enter logout to log out from the database server.
b Enter exit to close the ftp client.
7 Ensure that the database instance is stopped, and log on as the DB2 UDB
instance owner.
8 Verify that the siebel.tar file is in the home directory, and enter tar -xf
siebel.tar to uncompress the TAR archive.
The TAR archive will create a subdirectory called siebel that will contain the
necessary scripts and other files.
9 To change directories to siebel, enter cd siebel.

10 Enter ./installsiebel.
11 At the prompt, enter Y to install the stored procedure code and user-defined
functions.
12 When the script has finished and returned you to a shell prompt, log out from
the database server.


Overriding Default Storage Parameters 10
If you would like to override the default storage parameters, such as the tablespaces
in which specific tables are created, edit the ddl.ctl file located in the
dbsrvr\db2udb directory.
NOTE: The ddl.ctl file should be modified only by a qualified DBA.
For each Siebel table, you can specify a tablespace by using the Space parameter.
In the following example, the tablespace for the table S_APP_VIEW is set to DATA1.
As provided by Siebel, the .ctl file does not set storage parameters for the objects
it creates, so they will default to the parameters of the tablespaces in which they are
created.
As shown in the example below, you can use the Space parameter to set storage
parameters for specific tables.
[Object 219]
Type = Table
Name = S_APP_VIEW
Column 1 = ROW_IDVARCHAR(15)NOTNULL
Column 2 = CREATEDTIMESTAMPNOTNULL DEFAULT %NOW%
Column 3 = CREATED_BYVARCHAR(15)NOTNULL
Column 4 = LAST UPDTIMESTAMP NOTNULL DEFAULT %NOW%
Column 5 = LAST_UPD_BYVARCHAR(15)NOTNULL
Column 6 = DCKING_NUMNUMERIC(22,7)DEFAULT 0
Column 7 = MODIFICATION_NUMNUMERIC(10,0)NOTNULL DEFAULT 0
Column 8 = CONFLICT_IDVARCHAR(15)NOTNULL DEFAULT ‘0’
Column 9 = NAMEVARCHAR(50)NOTNULL
Column10 = DESC_TEXTVARCHAR(255)
Column11 = LOCAL_ACCESS_FLGCHAR(1)
Space = data1

Testing the ODBC Data Source 10
The Siebel Server installation program installs a utility called ODBCSQL.exe in the
\siebsrvr\bin directory. Siebel Systems recommends that you use this utility to
test your ODBC data source after database server installation. This utility is also
particularly useful in troubleshooting post-installation connectivity problems that
may stem from the ODBC layer of your installation.
To test your ODBC data source

1 From the ODBCSQL prompt, type:
set source SIEBEL_DATASOURCE_NAME
where:
SIEBEL_DATASOURCE_NAME = the data source name for which you would like
to test connectivity, for example:
siebel_srvr_enterprise_name
2 Type:
login SADMIN/password;
3 Type:
select APP_VER, COMMENTS from TABLE_OWNER.S_APP_VER;
select APP_VER, COMMENTS from S_APP_VER;
The foregoing commands should result in the display of the application version and
any comments. The display should also indicate whether or not connectivity
through the ODBC layer was set up correctly. Error messages at this point indicate
that problems exist downstream from the ODBC layer to the database or problems
in the user/password combination or SSE_ROLE privileges for that user.

Installing the Database Server
Installing the Database Server 10
You must complete two steps to install the Siebel Database server:
“Executing the Database Server Installation Script”

“Importing the Siebel Repository” on page 10-23
Executing the Database Server Installation Script 10
The Database Server installation script is called install.ksh and is located in the
DB2 subdirectory. It does the following:
Creates Siebel tables and indexes in a specified tablespace

Imports Siebel seed data—for example, correspondence templates and SADMIN
ID and responsibilities—thereby populating 118 tables. (Seed data within a table
can be identified by its ROW_ID prefix of 0.)
Installs Siebel seed data specific to your database.

Installs views, packages, and procedures for your database
Installs Siebel triggers and views
To install the Siebel Database Server, you must first edit the Database Server install
scripts.
Siebel Database Script Syntax

The install.ksh script, like all other Siebel Database Server scripts, uses Korn
shell syntax for compatibility across Siebel Enterprise Server platforms. The syntax
for these scripts is somewhat different from that for the Windows NT batch files
provided with earlier versions of Siebel applications.
Note the following guidelines when editing all Siebel Database Server scripts:
To comment out a line, use the number sign (#), not REM.
The forward slash (/), rather than the backslash, is used as a separator in
directory paths for both Windows NT and UNIX. For example:
C:/sea6xx/dbsrvr
Follow the syntax examples and instructions in the .ksh files closely. They
indicate, for example, where quotes must be included around values and the
proper case for parameter values.
Version 6.3.1 Siebel Server Installation Guide 1 0 - 1 7
Editing the Database Installation Script

Edit the install.ksh script, using Windows Notepad or another text editor, to set
the correct parameters for your installation before running the script. These
parameters are defined at the top of the install.ksh file, and are described in
Table 10-1 on page 10-18.
Make sure you update items that default to CHANGE_ME or unspecified. These
default entries will not work if left unchanged.
Table 10-1. install.ksh Parameters (1 of 2)
Parameter and Default Setting Description
SRC_USR=SADMIN User name of the Siebel Administrator.
SRC_PSWD=SADMIN Password of the Siebel Administrator: db2.
SRC_TBLO=SIEBEL The Siebel Database tableowner. This is the account that will own
the Siebel objects.
SRC_TBLO_PSWD=SIEBEL Siebel Database tableowner password.
ODBC=CHANGE_ME ODBC data source to access the database. The data source is created
automatically by the Siebel Server installation, using the format
SiebSrvr_EnterpriseServerName. The default is CHANGE_ME
and must be modified or your installation will fail.
To find out the ODBC data source name for the Siebel Server, do the
following:
Under Windows NT, navigate to the Control Panel and choose
ODBC Data Sources System DSN.
Under UNIX, navigate to SIEBEL_ROOT/sys and open the file
.odbc.ini.
Look for a DSN with the naming convention
SiebSrvr_EnterpriseServerName.
DBSRVR_ROOT= Root directory of the Database Software installation.

c:/CHANGE_ME/dbsrvr
Under UNIX, this is set to the SIEBEL_ROOT directory.
DATA_AREA=SIEBEL_4K= The tablespace for 4-KB data.

”default”

INDX_AREA=SIEBEL_4K= The index space for 4-KB data.

”default”
LONG_AREA=SIEBEL_4K= The tablespace for long varchar data.

”CHANGE_ME”
DB16K_AREA=SIEBEL_16K= The tablespace for 16-KB data.

”CHANGE_ME”
DATABASE_PLATFORM= Replace unspecified with DB2udb.

“Unspecified”
DB_LANG=Unspecified Names the language used by the database, such as enu for U.S.
English. See the install.ksh file for other valid entries.
DB_UNICODE_FLG=Unspecified For a database supporting Unicode, set the flag to Y.

For a database that does not support Unicode, set the flag to N.
DB2 does not support Unicode at this time.
Note that if you set the DB_UNICODE_FLG to Y, your upgrade to a
new version of Siebel eBusiness Applications will fail.
DBSERVER_OS=Unspecified Specify the database platform on which you run DB2:

aix
hpux
solaris
winnt
SIEBEL_HOME= The full path of the Siebel Server installation directory:
c:/CHANGE_ME/siebsrvr
Under Windows NT, the default is
C:/CHANGE_ME/siebsvr; it must be modified to show the
correct directory or your installation will fail.

Running the Database Installation Script

This script will run for approximately 45 minutes. Before running the script, make
sure that you have edited the parameters in the install.ksh file according to the
instructions in the previous section, “Editing the Database Installation Script” on
page 10-18.
To run the install.ksh script under Windows NT

1 In Windows NT Explorer, navigate to the database platform subdirectory of your
C:\\sea6xx\dbsrvr\db2 directory. Double-click sh.exe. This will bring up a
Korn shell window.
2 In the Korn shell window, type ./install.ksh and press ENTER to start the
install script.
The install.ksh script first prompts you to review the parameter settings.
3 Review these parameter settings carefully:
If any are incorrect, enter N to terminate the script and modify the variables.
Otherwise, enter Y to continue with the installation.
NOTE: When starting the Siebel Database Server installation or upgrade

scripts, be sure to enter Y after you have reviewed the parameters at the
beginning of the script. Pressing ENTER alone will cause the script to exit
with a syntax error. If this occurs, restart the script.
The install.ksh script exits when it has completed.
4 To close the shell window, enter exit.

To run the install.ksh script under UNIX

1 Make sure that you have set the parameters in the install.ksh file properly for
your system.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt, enter ksh to
invoke a Korn shell.
3 To set the environment variables, enter . ./siebenv.sh.
4 Navigate to the dbsrvr/DBNAME directory, and enter ./install.ksh to start the

install script.
The install.ksh script will prompt you to review the parameter settings.


The install.ksh script will exit when it has completed.

Reviewing the Log Files

The Database installation script creates several log files in the DB2 directory. Review
these log files for errors.
The log files may include certain errors that are expected and benign. Compare any
error messages found in the log files to the sample error messages in the
errors.rtf file, which is located in the same directory. (If a log file is not listed in
the errors.rtf file, then there are no acceptable error messages for that log file.)
No further action is required if the log files contain errors listed in the errors.rtf
file.
NOTE: Only one of each type of error occurring in a particular log file appears in the
errors.rtf file.
If you find errors that are not listed in the errors.rtf file, correct the condition
that caused the errors, and then rerun install.ksh to complete the installation.
Do not review error numbers alone, since these may have changed following
installation of a new driver version. Instead, compare the actual error descriptions
to find out which are acceptable errors for this platform.
Caution: Although other errors are rarely encountered, this review is

critical. Certain errors, such as a failure to create indexes, may result
in performance problems or anomalous behavior in Siebel
eBusiness Applications.

Importing the Siebel Repository 10
Finally, you must execute the imprep.ksh script to load the Siebel repository into
the Siebel database. This utility loads a new Siebel repository containing the version
6.x Siebel applications objects into the repository tables in the Database Server.
Regardless of how many Siebel eBusiness Applications you are using (for example,
Siebel Sales, Siebel Service, Siebel Marketing), you will run the imprep.ksh script
only once.
Editing the Repository Import Script

Edit the imprep.ksh script using Windows Notepad or another text editor to set the
correct parameters for your installation before running the script. The repository
import script, named imprep.ksh, is located in the same database-specific
subdirectory as install.ksh. These parameters are defined at the top of the
imprep.ksh file, and are described in Table 10-2.
Table 10-2. imprep.ksh Parameters (1 of 2)
SRC_USR=SADMIN User name of the Siebel administrator. Change as appropriate for your
installation.
SRC_PSWD=SADMIN Password of the Siebel administrator. Change as appropriate for your

installation.
SRC_TBLO=CHANGE_ME The Siebel Database tableowner. This is the account that will own the
Siebel objects.
SRC_TBLO_PSWD=CHANGE_ME Siebel Database tableowner password.

SiebSrvr_EnterpriseServerName. The default is CHANGE_ME
and must be modified or your installation will fail.
following:
Under Windows NT, navigate to the Control Panel and choose ODBC
Data Sources System DSN.
.odbc.ini.
REPOS_NAME= Name to be given to the Siebel repository after import. This should not
“Siebel Repository” be changed.
DBSRVR_ROOT=c:/ Root directory of the database software installation:

CHANGE_ME/dbsrvr
Under Windows NT, the default is c:/CHANGE_ME; it must be
modified to show the correct directory or your installation will fail.
Under UNIX, this will be the complete path to the dbsrvr directory.
DATABASE_PLATFORM= Replace Unspecified with db2udb.
Unspecified
DB_LANG=Unspecified Names the language used by the database, such as enu for U.S. English.
Use all lowercase letters. See your database server installation for other
valid entries.

C:/CHANGEME/siebsvr; it must be modified to show the correct
directory or your migration will fail.

Executing the Repository Import Script

The imprep.ksh script will run for approximately 20 minutes. Verify that you have
edited the parameters in the imprep.ksh file according to the instructions in the
previous section, “Editing the Repository Import Script” on page 10-23.
To execute the imprep.ksh script under Windows NT

1 Make sure that you have set the parameters in the imprep.ksh file properly for
your system, according to instructions in the previous section, “Editing the
Repository Import Script” on page 10-23.

C:/sea6xx/dbsrvr/db2 directory. Double-click sh.exe. This will bring up a
Korn shell window.
3 In the Korn shell window, enter./imprep.ksh to start the install script.

The imprep.ksh script prompts you to review the parameter settings.

Otherwise, enter Y to continue with the repository import procedure.

scripts, be sure to type Y, and then press ENTER, after you have reviewed the
parameters at the beginning of the script. Pressing ENTER alone will cause
the script to exit with a syntax error. If this occurs, restart the script.
The imprep.ksh script exits when it has completed.
5 To close the shell window, enter exit .

To execute the imprep.ksh script under UNIX

1 Ensure that you have set the parameters in the imprep.ksh file properly for your
system.
3 Enter . ./siebenv.sh to set the Siebel environment variables.
4 Navigate to the dbsrvr/DBNAME directory and enter ./imprep.ksh to start the

repository import script.
The imprep.ksh script will prompt you to review the parameter settings.

The imprep.ksh script will exit when it has completed.
6 Enter exit to close the shell window.
NOTE: You may need to do this twice to close the shell window.

Reviewing the Log File

The imprep.ksh script creates the imprep.log file in the database platform
subdirectory that you must review for any errors.
error messages found in the log files to the sample error messages in the
errors.rtf file, which is located in the same directory. (If a log file is not listed in
the errors.rtf file, then there are no acceptable error messages for that log file.)
No further action is required if the log files contain errors listed in the errors.rtf
file.
errors.rtf file.
that caused the errors, and then rerun imprep.ksh to complete the installation.

This completes the Siebel Database Server installation.

Post-Installation Task
Post-Installation Task 10
Perform the following tasks after you complete your installation of the Siebel
Database Server:
“Populating the Siebel File System”
Populating the Siebel File System 10
Specific files needed to run the Siebel File System, such as correspondence
templates and Siebel Marketing files, are provided with the Siebel Database Server
software. A subdirectory called files is created automatically when you install the
Siebel Database Server.
You must populate the File System directory with these file attachments after
installing the Database Server, and before running the Siebel client.
To populate the File System directory

1 Copy the appropriate files from the \files subdirectory of the Siebel Database
Server software to the File System.
2 Verify that the files are where they need to be.

Configuring the DB2 UDB for OS/390
Database Server 11
Estimating DB2 Storage Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Database Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4

Physical Device Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
Logical Table Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5

DB2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Choosing the Database Codepage . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Allocating Storage Space for Siebel Tables and Indexes . . . . . . . . . . 11-8
Verifying and Correcting Index Key Length . . . . . . . . . . . . . . . . . . . . . . . . 11-9
Allocating Log Space for Siebel Transactions . . . . . . . . . . . . . . . . . 11-9
Enhancing Database Performance With Bufferpools . . . . . . . . . . . . 11-10
Temporary Tablespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10
Partitioning Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
DB2 Administration Tasks Prior to Installation . . . . . . . . . . . . . . . . . 11-13

Configuring your DB2 Database Server . . . . . . . . . . . . . . . . . . . . . 11-13
Updating Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14
Configurable Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15

Configuring the DB2 UDB for OS/390 Database Server
About This Chapter
This chapter is written for database administrators who will set up the DB2 UDB for
OS/390 database. It provides an overview of Siebel Database configuration and
sizing recommendations for the DB2 UDB for OS/390 database server. The
parameter settings offered in this chapter are intended as starting points. You may
need to increase these settings, depending on your enterprise requirements.
“Storage Groups” on page 11-7

“Database Layout” on page 11-4
“Database Configuration Guidelines” on page 11-6
“DB2 Administration Tasks Prior to Installation” on page 11-13
“Configurable Parameters” on page 11-15

Estimating DB2 Storage Needs
Estimating DB2 Storage Needs 11
The space needed by DB2 will vary primarily based on the total number and types
of users supported. Siebel Systems recommends that you consult the IBM DB2 UDB
for OS/390 technical documentation for more information on these requirements.
functionality you implement and the amount and nature of data supporting it. The
process for making accurate database size calculations is a complex one involving
many variables. The following guidelines will assist you in the process:
Determine the total number, and types, of users of Siebel eBusiness Applications
(for example, 500 sales representatives and 75 sales managers).
required to support them. Typically, the largest entities are:
Accounts
Activities
Contacts
Forecasts
Opportunities
Service Requests
the estimated data sizes for the largest entities.
You must add extra space for the storage of other Siebel data. A rough guideline
for this amount would be one-half the storage required for these key entities.

Be sure to allow for a margin of error in your total size calculation.
Be sure to factor growth rates into your total size calculation.
Database Layout
Database Layout 11

Applications largely depends on the I/O performance of the database server. To
ensure optimal I/O performance, it is critical that the tables and indexes in the
database be arranged across available disk devices in a manner that evenly
distributes the I/O load.

Regardless of the RDBMS you implement and the disk arrangement you choose, be
sure that you properly distribute the following types of database objects:
Database log or archive files.

Temporary work space used by the database.
Tables and indexes. In most implementations, the tables and corresponding
indexes in the following list tend to be the most heavily used and should be
separated across devices. In general, the indexes should be on different physical
devices from the tables on which they are created.
S_ACCNT_POSTN S_ORG_EXT
S_ADDR_ORG S_OPTY
S_CONTACT S_OPTY_POSTN
S_DOCK_TXN_LOG S_POSTN_CON
S_EMPLOYEE S_POSTN_RPT_REL
S_EVT_ACT S_SRV_REQ
If you will make extensive use of Siebel Enterprise Integration Manager (EIM), you
may want to put the interface tables (names beginning with EIM_ or ending in _IF)
on different devices from the Siebel base tables, since both are accessed
simultaneously during EIM operations.

Database Layout
Physical Device Layout 11
On a DB2 UDB for OS/390 database server, data and log datasets should reside on
different DASD volumes to reduce contention between random and serial I/O.
Ideally, all DB2 devices should reside on different disks to minimize I/O contention.
When this approach is not possible, DB2 tablespaces and index spaces should be
spread across all available DASD volumes to reduce I/O contention. These objects
include tables, their indexes, and commonly joined tables.
Logical Table Layout 11
You can use DB2 UDB for OS/390 storage groups (STOGROUPs) to place tablespaces
and index spaces of different volumes. To do this, you assign multiple STOGROUPs
to the set of Siebel tablespaces, with each STOGROUP containing unique sets of
DASD volumes. You can also use multiple STOGROUPs for the set of Siebel index
spaces, with each STOGROUP containing unique sets of DASD volumes.
You can also use Data Facility Storage Management Subsystem (SMS) to randomly
distribute tablespace and index space data sets across multiple DASD volumes.
For more information about storage groups, refer to “Enhancing Database

Performance With Bufferpools” on page 11-10. For more information about the
types of tablespaces available in DB2 UDB for OS/390 and their properties, refer to
“Tablespaces in DB2” on page 11-7.

Database Configuration Guidelines
Database Configuration Guidelines 11
This section contains guidelines for obtaining optimum performance from a

DB2 UDB for OS/390 Database. These guidelines provide suggestions that will be
useful to a broad segment of customers. However, you should choose values for the
parameters described in this guide that reflect conditions in your particular
environment. Refer to your IBM DB2 UDB for OS/390 technical documentation for
additional information.

DB2 Structure 11
A DB2 database server holds multiple databases, each of which is a collection of

tablespaces. Each storage group is a collection of DASD volumes of the same type.
Storage groups identify the volumes that can be used for tablespace and/or index
space data set allocation. Tablespaces come in different types, and hold either a
single table or multiple tables. Most of those used in Siebel eBusiness Applications
hold multiple tables, as shown in Figure 11-1.
D B 2 /3 9 0 D a t a b a s e S e r v e r
D a t a b a s e
S t o r a g e G r o u p
In d e x e s T a b le s p a c e L o g s
T a b le s T a b le s
Figure 11-1. The Structure of a DB2 UDB for OS/390 Database
At each of these levels, physical and logical layout may differ; the OS/390 operating
system provides enhanced data security and performance through a complex file
system and other services.

Storage Groups
A DB2 storage group is a set of volumes on direct access storage devices (DASD).
These volumes hold the data sets in which tables and indexes are actually stored.
Tablespaces in DB2
A tablespace is one or more data sets in which one or more tables are stored. A
tablespace can consist of a number of VSAM data sets. Tablespaces are divided into
equal-sized units, called pages, which are written to or read from DASD in one
operation. You can specify page sizes for the data; the default page size is 4 KB.
Siebel uses 4-KB, 16-KB, and 32-KB tablespaces.
When you create a tablespace, you can specify the database to which the tablespace
belongs and the storage group it uses. You can also determine what kind of
tablespace is created: simple, segmented, or partitioned.
Simple tablespaces. A simple tablespace can contain more than one table, but, unlike
segmented tablespaces, the rows of different tables are not kept separate.
Partitioned tablespaces. With a partitioned tablespace, the available space is divided

into separate units of storage called partitions, each containing one data set of one
table. (You cannot store more than one table in a partitioned tablespace.) You assign
the number of partitions (from 1 to 254), and you can assign partitions
independently to different storage groups.
Segmented tablespaces. With segmented tablespaces, the available space is divided

into groups of pages called segments, each the same size. Each segment contains
rows from only one table. To search all the rows for one table, you need not scan
the entire tablespace, but only the segments that contain that table.
Choosing the Database Codepage 11
Users may create the DB2 UDB for OS/390 database with either an ASCII or an
EBCDIC code page. For users using ASCII-based clients (the majority of users), it is
best to create the database using the ASCII code page. That will significantly reduce
the amount of code page conversion processing required on both the server and
client machines.
NOTE: On DB2 UDB for OS/390, the code page is also known as the CCSID.

Allocating Storage Space for Siebel Tables and Indexes 11
You must now allocate sufficient space to hold your data. The scripts you will run
later, during your database server installation, will use this space to create the
tablespaces in which to store your Siebel tables and indexes (Table 11-1).
For a production installation, create at least 1 GB of total data space. For a

development or test installation, you may create a smaller amount of total data
space. To manage objects that you anticipate will be large or points of contention,
you may want to create separate additional tablespaces, preferably on separate disk
devices.
For information regarding how to size your database for small, medium, large, and
extra-large installations, refer to the DB2 Universal Database for OS/390 Installation
Guide. Table 11-1 lists the number of database objects created during the Siebel
installation and can be used as a sizing guideline.
Table 11-1. Space Allocation Guidelines
Approx. No. Required by

Database Objects Siebel on DB2 UDB for OS/390
Databases used to contain Siebel tables 10
Segmented tablespaces used to contain Siebel tables 150
Tables 1500
Indexes 7500
Packages 100

Verifying and Correcting Index Key Length 11
DB2 UDB for OS/390 requires that indexes be no longer than 255 bytes. This means
that the total indexed fields within a table must be no longer than 255 bytes. This
is handled automatically in standard Siebel installations, but customers who have
customized indexes must ensure their total key length does not exceed 255 bytes.
To calculate the length of a table’s index entry, add the total index value for each
indexed field in the table. Use the following guidelines to determine the index value
for each field:
CHAR columns require one byte per character
VARCHAR columns require one byte per character plus two bytes overhead
INTEGER columns require four bytes
DECIMAL columns require (p/2)+1 columns, where p is precision
Timestamps require 26 bytes

ROW_ID and other key fields require 15 bytes
VARCHAR fields longer than 255 bytes cannot be indexed
Nullable columns require one extra byte for the null
Allocating Log Space for Siebel Transactions 11
The size of logs you will need depends on how frequently your Siebel Database will
be updated, and how frequently you can accept some background server activity
while logs are archived. DB2 archives its active logs when the log datasets fill, and
will not reuse an active log until it has been archived. If log size is extremely
inadequate, the server may not be able to free log space fast enough, and processing
will stop until an active log has been archived and the space becomes available.
Small log files will also result in excessive system check pointing.
If this happens, or if archiving occurs too frequently and is impacting your database
server’s performance, the active logs need to be increased in size to reduce
archiving frequency to an acceptable level. See the DB2 Universal Database for
OS/390 Installation Guide, DASD requirements for active log data sets, to get sizing
information.

If you will be installing the Siebel Database on an existing DB2 UDB for OS/390
database server, the DB2 logs are probably already sized to handle the additional
load. If excessive archiving results after installing Siebel eBusiness Applications, the
active logs may need to be increased in size.
Enhancing Database Performance With Bufferpools 11
A bufferpool is an area of main system memory that is used for holding pages of
data that have been read from DASD. In DB2 UDB for OS/390, each tablespace is
associated with a bufferpool. Adding more space to a bufferpool can reduce I/O
requests, but will reduce the total storage available for other usage.
You will create at least three bufferpools for the Siebel tablespaces, with 4-KB, 16-
KB, and 32-KB page sizes for sorting and other SQL processing. A sample
configuration is shown in Table 11-2.
Table 11-2. Sample Bufferpool Configuration
Bufferpool Suggested Bufferpool Size Pagesize
PPPPP04K 50% of available memory 4 KB
PPPPP16K 32 MB 16 KB
PPPPP32K 5% of available memory 32 KB
An administrator can create additional bufferpools for tablespaces and indexes to

enhance performance.
Temporary Tablespaces 11
You must also create 4-KB, 16-KB, and 32-KB temporary tablespaces in the system
database DSNDB07 for sorting and other SQL processing.

Partitioning Tables 11
Tables stored in partitioned tablespaces are divided horizontally; complete records

are divided into groups and stored on different partitions rather than the table being
split vertically into two tables joined by a key. For example, you might divide an
especially large Enterprise Integration Manager (EIM) table that holds a list of new
contacts to store records with last names of A-L in one partition, and M-Z in another,
as shown in Figure 11-2.
A-L Partition
ROW_ID Last Name First Name Mr/Ms Phone Number
Ñ Azarov Vitaly Mr. (212) 856-0933
Ñ Bell Charles Mr. (818) 793-0016
Ñ Carter Remy Ms. (831) 226-7510
Ñ Coriolo Antonio Mr. (972) 652-7282
Partitioning Index
Data
and Partitioning Key
M-Z Partition
ROW_ID Last Name First Name Mr/Ms Phone Number
Ñ Martinez Eduardo Mr. (915) 584-6790
Ñ Neuss Guenther Mr. (405) 216-6743
Ñ Richards Mathilda Ms. (914) 725-8436
Ñ Trabant Violet Ms. (202) 387-4452
Figure 11-2. Partitioning a Table on DB2 UDB for OS/390
A partitioned tablespace can have up to 254 separate partitions. Each partition

contains one data set or part of the table.
Partitioning a large table to be stored on a partitioned tablespace requires that you

build a partitioning index that contains the rule, or partitioning key, used to
determine which records go into which partition. A partitioning index must contain
the same number and size of partitions as the associated tablespace.

You may choose to partition EIM tables in order to run them in parallel rather than
serially, to speed data transfers into your database. To do this, you must divide your
EIM tables through their primary indexes, and set the partition key by batch
number. Each partition will then function as its own tablespace, and can run in
parallel with the others.
For more information, see “Creating the Database Objects” on page 12-13.
NOTE: Siebel does not currently support partitioning using clustered indexes.
However, partitioned tablespaces are supported with the result that base tables can
grow to 16 terabytes.

DB2 Administration Tasks Prior to Installation
DB2 Administration Tasks Prior to Installation 11
Several database administration tasks are required before you install the Siebel
Database Server. These tasks will help ensure that you obtain optimum
performance from your DB2 database working with your Siebel application.
Configuring your DB2 Database Server 11
The following tasks should be performed after you have installed your DB2 UDB for
OS/390 database software on your OS/390 server according to the instructions in
the IBM DB2 UDB for OS/390 documentation.
To configure your DB2 UDB for an OS/390 database server

1 Configure TCP/IP on your OS/390 system to be used with DB2, as documented
in the IBM DB2 for OS/390 Installation Guide.
2 Make sure that a user who has administrative privileges has been created on
your computer in your local network domain.
NOTE: You do not need to be logged on to this administrator account to complete

this procedure; you just need to make sure that it exists.
3 From your local computer, log onto the DB2 UDB for OS/390 database server.
4 Create the ID and password for the Siebel (SSEROLE) and EIM (SSEEIM) user
groups, respectively, and assign them the necessary permissions.
SSEROLE is the default Siebel user group name, and should contain all Siebel
users. It must be assigned the appropriate permissions for Siebel users.
SSEEIM is the default EIM user group name, and should contain any users who
will use EIM. It must be assigned appropriate permissions for EIM.
5 For security and access control of your Siebel database server, Siebel Systems
recommends that you assign a security group, using RACF (Resource Access
Control Facility) or another security control system, to create the Siebel
administrative user (the default is SADMIN), and assign this user to the Siebel
users’ group.

DB2 Administration Tasks Prior to Installation
6 In the installation CLIST, or through the installation job stream $TIJUZ, set the
database manager and database configuration parameters. (For information on
these, see Table 11-3 on page 11-15.)
7 Size the logs, as described in “Allocating Log Space for Siebel Transactions” on
page 11-9.
Updating Statistics 11
You should update statistics on tables when there has been a change of 20% or
more in the row distribution. It is not usually necessary to update statistics on all
of the tables, but only on those that have changed. Siebel Systems recommends that
you edit the rstats390.exe script, located within the bin subdirectory of your
siebsrvr directory, that updates the tables that change frequently in your
installation. See the Siebel Data Model Reference for information on how tables
relate to each other.
NOTE: As far as possible, you should update statistics only for changed tables, not
for all tables, to save time and prevent locking problems.
Caution: Never use the runstats job to update statistics for the
S_DOCK_INIT_ITEM or the S_ESCL_LOG tables.
You should update statistics only when there is little activity on the system,
particularly activity by Siebel eBusiness Application clients, for instance, at
midnight or later. If you run this utility while users are accessing and updating the
Siebel Database, lock contention may occur. When this happens, an error message
like this will be generated:
ODBC error S1000 in SQLExecDirect: [IBM][CLI Driver][DB2/6000]

SQL2310N The utility could not generate statistics. Error "-911"
was returned.
This will not harm your database, but the RUNSTATS job will have to be run again
for any table for which this type of error was generated, because statistics were not
updated for that table.
You can execute RUNSTATS on an active system if you specify SHRLEVEL CHANGE
as an option on the RUNSTATS job. This allows concurrent access while the
RUNSTATS utility executes.

Configurable Parameters
Configurable Parameters 11
Reconfigure the parameters listed in Table 11-3 within DSNZPARM for optimum
operation of Siebel eBusiness Applications.
.
Table 11-3. DB2 /390 Database Manager Configuration Parameters (DSNZPARM)
Parameter Explanation Setting
NUMLKTS Number of locks per tablespace. Set to the maximum

number of pages within a
single tablespace that will
be updated by a single
user during a unit of work.
This will avoid lock
escalation during Siebel
operations.
NUMLKUS Number of locks per user. Set to the maximum

number of pages that will
If a resource unavailable error occurs because
be modified by a user
NUMLKUS has been exceeded while performing a
during a unit of work. If
Siebel operation, do one of the following:
this value is exceeded, the
Increase the NMLKLUS value. user will fail with a
resource
Issue commits more frequently, and reduce the unavailable error.
number of update and insert operations while
using Siebel eBusiness Applications.
Note that this parameter is important when running
large EIM batches. If this value is too small, EIM runs
can fail.
Should EIM fail due to NUMLKUS being exceeded, do
one of the following:
Reduce the size of the batch.
Increase the value of NUMLKUS.
MXTB Increases the maximum number of tables you can 40
have in a join. Refer to IBM APAP PQ31326/
UQ39732 instructions on setting parameter
SPRMMXT.
EXTENDED SECURITY Allows users to change their own passwords YES

periodically, as required by standard OS/390 security
procedures. Refer to the IBM OS/390 Installation
documentation for how to set this parameter.

Configurable Parameters

Installing the Siebel Database Server
with DB2 UDB for OS/390 12

Creating Security Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10
Testing the ODBC Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11
Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12

Creating the Database Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13
Editing the Table Group Configuration File . . . . . . . . . . . . . . . . . . . . . . .12-17
Creating the Siebel Database Schema . . . . . . . . . . . . . . . . . . . . . . 12-18
Importing Seed Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24
Creating and Validating Database Objects . . . . . . . . . . . . . . . . . . . 12-28


Installing the Siebel Database Server with DB2 UDB for OS/390
About This Chapter
This chapter is written for system administrators, database administrators,

installers, and others responsible for installing the Siebel Database server.
To install the Siebel Database Server, you install the database scripts on a Windows
NT or UNIX application server on which a Siebel Server has already been installed.
This application server acts as a client for the DB2 UDB for OS/390 database.
You edit and execute Siebel scripts on the client to create sql files to be executed
against the DB2 UDB for OS/390 database. Siebel also supplies other sql files as a
part of installation that you can execute, if desired.
You can transfer sql files from the client machines to the mainframe, using ftp or
similar file transfer programs. These sql files can be executed either from the client
machines using Siebel-provided odbcsql command; from OS/390 using an IBM
utility like SPUFI; or processed through any version control software in use by your
site, to create the following objects in your Siebel Database:
Database roles/groups with appropriate access to the Siebel Database objects

Tables
Indexes

About This Chapter
Installation of the Siebel database server consists of several tasks, some of which
the Siebel system administrator performs, other tasks being performed by the
DB2 UDB for OS/390 database administrator. Table 12-1 illustrates the sequence of
tasks.
Table 12-1. Installation Tasks (1 of 2)
Who Performs It? Task
Siebel administrator 1 Installs a Siebel Gateway Server, Siebel Server, and Siebel Database
scripts on one or more machines. One machine can be assigned to the
database administrator to run Siebel dba-specific scripts, as required. An
application server must be installed as a prerequisite to running the
database server installation scripts, although it is unnecessary to use this
application server for executing the installation scripts.
2 Installs the Siebel 6.x client on the machine where the Siebel Server
resides.
DB2 UDB for 3 Allocates space for and creates the database objects, including
OS/390 database bufferpools, storage groups, databases, and tablespaces.
administrator (dba)
4 Edits the tbspaces.sql and tbspaces.ctl templates provided by
Siebel Systems to reflect the local database.
Siebel system administrator 5 Modifies parameters in the following files:
install_siebel.ksh
validate_objects.ksh
imprep.ksh
6 Does one of the following:
Installs DB2 Connect configured with ODBC on mid-tier to point to

the mainframe.
Configures the mid-tier for TCP/IP, and then uses ftp to transfer the
file to the mainframe.

About This Chapter
Table 12-1. Installation Tasks (2 of 2)
DB2 UDB for OS/390 dba 7 Modifies parameters in generate_ddl.ksh.
8 Executes generate_ddl.ksh.
Depending on how its parameters were set, generate_ddl.ksh either:

Creates sieb_schema.sql.
or
Creates tables and indexes on DB2 automatically.
9 If this was not already done automatically in the last step, modifies and
executes sieb_schema.sql on the host or client system, or uses
version control software to create the Siebel tables and indexes.
Siebel system administrator 10 Executes install_siebel.ksh to install the seed data.
11 Reviews error log for any errors, fixes any found, reruns, and reverifies.
DB2 UDB for OS/390 dba 12 If parameters were not set up in install_siebel.ksh to
automatically create database objects on DB2 UDB for OS/390, copies
generated sql file to the MVS system, and executes it, using a version
control tool, if appropriate, or by other site-specific tools, such as SPUFI.
Siebel system administrator 13 Executes the validate_objects.ksh script, which validates the
existence of the created objects on the target database and produces a
report.
14 Reviews the resulting report for any errors, fixes any found, and
reverifies.
15 Executes imprep.ksh, which imports the repository.
16 Reviews the resulting error log for any errors. If the script fails, uses
Siebel Tools to delete the created repository, fixes the error, and reruns
imprep.ksh.

Before installing the Siebel Database server, you must complete the following tasks:
Obtain the services of a qualified database administrator who will assist you
during your installation.
Server,” to install at least one Siebel Server.
Install DB2 Connect to enable connection with DB2 UDB for OS/390 from the
Windows NT or UNIX client. The installation of DB2 Connect is described in
Part 2, “Installing the Siebel Server.”
Alternatively, if you want to transfer the sql files created by the Siebel
installation scripts to the mainframe to execute them there, using ftp rather
than ODBC, make sure that your system has TCP/IP installed.
Make sure that DB2 UDB for OS/390 is properly configured, as documented in
Chapter 11, “Configuring the DB2 UDB for OS/390 Database Server.”
Make sure that you have installed and enabled IBM’s Workload Manager (WLM)
on S/390. WLM supports the use of stored procedures and improves system
performance.
Allocate and configure disk space and storage groups appropriate to your
installation requirements and DB2 UDB for OS/390, described in this chapter.
If you have not already done so, make a photocopy of the Deployment Planning
Worksheet, located in Appendix A, and fill out the appropriate page with the
following:
DB2 UDB for OS/390 Database Alias. This is the DB2 UDB for OS/390 database
alias that you created when installing the DB2 Connect software.
Tableowner/Database Owner Account User Name and Password. Siebel requires

a single user name that acts as the database schema owner for all Siebel
tables and indexes. While SIEBEL is the default tableowner account user
name and password for Siebel applications, administrators may use any valid
name.

System Administrator User Name and Password. DB2 UDB for OS/390 requires
that you assign a user name and password to the system administrator for
security.
Group for SSE and for SSEEIM Users. For security and access control of your
Siebel database server, Siebel Systems recommends that you assign a security
group, using RACF (Resource Access Control Facility) or another security
control system, for all Siebel users, and an additional security group for EIM
users.
Make a photocopy of the DB2 UDB for OS/390 Installation Worksheet, located
in Appendix B, “DB2 UDB for OS/390 Tablespace and
Table Group Configuration Worksheet.” Fill out the values in the right-most
column as appropriate to your site before editing one of the sample tables group
configuration files provided by Siebel as a template for mirroring your local
database; the edited file will also be used later as a parameter of a sql file.
In addition, perform the following tasks, discussed in this section of Chapter 12,
before executing the Database Server installation scripts:
“Installing the Database Server Scripts” on page 12-7


Complete the steps described earlier in Chapter 7, “Installing the Siebel Server
Under Windows NT” or in Chapter 8, “Installing the Siebel Server Under UNIX,”
with the following exceptions. You must have a Siebel Server already installed on
this application server.
To install the database scripts under Windows NT



common options.

Browse button.
installation.

Next.

in the photocopy you made of Appendix A, “Deployment Planning Worksheet.”

4 Enter env to review environment variable settings, and make sure that the Siebel
Siebel server software is installed.
If the Siebel environment variable is not set, navigate to the SiebSrvr_Home

directory (on UNIX installations, SiebSrvr_Home is SIEBEL_ROOT) and enter:
. ./siebenv.sh
documentation.

where:
operating_system = your specific UNIX operating system, such as AIX.
NOTE: The volume label for the CD-ROM is seaunix6xx, and may not be
required, depending on how you access the CD-ROM.


script.

At a minimum, the package for DB2 and the Sample File Attachments package
must be selected.
the installation.
The Database Server software installer will copy the necessary files to disk and
bin
files
db2390
enu
ctiproc
See “Post-Installation Task” on page 12-36.
db2390. Contains the scripts, a rich-text file containing a list of acceptable errors for
review against error logs generated when running the scripts, sql commands, and
sample sql files for the DB2 UDB for OS/390 server.
enu. Language-specific files in U.S. English.
ctiproc. Contains sample source code and JCL (Job Control Language) for
building the CTI (Computer Telephony Integration) stored procedures for
inbound call routing.

Creating Security Privileges 12
Before installing Siebel on DB2 UDB for OS/390, the Security Administrator must
create security privileges for database administration, installation, and end-use. For
instructions on setting up Siebel security privileges, and Siebel tableowner and
administrator accounts, see the Siebel Applications Administration Guide.
Creating Tableowner and Administrator Accounts

Before installing Siebel on DB2 UDB for OS/390, the person in your organization
with the highest administrative authority must create the roles that will grant the
appropriate privileges for installation and product use. For information, see
Table 12-2.
Table 12-2. Roles and their Privileges (1 of 2)
Account/Role Description Privilege
SSEROLE group Siebel users Table privileges granted automatically as part of

installation. Has ability to perform the following on
Siebel tables:
Delete
Insert
Select
Update
Tableowner Siebel tableowner Ability to create the database objects that will be
used during the installation of the Siebel product.
(This function would normally be performed by
dba staff.)
Also includes:
Use of storage groups
Use of bufferpools
Use of databases
Use of tablespaces
Note that the default is SIEBEL, but you may use
any account name.

Table 12-2. Roles and their Privileges (2 of 2)
Account/Role Description Privilege
Siebel Administrator Siebel administrator account: Member of the SSEROLE group.

Requires Siebel user and Actual member of the RACF, or other security
administration privileges. program, group, selected to act as
administrator.
Note that the default is SADMIN; but you may
change this to any account name.
SSEEIM group Siebel EIM users Use of storage groups for EIM temporary tables
Use of bufferpools for EIM temporary tables
\SiebSrvr_Home directory. Siebel Systems recommends that you use this utility to

1 From the odbc.sql prompt, type:
where SIEBEL_DATASOURCE_NAME is the data source name for which you would like
2 Type:
3 Type:
select APP_VER, COMMENTS from TABLE_OWNER .S_APP_VER;
select APP_VER, COMMENTS from S_APP_VER;

Installation Tasks
The foregoing commands should result in the display of the application version and
that problems exist downstream from the ODBC layer to the database or problems
in the user/password combination or SSEROLE privileges for that user.
To install the Siebel Database server, installation activities may be shared between
the Siebel Administrator and the DB2 UDB for OS/390 database administrator.
Complete these steps in sequence:
“Creating the Database Objects”

“Editing the Table Group Configuration File” on page 12-17
“Creating the Database Objects” on page 12-13
“Creating the Siebel Database Schema” on page 12-18
“Importing Seed Data” on page 12-24
“Creating and Validating Database Objects” on page 12-28

Installation Tasks
Creating the Database Objects 12
Before the Siebel System Administrator can edit and execute the database creation
scripts, the DB2/390 database administrator, as defined in the “Creating Security
Privileges” on page 12-10, must activate or create the following database objects:
Bufferpools
Storage groups
Databases
Tablespaces (Siebel supplies a script to automate this.)
To accomplish this, database administrators must first create the appropriate logins
and passwords (as explained in “Creating Tableowner and Administrator Accounts”
on page 12-10), which will, in turn, allow them to create storage groups,
bufferpools, and databases, and to grant privileges for each of these.
Activating Bufferpools
The database administrator (or system programmer) must generate ddl to create
space for a minimum of one bufferpool to be activated for each individual page size
in the database.
To increase performance for very active tablespaces, database administrators may

activate additional bufferpools.
To create bufferpools
1 Activate a minimum of three bufferpools for the Siebel objects. (See default
bufferpool names in Table 12-3 on page 12-14.)
2 Select and rename the activated bufferpools (whose default names appear in
Table 12-3 on page 12-14) as required for your enterprise.

Installation Tasks
3 If you changed the default bufferpool names in Step 2 on page 12-13, modify the
Siebel-supplied tbspaces.sql or smalltbs.sql files, as appropriate. (These
files are described later under “Creating Tablespaces” on page 12-15.)
NOTE: You will also need to rename the bufferpools in the subsequently used
table group configuration files (tbspaces.ctl or smalltbs.ctl)
correspondingly.
4 The database administrator grants use of the bufferpools to the Siebel

tableowner and SSEEIM group, as appropriate, using the utilities customary at
the site.
Table 12-3. Default Bufferpool Names
Bufferpool Name
BP1 = 4-KB bufferpool

BP16K1= 16-KB bufferpool
BP32K1 = 32-KB bufferpool
Creating Storage Groups

Storage groups serve as containers for managing physical disk volumes, and are
required to create tablespaces and indexes.
The database administrator creates storage groups using the utilities customary at
the site.
To create storage groups

1 Create one or more storage groups with sufficient disk space in the Siebel
database to contain all table and index data. For guidelines on sizing disk space,
see Chapter 11, “Configuring the DB2 UDB for OS/390 Database Server.”
2 Grant use of the storage group to the tableowner account.

3 Grant use of the storage groups to the SSEEIM group holding the EIM temporary
tables. (This may be the same storage group that holds the Siebel tables.)

Installation Tasks
Creating Databases
The sample installation configuration files provided by Siebel require 10 databases
for Siebel tables and indexes. Each database in the sample files contains about 200
tables. You may optionally create an eleventh for temporary tables.
The database names in the sample tablespace (.sql) and table group configuration
(.ctl) files are XXXXX001-XXXXX010.
To create the databases

1 Provide names for the databases as appropriate for your enterprise, using the
utilities customary at your site.
2 At a minimum, grant the CREATETS privilege on the database to the Siebel

tableowner.
Creating Tablespaces
Two sample sql files exist in the /db2390 installation subdirectory for the purpose
of creating tablespaces:
tbspaces.sql. Contains sample ddl to create about 150 tablespaces in 10

databases, and is the default production configuration.
smalltbs.sql. Contains sample ddl to create about 20 tablespaces, and is

sufficient for development, testing, and demonstration databases.

Installation Tasks
To create tablespaces
1 Change the bufferpool names(BP1, BP16K1, BP32K1) and tablespace storage
group names and parameters (UUUUUUUU) in the appropriate tablespace .ctl
and .sql files to match your installation.
For more information on how to substitute these values, see Appendix B, “DB2
UDB for OS/390 Tablespace and Table Group Configuration Worksheet,” since it
also contains examples of the values in the tbspaces.sql and smalltbs.sql
files.
2 Execute the file in one of two ways:

Transfer to the host, using ftp, and execute it there.
Point ODBC to the DB2 UDB for OS/390 host and enter the following
odbcsql commands:
odbcsql /s odbc data source name /u username /p password /verbose filename
where: filename = either tbspaces.sql or smalltbs.sql
Notice that, in Appendix B, “DB2 UDB for OS/390 Tablespace and

Table Group Configuration Worksheet,” the EIM and repository groups are forced
into 16-KB tablespaces. This results in the 4-KB tablespace parameter being set to a
tablespace page size of 16 KB.
Some groups use the same tablespace definition for the 4-KB tablespace and 16-KB
tablespace to force all tables in the group into one 16-KB tablespace.
Several groups also only have one tablespace. With these exceptions and a couple
of groups with one table each, every other group shares the same 16-KB tablespace,
since very few tables exist that require it.

Installation Tasks
Editing the Table Group Configuration File 12
After you have allocated sufficient space for Siebel in the target environment, and
created storage groups, databases, and tablespaces, you may use one of the sample
table group configuration files as a template to define storage parameters for
database objects you require in your target database.
To enable generation of the physical database schema later in the installation

process, this sample file is used as a parameter value in the Korn shell script
generate_ddl.ksh, which generates the Siebel database schema.
You will find and edit these Siebel files, using Windows Notepad, vi, or another
text editor, in the /db2390 installation subdirectory:
tbspaces.ctl. For production systems; uses 10 databases and about 150

tablespaces.
smalltbs.ctl. For small test and development systems; uses 10 databases and only
20 distinct tablespaces.
The sample table group configuration files contain dummy database, tablespace,
and bufferpool names, and index storage parameters to make it easy to perform
string replacements and configure the files for a real environment.
These tables are divided into groups in the Siebel repository. Tables that may
become very large will, for example, have their own group, with their own
tablespace.
NOTE: For every group name in your local database repository, there should be a
matching section in the table group configuration file.
For an example of a completed tbspaces.ctl file, refer to Appendix B, “DB2 UDB

for OS/390 Tablespace and Table Group Configuration Worksheet.”
When you have edited the template file, save it to the same /db2390 directory
where generate_ddl.ksh file resides.
The sample files contain a section for each table group, as described above, and
follow the format illustrated in Appendix B, “DB2 UDB for OS/390 Tablespace and
Table Group Configuration Worksheet.”

Installation Tasks
Note that no bufferpools have been assigned to indexes in the sample files. (Their
definitions, as well as the definitions for tables are contained in the file ddl.ctl.)
To specify a bufferpool in which to place indexes, add the following to the index
stogroup argument in tbspaces.ctl:
bufferpool bufferpool name
where: bufferpool name = whatever name you want to give your bufferpool.
For example, you might create a statement similar to the following:
index stogroup = using stogroup SSSSSSSS priqty 720 secqty 720 define
yes close no pctfree 30 bufferpool BUFFERPOOLNAME.
NOTE: When you specify a bufferpool for an index stogroup name, that bufferpool
will apply only to indexes of the tables that fall in that particular table group.
Creating the Siebel Database Schema 12
After the storage groups, databases, bufferpools, and tablespaces have been
created, the database administrator executes the file generate_ddl.ksh.This file
generates the ddl (sieb_schema.sql) that creates the Siebel tables and indexes.
The definitions for tables and indexes are contained a file (ddl.ctl).
The objects in the file are compared with the physical schema of the empty target
database, and a list of statements is generated that the database administrator uses
later when installing Siebel for the first time to create the target database.

Installation Tasks

The generate_ddl.ksh file and other Siebel database server scripts use Korn shell
syntax for compatibility across Siebel Enterprise Server platforms.
Note the following guidelines when editing all Siebel database server files:
To comment out a line, use the pound sign (#), rather than REM.
Use the forward slash (/), rather than the backslash, as a separator in the
C:/sea6xx/dbsrvr for NT
/usr/sea6xx for UNIX
Follow the syntax examples and instructions in the .ksh script files closely. They
Editing the Database Schema Generation Script

The database administrator edits the parameters in generate_ddl.ksh, located in
the /db2390 installation subdirectory before running it to produce the ddl for tables
and indexes on the target database. When database administrators edit the
generate_ddl.ksh, they can set the DO_DDL flag (Table 12-4 on page 12-20) to Y
to automatically create the tables and indexes on DB2 UDB for OS/390.
If the enterprise requires ddl files to be processed through a version control tool,
the administrator should set the DO_DDL flag to N.
The file fetches the storage parameters defined earlier in the file tbspaces.ctl (or
smalltbs.ctl), and creates a file called sieb_schema.sql.

Installation Tasks
The editable parameters are defined at the top of the file, and are described in
Table 12-4.
Table 12-4. generate_ddl.ksh Parameters (1 of 2)
Siebel objects.
ODBC=CHANGE_ME ODBC data source name of target database.
DBSRVR_ROOT= The full path of database software installation:

c:/CHANGE_ME/dbsrvr
Under Windows NT, the default is c:/CHANGE_ME; it must be
modified to show the correct directory or your installation will fail.
Under UNIX, this will be the complete path to the dbsrvr
directory.

Under Windows NT, the default is C:/CHANGEME/siebsvr; it
must be modified to show the correct directory or your installation
will fail.
MODE=CHANGE_ME You must specify the context in which you are using
generate_ddl.ksh. In other words, you must indicate whether you
are running it for installation of the database server, migration of EAI
customizations, or the migration of development customizations to the
test or production environment:
Install. Database installation.
EAI. Migration of EAI repository customizations to test or
production.
Non-Install. Migration of general customizations from
development to test or production.
Note that when you set the MODE parameter, you must also set the
MERGE_FLG parameter correspondingly. See the description of
MERGE_FLG below for more information.

Installation Tasks
MERGE_FLG=CHANGE_ME Database merge flag. When set, Siebel compares the definitions of
tables and indexes from the definition file to those in the physical
database, and updates the physical tables and indexes appropriately.
Setting the Merge Flag to Match the Mode
Fresh installations:
N=Do not compare table schemas. This setting would most commonly
be used for fresh installations.
Note that if the MODE parameter above equals Install, the
MERGE_FLG must equal N.
Migrating EAI repository customizations from development to
production:
Y=Merge EAI development repository customizations with the
production EAI repository.
Migrating customizations from development to production:
Y=Compare table schemas, creating a list of deltas. This setting would
most commonly be used for migrations from development to
production or for upgrades when only the delta information is required.
Caution: If your environment requires generation of ddl for all
tables and indexes, set the MERGE_FLG parameter to N.
Note: If the MODE parameter above equals Non-Install,
MERGE_FLG must equal Y.
DO_DDL=N ddl execution flag.

N=Create ddl that can be processed through a version control tool.
Y=Create the tables and indexes in the DB2 UDB for OS/390 database
automatically.
TBSPACE_FILE=tbspaces.ctl Name of the file from which tablespace storage parameters are
retrieved.
Change the name of this file, if necessary, to match the name you saved
it with when you used either of the Siebel templates tbspaces.ctl
or smalltbs.ctl.

Installation Tasks
Executing the Siebel Database Schema Generation Script

Before executing generate_ddl.ksh, make sure that you have edited the
parameters according to the instructions provided in “Editing the Database Schema
Generation Script” on page 12-19.
If the DO_DDL flag is set to N, the generate_ddl.ksh script runs for approximately
one minute. The script creates the file sieb_schema.sql in the
/db2390 installation subdirectory.
If the DO_DDL flag is set to Y, the script runs about 120 minutes, depending on the
load on the database server, and creates the Siebel tables and indexes in the target
database. In this case, the file sieb_schema.sql is not generated.
Editing the Siebel Database Schema Generation Script Output

Before executing sieb_schema.sql, add the following statement to the top of the
file:
SET CURRENT SQLID = TTTTTTTT
This statement specifies a high-order tableowner of TTTTTTTT that conforms to the

OS/390 installation standard for tableowner names.
Executing the Siebel Database Schema Generation File Output

The Siebel database administrator transfers sieb_schema.sql to the mainframe
and processes it through a version control tool, if required, to create tables and
indexes. If the site does not require the use of a version control tool, the database
administrator transfers the file, using ftp, to the host and executes
sieb_schema.sql, using SPUFI, or another utility, against the DB2 database to
create tables and indexes.
The database administrator can also use odbcsql on the client machine to execute
the sieb_schema.sql file against the DB2 for OS/390 database to create tables and
indexes.
Because execution of sieb_schema.sql. takes about two hours, you may prefer to
break up segments of information in the file at strategic points into separate files
that you can execute, verify, correct, and rerun in less time.

Installation Tasks
To break up sieb_schema.sql for easier execution

1 Break the file up into multiple segments just before one of the CREATE TABLE
statements.
Make sure that each file contains ddl statements for a manageable number of
tables and their associated indexes.
2 Using a text editor, insert a commit statement at the end of each file segment in
the following form:
CR/LF
COMMIT;
CR/LF
NOTE: CR refers to carriage return and LF refers to line feed.

The script creates a log file in the /db2390 subdirectory. Review this log file
carefully for errors.
error messages you find to the sample error messages in the errors.rtf file, which
is located in the same directory. (If a log file is not listed in the errors.rtf file,
then there are no acceptable error messages for that log file.) No further action is
required if the log files contain errors listed in the errors.rtf file.
NOTE: Possible errors include setting the DO_DDL flag, MERGE_FLG flag, or other file
parameters incorrectly, entering incorrect values earlier into the tbspaces.ctl file,
and insufficient disk space.
that caused the errors, and then re-run generate_ddl.ksh.

Installation Tasks

Importing Seed Data 12
The Siebel system administrator now executes the database server installation script
install_siebel.ksh to perform the following tasks on DB2 UDB for OS/390:
Import Siebel seed data—for example, correspondence templates—thereby

populating 118 tables. (Seed data within a table can be identified by its ROW_ID
prefix of 0.)
Execute Siebel sql files required by some Siebel eBusiness Applications.

Create views (if the parameter for this is set accordingly).
Editing the Seed Data Import Script

Your Siebel administrator edits the install_siebel.ksh script using Windows
Notepad or another text editor to set the correct parameters for installation before
running the script.
When Siebel system administrators edit install_siebel.ksh, they can set the
DO_DDL flag (Table 12-5 on page 12-25) to Y to automatically execute the ddl
against DB2 UDB for OS/390 and to create views there.
If the enterprise requires files to be processed through a version control tool, the
administrator should set the flag to N.

Installation Tasks
The database installation script, install_siebel.ksh, is located in the

C:/sea6xx/dbsrvr/db2390 installation directory. These parameters are defined at
the top of the install_siebel.ksh file, and are described in Table 12-5.
Table 12-5. install_siebel.ksh Parameters (1 of 2)
SRC_USR=SADMIN User name of the Siebel administrator. Change as

appropriate for your installation.
SRC_PSWD=SADMIN Password of the Siebel administrator. Change as

SRC_TBLO=CHANGE_ME The Siebel Database tableowner. This is the account that

will own the Siebel objects.
ODBC=CHANGE_ME ODBC data source to access the database. The data source
is created automatically by the Siebel Server installation,
using the format SiebSrvr_EnterpriseServerName.
The default is CHANGE_ME and must be modified or your
installation will fail.
To find out the ODBC data source name for the Siebel
Server, do the following:
Under Windows NT, navigate to the Control Panel and
choose ODBC Data Sources System DSN.
Under UNIX, navigate to SIEBEL_ROOT/sys and
open the file .odbc.ini.
DBSRVR_ROOT=c:/CHANGE_ME/dbsrvr Root directory of the database software installation:

Under Windows NT, the default is c:/CHANGE_ME; it
must be modified to show the correct directory or your
Under UNIX, this will be the complete path to the
dbsrvr directory.

Installation Tasks
Table 12-5. install_siebel.ksh Parameters (2 of 2)

N=Do not execute sql files to create views, procedures,
and triggers.
Y=Execute Siebel-provided sql files to create views,
procedures, and triggers.
DB_LANG=Unspecified Names the language used by the database, such as enu for
U.S. English. Use all lowercase letters. See your database
server installation for other valid entries.
SIEBEL_HOME=c:/CHANGE_ME/siebsrvr The full path of the Siebel Server installation directory.

C:/CHANGE_ME/siebsvr; it must be modified to
show the correct directory or your installation will fail.
Executing the Seed Data import Script

Before executing install_siebel.ksh, make sure that you have edited the
parameters according to the instructions provided in “Editing the Database Schema
Generation Script” on page 12-19.
The install_siebel.ksh script will take about 15 minutes to run.
To run install_siebel.ksh script under Windows NT

installation directory (C:/sea6xx/dbsrvr/db2390). Double-click sh.exe.
This will bring up a Korn shell window.
2 To start the install script, enter ./install_siebel.ksh in the Korn shell

window.
The install_siebel.ksh script first prompts you to review the parameter

settings.

Installation Tasks

The install_siebel.ksh script exits when it has completed.
To run install_siebel.ksh script under UNIX

1 Make sure that you have set the parameters in the install_siebel.ksh file
properly for your system.
4 Navigate to the dbsrvr/DBNAME directory, and enter

./install_siebel.ksh to start the validation script.
The install_siebel.ksh script will prompt you to review the parameter

settings.

Installation Tasks


The install_siebel.ksh script will exit when it has completed.

The script creates a log file in the DB2 UDB for OS/390 directory. Review this log
file carefully for errors, as described in “Reviewing the Log Files” on page 12-23.
Creating and Validating Database Objects 12
If, when editing install_siebel.ksh,the Siebel system administrator sets the

DO_DDL flag to Y, the script creates any views, triggers, functions, and other
database objects required by Siebel eBusiness Applications on DB2 UDB for OS/390
automatically.
If the DO_DDL flag was set to N to enable processing through version control, the
Siebel administrator transfers the ddl to the DB2 UDB for OS/390 database
administrator, who creates these database objects locally.
To validate the existence of the database objects created by the database

administrator, the Siebel system administrator executes the file
validate_objects.ksh, located in the /db2390 installation subdirectory.

Installation Tasks
Editing the Object Validation Script

The Siebel system administrator edits the validate_objects.ksh script
(Table 12-6) using Windows Notepad or another text editor to set the correct
parameters for installation before running the script.
When executed, this script generates the 390_objects.txt file, which lists all the
views and procedures by NAME and CREATOR.
Review this report to make sure that the created objects illustrated in Table 12-7
exist.
Table 12-6. validate_objects.ksh Parameters
SRC_TBLO=CHANGE_ME The Siebel Database tableowner. This is

the account that will own the Siebel
objects.
ODBC=CHANGE_ME Name of the ODBC data source for

accessing the target database.
SIEBEL_HOME=c:/CHANGE_ME/siebsrvr The full path of the Siebel Server

installation directory.
C:/CHANGE_ME/siebsvr; it must
be modified to show the correct
directory or your installation will
fail.
Under UNIX, this is set to the
Table 12-7. Siebel Views, Triggers, and Procedures
Views Triggers Procedures
S_PERSON_V None at this time None at this time
S_TXN_LOG_ITEM_V "" ""
S_TXN_LOG_NODE_V "" ""
S_TXN_LOG_OPER_V "" ""

Installation Tasks
Executing the Object Validation Script

Verify that you have edited its parameters according to the instructions provided
under “Editing the Object Validation Script” on page 12-29 before running it.
Otherwise, this program will not work.
The validate_objects.ksh script will run for approximately one minute.
To run the validate_objects.ksh script under Windows NT

installation directory (C:/sea6xx/dbsrvr/db2390). Double-click sh.exe. This
will bring up a Korn shell window.
2 To start the install script, enter ./validate_objects.ksh in the Korn shell

window.
The validate_objects.ksh script first prompts you to review the parameter

settings.

The validate_objects.ksh script exits when it has completed.

Installation Tasks
To run the validate_objects.ksh script under UNIX

1 Make sure that you have set the parameters in the validate_objects.ksh file
properly for your system.

./validate_objects.ksh to start the validation script.
The validate_objects.ksh script will prompt you to review the parameter

settings.


The validate_objects.ksh script will exit when it has completed.


Installation Tasks
Finally, the Siebel system administrator must execute the imprep.ksh script to load
the Siebel repository into the Siebel database. This utility loads a new Siebel
repository containing the version 6.x Siebel application objects into the repository
tables in the Database Server.
only once.

Your Siebel system administrator edits the imprep.ksh script using Windows
Notepad or another text editor to set the correct parameters for installation before
running the script.
The repository import script, named imprep.ksh, is located in the same

/db2390 installation subdirectory as the other previously described scripts. These
parameters are defined at the top of the imprep.ksh file, and are described in
Table 12-8.
SRC_USR=SADMIN User name of the Siebel administrator. Change as appropriate

for your installation.
SRC_PSWD=SADMIN Password of the Siebel administrator. Change as appropriate

for your installation.
SRC_TBLO=CHANGE_ME The Siebel Database tableowner. This is the account that will
own the Siebel objects.

Installation Tasks
ODBC=CHANGE_ME ODBC data source to access the database. The data source is
created automatically by the Siebel Server installation, using
the format SiebSrvr_EnterpriseServerName. The
default is CHANGE_ME and must be modified or your
To find out the ODBC data source name for the Siebel Server:
Under UNIX, navigate to SIEBEL_ROOT/sys and open
the file .odbc.ini.
REPOS_NAME=“Siebel Repository” Name to be given to the Siebel repository after import. This
should not be changed.
DBSRVR_ROOT=c:/CHANGE_ME/dbsrvr Root directory of the database software installation.

Under Windows NT, the default is c:/CHANGE_ME; it
must be modified to show the correct directory or your
Under UNIX, this will be the complete path to the
dbsrvr directory.
DATABASE_PLATFORM=Unspecified Replace Unspecified with DB2390.
DB_LANG=Unspecified Names the language used by the database, such as enu for
U.S. English. Use all lowercase letters. See your database
server installation for other valid entries.
SIEBEL_HOME=c:/CHANGE_ME/siebsrvr The full path of the Siebel Server installation directory.

C:/CHANGEME/siebsvr; it must be modified to show
the correct directory or your migration will fail.

Installation Tasks
Executing the Repository Import Script

Verify that you have edited the script parameters according to the instructions in
“Editing the Repository Import Script” on page 12-32 before executing it. Otherwise,
this program will not work.
The imprep.ksh script will run for approximately 30 minutes.
To run the imprep.ksh script under Windows NT

installation directory (C:/sea6xx/dbsrvr/db2390). Double-click sh.exe.
2 To start the install script, enter ./imprep.ksh in the Korn shell window.
The imprep.ksh script first prompts you to review the parameter settings.


Installation Tasks
To run the imprep.ksh script under UNIX

your system.

./imprep.ksh to start the validation script.




Caution: If imprep.ksh fails, you may use Siebel Tools to delete the
repository; then rerun the script.
This completes the Siebel Database Server installation.
Perform the following task after you complete your installation of the Siebel
Database Server:
Populating the Siebel File System


Migrating Customizations From Development
to OS/390 Production 13
Pre-Migration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4

Customizing Siebel for Your Enterprise . . . . . . . . . . . . . . . . . . . . . 13-4
Migration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5

Generating the List of Invalid Objects Report . . . . . . . . . . . . . . . . . 13-5
Migrating Customizations from Development to the Target Database 13-10
Modifying the Siebel Schema on the Target Database . . . . . . . . . . . . . . .13-15
Validating the Target Database Against the Source Repository . . . . . 13-18
Post-Migration Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-22

Migrating Customizations From Development to OS/390 Production
About This Chapter
This chapter assumes that you perform your development on DB2 UDB at mid-tier
on a machine running the Windows NT, AIX, HP-UX, or Solaris operating systems.
Migration from development to production consists of several tasks, some of which

the Siebel system administrator performs, other tasks being performed by the
DB2 UDB for OS/390 database administrator. Table 13-1 illustrates the sequence of
tasks for migration of development data to a production environment.
Table 13-1. Development Migration Tasks (1 of 2)
Siebel developer 1 Customizes Siebel for business requirements in the site development
environment.
Siebel system 2 Edits parameters in validate_obj_names.ksh script.

administrator
3 Executes validate_obj_names.ksh script, thereby generating the List of
Invalid Objects Report. This report lists any objects that exceed the size
limitations imposed by DB2 UDB for OS/390 for the following:
Table name
Column name
Index name and size
4 Reviews report and fixes any object that violates the maximum length for DB2
UDB for OS/390.
DB2 UDB for 5 Updates the tbspaces.ctl parameter file, edited earlier for installation, to
OS/390 database reflect the storage for any new object created, such as tables or indexes.
administrator (DBA)

About This Chapter
Table 13-1. Development Migration Tasks (2 of 2)
Siebel system 6 Changes repository name in target database from the default (Siebel
administrator Repository).
7 Modifies parameters in the dev2prod.ksh script.
8 Executes dev2prod.ksh against the target database with the following

results:
Exports Siebel development source repository.

Imports the Siebel repository exported in the previous step to the user
acceptance or production environment.
Exports the schema definitions from the development database into a file
for use in a subsequent step.
9 Checks the log file generated for any errors, fixes them, and reruns, if needed.
DB2 UDB for 10 Modifies parameters in the generate_ddl.ksh script.

OS/390 DBA
11 Executes generate_ddl.ksh script.
Depending on how its parameters were set, generate_ddl.ksh either:

Creates sieb_schema.sql.
or
Creates tables and indexes on DB2 automatically.
12 If this was not already done automatically in the last step, executes
sieb_schema.sql on the host to create the Siebel tables and indexes.
Siebel system 14 Modifies parameters in dev2prod_validate_rep.ksh script to verify that

administrator the repository was migrated successfully.
15 Executes dev2prod_validate_rep.ksh script to make sure that the DB2
UDB for OS/390 database is in synch with the repository copied from the
development environment.
17 Creates or copies records in the production database required for the newly
developed application, such as the List of Values, created in the development
environment.

Pre-Migration Tasks
Pre-Migration Tasks 13
You should have already read Chapter 9, “Configuring the DB2 UDB for UNIX and
Windows NT,” and Chapter 10, “Installing the Siebel Database Server with DB2
UDB for UNIX and Windows NT.”
Complete the following task before migrating your development data to your user
acceptance testing area on DB2 UDB for OS/390:
“Customizing Siebel for Your Enterprise.”
Customizing Siebel for Your Enterprise 13
The migration of Siebel to the OS/390 environment begins with your customization
of Siebel within your development environment. This customization includes:
Changing the Siebel eBusiness views, business objects, applets, and tables
Adding new columns to existing tables

Migration Tasks
Migration Tasks 13
Migration of the database from the development environment to production

consists of the following tasks:
“Generating the List of Invalid Objects Report”

“Migrating Customizations from Development to the Target Database” on
page 13-10
“Validating the Target Database Against the Source Repository” on page 13-18
Generating the List of Invalid Objects Report 13
A Siebel system administrator must verify that no database objects created in the
development environment violate the size limitations imposed by the OS/390
production environment.
To accomplish this verification, you must run the script validate_obj_names.ksh

against the development database after editing its parameters as appropriate to your
business requirements. This file generates the List of Invalid Objects Report, which
lists any objects that exceed the DB2 UDB for OS/390 size limitations for the
following:
Table name
Column name
Index name and size
After reviewing the report, fix any objects that exceed the maximum length for
DB2 UDB for OS/390—18 characters for table names, index names, and column
names.

Migration Tasks

The validate_obj_names.ksh file and other Siebel Database Server scripts use
Korn shell syntax for compatibility across Siebel Enterprise Server platforms.
Note the following guidelines when editing all Siebel database server files:
To comment out a line, use the pound sign (#) rather than REM.
Use the forward slash (/), rather than the backslash, as a separator in the
C:/sea6xx/dbsrvr for NT
/usr/sea6xx for UNIX
Follow the syntax examples and instructions in the .ksh script files closely. They

Migration Tasks
Editing the List of Invalid Objects Report Script

The Siebel Administrator uses Windows Notepad or a similar text editor to edit the
parameters in validate_obj_names.ksh, located in the /db2390 installation
subdirectory on the Windows NT or UNIX client, before running it to produce the
comparison report between the source and the target databases.
These parameters are defined at the top of the file, and are described in Table 13-2.
Table 13-2. validate_obj_names.ksh Parameters
SRC_TBLO=SIEBEL The Siebel Database tableowner. This is the

account that will own the Siebel objects.
SRC_TBLO_PSWD=SIEBEL Siebel Database tableowner password.
ODBC=CHANGE_ME ODBC data source name for development

database.
REPOSITORY_NAME=”CHANGE_ME” Name of the development repository. (Do not

remove quotes.)
SIEBEL_HOME= The full path of the Siebel Server installation

c:/CHANGE_ME/siebsrvr directory.
C:/CHANGE_ME/siebsrvr; it must be
modified to show the correct directory or your
report will fail.
Under UNIX, this is set to the SIEBEL_ROOT
directory.
Executing the List of Invalid Objects Report Script

This script will run for approximately two minutes. Before running the script, make
sure that you have edited the parameters in the validate_obj_names.ksh file.
You will run this script on your Windows NT or UNIX client.

Migration Tasks
To run the validate_obj_names.ksh script under Windows NT

C:/sea6xx/dbsrvr/db2390 directory. Double-click sh.exe. This will bring up
a Korn shell window.
2 To start the install script, enter ./validate_obj_names.ksh in the Korn shell

window.
The validate_obj_names.ksh script first prompts you to review the parameter

settings.
NOTE: When starting any Siebel Database Server installation or upgrade

script, be sure to enter Y after you have reviewed the parameters at the
The validate_obj_names.ksh script exits when it has completed.
To run the validate_obj_names.ksh script under UNIX

1 Make sure that you have set the parameters in the validate_obj_names.ksh
file properly for your system.

Migration Tasks

./validate_obj_names.ksh to start the install script.
The validate_obj_names.ksh script will prompt you to review the parameter

settings.


The validate_obj_names.ksh script will exit when it has completed.
Reviewing the List of Invalid Objects Report

Review the List of Invalid Objects Report to make sure that none of the objects your
development team has created violate the size limitations of table names, column
names, and index names for the target DB2 system.
Correct any object size violations you find and rerun the
validate_obj_names.ksh script to verify that all objects now meet the target
system requirements.
The report may include some Siebel tables, columns, and indexes. Disregard Siebel-
created or Siebel-provided objects in this report. Any customized objects appearing
in the report should be within the DB2 size limitations.

Migration Tasks
Updating the Table Group Configuration File

The DB2 UDB for OS/390 database administrator updates the tbspaces.ctl
parameter file, which was edited prior to installing the Siebel database in the
development environment, to reflect the storage requirements for any new objects
created. For more information regarding the tbspaces.ctl parameter file, review
“Editing the Table Group Configuration File” on page 12-17.
Migrating Customizations from Development to the Target Database 13
The Siebel System Administrator now migrates the new Siebel tables, indexes, and
repository changes created in the development environment to the target DB2
database by editing and executing the dev2prod.ksh script, producing the
following results:
Exports the source repository from the development environment.

Imports the repository to the target system.
Exports the schema definition from the development environment to the target
system as schema.ddl.
Editing the Migration Script

The Siebel Administrator edits the parameters in dev2prod.ksh, located in the
/db2390 installation subdirectory of your Windows NT or UNIX client, before
running it against the development database.

Migration Tasks
These parameters are defined at the top of the file, and are described in Table 13-3.
Table 13-3. dev2prod.ksh Parameters (1 of 2)
SRC_USR=SADMIN Source database: Siebel application user login (SADMIN).

Change as appropriate for your installation.
SRC_PSWD=SADMIN Source database: Siebel application user password (SADMIN).

SRC_TBLO=siebel Source database: SSE tableowner (siebel).
SRC_TBLO_PSWD=siebel Source database: SSE tableowner password.
SRC_REPOS=”Siebel Repository” Source database: repository in which the required schema

definition resides. Confirm that this has been updated to “Siebel
Repository”).
Note that quotes are required.
SRC_ODBC=CHANGE_ME Source database: ODBC data source name (Siebel Server

Database).
TGT_USR=SADMIN Target database: Siebel application user login (SADMIN).

TGT_USR_PSWD=SADMIN Target database: Siebel application user password (SADMIN).

TGT_TBLO=siebel Target database: Siebel application user tableowner (SSE

tableowner). Change as appropriate for your installation.
TGT_TBLO_PSWD=siebel Target database: Siebel application user (SSE) tableowner

password (SIEBEL). Change as appropriate for your
installation.
TGT_REPOS=”Siebel Repository” Target database: Repository in which the required schema

definition resides (“Siebel Repository”). Change as
Note that quotes are required.

Migration Tasks
Table 13-3. dev2prod.ksh Parameters (2 of 2)
TGT_ODBC=CHANGE_ME Target database: ODBC data source name for DB2 for OS/390
database.
Note: You must create a new ODBC data source name for the
target database.
SIEBEL_HOME= The full path of the Siebel Server installation directory.

C:/CHANGE_ME/siebsrvr; it must be modified to show the
correct directory or your migration will fail.
Executing the Migration Script

When the Siebel system administrator executes dev2prod.ksh, it creates the
schema.ddl file, which contains the schema definitions and will later be used by
the database administrator to execute the generate_ddl.ksh script against the
target database on the mainframe.
The script dev2prod.ksh runs for approximately 45 minutes. Before executing the
script, make sure that you have edited its parameters according to the instructions
described earlier under “Editing the Migration Script” on page 13-10.
Instructions follow for executing dev2prod.ksh on the Windows NT and UNIX

client for transfer of the output to DB2 UDB for OS/390.
To run the dev2prod.ksh script under Windows NT

1 The database administrator must first change the repository name in the target
database from the default (Siebel Repository).

C:/sea6xx/dbsrvr/db2390 directory. Double-click sh.exe. This will bring up
3 To start the install script, enter ./dev2prod.ksh in the Korn shell window.
The dev2prod.ksh script first prompts you to review the parameter settings.

Migration Tasks

The dev2prod.ksh script exits when it has completed.
To run the dev2prod.ksh script under UNIX

1 The database administrator must first change the repository name in the target
database from the default (Siebel Repository).
2 Make sure that you have set the parameters in the dev2prod.ksh file properly
for your system.

./dev2prod.ksh to start the install script.
The dev2prod.ksh script will prompt you to review the parameter settings.

Migration Tasks


The dev2prod.ksh script will exit when it has completed.

Migration Tasks
Modifying the Siebel Schema on the Target Database 13
After the storage groups, databases, bufferpools, and tablespaces have been
created, the database administrator executes the file generate_ddl.ksh against
the production database. This file generates the ddl (sieb_schema.sql) that
creates the Siebel tables and indexes.
The definitions in the file schema.ddl, generated from dev2prod.ksh, are

compared with the physical schema of the target database, and a list of statements
is generated that the database administrator uses later when migrating the changes
to the target database.
Editing the Database Schema Generation Script

The database administrator edits the parameters in generate_ddl.ksh, located in
the /db2390 installation subdirectory, before running it to produce the ddl for
tables and indexes on the target database. When database administrators edit the
generate_ddl.ksh, they can set the DO_DDL flag (Table 13-4 on page 13-16) to Y
to automatically create the tables and indexes on DB2 UDB for OS/390.
If the enterprise requires files to be processed through a version control tool, the
administrator should set the DO_DDL flag to N.
The file fetches the storage parameters as modified for migration by the DBA in the
file tbspaces.ctl (or smalltbs.ctl).
The script also fetches the schema definitions from the schema.ddl file produced
by dev2prod.ksh in the previous task.
This script produces the file sieb_schema.sql, containing the ddl statements for
Siebel tables and columns, if the DO_DDL flag is set to N.If DO_DDL is set to Y,
sieb_schema.sql is not produced and tables and indexes are created in the target
database.

Migration Tasks
The editable parameters are defined at the top of the file, and are described in
Table 13-4.
Siebel objects.
ODBC=CHANGE_ME ODBC data source name of target database.
DBSRVR_ROOT= The full path of database software installation:

c:/CHANGE_ME/dbsrvr
c:/CHANGE_ME; it must be modified to show the correct directory
or your installation will fail.
Under UNIX, this will be the complete path to the dbsrvr directory.
C:/CHANGEME/siebsvr; it must be modified to show the correct
directory or your installation will fail.
MODE=CHANGE_ME You must specify the context in which you are using
generate_ddl.ksh. In other words, you must indicate whether you
are running it for installation of the database server, migration of EAI
customizations, or the migration of development customizations to the
test or production environment:
Install. Database installation.
EAI. Migration of EAI repository customizations to test or
production.
Non-Install. Migration of general customizations from
development to test or production.
Note that when you set the MODE parameter, you must also set the
MERGE_FLG parameter correspondingly. See the description of
MERGE_FLG below for more information.

Migration Tasks
MERGE_FLG=CHANGE_ME Database merge flag. When set, Siebel compares the definitions of
tables and indexes from the definition file to those in the physical
database, and updates the physical tables and indexes appropriately.
Setting the Merge Flag to Match the Mode
Fresh installations:
N=Do not compare table schemas. This setting would most commonly
be used for fresh installations.
Note that if the MODE parameter above equals Install, the
MERGE_FLG must equal N.
Migrating EAI repository customizations from development to
production:
Y=Merge EAI development repository customizations with the
production EAI repository.
Migrating customizations from development to production:
Y=Compare table schemas, creating a list of deltas. This setting would
most commonly be used for migrations from development to
production or for upgrades when only the delta information is required.
Caution: If your environment requires generation of ddl for all
tables and indexes, set the MERGE_FLG parameter to N.
Note: If the MODE parameter above equals Non-Install,
MERGE_FLG must equal Y.

N=Create ddl that can be processed through a version control tool.
Y=Create the tables and indexes in the DB2 UDB for OS/390 database
automatically.
TBSPACE_FILE=tbspaces.ctl Name of the file from which tablespace storage parameters are
retrieved.
Change the name of this file, if necessary, to match the name you saved
it with when you used either of the Siebel templates tbspaces.ctl
or smalltbs.ctl.

Migration Tasks
Executing the Siebel Database Schema Generation Script

Before executing generate_ddl.ksh, make sure that you have edited the
parameters according to the instructions described earlier in “Editing the Database
Schema Generation Script” on page 13-15.
If the DO_DDL flag is set to N, the generate_ddl.ksh script runs for about one
minute. The script creates the file sieb_schema.sql in the /db2390 installation
subdirectory.
If the DO_DDL flag is set to Y, the runtime of the script depends on the number of
objects being created or modified. In this case, the file sieb_schema.sql is not
generated.
Validating the Target Database Against the Source Repository 13
The Siebel system administrator must validate the target DB2 database against the
DB2 source repository that was imported into the target database. The Siebel
administrator accomplishes this by editing and executing the script
dev2prod_validate_rep.ksh against the target database. This script checks for
discrepancies between the repository and the physical database, creating a log of
any discrepancies found. It then updates the version number on the repository of
the target database.

Migration Tasks
Editing the Repository Validation Script

Your Siebel system administrator edits the dev2prod_validate_rep.ksh script
using Windows Notepad or another text editor to set the correct parameters for
installation before running the script.
The repository validation script, dev2prod_validate_rep.ksh, is located in the /

db2390 installation directory on your Windows NT or UNIX client. These
parameters are defined at the top of the dev2prod_validate_rep.ksh file, and are
described in Table 13-5.
Table 13-5. dev2prod_validate_rep.ksh Parameters
SRC_USR=SADMIN User name of the Siebel administrator.

SRC_USR_PSWD=SADMIN Password of the Siebel administrator. Change

as appropriate for your installation.
SRC_TBLO=siebel The Siebel Database tableowner. This is the

account that will own the Siebel objects.
SRC_TBLO_PSWD=siebel Siebel Database tableowner password.
ODBC=CHANGE_ME Name of the ODBC data source for accessing

the target database.
REPOS_NAME="Siebel Repository" Repository in which the required schema

definition resides (Siebel Repository).
SIEBEL_HOME= The full path of the Siebel Server installation

c:/CHANGE_ME/siebsrvr directory.
C:/CHANGE_ME/siebsrvr; it must be
modified to show the correct directory or
your migration will fail.
Under UNIX, this is set to the

Migration Tasks
Executing the Repository Synchronization Script

Before executing the script, make sure that you have edited the parameters in the
dev2prod_validate_rep.ksh file.
This script will run for approximately 15 minutes.
To run the dev2prod_validate_rep.ksh script under Windows NT

C:/sea6xx/dbsrvr/db2390 directory. Double-click sh.exe.
2 To start the install script, enter ./dev2prod_validate_rep.ksh in the Korn

shell window.
The dev2prod_validate_rep.ksh script first prompts you to review the

parameter settings.

script, be sure to enter Y after you have reviewed the parameters at the
The dev2prod_validate_rep.ksh script exits when it has completed.

Migration Tasks
To run the dev2prod_validate_rep.ksh script under UNIX

1 Make sure that you have set the parameters in the
dev2prod_validate_rep.ksh file properly for your system.

./dev2prod_validate_rep.ksh to start the install script.
The dev2prod_validate_rep.ksh script will prompt you to review the

parameter settings.


The dev2prod_validate_rep.ksh script will exit when it has completed.

The script creates a log file in the /db2390 installation subdirectory. Review this log
file carefully for errors, as described in Chapter 12, “Installing the Siebel Database
Server with DB2 UDB for OS/390.”
The report may include some Siebel tables, columns, and indexes. Disregard Siebel
created/provided objects in this report. Any customized objects appearing in this
report should be reviewed.

Post-Migration Task
Post-Migration Task 13
After you have successfully migrated your source database to your target
environment, you must create or copy records for any new applications you created
in your development environment. Such records might include:
List of Values. Contains important values, such as customer payment methods.
Messages. Any message table entries you created for your applications.

Configuring the Oracle Database Server 14
Database Sizing Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
Database Layout Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5

Oracle Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
Allocating Space in Your Oracle Database for Siebel Data . . . . . . . . . 14-9
Database Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10

Pre-Installation Administration Tasks . . . . . . . . . . . . . . . . . . . . . . 14-10
Post-Installation Administration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . .14-12

Configuring the Oracle Database Server
About This Chapter
This chapter is written for database administrators who will set up the Oracle
database.
It provides an overview of Siebel database configuration and sizing

recommendations for the Oracle database server. The parameter settings offered in
this chapter are intended as starting points. You may need to increase these,
depending on your enterprise requirements.
“Database Sizing Guidelines.”

“Database Layout Guidelines” on page 14-5.
“Database Configuration Guidelines” on page 14-7 explains how to configure an
Oracle database.
“Database Administration” on page 14-10 details tasks involved before and after
installing the Siebel database server scripts on an Oracle database.

Database Sizing Guidelines 14
One of the most important factors to determine about your database is its overall
size. In your planning, you will need to allocate space for system storage, rollback
or temporary storage space, log files, and other system files required by Oracle, as
well as space for Siebel data and indexes. If you allocate too little space for your
system, performance will be affected and, in extreme cases, the system itself may
be halted. If you allocate too much, you will waste space.
The space needed by Oracle will vary primarily based on the total number and types
of users supported. Siebel Systems recommends that you consult the
documentation provided by Oracle for more information on these requirements.
functionality you will implement and the amount and nature of data supporting that
functionality. At a minimum, Siebel version 6.x requires that you size your Oracle
database at from 400 to 600 MB. This range will vary, based on the default storage
space your database administrator sets up for tablespaces.
The process for making accurate database size calculations is a complex one
involving many variables. The following guidelines will assist you in the process:
Determine the total number and types of users of Siebel eBusiness (for example,
500 sales representatives and 75 sales managers).
required to support them. Typically, the largest entities are:
Accounts
Activities
Contacts
Forecasts
Opportunities
Service Requests

the estimated data size for the largest entities.
You must add extra space for the storage of other Siebel data. A rough guideline
for this additional amount would be one-half the storage required for these key
entities.

Be certain to allow for a margin of error in your total size calculation.
Be certain to factor growth rates into your total size calculation.

Database Layout Guidelines 14

is largely dependent on the I/O performance on the Database Server. To guarantee
optimal I/O performance, tables and indexes in the database must be arranged
across available disk devices so that the I/O load is evenly distributed.

A redundant array of independent disks, or RAID, can provide large amounts of

I/O throughput and capacity, while appearing to the operating system and RDBMS
as a single large disk (or multiple disks, as desired, for manageability). The use of
RAIDs can greatly simplify the database layout process by providing an abstraction
layer above the physical disks, while ensuring high performance.
Regardless of the RDBMS you implement and your chosen disk arrangement, be
certain that you properly distribute the following types of database objects:
Database log or archive files

Temporary work space used by the database
Tables and indexes
In most implementations, the tables and corresponding indexes in the following list
tend to be the most heavily used and should be separated across devices. In general,
indexes should be on different physical devices from the tables on which they are
created.
S_ACCNT_POSTN S_OPTY
S_ADDR_ORG S_OPTY_POSTN
S_CONTACT S_POSTN_CON
S_DOCK_TXN_LOG S_POSTN_RPT_REL
S_EMPLOYEE S_SRV_REQ
S_EVT_ACT S_OPTY
S_ORG_EXT

Even if space is at a premium, you must separate the indexes whose names end with
_P1 from the tables on which they are created, because they are heavily used in
outer join operations.
If you will make extensive use of the Enterprise Integration Manager (EIM), you
may want to put the interface tables (names ending in _IF) on different devices
from the Siebel base tables, as both are accessed simultaneously during EIM
operations.

Database Configuration Guidelines 14
This section contains guidelines for obtaining optimum performance from an Oracle
database. Refer to your Oracle technical documentation for additional information.

Oracle Configuration Parameters 14
The init.ora file contains parameters that control the operation of the Oracle
database. The settings of these parameters have a major impact on the performance
of Siebel applications.
NOTE: Use the following settings only as guidelines for your initial configuration.
Your final settings will vary based on the server hardware configuration, the
number of users, and the type of workload.
In the init.ora file, Oracle provides default parameter values for small, medium,
and large database configurations. Unless the configuration parameters are
specified in the following settings, set them to the large database values. Refer to
Oracle documentation for detailed descriptions of each of the parameters and their
effects on database performance and system resource utilization.
Following are brief descriptions of these parameters:
OPTIMIZER_MODE. Your Siebel application provides better response time using the
rule-based optimizer rather than the cost-based optimizer. The cost-based optimizer
often does not have enough information to make correct decisions regarding search
plans, which can result in less efficient queries and updates. The cost-based
optimizer also requires frequent updates to the database statistics.

DB_BLOCK_BUFFERS. The minimum recommended value is 10,000 blocks

(assuming a block size of 2 KB). This yields 20 MB of block buffers. If significant
I/O activity occurs, you can increase this value, provided that enough RAM is
available.
SHARED_POOL_SIZE. Start with a minimum value of 20 MB. A DBA should adjust

this value upward based on the hardware (available physical memory) and
performance. Siebel applications make heavy demands on the dictionary cache for
columns. In Oracle, you cannot explicitly set the size of the column cache. Instead,
column cache is set as a fixed percentage of the shared pool size. By setting a large
shared pool size, you effectively set a large column cache size.
Consult your Oracle documentation for guidelines and more information.
DB_FILE_MULTIBLOCK_READ_COUNT. This value should be set between 16 and 32

blocks, and adjusted as necessary. You may want to set an initial value of 32.
SORT_AREA_SIZE. This value is specified in bytes, and may be adjusted according to

the number of users, the amount of RAM available, and the size of sorted queries.
You should start with an initial value of 512,000.
SORT_AREA_RETAINED_SIZE. This value is specified in bytes, and determines how

much sort area is retained for each user process. You should start with an initial
value of 65,536.
OPEN_CURSORS. This parameter may be adjusted according to observed usage

patterns. The minimum open cursor requirement for Oracle support in Siebel 6.x is
1,500. If you set this value lower, Oracle may return an error to the application that
prevents you from continuing.
USE_ISM. This value may be set to FALSE by the Oracle installer. On some platforms,
Oracle recommends that you set the USE_ISM value to FALSE to avoid software
anomalies. If the version of Oracle you are using does not have these anomalies, the
recommended setting for your Siebel application is TRUE. Refer to Oracle World
Wide Support for specific information regarding this parameter on your database
platform.
DB_BLOCK_SIZE. The default recommended block size is 2 KB. However, Siebel

strongly recommends that you set the block size to a minimum of 4 KB to prevent
excessive row chaining and performance degradation with the EIM.
NLS_DATE_FORMAT. This parameter is set to DD-MON-YY by default. To guarantee

year 2000 compliance, you should reset it to DD-MON-RR, or to the appropriate
national date format, substituting RR for YY.

NLS_LANGUAGE. Specifies the default language of the database. This language is

used for messages, day and month names, the symbols for A.D., B.C., A.M., and
P.M., and the default sorting mechanism.
PROCESSES. Oracle defaults to 50 processes, which is often not enough. Siebel

Systems strongly recommends setting this figure to a minimum of 100.
SESSIONS. Certain Siebel operations require multiple connections. If you change this
parameter, make sure it is set to a number greater than 1.
Allocating Space in Your Oracle Database for Siebel Data 14
To improve performance on your production system, you can create at least two
tablespaces: one for indexes and one for data. In order to distribute objects that you
anticipate to be large or points of contention, you can create additional separate
tablespaces (preferably on separate disk devices). You can also override the default
tablespace storage parameters to reflect the actual amount of data in your tables. Be
sure that the Siebel tableowner account is granted the privilege to create tables and
indexes in the tablespaces you create.

Database Administration
Database Administration 14
Several database administration tasks are required both before and after installing
your Siebel software.
Pre-Installation Administration Tasks 14
Before you install Siebel database scripts for the Oracle RDBMS, review the
following database administration steps.
Before installing Siebel on an Oracle platform

1 Create temporary tablespaces and set appropriate default storage parameters for
them.
The Oracle default of 10 KB extents has an adverse effect on the response time
of queries with sorts. The INITIAL and NEXT EXTENT parameters for your
temporary tablespace should be set to a multiple of the init.ora parameter
SORT_AREA_SIZE, plus the size of one database block for header information.
This setting will guarantee that operations that use space in the temporary table
are able to efficiently allocate space.
2 Estimate the best distribution of tables and indexes across disks to optimize I/O.
Try to put indexes for a given table on a different disk from the table data.
3 Set storage parameters for your data and index tablespaces.

The Siebel installation procedure does not set default generic storage parameters
for the objects it creates, as their sizes will vary widely by customer. To
guarantee suitable initial sizing and successful installation:
Set the initial extent to a very small size (the minimum is one database block)
so that unused tables and indexes do not consume large amounts of space.
Set the default next extent for your data and index tablespaces to a minimum
of 100 KB.
Monitor object growth and fragmentation carefully.
NOTE: The Siebel software will automatically alter the storage parameters for
certain objects.

4 Define rollback segments, using the following guidelines:

Make sure that you have suitable rollback segments available for installing,
running, and administering your Siebel application. The number and size of
rollback segments required will vary depending on such variables as your
implementation of Siebel applications, data volumes, and the number of
users.
Provide enough rollback segments.
Common configuration for an OLTP application, like Siebel eBusiness, is four

rollback segments per 20–50 users, each with an initial extent of 100 KB, and
NEXT set to 100 KB.
Create a single, much larger rollback segment for Siebel Server components,
such as Enterprise Integration Manager (EIM).
The Siebel Server components can point directly to this rollback segment
when performing long-running queries.
Remove the default rollback segments created by the Oracle installer

program, which are much smaller, so that only the new rollback segments
are used.
Create your rollback segments in a dedicated tablespace on a dedicated disk.
Rollback segments typically support high I/O rates, so this configuration will
improve system performance measurably.

Post-Installation Administration Tasks 14
After your Siebel installation is up and running, monitor the following areas on a
regular basis:
Insertion rates on tables. You will probably want to set the INI_TRANS value for
tables with high insertion rates to a value higher than 1; a typical setting is 4.
This parameter determines how many simultaneous inserts can occur on the
database blocks that store data for those tables and, therefore, can affect
performance in an intensive data-entry environment.
SGA cache hits. Determine whether SGA parameters need to be adjusted for your
system.
The extents used by each object. A large number of extents on a table or index
creates response time degradation for transactions that access the table or index.
Siebel tables that are subject to frequent INSERT and DELETE operations. This
transaction mixture can cause some databases to become fragmented over time.
You should monitor the space utilization and fragmentation of these tables and
perform regular database maintenance procedures as recommended by your
database vendor. The following list contains the names of the tables you should
monitor.
S_DOCK_TXN_LOG
S_DOCK_TXN_LOGT
S_DOCK_TXN_SET
S_DOCK_TXN_SETT
S_DOCK_INST
S_DOCK_INIT_ITEM
Rollback segments. This will guarantee that enough segments are available and
that they are the optimum size for common operations.
You have now configured your database properly, and can proceed to installing the

Installing the Siebel Database Server
with Oracle 15
Database Server Scripts Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4

Installing the Database Server Scripts . . . . . . . . . . . . . . . . . . . . . . 15-4
Reviewing the Software Installation . . . . . . . . . . . . . . . . . . . . . . . . 15-7
Creating Tableowner and Administrator Accounts . . . . . . . . . . . . . . 15-7
Overriding Default Storage Parameters . . . . . . . . . . . . . . . . . . . . . . 15-8
Testing the ODBC Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-9

Executing the Database Server Installation Script . . . . . . . . . . . . . 15-10
Editing the Database Installation Script . . . . . . . . . . . . . . . . . . . . 15-11
Running the Database Installation Script . . . . . . . . . . . . . . . . . . . . . . . .15-13
Reviewing the Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-15


Installing the Siebel Database Server with Oracle
About This Chapter
This chapter is written for system administrators who will install the Siebel
Database Server.
To install the Siebel Database Server, you will first install the database scripts on a
Windows NT or UNIX Siebel Server. Then you will run the database scripts to create
the following in your Siebel Database Server:
A database role/group with appropriate access to the Siebel database objects

The Siebel administrator’s user account
Tables
Indexes
Triggers and stored procedures
Seed data
File attachments to be copied to the Siebel File System

Before installing the Siebel Database Server, you must complete the following tasks:
Complete the appropriate RDBMS-specific information in a photocopy you make

The Oracle SQL*Net Connect String. You will need this to connect to your
Oracle database.
The Tableowner Account User Name and Password. Oracle requires that you
assign a user name and password to any database tables you create. Prior to
installing the Database Server, you will edit the grantusr.sql script and
enter this information. SIEBEL is the default Tableowner Account user name
and password for Siebel applications.
The Siebel Data Tablespace. The name of the tablespace on the Oracle server
where the Siebel data tables are stored.
The Siebel Index Tablespace. The name of the tablespace on the Oracle server
where the Siebel indexes are stored.
Obtain the services of a qualified database administrator to assist you during

your installation.
Server,” to install at least one Siebel Server.
Make sure that Oracle is properly configured, as documented in Chapter 14,

“Configuring the Oracle Database Server.”
Allocate and configure disk space appropriate to your installation requirements

and to Oracle.

Database Server Scripts Installation
Database Server Scripts Installation 15
Installation of the database scripts consists of the following tasks:
“Installing the Database Server Scripts”

“Overriding Default Storage Parameters” on page 15-8 (optional)
NOTE: When starting the Siebel Database Server installation or upgrade scripts, be
sure to enter Y after reviewing the parameters at the beginning of the script.
Pressing ENTER alone causes the script to quit with a syntax error. If this occurs,
restart the script.
Complete the steps below to complete the Database Server installation scripts on
one computer. You must have a Siebel Server already installed on this computer.
To install the Database scripts on Windows NT




common options.

Browse button.
installation.
Next.

in your photocopy of Appendix A, “Deployment Planning Worksheet.”

4 Enter env to review environment variable settings, and ensure that the Siebel
Siebel Server software is installed.

5 If the Siebel environment variable is not set, navigate to the SiebSrvr_Home

directory and enter: . ./siebenv.sh.
documentation.

where:

script.

At a minimum, select the package for DB2 and the Sample File Attachments.
the installation.
The Database Server software installer will copy the necessary files to disk and

bin
files
oracle
enu
See “Populating the Siebel File System” on page 15-21.
oracle. Contains the scripts for Oracle.
enu. Contains language-specific files in U.S. English.
The Database Server installation script creates the Siebel program folder.
Creating Tableowner and Administrator Accounts 15
You must execute the grantusr.sql script against your database server to create
the Siebel tableowner and Siebel administrator database accounts.
The grantusr.sql script must be run before installing the Siebel Database Server.
This script is located in the appropriate subdirectory for your database platform.
Your database administrator should review and run this script, which performs the
following functions:
Creates a Siebel tableowner account that “owns” all the database objects for
your Siebel application.
Creates a role (sse_role) with create session privileges.
The default user name and password for the logon are listed in the grantusr.sql
script. If you want another logon, edit the grantusr.sql script and change all the
references to your preferred name.
NOTE: If the user SADMIN already exists on your system, this script will modify its
password.

To run the grantusr.sql script

1 Run the grantusr.sql script from SQL*Plus, using an account with DBA
privileges, and using the following command:
SQL> @c:\dbsrvr\oracle\grantusr.sql
NOTE: You must specify the full path to the dbsrvr directory.
The script prompts you for the default tablespace in which your Siebel objects
are to be created.
2 Type the tablespace name listed in Appendix A, “Deployment Planning

Worksheet.”
Overriding Default Storage Parameters 15
If you would like to override the default storage parameters, such as the tablespaces
in which specific tables or indexes are created, edit the ddl.ctl file located in the
dbsrvr\oracle directory.
NOTE: The ddl.ctl file should be modified only by a qualified DBA.
For each Siebel table, you can specify a tablespace by using the Space parameter.
In the following example, the tablespace for the table S_APP_VIEW is set to DATA1.
As provided by Siebel, the .ctl file does not set storage parameters for the objects
it creates, so they will default to the parameters of the tablespaces in which they are
created.

As shown in the example below, you can use the Space parameter to set storage
parameters for specific tables.
[Object 219]
Type = Table
Name = S_APP_VIEW
Column 1 = ROW_IDVARCHAR(15)NOTNULL
Column 2 = CREATEDTIMESTAMPNOTNULL DEFAULT %NOW%
Column 3 = CREATED_BYVARCHAR(15)NOTNULL
Column 4 = LAST UPDTIMESTAMP NOTNULL DEFAULT %NOW%
Column 5 = LAST_UPD_BYVARCHAR(15)NOTNULL
Column 6 = DCKING_NUMNUMERIC(22,7)DEFAULT 0
Column 7 = MODIFICATION_NUMNUMERIC(10,0)NOTNULL DEFAULT 0
Column 8 = CONFLICT_IDVARCHAR(15)NOTNULL DEFAULT ‘0’
Column 9 = NAMEVARCHAR(50)NOTNULL
Column10 = DESC_TEXTVARCHAR(255)
Column11 = LOCAL_ACCESS_FLGCHAR(1)
Space = data1
\siebsrvr\bin directory. Siebel Systems recommends that you use this utility to

1 From the odbcsql prompt, type:
where:
SIEBEL_DATASOURCE_NAME = the data source name for which you would like
2 Type:
3 Type:
select APP_VER, COMMENTS from TABLE_OWNER .S_APP_VER;

The previous commands should result in the display of the application version and
that problems exist downstream from the ODBC layer to the database, or that
problems exist in the user/password combination or SSE_ROLE privileges for that
user.
Installing the Database Server 15
You must complete two steps to install the Siebel Database Server:
“Executing the Database Server Installation Script”

“Editing the Database Installation Script” on page 15-11
“Running the Database Installation Script” on page 15-13
“Reviewing the Log Files” on page 15-15
Executing the Database Server Installation Script 15
The Siebel Database Server installation script is called install.ksh, and is located
in the Oracle subdirectory. It performs the following tasks:
Creates Siebel tables and indexes in a specified tablespace.

Imports Siebel seed data.
Installs Siebel seed data specific to your database—for example, correspondence
templates—thereby populating 118 tables. (Seed data within a table can be
identified by its ROW_ID prefix of 0.)
Installs views, packages, and procedures for your database.

Installs Siebel triggers and views.
To install the Siebel Database Server, you must first edit the database server install
scripts.


The install.ksh script, like all other Siebel Database Server scripts, uses Korn
Shell syntax for compatibility across Siebel Enterprise Server platforms. The syntax
for these scripts is somewhat different from that for the Windows NT batch files
provided with earlier versions of Siebel applications.
Note the following guidelines when editing all Siebel Database Server scripts:
To comment out a line, use the pound sign (#), not REM.
The forward slash (/), rather than the backslash, is used as a separator in
C:/sea6xx/dbsrvr
Follow the syntax examples and instructions in the .ksh files closely. They
Editing the Database Installation Script 15
Edit the install.ksh script, using Windows Notepad or another text editor, to set
the correct parameters for your installation before running the script. These
parameters are defined at the top of the install.ksh file, and are described in
Table 15-1.
Make sure you update items that default to CHANGE_ME or unspecified. These
default entries will not work if left unchanged.
SRC_PSWD=SADMIN Password of the Siebel administrator: ORACLE.
SRC_TBLO=siebel The Siebel Database tableowner.

In Oracle, this is the account that will own the Siebel objects.

ODBC=CHANGE_ME ODBC data source to access the database. The data source is
created automatically by the Siebel Server installation, using
the format SiebSrvr_EnterpriseServerName. The
default is CHANGE_ME and must be modified or your
To find out the ODBC data source name for the Siebel Server,
do the following:
Under UNIX, navigate to SIEBEL_ROOT/sys and open
the file .odbc.ini.
DBSRVR_ROOT=C:/CHANGE_ME/DBSRVR Root directory of the Database Server installation. (Under

UNIX, this will be the same as the SIEBEL_ROOT directory.)
DATA_AREA=”CHANGE_ME” Under UNIX, the Oracle tablespace in which to create tables.

Quotes are required around this value.
INDX_AREA=”CHANGE_ME” Under UNIX, the Oracle tablespace in which to create

indexes. Quotes are required around this value.
DBSRVR_ROOT= c:\change_me\dbsrvr Under UNIX, this is the same as the $SIEBEL_ROOT.
DATABASE_PLATFORM=CHANGE_ME Oracle.
DB_UNICODE_FLG=Unspecified For a database supporting Unicode, set the flag to Y.

Guarantees that database tables are correctly created,
using Unicode NVARCHAR, NCHAR, NTEXT, instead
of VCHAR, CHAR, and TEXT.
For a database that does not support Unicode, set the
flag to N.
DB_LANG=CHANGE_ME Names the language used by the database, such as enu for
U.S. English. See the install.ksh file for other valid
entries.
SIEBEL_HOME= c:\change_me\siebrvr Full path of the Siebel Server installation directory. This is
set to the SIEBEL_ROOT directory.

Running the Database Installation Script 15
This script will run for approximately 45 minutes. Before running the script, make
certain that you have edited the parameters in the install.ksh file according to
the instructions in the previous section, “Editing the Database Installation Script”
on page 15-11.
To run the install.ksh script under Windows NT

C:\sea6xx\dbsrvr\oracle directory. Double-click sh.exe. This will bring up
2 In the Korn shell window, type install.ksh and press ENTER to start the
install script.
The install.ksh script first prompts you to review the parameter settings.
If any are incorrect, type N and press ENTER to terminate the script and
modify the variables.
Otherwise, type Y and press ENTER to continue with the installation.
NOTE: When starting the Siebel Database Server installation or upgrade scripts,
be sure to type Y, and then press ENTER, once you have reviewed the parameters
at the beginning of the script. Pressing ENTER alone will cause the script to exit
The install.ksh script exits when it has completed.
4 Type exit and press ENTER to close the shell window.

To run the install.ksh script under UNIX

1 Make sure that you have set the parameters in the install.ksh file properly for
your system, according to the instructions in the previous section, “Editing the
2 Navigate to the siebsrvr home directory, and at the UNIX prompt type ksh and
press ENTER to invoke a Korn shell.
3 Enter . ./siebenv.sh.
4 Navigate to the siebsrvr home directory, and enter install.ksh to start the
install script.
The install.ksh script will prompt you to review the parameter settings.

be sure to enter Y after you have reviewed the parameters at the beginning of the
script. Pressing ENTER alone will cause the script to exit with a syntax error. If
this occurs, restart the script.
The install.ksh script will exit when it has completed.

Reviewing the Log Files 15
The Database installation script creates several log files in the Oracle directory. The
log files may include certain errors that are expected and benign. Compare any error
messages found in the log files to the sample error messages in the errors.rtf file,
which is located in the same directory. (If a log file is not listed in the errors.rtf
file, there are no acceptable error messages for that log file.) No further action is
required if the log files contain errors listed in the errors.rtf file.
errors.rtf file.
If you find errors that are not listed in the errors.rtf file, correct the condition that
caused the errors, and then re-run install.ksh to complete the installation.
Do not review error numbers alone since these may have changed following
Caution: Although other errors are rarely encountered, this review

is critical. Certain errors, such as a failure to create indexes, may
result in performance problems or anomalous behavior in Siebel

Finally, you must next execute the imprep.ksh script to load the Siebel repository
into the Siebel database. This utility loads a new Siebel repository containing the
version 6.x Siebel applications objects into the repository tables in the Database
Server.
only once.
To avoid certain types of errors after executing the imprep.ksh script, make sure
either to provide only one large rollback segment online in your Oracle database, or
to set the SIEBEL_ROLLBACK_SEG parameter in the siebenv.bat file.

Edit the imprep.ksh script using Windows Notepad or another text editor to set
the correct parameters for your installation before running the script. The repository
import script, named imprep.ksh, is located in the same database-specific
subdirectory as install.ksh. These parameters are defined at the top of the
imprep.ksh file, and are described in Table 15-2.
SRC_PSWD=SADMIN Password of the Siebel administrator.
SRC_TBLO=siebel The Siebel Database tableowner.

In Oracle, this is the account that will own the Siebel objects.

SiebSrvr_EnterpriseServerName. The default is CHANGE_ME and
must be modified or your installation will fail.
following:
Under Windows NT, navigate to the Control Panel and choose ODBC
Data Sources System DSN.
.odbc.ini.
DBSRVR_ROOT= Root directory of the Database Server installation. (Under UNIX, this will be
C:/CHANGE_ME/DBSRVR the same as the SIEBEL_ROOT directory.)
DBSRVR_ROOT=CHANGE_ME Under UNIX, this is the same as the $SIEBEL_ROOT.
DATABASE_PLATFORM= Oracle.
CHANGE_ME
DB_LANG=CHANGE_ME Names the language used by the database, such as enu for U.S. English. See
the install.ksh file for other valid entries.
SIEBEL_HOME=CHANGE_ME Full path of the Siebel Server installation directory. This is set to the
Running the Repository Import Script

The imprep.ksh script will run for approximately 20 minutes. Verify that you have
edited the parameters in the imprep.ksh file appropriately for your system.
To execute the imprep.ksh script under Windows NT

your system, according to instructions in the previous section, “Editing the

C:/sea6xx/dbsrvr/oracle directory. Double-click sh.exe. This will bring up

3 In the Korn shell window, enter . ./siebenv.sh to start the install script.
The imprep.ksh script prompts you to review the parameter settings.

be sure to enter Y after you have reviewed the parameters at the beginning of the
script. Pressing ENTER alone will cause the script to exit with a syntax error. If
this occurs, restart the script.

To execute the imprep.ksh script under UNIX

your system.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt enter ksh to
3 Enter . ./siebenv.sh.
Caution: Before sourcing siebenv.sh, make sure you have your

database environment set up correctly. Specifically, verify that
your database client library directory is in the LD_LIBRARY_PATH
environment variable. If you did not set up the database
environment property, you will receive an error message stating,
“An internal error with the Connector DLL has
occurred.”
4 Navigate to the dbsrvr directory, and at the UNIX prompt, enter

./imprep.ksh to start the repository import script.

6 Type exit and press ENTER to close the shell window.
NOTE: You may need to do this twice to close the shell window.

Reviewing the Log File

The imprep.ksh script creates the imprep.log file in the database platform
subdirectory that you must review for any errors. The log files may include certain
errors that are expected and benign. Compare any error messages found in the log
files to the sample error messages in the errors.rtf file, which is located in the
same directory. (If a log file is not listed in the errors.rtf file, there are no
acceptable error messages for that log file.) No further action is required if the log
files contain errors listed in the errors.rtf file.
errors.rtf file.
that caused the errors, and then re-run imprep.ksh to complete the installation.
Do not review error numbers alone since these may have changed following
Caution: Although other errors are rarely encountered, this review

is critical. Certain errors, such as a failure to create indexes, may
result in performance problems or anomalous behavior in Siebel

Perform the following task after you complete your installation of the Siebel
Database Server:
“Populating the Siebel File System”



Installing CORBA
Part 4
Chapter 16. Installing CORBA Under Windows NT
Chapter 17. Installing CORBA Under UNIX

Installing CORBA Under Windows NT 16

Verifying Siebel Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . 16-3
Configuring Database Connectivity Software . . . . . . . . . . . . . . . . . . 16-3

Setting Up the Object Request Broker in Persistent and Shared Server
Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10

Installing CORBA Under Windows NT
About This Chapter
This chapter describes the steps involved in installing and configuring the Siebel
CORBA Object Manager under Windows NT.
The Siebel CORBA Object Manager is an alternative object manager; it allows you
to access the Siebel BusObjects, through a supported CORBA ORB. The standard
Application Manager is installed automatically when you install your Siebel Servers.
The CORBA Object Manager is not installed as part of the standard Siebel Server
installation. If you plan to use the CORBA interfaces, you must install the CORBA
Object Manager on each application server on which you plan to operate it.
The CORBA Object Manager does not require the creation of a Siebel Enterprise
Server, or installation of a Gateway Server or Siebel Server. Rather, the CORBA
Object Manager operates outside the Siebel Server infrastructure. Task instantiation
and management, load balancing, and other capabilities that are usually provided
by the Siebel Enterprise Server infrastructure are instead provided by the CORBA
object request broker (ORB).
Connectivity between client applications and CORBA Object Manager is provided

by third-party ORB software. For information on the specific ORB products and
versions supported by Siebel eBusiness Applications, refer to Siebel System
Requirements and Supported Platforms. The CORBA Object Manager installation
provides support for all supported ORBs.

Perform the following tasks before running the Siebel CORBA Object Manager
installation programs:

“Configuring Database Connectivity Software”
Be sure that all application servers onto which the Siebel CORBA Object
Manager will be installed meet the hardware and software requirements
described in Siebel System Requirements and Supported Platforms.
The CORBA Object Manager may be installed on an application server that also
supports the Siebel Enterprise Server components, although for best
performance and scalability you must install the CORBA Object Manager onto a
dedicated application server.
You must configure your database connectivity software to connect to the Siebel
CORBA Object Manager:
Microsoft SQL Server. No configuration is required once the Microsoft SQL Server
ODBC driver specified in Siebel System Requirements and Supported Platforms
has been installed on each application server. Siebel automatically creates an
ODBC data source using connectivity parameters that you will specify during
installation of the Siebel Server.

Oracle. Verify that the Oracle SQL*Net database connectivity software is installed
onto each application server, according to the Oracle documentation. See Siebel
System Requirements and Supported Platforms for database connectivity
software requirements.
Prior to installing the Siebel Server and Siebel Enterprise Server, you must use
the Oracle SQL*Net Easy Configuration utility to define a database alias with the
proper connection information for your Siebel Database Server, if you have not
done so already. Record the connect string in Appendix A, “Deployment
Planning Worksheet.” You will specify this connect string when installing the
Siebel Server.
DB2 UDB for Windows NT, UNIX, and DB2 UDB for OS/390. Define a database alias
with the proper connection information for your database. This alias will be the
connect string used when installing the Siebel Server.
Processor to define your database alias. For more information, see the IBM DB2
Universal Database Quick Beginnings manual for NT or IBM DB2 Universal
Database Command Reference.

You must verify network connectivity between the application server and the Siebel
Database Server.
To verify network connectivity

1 Use the test utility for your network type to verify that the Siebel Servers can
access the database servers. For TCP/IP networks, you should use the ping
utility.

Microsoft SQL Server. Use the Control Panel - ODBC icon to verify that the
proper ODBC driver has been installed and to create and test a data source
for your database server.
DB2 UDB on Windows NT, UNIX, and OS/390. Use a DB2 Command Window to
make sure that you can connect to your database.
Choose Start Programs DB2 for Windows NT Command Window, and

type:
DB2 connect to database alias user user ID using password
where:
user ID = a valid user name on DB2

following:

Caution: Be sure to use the Command Window for this

procedure, and not the Command Line Processor window
that appears directly above it. The Command Line Processor
slightly different syntax. For this procedure, the commands
will not work in a Command Line Processor window; they
must be issued in a Command Window.
To close the connection, type db2 terminate.
NOTE: You can also use the DB2 Command Center GUI tool to do this.
The Siebel Server installation will create its own ODBC data source.

Installing the CORBA Object Manager
Installing the CORBA Object Manager 16
Complete the following steps to install the CORBA Object Manager on each
Windows NT application server.
To install the CORBA Object Manager under Windows NT

1 Start the CORBA Object Manager Installation Program:
a Insert the Siebel Windows Server Programs CD-ROM in the CD-ROM drive of
the application server (assumed in these instructions to be D:\).
b In Windows NT Explorer, navigate to the D:\corbaom directory and double-

click Setup.exe to start the CORBA Object Manager installation program.
The Welcome to CORBA Object Manager Setup screen appears.
2 Read the Welcome screen and click Next.

3 Select the setup type you want from the options in the Setup Type screen.
The options are:
Typical. This setup option will install all the CORBA Object Manager
components: these components are Siebel executable files, sample clients
and IDL, help files, and object configuration templates (the siebel.srf file).
This option is recommended for most installations.
Compact. This option is identical to the Typical Setup option for the CORBA
Object Manager installation.
Custom. This setup option allows you to customize your installation by

choosing only those components you want to install.
Review the destination directory (by default C:\sea6xx\corbaom) and, if

you need to change the default, navigate to the correct directory by using the
Browse button.
The Server Database screen appears.

4 Choose the database server you will be using, and then click Next.
The Database Identification screen appears.
5 Complete the Database Identification screen as follows, using the information

you recorded in Appendix A, “Deployment Planning Worksheet.”
IBM DB2 UDB for UNIX or Windows:
Database Alias. Type the database alias catalogued for your DB2 database.
tables and indexes.
DB2 UDB for OS/390:
Database Alias. Type the database alias cataloged for your DB2 UDB for
OS/390 database.
tables and indexes.
SQL ID. Type the SQL ID that defines your RACF (or other security control
product) group. This grants ordinary user privileges for most users. The
default is SSEROLE.
Oracle Enterprise Server:
Database Alias. Type the SQL*Net connect string for your Siebel Server
database.
Tableowner. Type the name of the database account that owns the Siebel
tables.
Microsoft SQL Server:
Server Name. Type the network name or IP address of the database server on
which you are installing the Siebel database.
Database Name. Type the name of the SQL Server database where the Siebel
tables and indexes will reside.
The Select Program Folder screen appears.

6 Type the name of the program folder that will contain your Siebel icons in the
Program Folder field, or choose from one of the displayed selections.
Siebel Systems recommends something similar to Siebel CORBA Object

Manager 6.x. Use spaces and the backslash (\) in folder names to create a folder
hierarchy.

The Setup Status screen appears, displaying a status bar that indicates the
progress of the installation.
When the installation is complete, the Event Log screen appears.
8 Review the results of the installation, and then click Next.

The Registry Log screen appears, showing the registry information the installer
used during CORBA installation.

10 To complete the installation, click Finish.

Before starting the CORBA Object Manager, perform the following tasks:
Make sure that your customized Siebel repository file (the .srf file) has been
copied from the location where you modified it to the \objects subdirectory of
each CORBA Object Manager installation.
Make sure that the supported ORB software you will use with the CORBA Object
Manager has been installed on each application server.
Set up the ORB to broker requests between clients and the CORBA Object
Manager, following instructions under “Setting Up the Object Request Broker in
Persistent and Shared Server Modes” on page 16-10. For more information on
the ORB environment, refer to the documentation for the ORB product you are
using.
Follow the instructions under “Registering Multiple Object Managers for Better
Performance” on page 16-14 (optional).
Setting Up the Object Request Broker in Persistent and Shared Server

Modes 16
You must set up the Object Request Broker (ORB) to broker requests between clients
and the CORBA Object Manager. How you do this depends on which ORB product
you are using and how you want the system to operate. Two scenarios are described
in this section: setting up an ORB in persistent mode and setting up an ORB in
shared-server mode.
Persistent Mode
In persistent mode, the CORBA Object Manager is always running and available for
the ORB. You must set up either the Visibroker ORB or the Orbix ORB for persistent
mode, but not both. Choose the correct set of procedures for your deployment from
the following.

To set up the Visibroker ORB in persistent mode

1 Choose the Visibroker Osagent icon from the Windows Start menu to start the
Osagent process.
This process needs to be running on at least one application server; however, it

provides resiliency if started on multiple servers.

2 To start the CORBA Object Manager from the Windows Start menu, choose
Programs Siebel CORBA Object Manager 6.x Visibroker ORB.
If you cannot find the CORBA Object Manager in your Windows Start menu,
look for ssomvisi.exe in the bin subdirectory of the CORBA Object Manager
installation. You can open the My Computer window or Windows NT Explorer,
navigate to this directory, and double-click the program to run the CORBA Object
Manager.
To set up the Orbix ORB in persistent mode

1 Start the Orbix program on each of the application servers that will be running
the CORBA Object Manager, using the orbixd.exe command.
Refer to the documentation provided with your Orbix software for more
information on the orbixd command.
2 Before starting the CORBA Object Manager for the first time on an application
server, register it with the Orbix daemon by executing the following command
from a Windows NT Command Prompt window:
putit SiebelCorbaServer -persistent
The putit program is located in the bin directory of your Orbix installation.

3 To start the CORBA Object Manager, from the Windows Start menu, choose
Programs Siebel CORBA Object Manager 6.x Orbix ORB.
The CORBA Object Manager executable (ssomorbx.exe) is located in the bin

directory of the CORBA Object Manager installation. It can also be invoked from
a Command Prompt window using the command-line arguments found on the
shortcut tab of the icon.

Shared Server Mode

In shared server mode, the ORB manages the CORBA Object Manager executable,
starting it automatically as needed. In this mode, you need register only the CORBA
Object Manager program with the ORB.
To set up the Visibroker ORB in shared server mode

1 From the Windows Start menu, choose the Visibroker Osagent icon to start the
osagent.exe program on the application server.
This process needs to be running on only one application server; however, it

provides resiliency if started on multiple servers.
2 Start an object activation daemon (OAD) on each application server that will be
running the CORBA Object Manager.
The term daemon is borrowed from UNIX and denotes here a program that runs
in the background without user intervention.
The Visibroker oadutil.exe program is located in the bin directory of your

Visibroker installation. Under Windows NT, execute the following command
from a command window on each application server:
oadutil reg -i SiebelAppFactory -o SiebelObjectFactory -cpp

SIEBEL_ROOT\bin\ssomvisi.exe -p shared -a /n -a
SiebelObjectFactory -a /c -a config_file -a /d -a datasource
-a /l -a language
where:
SIEBEL_ROOT = the full path of your SIEBEL_ROOT (or Siebel CORBA Object
Manager) directory.
config_file = the full path and name of the Object Manager configuration
file; the default is siebel.cfg, located in the same directory as ssomvisi.
datasource = the name of the Data Source defined in the .cfg file; the default
is Server. Make sure that the .cfg file includes a section that defines that data
source, and that it lists that data source in the [DataSources] section of the
.cfg.
language = the three-letter code for the language in which to operate: enu for
U.S. English.

To set up the Orbix ORB in shared server mode

1 Start the Orbix daemon on each of the application servers that will be running
the CORBA Object Manager, using the orbixd.exe command.
The term daemon is borrowed from UNIX and denotes here a program that runs
in the background without user intervention. Refer to the documentation
provided with your Orbix software for more information on the orbixd.exe
command.
2 Execute the following command from a command window once on each

application server to register the CORBA Object Manager.
putit SiebelCorbaServer -shared SIEBEL_ROOT\bin\ssomorbx.exe
“/n SiebelCorbaServer /c config_file /d datasource /l language”
where:
Manager) directory.
is Server.
U.S. English.
The putit executable is located in the bin directory of your Orbix installation.
This completes configuration and installation of the Siebel CORBA Object Manager
under Windows NT.

Registering Multiple Object Managers for Better Performance 16
To improve system performance, Siebel Systems recommends registering multiple

CORBA Object Managers on the same host. When registering multiple CORBA
Object Managers, you must use a unique name for each instance.
Persistent Mode
Users should note that Visibroker does not use the Visibroker Activation Daemon
(OAD) in persistent mode.
To register multiple object managers, using Visibroker ORB

Osagent process.
2 Execute the following command for multiple instances of the CORBA Object
Manager:
SIEBEL_ROOT\bin\ssomvisi.exe /n SiebelObjectFactory
/c config_file /d datasource /l language
where:
is Server.
language = the three-letter code for the language in which to operate, such as
enu for U.S. English.

To register multiple object managers, using Orbix ORB

1 Follow Step 1 on page 16-11 for setting up Orbix ORB in persistent mode.
2 Follow Step 2 on page 16-11, but enter the following commands, varying the
name of each instance as shown in the examples below:
putit -persistent SiebelCorbaServer
putit -persistent SiebelCorbaServer2
On the command prompt, enter the following commands:
ssomorbx.exe /n SiebelCorbaServer
/c SIEBEL_ROOT\bin\config_file/d Server /l language
ssomorbx.exe /n SiebelCorbaServer2
/c SIEBEL_ROOT\bin\config_file /d Server /l language
where:
SIEBEL_ROOT=the full path of your SIEBEL_ROOT or Siebel CORBA Object

Manager directory.
config_file =the full path and name of the Object Manager configuration file;
the default is siebel.cfg, located in the same directory as ssomorbx.exe.
language =the three-letter code for the language in which to operate, such as

Shared Server Mode

Osagent process.
2 Start an OAD on each application server that will run the CORBA Object
Manager.
3 Register multiple instances of the CORBA Object Manager, as desired; for

example:
oadutil reg -i SiebelAppFactory -o NAME -cpp SIEBEL_ROOT/bin/
ssomvisi -p shared -a /n -a NAME -a /c -a SIEBEL_ROOT/bin/
config_file -a /d -a datasource -a /l -a language
where:
NAME=a unique name for each registration of the Object Manager.
SIEBEL_ROOT=the full path of your SIEBEL_ROOT or Siebel CORBA Object

Manager directory.
config_file =the full path and name of the Object Manager configuration file;
the default is siebel.cfg, located in the same directory as ssomorbx.exe.
datasource =the name of the Data Source defined in the .cfg file; the default
is Server.
language =the three-letter code for the language in which to operate, such as


Follow Step 2 on page 16-11, but enter the following command, varying the
name of each instance as shown in the examples below:
putit NAME SIEBEL_ROOT\bin\ssomorbx.exe /n NAME /c
SIEBEL_ROOT\bin\config_file /d Server /l language
where:
NAME is unique for each registered instance.
SIEBEL_ROOT = the full path of your SIEBEL_ROOT or Siebel CORBA Object

Manager directory.
file; the default is siebel.cfg, located in the same directory as ssomorbx.exe.


Installing CORBA Under UNIX 17

Verifying Siebel Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . 17-3
Configuring Database Connectivity Software . . . . . . . . . . . . . . . . . . 17-4
Verifying Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-4
Managing Siebel Environment Variables . . . . . . . . . . . . . . . . . . . . . . 17-10


Installing CORBA Under UNIX
About This Chapter
This chapter describes the steps involved in installing and configuring the Siebel
CORBA Object Manager under UNIX.
The Siebel CORBA Object Manager is an alternative object manager; it allows you
to access objects in your Siebel applications using the industry-standard CORBA
procedures. The standard Application Object Manager is installed automatically
when you install your Siebel Servers.
The CORBA Object Manager is not installed as part of the standard Siebel Server
installation. If you plan to access your Siebel Servers through CORBA, you must
install the CORBA Object Manager on each application server on which you plan to
operate it.
The CORBA Object Manager does not require that you create a Siebel Enterprise
Server, or install a Gateway Server or Siebel Server. The CORBA Object Manager
operates outside the Siebel Server infrastructure, with task instantiation and
management, load balancing, and other capabilities that are usually provided by the
Siebel Enterprise Server infrastructure instead being provided by the CORBA object
request broker (ORB).
Connectivity between the client and CORBA Object Manager is provided by third-
party ORB software. Refer to Siebel System Requirements and Supported Platforms
for information on the specific ORB products and versions supported by Siebel
eBusiness Applications. The CORBA Object Manager installation provides support
for all supported ORBs.

Perform the following tasks before running the Siebel CORBA Object Manager
installation programs:

“Configuring Database Connectivity Software” on page 17-4
Be sure that all application servers onto which the Siebel CORBA Object
Manager will be installed meet the hardware and software requirements detailed
in Siebel System Requirements and Supported Platforms.
The CORBA Object Manager may be installed on an application server that also
supports the Siebel Enterprise Server components, although for best
performance and scalability you must install the CORBA Object Manager onto a
dedicated application server.
The CORBA Object Manager installation program uses /siebel as the default
installation directory on supported UNIX platforms. Whether you are installing
CORBA Object Manager into a pre-existing installation directory or performing a
fresh installation, make sure that you do not install CORBA into the same
directory as the Siebel Server.
NOTE: Siebel Systems recommends that you use a directory naming convention
that identifies the component and version being installed.
To install the CORBA Object Manager in a separate directory, make sure that the
environment variable SIEBEL_ROOT either is not set or is set to the new
directory.

Oracle. Verify that the Oracle SQL*Net database connectivity software is installed
onto each application server, according to the Oracle documentation. See the Siebel
System Requirements and Supported Platforms for database connectivity software
requirements.
Prior to installing the Siebel Server and Siebel Enterprise Server, you must use the
Oracle SQL*Net Easy Configuration utility to define a database alias with the proper
connection information for your Siebel Database Server, if you have not done so
already. Record the connect string in Appendix A, “Deployment Planning
DB2 UDB for Windows NT, UNIX, and DB2 UDB for OS/390. Define a database alias with
the proper connection information for your database. This alias will be the connect
string used when you are installing the Siebel Server.
Use the DB2 Command Line Processor (CLP) to define your database alias. For more
information, see the IBM DB2 Universal Database Command Reference.
You must verify network connectivity between the Siebel Server and the Siebel
Database Server.
To verify network connectivity

1 Verify network connectivity to the Database Servers from the application
servers, using the test utility for your network type.
For TCP/IP networks, use the ping utility to verify network connectivity to the
Database and Gateway servers.

2 Verify connectivity to the Database server:

Oracle. Use the tnsping utility and SQL*Net database alias from a
Command Prompt window to make sure that you can connect to the
database, using the network connect string that you defined in the previous
step.
DB2 UDB for Windows NT, UNIX, and DB2 UDB for OS/390. Use the Command
Line Processor (CLP) to make sure that you can connect to your database.
From the CLP, open a UNIX shell and enter:
DB2 connect to database alias user user ID using password
where:
user ID =a valid user name on DB2.
following:

3 To close the connection, enter db2 terminate.
NOTE: The Siebel Server installation will create its own data source.

Installing the CORBA Object Manager 17
To complete the installation, you need to respond to a series of prompts generated

by the script you just installed. The Siebel server installation script will prompt you
for values that it needs to complete the installation. The script uses two different
styles of prompts:
First prompt type. This type of prompt asks you to type the desired value for a
given parameter; the default value is shown in square brackets [ ].
For example,

installed [/siebel]
To change the default value, enter the desired value.
Second prompt type. This type of prompt displays a list of one or more parameter
values and asks you whether you want to modify any of them:
example:
[X] Siebel CORBA Object Manager Executables

[ ] CORBA Client Sample Code

N to change) [Y]
Complete the following steps to install the CORBA Object Manager on each UNIX
application server, using the information you recorded in your copy of Appendix A,

To install the CORBA Object Manager

application server and mount it, if required by your UNIX configuration.
2 Log in to the application server using the Siebel service owner account and enter
./ksh to run a Korn shell.

This guarantees that the permissions mask for your installation shell is set
appropriately.

incorrectly on your CORBA installation files; this will require you
to reset them properly before continuing with the installation.

/seaunix6xx/operating_system/corbaom/install
where:
5 Enter ./bin/install_corbaom to start the Siebel CORBA Object Manager

The first prompt will ask for the directory in which the CORBA Object Manager
should be installed.
6 Enter the full path of the directory.

7 If you are creating a new installation directory, the next prompt will ask you to
confirm that this directory should be created:
If the directory is correct, press ENTER to accept the default value of Y and
continue with the installation.
If the directory is incorrect, enter N to change it.
The next prompt lists the packages available for selection, as shown below:
[X] Siebel CORBA Object Manager

[X] CORBA Client Sample Code
Both packages that you must install are selected by default.
After you have confirmed the packages to install, the Siebel CORBA Object Manager
installation script will install the files on disk. It will then bring up a series of
prompts, as detailed below, to allow you to configure the CORBA Object Manager.
Answer the prompts, using the information you recorded in Appendix A,
To configure the CORBA Object Manager

1 When prompted, select your database from the list of available options and press
ENTER.
2 Enter the appropriate connect string or database alias used to connect to your
RDBMS:
IBM DB2 UDB for UNIX or Windows. Enter the database alias for your Siebel
Server Database, for example, db2345.
DB2 UDB for OS/390. Enter the database alias cataloged for your DB2 UDB for
OS/390 database, for example, db2390.
Oracle. Enter the SQL*Net connect string for your Siebel Server Database.

3 Enter the Siebel tableowner or database owner account:

IBM DB2 UDB for UNIX or Windows. Enter the name of the database account
that owns the Siebel tables.
DB2 UDB for OS/390. Enter the name of the database account that owns your
Siebel tables and indexes.
Oracle. Enter the name of the database account that owns the Siebel tables.
If your database is DB2 for OS/390, proceed to Step 4. For all others, proceed to
Step 5.
4 Enter the SQL ID that defines your RACF (or other security control product)
group. This grants ordinary user privileges for most users. The default is
SSEROLE.
5 Enter the Siebel administrator’s account.

The Siebel Server uses this account to connect to the Database Server.
You will next be prompted to review all the parameters set in the previous steps.
6 Review these settings carefully:

If the settings are correct, enter Y to proceed with the installation.
If any are incorrect, enter N to return to the previous prompts so that you can
re-enter the information.
The CORBA Object Manager will exit after the installation has finished.

Managing Siebel Environment Variables
Managing Siebel Environment Variables 17
For convenience, when managing and configuring the Siebel CORBA Object
Manager, you may want to set the Siebel environment variable SIEBEL_ROOT and
add the SIEBEL_ROOT/bin directory to your search path.
During installation of the CORBA Object Manager, the script files siebenv.csh (for
C shells) and siebenv.sh (for Bourne and Korn shells) are automatically created
in the SIEBEL_ROOT directory. When executed, these shell scripts set the
environment variables.
You may also want to add a call to the appropriate script to the logon file of all Siebel
administrator UNIX accounts, so that these variables are set automatically
whenever a Siebel administrator logs on.
Before starting the CORBA Object Manager, perform the following tasks:
Make sure that your customized Siebel repository file (the .srf file) has been
copied to the \objects subdirectory of each CORBA Object Manager
installation.
Make sure that the supported ORB software you will use with the Object
Manager has been installed on each application server.
Set up the ORB to broker requests between clients and the CORBA Object
Manager, following instructions under “Setting Up the Object Request Broker in
Persistent and Shared Server Modes” on page 17-11. For more information on
the ORB environment, refer to the documentation for the ORB product you are
using.
Follow the instructions under “Registering Multiple Object Managers for Better
Performance” on page 17-17 (optional).

Setting Up the Object Request Broker in Persistent and Shared

Server Modes 17
You must set up the object request broker (ORB) to broker requests between clients
and the CORBA Object Manager. How you do this depends on which ORB product
you are using and how you want the system to operate.
Two scenarios are described in this section: setting up an ORB in persistent mode
and setting up an ORB in shared-server mode.
Persistent Mode
In persistent mode, the CORBA Object Manager is always running and available for
the ORB.
To set up CORBA using the Visibroker ORB

1 Edit your UNIX path statement and include the following:
visibroker_installation_location/bin
If you are using csh, add this:
set PATH = ${PATH}:visibroker_installdir/bin
If you are using ksh, add this:
PATH=${PATH}:visibroker_installdir/bin
export PATH
2 Start the osagent daemon process from a shell program.

The osagent daemon is located in the bin subdirectory of your Visibroker
installation.

3 Execute the ssomvisi program using the following arguments to start the
ssomvisi /n SiebelObjectFactory /c config_file /d datasource /l language
where:
config_file is the full path and name of the Object Manager configuration
datasource = the name of the Data Source defined in the .cfg file; the
default is Server. Make sure that the .cfg file includes a section that defines
that data source, and that it lists that data source in the [DataSources]
section of the .cfg.
language =the three-letter code for the language in which to operate, for
example enu for U.S. English.
NOTE: The ssomvisi program is located in the bin subdirectory of your Siebel
CORBA Object Manager installation. You can invoke it by specifying the full path
(for example, SIEBEL_ROOT/bin/ssomvisi); however, setting the Siebel
environment variables automatically adds this directory to your search path so
that you do not need to specify the full path.
If you get the following error:
ld.so.1: ssomvisi: fatal: liborb_r.so: open failed:

No such file or directory Killed
check the following:
Is the osagent daemon down?
Is the LD_LIBRARY_PATH environment variable defined correctly?
Make sure visibroker_installdir/lib and Siebel_Server/lib are

included in LD_LIBRARY_PATH.

Are any Visibroker ORB system requirements missing?
For example, the Visibroker ORB system requires that a C++ compiler on
its approved list be installed. If you have no C++ compiler, or an
unapproved C++ compiler, Visibroker will quit with an error message.
Refer to the Visibroker documentation for Visibroker installation

requirements.
Are you using a certified version of the Visibroker ORB for Siebel eBusiness
Applications version 6.x?
Refer to Siebel System Requirements and Supported Platforms for certified

Visibroker software versions.
To set up CORBA using the Orbix ORB

the CORBA Object Manager, using the orbixd command.
A daemon is a program that runs in the background automatically, without user

intervention. Refer to the documentation provided with your Orbix software for
more information on the orbixd command.
2 Before starting the CORBA Object Manager for the first time on an application
server, execute the following command from a UNIX Korn shell to register the
CORBA Object Manager with the Orbix ORB:
putit SiebelCorbaServer -persistent
The putit executable is located in the bin directory of your Orbix installation.
3 Execute the ssomorbx program using the following arguments to start the
ssomorbx /n SiebelCorbaServer /c config_file /d datasource /l language
where:
file; the default is siebel.cfg, located in the same directory as ssomorbx.
datasource = the name of the data source defined in the .cfg file; the
default is Server.

language = the three-letter code for the language in which to operate: enu
for U.S. English.
NOTE: The ssomorbx program is located in the bin subdirectory of your Siebel
CORBA Object Manager installation. You can invoke it by specifying the full path
(for example, SIEBEL_ROOT/bin/ssomorbx); however, setting the Siebel
environment variables automatically adds the bin directory to your search path
so that you do not need to specify the full path.
Shared Server Mode

In shared server mode, the ORB manages the CORBA Object Manager executable,
starting it automatically as needed. In this mode, you need only register the CORBA
Object Manager with the ORB.
Execute the following commands on each application server that will be running
the CORBA Object Manager to start an object activation daemon (OAD).
To set up CORBA in shared server mode with the Visibroker ORB

1 Open a terminal window and enter ksh to run a Korn shell.
2 Start an object activation daemon (OAD) on each application server that will be
running the CORBA Object Manager.
The Visibroker oad program is located in the bin directory of your Visibroker
installation.
No parameters are needed for running oad—just enter oad at the command
prompt and press ENTER. However, you need to define either the environment
variable VBROKER_ADM or the environment variable VBROKER_IMPL_PATH before
executing oad. VBROKER_ADM defines the path to the directory where the files in
the implementation repository are stored. The default is
visibroker_installation_dir/impl_dir. Use VBROKER_IMPL_PATH to
overwrite the default VBROKER_ADM path.

Refer to the documentation of the ORB product you are using for more
information on VBROKER_ADM and VBROKER_IMPL_PATH.
NOTE: Make sure the oad program is already started successfully before running
the oadutil utility. If it is not, the oadutil utility will quit with the following
error message:
oadutil reg: Failed to bind to OAD
3 Navigate to the bin subdirectory of your Visibroker installation and run the
osagent program.
NOTE: This process does not need to be running on only one application server.
However, it provides resiliency if started on more than one server.
4 To register an object, execute the Visibroker oadutil reg command from a shell
window on each application server, as follows:
oadutil reg -i SiebelAppFactory -o SiebelObjectFactory -cpp\
SIEBEL_ROOT/bin/ssomvisi -p shared -a /n -a SiebelObjectFactory\
-a /c -a SIEBEL_ROOT/bin/config_file -a /d -a datasource -a /l -a language
where:
Manager) directory.
datasource = the name of the data source defined in the .cfg file; the default
is Server.
U.S. English.
NOTE: Enter this command on a single command line.
The oadutil command is located in the bin directory of your Visibroker

installation.

5 To manually unregister an object that has been previously registered, execute the
oadutil unreg command from a shell window on each application server, as
follows:
oadutil unreg -i SiebelAppFactory -o SiebelObjectFactory
NOTE: Enter this command on a single command line.
To set up CORBA in shared server mode with the Orbix ORB

the CORBA Object Manager, using the orbixd command.
Refer to the documentation provided with your Orbix software for more
information on the orbixd command.
2 Execute the following command once on each application server to register the
CORBA Object Manager. The putit program is located in the bin directory of
your Orbix installation, and should be run from a Korn shell window.
putit SiebelCorbaServer -shared SIEBEL_ROOT/bin/ssomorbx “/n SiebelCorbaServer\
/c config_file /d datasource /l language”
where:
Manager) directory.
is Server.
3 To manually unregister an object that has been registered previously, execute the
rmit command from a shell window on each application server as follows:
rmit SiebelCorbaServer

Registering Multiple Object Managers for Better Performance 17

Persistent Mode
1 Follow Step 1 through Step 2 on page 17-11.
2 Execute the ssomvisi program using the following arguments to start the
CORBA Object Manager, for example:
ssomvisi /n SiebelObjectFactory/c config_file /d datasource /l language
Optionally, you can also make the configuration files unique and point them to
distinct Siebel Repository files (.srf); for example:
ssomvisi /n SiebelObjectFactory/c config_file _2 /d datasource /l language
where:
is Server.

1 Follow Step 1 and Step 2 on page 17-13. However, in Step 2, give the variable
SiebelCorbaServer a unique name for each instance, such as
SiebelCorbaServer2 or SiebelCorbaServer3 .
2 Follow Step 3 on page 17-13, but again give the variable SiebelCorbaServer
the unique name you gave this instance in the previous step, for example,
SiebelCorbaServer2.

Shared Server Mode


1 Follow Step 1 through Step 3 on page 17-15.
2 Follow Step 4, but give the first argument a unique name for every instance you
register; for example:
SIEBEL_ROOT/bin/ssomvisi -p shared -a /n -a SiebelObjectFactory\
and
SIEBEL_ROOT/bin/ssomvisi -p shared -a /n -a SiebelObjectFactory1\
Optionally, you can also make the configuration files unique and point them to
distinct Siebel Repository files (.srf); for example:
-a /c -a SIEBEL_ROOT/bin/config_file _2 -a /d -a datasource -a /l -a language

Follow Step 1 and Step 2 on page 17-16. However, in Step 2, give the variable
SiebelCorbaServer a unique name for every instance you register, such as
SiebelCorbaServer2 or SiebelCorbaServer3.

Installing and Configuring
Siebel Thin Clients Part 5
Chapter 18. Thin Client Network Requirements
Chapter 19. Editing Siebel Thin Client for Windows Files
Chapter 20. Installing and Configuring the .COM Applications Under Windows NT
Chapter 21. Installing and Configuring the .COM Applications Under UNIX

Thin Client Network Requirements 18
Accessing Siebel Thin Clients From Outside a Firewall . . . . . . . . . . . . . 18-2

Firewall Requirements in a Load-Balanced Environment . . . . . . . . . 18-2
Firewall Requirements in a Non-Load-Balanced Environment . . . . . . 18-3
Accessing HTML Thin Clients from Outside a Firewall . . . . . . . . . . . . . 18-4

HTML Thin Client Firewall Configuration . . . . . . . . . . . . . . . . . . . . 18-5
Browser to Web Server Connection . . . . . . . . . . . . . . . . . . . . . . . . 18-6
Web Server Extension to Application Object Manager Connection . . . . . . .18-7
Firewall Requirements in a Load-Balanced Environment . . . . . . . . . 18-7
Firewall Requirements in a Non-Load-Balanced Environment . . . . . . 18-8

Thin Client Network Requirements
About This Chapter
This chapter describes the network configuration requirements for deploying Siebel
Java Thin Client, Siebel Thin Client for Windows, and Siebel HTML Thin Client,
particularly when deploying these products across firewalls.
Accessing Siebel Thin Clients From Outside a Firewall 18
One of the key advantages of deploying Siebel Thin Client for Windows and Siebel
Java Thin Client is that it allows users to connect to Siebel eBusiness Applications
remotely. However, enabling thin clients to connect to Siebel Servers over the
Internet and through a firewall requires specific client/server, firewall, and network
configurations described in this section.
Firewall Requirements in a Load-Balanced Environment 18
If you are using Resonate Central Dispatch to dynamically load-balance connections

across the Enterprise Server, you only need to expose one port through the firewall.
Siebel Thin Clients use this port to connect to the Siebel Gateway Server, which
forwards the connection to the Application Object Manager within the Siebel Server.
In a load-balanced environment, the Application Object Manager supports both
TCP/IP and tunneled HTTP network connections.
TCP/IP. If you are using TCP/IP, you must expose the TCP port (the default port
number is 2320) of the Gateway Server through the firewall.
HTTP. If you are using HTTP, you need only expose a generic HTTP port (the
default HTTP port number is 80).
Both HTTP and TCP/IP connections to the Application Object Manager support
firewalls that perform network address translation (NAT).
NOTE: Siebel eBusiness Applications supports NAT only if Central Dispatch has been
installed for load balancing.

Accessing Siebel Thin Clients From Outside a Firewall
However, neither networking protocol is supported when a firewall uses a

multiplexing application proxy. While the use of HTTP does create some overhead
and can degrade response times, you may prefer it for firewall configurations
requiring packet filtering or other stringent security measures.
The Application Object Manager communications protocol is set as part of the

definition of each Object Manager-defined component. As multiple defined
components can operate in the Enterprise Server, it is possible to use a mix of HTTP
and TCP/IP communications in your deployment; however, each Object Manager
can use only a single protocol, and the start-up file for a thin client can only specify
one Application Object Manager-defined component. See the Siebel Server
Administration Guide for instructions on configuring the communication protocol
for Application Object Manager.
NOTE: See the Siebel Client Installation and Administration Guide for information
about configuring Java Thin Client. The stand-alone Thin Client for Windows does
not require configuration.
Firewall Requirements in a Non-Load-Balanced Environment 18
The firewall requirements are slightly different if you do not use load balancing in
your Enterprise Server network. In this environment, the Application Object
Manager only supports connections over TCP/IP. Both the Gateway Server TCP port
(default is 2320) and the TCP port on which each Object Manager listens must be
exposed through the firewall. The Object Manager port is determined by the Object
Manager configuration and can be allocated dynamically or statically.
To minimize the number of ports you must open through the firewall, Siebel
Systems recommends that you use static port allocation, and create as small a
number of Object Manager-defined components as possible.
NOTE: In the non-load-balanced environment, the Object Manager connection does

not support network address translation, and does not support firewalls with
multiplexing proxy servers.

Accessing HTML Thin Clients from Outside a Firewall
Accessing HTML Thin Clients from Outside a Firewall 18
One of the key advantages of deploying Siebel HTML Thin Clients is that it allows
users to connect to Siebel eBusiness Applications remotely. However, enabling
Siebel HTML Thin Clients to connect to Siebel Servers over the Internet and through
a firewall requires specific client/server, firewall, and network configurations
described in this section.

HTML Thin Client Firewall Configuration 18
Figure 18-1 shows one possible network configuration for deploying Siebel HTML
Thin Client. Your actual configuration will vary depending on the firewall hardware
or software and security standards of your organization; however, the requirements
outlined here apply across all configurations and should be used as the guidelines
for your environment.
Web browser
Web application
(generated HTML pages)
External firewall
HTTP port
Web server
Siebel Web
Server Extension
Internal firewall
TCP/IP port
Siebel Siebel Web Engine Templates

application
definition Siebel Object
(.srf) Manager
A shaded box
denotes an
Database HTML Thin Client
component
Figure 18-1. Two Firewalls to Protect Data on the Servers

Two distinct network connections exist in an HTML Thin Client deployment:
The Web browser connection to the Web server.

Siebel Web Server Extension connection to the Application Object Manager
component, running within the Siebel Server.
Each of these connections has unique configuration requirements, particularly in

regard to firewalls. Each is discussed separately.
Browser to Web Server Connection 18
The Web browser uses a standard HTTP or SSL connection to the Web server.
Typically, this connection requires only that the firewall be able to pass HTTP or SSL
traffic to a single port on the Web server. These requirements are determined
entirely by your browser and Web server configurations. For more information on
supported firewall configurations in these environments, refer to the documentation
provided by the vendors of the products your enterprise uses.
These connections can usually be supported over VPNs, through firewalls that
perform network address translation, and through multiplexing proxies.
NOTE: The use of SSL does impose some overhead that can degrade performance.
For that reason, Siebel Systems recommends its use only in those portions of your
application configuration where network security is critical, such as transfers
involving login information.

Web Server Extension to Application Object Manager Connection 18
The Siebel Web Server Extension, operating on the Web server, connects to the
Application Object Manager component operating within the Siebel Server. This
connection uses Siebel's application protocol, which can be compressed and can
also be encrypted when both components are deployed on Windows NT.
The supported configurations for a firewall between the Web server and Siebel
Enterprise Server vary depending on whether you are using dynamic load balancing
in the Enterprise Server.
Firewall Requirements in a Load-Balanced Environment 18
NOTE: Siebel Systems supports network address translation (NAT) with Resonate
Central Dispatch installed. If Resonate Central Dispatch is not installed, network
address translation (NAT) is not supported.
If you are using Resonate Central Dispatch to dynamically load-balance connections

across the Enterprise Server, you need to expose only a single port through the
firewall. The Web Server Extension uses this port to connect to the Siebel Gateway
Server, which in turn passes the connection to the Application Object Manager. In
the load-balanced environment, the Application Object Manager can be configured
to support connections over TCP/IP and tunneled HTTP. If you are using TCP/IP,
you must expose the TCP port of the Gateway Server (the default is 2320) through
the firewall. If you are using HTTP, you need to expose only a generic HTTP port
(the default is 80).
If you are using load balancing, both HTTP and TCP/IP connections to the
Application Object Manager support firewalls that perform network address
translation. However, neither can be used with a firewall that has a multiplexing
application proxy. While the use of HTTP does create some overhead and can
degrade response times, you may prefer it for firewall configurations requiring
packet filtering or other stringent security measures.

The Applications Object Manager communications protocol is set as part of the

definition of each Application Object Manager-defined component. Because
multiple defined components can operate in the Siebel Server, a mix of HTTP and
TCP/IP communications can be used in your deployment. However, each individual
Application Object Manager can use only a single protocol, and each Web Server
Extension can only connect to a single defined component. For instructions on
configuring the communication protocol for the Application Object Manager, see
the Siebel Server Administration Guide.
NOTE: See Chapter 20, “Installing and Configuring the .COM Applications
Under Windows NT” or Chapter 21, “Installing and Configuring the
.COM Applications Under UNIX” for information on how to modify the
configuration files for Siebel .COM Applications.
Firewall Requirements in a Non-Load-Balanced Environment 18
The firewall requirements are slightly different if you do not use load balancing in
your Enterprise Server. The Object Manager connection can only use TCP/IP in this
environment. In addition to the Gateway Server TCP port (the default is 2320), the
TCP port on which each Object Manager listens must also be exposed through the
firewall.
The Object Manager port is determined by the Object Manager configuration and
can be allocated dynamically or statically. To minimize the number of ports that
must be opened through the firewall, it is recommended that you use static port
allocation and create as small a number of Object Manager-defined components as
possible.
NOTE: In the non-load-balanced environment, the Object Manager connection

supports neither NAT nor firewalls with multiplexing proxy servers.

Editing Siebel Thin Client for Windows Files 19
About Siebel Thin Client for Windows . . . . . . . . . . . . . . . . . . . . . . . . 19-2

Browser Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2
Stand-Alone Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2

Verifying the Siebel Enterprise Server . . . . . . . . . . . . . . . . . . . . . . 19-3
Editing the Browser-Mode Startup Files . . . . . . . . . . . . . . . . . . . . . . . 19-4

Internet Explorer Client Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-5
Netscape Communicator Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-9
Sharing Thin Client Startup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-10

Editing Siebel Thin Client for Windows Files
About This Chapter
This chapter describes the steps involved in verifying and, if required by your
deployment, editing the Siebel Thin Client for Windows files installed with and
configured by the Siebel Server.
For instructions on installing the client-side components of Siebel Thin Client for
Windows, or other Siebel Thin Clients, see the Siebel Client Installation and
About Siebel Thin Client for Windows 19
Siebel Thin Client for Windows consists of client-side software that runs in one of
two modes:
In a Microsoft Internet Explorer or Netscape Communicator Web browser

(browser mode)
As a stand-alone application (stand-alone mode)

In each mode, Siebel Thin Client for Windows connects to a Siebel Application
Object Manager that runs in the Siebel Enterprise Server. For information about
supported versions of these Web browsers and other platform requirements, see
Browser Mode 19
When run in this mode, Siebel Thin Client for Windows uses a startup file typically
accessed from a file or Web server to control its operation. This startup file sets a
number of operational parameters, including default appearance, connectivity, and
authorization information.
This chapter provides instructions on editing the Siebel Thin Client for Windows
Startup file, should your environment require this.
Stand-Alone Mode 19
There are no configuration tasks for the stand-alone executable version of Thin
Client for Windows. If your clients will use the stand-alone version, this completes
the information for Siebel Thin Client for Windows.

Complete the following pre-installation tasks on the appropriate servers before you
install and perform any reconfiguration of Siebel Thin Client for Windows required
by your deployment. These tasks consist of the following:
“Verifying the Siebel Enterprise Server”

“Editing the Browser-Mode Startup Files” on page 19-4
Verifying the Siebel Enterprise Server 19
Before installing the Thin Client software, you must have completed the installation
of the following:
An Enterprise Server containing the Gateway Server and at least one Siebel
Server, following the instructions provided in this guide

Siebel File System
You must also have configured and started at least one Application Object Manager-
defined component in the Siebel Enterprise Server.
NOTE: Siebel Systems strongly recommends that you implement the connection-
brokering capabilities of Resonate’s Central Dispatch if you will support Thin
Clients from multiple Siebel Servers. These capabilities help to guarantee high
scalability and availability for your Thin Client users. Refer to Chapter 3, “Installing
Central Dispatch Under Windows NT,” for more information on connection
brokering.

Editing the Browser-Mode Startup Files
Editing the Browser-Mode Startup Files 19
This section describes how to edit the startup files that control Siebel Thin Client
for Windows operation.
These startup files are initially installed with the Siebel Enterprise Server. After you
have edited these files, you will make them available to Siebel Thin Client for
Windows users by one or more of the methods described in “Sharing Thin Client
Startup Files” on page 19-10.
Siebel Thin Client for Windows uses one of two startup files, also called tclient
files, depending on the Web browser in which Siebel Thin Client for Windows is
executed:
The tclient.htm file is used to start Thin Client for Windows in the Internet
Explorer Web browser.
The tclient.stc file is used to start Thin Client for Windows in the Netscape
Communicator Web browser.
The parameters in these files are not set automatically during installation with the
Siebel Server. You must complete the following steps to edit the appropriate file
before you can use Siebel Thin Client for Windows.

Internet Explorer Client Startup File 19
To make sure that the Thin Client for Windows files operate correctly in your
Microsoft Internet Explorer browser, follow the steps below.
To edit the Internet Explorer client startup file

1 Using a text or HTML editor, such as WordPad, open the tclient.htm file from
the \tclient subdirectory on the Siebel Server.
Caution: Do not change the order of the parameters in this file. If

you do, Thin Client for Windows will not start up.
2 Find the line that uses this syntax:

SiebelApplicationControl1.Login('host =
“siebel[.transport][.encryption][.compression]://<gatewayaddress>[:port]
/<siebelenterprise>/<objectmanager>/
< siebelserver> [cti= “TRUE”] [lang = “ENU”]', '[username]', '[password]')
where < > (angle brackets) indicate a required parameter, and [ ] (square
brackets) indicate an optional parameter.
Note that the default values in the actual file may be different from these strings,
but the location and meaning of the values remain the same.
a Specify the variable protocol settings below:

[transport][.encryption][.compression]
Transport values are tcpip or http. The default is tcpip.
Encryption values are none or mscrypto. The default is none.
NOTE: You must set the encryption value to match the value of the Siebel
Application Object Manager to which the Siebel Thin Client will connect.
Compression values include none, zlib, or pkware. The default is

none. This parameter only controls messages sent from the Siebel Thin
Client to the Application Object Manager. The compression parameter for
the Application Object Manager, whose setting can vary from this one,
determines the compression applied to messages sent from the server to
the Siebel Thin Client.

b Replace gatewayaddress with the address of the machine on which the

Siebel Gateway Server is installed, using one of the following values:
If you are using Resonate Central Dispatch, the Gateway Server address is
the Gateway VIP that you assigned while installing the Siebel Server
components.
If you are not using Resonate Central Dispatch, enter either the network
name or IP address of the application server on which the Gateway Server
is installed.
Make sure to precede the parameter with double quotes, as shown in Step 2
on page 19-5. The quotes will be closed in Step 2e below.
c Replace siebelenterprise with the name of the Siebel Enterprise Server.

d Replace objectmanager with the name of the defined Application Object
Manager component that you want Siebel Thin Client for Windows to access.
NOTE: If you will have multiple groups of Siebel Thin Client for Windows
users who will access different Application Object Manager components, you
must create multiple copies of the startup file, each with a unique name.
There are several predefined Application Object Manager components, four

of which pertain to Siebel Thin Client for Windows:
SCCObjMgr
SSEObjMgr
SFSObjMgr
SSVObjMgr
NOTE: You can also define your own components. See the Siebel Server
Administration Guide for information about defining and assigning
Application Object Manager services.

e The siebelserver parameter determines the Siebel Server on which the

thin client will access the Application Object Manager-defined component.
You will specify a Siebel Server only if you are not using Resonate Central
Dispatch.
If you are using Resonate Central Dispatch, the Gateway Server

automatically determines the Siebel Server to which the thin client will
connect. In this case, there will be no entry for the siebelserver value;
instead, put double quotes immediately after the value specified for
objectmanager.
If you are not using Resonate Central Dispatch, replace siebelserver

with the name of a Siebel Server to which the defined component,
identified by the ObjectManager parameter, will operate. The
siebelserver value must be followed by double quotes, as shown in
Step 2 on page 19-5.
Make sure that you precede the parameter you add with a double quote, as
shown in Step 2 on page 19-5.
f The lang parameter specifies the language used by the Application Object
Manager component, defined by objectmanager.
This parameter is part of the Application Object Manager component

definition; refer to the Siebel Server Administration Guide for more
information on component parameters. This value is specified using the
three-letter code for the language: ENU for U.S. English, JPN for Japanese,
and so forth. Make sure to put double quotes around this value and a single
quote immediately following it, as shown in Step 2 on page 19-5.

g Username and Password specify the user name and password used by the
thin client to log onto the Siebel Database Server. If desired, enter a valid user
name and password that will automatically be used by all thin client users.
Each value must be enclosed by single quotes, as shown in Step 2 on
page 19-5.
If you leave these values blank, each thin client user will be prompted to
enter a login name and password at startup. Enter two single quotation
marks for each value to indicate a null value for the user name and password,
as shown here:
SiebelApplicationControl1.Login('host =
“siebel.transport.encryption.compression://
gateway_address:gateway_port/ “siebelenterprise/
objectmanager/siebelserver” lang=”ENU”,'','')
h The cti parameter enables Siebel CTI (Computer Telephony Integration) for
the thin client.
Set cti to “TRUE” if you are using Siebel CTI and “FALSE” if you are not
using Siebel CTI. If you are not using CTI, you can also omit the cti
parameter.
3 Find the line that uses this syntax:

OBJECT ID=”SiebelApplicationControl1” WIDTH=100% HEIGHT=100%
CLASSID=”CLSID:38E95018-1EBB-11d3-A22C-00508B347441”
/OBJECT
The WIDTH and HEIGHT attributes specify the width and height of the screen
area in which Thin Client for Windows will be displayed.
In the example above, the width and height are specified as a percentage of the
Web browser display area, or 100% by 100%. A setting of 100% by 100% causes
the thin client to occupy the entire Web browser display area.
You can also specify this area in pixels, for example, 800 by 600 pixels, by
entering a number for each value.

Netscape Communicator Startup File 19
To ensure that the Thin Client for Windows files operate correctly in your Netscape
browser, follow the steps below.
To edit the Netscape Communicator client startup file

1 Using a text or HTML editor, such as WordPad, open the tclient.stc file from
the \tclient subdirectory on the Siebel Server.
Caution: Do not change the order of the parameters in this file.

Otherwise, Siebel Thin Client for Windows will not start up.
The structure of the tclient.stc file is shown here. Pay close attention to
single and double quotes. Improper placement of these quotes will cause your
application not to launch:
Login('host = “siebel[.transport][.encryption][.compression]://
<gatewayaddress>[:port]/<siebelenterprise>/<objectmanager>/
< siebelserver> [cti= “TRUE”] [lang = “ENU”]', '[username]', '[password]')
where < > (angle brackets) indicate a required parameter, and [ ] (square
brackets) indicate an optional parameter.
2 The values for the tclient.stc file are exactly as described for the Internet
Explorer startup file in the previous section; refer to that section, “To edit the
Internet Explorer client startup file” on page 19-5, for a description of the values.
NOTE: The default values in the actual file may be different from these strings,
but the locations and meanings of the values remain the same.
3 Make sure that each string of values is enclosed in double quotes, as shown in
the example in Step 1 for the parameters cti and lang.

Sharing Thin Client Startup Files
Sharing Thin Client Startup Files 19
After you have edited one or both of the Thin Client for Windows startup files, they
must be made available to the Thin Client users. For ease of maintenance, Siebel
Systems strongly recommends that you share the startup files from a network
shared drive or a Web server, or from both. This allows you to easily distribute
changes in the event that your Siebel Enterprise Server configuration is altered.
You may elect to use a combination of these two methods to serve different groups
of users. Whichever sharing mechanisms you elect to deploy, distribute the Thin
Client startup files now and make sure that the Thin Client machines have read
access to them.

Installing and Configuring the
.COM Applications Under Windows NT 20

Planning the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-3
Verifying the Siebel Enterprise Server . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5
Verifying .COM Application Requirements . . . . . . . . . . . . . . . . . . . 20-5
Installing the Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5

Review Installation Directories . . . . . . . . . . . . . . . . . . . . . . . . . . 20-11
Services You Must Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-18

Installing and Configuring the .COM Applications Under Windows NT
About This Chapter
The Siebel .COM Applications are a family of Web-based applications that you
access through a standard Web browser.
The .COM Applications use several server-side components to service these browser
clients:
A Web server, to which client Web browsers connect.

.COM Application server components that run as extensions within the Web
server. These server components connect to the Application Object Manager for
access to Siebel Applications data and logic.
The Application Object Manager, operating within the Siebel Enterprise Server.
This chapter provides instructions for installing and configuring the .COM
Application server components. For information on supported hardware, operating
system platforms, Web browsers, and Web servers, refer to Siebel System

Complete the following tasks before running the eappweb installer.
“Planning the Installation”

“Verifying the Siebel Enterprise Server” on page 20-5
“Verifying .COM Application Requirements” on page 20-5
“Installing the Web Server” on page 20-5
Planning the Installation 20
Before installing the .COM Applications, you must have already installed the
following components:
A support Web server

Before beginning the installation process, decide how you will distribute the server
components.
Single-node. Installation of Siebel Enterprise Server components, Siebel .COM

Application server components, and your Web server on a single server.
Distributed. Distribution of the above-mentioned components across multiple

application servers (typically one or more dedicated Web servers) connecting to
multiple Application Object Managers whose load can be dynamically balanced
across multiple Siebel Servers within an Enterprise Server.
NOTE: In either configuration (single-node or distributed), the database server

resides on a separate node.

Recommended Configuration
Each configuration involves trade-offs. However, Siebel Systems strongly
recommends a distributed node deployment for the following reasons:
Less resource contention. Distributing the Web server and the Siebel Server (with
Application Object Manager) on different machines eliminates contention for
CPU and other server resources. However, to take advantage of the performance
improvement, you must have a high-speed network connection between the two
machines.
Load balancing. A single Web server can distribute the load of multiple user
requests among multiple Application Object Manager instances, using the
connection-brokering capabilities of the Siebel Gateway Server.
Higher fault tolerance. Operating multiple instances of components on multiple

machines reduces downtime and the impact of failure on any one machine.
Greater flexibility with firewalls. Putting the Web components of the HTML Thin
Client on a different machine from the Siebel Enterprise Server and Application
Object Manager lets you deploy your Web server outside the firewall while
keeping the Enterprise Server components behind the firewall.
A multi-node configuration is, therefore, strongly recommended for deployments

that support large numbers of concurrent users, or where high availability is an
operating requirement.

You must have installed and configured the Siebel Gateway Server and an Enterprise
Server containing at least one Siebel Server before installing the Siebel .COM
Applications. Complete the steps in Chapter 7, “Installing the Siebel Server Under
Windows NT,” to install and configure the Enterprise Server entities, following the
configuration chosen in the previous step.
If you are installing the Application Object Manager and Web components of an
HTML Thin Client application on the same machine, use separate installation
directories to avoid file permission problems at installation time.
Verifying .COM Application Requirements 20
Make sure that the application server that will support the .COM applications meets
all the hardware and software platform requirements documented in Siebel System
Installing the Web Server 20
Before installing the .COM Applications, install, configure, and start the supported
Web server on the machine where your .COM Applications will reside. Follow the
instructions from the vendor to complete these tasks.
NOTE: For the best performance and scalability, Siebel Systems recommends that the
Web server reside on a separate machine from the Siebel Enterprise Server.

Installing .COM Applications
Installing .COM Applications 20
The .COM Application files will be installed on the same application server as the
Web server. The installation program sets up the Siebel directory structures, copies
required files and components to the target disk, and configures the host
environment.
To install the .COM Applications files

the machine where your Web server is installed. (In these instructions, this is
assumed to be D:\.)
2 In Windows NT Explorer, navigate to D:\eappweb and double-click Setup.exe

to start the .COM applications installation program.
3 In the Welcome screen, click Next.

If you have not yet installed the supported Web server, Setup prompts you to
install it now. Otherwise, your Siebel programs will not function properly.
4 Follow the on-screen instructions and click Next.

5 Specify the destination directory for the Web Engine and .COM Applications.
The default directory is C:\sea6xx\SWEApp.
To accept the default directory, click Next.
To specify a different destination directory, click Browse.
If you specify a directory other than C:\sea6xx\SWEApp, make the

appropriate substitutions throughout the remainder of this section.
The Load Balancing screen appears.

6 Indicate whether or not you use the Central Dispatch load balancing feature.
If you use Central Dispatch, choose Yes.
If you do not use Central Dispatch, choose No.
NOTE: Siebel Systems strongly recommends the use of load balancing in your
enterprise network.
The Gateway and Enterprise server information screen appears.
7 Type the following information, referring to your entries in Appendix A,

Gateway Server Alias
If you use Central Dispatch, type the Gateway Server VIP address.
If you do not use Central Dispatch, type the network name or IP address
of the Gateway Server host.
Gateway Server Port Number. The default is 2320.
Enterprise Server Alias. The name of the Siebel Enterprise Server on which the
Application Object Manager components are running.
If you are not using Central Dispatch, the Siebel Server Information screen
appears. Proceed to Step 8.
If you use Central Dispatch, proceed to Step 9 on page 20-8.
8 On the Siebel Server Information screen, type the logical name of your Siebel
Server (not the machine name).
The Connection Protocol screen appears.

9 On the Connection Protocol screen, choose the type of protocol Siebel should
use to connect to the Application Object Manager:
TCP IP
HTTP
NOTE: The Application Object Managers to which the .COM Applications

connect must be configured to use the same protocol.
The Encryption Type screen appears.
10 Choose whether or not you want to encrypt communications to the Application

Object Manager:
None
MSCRYPTO
NOTE: The Application Object Managers must be configured with the same
encryption setting.
The Compression Method screen appears.

11 Choose the method of data compression you prefer when the .COM Applications
communicate to the Applications Object Managers:
None
ZLIB
PKWARE
NOTE: The compression setting on an Application Object Manager controls

compression of communications between it and its .COM Application.
The first of two Anonymous User Account screens appears.
This screen requires an employee login ID and password that any employee may
access through an electronic billboard or similar medium.
The login ID should be a valid client login for the application you are installing,
regardless of the authentication method your company uses.
The ID used should also have authorization to access the Public View.
12 Type the login and password for employees.

The second Anonymous User Account screen appears.
This screen is for those who use a contact-type login ID and password.
13 If you use a contact-based login, type this login now.

Make sure that it is a valid login for the application you are installing, regardless
of the authentication method your company uses.
The Error Level for Logging screen appears.

14 On the Error Logging Level screen, specify the level of operational error logging
for the .COM Applications, and then click Next.
The options consist of the following:
Errors only. The default setup option causes nonfatal and fatal operational
errors to be logged.
All (errors and warnings). This setup option causes all operational statistics,
information messages, warnings, and errors to be logged.
None. This setup option causes only fatal operational errors to be logged.
NOTE: For the best performance, choose Errors Only. Choose All only for
debugging.
The Setup Status bar appears. The installer now installs the Siebel .COM
Applications.
The Event Log screen appears.

16 Click Finish.
This completes the installation of the Siebel .COM Application files.
For instructions on deploying HTML Thin Client applications, see the Siebel .COM
Applications Guide.

Perform the following post-installation tasks only if your environment requires

changes to the default settings, resulting from installation of the Siebel .COM
Applications, using the eappweb installer:
“Review Installation Directories”

“Editing the .COM Applications Configuration File” on page 20-12
“Services You Must Restart” on page 20-18
Review Installation Directories 20
Review the physical and virtual directories created during installation of the .COM
Applications on the Web server host to familiarize yourself with the locations of
files, such as the .COM Applications configuration file (eapps.cfg). The following
list shows physical directories that the installer puts in the /sea6xx directory:
/SWEApp/
bin/
language/
public/
demo
files
help
images
scripts
webtempl
Virtual directories are installed on the Web server for each .COM Application, for
example, eservice directory for the eService product.

Editing the .COM Applications Configuration File 20
The eappweb installer installs a single configuration file, eapps.cfg, for all the
.COM Applications by default into the \BIN subdirectory of the installation on your
Web server host.
The parameters of the configuration file are automatically set during installation
and do not normally require any manual configuration. However, should your
environment require making changes to any of the settings, just double-click the file
to launch your default text editor. You may edit it with any standard text editor such
as Windows Notepad.
If you do modify the configuration file, you must restart several Windows NT
services to make your changes take effect. See “Services You Must Restart” on
page 20-18.
For information about parameters that you may be required to set at the Application
Object Manager level on the Siebel Server, refer to the appropriate section of the
Siebel Server Administration Guide, Configuring Siebel .COM Applications, and
Siebel .COM Applications Guide. For example, if your enterprise uses eChannel,
eSales, or eService, you will need to configure LDAP for a secure connection.
About the Configuration File

The eapps.cfg file contains configuration information that you entered during the
installation of the .COM Applications on the Web server, including identity and
connectivity information for the Application Object Manager, and login and security
settings.
You may also add selected optional parameters manually to affect the .COM
Applications as a whole. Alternatively, you may override these added parameters to
determine the performance of one or more applications by adding them to the
appropriate connect string in the applications section of the file and editing them
there.
This section of the file contains connect strings for each .COM application. Each
connect string is preceded by a bracketed heading as illustrated below:
[/xxx]
where xxx is the name of the .COM Application you want to edit.

Sample eapps.cfg
[swe]
Language = enu
Log = errors
LogDirectory = /SWEAppweb/log
SwcPort = 8197
[defaults]
AnonUserName = User1
AnonPassword = User1
AnonUserPool = 10
StatsPage = _stats.swe
[/ebriefings]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eBriefingsObjMgr/USER1
[/ebriefings_w]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eBriefingsDCObjMgr/
USER1
[/echannel]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eChannelObjMgr/USER1
[/partnerfinder]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/PartnerFinderObjMgr/
USER1
[/%HTMLSales_VIRTUALDIR%]
ConnectString = siebel.TCPIP.none.none://Shakt:2320/siebel/HTMLSalesObjMgr/Shakti
[/wpsales]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/WebphoneSalesObjMgr/
USER1

[/wpserv]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/WebphoneServiceObjMgr/
USER1
[/eai]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eSalesObjMgr/USER1
EnableExtServiceOnly = TRUE
[/ecustomer]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eCustomerObjMgr/USER1
[/emarketing]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eMarketObjMgr/USER1
[/esales]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eSalesObjMgr/USER1
[/eservice]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eServiceObjMgr/USER1
[/etraining]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eTrainingObjMgr/USER1

Optional Parameters
The following optional parameters may be manually added to the [defaults]
sections of the file, at the individual application level, or in both locations, with
exceptions for particular applications.
Enabled
A particular .COM Application (for example, /etraining) stops responding to user
requests if this flag is set to 0. The default is 1, or enabled.
SessionTimeout
The time, in seconds, from the user’s last browser request until the user’s
connection times out.
If set to 0, it will never time out. If omitted, the default value is 28800
(eight hours).
For example, if SessionTimeout is set to 28800, then the session ends 28800
seconds (eight hours) after the user’s last browser request.
HTTPPort
The HTTP port used for Web browser communications. The default setting is the
specified port of the Web server in use.
HTTPSPort
The HTTPS port used for secure Web browser connections. The default setting is
the specified port of the Web server in use.
Mandatory Parameters
These parameters already exist in the eapps.cfg file when you open it after
installation to your \bin subdirectory. You may edit them if your environment
requires it.
[swe] Section
The parameters that follow can be found in this section of the eapps.cfg file. These
parameters apply to all .COM Applications.
Language
This is the localized version you purchased for .COM Applications. For example,
enu stands for U.S. English.

Log
These are the types of log entries you selected during installation. For example, an
entry reading “errors” would mean that the log should show only fatal and non-
fatal operational errors.
LogDirectory
This is the location of the log directory, whose default location is
/SWEAppweb/log.
SwcPort
If you use IBM HTTP Server under AIX UNIX, you must reset this parameter to
provide a listening port for Siebel Web Companion. Siebel Systems recommends
resetting the port number from 8197 to 8192 since the Siebel Web Engine uses the
former; for example:
SwcPort=8192
NOTE: You do not need to reset this parameter if you do not use IBM HTTP Server.
For instructions on use of IBM HTTP Server with AIX, see Chapter 21, “Installing
and Configuring the .COM Applications Under UNIX.”
[defaults] Section
The parameters that follow apply to all .COM Applications. Any of the settings that
can be specified under [defaults] can be also specified for individual .COM
Applications (such as /esales) in the [xxx] section. If such a parameter is set for
a particular .COM Application, it overrides the value listed in [defaults].
AnonUserName
If you are accessing the application through the database, the name you use must
be an authorized user of the database. The person whose name is used should be
authorized for access to Public View.
This parameter controls the “handshake” between the Siebel Web Engine and the
Siebel Database.
AnonPassword
The password corresponding to the value entered for AnonUserName.

AnonUserPool
This parameter specifies the maximum number of anonymous user connections
from the Web server to the Application Object Manager. If the environment variable
NUMBER_OF_PROCESSORS is set, then the maximum value is multiplied by that
value.
The anonymous user pool is used during the brief initial interactions from the user
before logging in. After users log in, they have a separate connection.
The default value is 10. If you expect to have a very busy site, you may want to
increase this.
StatsPage
This is the URL (relative to the application’s virtual directory) of the page that
administrators can access to view application statistics. Statistics include the
number of active users, the number of requests, and average speed of request
processing.
Since this page is generated by Siebel Web Engine, you can view it only from a
browser. For example, if StatsPage is set to _stats.swe, and the virtual directory
for your application is Service, then to see the statistics you would enter the
following URL:
http://mysite/Service/_stats.swe
Caution: To protect your statistics, make this page password-

protected, or rename _stats.swe.
[/xxx] Section
The parameters that follow can be found in this section of the eapps.cfg file. These
parameters apply to each of the .COM Applications. As mentioned previously, any
parameter you set for a particular .COM Application overrides any opposite value
listed under [defaults].
ConnectString
A connect string exists for each .COM Application. Each connect string reflects the
individual object manager for that application and contains information you
entered during setup.

The sample connect string below contains descriptions within parentheses of the
string components.
[/echannel]
ConnectString = siebel.TCPIP (networking protocol).none.

(encryption type chose) none (data compression method chosen)://USER1
(Gateway alias):2320(port number)/siebel(Enterprise Server)/
eChannelObjMgr(relevant object manager)/USER1(Siebel Server alias)
Services You Must Restart 20
If you make any changes to a configuration file in the private directory BIN, as
opposed to those in the siebel_server/bin directory, where siebel_server is
the name of the directory where your Siebel Server resides, you must stop and
restart the following Windows NT Services:
IIS Admin Service

World Wide Web Publishing Service
Siebel Gateway Name Server
Siebel Server
Restarting these services guarantees that Siebel Web Engine reads the new
information from the modified configuration file.

.COM Applications Under UNIX 21

Planning the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-3
Granting User Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-4
Verifying the Siebel Enterprise Server . . . . . . . . . . . . . . . . . . . . . . 21-5
Verifying .COM Application Requirements . . . . . . . . . . . . . . . . . . . 21-5
Installing the Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-5

Review Installation Directories . . . . . . . . . . . . . . . . . . . . . . . . . . 21-13
Setting the LATCH Environment Variable . . . . . . . . . . . . . . . . . . . 21-14
Configuring iPlanet to Accept Siebel .COM Applications . . . . . . . . . . . . . 21-22
Shell Scripts You Must Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-23
Running the IBM HTTP Server and Siebel Web Companion . . . . . . 21-23

Installing and Configuring the .COM Applications Under UNIX
About This Chapter
The Siebel .COM Applications are a family of Web-based applications you access
through a standard Web browser.
The .COM Applications use several server-side components to service these browser
clients:
A Web server, to which client Web browsers connect.

.COM Application server components that run as extensions within the Web
server. These server components connect to the Application Object Manager for
access to Siebel Applications data and logic.
The Application Object Manager, operating within the Siebel Enterprise Server.
This chapter provides instructions for installing and configuring the .COM
Application server components. For information on supported hardware, operating
system platforms, Web browsers and Web servers, refer to Siebel System

Complete the following tasks before beginning running the eappweb installer.
“Planning the Installation”

“Granting User Permissions” on page 21-4
“Verifying .COM Application Requirements” on page 21-5
“Installing the Web Server” on page 21-5
Planning the Installation 21
Before installing the .COM Applications, you must have already installed the
following components:
A support Web server

Before beginning the installation process, decide how you will distribute the server
components.
Single-node. Installation of Siebel Enterprise Server components, Siebel .COM

Application server components, and your Web server on a single server.
Distributed. Distribution of the above-mentioned components across multiple

application servers (typically one or more dedicated Web servers), connecting to
multiple Application Object Managers whose load can be dynamically balanced
across multiple Siebel Servers within an Enterprise Server.
NOTE: In either configuration (single-node or distributed), the database server

resides on a separate node.

Each configuration involves trade-offs. However, Siebel Systems strongly

recommends a distributed node deployment for the following reasons:
Less resource contention. Distributing the Web server and the Siebel Server (with
Application Object Manager) on different machines eliminates contention for
CPU and other server resources. However, to take advantage of the performance
improvement, you must have a high-speed network connection between the two
machines.
Load balancing. A single Web server can distribute the load of multiple user
requests among multiple Application Object Manager instances, using the
connection-brokering capabilities of the Siebel Gateway Server.
Higher fault tolerance. Operating multiple instances of components on multiple

machines reduces downtime and the impact of failure on any one machine.
Greater flexibility with firewalls. Putting the Web components of the HTML Thin
Client on a different machine from the Siebel Enterprise Server and Application
Object Manager allows you to deploy your Web server outside the firewall while
keeping the Enterprise Server components behind the firewall.
A multi-node configuration is, therefore, highly recommended for deployments that

support large numbers of concurrent users, or where high availability is an
operating requirement.
Granting User Permissions 21
After installing the .COM Applications, make sure that the following steps are taken.
iPlanet Web Server:
Run install_eappweb under an account that has access rights to modify the
iPlanet (formerly, the Netscape Enterprise) configuration files. This account is
typically the root directory.
Make sure that the account that the iPlanet httpd daemon uses has write
permissions for the /eappweb/log directory. Typically this means that you must
change the permissions for the appropriate directory.
Make sure that the account that the iPlanet httpd daemon uses has read
permissions to all files in the /eappweb/public directory. Alternatively, you
may make the public directory available to everyone by inputting the following:
chmod -R a+r /eappweb/public

IBM HTTP Server:
Make sure that users who will be running the Web server have execution
permission for the scripts installed with the .COM Applications to enable
starting and stopping the Web server and Siebel Web Companion, and write
permission for the log file path.
You must have installed and configured the Siebel Gateway Server and an Enterprise
Server containing at least one Siebel Server before installing the Siebel .COM
Applications. Complete the steps in Chapter 8, “Installing the Siebel Server
Under UNIX,” to install and configure the Enterprise Server entities, following the
configuration chosen in the previous step.
If you are installing the Application Object Manager and Web components of an
HTML Thin Client application on the same machine, use separate installation
directories to avoid file permission problems at installation time.
Verifying .COM Application Requirements 21
Make sure that the application server that will support the .COM applications meets
all of the hardware and software platform requirements documented in Siebel
Installing the Web Server 21
For the best performance and scalability, Siebel Systems recommends that the Web
server reside on a separate machine from the Siebel Enterprise Server.
Before installing the .COM Applications, install, configure, and start the supported
Web server on the machine where your .COM Applications will reside. Follow the
instructions from the vendor to complete these tasks.
NOTE: If you are installing the IBM HTTP Server under AIX, you must also run a
server called Siebel Web Companion whenever you run the Web server. Siebel Web
Companion is installed automatically along with the .COM Applications.

Installing .COM Applications 21
Install the .COM Application files on the same machine as the Web server. The
installation program sets up the Siebel directory structures, copies required files and
components to the target disk, and configures the host environment.
To install the .COM Applications in a UNIX environment

1 Insert the UNIX CD-ROM into the CD-ROM drive of your application server.
2 Log onto the server as root, or as superuser, and mount the CD-ROM, if required
to make it accessible.
3 Open a terminal window and navigate to the following directory:

seaunix6xx/operating_system/eappweb/install
where:
operating_system = your specific UNIX platform, such as Solaris or AIX.
depending on the way in which you access the CD-ROM.
4 Enter install_eappweb to start the installer script:

$ install_eappweb
The following text appears:
Siebel Web Engine Installer (Version 6.x [xxxx] ENU)
If you have not yet specified the root directory by setting the environment
variable SIEBEL_ROOT, the installer script prompts you to enter it now.
5 To accept the displayed default value, press ENTER. Otherwise, enter the name
of the Siebel root directory.
The installer prompts you to enter the root directory of the iPlanet Web Server/
IBM HTTP Server instance on which you want to deploy the .COM Applications.

6 Enter the desired root directory for the Web server.

This directory will be under the same root directory where you installed your
Web server and will have a name with the format:
https-your_server_instance_name
If you have installed iPlanet Web Server, the Siebel installer prompts you:
Do you want to use Resonate load balancing ? [N]
7 Specify whether or not you are using Resonate Central Dispatch load balancing
software by entering Y or N, as appropriate.
The Siebel installer prompts you:
Please specify the gateway server address [shakti]
8 Accept the default Gateway Server, or enter the VIP address of the one you prefer
to use.
The following prompt appears with the default port number:
Please specify the gateway server port [2320]
9 Accept the default port number or enter another.

Please specify enterprise name [siebel]
10 Enter the name of the Siebel Enterprise Server on which the Application Object
Manager components are running if it is different from the default.
Please specify siebel server name [shakti]

11 Enter the alias of your Siebel Server.

In the example above, the alias entered was shakti.
1) tcpip
2) http
Please select communication protocol [1]
12 Enter the number corresponding to the type of networking protocol the Siebel
HTML Thin Client should use to connect to the Application Object Managers.
For information about the Application Object Managers, refer to the Siebel Server
NOTE: The Application Object Managers to which the .COM Applications

connect must be configured to use the same protocol.
1) none
2) zlib
3) pkware
Please select compression type [1]

13 Enter the number corresponding to the type of encryption you want to use, if
any, for communications to the Application Object Managers.
NOTE: The Application Object Managers must be configured with the same
encryption setting.
1) errors
2) all
3) none
Select logging level [1]
14 Enter the number corresponding to the level of operational error logging for the
.COM Applications, as described below.
Errors. The default setup option causes nonfatal and fatal operational errors
to be logged.
All (errors and warnings). This setup option causes all operational statistics,
information messages, warnings, and errors to be logged.
None. This setup option causes only fatal operational errors to be logged.
NOTE: For the best performance, choose 1) errors. Choose 2) all only for
debugging.
Please specify anonymous login EMPLOYEE name [] SADMIN

15 Enter an employee login ID and password that any employee may access
through an electronic billboard or similar medium.
The login ID should be a valid client login for the application you are installing,
regardless of the authentication method your company uses.
Please specify anonymous login EMPLOYEE password []
16 Enter a password to which all can have access for the login ID entered above.
Please re-type anonymous login EMPLOYEE password []
Please specify anonymous login CONTACT name [] GUEST
This prompt is for those who use a contact-type login ID and password.
17 If you use a contact-based login, enter this login now.

Make sure that it is a valid login for the application you are installing, regardless
of the authentication method your company uses.
Please specify anonymous login CONTACT password []
18 Enter the password for the contact-based login.

If your system is Solaris, proceed to Step 20 on page 21-11.
If you are running AIX, the Siebel installer prompts you:
Please specify the Siebel Web Companion port [8197]

19 Accept the default port, or select an alternative port number.

Now beginning File Installation
Installation directory /volx/xxxxx/xxxxx does not exist; would

you like to create it? [Y]
20 Accept the default (Y) to install the .COM Applications in a new directory.
[X] All

N to change) [Y]
21 To install the software installation packages, accept the default Y.

To postpone the installation, choose N. The installer exits.
When you confirm installing the software packages now, a number of system
messages appear, indicating the status of package installation.
The installation script starts installing the .COM Application files.
If your Web server is running during the installation, the installation script
prompts you to restart the Web server so that it can load the changes into the
configuration file:
To see your changes, the Web Server needs to be restarted.

Restart Web Server? [Y]

22 Accept the default Y and press ENTER to restart the Web server processes, or
enter N if you want to restart them later.
If you do not restart the Web server processes at this time, you should do so
before making Siebel .COM Applications available to your users.
If you have installed IBM HTTP Server, restarting the Web server processes also
starts Siebel Web Companion, which is required to run in tandem with HTTP
Server when swcsrvr is not running.
If you decide to restart the Web server later, you will need to start Siebel Web
Companion manually. For instructions on starting and stopping Siebel Web
Companion, see “Running the IBM HTTP Server and Siebel Web Companion”
on page 21-23.
The installation script exits when installation is complete.

After installing the Siebel .COM Applications, perform the following post-
installation tasks, if needed.
“Review Installation Directories”

“Setting the LATCH Environment Variable” on page 21-14
“Editing the .COM Applications Configuration File” on page 21-15 (optional)
“Configuring iPlanet to Accept Siebel .COM Applications” on page 21-22
“Shell Scripts You Must Restart” on page 21-23
“Running the IBM HTTP Server and Siebel Web Companion” on page 21-23
(optional)
Review Installation Directories 21
Review the physical and virtual directories created during installation of the .COM
Applications on the Web server host to familiarize yourself with the locations of
files, such as the .COM Applications configuration file (eapps.cfg). The following
list shows physical directories that the installer puts in the $SIEBEL_HOME directory:
/SWEApp/
bin/
language/
public/
demo
files
help
images
scripts
webtempl
Virtual directories are installed on the Web server for each .COM Application, for
example, eservice directory for the eService product.

Setting the LATCH Environment Variable 21
To make sure that applications run correctly, set the environment variable
SIEBEL_OSD_LATCH to 2.5 times the number of concurrent users you anticipate. For
example, if you anticipate 1,000 concurrent users, run this command at the
command prompt:
set SIEBEL_OSD_LATCH 2500
This variable controls the maximum number of latches that can be created.
Therefore, do not set it at a significantly higher value than that recommended here.
You can put this command in your .cshrc file. If you do not do this, make sure you
run it before you start your Web server.
For instructions on deploying HTML Thin Client applications see the Siebel HTML
Thin Client Developers Reference.

Editing the .COM Applications Configuration File 21
The eappweb installer installs a single configuration file, eapps.cfg, for all the
.COM Applications by default into the /bin subdirectory of the installation on your
Web server host.
The eapps.cfg file contains configuration information that you entered during the
installation of the .COM Applications on the Web server, including identity and
connectivity information for the Application Object Managers, and login and
security settings.
As a result, you do not, in most cases, need to edit this file unless you are moving
server components to another machine, for which you would need to record new
information.
You may, if desirable, add selected optional parameters manually to affect the .COM
Applications as a whole. You may also override the added parameters to determine
the performance of one or more applications. This is accomplished by adding them
to the appropriate connect string in the applications section of the file and editing
them there, using any editing tool, such as vi.
If you will be running iPlanet Web Server under Solaris, be aware that the iPlanet
Server configuration file obj.conf, located within the iPlanet configuration
directory, references the file eapps.cfg, because the Siebel installer adds the
reference to obj.conf. A typical line the installer would add to obj.conf might be:
Init fn=”swe-init”config-file=”/SWEappweb/bin/eapps.cfg”
siebel-home=”/eappweb”
To find obj.conf, look under the following path:
“/usr/netscape/suitespot/https-your server instance name/config”
It may be directly under the config directory or within a subdirectory of config.
For information about parameters that you may be required to set at the Application
Object Manager level on the Siebel Server, refer to the appropriate section of the
Siebel Server Administration Guide, Siebel HTML Thin Client Developers Reference,
and Siebel .COM Applications Guide. For example, if your enterprise uses eChannel,
eSales, or eService, you will need to configure LDAP for a secure connection.
To make your changes take effect, you must restart several shell or UNIX shell
scripts, as described in “Shell Scripts You Must Restart” on page 21-23.

About the Configuration File

The applications section of the file contains connect strings for each .COM
application. Each connect string is preceded by a bracketed heading as illustrated
below:
[/xxx]
where xxx is the name of the .COM Application you want to edit. xxx should
match the name of the virtual directory in iPlanet configuration file obj.conf that
is mapped to the Siebel plug-in.
Sample eapps.cfg
[swe]
Language = enu
Log = errors
LogDirectory = \SWEApp\log
SwcPort = 8197
[defaults]
AnonUserName = Shakti
AnonPassword = Shakti
AnonUserPool = 10
StatsPage = _stats.swe
[/ebriefings]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eBriefingsObjMgr/
Shakti
[/ebriefings_w]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eBriefingsDCObjMgr/
Shakti
[/echannel]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eChannelObjMgr/Shakti

[/partnerfinder]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/PartnerFinderObjMgr/
Shakti
[/%HTMLSales_VIRTUALDIR%]
ConnectString = siebel.TCPIP.none.none://Shakt:2320/siebel/HTMLSalesObjMgr/Shakti
[/wpsales]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/WebphoneSalesObjMgr/
Shakti
[/wpserv]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/
WebphoneServiceObjMgr/Shakti
[/eai]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eSalesObjMgr/Shakti
EnableExtServiceOnly = TRUE
[/ecustomer]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eCustomerObjMgr/
Shakti
[/emarketing]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eMarketObjMgr/Shakti

[/esales]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eSalesObjMgr/Shakti
[/eservice]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eServiceObjMgr/Shakti
[/etraining]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eTrainingObjMgr/
Shakti
Optional Parameters
The following optional parameters may be manually added to the [defaults]
sections of the file, at the individual application level, or in both locations, with
exceptions for particular applications.
Enabled
A particular .COM Application (for example, /etraining) stops responding to user
requests if this flag is set to 0. The default is 1, or enabled.
SessionTimeout
The time, in seconds, from the user’s last browser request until the user’s
connection times out.
If set to 0, it will never time out. If omitted, the default value is 28800
(eight hours).
For example, if SessionTimeout is set to 28800, then the session ends 28800
seconds (eight hours) after the user’s last browser request.

HTTPPort
The HTTP port used for Web browser communications. The default setting is the
specified port of the Web server in use.
HTTPSPort
The HTTPS port used for secure Web browser connections. The default setting is
the specified port of the Web server in use.
Mandatory Parameters
These parameters already exist in the eapps.cfg file when you open it after
installation to your /bin subdirectory. You may edit them if your environment
requires it.
[swe] Section
The following parameters can be found in this section of the eapps.cfg file. These
parameters apply to all .COM Applications.
Language
This is the localized version you purchased for .COM Applications. For example,
enu stands for U.S. English.
Log
These are the types of log entries you selected during installation. For example, an
entry reading “errors” would mean that the log should show only fatal and non-
fatal operational errors.
LogDirectory
This is the location of the log directory, whose default location is
/SWEAppweb/log
SwcPort
IBM HTTP Server users may, if desirable, reset this parameter to provide a different
listening port from the default port number for Siebel Web Companion. However,
resetting this parameter is not required.

[defaults] Section
The parameters that follow apply to all .COM Applications. Any of the settings that
can be specified under [defaults] can be also specified for individual .COM
Applications (such as /esales) in the [xxx] section. If such a parameter is set for
a particular .COM Application, it overrides the value listed in [defaults].
AnonUserName
If you are accessing the application through the database, the name must be an
authorized user of the database. The person whose name is used should be
authorized for access to Public View.
This parameter controls the “handshake” between the Siebel Web Engine and the
Siebel Database.
AnonPassword
The password corresponding to the value entered for AnonUserName.
AnonUserPool
This parameter specifies the maximum number of anonymous user connections
from the Web server to the Application Object Manager. If the environment variable
NUMBER_OF_PROCESSORS is set, then the maximum value is multiplied by that
value.
The anonymous user pool is used during the brief initial interactions from the user
before logging in. After users log in, they have a separate connection.
The default value is 10. If you expect to have a very busy site, you may want to
increase this.
StatsPage
This is the URL (relative to the application’s virtual directory) of the page that
administrators can access to view application statistics. Statistics include the
number of active users, the number of requests, and the average speed of request
processing.

Since this page is generated by the Siebel Web Engine during installation, you can
view it only from a browser. For example, if StatsPage is set to _stats.swe, and
the virtual directory for your application is Service, then to see the statistics you
would enter the following URL:
http://mysite/Service/_stats.swe
Caution: To protect your statistics, make this page password-

protected, or rename _stats.swe.
[/xxx] Section
The following parameters can be found in this section of the eapps.cfg file. These
parameters apply to each of the .COM Applications. As mentioned previously, any
parameter you set for a particular .COM Application overrides any opposite value
listed under [defaults].
ConnectString
A connect string exists for each .COM Application. Each connect string reflects the
individual object manager for that application and contains information you
entered during setup.
The sample connect string below contains descriptions within parentheses of the
string components.
[/echannel]
ConnectString = siebel.TCPIP (networking protocol).none.(encryption

type chose) none (data compression method chosen)://USER1 (Gateway
alias):2320(port number)/siebel(Enterprise Server)/
eChannelObjMgr(relevant object manager)/USER1(Siebel Server alias)

Configuring iPlanet to Accept Siebel .COM Applications 21
If your system is Solaris, it is crucial that you configure the iPlanet Web Server to
accept the changes that the eappweb installer makes to the iPlanet server
configuration files after you install Siebel .COM Applications. Otherwise, changes
that you may make in future to the iPlanet Web Server configuration will overwrite
the changes made by the Siebel installation script.
To make sure that the iPlanet accepts changes made by Siebel .COM Applications
1 Navigate to the iPlanet Web Server Administration page. (Refer to the iPlanet
documentation.)
2 Click the button that shows the server instance on which the .COM Applications
were installed.
This takes you to the Server Preferences page for the instance.
3 On the upper right-hand side of the Server Preferences page, click Apply.
This displays another page with a warning message:
WARNING: The configuration files have been edited by hand. Use

this button to load the latest configuration files.
4 Click on the Load Configuration Files button.

This displays the message:
Success! The most recent config files have been loaded.
This message indicates that the iPlanet Web Server has accepted the changes
made to it by the eappweb installer.

Shell Scripts You Must Restart 21
After making changes to any configuration file, restart the following UNIX shell
scripts:
Either iPlanet Web Server or IBM HTTP Server

Siebel Application Server
This will guarantee that the Siebel Web Engine reads the new information from the
modified configuration file.
Running the IBM HTTP Server and Siebel Web Companion 21
Siebel Web Companion is installed along with the .COM Applications on the IBM
HTTP Server. The installation of the .COM Applications also generates several
scripts for use in starting and stopping IBM HTTP Server and Siebel Web
Companion. These scripts consist of the following:
startapa—Starts both IBM HTTP Server and Siebel Web Companion.
stopapa—Stops both IBM HTTP Server and Siebel Web Companion.
swcctl— Starts/stops Siebel Web Companion. Used by startapa/stopapa to

control Siebel Web Companion, but it can also be used separately; for example:
swcctl start
or
swcctl stop
An alternative method for running Siebel Web Companion is to execute the

following command from the SIEBEL_ROOT/bin directory:
swcsrvr SiebelHomeDirectory
In the above case, you must use the same SiebelHomeDirectory specified during
installation.


Report Server Part 6
Chapter 22. Installing the Siebel Report Server Under Windows NT
Chapter 23. Installing the Siebel Report Server Under UNIX

Installing the Siebel Report Server
Under Windows NT 22
Siebel Report Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-2

Installing Actuate ReportCast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-4
Installing Actuate e.Reporting Server . . . . . . . . . . . . . . . . . . . . . . . 22-5
Installing Siebel Report Server Access . . . . . . . . . . . . . . . . . . . . . . . . . . .22-8
Installing Actuate Administrator Desktop . . . . . . . . . . . . . . . . . . . . . . . .22-12
Installing Actuate Developer Workbench . . . . . . . . . . . . . . . . . . . 22-13
Installing Actuate e.Report Designer . . . . . . . . . . . . . . . . . . . . . . . . . . .22-15

Enabling the Report Server for Use With a Client . . . . . . . . . . . . . 22-16
Editing Repository Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-19

Installing the Siebel Report Server Under Windows NT
About This Chapter
This chapter describes how to install the Siebel Report Server on the Siebel Server,
on a Microsoft IIS or a iPlanet Web Server machine, and on a dedicated Windows
client or Thin Client. For specific version information, refer to Siebel System
This chapter provides both server- and client-side installations.
Siebel Report Server 22
The Siebel Report Server consists of the following components:
Actuate e.Reporting Server. Generates and manages live report documents.

Actuate e.Reporting Server also contains the Report Encyclopedia, a shared
repository that stores report items, along with related data, such as access
privileges and request queues.
Actuate Administrator Desktop. Used to manage one or more Actuate e.Reporting

Servers and Report Encyclopedias and control user privileges.
Actuate ReportCast. Provides access to Siebel Report Server from the World Wide
Web. Using ReportCast, you can access and work with reports through any Web
browser.
Actuate Developer Workbench. Used by professional developers of structured

content to design, build, and distribute report object designs and components
throughout the enterprise. The Actuate Basic Language and Actuate Foundation
Class Library support extensive customization capabilities.
Actuate e.Report Designer. Lets you design and build reports using its graphical
user interface.
Siebel Report Server Access. A Siebel integration component that includes Siebel
Report executables, Siebel ReportCast templates, and other Siebel-specific
library files.

Before installing Actuate ReportCast, make sure that you have installed, configured,
and started either the Microsoft Internet Information Server (IIS) or the iPlanet Web
Server. Siebel Report Server supports both Web servers on Windows NT.
For important pre-installation considerations, see the section entitled “Setting up

the report server account” in the chapter “Report Server Administration on
Windows NT” of the Actuate e.Reporting Server Guide. (This guide is available
in.pdf format on your Bookshelf for Siebel eBusiness Applications CD-ROM.) Read
this section carefully and discuss it with your Windows NT system administrator so
that an account for the Siebel Report Server can be allocated.
Siebel Report Server Installation 22
Install the Siebel Report Server and its associated applications in the following
order:
Server
Actuate ReportCast
Actuate e.Reporting Server
Siebel Report Server Access
Client
Actuate Administrator Desktop

Actuate Developer Workbench
Actuate e.Report Designer

Siebel Report Server Installation
Installing Actuate ReportCast 22
You should install Actuate ReportCast on the same machine as your Web server.
To install Actuate ReportCast

the machine where your Web server resides.
2 Navigate to the appropriate directory, depending on which Web server you use:
\Thirdpty\language\actuate\reportcast\netscape
or
\Thirdpty\language\actuate\reportcast\IIS
where language means that language in which you have bought your Siebel
eBusiness Application, for example, enu for U.S. English.
3 To install ReportCast, double-click SETUP.EXE.

4 Read the Welcome screen and click Next to continue.

The software license screen appears.
5 Read the license screen and accept the license conditions by clicking Yes.
The installer copies the appropriate files to your computer.
After a number of informational screens, the Setup Complete screen appears,

prompting you as to whether you want to reboot your computer now or later.
6 Indicate your preference and click Finish.

Starting Services
After setup has finished installing ReportCast on Windows NT, follow the
instructions below to start services.
To start ReportCast services

1 After setup has finished installing ReportCast, from the Windows NT Start

menu, choose Settings Control Panel Services.
2 Stop and restart the Web server.
Installing Actuate e.Reporting Server 22
To achieve the best performance, Siebel Systems recommends that you install
Actuate e.Reporting Server on a different machine from the one on which Actuate
ReportCast resides.
To install Actuate e.Reporting Server

1 Insert the Siebel Windows Server Programs CD-ROM into your CD-ROM drive.
2 Navigate to the following directory:
\Thirdpty\language\actuate\ntserver
3 Double-click SETUP.EXE.
4 Read the Welcome screen and click Next to continue.

The software license screen appears.
5 Read the license screen and accept the license conditions by clicking Yes.
The Choose Destination Directory screen appears.
The installer will place the e.Reporting Server files by default in the following
directory:
C:\Actuate4\Server

6 Accept the default or use the Browse button to navigate to another directory.
The installer copies the appropriate files to your computer.
The installer prompts you to specify an account name to use to start the services.
7 Type the account name and network password that you want to use. Click
Continue.
If you have not already set up this user account with logon privileges, the
installer prompts you with the following message:
The user specified does not have “LogOn as a Service”

privilege. The Actuate e.Reporting Services cannot start as
this user account without this privilege. Do you want to grant
this privilege to this user?
8 Click Yes.
The installer prompts you as to whether or not you want Actuate e.Reporting
Server to start automatically whenever you log on.
9 Indicate your preference:

To confirm automatic logon, click Yes.
To choose manual logon, click No.
The Actuate e.Reporting Server Email Registration screen appears.
10 On the Actuate e.Reporting Server Email Registration screen:

a Select the Profile (email account name) for the user account from which
Actuate e.Reporting Server sends email notification.
b Type the password for the email account of that user.

c Click OK.
The text editor application to which your system defaults, such as Notepad,
launches a screen to display the contents of a text file.

11 Follow the instructions described in the text file and close the file when finished.
After a number of informational screens, the Setup Complete screen appears and
prompts you as to whether you want to reboot your computer now or later.
12 Indicate your preference and click Finish.
Starting Services
After setup has finished installing Report Server, on Windows NT, follow the
instructions below to start services.
To start e.Reporting Server services

1 If you did not restart your machine after you installed e.Reporting Server, do so
now.
2 From the Windows NT Start menu, choose Settings Control Panel Services.
3 Start the following services:
Actuate Administration Server 4
Actuate Persistent Object Server 4
Actuate Request Server 4

Installing Siebel Report Server Access 22
Install Siebel Report Server Access on the same host on which you installed Actuate
e.Reporting Server to enable communication between e.Reporting Server and the
Siebel Server.
To install Siebel Report Server Access

1 Navigate to the rptsrvr directory on your Siebel Windows Server CD-ROM.
2 Double-click the Setup.exe file.
3 Read the Welcome screen and click Next.

4 Specify the destination directory for the Web Engine and .COM Applications.
The default directory is C:\sea6xx\rptsrvr.
To accept the default directory, click Next.
To specify a different destination directory, click Browse.
If you specify a directory other than C:\sea6xx\rptsrvr, make the

appropriate substitutions throughout the remainder of this section.
The Setup Status screen appears and the installer proceeds to install all required
files.
When Setup has installed all required files into the directory, the Event Log
screen appears.

6 Click Finish.
This concludes installation of Siebel Report Server Access.

Importing Siebel Report Files to the Report Encyclopedia

After you install Siebel Report Server Access, you must import a number of Siebel
Report executable files to the Report Encyclopedia.
To import Siebel Report files

1 Navigate to the Windows NT Start menu and choose Settings Control Panel
Services.
2 Stop the following services:

Actuate Administration Server 4
Actuate Persistent Object Server 4
Actuate Request Server 4
3 Open an MS-DOS command prompt window and navigate to the directory in

which you have installed Siebel Report Server Access.
The default directories are:
C:\Actuate4\Server (for the Actuate e.Reporting Server)
C:\sea6xx\rptsrvr (for Siebel Report Server Access)
In the following instructions, the Actuate e.Reporting Server default directory

will be referred to as AC_SERVER_HOME.
4 At the DOS prompt, enter:

AC_SERVER_HOME\bin\acimport -home AC_SERVER_HOME
-if “Siebel Reports/enu” -force -input reports\reports.acf
5 Enter:
exit
If the import was successful, no message appears, but you will see a list of report
executable files that were imported.
If error messages appear, refer to Chapter 5 of the Actuate e.Reporting Server

Guide for troubleshooting procedures, available in .pdf format on the Siebel
Bookshelf.
6 Restart the e.Reporting Server services that were stopped in Step 2.

Configuring ReportCast Web Server Extensions

These files are automatically installed as part of your installation of Siebel Report
Server Access. They control the location of the default directory for your Web server
extension.
To configure your ReportCast Web server extensions

1 Navigate to C:\sea6xx\rptsrvr\rptcast.
2 Copy rptcast.zip to the directory of the host where Actuate ReportCast resides
and unzip the files.
If you are using IIS as your Web server, the directory path will be similar to
the following example:
C:\Inetpub\wwwroot\Actuate\Default
If you are using iPlanet Web Server as your Web server, the directory path
will be similar to the following example:
C:\Netscape\SuiteSpot\docs\Actuate\Default
Reloading Template Files

Changes to the template files are not reflected in the HTML pages generated
immediately. To see the updated versions of the template files, you must reload
them from the Administration page of ReportCast.
NOTE: Only users with administrative privileges can access the ReportCast
Administration page.

To reload the templates

1 Access the ReportCast Channel Administration page by typing the URL
http://webserver/acw/report_server on the command line of your
browser, where webserver is the name of the machine that runs your Web
server.
Alternatively, you may also navigate to

http://webserver/acweb/__admin.
2 Choose the Administration tab.

The ReportCast Channel Administration page appears.
3 Click ReportCast Administration, located in the left menu.

The ReportCast Administration page appears.
4 Click Reload Templates.

If the templates reload successfully, the Confirmation page appears.
NOTE: If the Confirmation page does not appear, verify that the connection to
your Web server is still active.
5 Verify that your changes took place by displaying any ReportCast page.

Installing Actuate Administrator Desktop 22
Actuate Administrator Desktop offers users the added capability of managing one
or more Actuate e.Reporting Servers and Report Encyclopedias, and of controlling
user privileges.
You can install Actuate Administrator Desktop in any machine on your network.
NOTE: Installation of Actuate Administrator Desktop is not required to run Siebel

Report Server.
To install Actuate Administrator Desktop

1 Insert the Siebel Windows Client CD-ROM into your CD-ROM drive.
\Thirdpty\language\actuate\adt
3 To install Administrator Desktop, double-click SETUP.EXE.

The Welcome to Actuate Administrator Desktop Setup screen appears.

The License screen appears.
5 Read the License screen and accept its conditions by clicking Next.
The Choose Destination location screen appears.
6 Accept the default directory (C:\Actuate4\adt) or use the Browse button

to select another directory.
The progress bar appears and shows the status of file installation.
7 Indicate whether you want to restart your computer now or later, and then click
Finish.
This completes your installation of Actuate Administrator Desktop.

Installing Actuate Developer Workbench 22
Actuate Developer Workbench offers developers of structured content the added

capability of designing, building, and distributing report object designs and
components throughout the Enterprise.
You may install Actuate Developer Workbench on any client machine.
NOTE: Installation of Actuate Developer Workbench is not required to run Siebel

Report Server.
\Thirdpty\language\actuate\devwb
3 To install Developer Workbench, double-click SETUP.EXE.

The Welcome to Actuate Developer Workbench Setup screen appears.

6 Accept the default directory (C:\Actuate4\Devwb) or use the Browse button
to select another directory.
The Select Component screen appears, prompting you to choose which

components you want the installer to place in the specified directory. These
include the following:
ODBC. Triggers installation of the ODBC drivers. These are needed if you want
to run any of the sample reports.
Core System. Triggers installation of all executables and data files, except for
ODBC drivers and online help.

Online Help. Triggers installation of all online help files.
Each entry shows the amount of disk space it takes up on your drive.
By default, all are selected.
7 Clear any components that you do not want installed, and then click Next.
8 Indicate whether you want to restart your computer now or later, and then click
Finish.
This completes your installation of Actuate Administrator Desktop.

Installing Actuate e.Report Designer 22
Actuate e.Report Designer lets developers design and create reports, using its
graphical user interface.
You may install Actuate e.Report Designer on any client machine.
NOTE: Installation of Actuate e.Report Designer is not required to run Siebel Report
Server.
\Thirdpty\language\actuate\erd
3 To install e.Report Designer, double-click SETUP.EXE.

The Welcome to Actuate e.Report Designer Setup screen appears.

6 Accept the default directory (C:\Actuate4\Erd) or use the Browse button to
select another directory.
The Select Component screen appears, prompting you to choose which

components you want the installer to place in the specified directory. These
include the following:
ODBC. Triggers installation of ODBC drivers. These are needed if you want to
run any of the sample reports.
Core System. Triggers installation of all executables and data files, except for
ODBC drivers and online help.
Online Help. Triggers installation of all online help files.
Each entry shows the amount of disk space it takes up on your drive.
By default, all are selected.

7 Clear any components that you do not want installed, and then click Next.
Perform the following post-installation tasks to make Siebel Report Server available
for users and to confirm proper installation.
Enabling the Report Server for Use With a Client 22
This section describes how to modify Siebel client files, such as Sales.cfg,
Service.cfg, and Customer.cfg, in an ActiveX Thin Client deployment on a
server, or on a dedicated client to run with the Siebel Report Server.
To configure Siebel configuration files

1 Navigate to the destination directory where Siebel eBusiness configuration files
have been installed on the Siebel Server.
2 Locate the configuration (.cfg) file corresponding to the application that you
want to run with Siebel Report Server, and then double-click.

3 Using your default text editor, such as Windows Notepad, edit the following
parameters.
[Actuate Reports]
EnableReportServer = TRUE
ReportServerHost = Report Server host

ReportCastHost = Name of ReportCast host
RoxDir = /Siebel Reports/language/
(example: enu for US English)
ConnectString = siebel.tcpip://xxx/siebel/zzzOBJMGR/yyy
xxx = Name of your Siebel Gateway
yyy = Name of your Siebel Server
zzz = Type of Object Manager, for example:
SCCOBJMGR = Siebel Call Center Object Manager
SFSOBJMGR = Siebel Field Service Object Manager
SSVOBJMGR = Siebel Service Object Manager
SSEOBJMGR = Siebel Sales Object Manager

Testing Siebel Report Server on the Client 22
Perform the following tasks to confirm that you have installed Siebel Report Server
correctly.
To test Siebel Report Server

1 Launch any Siebel eBusiness application, for example, Siebel Sales.
The Logon screen appears.
2 Log on as SADMIN for your Siebel RDBMS.

The Main Menu appears.
3 From the left panel of the Main Menu, choose any view.
The selected view appears.
4 From the Reports Menu in the menu bar, choose any report.
The Run or Schedule for Later dialog box appears, prompting you as to whether
you want to generate a report now or schedule it for later.
5 Indicate that you want to schedule the report for later, specify the date, time, and
frequency, and click OK.
6 From the menu bar, choose Screens Report Server My Requests

Scheduled Request View.
The scheduled report appears in the view, indicating the scheduled date, time,
and other information.
If the report does not appear, check the order and location in which you installed
the Siebel Report Server components, as described earlier in this chapter.

Editing Repository Variables 22
To eliminate the potential for memory leakage, Siebel Systems strongly recommends
that the Report Server administrator edit two variables within the Windows
repository.
To edit these variables

1 From the Windows Start menu, choose Run regedit HKEY_LOCAL_MACHINE
SOFTWARE
Actuate Actuate Report Server 4.
If you do not find these variables at the location described above, you must
create them in Step 2 below. If the variables are present, proceed to Step 3.
2 After navigating to the path described above, right-click within the Data field in

the right panel and choose New String Value.
Type the appropriate variable name (AC_RECYCLE_OPERATION_SERVERS or

AC_FACTORY_SERVER_RECYCLE_COUNT).
Right-click to highlight the variable and select Modify.
In the Value data field, type the values shown below in Step 3.
3 Edit the following variables as shown below:

AC_RECYCLE_OPERATION_SERVERS=TRUE
AC_FACTORY_SERVER_RECYCLE_COUNT=100
4 Quit the Registry Editor dialog box.


Installing the Siebel Report Server
Under UNIX 23
Pre-Installation Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-2

Installing Actuate ReportCast . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-2
Installing Actuate e.Reporting Server . . . . . . . . . . . . . . . . . . . . . . . 23-4
Installing Siebel Report Server Access . . . . . . . . . . . . . . . . . . . . . . 23-5

Enabling the Report Server for Use with a Client . . . . . . . . . . . . . . 23-10

Installing the Siebel Report Server Under UNIX
About This Chapter
This chapter describes how to install the Actuate e.Reporting Server and Actuate
ReportCast, which are components of Siebel Report Server, under UNIX.
Pre-Installation Task 23
Before installing Siebel Report Server, make sure that you have installed,
configured, and started the iPlanet (formerly, the Netscape Enterprise) Web Server
or IBM HTTP Server, as appropriate.
Siebel Report Server Installation 23
Install Siebel Report Server in the order and location given for the programs
described below.
Installing Actuate ReportCast 23
This section describes how to install Actuate ReportCast under UNIX.
You should install Actuate ReportCast on the same machine on which your Web
server resides.

Installation Tasks
Read and, afterwards, perform the following tasks to complete installation of
Actuate ReportCast in a UNIX environment.
To install Actuate ReportCast under UNIX

1 Put the Siebel UNIX Server Programs CD-ROM in your CD-ROM drive, and mount
it, if necessary. Refer to the operating system documentation for instructions.
For the purpose of these instructions, this mount directory will be called mount
point.

Solaris
mount point/Thirdpty/language/actuate/reportcast/Sunos
where language is the language in which you purchased your Siebel eBusiness
Applications, for example, enu for U.S. English.
AIX
mount point/Thirdpty/language/actuate/reportcast/aix
3 For the remaining installation steps, refer to Installing Actuate ReportCast Release
4.1 for UNIX.
Running IBM HTTP Server With ReportCast

When you installed the Siebel .COM Applications, several scripts were generated for
use in starting and stopping IBM HTTP Server. If you use this Web server, you must
use these scripts rather than the IBM HTTP Server control scripts to start and stop
the Web server; otherwise, you will not be able to run IBM HTTP Server.
Use the following scripts to start and stop IBM HTTP Server:
startapa—Starts IBM HTTP Server.
stopapa—Stops IBM HTTP Server.

Installing Actuate e.Reporting Server 23
For best performance, Siebel Systems recommends that you install Actuate
e.Reporting Server on a different machine from that on which you installed Actuate
ReportCast and your Web server. Siebel Systems also recommends that you not
install Actuate e.Reporting Server on a host on which any other Siebel product
resides.
Installation Tasks
Read and perform the following tasks to complete installation of the Actuate
e.Reporting Server in a UNIX environment.
To install Actuate e.Reporting Server

1 Put the Siebel UNIX Server Programs CD-ROM in your CD-ROM drive, and mount
it if necessary. Refer to the operating system documentation for instructions. For
the purpose of these instructions, this mount directory will be called mount
point.

Solaris
mount point/Thirdpty/language/actuate/Sunos
AIX
mount point/Thirdpty/language/actuate/aix
3 For the remaining installation steps, refer to Installing Actuate e.Reporting Server
Release 4.1 for UNIX.
NOTE: During the installation process, bypass all prompts except the X Server
prompt by pressing ENTER.
An X Server is required for DHTML/HTML graphs and for all printing in Actuate
e.Reporting Server.

Installing Siebel Report Server Access 23
Siebel Report Server Access consists of libraries shared by the Actuate products to
enable communication with the Siebel Server. Siebel Report Server Access also
contains an archive of reports that a user with system administrator privileges must
import to the report encyclopedia in a later step, along with customized Siebel
templates to be used by Actuate ReportCast.
Installation Tasks
You must install Siebel Report Server Access within the same directory in which you
installed Actuate e.Reporting Server. For example, if you installed Actuate
e.Reporting Server into actuate_server_home, you would install Siebel Report
Server Access under actuate_server_home/lib. This location guarantees that
the Actuate e.Reporting Server will find the shared libraries at run time.
From here forward, to make installation steps easier to complete, we will refer to
the Siebel Report Server Access installation directory (actuate_server_home/lib
in our example above) as siebel home.

To install Siebel Report Server Access

1 Navigate to siebel home and, at the prompt, enter the following two
commands:
Solaris
uncompress -c mount point/rptsrvr/language/sol/install/bin.tar.Z | tar xvf -
uncompress -c mount point/rptsrvr/language/sol/install/omu.tar.Z | tar xvf -
AIX
uncompress -c mount point/rptsrvr/language/aix/install/bin.tar.Z | tar xvf -
uncompress -c mount point/rptsrvr/language/aix/install/omu.tar.Z | tar xvf -
2 Verify that you installed the Siebel shared libraries, archived reports, and the
customized templates of Actuate ReportCast correctly.
Solaris
siebel home/reports/reportsol.acf
siebel home/rptcast/rptcast_solaris.tar.gz
AIX
siebel home/reports/reports.acf
siebel home/rptcast/rptcast_aix.tar.gz
3 Set the following two environment variables in a suitable startup script for this
UNIX account.
For accounts using csh, tcsh, or other C-shell variants, edit the .cshrc file
and insert the following lines:
Solaris and AIX
setenv SIEBEL_HOME siebel home
setenv SIEBEL_PLATFORM sol
For accounts using sh, ksh, bash, zsh, or other Bourne shell variants, edit
the .profile file and insert the following lines:
Solaris and AIX
SIEBEL_HOME=siebel home
SIEBEL_PLATFORM=sol

4 After making sure that all required environment variables set will be available
to the Actuate e.Reporting Server startup scripts, restart Actuate e.Reporting
Server.
An easy way of resetting the variables is to log out and log into the UNIX account
you created for Siebel Report Server before restarting Actuate e.Reporting Server.
After you install Siebel Report Server Access, you must perform the following tasks:
“Import Siebel Report Server files to the Report Encyclopedia”

“Configure Actuate ReportCast Web Server Extensions” on page 23-8
“Reload Template Files” on page 23-8
Import Siebel Report Server files to the Report Encyclopedia
Before your users can use Siebel Report Server, you must import a number of Siebel
Report Server executable files to the report encyclopedia.
To import Siebel Report Server files to the report encyclopedia

1 Shut down the Actuate e.Reporting Server.
For instructions, see the Actuate e.Reporting Server Guide.
2 Navigate to siebel home and at the command prompt, enter:

Solaris
actuate_server_home/bin/acimport -home actuate_server_home -if \

“Siebel Reports/enu” -force -input reports/reportsol.acf
AIX
actuate_server_home/bin/acimport -home actuate_server_home -if \

“Siebel Reports/enu” -force -input reports/reports.acf
If you imported the files successfully, no message appears, but a list of imported
report executable files appears.
If error messages appear, refer to Chapter 5 of the Actuate e.Reporting Server

Guide for troubleshooting procedures. This book is located in .pdf format on
the Siebel Bookshelf.
3 Start the Actuate e.Reporting Server by entering:

$AC_SERVER_HOME/bin/start_srvr.sh

Configure Actuate ReportCast Web Server Extensions

The customized Actuate ReportCast templates should overwrite the ones installed
automatically with Actuate ReportCast. The person performing this configuration
should have system administrator privileges.
To configure Actuate ReportCast Web server extensions

1 Navigate to the following location:
Solaris
netscape home/suitespot/docs/actuate/default
where netscape home is the directory into which you installed your iPlanet
Web Server.
AIX
ReportCast/actuate/templates/default
where ReportCast is the directory into which you installed your Web server.
2 Enter:
Solaris
gzip -dc siebel home/rptcast/rptcast_solaris.tar.gz | tar xvf -
AIX
gzip -dc siebel home/rptcast/rptcast_aix.tar.gz | tar xvf -
Reload Template Files

Changes to the template files will not immediately be reflected in the HTML pages
you generate. To see the updated versions of the template files, you must reload
them from the Channel Administration page of Actuate ReportCast.
NOTE: Only users with administrator privileges can access the Actuate ReportCast
Administration page.

To reload the templates

1 Navigate to the ReportCast Channel Administration page by entering the
following URL on the command line of your browser.
If you are not using CGI:
http://webserver/acweb/report_server
where:
webserver = the name of the host on which your Web server resides
report_server = the name of the host on which Actuate e.Reporting Server

resides
If you are using CGI:
http://webserver/cgi_directory/nph-actuate.cgi/acweb/
report_server
where:
webserver = the name of the host on which your Web server resides
cgi_directory = the path to the directory where CGI programs reside
report_server = the name of the host on which Actuate e.Reporting Server

resides
Alternatively, you may also navigate to the following URL.
If you are not using CGI:
http://webserver/acweb/__admin
If you are using CGI:
http://webserver/cgi_directory/nph-actuate.cgi/acweb/__admin

2 Click Reload Templates.

If the templates reload successfully, the Confirmation page appears.
NOTE: If the Confirmation page does not appear, verify that your Web server
connection is still active.
3 Verify that your changes took place by displaying any Actuate ReportCast page.
Perform the following post-installation tasks to make the Siebel Report Server
available to users and to confirm proper installation:
“Enabling the Report Server for Use with a Client”

“Testing Siebel Report Server on the Client” on page 23-12
Enabling the Report Server for Use with a Client 23
This subsection describes how to modify Siebel client files, such as Sales.cfg,
Service.cfg, and Customer.cfg, in an ActiveX Thin Client deployment on a
server, or on a dedicated client to run with the Siebel Report Server.
To configure Siebel configuration files

1 Navigate to the destination directory where Siebel eBusiness configuration files
have been installed on the Siebel Server.
2 Locate the configuration (.cfg) file corresponding to the application that you
want to run with Siebel Report Server, and then double-click.

3 Using your default text editor, such as Windows Notepad, edit the following
parameters.
[Actuate Reports]
EnableReportsServer = TRUE
ReportServerHost = Report Server host
ReportCastHost = If you are not using cgi:

Name of ReportCast host
= If you are using cgi:
Name of ReportCast host/cgi_directory/
nph-actuate.cgi
where cgi_directory is the path to the directory

where the cgi programs reside.
RoxDir = /Siebel Reports/language/

(example: enu for U.S. English)
ConnectString = siebel.tcpip://xxx/siebel/zzzOBJMGR/yyy
xxx = Name of your Siebel Gateway
yyy = Name of your Siebel Server
zzz = Type of Object Manager, for example:
SCCOBJMGR = Siebel Call Center Object Manager
SFSOBJMGR = Siebel Field Service Object Manager
SSVOBJMGR = Siebel Service Object Manager
SSEOBJMGR = Siebel Sales Object Manager

Testing Siebel Report Server on the Client 23
Perform the following tasks to confirm that you have installed Siebel Report Server
correctly.
To test Siebel Report Server

1 Launch any Siebel eBusiness application, for example, Siebel Sales.
The Logon screen appears.
2 Log on as SADMIN for your Siebel RDBMS.

The main menu appears.
3 From the left panel of the main menu, choose any view.
The selected view appears.
4 From the Reports menu in the menu bar, choose any report.
The Run or Schedule for Later dialog box appears, prompting you as to whether
you want to generate a report now or schedule it for later.
5 Indicate that you want to schedule the report for later, specify the date, time, and
frequency, and click OK.
6 From the menu bar, choose Screens Report Server My Requests

Scheduled Request View.
The scheduled report appears in the view, indicating the scheduled date, time,
and other information.
If the report does not appear, check the order and location in which you installed
the Siebel Report Server components, as described earlier in this chapter.

Uninstalling Siebel eBusiness
Applications Part 7
Chapter 24. Uninstalling Siebel eBusiness Applications

Uninstalling Siebel eBusiness Applications 24
Uninstalling Siebel eBusiness Applications Under Windows NT . . . . . . 24-2
Uninstalling Siebel eBusiness Applications Under UNIX . . . . . . . . . . . . 24-4
Migrating to a New Software Version or a New Database Platform . . . . . 24-4

Uninstalling Siebel eBusiness Applications
About This Chapter
The method for uninstalling Siebel products has changed in version 6.x. This
chapter describes how to uninstall Siebel products under Windows NT and UNIX.
Uninstalling Siebel eBusiness Applications Under

Windows NT 24
Uninstallation of Siebel products follows the standard Windows NT uninstallation

process.
To uninstall Siebel Server components on your system

1 From the Windows Start menu, choose Settings Control Panel Services.
2 Make sure that the Siebel Gateway Server is started.
NOTE: If you do not want to delete the Siebel Server, skip ahead to Step 5.
3 Stop the Siebel Server, and then close the Services dialog box.
Do not quit the Control Panel yet.
4 From the Control Panel, double-click Add/Remove Programs.

5 Scroll down the list on the Install/Uninstall tab of the Add/Remove Programs
Properties dialog box until you find the Siebel program that you want to remove.
NOTE: You must always uninstall the Siebel Server before uninstalling the Siebel
Gateway Server. Always uninstall the Gateway Server last.
6 Select the Siebel Server, or other component, and click Add/Remove.

Uninstalling Siebel eBusiness Applications Under Windows NT
7 Follow the remaining prompts from the uninstallation wizard until you complete
all screens.
Following uninstallation, you may either restart your machine immediately or

wait until you have finished removing other components. To remove other
components, repeat Step 6 on page 24-2 and Step 7 above.
8 If you are uninstalling the Siebel Gateway Server, first navigate to the Services
dialog box and stop the Gateway Server.
Repeat Step 6 on page 24-2 and Step 7 above for the Gateway Server.

10 After logging on, navigate to the drive where you originally installed the Siebel
Server components (for example, C:\sea6xx), and delete this directory.
This completes uninstallation of Siebel Server components.

Uninstalling Siebel eBusiness Applications Under UNIX
Uninstalling Siebel eBusiness Applications Under UNIX 24
Uninstalling Siebel under UNIX is a relatively simple process.
To uninstall the Siebel Gateway Server and Siebel Servers on your system
1 Stop all services.
2 Manually delete the installation directory and rc3 entries.
Migrating to a New Software Version or a New Database

Platform 24
When migrating either to a new version of Siebel software or to a new database

platform, refer to the instructions in the Siebel Upgrade Guide.

Deployment Planning Worksheet A
Appendix Overview A
The Deployment Planning Worksheet should be photocopied and a copy given to

each member of the deployment team. Please do not write on the master copy in
this Appendix—you will need to make copies of this master each time you install a
new Siebel Enterprise Server.
Version 6.3.1 Siebel Server Installation Guide A-1

Deployment Planning Worksheet
Master Worksheet
Master Worksheet A
Team Lead Summary A
Section 1: Deployment Team Members

Deployment Team Lead:
System Administrator:
Database Administrator:
Section 2: Deployment Overview

RDBMS Type:
DB2 UDB Microsoft SQL ServerDB2 Oracle

UDB for OS/390
Enterprise Server Info:
Server Name Type Owner # of Users Server OS
A-2 Siebel Server Installation Guide Version 6.3.1

Master Worksheet
Enterprise Server Names and Installation Directories A
(Make a copy for EACH enterprise you install.)

Section 3: Server Names
Network Host Name Installation Directory
Enterprise Server/Siebel Root:
Database Server:
File System Location and Path:
Gateway Server:
Central Dispatch Server (if applicable):
CORBA Object Manager (if applicable):
Siebel Server Name Network Host Name Installation Directory

Master Worksheet
Siebel Accounts, VIPs, and Static IPs A

Section 4: Siebel Account Information
Login/User ID Password
Service Owner/
Administrator:
Monitoring:
Section 5: VIP and Static IP Addresses

Default Gateway Subnet Mask
Gateway Server VIP
Static IPs for Siebel Servers

Server Name Static IP

Master Worksheet
Ports and RDBMS Details A

Section 6: Ports
Synch Manager Request Manager Object Manager
Section 7: General RDBMS Information

ODBC Data Source Name
Section 8: DB2 Universal Database Information

Tableowner Account Tableowner Account
DB2 Connect String Username Password
4-KB Data Tablespace 4-KB Long Tablespace 16-KB Data Tablespace Index Tablespace

Master Worksheet
Section 9: DB2 UDB for OS/390 Information

Alias Tableowner Account Username Tableowner Account Password
System Administrator Username System Administrator Password
SSE (default) User Group SSEEIM User Group

(Max. 8 char.) (Max. 8 char.) Dataset Name
4-KB Data Tablespace 4-KB Long Tablespace 16-KB Data Tablespace
Section 10: Oracle Information

SQL*Net Connect String Tableowner Account Username Siebel Index Tablespace
Tableowner Account Password Siebel Data Tablespace

DB2 UDB for OS/390 Tablespace and
Table Group Configuration Worksheet B
As you configure your DB2 UDB for OS/390 database for Siebel eBusiness
Applications, record the actual values for your system in the appropriate column in
Table B-1.
Table B-1 lists the parameters in the sample tablespace files (tbspaces.sql and
smalltbs.sql) and table group configuration files (tbspaces.ctl and
smalltbs.ctl), shipped with Siebel eBusiness Applications for DB2 UDB for
OS/390.
After choosing the sample file that matches your target database, edit it to replace
the default parameter names with the actual database object names that you use on
your DB2 UDB for OS/390 system and that you have recorded in Table B-1.
NOTE: The three number signs (###) in the first several object names represent a
three-digit numeric sequence, such as 001, that appears in the actual table name.
Table B-1. DB2 UDB for OS/390 Tablespace and Table Group Configuration File Parameters (1 of 3)
Name as It
Appears in
Object Description Shipped Table Actual User Value
Tablespace for row-level logging tables. (Very high transaction rates.) AAAAA###
Tablespace for large tables that require their own 4-KB tablespace. BBBBB###
Tablespace for large tables that require their own 16-KB tablespace. CCCCC###
Tablespace for smaller or medium tables for a 4-KB tablespace. Most DDDDD###
tables will belong in these tablespaces.
Tablespace for other tables that require a 16-KB tablespace. EEEEE###
Tablespace for any table that requires a 32-KB tablespace. Two such tables FFFFF###
exist in the default configuration.
Version 6.3.1 Siebel Server Installation Guide B-1

DB2 UDB for OS/390 Tablespace and Table Group Configuration Worksheet
Name as It
Appears in
Tablespace for interface tables used only by an EIM run. GGGGG###
Tablespace for repository tables. Most of these are read-only except when HHHHH###
a repository upgrade is underway.
4-KB bufferpool storage parameters. PPPPP04K
Index storage parameters: SSSSSSSS

Primary quantity
Secondary quantity
Can include the following clauses:
stogroup
bufferpool
vcat
priqty
secqty
erase
freepage
pctfree
gbpcache
B-2 Siebel Server Installation Guide Version 6.3.1

Name as It
Appears in
Tablespace storage parameters: UUUUUUUU

Primary quantity
Secondary quantity
Can include the following clauses:
stogroup
vcat
freepage
gbpcache
trackmod
Database for 16-KB tablespace XXXXX001
Database for 4-KB base tables XXXXX002
Database for EIM tables XXXXX003
Database for EIM tables XXXXX004
Database for repository tablespace XXXXX005
Database for base tables XXXXX006
Database for logging tables with very high transaction rates XXXXX007

Version 6.3.1 Siebel Server Installation Guide B-3

B-4 Siebel Server Installation Guide Version 6.3.1

Index
A pre-installation tasks 10-3, 12-5, 15-3

Administration Guide 1-14 verifying LAN connectivity 7-6, 8-7
database server installation script
B review of software installation 12-9
bufferpools 9-12 database upgrade scripts
log files 10-22, 12-28, 12-31, 12-36,
C 15-15
DB2
caution, parameter order in Thin Client for
Administration Tasks Before Installing
Windows 19-5
Siebel 9-13
client, defined 1-6
allocating Space for Siebel Data 9-10
Compact Setup option, CORBA Object
allocating Sufficient Database Log
Manager installation 16-7
Space 9-11
configuration
buffer Pools 9-12
database 9-2, 11-2, 14-2
database configuration parameters 9-6,
of Resonate Central Dispatch 3-10, 4-10
9-8
connectivity, database software 7-3, 8-3,
database manager configuration
16-3, 17-4
parameters 9-6, 11-15
correspondence templates, putting on File
mirroring 9-11
System 10-28, 12-36, 15-21
updating statistics 9-15
CTI stored procedures 12-9
DB2 database
ctisim parameter 19-8
configuration parameters 9-6, 9-8
Custom Setup option, CORBA Object
DB2 Database Administration 9-13
Manager installation 16-7
DB2 log space, allocating sufficient 9-11
DB2 Universal Database for OS/390
D
Installation Guide 11-9
database
DB2/390
configuration 9-2, 11-2, 14-2
allocating storage space 11-8
DB2/390, about configuring 11-2
allocating sufficient log space 11-9
installation scripts 5-7, 10-4, 12-7, 15-4
bufferpool activation 12-13
layout 11-4
bufferpools 11-10
planning DB2/390 configuration 11-6
codepage 11-7
sizing 11-3
configuration 11-2
database installation scripts
configuration guidelines 11-6
installing 5-7
configuring the database server 11-13
Database Server
customizing Siebel for 13-4
importing repositories 10-23, 12-32,
database alias 12-5
15-16
database layout 11-4
installation 10-17, 15-10
Version 6.3.1 Siebel Server Installation Guide 1

Index
database object creation and table group configuration

validation 12-28 templates 12-17
database objects, creation of 12-13 tables 11-4
database sizing 11-3 tablespaces 11-7, 12-15
databases creation of 12-15 temporary tablespaces 11-4
development to production migration updating statistics 11-14
tasks 13-5 DB2/Connect 7-4
EIM tables 11-4 DB2/Connect installation 7-4
enhancing performance with ddl.ctl 10-15, 15-8
bufferpools 11-10 default
index key length 11-9 EIM user group name 11-13
indexes 11-4 Siebel user group name 11-13
installation CLIST 11-14 defaults
installation job stream $TIJUZ 11-14 overriding for tablespaces 10-15, 15-8
interface tables 11-4
log file review 12-28, 12-31, 12-36, 13-21 E
log space allocation 11-9 eapps.cfg file 20-12, 21-15, 21-16
logical device layout 11-5 editing configuration files
logs 11-4 thin client for Windows 19-5
migration of the repository from Enterprise Server, and network
development to production 13-10 connectivity 3-6, 4-6
parameters configurable by users 11-15 EXTENDED SECURITY parameter 11-15
partitioning tables 11-10, 11-11
physical device layout 11-5 F
Pre-installation configuration File System
tasks 11-13 and correspondence templates 10-28,
pre-migration tasks 13-4 12-36, 15-21
sample sql files for tablespace directory structure 5-4, 6-4
creation 12-15 populating 10-28, 12-36, 15-21
Siebel repository 12-32 setting up 5-4, 6-4
SSEEIM 11-13 verifying LAN connectivity 7-6, 8-7
SSEROLE 11-13
storage groups 11-7 G
storage groups, creation of 12-14 Gateway Server
Storage space allocation for tables and post-installation tasks 6-11
indexes 11-8
structure 11-6 H
synchronizing the production database HTML Thin Client
with the development network security 18-5
repository 13-18
system administrator username and I
password 12-6
IBM DB2 for OS/390 Installation
system checkpointing 11-9
Guide 11-13
table group configuration 12-17
icons
Siebel Server, described 7-18, 8-22
2 Siebel Server Installation Guide Version 6.3.1

Index
implementation N
process 2-5 network connectivity
imprep.ksh 12-32 and the Enterprise Server 3-6, 4-6
imprep.log 10-27 establishing for mobile users 7-19, 8-25
index key length network security
verifying and correcting 11-9 access outside firewall 18-2, 18-4
indexes firewall configuration 18-5
allocating storage space on DB2/ networks
390 11-8 verifying LAN connectivity 7-6, 8-7,
init.ora file 14-7 16-5, 17-4
install_siebel.ksh
location of 12-25 O
installation object validation script
Database Server 10-17, 15-10 editing of 12-29
File System 5-4, 6-4 execution of 12-30
process 2-5 Oracle database
Siebel Server 7-9, 8-9 administration 14-10, 14-12
skill requirements 1-2 configuration guidelines 9-2, 14-3
Installing 22-1, 23-1 configuration parameters 14-7
Interface table usage by EIM 11-4 post-installation
IP addresses recommendations 14-12
about 3-6, 4-6 space for Siebel data 14-9
tablespace allocation 14-9
J
Java Thin Client P
access outside firewall 18-2, 18-4 post-installation tasks
Enterprise Server 6-11
L Gateway Server 6-11
list of invalid objects report 13-5, 13-9 Resonate Central Dispatch 3-10, 4-10
list of invalid objects report script Siebel Server 7-18, 8-22
editing of 13-7 post-migration task 13-22
execution of 13-7 pre-installation tasks
log files Database Server 10-3, 15-3
install.bat 10-22, 12-23, 12-28, 12-31, Resonate Central Dispatch 3-2, 4-2
12-36, 13-21, 15-15
repository import 10-27, 15-20 R
RACF group for Siebel and EIM users 12-6
M RDBMS software
Microsoft SQL Server database verification 2-24
indexes 9-4, 14-5 Release Notes 5-6, 6-5, 7-2, 8-3, 16-3, 17-3
table indexes 9-4, 14-5 repositories, and log files 10-27, 15-20
Mirroring 9-11 repository importation script
MXTB 11-15 editing of 12-32
execution of 12-34

Index
repository migration script database connectivity software 5-6, 6-5,

editing of 13-10 7-3, 8-3, 16-3, 17-4
execution of 13-12 installing 7-9, 8-9
repository synchronization script post-installation tasks 7-18, 8-22
editing of 13-19 pre-installation tasks 7-2, 8-3, 16-3, 17-3
executing of 13-20 verifying prerequisites 7-2, 8-3, 16-3,
Resonate Central Dispatch 17-3
and Windows NT Accounts 3-3, 4-3 Siebel Server Administration Guide 1-14
configuring 3-10, 4-10, 4-13 Siebel Services
post-installation tasks 3-10, 4-10 starting 7-17
pre-installation tasks 3-2, 4-2 stopping 7-9
runstats 11-14 Siebel Tools Guide 1-14
smalltbs.ctl 12-17
S system administrator
S_DOCK_INIT_ITEM 11-14 user account 10-8, 12-10, 15-7
S_ESCL_LOG 11-14
security privileges 12-10 T
seed data importation script table group configuration file
editing of 12-24 updating 13-10
execution of 12-26 tableowner
setup.exe account creation 10-8, 12-10
Database Server scripts 3-9 tableowner and administrator
Siebel Server 7-9, 10-4, 12-7, 15-4, 16-7 accounts 12-10
Siebel Data Model Reference 11-14 tableowner/database owner account 12-5
Siebel database schema generation script tables
editing of 12-19, 13-15 allocating storage space on DB2/
execution of 12-22, 13-18 390 11-8
Siebel database schema, creation of 12-18, tbspaces.ctl 12-17
13-15 tclient.htm configuration file 19-4
Siebel database script syntax 12-19, 13-6 tclient.stc configuration file 19-4
Siebel database server script, installation templates
of 12-7 putting on File System 10-28, 12-36,
Siebel File System, population of 12-36 15-21
Siebel program Typical Setup option
database configuration 9-2, 11-2, 14-2 CORBA Object Manager
Siebel Server setup 7-2, 8-2 installation 16-7
Siebel Repository, loading into Siebel
database 10-23, 12-32, 15-16 U
Siebel schema import, log file update of table statistics 11-14
review 12-23 updating statistics, DB2/390 11-14
Siebel schema, creation of 12-22 Upgrade Guide 1-14
Siebel Server Using DB2/Connect with ODBCSQL 7-6,
8-6

Index
V
verification
Gateway Server 2-13
RDBMS software 2-24
Siebel Server 2-13
Siebel Server database connectivity
software 7-3, 8-3, 16-3, 17-4
Siebel Server prerequisites 7-2, 8-3,
16-3, 17-3
W
Windows NT Accounts, creating for
Resonate Central Dispatch 3-3, 4-3
Windows Thin Client
access outside firewall 18-2, 18-4
caution 19-5
editing configuration files 19-5
parameters order 19-5
tclient.htm 19-4
tclient.stc 19-4
Z
ZPARM
EXTENDED SECURITY 11-15
MXTB 11-15

Index

SRVR Inst

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRVR Inst

Uploaded by

Copyright:

Available Formats

SIEBEL eBUSINESS APPLICATIONS

Windows® is a registered trademark of Microsoft Corporation.

Chapter 2. Preparing for the Installation

Version 6.3.1 Siebel Server Installation Guide iii

Grouping Your Siebel Servers Into Siebel Enterprise Servers . . . . . . . . . . . 2-9

PART 1. Installing Central Dispatch and the Siebel

Chapter 3. Installing Central Dispatch Under Windows NT

iv Siebel Server Installation Guide Version 6.3.1

Chapter 4. Installing Central Dispatch Under UNIX

Chapter 5. Installing the Siebel Gateway Server

Chapter 6. Installing the Siebel Gateway Server Under UNIX

Version 6.3.1 Siebel Server Installation Guide v

Reviewing the Use of Connection Brokering . . . . . . . . . . . . . . . . . . . . . . . 6-5

PART 2. Installing the Siebel Server

Chapter 7. Installing the Siebel Server Under Windows NT

Chapter 8. Installing the Siebel Server Under UNIX

vi Siebel Server Installation Guide Version 6.3.1

Verifying Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

PART 3. Configuring and Installing the Siebel

Chapter 9. Configuring the DB2 UDB for UNIX

Version 6.3.1 Siebel Server Installation Guide vii

Log File Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12

Chapter 10. Installing the Siebel Database Server with DB2

Chapter 11. Configuring the DB2 UDB for OS/390

vii i Siebel Server Installation Guide Version 6.3.1

Database Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6

Chapter 12. Installing the Siebel Database Server with DB2

Version 6.3.1 Siebel Server Installation Guide ix

Chapter 13. Migrating Customizations From Development

Chapter 14. Configuring the Oracle Database Server

Chapter 15. Installing the Siebel Database Server with Oracle

x Siebel Server Installation Guide Version 6.3.1

Installing the Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-10

PART 4. Installing CORBA

Chapter 16. Installing CORBA Under Windows NT

Chapter 17. Installing CORBA Under UNIX

Version 6.3.1 Siebel Server Installation Guide xi

Setting Up the Object Request Broker in Persistent

PART 5. Installing and Configuring Siebel Thin Clients

Chapter 18. Thin Client Network Requirements

Chapter 19. Editing Siebel Thin Client for Windows Files

xii Siebel Server Installation Guide Version 6.3.1

Chapter 20. Installing and Configuring the .COM Applications

Chapter 21. Installing and Configuring the .COM Applications

Version 6.3.1 Siebel Server Installation Guide x iii

PART 6. Installing and Configuring the Report Server

Chapter 22. Installing the Siebel Report Server

Chapter 23. Installing the Siebel Report Server

xiv Siebel Server Installation Guide Version 6.3.1

PART 7. Uninstalling Siebel eBusiness Applications

Chapter 24. Uninstalling Siebel eBusiness Applications

Appendix A. Deployment Planning Worksheet

Appendix B. DB2 UDB for OS/390 Tablespace and

Version 6.3.1 Siebel Server Installation Guide xv

xvi Siebel Server Installation Guide Version 6.3.1

Who Should Use This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-2

How This Guide Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-3

What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-5

Additional Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-6

Contacting Siebel Technical Support . . . . . . . . . . . . . . . . . . . . . . . . Intro-7

Siebel Welcomes Your Comments . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-8

Version 6.3.1 Siebel Server Installation Guide I n tr o - 1