dsm adv topics r11

Unicenter®

Desktop and Server Mc® anagement

Advanced Topics R11.x

Legal Notice

This publication is based on current information and resource allocations as of its date of publication and is subject to change or withdrawal by CA at any time without notice. The information in this publication could include typographical errors or technical inaccuracies. CA may make modifications to any CA product, software program, method or procedure described in this publication at any time without notice.

Any reference in this publication to non-CA products and non-CA websites are provided for convenience only and shall not serve as CA’s endorsement of such products or websites. Your use of such products, websites, and any information regarding such products or any materials provided with such products or at such websites shall be at your own risk.

Notwithstanding anything in this publication to the contrary, this publication shall not (i) constitute product documentation or specifications under any existing or future written license agreement or services agreement relating to any CA software product, or be subject to any warranty set forth in any such written agreement; (ii) serve to affect the rights and/or obligations of CA or its licensees under any existing or future written license agreement or services agreement relating to any CA software product; or (iii) serve to amend any product documentation or specifications for any CA software product. The development, release and timing of any features or functionality described in this publication remain at CA’s sole discretion.

The information in this publication is based upon CA’s experiences with the referenced software products in a variety of development and customer environments. Past performance of the software products in such development and customer environments is not indicative of the future performance of such software products in identical, similar or different environments. CA does not warrant that the software products will operate as specifically set forth in this publication. CA will support only the referenced products in accordance with (i) the documentation and specifications provided with the referenced product, and (ii) CA’s then-current maintenance and support policy for the referenced product.

Certain information in this publication may outline CA’s general product direction. All information in this publication is for your informational purposes only and may not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA provides this document “AS IS” without warranty of any kind, including, without limitation, any implied warranties of merchantability, fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost investment, business interruption, goodwill or lost data, even if CA is expressly advised of the possibility of such damages.

Copyright License and Notice

This publication contains sample application programming code and/or language which illustrate programming techniques on various operating systems. Notwithstanding anything to the contrary contained in this publication, such sample code does not constitute licensed products or software under any CA license or services agreement. You may copy, modify and use this sample code for the purposes of performing the installation methods and routines described in this document. These samples have not been tested. CA does not make, and you may not rely on, any promise, express or implied, of reliability, serviceability or function of the sample code.

Copyright © 2007 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.

Contents

Chapter 1: Introduction

References ................................................................................... 1-1 Providing Feedback ........................................................................... 1-2

Chapter 2: Component Details

The Engine................................................................................... 2-2 Engine Startup ........................................................................... 2-4 Engine Tasks ............................................................................. 2-5

Managers .................................................................................... 2-9 Infrastructure Deployment Manager........................................................ 2-9 Common Object Manager.................................................................2-10

The MDB ....................................................................................2-11 MDB Installation .........................................................................2-12

Data Transfer Service (DTS)..................................................................2-14 DTS Transfers ...........................................................................2-15 DTS Components ........................................................................2-16

The Agent and DM Primer ....................................................................2-25 Report Extractor.............................................................................2-25

Architectural Overview ...................................................................2-26 Report Templates ........................................................................2-27 Communications .........................................................................2-29 Diagnosing Problems.....................................................................2-29

Web Admin Console (WAC)...................................................................2-31 WAC and AMS ...........................................................................2-32 Diagnosing Problems.....................................................................2-32

Web Services................................................................................2-33 Things to Note...........................................................................2-35 Diagnosing problems.....................................................................2-35

Chapter 3: DSM Explorer

Architectural Overview ........................................................................ 3-1 Diagnostic Tips ............................................................................... 3-2 Common Plug-in.............................................................................. 3-3 CCNF Plug-in ................................................................................. 3-5

September 2007 Contents iii

References

Reading Configuration Policies............................................................. 3-6 DM Deploy Plug-in ........................................................................... 3-8

Diagnosing Problems ..................................................................... 3-9 Directory Browser Plug-in.................................................................... 3-10

Directory Wizard ........................................................................ 3-10 Directory Synchronization................................................................ 3-11 Directory Browsing ...................................................................... 3-12

Asset Manager (AM) Plug-in ................................................................. 3-12 Software Delivery (SD) Plug-in............................................................... 3-16 Remote Control (RC) Plug-in ................................................................. 3-20

Things to Note .......................................................................... 3-23 OSIM Plug-in ............................................................................... 3-23

Chapter 4: CAF

What is CAF? ................................................................................ 4-2 OS Services ................................................................................. 4-5

Tracing .................................................................................. 4-5 Security ..................................................................................... 4-9

Authentication .......................................................................... 4-10 Encryption .............................................................................. 4-12 Authorization (Object Level Security) ..................................................... 4-13

Communication ............................................................................. 4-20 Streams ................................................................................ 4-20 The Messenger .......................................................................... 4-22

Chapter 5: Installation Topics

Infrastructure Deployment.................................................................... 5-2 Processes and Log files ................................................................... 5-4 Stage to and Deploy from Scalability Server................................................ 5-5 Diagnosis Tips ........................................................................... 5-6 Frequently asked Questions ............................................................... 5-7 Additional Considerations for r11.2 ........................................................ 5-8

Upgrading from a Previous Release........................................................... 5-12 Data Migration .......................................................................... 5-13

DSM and NAT ............................................................................... 5-20 Overview ............................................................................... 5-20 Scenario 1: Scalability Server as Proxy Router ............................................ 5-21 Scenario 2: Agent as CAM Proxy ......................................................... 5-25

iv Desktop and Server Management Advanced Topics Guide September 2007

References

Chapter 6: Startup and Configuration

What Happens at Startup? .................................................................... 6-1 Startup Under Windows ................................................................... 6-4 Startup under Linux....................................................................... 6-6

Infrastructure Configuration ................................................................... 6-8 Configuration Policy....................................................................... 6-8 Activating Computer Configuration ......................................................... 6-8 Enterprise and Domain Policies ...........................................................6-10 Property Storage ........................................................................6-10 Processes and Log Files ..................................................................6-14

Agent Registration...........................................................................6-15

Chapter 7: Software Scanning

Overview and Flow ........................................................................... 7-1 Processes and Log files ....................................................................... 7-3

A Closer Look at the Content Download Process............................................. 7-4 A Closer Look at the XML Generation Process ............................................... 7-5 A Closer Look at the Engine Transfer Process ............................................... 7-6 A Closer Look at the Scalability Server Transfer Process ..................................... 7-6 Using an Enterprise Server ................................................................ 7-8 A Closer Look at the Import\Export Utility .................................................. 7-8

Diagnosis Tips...............................................................................7-10

Chapter 8: Remote Control Connection

Overview and Flow ........................................................................... 8-1 Processes and Log files ....................................................................... 8-3 Getting the Address Book ..................................................................... 8-3 Getting the Authority List ..................................................................... 8-4

Centralized User Validation ................................................................ 8-6 Cached\Fail Safe Validation................................................................ 8-7

Connecting to the Desktop .................................................................... 8-7 Terminal Services Obstacles ............................................................... 8-8

Displaying Confirmation Dialogs ..............................................................8-10 Starting Remote Control .....................................................................8-10

RCConfig and RCTrace ...................................................................8-11 Diagnosis Tips...............................................................................8-11

September 2007 Contents v

References

Chapter 9: Delivering Software

Overview and Flow ........................................................................... 9-2 DTS Integration .......................................................................... 9-9

USD Shares................................................................................. 9-11 USD Directories ............................................................................. 9-12 USD Files................................................................................... 9-14 MDB Tables................................................................................. 9-15 Process, Trace and Log Files ................................................................. 9-16 Install Packages and Trace Files.............................................................. 9-18 USD Logical Process Flows and Log Files ...................................................... 9-19 Major Changes between 11.1 and 11.2 ....................................................... 9-22 Collecting Information for Troubleshooting.................................................... 9-23 Additional DTS Considerations ............................................................... 9-23

Chapter 10: OSIM

OSIM Architecture........................................................................... 10-1 Process and Log Files........................................................................ 10-4 Installation and Configuration................................................................ 10-5

Multiple Boot Server (BS) in a PXE broadcast network ..................................... 10-6 Prioritization of Boot Server with Remote Configuration .................................... 10-6

Image Prepare System (IPS)................................................................. 10-8 Example.................................................................................... 10-9

Create Boot Images ..................................................................... 10-9 Register DOS Boot Images.............................................................. 10-12 Create OS Image....................................................................... 10-13 Register the OS Image ................................................................. 10-14 Prepare the Target for Network Boot..................................................... 10-15 Boot the Target ........................................................................ 10-16 Change Selected PXE Target to Managed................................................. 10-16 Editing the Job Parameter............................................................... 10-16 Activate the OS Installation Job ......................................................... 10-17 Boot the Target to Execute the OS install job............................................. 10-17

Under the Hood ............................................................................ 10-18 Boot Image Tools and Templates ........................................................ 10-18 Template Files and OS Types............................................................ 10-22 Registering to Another Domain Manager ................................................. 10-27 Special Preparation for GHOST and PQIMG Based Images ................................. 10-28 Upgrade Procedure for OS-SD packages ................................................. 10-28 OSIM Domain Manager Plug-in .......................................................... 10-29 OS Installation Job States............................................................... 10-29

vi Desktop and Server Management Advanced Topics Guide September 2007

References

OSIM (CSM) Data Base Design...........................................................10-30 OSIM Database Objects and Relationships ................................................10-33 Boot Server Components ................................................................10-35

OSIM and CADSMCMD ......................................................................10-50 Architectural Overview ..................................................................10-51 Diagnosing Problems with CADSMCMD ...................................................10-52 TargetComputer command ..............................................................10-54 Enhancements/Changes.................................................................10-56 Example Scenarios......................................................................10-57

Glossary

September 2007 Contents vii

Chapter 1: Introduction

This guide provides a closer look at several key Unicenter Desktop and Server Management components and functions. It is intended to be used in conjunction with the product documentation and other supporting materials available through the Technical Support website.

This information is presented in a series of chapters and topics that cover product specific and shared aspects of Unicenter DSM. The chapters are intended to be self-contained and randomly accessible. Updates and revisions will be provided on an ongoing basis and will be clearly noted.

References The following additional documents are referenced and should be consulted for further details:

Unicenter DSM r11.x – Implementation Guide

Unicenter DSM r11.x – Release Impact Guide

Inside Guides for Asset Management, Software Delivery and Remote Control

Product Readme files and online HELP

The most up-to-date technical guidelines and tips can also be found on the CA Support Online website (http:\\support.ca.com). In addition, best practice guidelines for both Unicenter DSM and its underlying database (the MDB) can be found at the following link:

http://supportconnectw.ca.com/public/impcd/r11/StartHere.htm

Included on this site is the Unicenter Desktop and Server Management Diagnostics Guide which includes basic troubleshooting procedures and a list of common symptoms and solutions.

Following is the direct link to the CA Messaging Troubleshooting Guide which contains information on diagnosing problems with CAM and CAFT, common components used by Unicenter DSM:

http://supportconnectw.ca.com/premium/unicenter30/infodocs/TEC418063.pdf

Note that this document requires a login to the SupportConnect site.

September 2007 Chapter 1: Introduction 1–1

http://supportconnectw.ca.com/public/impcd/r11/StartHere.htm



Providing Feedback

Providing Feedback This is the first edition of the Advanced Topics Guide. This document was produced in direct response to many requests for additional details regarding particular functions and component interactions provided in DSM. Feedback is welcome and can be sent to the following email address:

[email protected]

All feedback will be reviewed and considered for inclusion in future updates of these materials. Updates will be posted as they become available. If you have a technical question or if you require a more immediate response, you should consider opening an issue through CA Technical Support.

1–2 Desktop and Server Management Advanced Topics Guide September 2007

mailto:[email protected]

Chapter 2: Component Details

This chapter takes a closer look at the following DSM components:

Engine

Manager

MDB

DTS

Agent

Report Extractor

Web Admin Console (WAC)

Web Services

Both the DSM Explorer (and its plug-ins) as well as CAF are discussed in later chapters due to the extent of the information provided.

Note that this is not an exhaustive list of components and details regarding additional components may be added in the future.

These topics are also discussed in the following documents:

Implementation Guide (notably “Chapter 1: Understanding Unicenter DSM”)

DSM HTML Help Web Services Reference Guide

You should also consult the following links on the Implementation Best Practices site for further information:

Working with the MDB (includes information regarding the MDB and CORA):

http://supportconnectw.ca.com/public/impcd/r11/MDBMain/MDB_Frame.htm

Working with your CMS Solution

http://supportconnectw.ca.com/public/impcd/r11/Unicenter/CMS_Frame.htm

Scalability Considerations (includes information regarding sizing and performance considerations)

http://supportconnectw.ca.com/public/impcd/r11/scalability/scalability_guidelines__udsm.htm

A full list of techdocs is also available from the following link:

September 2007 Chapter 2: Component Details 2–1







The Engine

http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp

The Engine The Engine is a multi-instance, multi-function, distributable component. Its primary focus is the maintenance of computers and related information. Logic is encapsulated into a number of Engine Tasks enabling them to be scheduled to run at regular intervals.

The DSM Engine supports the following tasks

Sector collect – inventory collection from Scalability Server

Data Replication – copying of key data between Domain and Enterprise databases

Dynamic Group Evaluation – Evaluation of the membership of non-static groups (e.g., query-based)

Query-Based Policy Evaluation – Evaluation of policy violators and execution of actions

Report Extractor Jobs – execution of scheduled report extractions

Query Evaluation – simple evaluation of a standalone query

Migration Sync – copy and transform of info from previous version implementations

Run Generic SQL

Run External exe

Architecturally, the Engine can be considered as part of the DSM Manager. Every DSM Manager contains at least one default Engine instance which is known as the “System Engine.” Additional Engine instances can be created on the primary DSM Manager machine or on other remote machines.



The Engine

Note: When a DSM Domain Manager is running on Linux with an Ingres MDB and the Enterprise Manager is running on Windows with MS SQL Server then a Windows Domain Engine is required for successful replication.

September 2007 Chapter 2: Component Details 2- 3

The Engine

The following diagram provides an overview of the different pieces that comprise the Engine:

amoDataClasses

sqlexec

cfnotcli

CMEngine

This includes the following:

CmEngine – responsible for server/manager registration, Enterprise/Domain linking and Server/Engine linking

cfnotcli – notification client side API

Sqlexec – generic database API

amoDataClasses – embedded library of data access classes

Engine Startup

Engine startup is comprised of the following tasks:

1. Engine started up by CAF

2. Instance name passed on command line

3. DSM Manager hostname read from comstore

4. Database Name, Type, Credentials and other details are obtained from Common Manager

5. Database is opened

6. Jobs assigned to Engine are read

7. Work begins!


The Engine

Engine Tasks

As noted earlier, key Engine tasks include the following:

Collection

Replication

Reporting

Migration

Evaluation of Polices/Dynamic Grouping

Licenses

Sector Collection

During Sector Collection the Engine basically does a READ and WRITE to a Scalability Server. When an Agent initially connects to a Scalability Server it submits a request to be created and it will store all information it would like to push to the database in a “collect” area on the Scalability Server.

When the Engine connects to a Scalability Server it first “verifies” the integrity of the Scalability Server (for example, does the Scalability Server contain all the information about the Assets that it is supposed to according to the database?). Next, it checks the “Request Area” (“new” area in UAM terms) to see if any assets have requested to be created. The Engine checks to see if those assets (or Users) already exist in the database and confirms that the Scalability Server information correctly identifies this Scalability Server (i.e., the one from which the information is currently being “collected”).

If the Assets are new to the whole system they will be created in the database and in the Scalability Server’s “Unit” area. This enables the agent to “find itself” the next time it connects to the Scalability Server.

Next, the Engine processes all the information provided by Agents in the “Collect” area. The information collected can take various forms:

Inventory (Hardware/template information)

Software inventory (Software Found based in signature files, heuristic found software)

Configuration Files (i.e. Autoexec.bat or other ini files configured to be backup by the UAM system)

Job Status

Module Status

Time Stamps (Last Execution date)

Usage (Metering) Inventory


The Engine

Relation information (between Computers/Users/Devices etc)

The information that is collected is then stored in the appropriate table in the MDB. For example:

Computer information is stored in the ca_discovered_hardware table and created in the common asset model using the CORA API.

User Accounts are stored in the ca_discovered_user table

User Profiles are stored in the ca_link_dis_hw_user table

Relationships (e.g. VMware host/guest) are stored in the ca_link_dis_hw table

Additional information for each of these items is also stored in the ca_agent and ca_agent_component tables.

When Computers are created in the ca_discovered_hardware table a call is made to CORA. CORA is responsible for maintaining the Common Asset Model and enables the integration between NSM, DSM and USVD/UAPM. One inventory table is set for each component while General/Common Inventory is stored in inv_generalinventory_item and inv_generalinventory_tree

Note: Additional information regarding CORA can be found in the “MDB Hardware Assets and CORA” document available from the following link:

http://supportconnectw.ca.com/public/impcd/r11/MDBMain/Doc/CORA_MDB_and_Assets_SC.pdf

New Inventory tables are generated in the MDB by the Engine when new inventory is collected.

Query and Dynamic Group Evaluation

The basic functionality of the Query and Dynamic Group Evaluation tasks have not changed significantly since the previous 4.0 release of Unicenter Asset Management. In r11, however, group definition details are stored in ca_group_def table in the MDB and the link between Group and Member (Computer, Users, etc.) is stored in the ca_group_member table.

Queries definitions are stored separately in the ca_query_def table.

Query based groups and policies are evaluated by the Engine based either on set time intervals or when the servers are processed.




The Engine

Replication

Replication functions utilize the following MDB tables:

Database triggers/procedures are kept in the auto_rep_version table

Creation of database triggers and procedures include the following:

– Update/insert on Ingres

– Delete on Ingres and MSSQL

Replication configuration information is kept in the ca_replication_conf

Replication status is kept in the ca_replication_status table

Replication deletion history is kept in the ca_replication_history

When the Domain is linked to an Enterprise, Domain information is maintained in the ca_n_tier table while Manager information is maintained in the ca_manager table. Data is owned either by the Domain or the Enterprise and records are only replicated one way. If a record is changed on the target it will be overwritten. The sequence is as follows:

Process deletes go from Domain -> Enterprise

Process updates go from Domain -> Enterprise

Process deletes go from Enterprise -> Domain

Process updates go from Enterprise -> Domain

To delete records select top 25000 * from ca_replication_history where table_name=’ca_agent’ and auto_rep_version > last_deleted

while (more records)

{

if (record owned by source database)

delete record in target database

last_deleted = record.auto_rep_version

next record

}

To update records select top 25000 * from ca_agent where auto_rep_version > last_updated

while (more records)

{


The Engine

if (record exist in target database)

update record in target database

else

insert record into target database

last_updated = record.auto_rep_version

next record

}

On SQL server the auto_rep_version field is of type timestamp. This field type is always automatically updated and it contains a unique value for the table.

On Ingres, however, this is a date type field and it is only populated when the triggers and procedures are created during linking. Furthermore, since the value is not unique some additional logic is implemented to make this work on Ingres.

To unlink a Domain from the Enterprise you need to:

Deregister assets on Enterprise

Remove replicated data based on ca_replication_conf

Remove database triggers and procedures

To support the process of computers roaming between Domains linked to the same Enterprise before a computer is replicated to the Enterprise the replication mechanism checks to see if there is already a computer listed with the same host uuid but from another domain. If one is found, it is deleted from the Enterprise and a record is added to the Enterprise history table. The replication mechanism also checks the Enterprise history to see if any of the roamed computers belongs to this Domain.


Managers

Managers There are two types of managers that will be discussed here: the Infrastructure Deployment Manager and the Common Object Manager.

Infrastructure Deployment Manager

The Infrastructure Deployment Manager (dmdeploy) controls the overall deployment mechanism and maintains status among other tasks. It is a CAF plug-in that can be stopped and started through the following command:

caf stop dmdeploy

caf start dmdeploy

Upon startup the Infrastructure Deployment manager generates public/private encryption keys if they are not already present. Old keys are retained, but can be generated afresh after removal – though this requires re-authentication. Encryption key generation is managed through the dmkeydat.pri and dmkeydat.pmr files which are found in the DMdeploy/bin/ folder. Dmkeydat.pmr must be transferred to the target systems before deployment can be achieved.

The deployment library is kept on the manager machine under the following locations:

For Windows: <PF>\CA\Unicenter DSM\Packages

For Linux: $CA_ITRM_BASEDIR/Packages

The \Public subdirectory contains the payloads which can be deployed (selectable in the wizard). The <PF>\CA\Unicenter DSM\Packages\Private folder contains the DMPrimer installation images and intermediate copies of payload data.

The DMAPI is used by deployment consumers, such as dmsweep and the Deployment Wizard, to communicate with the manager. All user-visible deployment functionality is driven through the API.

During installation, the software that is to be installed (i.e., “the payload”) is stored in the Deployment “Packages/Public” area on the Manager and subsequently staged on Scalability Servers. Only agents and servers are currently supported.

Deployment components are decoupled from payloads. In other words, you can “slot in” new versions or even new payloads without altering the DMDeploy software.

Payload configuration is managed through the dmdeploy.dat file which does the following:


Managers

Defines payload name and version

Defines the command line to use to install the payload.

Optionally defines CLI parameters which must be supplied by customer prior to deployment.

Since Dmdeploy.dat contents are processed “on the fly” by the Deployment Manager any changes that are made take effect for all subsequent deployments.

Common Object Manager

The Common Object Manager provides a set of core, prerequisite, fundamental services that all other Manager components build upon or use. It provides the following services:

API access to common objects shared across the products

Scalability Server registration and Engine linking

Domain Manager to Enterprise Manager linking

Examples of Common Objects include:

Computers

User Accounts

User Profiles

Managers

Servers

Domains

Groups

Engines

Queries

Companies

Software Categories

Software Definitions

Agents

Scalability Server Components

Manager Components

Agent Components

The Common Object Manager is implemented as a set of executables and shared libraries:


The MDB

This includes the following components:

cmRegister – server/manager registration, Enterprise/Domain linking, Server/Engine linking

cmObjectInterface – common object client interface

cmObjectManager – common object manager

am_api – amManager client side API

cmObjectDAI – Data Access Interface for common objects

Sqlexec – generic database API

amManager – provides access to common objects provided by amoDataClasses

amoDataClasses – embedded library of data access classes

The MDB The MDB schema provides a unified and extensible model for enterprise IT management (EITM). It contains both common tables and product-specific tables that were previously implemented in separate product databases. The MDB serves as the enterprise database for all CA products and acts as a primary reference point.


The MDB

The MDB schema includes the database objects used by CA products and their components. These include tables, columns, views, triggers, rules and procedures. The MDB manages operational and transactional data, as well as the analytical data used for intelligence and data mining.

The integration point for all products is the common asset. Common registration of assets is handled by the CORA API.

Depending on a company’s business needs, as well as its organizational and geographical structure, you can use a single MDB or multiple MDBs; both approaches utilize the same schema.

In DSM MDBs reside at the Domain Manager and the Enterprise manager levels, though they are not necessarily co-located on the same physical machine as the manager.

MDB Installation

Ingres is supported on Windows and Linux while MS-SQL Server is supported on Windows only.

Ingres Notes

When using an Ingres-based MDB, keep the following in mind:

Ingres will be installed by the DSM installer if not already installed


The MDB

The Ingres installer will itself install the MDB (setupmdb)

The DSM installer uses a response file to specify Ingres installation parameters

The Ingres installer (setupmdb) will set the MDB_SIZE=medium by default

MDB_SIZE is a configuration parameter which affects certain Ingres DBMS settings, such as DMF cache size, in an attempt to attain better performance based on expected load.

The MDB_SIZE setting can be changed but the actual physical hardware used must be capable of supporting the increased MDB size.

MDB patches are applied during the DSM installation if needed.

The following process is used when an Ingres-based MDB is installed on Windows:

1. The Install kit collects installation attributes (for example, which database server is to be used).

2. The Install kit uses the dbinfo.dll component to check certain prerequisites such as:

Has the MDB already been installed?

Is that MDB version OK?

Is MDB already initialized (in other words, has the DSM Domain already been installed)?

3. The Install kit calls the dsmMdbPatch.bat script to apply MDB patches provided by Support.

4. The Install kit calls a post_install.bat/.sh script to add a row into the ca_settings table that will be used as tag indicating that the MDB schema is OK.

5. The Install kit calls the dbDataAfterCopy.dll to initialize and populate the MDB with some basic content. The dbDataAfterCopy also sets the DB credentials to the comStore and the DSM is registered in the ca_application_registration table.

6. At the end of the installation the Install kit calls the data_install.bat script to load additional content, such as queries, report data and software definitions, into the MDB.

Note: It may take some time to load software definitions but this step is only done when the Asset Management component is installed.

The procedures used under Linux are very similar – the only major exception is that, under Linux, dbInfo and dbDataAfterCopyApl are processes and not libraries.


Data Transfer Service (DTS)

MS SQL Server Notes

If the MDB is to be installed under MS-SQL Server you must ensure that SQL Server already installed and properly configured before the MDB installation begins. The MDB schema will be installed automatically by the DSM installer.

During installation on MS SQL Server an additional library, mssqllogin.dll, is used to do the following:

Check if MDB is already installed

Create users (grant user access)

check server collation name

Note that if the MDB is installed on a machine that is remote from the Domain Manager, a trusted connection must be established between the two machines. One way to accomplish this is to have them reside in the same Windows domain.

Data Transfer Service (DTS) The Data Transfer Service (DTS) is used by Software Delivery to manage the distribution of software through the network.

In USD terms a “USD job” is a “DTS transfer job” and the targets of those jobs are considered “DTS Transfers.” In the following screen shots you can see how DTS appears in the UI (the image on the left is r11.1 and the image on the right is from r11.2):



DTS Transfers

DTS supports the following types of transfers:

Fan-out (read once and send to many)

USD transfers will resolve to a transfer job. Fan-out reads the source data once and sends it to each of the targets.

This type of transfer requires that the following properties be identical:

– input data

– output data

– initiating machine identity

– initiator security tokens. In other words, the initiator User and Password are the same for each transfer.

– responder security tokens. In other words, the responder User and Password are the same for each transfer.

– Read Parcel and Read File filters

– Parcel Size



Broadcast/Multi-cast

This type of transfer requires WorldView to be configured. Broadcast/Multi-cast similar distributions are similar to fan-out distributions, however, the data is sent to targets using bcast/mcast processes

Point-to-point

This type of transfer is usually used when there’s only one transfer in a transfer job.

You can use the DtsCli to view and monitor the transfers. For information on command syntax, execute the following:

Dtscli –h

Useful commands for monitoring and debugging purposes are:

dtscli –t method=status id=TheId

dtscli –t method=status id=TheId method_parameters=implementation

dtscli –j method=status id=TheId

dtscli –j method=status id=TheId method_parameters=implementation

dtsCli –j method=status id=TheId method_parameters=transfers

DTS Components

DTS consist of the DTS Transfer Agent, DTS Command Line Interface (DTSCLI) and three “servers” – the Network Object Server (NOS), Transfer Object Server (TOS) and Schedule Object Server (SOS) – that are distributed across the DSM r11 architecture as follows:



Here you can see the individual processes and log files and log files used by these components:

Transfer Object Server (TOS)

DTS is implemented around an object model. These are the objects controlled by the Transfer Object Server (TOS).



The client tells the TOS to create, manage and activate transfers and jobs. Session messaging is used (previously it was TCP) as is encryption, compression and certificates.

DTTransferGroup This class of object defines a group of transfers that are to be controlled together.

DTTransfer Fully defines a single data transfer from one computer to another.

DTFilter Specifies how data is to be read or written and also any processing that should be performed on the data before or after the transfer.

DTS TOS is multi-threaded and uses information in DSM tables.

Network Object Server (NOS)

When a transfer job is activated the TOS contacts the Network Object Server (NOS) for the best route. Communication is managed via SM.

WorldView integration is used to model the network and to:

Define routes between machines

Set parcel size

Designate throttle factor

Select protocols other than TCP



Configure Multi-cast and Broadcast methods

This is the same functionality that was used in v3.0, however, note that it is not available in r11 or r11.1.

Modeling the network involves creating logical links among the network computers to satisfy data transport requirements. By default, when DTS is installed, it assumes that all computers are connected directly to one another. Not only is this unlikely to be the case (and this would, obviously, cause problems) more likely than not, it is not what is logically required anyway. Thus, the first task is to model the network to satisfy the logical requirements.

The first step is to analyze the DTS network topology in order to determine whether the data should be transferred directly between two machines or via one or more others (multi-hop).

DTS objects population can be done through:

Self discovery

– CCS objects are no longer automatically created

– DTS objects are automatically created, provided the associated CCS object exists

– IP addresses are not automatically updated in CCS

Auto discovery



Right click on the DTS BPV and select DTS Auto-discovery

Integration with WorldView includes the ability to associate a CCS Calendar with a DTLink. This can be used to specify when the link can be used – DTS will suspend and resume transfers based on when the calendar is enabled.

The use of Dynamic Containers is also provided through WorldView integration, which includes limited dynamic routing functionality.

In the r11.2 release you should note that:

The TOS’s route lookup is no longer synchronous

The TOS asks for the routes of all transfers in the transfer job, not just one at a time

The NOS can be responsive to other route lookup requests

The transfer job’s status at this time is: Calculating

DTS Transfer Agent

The DTS Transfer Agent consists of the following components:

Following are the methods by which the DTS Agent receives a transfer request, connects to the responder and performs the data transfer:



Communication between TOS and Agent (Initiator) occurs via Session Messaging. Encryption and compression are used.

Communication between the Agent and the TOS occurs via Session Messaging, Store and Forward.

Communication between the Agents uses the Networker by default, although other protocols can be configured via WorldView.

The Networker uses the port-multiplexer and provides encryption and compression capability. When sending control messages (for example, transfer requests), the Networker’s encryption and compression are used, however, when sending data, they are not.

The following Agent Filters are provided:

Read File Filter: Applied to the file before it is sent

Write File Filter: Applied to the file after it has been received

Read Parcel Filter: Applied to the data stream as it is being sent

Write Parcel Filter: Applied to the data stream as it is being received

Other DTS filters used by USD in DSM include:

Directory tree (file filter)

Encryption filters (these have to be configured)

External Filters include Sddtfilt which is a UD filter executed by DTS after the data transfer has completed.



The following types of intermittent transfers are supported:

Transfers to agents that are off-line

Transfer’s state change to Interrupted

Once the agent sends a message to the TOS (via the port multiplexer) that it has restarted, interrupted transfers are resumed. USD’s representation of the state is ‘active’.

Full support is provided for the transfers of large files. This includes files that are larger than 2GB, directories whose combined size is larger than 2GB or that contains files larger than 2GB. The file system, however, has to support large files. HP file systems, for example, can be mounted as 64 bit or 32 bit.



MDB Tables

Here you can see which MDB tables are used by DTS:

Event Management

The Common Eventing component is used therefore Dtaaudit.log is no longer employed. The Common Eventing component outputs to the following locations:

Program files\ca\dsm\logs\Events_n.log

Windows Event console

CCS Event console

Installation and Configuration

DTS is integrated into DSM configuration policy. The Tngdts.ini that was used to configure DTS in previous releases is no longer used except for legacy purposes. Further, the former DTS Administration client is no longer used.



If a previous DTS release is detected it will be upgraded. DTS is backwards compatible, however. Transfers between different agent versions are supported. In the event of a partial (“staged”) upgrade, for example, when there is a version 3 manager and agent followed by an r11 Agent install, only the agent will be upgraded.

During an upgrade, the install location is not changed. Otherwise, the DTS components will be installed as follows:

Program files\ca\sharedcomponents\dts

Program files\ca\sc\dts

\dta\status is used for the DTS Agent’s checkpoint restart files

\dta\staging is used as a temporary folder to hold data before file filters are applied

In r11.2 these directories are not below the DTS install location (Program files\ca\dsm\dts).

Log files are not kept in the DTS installation directory. Rather, they are installed in the Program Files\dsm\logs directory. This includes the following log files:

TRC_DtsAgent_n.log (Master DTS Agent)

TRC_DtsAgentx_n.log (Slave DTS Agent)

TRC_DtsTOS_n.log (TOS log)

TRC_DtsNos_n.log (NOS log)

TRC_DtsSos_n.log (SOS log)

TRC_DTS_n.log (Anything that uses the DTS API)

Sometimes it can be difficult to see the DTS trace messages. For example:

141206-13:48:25.0164333L|000548|00000b44|DtsAgent0

|CCFNetwork::Send|CCFNetwork.cpp |000885|DETAIL | m_encryptOn=<0>

MSGHEADER_GET_ENCRYPT=<0>

141206-13:48:25.0818844L|000548|00000b44|DtsAgent0 |dtsPWIEXT_Send_D|PWIEXT.c

|000566|DETAIL | 524318

141206-13:48:25.0821777L|000548|00000b44|DtsAgent0 |dtsEQP_Outstandi|eqp.c

|000400|DETAIL | Event <503> found in event queue for transfer <I1522leh>,

setting work to do flag

141206-13:48:25.2856018L|000548|00000b44|DtsAgent0 |dtsEQP_Process_E|eqp.c

|000295|DETAIL | Processing events for transfer <I1522leh>

Note, however, that all DTS trace statements have the function name (column 5) prefixed with “Dts”.


The Agent and DM Primer

The Agent and DM Primer DM_Primer handles payload transfer and payload installation execution.

dm_primer[.exe] (renamed from dmprimer.exe in V1)

It is installed in the following location:

<PF>\CA\Unicenter DSM\dmprimer or /opt/CA/UnicenterDSM/dmprimer

It is NOT a caf plug-in (because it installs CAF).

Primer install images are in the payload library, in the “Private” area (or possibly on an FTP server, mainly when deploying to *nix).

It can be installed automatically (pushed out by deployment manager) or installed manually (from DVD, login script, etc.). Information on manual install can be found in the Implementation Guide.

To establish connection with manager, an encryption public key must be obtained from the manager and placed in the expected location on the target. This proves that the deployment user has authority to install software.

Report Extractor The Report Extractor is a separate EGC plug-in that is used to:

extract data from the MDB into result tables

present the results in the GUI

print the results

export the results in a number of standard formats

provide data on demand (for example, for portals and web servers)

The Report Extractor plug-in is also used by the DSM Engine to generate result sets on a scheduled basis.

The implementation includes a large number of canned reports, covering all functional areas of the suite as well as extensive features for designing new reports and data extracts.

The inner workings of the reporter feature generic data extraction and handling based on tables, columns and links, but knowledge about the product’s data model or implementation is not necessary to use the Report Extractor.


Report Extractor

Architectural Overview

The following graphic depicts how the Report Extractor fits into the general architecture:

Database

Data Access

Application

User

MDB

AM Data Classes

EGC 3.0Print

Scheduled ReportsWin: gui_rep_exec.dll

Linux: lib_rep.so

Exportmodules

AM Manager Security

DSM Reporter GUIWin: gui_rep.dll

In this graphic yellow arrows represent data flow from the MDB to the UI, prints and exports.

Scheduled reports are initiated by the Engine, but neither the data nor the code is shared with the Engine. Scheduled reports run in Engine context, meaning that all data can be accessed. In the Reporter all security is applied at the time the data is viewed, printed or exported. All results are “complete”, no matter what user generates them. This is because the results can be viewed later and used by other users – under their own security settings - so the native result cannot be limited.

Under Windows the Report Extractor is implemented through the gui_rep.dll program which utilizes the following resources:

gui_rep_res.enu

gui_rep_htmlres.enu

Report Templates are maintained in gui_rep_template.enu and the Engine library for scheduled reports is implemented through gui_rep_exec.dll.

Under Linux the Engine library for scheduled reports is implemented through the lib_rep.so library.


Report Extractor

Report Templates

Reports are defined by their templates which contain information such as report name and description, a list of which fields are included, and how the data is supposed to be viewed. The Report Template does not contain data – it is only a recipe for generating results, which will, in turn, contain the current data. You can either use the report templates that are provided with the Reporter or create your own.

Report Templates are organized in a file-system-like folder structure, but this can be customized as well.


Report Extractor

Following is a model of report results:

Here you can see the sequence in which reports are generated:


Report Extractor

System Templates are installed silently, skipping existing templates whereas non-system template issue a prompt for overwrite. All templates in default contents should be System Templates.

Never use a text editor to edit a template definition in a text editor!

Import is controlled by the timestamp of the library file. The last import time is stored in registry as follows:

[HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\

Unicenter ITRM\Reporter\Library\<domain_id>]

When library file is newer, templates are imported. Already existing templates are not overwritten!

Communications

The Report Extractor communicates with the Manager using the manager address set in the comstore during installation. This value can be overridden through the following:

dsmreporter.exe manager:<manager_address>

Database connection information is obtained through the common manager. After that, direct database access is used.

Security implementation uses the AM Manager while Directory integration uses the common manager.

e (GUI or Engine box). To diagnose connection or start-up problems - consult the log files.

Diagnosing Proble

:

ents and dependencies. For a more concise reporter-specific log file, set reporter/AM at INFO level and others at WARN level:

cftrace set -f CSTACK -l WARN

cftrace set -f CF -l WARN

cftrace set -f CSTACK -mp "(Reporter|amlog)" –l INFO

Communication with a remote Ingres database requires installation of the Ingres Net client on the Reporter machin

ms

DSM trace logs are maintained in the following location

<dsm_install_dir>/logs/TRC_REPORTER_n.LOG

Specify the DETAIL log level for CF and CSTACK to get all information for infrastructure compon


Report Extractor

Prior to the r11 release, the Reporter used 3 log levels: Error, Warning and Information. In the r11 model, these have been mapped directly to ERROR,

,

icant information from AM Data Classes, while framework and stack output will be limited to errors and warnings. These

porter functionality because they give a precise, reporter-focused log file.

SQL statements. This enables input of additional log entries in the trace file for all ExecSQL, and most CRec

[HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\

For duration of SQL calls, add the following:

SqlTimer"=dword:00000001

he result in the If the Detail view is View defined for the

e reports. Set a break-in

WARN and INFO. The DETAIL level is not used by the Reporter. As a resultwhen the alternative settings listed above are used, you will get all Reporter information and all signif

settings are preferred when debugging Re

The follow are optional registry keys to log

record creations:

Unicenter ITRM\Reporter\Features]

"LogSql"=dword:00000001

"

If the data is either missing or wrong you should inspect tReporter, using the Detail view instead of the HTML view.correct, the problem may be related to the Custom HTMLreport template.

To inspect the raw data in result tables select the Results folder node to seetable names for the results, and inspect the table using DBMS tools. If raw data is correct, the problem may be related to the result data formatting.

Temporary tables are used for Directory and Softwarpo t to inspect them before they are deleted.



Web Admin CThe Web Admin Console (WAC) follows the MVC design pattern. It supports

s of

ically

the lder

On ess you

onsole (WAC)

and relies on several technologies to supply the implementation of portionthe design. The following graphic provides an architectural overview of WAC:

WAC is shipped as a WAR file “wac.war” (zip) which is expanded automatwhen Tomcat starts during the install. This enables DSM to modify configuration settings within the expanded files. This process is managed through WacAfterCopy .

Although Tomcat is installed into the common SharedComponents folderTomcat configuration files are installed into DSM’s own “Web Console” foand run up its own instance of Tomcat.

Tomcat compiles jsp files at runtime into the Web Console\work folder.occasion, if you modify jsp files the changes may not be picked up unldelete the work folder.

Online help is expanded from zip file in CVS and then compressed into wac.war file.



WAC and AMS

SM Explorer.

d

at is displayed by WAC. Web services are also used to retrieve Query results.

ller just calls AMS’s installer.

Diagnosing Proble

The most useful tool for diagnosing a problem with WAC is dsminfo. SetTrace batch files do not currently increase trace levels of AMS or main WAC log. The primary log file for WAC is:

NF\classes\com\ca\wac\log\waclog.log

Tomcat and isapi redirector logs can be found in the following location:

Detailed tracing for AMS is set through the following file:

enter DSM\Web Console\webapps\AMS\WEB-INF\classes\log4j.properties

jlog

C is defined through the following file:

INF\classes\com\ca\wac\config\waclog.properties

Change the lines that read:

log4j.logger.com=ERROR

AMS displays Discovered and Owned inventory and is launched embedded, and in context, in WAC and D

Web Services are used to create, configure, stop and restart software jobs anto retrieve product functionality based on what is installed on the manager (i.e., SD, AM or RC). This determines wh

A separate web application is installed by DSM installer into WAC’s Tomcat instance. The DSM Insta

ms

<install dir>\Web Console\webapps\wac\WEB-I

You can increase trace by setting the following in “waclog.properties”:

log4j.logger.com=DEBUG

<install dir>\Web Console\logs

CA\Unic

Change the following line:

log4j.rootCategory=ERROR, std

to read

log4j.rootCategory=DEBUG, stdjlog

Detailed tracing for WA

CA\Unicenter DSM\Web Console\webapps\wac\WEB-


Web Services

to read:

log4j.logger.com=DEBUG

Then, restart tomcat to pick up the changes for AMS and WAC:

caf start tomcat

Note: The folder path varies slightly on Linux.

Web Services Following is an architectural overview of the DSM Web Services on Windows

Web Server is used):

The mod_gsoap.dll originates from gsoap but has been slightly modified for use by DSM.

The Webservices api connects the gsoap layer to high level API layer which provides validation and parsing of the input.

The first step to using the Web Services is to login. Upon receipt of a login call the webservice api will establish a session to the high level api and will also manage the timing out of this session when it is not used.

caf stop tomcat

(when IIS


Web Services

Any errors raised by the high level API will be caught by the web service API and converted into a SOAP fault and sent back to the client.

The Highlevel API connects from webservices API layer to lower level client api’s. The primary purpose of this layer is to wrap the lower level API’s.

The purpose of the high level API is to present a standard interface to each of the lower level API’s. The high level API has no knowledge of web services etc. The interface is exposes is a C interface. The web service API layer is the bridge between the standard C high level API and mod_gsoap layer. The webservice API layer is gsoap dependent - in other words it uses gsoap constructs and is the layer called by gsoap.

When an HTTP XML message arrives at the web server it is routed to mod_gsoap.dll (via the url). The XML message (a Simple Object Access Protocol – SOAP) message gets converted into a function call onto Webservicesapi.dll.

The webservicesapi.dll performs any necessary validation and then calls the high level API function, which exposes a standardized C interface. This standardizes differences between lower layers.

b can see the runtime structure used by Apache is different than

that used by IIS.

Following is high level overview of the architecture on Linux using Apache WeServer. As you


Web Services

When a request is made Apache can deliver that request to any one of potentially many mod_gsoap.so processes. This helps improve scalability andreliability, however, in the web service, the state

is held internally. It holds

interface pointers to CO, SD and AM client APIs. Therefore, the current

Things to Note

All users connecting to the web service need to be authenticated.

When Unicenter DSM Web Services (Web Services) is installed on a machine running IIS 6 it will enable “IIS 5.0 isolation mode” within IIS 6 automatically. This is required in order for Web Services to function correctly. However, there is a slight risk that this change may adversely affect existing web applications.

Diagnosing problems

If you experience problems with the web services first verify that you can reach IIS and the gsoap layer. To do this under Windows type

http://<machine>/UDSM_R11_WebService/mod_gsoap.dll

You must use a GET request only for fetching WSDL ! see WebWare gsoap

webservice design relies on all requests for a session being directed to the same process. The above design solves this problem.

ISAPI module documentation for more details.

Then, type:

://<machine>/UDSM_R11_WebService http

Result…

mod_gsoap Apache SOAP Server Error

Only POST allowed as request for SOAP! Please see the documentation at WebWare for details.

This will establish that you have basic connectivity to the web server and gsoap layer. If this does not work then there is either a problem in IIS or in connectivity with gsoap

Check the webservice log file located in logs directory

Log filename is TRC_CF_WEBSERVICES_X.log


Chapter 3: DSM Explorer

This chapter takes a closer look at the DSM Explorer interface as well as the various plug-ins that are used. Additional details regarding other DSM components can be found in the previous chapter.


Implementation Guide (notably “Chapter 1: Understanding Unicenter DSM”)









Architectural Overview The DSM Explorer is a single EGC framework-based Admin GUI. It consists of the framework itself, a common plug-in and a number of product specific plug-ins. The DSM Explorer provides a homogenized view and operation of all DSM products in which no product separation is apparent. As DSM products are purchased and installed the GUI simply becomes richer and more powerful.

The EGC framework is a proven Win32 solution. It provides a basic tree/listview interface as well as numerous other common features. Product specific functionality is added via the concept of EGC plug-ins (DLLs which implement and exploit well defined programming interfaces).

The following graphic demonstrates the architecture that is used:

September 2007 Chapter 3: DSM Explorer 3–1






Diagnostic Tips

The EGC provides the basic explorer framework. This includes the treeview, listview, html view, tool bar, application menus as well as all the controls (widgets).

The plug-ins create and populate the controls. The Common plug-in provides the top level tree hierarchy and most of the cross product functionality (with the exceptions noted as blue/violet in the above graphic). All the other plug-ins add features and functions to the nodes, portals and menus that are provided by the common plug-in.

Visible functionality is controlled by the DSM components installed on the client and the manager

Diagnostic Tips Most plug-ins write to the standard DSM trace file which is: TRC_GUI_<n>.log

If you are experiencing problems with the DSM Explorer you will need to disable the plug-ins in order to isolate the problem. To do this, make the following modification:

HKLM\SOFTWARE\ComputerAssociates\EGC3.0N\Plug-ins\<Plug-in>

[DWORD] Plug-inEnabled = 0


Common Plug-in

To enable EGC Tracing edit the following:

HKCU\Software\ComputerAssociates\EGC3.0N\Trace

[DWORD] Enabled = 1

[DWORD] Level = 5

[STRING] Location=“C:\”

When you restart EGC the following files are created:

EGC3.0_<date>_<time>_<pid>_info.txt (modules loaded by EGC)

EGC3.0_<date>_<time>_<pid>_log.txt (trace information)

To display EGC node information select the node and press Ctrl+Alt+Shift+O

Common Plug-in The purpose of the common plug-in is to glue the product specific plug-ins together in a common tree and provide common functionality and features. It provides the following:

A hierarchical representation of common data

Basic management services like grouping of objects

Support to forward control to product specific plug-ins

Common menu handling

September 2007 Chapter 3: DSM Explorer 3- 3

Common Plug-in

HTML interface for displaying basic information from relevant sources / products.

Seamless connectivity and security across managers

The following nodes are provided by the common plug-in:

Here you can see an example of the UI dialogs provided by the Common plug-in:


CCNF Plug-in

CCNF Plug-in The CCNF plug-in manages the configuration policies for centralized security and default computer policies. Here you can see the nodes in the tree that are implemented by the configuration GUI:


CCNF Plug-in

Here is where you can see which configuration policies already exist and also where the user can create new policies.

Note: Policies have to be sealed before they can be applied, and have to be unsealed before they can be modified.

Reading Configuration Policies

To locate the default policy requesting a policy but leave the name blank. Giving the default policy a blank name at the manager allows the GUI to localise the display name for the default policy.

A GUI policy object is created for each policy that is found. For example:


CCNF Plug-in

The default policy contains all the managed settings while a user-defined policy, in this case the policy “Centralised Security”, only contains the sections that have been modified.

When a user-defined policy is unsealed the GUI displays all the available settings, so that it matches the default policy, but only the settings that are modified from the default are actually added to the policy.

These folders below the individual policy folders are called ParamSections.

Configuration Portal

Under each group and asset, you will find a configuration policy node.


DM Deploy Plug-in

When this node is selected an HTML page is displayed on the right hand side.

On the left it shows the policies that have been applied directly to this asset. In this example it is a policy call “UK Users”.

Below that it shows the policies that have been inherited. These policies have been applied to groups that this asset is a member of.

Details for the reported configuration that the CCNF agent returns from the agent computer can be viewed in a separate dialog.

A list of scheduled configurations is provided on the right hand side along with a list of any configurations which have failed.

In this example you can see a configuration that contains two policies. Because each contains different values for the same settings, the CCNF manager cannot determine which value to use – resulting in a conflict error. This error message instructs the user as to which parameters are causing the conflict so that the error can be remedied quickly.

DM Deploy Plug-in The DSM Explorer provides access to the enhanced deployment technology available in DSM r11. The access is presented in the form of a deployment wizard which itself is an EGC plug-in.

The Deployment plug-in implements the following two nodes in the DSM Explorer’s Control Panel:


DM Deploy Plug-in

When selected, a connection is made to the Deployment Manager, and a list of the available packages is retrieved and displayed for selection.

The wizard prompts for target information and allows the administrator to scan targets for suitability and to create deployment jobs.

The user can suspend the scan and go back to previous pages, but cannot move onto the next page in the wizard until the scan is complete.

The EGC plug-in that contains all the functionality is Gui_dm.dll while Gui_dep_res.en is the resource plug-in that contains all the localised resources, html file, graphics, strings etc.

Diagnosing Problems

Most of the current tracing for this plug-in is focuses on calls to the DmApi, so it is best to search for DmAPI function names such as DmPack, DmLogin, and DmStatus.

To diagnose problems use the following DmApi and DmDeploy log files:

TRC_CF_DMAPI_n.log (client api)

TRC_CF_DMDEPLOY_n.log (manager)


Directory Browser Plug-in

Directory Browser Plug-in The Directory Browser plug-in provides support for browsing directory hierarchies. It includes the following:

Directory wizard

Directory synchronization configuration

Directory browsing

This particular plug-in is used by other plug-ins to manage their directory browsing such as:

Query designer

Security profiles

Deployment

Reporting

Directory Wizard

The Directory wizard consists of eight HTML pages that are used to specify directory details including:

Directory name

Server (which it attempts to resolve from directory name)

Port – default 389

User credentials

Base DN (which it attempts to resolve from directory name)

Directory schema to use


Directory Browser Plug-in

It is also used to edit schema and create directory objects. Following is an example of the Add Directory function dialog:

Directory Synchronization

Directory synchronization controls consists of two HTML pages which can be used to modify the directory synchronization Engine jobs.


Asset Manager (AM) Plug-in

The user clicks Configure to change settings for job frequency and synchronization orders. These changes are saved in command line parameters for the Engine job.

Directory Browsing

This function provides directory browsing capabilities to other GUI plug-ins.

Asset Manager (AM) Plug-in The Asset Manager (AM) Plug-in provides both AM specific and common functionality. It manages:

Hardware Inventory

Software Inventory

Custom Software Definitions

Asset Jobs

Queries

Query and Event Based Policies

Engine Portal

External Assets

For example:



Here you can see the type of information provided:


Software Delivery (SD) Plug-in

Software Delivery (SD) Plug-in The SD plug-in is comprised of the following two files:

gui_sd.dll which contains all the functionality

gui_sd_res.en which is the English language locale. This contains the dialogs, icons and localized text

The SD plug-in provides the following controls:

Software Package Library

Software Jobs / Distributions

Software Policies

Delivery Engine

Software Job Management (configuration)

Here you can see the related controls on the DSM Explorer:



These controls are available through the Start menu as follows:



It includes the following menus:

Computer menu

User Profile menu

Asset Group menu

Server menu

Server Group menu

Domain menu

Here you can see an example of the Domain Portal:



It also includes the following wizards:

Software Deployment Wizard

Software Staging Wizard

Software Policy creation Wizard

Software Publishing Wizard.


Remote Control (RC) Plug-in

Remote Control (RC) Plug-in The RC plug-in is comprised of the following two files:

gui_rc.dll which contains all the functionality

gui_rc_res.en which contains the English language locale. This contains dialogs, icons and localized text.

Here you can see the controls that are added to the DSM Explorer:

This includes:

Active Sessions – This is a list of current sessions that this manager has authenticated.

Previous Session – A log of sessions that have now completed.

Root Address book permissions – An area to define RC permissions that will be applied to all computers in RC address book groups.

You can also define Remote Control Permissions on each group by adding users to the Remote Control Permissions folder within the group’s details section.



After a user has been selected, each of the following permissions can be set to “allow” or “deny.”

View

Stealth view

Classroom

Exclusive Control

Secure Control

Chat

Send Files

Receive Files



Require Local Confirmation

Record

Record on Host

You can also call up this Address Book properties dialog box by right clicking on the RC Permissions node and selecting Properties. From here you specify if the Group should be a remote control address book, and if you want it to inherit the Remote Control permissions of its parent.

There is also the option to “override permissions” on derived groups. This forces the same permissions onto the groups that this group contains, and all their subgroups.

This is accessed from the DSM Explorer menu as follows:


OSIM Plug-in

The computer context menu includes the following RC options:

Effective Settings – this allows you to see the RC permissions that have been granted for a specific user on a specific machine.

Connection Addresses - this allows you to view the addresses that this computer has reported it is listening on. You can add additional addresses also, and these will be added to the Address Books distributed to viewers.

Actions – including lock, unlock and reboot.

Things to Note

Take Control functionality is maintained in different plug-in: gui_rcView.dll.

OSIM Plug-in The GUI components for the OSIM plug-in are based on EGC 3.0 and Common Plug-in and include:

DSM Explorer nodes

Domain and Asset portal

Dialogs

Property Pages

OS Installation Wizard

Messages

Here you can see how the OSIM plug-in relates to the Common plug-in and Common API.


OSIM Plug-in

Here you can see an example of tree integration for Asset Groups dialog that is added by this plug-in:

The System Status Portlet identifies Failed Jobs (configurable), noting:

OS Image Installations, Image oriented

Erroneous Boot Servers (extremely rarely)


OSIM Plug-in

The overview Portlet includes controls for:

Software: current installed OS image

Jobs: planned and scheduled OS installations

Configuration: PXE managed

The OSIM plug-in implements the OSIM methods for the following CCSM database objects:

Computer, Bootconfiguration, Bootserver

BootParameter, Parametervalue

Bootdiskimage, BootOSimage

The APIs include:

CCSM API (mainly)

common API (special: make managed computer)


Chapter 4: CAF

This chapter provides a detailed discussion of the Common Application Framework (CAF) used by DSM, including information


Implementation Guide (notably “Chapter 1: Understanding Unicenter DSM” and “Appendix M: CAF Scheduled Jobs” DSM”)







The following techdocs also provide useful information:

“When installing R11.2 with Common Services how does it handle having existing versions of NSM components already installed on the server” (TEC426063)

“Configuration Policy to hide the System tray applet from users (TEC425430)

“Initialization failed error when the caf command is used at the UNIX console” (TEC422439)

Keep in mind that additional techdocs may be available after publication of this document. A full list of techdocs is also available from the following link:


September 2007 Chapter 4: CAF 4–1






What is CAF?

What is CAF? CAF provides a common, extensible runtime environment for all DSM program code. In its most basic form CAF provides the following general functionality:

Perceived single service

CAF runs as a single service on a computer and acts as the hub for all of the Agent, Scalability server and Manager processes. CAF does not make distinctions between the types of entities plugged into it. They all support the same basic interface and make use of the same common components.

Process control

CAF provides the following mechanisms for starting, stopping, pausing and restarting plug-ins:

– by networked API

– by command line (which calls API)

– by periodic start as defined by the scheduling component.

– By auto-restart. if a plug-in such as an agent fails and is terminated by the operating system, the framework can restart it (as defined by policy).

Messaging

An out of process messaging plug-in provides secure transmission of information. This is implemented using CAM. Messages can be routed directly to a process or to a plug-in via the framework's persistent process. In the latter case the framework will detect the intended recipient plug-in and route the message there via the plug-in's interface.

Stream communications with port multiplexing

Scheduling

An in-process scheduling plug-in can be used to start/stop other plug-ins or send messages to plug-ins.

Registration

An in-process registration plug-in is used to register end systems with a DSM Domain Manager via a Scalability Server, and basic inventory is collected and passed up during the registration process.

The CAF framework is dynamically extensible via the concept of plug-ins and the common component library (CCL).

CAF can be many things:

Periodic agent: running scheduler only. At given times it runs an agent via plug-in load/unload

Manager: It runs with a set of manager plug-ins and the messenger loaded, both persistently


What is CAF?

Remote control agent: It runs with the port multiplexer. When a URC viewer connects to it’s port, CAF starts up the URC host agent which then accepts the connection

Sector server: It runs with the AM Scalability Server plug-in running persistently

Much more: It runs with the AM metering agent, RC host, the registration plug-in, messenger and an AM Scalability Server plug-in, all loaded persistently

The major packages and components which are listed below are more fully described in other sections.

CAF: The DSM Common Service. To the user, this is the “CA Unicenter DSM r11 Common Application Framework” service. The service hosts the actual DSM Agents, Scalability Servers and Managers.

DSM Plug-in: a DSM plug-in is a component which contains DSM conformant functionality. A plug-in may also delegate the functionality to a “worker” process whose lifetime it manages.

Custom Plug-in: this is intended for any other functionality which is not strictly DSM conformant process.

September 2007 Chapter 4: CAF 4- 3

What is CAF?

DSM worker processes: the set of DSM processes covering Agents, Scalability Servers and Managers. These are managed by instances of the DSM plug-in. Note also that only a subset of Manager worker processes are dependent on the MDB.

Common Component Library (CCL): a set of components implementing shared, re-usable functionality, including: messaging, tracing, encryption, compression etc.

Common Config (CCNF): a component which accesses a store of configuration information. This is actually part of CCL but is shown separately here because it is critical to CAF. The config component provides a consistent means of getting and setting configuration values. The storage location of the values themselves is hidden from the client of the component. The values may be supplied at install time and may be locally or centrally managed.

Manager Proxy: this component is used to provide management capabilities for agents. It handles manager location, registration and commands sent by a manager (described elsewhere).

Scheduler: Manages scheduled execution of plug-ins.

Port MUX: the port multiplexer. This provides a single listening port for TCP and another for UDP connections. When a connection is made (for example, from the URC viewer), the multiplexer detects which plug-in the connection is intended for and gives it a new socket with which to continue. This allows multiple plug-ins to share the same port and is intended to make life easier for the customer when configuring firewalls.

Messenger: the messaging component. This is used for connectionless reliable and secure transfer of information. All messages from managers, GUI’s and command line tools use the messenger.

MDB: The common CA database. Only a subset of Manager worker processes uses this.

DSM Explorer: this is the common DSM admin GUI. It provides a single view of the DSM system.

System Tray Applet: This provides a single icon on the system tray and allows the user to see the status of CAF and issue some commands.

CLI: this is supported by caf.exe itself and is used by administrators to start, stop or interrogate plug-ins and consequently any worker processes they are associated with them. The command line sends messages to the service using the messenger component.

On Windows CAF runs as a windows service (CAF.EXE) called the “CA DSM Common Application Framework” while on Linux\UNIX it runs as a daemon (caf).

CAF provides a command line which allows administrators local and remote access to CAF functionality. The syntax is as follows:


OS Services

caf command [options … | arguments ...] [output | append filename]

Please refer to the CA Unicenter DSM r11 Implementation Guide for full details of the CAF command line options.

OS Services In addition to communication (messaging and networking) CAF provides the following OS services:

Tracing

Security

Localization

Configuration

Compression

Encryption

Basic Inventory

Common Utilities

XML Parser

Directory Integration

Event Logging

All common components are built using a straightforward, proprietary component interface and take the form of DLLs that can be dynamically loaded and unloaded as and when required.

Backward compatibility is provided for interface versions. CAF checks that the version the client wants is the one that a component offers. Old interface versions can also be offered so that changes to the interface do not break clients compiled with the older versions.

Tracing

The syntax for running a CAF trace is as follows:

cftrace –c set –f <product> –pp <processorpplug-in> –l DETAIL –s <tracefilesize

>

where:

<product> = UAM, USD, URC, DTS, CSTACK or CF

<processorplug-in> = See table below


OS Services

tracefilesize is size of file in Kb before it flips.

For example:

cftrace –c set –f UAM –l DETAIL –s 30000

Sets detailed tracing on for all Asset Management-specific components and a log file size of 30Mb, which flips and cycles when full so the total amount of data captured will be approx 60Mb.

Valid values for <processorplug-in> are listed in the following table:

CAF Plug-in Binary Processor Plug-in Log file

- CAF CAF_CMD TRC_CF_CAF_CMD.log

- Caf CAF_CMD TRC_CF_CAF_CMD.log

- CAF CAF_SERVICE TRC_CF_CAF_SERVICE.log

- cafC CAF_SERVICE TRC_CF_CAF_SERVICE.log

systray cfSysTray SYSTRAY TRC_CF_SYSTRAY.log

ccsmagt - Ccsmagt TRC_CSMAGENT.log

ccnfagent ccnfAgent CcnfAgentWorker TRC_CCNFAGENT.log

pmux (lib) cfPmuxPlugin cfPmuxPlugin TRC_CFPMUXPLUGIN.log

smserver Cfsmsmd CFSMSMD TRC_CF_CFSMSMD.log

- Dmscript DMSInterpreter TRC_DMSINTERPRETER.log

cfnotsrvd Cfnotsrvd Cfnotsrvd TRC_CF_NOTSRVD.log

cfftplugin cfFTPlugin cfFTPlugin TRC_CF_FTPLUGIN.log

cfregister (lib) cfRegister cfRegister TRC_CF_REGISTER.log

- cfUsrNtf cfUsrNtf TRC_CF_USRNTF

sdagent sd_jexec SDAgent TRC_USD_SDAGENT.log

- sd_msiexe SDMSIExe TRC_USD_SDMSIEXE.log

amagent amagentsvc amagent TRC_AMAGENT.log

amagent amagent amagent TRC_AMAGENT.log

amswmagtu amswmagt UAM TRC_UAM.log

amswmagtw amswmagt UAM TRC_UAM.log

- Amsoftscan UAM TRC_UAM.log

ampmagent capmuamagt amperfagent TRC_AMPERFAGENT.log

rchost rcHost _HOST TRC_URC_HOST.log


OS Services


rchost rcHost URC TRC_URC.log

ttsagent tngdta dtsagent TRC_DtsAgent.log

dtsmg tngdtmg dtsagent TRC_DtsAgent.log

dtsbrowser tngdoba dtsbrowser TRC_DtsBrowser.log

- - BACKUP_AGENT TRC_BACKUP_AGENT.log

- (lib) ammsapi Metering API TRC_AMMeterAPI.log

ccsmsvr- ccsmsvrd ccsmsvr TRC_CSMSERVER.log

cserver cserver cserver TRC_CSERVER.log

- sd_sscmd SSCMD TRC_USD_SSCMD.log

sdmpcserver sdmpcworker sdmpcworker TRC_USD_PMCWORKER.log

sdserver sd_server SDServer TRC_USD_SDSERVER.log

amms amms Metering Server TRC_AMMMS.log

amrss amrss RSS TRC_AMRSS.log

rcserver rcServer _SERVER TRC_URC_SERVER.log

- - BACKUP_SERVER TRC_BACKUP_SERVER.log

dtssos tngdtsos dtssos TRC_DtsSos.log

dtsnos tngdtnos dtsnos TRC_DtsNos.log

dtstos tngdttos dtstos TRC_DtsTos.log

rcmanager rcManSrv _MANSRV TRC_URC_MANSRV.log

- (lib)sqlexec sqlexec TRC_DBAPI.log

highlevelapi DSMHLAPI TRC_HLAPI.log

- ccnfclient ccnfclient TRC_CCNFCLIENT.log

ccsmact ccsmactd ccsmact TRC_CSMACT.log

ccsmapi ccsmapid ccsmapi TRC_CSMAPI.log

tomcat java cfjvmplugin TRC_CF_JVMPLUGIN.log

- webservieapi.dll DSMWebServices TRC_CF_WEBSERVICES.log

cmcontdiscover cmContDiscover cmContDiscover TRC_CF_CMCONTDISC.log

dmdeploy DMDeploy DMDeploy TRC_CF_DMDEPLOY.log

cmobjectmanager cmObjectManager cmObjectManager TRC_CMENGINE.log

- cmDirEngJob cmDirEngJob TRC_CMDIRENGJOB.log


OS Services


ammanager amObjectManager AMManager TRC_AMMGR.log

sdmgr_tm sd_taskm tm TaskMan TRC_USD_TASKMAN.log

sdmgr_dm sd_dialog_m DialogM TRC_USD_DIALOGM.log

sdmgr_api sd_apisrv ApiServer TRC_USD_APISERVER.log

sdmgr_im sd_taskm im InstMan TRC_USD_INSTMAN.log

- sd_ahdcmd sd_ahdcmd TRC_USD_SDAHDCMD.log

sdmgr_ft sd_mgr_ft SDMgrFT TRC_USD_SDMGRFT.log

sd_dtpush SdDtPush TRC_USD_SDDTPUSH.log

sd_dtsft DtsFT TRC_USD_DTSFT.log

BACKUP_WORKER TRC_BACKUP_WORKER.log

BACKUP_MANAGER TRC_BACKUP_MANAGER.log

Migration_CSM TRC_MIGRATION_CSM.log

Migration_USD TRC_MIGRATION_USD.log

rcManagerR11Migration

Migration_URC TRC_MIGRATION_URC.log

Migration_UAM TRC_MIGRATION_UAM.log

(lib)amRsapi RSAPI TRC_AMRAPI.log

dmsedit DMSEditor TRC_DMSEDITOR.log

dsmreporter REPORTER TRC_REPORTER.log

dsmgui GUI TRC_GUI.log

(lib) dmapi DMAPI TRC_CF_DMAPI.log

BACKUP_MGUI TRC_BACKUP_MGUI.log

(lib) gui_rc _EXPLORER TRC_URC_EXPLORER.log

(lib) gui_rcView _VIEWER TRC_URC_VIEWER.log

(lib) gui_rcReplay _REPLAYER TRC_URC_REPLAYER.log

(lib) rcHostGUI _HOSTGUI TRC_URC_HOSTGUI.log

(lib) gui_rcWrap _WRAPPER TRC_URC_WRAPPER.log

rcUtilCmd(lib) _UTILCMD TRC_URC_UTILCMD.log


Security

Security There are three primary aspects to common security:

Authentication

Authentication provides confidence that the requesting object is who they say they are. It is employed for login and machine to machine communications (application to application).

Authorization (Permissions)

Components use the verified identities to lookup rights and privileges to apply to the requested operation. This occurs in the MDB via an API.

Data Encryption

This can occur on the disk or over the network.

Some common terms you should be familiar with for this topic include:

URI - Uniform Resource Identifier. Similar to a URL. The format of a URI is:

Format – “<scheme>://<authority>/<object>”

Where <scheme> is the namespace (a.k.a “Provider”). For example:

– winnt: Primarily Windows NT domain and local SAM’s.

– unixl: Unix local account (shadow password file)

– ldap: LDAP directory access

– nds: NDS directory access

– x509cert: X.509 V3 certificates

and <authority> identifies a security database of some form – local SAM, domain SAM, NDS directory, Unix password file.

Security Scheme. Each security component may be able to use one or more protocols to provide authentication. For example:

– winnt:(ntlm) – NTLM authentication using SSPI

– winnt:(krb5) – Kerberos authentication using SSPI

– winnt:(plain) – LogonUser authentication using RSA crypto

– unixl:(plain) – shadow file access using RSA crypto

– x509cert:(dsm) – certificates using DSM RSA crypto

– local: special – represent O/S local interface

Security Schemes are usually hidden – only used explicitly by SM and RC.


Security

CCL Security provides

Authentication

Authorization assistance & access tests

Authority browsing

Authority management

Identity reporting

Authentication

Authentication is the process of a security principal proving they are who they say they are through:

“Something I know” – for example, a password

“Something I have” – such as a smart card / certificate

“Something I am” - in other words, biometrics

The CCL Security Authentication component provides authentication services to local and remote services. It links closely with the Session Messaging services to provide authentication services for messaging clients.

It also provides mechanisms for being inserted into other transports, such as a networking stream, to allow for the same authentication methods to be used by all services.

Authentication is used by Networker, RC, Configuration, COAPI, AM, SD, Session Messaging - nearly everywhere! CCL security does NOT provide authorization - in DSM this is provided by the OLS component. CCL Security does provide:

Membership evaluation

Upper security layers also require group membership tests for authorization

Access restriction

The NDS provider has to manually test for logon-hours, etc., as the API does not enforce these.

Authority Browsing

An “authority” is a security database of some form – for example, a local SAM, domain SAM, NDS directory, Unix password file. It provides a generic interface for browsing for:


Security

Users

Groups

Computers

Management

Some authorities are always enabled for authentication, such as O/S native and certificates.

Some authorities are specified by manager policy, such as External directories – LDAP, NDS.

The security components manage the list of available authorities and security schemes including those that are:

Implicit: where certificate authority always enabled (DSM r11)

Explicit: where external directories always enabled by manager policy

Derived: where O/S providers are calculated in priority order:

– Global – domain

– Local – local SAM (Windows – but not DC’s) or local machine (Unix)

– Trusted – explicitly trusted domains

Note: There is no GUI mechanism to support implicitly trusted domains. These must be added using cfspsetpass – a supported tool in r11.2.

The security components are responsible for generating the URI’s which represent the current machine and the logged on user(s) in varying namespaces.

These only work where the URI’s can be reliably generated:

NT

Unix

NDS (with NW client support)


Security

Encryption

Encryption is used to secure data and secure communication. Here you can see the relationship between the encryption function and the common configuration:

Encryption provides a low-level wrapper around the eTPKI that is used for:

Digital signatures

Generating, importing, exporting keys

Data encryption

Supported cryptographic algorithms: RSA/DES/3DES

Used by:

CCNF (comstore)

Session Messaging

High-level interface for data encryption.

Automatic key handling

User based encryption is used by RC viewer (local address book)

System based encryption is used by RC host (users for local security)

ITRM encryption mode is used to secure the DB password

The 3DES algorithm is used in NETWORK mode to negotiate secure peer-to-peer communication.

3DES session key is integrated in the Networker. It is used by CFFTPlug-in (NOSless file transfer), DTS agent, and RC host – viewer (supports legacy negotiation for URC 6.0 connections)

Run Time Requirements include Etpki 2.3.3. (OpenSSL 0.9.7d):

On Windows: ipthread.dll, libetpki2.dll, libetpki2_thread.dll


Security

On Unix: libetpki2.so, libetpki2_thread_posix.so

Logging is done to the file of the calling component.

Authorization (Object Level Security)

DSM Object Level Security (OLS) is based on the USD 4 permissions model:

Security Profile

This is a role/group/individual user mapped from a security provider (for example, an NT domain group).

Class ACE (Class level security)

For each profile one Class ACE will be assigned for each type of secured object.

From the start only Class ACE exists for all objects. This is the default ACE for an object of a given type. This ACE value is used.

Object ACE (Object Access Control Element)

Permissions assigned to an object


Security

Ownership

An object is either owned by a user or is said to be unassigned. When a background process creates an object, that object is usually unassigned. If you create an object, your user ID is the owner of the object. As the owner of an object you inherit all permissions associated with the “Owner” security profile. “Owner” is a special security profile, created at install time and set to Full Access by default.

Take Ownership

A user gets the ownership of an object

Access Control

Authorization concerns itself with the rights and privileges associated with an authenticated entity (typically a logged in user, but could be a machine/process/application). The common authorization sub-system covers class level, group level, object level and functional security.

It is based on the concept of an Access Control Entry (ACE), which is a bit-oriented integer. The following eight bits are currently used:

V View bit, allows you to show objects.

C Create bit, allows you to create objects.

R Read bit, allows you to read sub-objects of an object.

W Write bit, allows you to change and object.

X Execute bit, allows execution, depends on object type.

D Delete bit, allows you to delete objects.

P Permission bit, allows you to change the ACE itself.

O Ownership bit, allows you to take ownership of an object.

A permission mask is the complete ACE for a specific entity. The way to obtain this is to OR every ACE associated with the specific secured entity. There are exceptions to this rule:

If one ACE is all zeros (no access) then the resulting permission mask will be zero (no access)

If it is the “everyone” profile that has all zero (no access) then the exception above is invalid.


Security

Things to Note

It is very important that you understand the relationship between the User and the Security Profile. A user can be a member of more than one Security Profile and, in that case, the user has cumulative rights (i.e., permissions are OR’d together).

When permissions are defined for a group, rights are inherited. Inheritance can be enabled or disabled for each individual group.

Unlike the previous r4 USD release, the “No Access” permission does not override all other permissions.

There is no replication of security profiles or permissions.

Components that use OLS include:

Every DAI component using the DBAPI

Web Admin Console

DSM AM Manager ( AMO Data classes)

CLS-SD Stored procedures

Test of the permissions must be very fast. It needs to:

Use simple select for permission

Calculate the effective permissions when an object is created or a permission is changed


Security

Applicable MDB Tables

Following are the MDB tables used by security:

Class level permissions are maintained in the ca_class_ace table

Object level permissions are maintained in the ca_object_ace table

Group level permissions are maintained in the ca_group_acen table

Following is the list of security profiles used:

Profile Name Purpose

Everyone This profile initially has class permissions. NO_ACCESS for all classes

Owner This profile is necessary for managing dynamically created objects so that every object will be assigned to an owner profile.

Ownership may be changed via an application, such as a UI

Distributions This profile is used by the Enterprise. Administrators have class permissions

FULL_CONTROL for all objects

Administrators This security profile is for the local user. User group is called ADMINISTRATORS. This profile initially has class permission FULL_CONTROL for all objects


Security

The following table identifies the relationship between the GUI level object, their corresponding DB tables, Security Class ID and Level used in the Common Table.

GUI Level DB Tables Security Class ID Security Level

Computers ca_discovered_hardware SEC_CLSID_COM_COMPUTER Class, Object

Users ca_discovered_user SEC_CLSID_COM_USER Class, Object

Computer Users

Ca_link_dis_hw_user SEC_CLSID_COM_COMPUTER_USER Class, Object

Managers ca_manager SEC_CLSID_COM_MANAGER Class, Object

Servers ca_server SEC_CLSID_COM_SERVER Class, Object

Groups of all above

ca_group_def SEC_CLSID_COM_GROUP [1] Class, Group, Object

Group of assets

ca_group_def SEC_CLSID_COM_ASSET_GROUP Class, object

Group of servers

Ca_group_def SEC_CLSID_COM_SERVER_GROUP Class, object

Group of domains

ca_group_def SEC_CLSID_COM_DOMAIN_GROUP Class, object

Queries ca_query_def SEC_CLSID_COM_QUERY Class, object

The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used in the Security Table.


Class Permission

ca_class_def SEC_CLSID_SEC_CLASS_SECURITY_ OBJECT

Class, Object

Security Profiles

ca_security_profile SEC_CLSID_SEC_SECURITY_PROFILE Class, Object

MDB Access -- SEC_CLSID_MDB_ACCESS Class


Security

The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used in the Software Delivery Table.


SW Packages usd_rsw SEC_CLSID_USD_SOFTWARE Class, Object

SW Procedures usd_actproc SEC_CLSID_USD_PROCEDURE Class, Object

SW Groups Usd_swfold & type=1 SEC_CLSID_USD_SW_GROUP Class, Object

Procedure groups Usd_swfold & type=2 SEC_CLSID_USD_PROC_GROUP Class, Object

Job containers Usd_job_cont SEC_CLSID_USD_JOB_CONTAINER Class, Object

Jobs Usd_activity SEC_CLSID_USD_JOB Class, Group, Object

Distribution containers

Usd_contfold SEC_CLSID_USD_DIST_CONTAINER Class, object

TM Tasks Usd_task SEC_CLSID_USD_TASK Class

Container Usd_cont SEC_CLSID_USD_CONTAINER Class, object

The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used in the Asset Management Table.


Jobs Ncjobcfg + column job_category

SEC_CLSID_ASSET_JOBS SEC_CLSID_ENGINE_JOBS

Class Class

Modules Ncmodcfg + column motype

SEC_CLSID_MODUL_INVENTORY SEC_CLSID_MODUL_TEMPLATE SEC_CLSID_MODUL_SOFTWARE SEC_CLSID_MODUL_METERING

Class Class Class Class

Policies Polidef SEC_CLSID_POLICY_QUERYBASED SEC_CLSID_POLICY_EVENTBASED

Class Class

Software Ca_software_def SEC_CLSID_AMO_SW Class, Object

Engines Ca_Engine SEC_CLSID_AMO_ENGINE Class, object


Security

The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used by the DSM Explorer Table.


GUI task wizard [*] -- SEC_CLSID_COM_TASKWIZ (this is no longer used)

Class

Enable Control Panel

-- SEC_CLSID_COM_CONTROL_PANEL Class

Enable Remote Control

-- SEC_CLSID_COM_REMOTE_CONTROL Class

The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used by Other MDB Tables.


External directories Ca_directory_details SEC_CLSID_DIR_EXT_DIRECTORY Class, Object

Report Template Rptree & type = 3 SEC_CLSID_REPORT_TEMPLATE Class

Schedule Template Rptree & type = 40 SEC_CLSID_SCHEDULE_TEMPLATE Class

Configuration Policies computer

Csm_object and csm_class is ConfPolicyComp

SEC_CLSID_CCNF_POLICY_COMP

Configuration Policies user

Csm_object and csm_class is ConfPolicyComp

SEC_CLSID_CCNF_POLICY_USER

OSIM object – Boot/OS images

Csm_object and csm_class is “OSimage” OR csm_object and csm_class is “BootImage”

SEC_CLSID_OSIM_IMAGE

Troubleshooting

There may occasionally be problems with a long running query such as a query created by the DBAPI.

If object are not visible in the Explorer but full control is provided:

Check permissions in the MDB

Check stored procedures


Communication

Communication In an attempt to reduce port usage, complexity, volume of code and to improve reliability and supportability DSM r11 introduces two types of common communications:-

connection-oriented, multiplexed, stream-based networking. Provided by two components; “the Networker” and “The Port Multiplexer”

connectionless, message-based messaging. Provided by two components; “The Messenger” and “Session Messaging”

The diagram below illustrates the conceptual position of these components within the DSM R11 stack.

Streams

Stream-based communications is provided by the common networking component which provides an interface to support (primarily) stream- based communications but also includes support for low volume datagram-based networking. In other words, for datagrams, it provides the ability to unicast, broadcast or multicast ‘trigger’ packets and handle responses to these packets.

There are two distinct parts to the networking component: the Networker and the Port Multiplexer.


Communication

Networker

The Networker is a generic, protocol-independent interface to stream based networking. This is a loadable component, which makes use of other loadable components to provide support for specific protocols, such as TCP/IP.

The Networker supports Synchronous or Asynchronous (API). The Asynchronous (non-blocking) API uses the CCL Notification object and separate threads for sending, receiving and listening. The Synchronous (blocking) API uses CCFNetwork::Select to process incoming connections in the case of a listening networker and to determine if there is data to process on the receive queue.

Synchronous/Asynchronous mode is determined by passing a notification object to the CCFNetwork::Init routine.

As most datagram-style communications are intended to use the messenger component, the Networker restricts the messaging styles it supports. Datagram messaging is needed especially when interfacing with external resources.

The Networker makes use of a lower level interface to protocol specific components. These components are given logical names (which may map on to ‘well known’ protocols such a ‘TCP’ or may be something less obvious). The logical name is associated with a ‘configuration set’ which conditions the behavior of the component. Some of the configuration information is used by the generic layer and some by the specific layer (and some may be shared and exposed externally).

One important detail included in the configuration set is the name of the dll/shared library which implements protocol support. The configuration set may also include information used by the protocol support itself, such as the entity it should act as when listening for incoming connections.

This model gives great flexibility is allowing a single DLL to act for multiple protocols, where the protocols are ‘well known’ or convenient tailoring of a particular implementation.

Port Multiplexer

The Port Multiplexer is a plug-in that listens for stream connections and forwards them to the process that requires them. It handles connection establishment and enables multiple applications to listen on a single port.

The default listen port is 4728.

Applications use virtual ports and incoming connections handed off to waiting applications.


Communication

The Port Multiplexer only supports TCP.

Since the Port Multiplexer has its own API set it is not necessary to convert existing applications to use the Networker (see below) in order to use the Networker services. The conversion is straightforward and adopting such an approach has benefits over using the Networker including: -

Existing pre-release 11 components can be communicated with (which might not be the case with the Networker, which imposes its own protocols on the data interchange). The Port Multiplexer can also listen directly on ‘legacy’ ports which allows applications which haven’t been converted to use the multiplexer to converse with those which have, without requiring the converted application to handle multiple concurrent connection styles.

Existing logic can be preserved. Often, changing to use the Networker will involve changing the style of interacting with the communications. Application logic is often based on the behavior of the interfaces used.

The Pmux API routines send a small message to the plug-in which is listening on port 4728. Message types include:

Listen

Legacy Listen

Connect

Query

PMUX and Networker Working Together

The Port Multiplexer and Networker are complementary solutions. The Networker will make use of the port multiplexer in order to make or allow connections. For example, instead of listening for a connection, a Networker will ask the Port Multiplexer to listen on its behalf and the Port Multiplexer will hand over connection to it. Similarly, when making a connection to another machine, the Networker will connect to a remote port multiplexer nominating the (virtual) port it wishes to connect to. That Port Multiplexer will accept its connection and hand it over to the ‘real’ listener. Thus, all DSM components on a machine can share a single port for all connections.

The Messenger

DSM r11 messaging is delivered via the Messenger common component. The Messenger provides an abstraction layer, implemented on top of CAM, which separates its users from the messaging system actually in use.


Communication

Each component allocates its own CAM queue along with a worker thread to poll messages from this queue. The Messenger component will then deliver messages asynchronously to the component subscriber.

The Messenger is message format-agnostic and includes the capabilities to build additional layers on top of it. These layers may be generic (for example, supporting encryption or compression) or specific (for example, building a remote procedure call (RPC) model with its particular message structure on top).

Each Messenger ‘object’ represents a distinct logical connection to the messaging system with its own identity. Message objects provide a convenient method of encapsulating incoming messages.

An object/structure is also provided to abstract the addressing of messages. This has two components. The first is the machine the message should be directed to and the second is the identity of the component, relative to that machine. (In CAM terms, this equates to a ‘host name’ and a ‘queue name’).

The Messenger API provides an interface to declare an interest in a messenger connection and to give that connection a logical name. It also provides a means of sending messages.

Message receipt and failure notifications are notified asynchronously. Such notification will normally take place in a thread different from the one used to send messages.

Session Messaging

Session Messaging (SM) is a client-server layer that sits atop the DSM Messenger component. SM is provided in the form of a C-based interface DLL and a management daemon (CAF plug-in). SM is modular and utilizes many common components. It provides the following

Session management

Encryption

Compression

Low-level authentication (X.509)

High-level authentication (O/S or External)

Transactional calls

Message forwarding


Communication

Receiving Data

SM supports 3 modes of data receipt

Call-back – asynchronous call made into application space. Message released on call-back termination.

Scan with call-back – synchronous call made into application space when application asks. Message release on call-back termination.

Scan with output – synchronous call that returns pointer to message. Message released by application when finished with.

Message Forwarding

Session Messaging is provided as a tri-interface DLL. This means that it differs slightly from other components in that it provides three interfaces for most text based APIs

Wide (Unicode – UCS16)

Narrow (MBCS – Current code page)

Native (UTF8 – UCS8)

Internally, SM tries to work in UTF8 as much as possible to be forward capable with new messaging providers. Following is an overview of the process SM uses to communicate:

Client establishes a session with Dispatcher.

Session bound between Client and Dispatcher.

Dispatcher forwards request to a server endpoint on the local machine.

Session now bound between Client and Server n.

Session holds authentication and encryption

Server responds to the request.

Session still bound between Client and Server n.

When finished, Server unbinds.

Client now re-binds to Dispatcher.


Chapter 5: Installation Topics

This chapter discusses a several topics relating to the installation of Unicenter DSM architecture, including:

Infrastructure deployment

Migrating\upgrading from a previous installation\version

NAT Environments

For additional information you should consult the following sources:

Implementation Guide (notably “Chapter 2: Planning the Infrastructure Implementation”, “Chapter 3: Installation of Unicenter DSM” “Chapter 4: Infrastructure Deployment,” “Chapter 5: Upgrading Unicenter DSM”, “Chapter 8: Migration to Unicenter DSM,” “Appendix B: Software Delivery Procedures for Installation” and “Appendix G: Unicenter Software Delivery Query Migration Details”)

Chapter 5 in the Unicenter Desktop and Server Management Diagnostics Guide








Upgrade checklist (http://supportconnectw.ca.com/public/impcd/r11/administration_and_maintenance/unicenter_udsm_r11_upgrade_checkl.htm

Managing hostname changes http://supportconnectw.ca.com/public/impcd/r11/Unicenter/cms_main.htm#namechange

September 2007 Chapter 5: Installation Topics 5–1







http://supportconnectw.ca.com/public/impcd/r11/administration_and_maintenance/unicenter_udsm_r11_upgrade_checkl.htm

http://supportconnectw.ca.com/public/impcd/r11/administration_and_maintenance/unicenter_udsm_r11_upgrade_checkl.htm

http://supportconnectw.ca.com/public/impcd/r11/Unicenter/cms_main.htm#namechange

http://supportconnectw.ca.com/public/impcd/r11/Unicenter/cms_main.htm#namechange

Infrastructure Deployment

The following techdocs should also be noted:

“How Authentication Works in r11 for Centrally and Locally Managed Configurations” (TEC401105)

“How to Centralize Security in URC r11” (TEC401138)

“SQL Installation and Preparation for DSM r11 Domain and Enterprise Manager Installs” (TEC401106)

“How to Move a Domain from one Enterprise to Another” (TEC401299)

“How do you install the Software Delivery Agent without the need to also install the Software Catalog” (TEC430032)

“SQL Installation and Preparation for DSM R11 Domain and Enterprise Manager Installs” (TEC401106)

“When installing r11.2 with Common Services how does it handle having existing versions of NSM components already installed on the server?” (TEC426063)

“Creating a Pre-configured Standalone Customised install for the r11 Remote Control Agent” (TEC395449)



Infrastructure Deployment The Infrastructure Deployment subsystem facilitates the initial deployment of DSM software components within a heterogeneous enterprise. Infrastructure Deployment is also sometimes known as DMDeploy v2. DSM infrastructure components, such as Agents and Scalability Servers, can be transferred and installed without the use of Unicenter Software Delivery. This functionality is typically used for an initial roll out of the DSM infrastructure.

Infrastructure Deployment uses a DSM Explorer wizard to scan for deployment targets and to configure and initiate the deployment job.

Important note: When the Infrastructure Deployment wizard is completed a deployment job is created which manages the progress of the deployment to all the selected end systems. The status of this job can be viewed via the DSM Explorer, but please note that the job is NOT persistent; it is maintained in the memory space of the DMDeploy manager process. If the DMDeploy manager exits for any reason (crashes, is restarted, machine rebooted) the job information is lost as are any unprocessed status messages from end system installations. These installations, however, will continue if already started.




Important note: All Operation Systems are not created equal. The deployment manager has different capabilities on different platforms. Two major restrictions on the Linux manager are that:

it cannot push out a primer to Windows shares since it cannot run the installation command

it cannot enumerate Windows domains

You will get an error if you try to do the latter. The Windows manager however is fully capable of SSH and telnet/FTP deployment to UNIX variant targets.

Important note: Deployment using FTP can seem back to front until you think about it. This method of deployment works as follows:

First DMDeploy Manager connects to target using telnet

Then DMDeploy Manager issues FTP commands over telnet on the target, pulling the primer installation image from manager to target – in other words, initiating the FTP “get” request on the target.

This is different for deployment via shares and ssh, which are pushes from the manager to target. This method only requires that a single FTP server be set up on the Manager, rather than having to have one on each target.

September 2007 Chapter 5: Installation Topics 5- 3


Processes and Log files

The diagram below gives an overview of the processes and data flow involved.

Initially the DMDeploy EGC plug-in will make a request via DMAPI to install the package on a remote target(s). The following process flow is then used by the infrastructure deployment to deploy the software:

1. Select payload to deploy & specify targets

Using Wizard or dmsweep

Can use IP addresses, directory, Windows domain

All target source mechanisms result in a list of addresses to deploy to.

2. Scan for targets/payload

is machine in DNS?

try to open socket (7)

cam ping – determines presence of primer

3. Transfer Manager Public Key to target

Using Windows (ADMIN$) Share, SSH or Telnet/FTP (or manually).

From <manager root>\dmdeploy\bin\dmkeydat.pmr



4. DMDeploy manager will transfer DMPrimer Installer image to target (if not already installed) and, if necessary, (e.g., Windows 9x systems), DMBoot. This can be done through SMB shares, telnet/ftp or SSH depending on the type of target platform and the security that has been enabled on them.

Note: Image placed in <ADMIN$>\dmsetup.exe, or /tmp/dmprimer/* on *nix

5. DMPrimer installer installs itself and CAM on the target machine using either Windows RPC, SSH or Telnet (or manually). Note that DMPrimer must run with elevated privileges.

Note: Some operating systems, such as Windows 9x, do not have a method for remote invocation. In these cases, it is necessary to configure the OS to install the primer on a significant operating system event, such as a reboot.

6. When install completes, DMPrimer notifies manager (via CAM) of successful installation so that package deployment can now be initiated.

Note: A DMDeploy manager that has either installed a DMPrimer or has authenticated with it can deploy packages without needing to re-supply usernames or passwords. This is achieved through authentication using public and private keys.

Any errors up to this point usually result in “No Primer Transport”

7. Manager sends payload data to Primer (using CAM messages).

Data appears as a “primer.packN” file in the Primer installation folder (‘N’ is a small number).

8. Primer unpacks the payload data, then sends a “package received” message to manager

9. Manager sends payload installation command in a CAM message to primer, which executes it

Payload installation is synchronous, no timeout

Install command is logged in dmprimer.log on target

10. Primer returns installation status to manager

Also logged in dmprimer.log

Stage to and Deploy from Scalability Server

To reduce overall network traffic, deployment payloads can be “staged” to a Scalability Server. This operation is basically a normal deployment except that the installation command is replaced by a copy into a staging area.

On Windows: staging area is a share (DMDEPLOYSS$)

On Linux/UNIX: staging area is an FTP server.



Deployment from a Scalability Server simply takes the payload data from the staging area rather than the manager library area.

Note: In r11.1 the primer installation image is transferred from the Manager while, in r11.2, it can be staged at the Scalability Server.

Even when a Scalability Server is used to stage and deploy software packages, control of the process is still handled by the manager.

Diagnosis Tips

Consult the following log files if you experience problems with Infrastructure Deployment:

Manager Logs use standard DSM log mechanism and the following naming convention:

TRC_CF_DMDEPLOY_*.LOG

Major deployment stages are logged at “INFO” level and log analyser rules are available. The Manager Logs include information regarding the connection to Windows target shares, job status and other deployment stages.

Primer Logs note the exact installation command that is run along with the exit code it produces upon completion. These logs are produced in the temporary directory (%TEMP% or /tmp).

Payload Installation Logs can typically be found in the following locations:

– On Windows: %TEMP%

– On UNIX\Linux: /opt/CA/installer/log

You should also check the following logs for more information:

CAM logs, if you have communication issues

UNIX/Linux syslog on target computers can be useful to diagnose SSH/Telnet security issues

Don’t forget to….

Check Firewall settings!

Full automatic deployment is not always possible because…

– Windows 9x does not support remote installation of primer from the manager, and by default doesn’t let you map the ADMIN$ share.

– Later Linux versions are configured to disable remote non-interactive SSH sessions.

Further details can be found in the DSM Implementation Guide



Upgrade of Primers

Primers are not automatically upgraded; therefore you will need to use the “force primer push” policy setting to achieve this. Deployment of DMPrimer uses native OS data transport mechanisms or is done manually, but, all subsequent network activity is performed via CAM (such as pushing payloads and returning payload installation status). This reliance on CAM isolates the main portion of the deployment process from networking issues and configuration.

Note: This process requires re-authentication (to push new encryption keys).

DSM session messaging (hence CAM) is used for all DSM Explorer Wizard to Manager communications.

Frequently asked Questions

Following are some frequently asked questions regarding Infrastructure Deployment:

What does “No Primer Transport” Job status mean?

Can’t push primer to target (or it failed to install)

What does “Failed to Telnet” trace message mean?

This error is usually associated with the No Primer Transport status and is preceded by “failed to map share” and “failed to SSH” errors!

Where have my deployment jobs gone?

Jobs are not retained when the deployment manager is recycled.

What can I do to test CAM Connectivity issues?

Ensure that you can execute “camping” both ways between manager & targets. Also, check DNS, and firewalls configurations.

Where are the agent configuration options documented?

In the Implementation Guide (<DVD>\doc\r11impl.pdf). See sections “Modifying Installation Property Values” (for Linux) and “Installation Tool msiexec” (for Windows).

How do we add new package versions/packages for new platforms?

Use the dsmPush.dms script (included on the distribution image) to do this.



Additional Considerations for r11.2

The following are additional considerations when using the r11.2 release:

Hidden CLI passwords

Primer Arguments can be used to change primer installation location.

A target credentials file assists with offline specification of bulk targets

Less bandwidth is used between Manager and targets when a Scalability Server is used since the primer image is now transferred from Scalability Server

You can now suspend a scan and proceed with deployment using current scan results - no need to wait for a scan to complete!

CCNF Parameters

A number of common configuration policy parameters can be modified and affect infrastructure deployment behavior as described below:

AlwaysDeploy

Will force payload push/install even if a newer version of the payload is detected on the target computer.

AlwaysDeployPrimer

Will always push the primer image and reinstall. Useful if primer install image got corrupted in some way.

PingCheckSkip

Eliminates the quick “ping” of a target during scanning. This setting is necessary when TCP port 7 is protected by a firewall.

Detection of Deployed Packages

Detection of deployed packages differs based on the operating system involved.

On Windows this is done through MSI product codes. The DSM payloads (packages) include MSI product codes within dmdeploy.dat. The primer uses this code and interrogates the MSI database to check whether a product has already been deployed.

Note: A payload may consist of multiple MSI products (e.g. “all agents” package).

On Linux/UNIX, registration is recorded in the following file:

$CA_ITRM_BASEDIR/dmprimer/bin/dmdeploy.reg



The installer registers/deregisters a product by calling dmprimer with special args. The Infrastructure Deployment Manager asks “is product x version y installed?” not “what products have you got?”

Increasing Primer Log Level

To increase the primer log level do the following:

1. Change to the directory containing the dm_primer. On Windows this is:

Program Files\CA\Unicenter DSM\DMPrimer

2. Issue a 'dm_primer stop' command

3. Remove the old dmprimer.log

4. Edit the dmprimer.cfg file found in the above directory and change the TRACE_LEVEL value from 3 to 5.

5. Deploy the software

Note: There is no need to restart the primer as cam will do this automatically

Note: SE Testfix T18C872 allows log level updates without restarting primer.

Deploying to Linux over SSH

Deployment to Linux targets using DMDeploy over SSH (the default method for Linux) is quite complex and subject to a variety of environmental obstacles. Many things have to occur successfully before the deployment payload becomes active on a target system. Unfortunately, since no CA software is assumed to be present during deployment it is impossible to report accurate status and diagnostic messages during this operation. Therefore an understanding of the process is important.

Following is the sequence of events that occur when deploying to Linux using SSH, to a clean system. When diagnosing problems in this area identifying the point of failure within the sequence is crucial.

1. The dmdeploy manager connects to target system using ssh

You should see the connection attempt logged into the system log file /var/log/secure.

2. If the connection is successful, the primer installation package is pushed to the target system using ssh/sftp

You should see OS processes with names containing these strings appear on the target system

3. Primer image is uploaded to /tmp/dmprimer



You can do “ls –ltr” in this directory to monitor the growth of files as they are uploaded. In order to assist with tracking down installation issues this directory is not removed.

4. When the image stops growing, the primer install (installdmp) is launched.

You should see a process with this name appear in your ps list. You should also see a process running lsm.exe.

5. After the primer install is finished, you should see two packages called “ca-dsm-dmprimer” and “ca-dsm-dmprimer-standalone” in the pif package list (“lsm –lOpif”). Primer files are installed into the following directory:

/opt/CA/UnicenterDSM/dmprimer

6. Dmprimer should then be started (you should see “dm_primer start” appear in the ps list). The dmprimer log file (/tmp/dmprimer.log) should also appear.

7. The transfer of the deployment payload (for example, UAM agent) starts. You should see the “transferring xx%” messages appear in the GUI/CLI. This is quite quick in comparison to the primer upload in step 2.

8. Package installation starts.

You will see the “installdsm” process in the ps listing. The command “lsm –lOpif “will display the PIF packages currently installed. After completion, the package ca-dsm will be present. Other sub-components will be present depending on which payload you are installing.

That’s it – package installation status is sent back to the manager and displayed in the GUI/CLI.

Deploying to Windows over a Network Share

Deployment to Windows targets using DMDeploy is subject to a number of environmental obstacles as well. As with Linux deployments, many things have to occur successfully before the deployment payload becomes active on a target system. Unfortunately, since no CA software is assumed to be present during deployment it is impossible to report accurate status and diagnostic messages during this operation. Therefore an understanding of the process is important.

Following is the sequence of events that occurs when Windows is deployed to a clean system using shares. When diagnosing problems in this area identifying the point of failure within the sequence is crucial.

1. DMDeploy manager attempts to open a share (by default “admin$”) on the target system.

2. If the share is opened successfully the primer installation package is copied to the target system. This consists of the following 4 files:

DMBoot.exe



dmkeydat.pmr

dmsetup.exe

msvcr71.dll

3. Primer image is uploaded to admin$, or whatever share the user has configured the manager to use for deployment.

4. When the image stops growing, the primer install is launched by the MSI installer. The task manager will show at least one msiexec.exe process running.

5. After the primer install is finished, you should see the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\DMPrimer

The key’s data will show where the primer files have been installed. The usual location is:

C:\Program Files\CA\Unicenter DSM\DMPrimer

6. The primer should now have started and “dm_primer.exe” should appear in the task manager.

The primer log file, C:\Documents and Settings\<user name>\Local Settings\Temp\dmprimer.log, should also appear at this point.

7. The transfer of the deployment payload (for example, UAM agent) starts and you should see the “transferring xx%” messages appear in the GUI or the CLI. This is quite quick in comparison to the primer upload in step 2.

8. Package installation starts and you should see a ‘.msi’ process corresponding to the package being installed (for example, ‘AgtAM.msi’ for the Agent + Asset Management plug-in package), in the Task Manager. The ‘Add or Remove Programs’ utility, accessible from the Control Panel, will display the packages currently installed. After completion, the deployed package will be present, the exact entry obviously depending on which payload you installed.

That’s it – the package installation status is sent back to the manager and displayed in the GUI/CLI.


Upgrading from a Previous Release

Upgrading from a Previous Release Detailed procedures and guidelines for upgrading to the r11 release from a previous version of Unicenter Software Deliver, Unicenter Asset Management or Unicenter Remote Control can be found in the Implementation Guide. Following is an overview and additional tips to further assist you in upgrading.

Direct software upgrade to release 11 is not supported. Rather, the upgrade path uses a “parallel” or “side-by-side” approach. First, the new r11 components are deployed (Domain Managers, Scalability Servers and other) typically using a new, more optimal, topology. Then data is migrated from the pre-r11 databases to the new r11 CA-MDB. Following is a list of supported upgrade paths:

Unicenter Software Delivery r11 can be migrated from Version 3.1 and Version 4.0

Unicenter Asset Management r11 can be migrated from Version 3.2 and Version 4.0

Unicenter Remote Control r11 can be migrated from Version 6.0

The migration to DSM r11 is about homogenization of three distributed solutions with different architectures and separate databases into one consolidated r11 architecture.



The change is a significant one in that three formerly disparate and independent technologies have now merged into a single technology employing a single management database structure. Additionally, as each product is multi-tiered, an upgrade approach would require extensive backwards compatibility support between the tiers during the migration process that would not add any value post migration.

The end result is a simple upgrade strategy will not suffice.

The DSM Implementation Guide includes a migration chapter which describes the general migration approach, limitations and challenges, as well as the specifics regarding ASM.CNF keys, MSI library migration and lots more! We strongly suggest you read this chapter.

Migration to r11 is achieved via 3 distinct steps:

1. The installation of management infrastructure (see the earlier discussion of Infrastructure Deployment)

2. The migration of data

3. The installation of new agent software

Data Migration

The Data Migration step is driven by Engine Tasks, with one Task type per product (UAM, USD, OSIM, URC). There may be multiple legacy managers and multiple tasks for each legacy manager – which could add up to “a lot of tasks!”

Migration is a continuous process and all migrated computers are visible in system group “All Legacy Computers.” The process ends when r11 Agents are registered with the MDB – at which point you should STOP managing those assets through legacy managers.

The Engine reads migration job from database using the following method based on which product is being migrated:

For Software Delivery, Remote Control and OSIM:

An XML file is created containing Job contents. The product specific migration DLL is loaded and executed with this XML file as a parameter.

For Asset Management:

A call internal Engine code is made to migrate AM data



Software Delivery Specific Information

There is a slight difference between what can be migrated at the Enterprise and Domain levels in terms of:

Software Packages

Software Groups

Software Policies

Computer and User Groups

Computers and Users (Domain only)

Computer Job History (Domain only)

Security

To use USD 4.0 SP1 SDGAPI to get to v4.0 data do the following:

On Windows install the legacy API from DSM Installpath\SD\Legacy\usd40sp1\sdapi.w32 IF and only IF USD 4.0 SP1 and DSM r11 are not co-hosted.

On Linux the legacy API is installed with the DSM r11 manager and no additional actions need to be taken

Migration of Software Packages:

Exports packages and added procedures and imports them to r11

Is only done once

Limited Group Membership update on each run – unlinking not detected on legacy manager

Migration of Software Groups:

Is only done once

Limited Group Membership update on each run – unlinking not detected on legacy manager

Migration of Software Policies (aka Software Templates):

Is only done once

Never sealed automatically

Sealed Software Policies are migrated on Domain only

Migration of Computer and User Groups:

Is only done once

Limited Group Membership update on each run – unlinking on legacy manager not detected



Limited query migration. Many queries cannot be migrated properly but they will appear in r11 as “disabled” and can be redefined using the DSM Explorer post migration

Migration of Computers and Users (Domain only):

Is only done once

Limited Group Membership update on each run – unlinking on legacy manager not detected

Scoped – able to specify migration scope by naming Computer and User group on legacy manager. Only members of that group will get migrated

Watch out for duplicate HOST UUIDs! HOST UUID used as primary identifier of computers in r11. Duplicates WILL mess things up!

Migration of Computer Job History (Domain only):

Migrated every time

Records replaced on consecutive runs

Records merged on last run

Migration of SD Security:

Only migrated once

Security Profiles migrated regardless of security provider conflicts (winnt/unix). Can be remapped to other OS security groups post migration using DSM r11 Explorer.

Object ownership only migrated if security providers match (winnt/winnt, unix/unix, not winnt/unix)

The migration of computer and user data occurs in the following phases:

Computer or User created by migration task and set in state locked by migration on DSM r11 manager to prevent DSM r11 manager from setting up jobs for it

When r11 Agent registers with DSM r11 manager the agent version is updated. Computer or User remains in state locked by migration on DSM r11 manager

Next time migration task is run the installation history from the legacy manager is merged with the existing history in r11 DSM Manager and Computer or User state is unlocked from migration

Management of Agent using r11 manager can begin. At this point you should STOP managing the agent using legacy manager as no further migration of job history will be performed!

Detail on how ASM.CNF is migrated into r11 comstore is documented in Implementation Guide. This includes the migration of user data including: User, Room, Phone and Comment and customized agent name.



Migration is invoked by agent installer if selected by user.

Migrated configuration settings are protected by CCNF from override by DSM r11 default policy. Only custom policy will override the migrated settings.

On Managers, the library is copied by a migration task - it is NOT automated on Scalability Servers. You will need to run sd_sscmd import to copy or move packages from legacy staging servers.

MSILIB is not automatically migrated on Domain Managers and Scalability Servers. You will need to run sd_sscmd importmsi to copy or move packages from a legacy local or staging server MSILIB.

In r11 software packages are identified by DSM UUID – NOT by their MSI Product Code.

This appears in MSILIB in folder named with this DSM UUID

DSM UUID maintained during export and Enterprise to Domain distribution

Important to use the same DSM UUID throughout Enterprise and all Domains to improve roaming source list updates

The new MSILIB share name is “SDMSILIB” and a new MSI dictionary file is provided to improve roaming source list update. In addition, new MSI procedure macros replace old macros used to find admin installs in new locations. The old macros are updated during package import. For more details, consult the Implementation Guide.

USD Data Migration Implementation

The process of migrating USD specific data is as follows:

1. Engine loads the usdLegacy DLL/SLIB

2. usdLegacy DLL/SLIB calls the sdmgrmig executable using instructions it received from the Engine

3. Sdmgrmig loads usd40sp1 DLL/SLIB to connect to legacy manager

4. Sdmgrmig loads ps DLL/SLIB to connect to r11 database

5. Sdmgrmig loads coApi DLL/SLIB to connect to r11 common manager

6. Migration is done for each selected object class

All tracing goes to TRC_MIGRATION_USD.

7. As with previous installations, all SD events are also logged to the NT(/CCS) event console.

8. Very limited feedback is written to Engine task portal but you can see if the task has completed and what the result of the run was.



9. Sdmgrmig can be executed from a command line as well. For information on parameters supported by this command execute it without providing parameters.

The installer sdcnfmig executable is used for information regarding migration of the ASM.CNF file. This executable loads rdcnf DLL/SLIB to read local ASM.CNF and write to the r11 comstore. It can be executed on command line as well. To view the list of supported parameters execute the command without providing any parameters.

OSIM Specific Information

The following OSIM data is migrated:

OSIM OS images and OSIM Boot images. Default parameters are kept synchronized.

OSIM Configuration. Current states of OSIM computers are migrated

OSIM Computer Groups

The prerequisites include:

Target computers must be migrated first (run the SD migration job)

OS Images must be migrated manually (see the DSM Implementation Guide for a description)

Collect all information to access the SD 4.0 database (including database type, host, database name, credentials)

OSIM Migration imports data related to Operating System installation from a SD 4.0 Local Server into r11. This includes parameter values and SD 4.0 OSIM groups.

There are two kinds of parameter sets:

default parameter values of OS images. The parameters of each SD 4.0 OS Image are mirrored to the r11 OS image with the same name.

current parameter values of target computers (taken from the last successful installation). The current parameters of each SD 4.0 OSIM computer are mirrored to the r11 computer with the same name.

Log file: TRC_Migration_CSM.log

An r11 group is created for each SD 4.0 OSIM group and an ‘-r4’ suffix is added to the name of the new r11 groups. Memberships are updated on the next run.



OSIM Data Migration Implementation

OSIM data migration runs as an Engine job and is implemented as a DLL (ccsmmig.dll) or a UNIX library (libccsmmig.so) depending on the platform.

Unicenter Asset Management Specific Information

The following Asset Management data is migrated:

Computers – including State “Legacy.” Use migration scope to identify which computers to migrate.

Static Groups (also link members)

Dynamic Groups - depending on which queries are migrated

Computer General Inventory

Computer Software Inventory - depending on which Software Definitions are migrated

Jobs. Note that these are not linked to groups or assets. Status will not be migrated.

Templates

Configuration Files

Queries. Although most will be migrated automatically, those that are not migrated successfully will be flagged.

Query based policies - depending on which queries are migrated

Event Policies

Categories

Publishers

Application Definitions. Note that heuristic applications will not be migrated.

Only Software Definitions with corresponding software in UAM 4.0 will be migrated, unless the Software Definitions belong to a Category labeled 'Migration'.

Report templates

Scheduled Reports

Asset Management Specific Data Migration Process

Following is the process by which Asset Management specific data is migrated:

1. DSM connects to the Legacy Database

2. Important data is verified and loaded into cache



3. Each individual configured item is migrated

4. Legacy Database is closed

The list of legacy objects is maintained in the amlegacy_objects table. This table maps UAM 4.0 primary key and r11 primary key for each object. Objects that are mapped will not be migrated again (with the exception of an update of inventory on Computers).

With the exception of Computers, objects will be mapped to existing r11 object if the object name matches. Computers are mapped to existing computers if host_uuid are the same or if host_name is the same.

A computer’s General Inventory and filescan based Software Inventory is migrated (Software Definitions for these, however, have to be migrated).

To verify migration status, check the TRC_MIGRATION_UAM_0.LOG which is found in the \CA\Unicenter DSM\logs directory. This file provides runtime logging.

Remote Control Specific Information

The following data is migrated for the Remote Control component:

Computer Groups

Global/Local Address Book Information

Computers. State will be listed as “migrated.” Use migration scope to identify which computers to include.

Configuration Policy Data

All necessary data for each object type is copied from the Remote Control r6 database to memory and each object is inserted repeatedly. Some object types are updated if already present depending on responsibility. Inserting duplicates does not interfere with migration.

Computer -> ca_discovered_hardware(machine), ca_agent( RC status “Migrated”), ca_group_member(group membership)

ComputerGroup -> ca_group_def(r11 group), ca_agent, ca_group_member(group membership)

Address book data -> ca_group_def(r11 group), ca_agent, ca_group_member(group membership), urc_ab_group_member(indicating address book), urc_ab_computer(with connection addresses), urc_ab_permission(permissions for address book groups)

You can delete objects in the DSM Explorer and migrate again to recreate them.


DSM and NAT

Note that configuration policies are not deleted instantly although you cannot see them in the GUI any longer.

Remote Control r6 address book groups are transformed into standard r11 groups plus some extra address book properties. R6configuration policies are added to the r11 configuration via CCNF client calls. The sequence of calls is generated from the r6 data in memory.

To view migration status, check the TRC_MIGRATION_URC_0.LOG file. You can also check the Engine Status.

Remote Control Data Migration

Data migration for URC is managed through the rcLegacy.dll and the rcManagerR11Migration.exe. The Engine calls rcLegacy with the data provided by the Migration Wizard and rcLegacy builds a command from the data and executes it.

This command can also be run standalone. For information on the syntax, execute the following:

rcManagerR11Migration.exe -?

DSM and NAT DSM r11 can function within a network using Network Address Translation (NAT) or Port Address Translation (PAT) network but there are some additional considerations, limitations and configuration requirements that need to be understood. This section describes some basic testing that was carried out on a DSM r11 deployment within a NAT’d network environment.

Note: No firewalls were in place during testing.

Overview

There are different types of NAT:

Static NAT - Maps an unregistered IP address to a registered IP address on a one-to-one basis.

Dynamic NAT - Maps an unregistered IP address to a registered IP address from a pool of registered IP addresses.

Overloading – Similar to dynamic NAT, it maps multiple unregistered IP addresses to a single registered IP address by using different ports. This is also called PAT (Port Address Translation).


DSM and NAT

Typically, NAT routers are used to provide a degree of security and to enable re-use of IP addresses. In the former case, end systems are hidden behind a NAT router using either Static or Dynamic NAT. In this way the end system’s internal, configured IP address is never exposed to systems beyond the router. In the latter case, PAT or NAT Overloading is used to counter the decreasing number of available registered IP addresses.

PAT presents the biggest challenges for DSM and is, therefore, the focus of the following tests. PAT essentially stops any direct connections from beyond the router from reaching systems connected to the local LAN.

DSM uses the following two proprietary communications technologies:

CAM

TCP Stream via Port Mux (used by DTS, the NOS-less file transfer component and the RC video stream).

Since CAM uses the message’s source IP address to identify an end system this may cause a problem in an Overloaded NAT network where the source IP address will always be that of the router. When CAM receives a second connection from the same IP address it discards the first as an apparent duplicate. Since response messages would not be able to get back to the system that made the first request this could cause a problem.

With the exception of Asset Management the same behavior was used in the previous releases. Prior to r11 Asset Management could use file shares as sectors, or use the AM connectivity server. As a result, users were able to design different working solutions through these alternate mechanisms in order to suit their needs and their network configuration. In r11, these options are replaced by CAM.

Fortunately, CAM will work when communicating out from a PAT configured network but only if something else from the same PAT configured network doesn’t come along in the middle of a message exchange. The effect of this may be minimal in a normally quiescent network and, even in a DSM network with moderate activity where application code may experience connection failures or timeouts – though the code should retry and recover. A very active CAM network, however, may be significantly affected.

Scenario 1: Scalability Server as Proxy Router

In this example, the network incorporating a NAT/PAT router was configured as follows:

A DSM Domain Manager was connected to the example Corporate Network

A DSM Scalability Server was connected to the NAT router with a static NAT address appearing as 10.100.1.100 to connections via the WAN and 192.168.2.10 locally.


DSM and NAT

2 DSM Agents were connected to the DHCP based, NAT’d (PAT’d) LAN.

In this scenario the Scalability Server is essentially in the DMZ, so that both the WAN and NAT’d LAN can see it, but with different IP addresses. The DSM Agents are hidden from the WAN.

The test network was not connected to the domain network for security reasons and, as such, a DNS service was not available. To that end etc/hosts file entries were used for machine naming.

Also NOTE that no firewalls were in place.


DSM and NAT

In this scenario the Scalability Server successfully registered with the Domain Manager and agents successfully connected to the Scalability Server for registration and inventory upload. However, this information was not collected by the Engine.

Problem 1: CAM in the DMZ

The DSM Domain Manager Engine was unable to connect to the DMZ Scalability Server and “Unable to Open….” Messages were written to the Engine event log.

From the Manager’s perspective, the Scalability Server is known by its external address (10.100.1.100) and, therefore, CAM messages are directed to this address. The Scalability Server, however, actually knows itself by its NAT address (192.168.2.100) and so attempts to forward the messages sent from the Manager to an address that is unreachable.

Solution

CAM needs to be configured on the Scalability Server to route messages sent to its WAN address to itself via a simple cam.cfg rule. Add a ROUTING rule to the cam.cfg file that directs messages destined for 10.100.1.100 to localhost. For example:

*ROUTING

forward localhost 10.100.1.100

The Engine can now successfully contact the Scalability Server and the new computers and their inventory is collected.

With this solution in place the following functionality has been validated as functioning correctly via limited, ad-hoc testing.

Agent registration

Inventory collection

Common configuration

Asset Jobs

Agent RC Viewer Global Address Book retrieval

Agent RC Host Authentication

Agent RC Viewer to Agent RC Host

Agent RC Viewer to Scalability Server RC Host

Manager RC Viewer to Scalability Server RC Host

Scalability Server RC Viewer to Agent RC Host


DSM and NAT

Note how the latter two entries mean that an RC Viewer running at the Manager can control an Agent by hopping through a Scalability Server.

Problem 2: Infrastructure Deployment

Infrastructure Deployment fails to discover the end systems during the scan phase and, even if it could, file share and telnet access is not possible because the end systems are hidden from the Manager.

Solution

Failure to discover and connect directly to end systems is, as it should be, and, as such, there is no real solution for the discovery and primer transfer. However, it is possible to instruct the Deployment Manager to skip the IP ping that it uses to detect end systems. If the ping is skipped the Deployment Manager attempts to connect to the dm_primer directly. If the dm_primer is already installed on the end systems with the appropriate Manager key file (perhaps via logon script execution of the dm_setup package) and CAM traffic intended for the NAT network is routed through the Scalability Server then deployment is possible and successful.

Note: This problem also occurred in previous product releases.

The Manager’s instance of CAM is configured to route all messages to the Agent addresses via the Scalability Server as follows

*ROUTING

forward 10.100.1.100 192.168.1.*

This enables CAM communications from Manager to end system via Scalability Server.

Problem 3: AM/SD Job Checks

An AM/SD job check request from DSM Explorer to Agent does not work.

Solution

A combination of CAM routing rules at the Manager and host file entries solves this problem. First, hosts file entries for the end systems are added as follows:

agent1 192.168.1.129

agent2 192.168.1.130


DSM and NAT

This enables the names of the end systems to be resolved to IP addresses. Next, the Manager’s instance of CAM is configured to route all messages to these addresses via the Scalability Server as follows

*ROUTING

forward 10.100.1.100 192.168.1.*

This enables CAM communications from Manager to end system via the Scalability Server. However, this is not ideal since, in a domain with multiple NAT’d networks, each private NAT addressing scheme would have to be different (in other words, the end system’s private IP addresses would have to be unique within the DSM domain). In addition, since a DNS is not used to resolve the addresses and DHCP is used on the NAT’d networks, agent addresses might change and become out of sync with the hosts file.

Recommendation

In this case, our recommendation is simply to not run manual, ad hoc job checks. There should be very little need to do so in a properly configured, managed enterprise.

Scenario 2: Agent as CAM Proxy

In this scenario all CAM communications are routed through the CAM proxy using appropriate CAM ROUTING rules on the Agents and Scalability Server.


DSM and NAT

Similar to the previous topology, the agent1 machine is placed in the DMZ and, since it is known by a different IP address externally, a CAM ROUTING rule is required to ensure all traffic sent to its external address is processed locally.

To do this, add a ROUTING rule to the cam.cfg file that directs messages destined for 10.100.1.100 to localhost. For example:

*ROUTING

forward localhost 10.100.1.100

In addition, now that agent1 is acting as a CAM proxy, CAM traffic from the Scalability Server destined for agent2 must be forwarded to agent1. So the following routing rule must be added to the Scalability Server:

*ROUTING


DSM and NAT

forward 10.100.1.100 192.168.1.*

With this solution in place the following functionality has been validated as functioning correctly via limited, ad-hoc testing.

Agent registration

Inventory collection

Common configuration

Asset Jobs

SD jobs

SD Catalog

Agent RC Viewer Global Address Book retrieval

Agent RC Host Authentication

Agent RC Viewer to Agent RC Host

Manager RC Viewer to agent1 RC Host

Scalability Server RC Viewer to agent1 RC Host

Problem – Infrastructure Deployment

Infrastructure Deployment fails to discover agent2 during the scan phase and, even if it could, file share and telnet access is not possible because the end system is hidden from the Manager.

Solution

Failure to discover and connect directly to end systems is, as it should be, and, as such, there is no real solution for the discovery and primer transfer. However, it is possible to instruct the Deployment Manager to skip the IP ping that it uses to detect end systems. If the ping is skipped the Deployment Manager attempts to connect to the dm_primer directly. If the dm_primer is already installed on the end systems with the appropriate Manager key file (perhaps via logon script execution of the dm_setup package) and CAM traffic intended for the NAT network is routed through agent2 then deployment is possible.

Note: This was also the case with previous versions of the products.


Chapter 6: Startup and Configuration

This chapter takes a closer look at the interaction between components including:

what happens when DSM r11 boots up

infrastructure configuration process

Agent registration process


Implementation Guide





The following techdocs also provide useful information:

“When installing R11.2 with Common Services how does it handle having existing versions of NSM components already installed on the server” (TEC426063)

“Configuration Policy to hide the System tray applet from users (TEC425430)

“Initialization failed error when the CAF command is used at the UNIX console” (TEC422439)



What Happens at Startup? What happens when a machine running DSM r11 boots up? To answer this let us first consider a computer that is running a full DSM Domain Manager with all products (UAM, URC, USD) and components installed (including Scalability Server, Agent and Web components).

September 2007 Chapter 6: Startup and Configuration 6–1




What Happens at Startup?

Nearly every DSM process is controlled via CAF. In essence CAF starts up and then starts up all configured plug-ins.

There are a couple of exceptions which are mentioned here for completeness

cfusrntf.exe is invoked transiently whenever a user logs in to a system. This is used to capture user accounts.

sxplog32.exe is invoked persistently whenever a user logs in to a system. This is used to apply sxp package settings within a user context i.e. it is only used when an sxp package is installed. This is started via the registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\DsmSxplog

cf_SysTray.exe is invoked persistently whenever a user logs in to a system. This is used to provide a menu applet within the system tray area of the desktop. It is started via the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\CAF_SystemTr

ay

The following diagram provides an overview of the startup process.



CAF reaches a steady state with the following threads awaiting stimulus:

Main thread is waiting on Service Control events

ServiceMain thread is waiting within the main CAF message processing loop

Scheduler thread is waiting in timed loop on scheduled events

SM endpoint (U-CAF) is waiting on CAM messages (with thread pool of 1)

PortMux thread is waiting in timed loop on status change flag and socket connections

Each instance of cfPlug-in has a thread waiting for messages from the cfRuntime IPC pipe.

Tip! You can run the following command to query CAF for the current status of all plug-ins.

caf status

The output should look something like this…

Querying caf for status information...

Unicenter DSM r11 Common Application Framework 11.0.8024.234

Showing running DSM services...

[1] Asset Management manager (ammanager)

[2] Asset Management performance agent (ampmagent)

[3] Asset Management server (amrss)

[4] Asset Management usage server (amms)

[5] Certificate exchange plug-in (cfcertex)

[6] Common Server (cserver)

[7] Common object manager (cmobjectmanager)

[8] Configuration agent (ccnfagent)

[9] Configuration and State Management agent (ccsmagt)

[10] Configuration and State Management agent controller (ccsmact)

[11] Configuration and State Management database api server (ccsmapi)

[12] Configuration and State Management server (ccsmsvr)

[13] DSM Service Locator plug-in (cfsvclocator)

[14] Data Transport network object server (dtsnos)

[15] Data Transport schedule object server (dtssos)

[16] Data Transport transfer agent (dtsagent)

[17] Data Transport transfer object server (dtstos)

[18] Deployment Manager (dmdeploy)

[19] Engine (SystemEngine)

[20] Event notification plug-in (cfnotify)

[21] File transfer server (cfftplug-in)

[22] Notification Server (cfnotsrvd)

[23] Port multiplexer (pmux)

[24] Registration plug-in (cfregister)

September 2007 Chapter 6: Startup and Configuration 6- 3


[25] Remote Control host agent (rchost)

[26] Remote Control manager (rcmanager)

[27] Remote Control server (rcserver)

[28] Session messaging server (smserver)

[29] Software Delivery Boot Server (sdmpcserver)

[30] Software Delivery manager: api server (sdmgr_api_2)

[31] Software Delivery manager: dialog manager (sdmgr_dm)

[32] Software Delivery manager: file transfer (sdmgr_ft)

[33] Software Delivery manager: installation manager (sdmgr_im)

[34] Software Delivery manager: task manager (sdmgr_tm)

[35] Software Delivery server (sdserver)

[36] tomcat server (tomcat)

Note that the list of plug-ins is sorted alphabetically – not in the order in which they are started.

Startup Under Windows

On the Windows platform the following specific actions occur at startup:

1. Session messaging plug-in starts

C:\Program Files\CA\Unicenter DSM\bin\cfsmsmd.exe -t

2. CAF’s own session messaging end point U-CAF is set up

3. Common config agent plug-in (ccnfagent) starts up

C:\Program Files\CA\Unicenter DSM\Bin\ccnfagent.exe

These three actions always occur first and are, essentially, hardcoded. The following actions occur based on configuration within comstore.

1. Tomcat starts up

2. Infrastructure Deployment Manager (DMDeploy) starts up

C:\Program Files\CA\Unicenter DSM\Bin\DMDeploy.exe start

3. Boot Server starts up

C:\Program Files\CA\Unicenter DSM\Bin\sdmpcworker.exe

4. CSM Server starts up

C:\Program Files\CA\Unicenter DSM\Bin\ccsmsvrd.exe

5. CSM Agent Controller starts up

C:\Program Files\CA\Unicenter DSM\Bin\ccsmactd.exe

6. CSM API Server starts up

C:\Program Files\CA\Unicenter DSM\Bin\ccsmapid.exe

7. Notification server starts up



C:\Program Files\CA\Unicenter DSM\Bin\cfnotsrvd.exe

8. CSM Agent starts up

C:\Program Files\CA\Unicenter DSM\Bin\ccsmagtd.exe

9. Port Multiplexer starts up

10. Software Usage Server starts up

C:\Program Files\CA\Unicenter DSM\Bin\amms.exe

11. Sector Server (amrss.exe) starts up

12. Common Server starts up

C:\Program Files\CA\Unicenter DSM\Bin\cserver.exe start

13. RC Host starts up

C:\Program Files\CA\Unicenter DSM\Bin\rcHost.exe start

14. RC Server starts up

C:\Program Files\CA\Unicenter DSM\Bin\rcServer.exe

15. RC Manager starts up

C:\Program Files\CA\Unicenter DSM\Bin\rcManSrv.exe

16. DTS Agent starts up

C:\Program Files\CA\SharedComponents\DTS\bin\tngdta.exe

17. DTS TOS starts up

C:\Program Files\CA\SharedComponents\DTS\bin\tngdttos.exe

18. DTS NOS starts up

C:\Program Files\CA\SharedComponents\DTS\bin\tngdtnos.exe

19. DTS SOS starts up

C:\Program Files\CA\SharedComponents\DTS\bin\tngdtsos.exe

20. System Performance Agent starts up

C:\Program Files\CA\Unicenter DSM\PMAgent\capmuamagt.exe debug

21. Certificate Exchange plug-in starts up

SM end point = U-CFCERTEX

22. SD Installation Manager (sd_taskm.exe im) starts up

23. SD Task Manager (sd_taskm.exe tm) starts up

24. SD Dialog Manager (sd_dialog_m.exe /L) starts up

25. Common File Transfer plug-in starts up

C:\Program Files\CA\Unicenter DSM\Bin\cfftplug-in.exe)

26. SD Manager file transfer (sd_mgr_ft.exe) starts up



27. SD Scalability Server plug-in starts up

C:\Program Files\CA\Unicenter DSM\Bin\sd_server.exe

28. Common Object Manager starts up

C:\Program Files\CA\Unicenter DSM\Bin\cmObjectManager.exe

29. AM Object Manager starts up

C:\Program Files\CA\Unicenter DSM\Bin\amObjectManager.exe

30. Engine starts up

C:\Program Files\CA\Unicenter DSM\Bin\cmEngine.exe

31. CAF event notifier (cfnotify) starts up using SM end point = CFNOTIFY

32. Common registration plug-in (cfregister) starts up using SM end point = CAITRMAGENT

33. CAF service locator (cfsvlocator) starts up

34. Scheduler is enabled

35. Register job is executed

36. Begin waiting for CAF messages

37. AM Agent starts up

C:\Program Files\CA\Unicenter DSM\Bin\amagentsvc.exe UNIT=

38. SD Agent (sd_jexec.exe UNIT=.AfterReboot) starts up

Startup under Linux

Following is what happens during startup of cmObjectManager under Linux:

1. If Windows, init COM

2. Configuration information is read

3. SM end point (registering callback function) opened

4. OS Event created for shutdown

5. CAF notified that it is ready

6. Wait for shutdown event.

When a shutdown event is received, the cmObjectManager does the following:

1. Stops processing messages

2. Enters an infinite loop waiting for all open threads to finish

3. When all open threads have finished cmObjectManager exits



Following is what happens during startup of common server:

1. Init common components

2. Parse command line

3. Load config

4. Register with CAF

5. Register Server with Manager

Then, it reaches steady state with the following:

1. Main thread waiting on m_trigger_event

2. Notifier thread waiting on m_notify_event

3. CFRuntime thread waiting on IPC CAF messages

4. SM endpoint waiting on SM messages (with thread pool of 1)

By Default, the common server is actually single threaded in terms of processing workload but that configuration can be increased to use SM thread pool.

Following are the key startup activities (in order) when the Engine starts up:

1. Command line args parsed

2. Connect to CAF

3. Configuration read

4. One (1) second delayed loop entered - checking for work every 20 seconds.

Then, it reaches steady state with the following:

1. Main Thread in 1 second timed loop

2. Thread waiting on CAF pipe

Engine tasks may include the following:

Sector collect

Query Evaluation

SQL Script Execute

Reporter job

Legacy Sync (migration)

Replication

External Exe

Domain Dynamic Groups Evaluation

Domain Policy Evaluation


Infrastructure Configuration

Infrastructure Configuration The Unicenter DSM products are configured centrally and locally through a shared component typically referred to as “common config” or “CCNF”. This components acts like an “enhanced Windows registry.” It manages the runtime configuration of practically all of the DSM subcomponents and infrastructure features, though there are some exceptions.

Configuration Policy

In order to simplify administration of configuration parameters, you can group a collection of those parameters into a single configuration policy. Therefore, instead of assigning single parameters to computers or groups, configuration policies are assigned. Configuration policy can be assigned to multiple computers or groups. From the administrator’s point of view, configuration policies are created and maintained independently of any specific computer or group.

There may be some overlap in the parameters defined in configuration policies – one parameter could be defined in more than one configuration policy destined for the same end system. Since only a unique parameter value can be set on a computer, the following rules are used to determine how to proceed when configuration policies overlap:

Policies assigned to a group are inherited by the children of the group. A child can be a group or computer.

In a hierarchy, policies assigned on the child level override the ones on the parent level. In other words, all parameters defined on the parent level are also defined for the child, however, when a child policy overlaps with a parent policy, the child policy ‘wins’.

In all other cases where overlapping policies present a conflict the user will be prompted to resolve the conflict.

Activating Computer Configuration

When the time comes for a computer configuration job to be activated the manager collects the parameters that need to be sent down to the computer.

The configuration job sent down to the target computer will only contain the parameters that have changed since the last time the configuration was sent down.



Reported Configuration

The agent reports parameter settings to the manager. On the manager, these settings are stored in the database where they are referred to by the GUI as the ‘reported configuration’. A full report of all parameters is returned after the very first configuration job has been applied. Subsequent reports only contain deltas.

Configuration Properties

Configuration properties can be:

Centrally managed

Configuration properties are set up through the DSM Explorer and stored in the MDB. They are then evaluated and transmitted down to end systems via the CCNF and CSM (Configuration and State Management) sub-systems.

Locally managed

Here, although the MDB contains entries for the configuration properties the values are set and stored locally.

Locally unmanaged

This state can be set and reset only locally via the ccnfAgentApi. In other words, locally unmanaged parameters can be set to “centrally managed” by the local end system. This essentially puts the manageability of these parameters under end-system control.

These “managed” properties are collected together hierarchically under a configuration policy. Configuration policies can be viewed and manipulated within the DSM Explorer under /Control Panel/Configuration/Configuration Policy.

Tip: When viewing “managed” properties within the DSM Explorer by default you will see their display names. To view their “real” internal names right clicking on the list view column header and select the display “internal names” option.

Unmanaged

Configuration properties exist only on the end systems. These properties typically contain values that are specific to and only useful to the processes that execute on the managed computer.



Enterprise and Domain Policies

On the Enterprise, the following rules apply to policies:

Enterprise policies are replicated to Domains

Enterprise group configuration jobs are replicated to Domains

Enterprise policies can only be applied to groups

On the Domain, the following rules apply to policies:

Enterprise default policy replaces Domain default policy

Policies can be applied to group OR to individual assets.

Reported configuration is only available at the Domain level

Property Storage

Property storage (also known as “persistence”) is maintained in different locations – in the MDB and on the end system itself.

In the MDB

Centrally managed properties and their values, as well as locally managed property definitions (without values), are stored in the following MDB tables

csm_property

csm_object

csm_class

csm_link

Important Note: These tables are also used for storage of OSIM data since CCNF and OSIM both utilize CSM.

The configuration manager processes the configuration policies applied to a specific computer as well as policies applied to any groups that the computer belongs to. It will eventually work out which properties should be set to what value and then pushes these property values down to the end system.

On the End System

The configuration settings for an end system ultimately end up in an encrypted XML file. If you want to know what property values are really being used by DSM on a particular machine, this is the place to look.



Configuration is stored locally in comstore.enc and userstore.enc on each node. This replaces pre-r11 mechanisms such as ASM.CNF, TNGDTS.INI, and Registry. comstore.enc is stored in <DSM install path>\Agent\CCNF while userstore.enc is stored in <Documents and Settings>\<DSM install path>\Agent\CCNF.

Both comstore.enc and userstore.enc are encrypted to avoid direct manipulation.

In addition the file can be decrypted and written to a standard XML format file using the following command.

ccnfcmda –cmd GetConfigStore –fi c:\MyComStore.xml

Below is some example content. It shows some nested parameter sections e.g. “itrm/usd/shared”, as well as a parameter “nos” and it’s value “MS”.

A managed parameter is indicated by an entity value of “Manager.” For example:

When the attribute “write” is set to agent this means the local end system may update the parameter value. For example:



Here you can see an example of a migrated parameter:

Here is an example of locally unmanaged parameters:

Here is an example of an unmanaged parameter:

Extending the Configuration Policy

Additional parameters can be added to the DSM CCNF by doing the following:

1. Create an XML file containing the following definitions:

Parameter name

Location within the hierarchical structure of configuration parameters

Information about how to edit the parameter regarding type, range, description

Default value

2. Register parameter to the database.

For example, to add the parameter “processreportstime” first create an XML (for example “addparam.xml”) and populate it with the following XML definition:



Then register the new parameter by executing the following command on the Manager machine:

ccnfregdb.exe –mlocalhost –fC:\addparam.xml



Processes and Log Files

The following diagram illustrates the various modules and their interaction:

The CcnfAgentApi can work in “direct access mode” and in “message mode”.

Direct access mode is used when the ccnfAgent is not running (such as during setup and CAF startup). In direct access mode ccnfAgentApi reads directly from and writes directly to the comstore.enc and userstore.enc files.

Message mode is used when the ccnfAgent is running. In message mode the ccnfAgentApi communicates with the ccnfAgent via cfMessenger to access configuration data.

The CcnfAgentApi can switch modes as appropriate, such as when the ccnfAgent starts up, terminates or when the underlying messaging component goes down.

The CSM Agent calls ccnfcsmplug-in.dll to process configuration jobs from the manager.

Configuration data is set using the ccnfAgentApi.


Agent Registration

All CAF plug-ins and worker processes are notified about the configuration changes using the internal CAF notification mechanism.

CCNF Agent keeps track of any configuration changes in the common store. The list of parameters to be reported is kept in the following file:

<Unicenter DSM>/Agent/CCNF/paramlist.xml.

This list is initially sent by the manager and will be updated when the DefaultPolicy has been updated.

Ccnfcsmplug-in.dll is triggered by CSM Agent on a regular basis to check for delta reports. It requests a delta report from CCNF Agent and forwards the parameters according to the template list via CSM Agent.

CSM Agent calls ccnfcsmplug-in.dll if a report request arrives from the manager. Ccnfcsmplug-in.dll requests the full report from the CCNF Agent and forwards the data according to the template list via CSM Agent to the manager.

Agent Registration When a DSM agent is installed on an end system the first thing it does is attempt to register its existence with the Domain Manager via its Scalability Server. This registration process is common across all products and includes a limited amount of inventory information (known as “Basic Inventory” or sometimes “Basic Hardware Inventory”). Note that agents register on a regular basis but basic inventory information is delta’d after the first registration.


Agent Registration

Engine [cmEngine.exe]

Common Server – [cserver.exe]

CAF – [caf.exe]

CF Register – [cfRegister.dll]

Basic Inv Collector – [cfbasichwwnt.exe]

TRC_CMENGINE_0.logam.log

TRC_CF_DMDEPLOY_0.log

TRC_CF_CAF_SERVICE_0.log

TRC_CF_REGISTER_0.log

trace

Domain Manager

Session Messaging

trace

Scalability Server

Agent

trace

trace

Create Process


Chapter 7: Software Scanning

This chapter provides a closer look at the Asset Management software scanning process including:

General flow

Processes and log files

Content download process

XML generation process

Transfers from Engine to Scalability Server and from Scalability Server to agent

Enterprise Manager considerations

Import\Export utility

Diagnosis Tips



Inside Asset Management Guide

Unicenter Desktop and Server Management Diagnostics Guide



Overview and Flow DSM r11 has fully incorporated the eVM signature scanner technology which supports the download of a signature database from the online CA Content Management System. This information is stored within the MDB, converted to an XML file and transmitted down to the DSM agent for use by the software detection component.

The key difference between this technique and the technique employed in the previous Asset Management release is that the signatures are available to the agent, and it is the agent that does the software detection. Previously, a list of file information was returned to the manager and the analysis took place there. Shifting the task to the agents helps reduce the load on the manager system.

September 2007 Chapter 7: Software Scanning 7–1


Overview and Flow

The following diagram illustrates the various modules and their interaction:



Processes and Log files The software scanning function uses the following processes and log files:

September 2007 Chapter 7: Software Scanning 7- 3


The Content Management System (CMS) is a central repository hosted by CA and available via the public internet. CMS contains information about all known software, including patch and fix recognition information (signatures).

A Closer Look at the Content Download Process

The Content Downloader is a Java program that is kicked off by the DSM Engine on a scheduled basis. This program, ImportClient.jar, can be found in the following locations:

On Windows: \Program Files\Unicenter DSM\bin\upm

On Linux: /opt/CA/UnicenterDSM/Engine/bin/upm

It writes to the following log file:

On Windows: Unicenter DSM\bin\upm.log

On Linux: /opt/CA/UnicenterDSM/Engine/bin/upm/UPM.log

Tip: The location and format of the log file does not conform to DSM standards. If the downloader fails for any reason it will be indicated in the upm.log file. To check connectivity look for "Contacting ACME Server (contentupdate.ca.com)" messages.

The Content Downloader reads settings from the following configuration file:

Unicenter DSM\bin\upm\config.properties

This file contains information about which database to publish, proxy-server, username and password. Passwords are encrypted and proxy server information is actually read by the Engine from published configuration policy settings and written to the config.properties file.

When the Content Downloader connects to the Content Management System, it downloads new signatures and publishes them to the MDB. Tables affected by the updates to the MDB can include the following:

ca_software_def

ca_company

ca_company_type

ca_country

ca_dir_schema_map

ca_download_file

ca_install_package

ca_install_step

ca_language



ca_location

chip_set

ca_software_signature

ca_category_def

ca_category_member

ca_link_sw_def

ca_class_def

ca_class_hierarchy

ca_source_type

ca_software_type

ca_link_type

ca_software_def_types

ca_software_def_class_def_matrix

The Content Management System and downloader use a message numbering system to ensure that only changes are downloaded. For each object type the downloader asks the content server if any messages above a particular message number (“X”) are available. The value of “X” for each object type is stored in the ca_acme_checkpoint MDB table.

A Closer Look at the XML Generation Process

Whenever changes are made to the ca_software_signature MDB table (via Content Downloader, DSM Explorer, or some other mechanism) a trigger is executed which updates a record indicating that changes have occurred.

"select set_val_lng from ca_settings where set_id=4" will indicate (=1) if the version has changed for Windows

"select set_val_lng from ca_settings where set_id=5" will indicate (=1) if the version has changed for UNIX

"select set_val_lng from ca_settings where set_id=6" will give you the version number for Windows

"select set_val_lng from ca_settings where set_id=7" will give you the version number for UNIX

When the Engine contacts a Scalability Server with the intention of updating signatures it does the following for both Windows and Linux signatures:



Checks if the “version has changed” flag is set (see above). If it is, the version number is incremented by one and the "version has changed” flag is reset.

Compares the MDB contents version number with the latest version number that the Engine has. This is extracted from the file names of the existing signature files.

For Windows signatures, the file name is “Wnnnnnnn.XML” and for UNIX signatures the file name is “Ummmmmmm.XML” where nnnnnnn and mmmmmmm designate the version. For example, “W0000006.XML” is version 6 of Windows while “U0000005.XML” is version 5 for UNIX.

If the MDB version is higher than what the Engine has, the Engine generates a new XML file and puts this into the following locations:

– For Windows: \Documents and Settings\All Users\Application Data\CA\eso_fingerprints

– For UNIX\Linux: /var/eso_fingerprints

A Closer Look at the Engine Transfer Process

Next, the Engine checks to see if the Scalability Server has the latest signatures (in comparison to the ones most recently generated by the Engine). If not, it sends them down to the Scalability Server. The signatures are compressed during the transfer process in order to keep network load down. The Scalability Server stores the updated, compressed signature files in the following locations:

For Windows:

\Program Files\CA\Unicenter DSM\ServerDB\SECTOR\SSFW\Wnnnnnnn.ZML

\Program Files\CA\Unicenter DSM\ServerDB\SECTOR\SSFU\Lnnnnnnn.ZML

For UNIX\Linux:

/opt/CA/UnicenterDSM/Server/serverdb/SECTOR/SSFW/Wnnnnnnn.ZML

/opt/CA/UnicenterDSM/Server/serverdb/SECTOR/SSFL /Lnnnnnnn.ZML

A Closer Look at the Scalability Server Transfer Process

The XML documents are used by the software detector module that runs on the end system and they are downloaded by the DSM Agent from the Scalability Server if appropriate.



The DSM Agent launches the Asset Management agent plug-in (amagents.exe for Windows and amagent for Linux) which, assuming software detection is configured to run at that time, first contacts the DSM Scalability Server to get the latest XML Signature file.

The first time the DSM Agent pulls the signature database file from the server it will also retrieve the revision number. The second and subsequent times that the agent requests the signatures it passes the current revision number to the Scalability Server and will only get a new signature database if there is a new revision.

After transfer, the file is stored (uncompressed) locally on the following locations of the end system’s hard drive:

On Windows: \Program Files\CA\Unicenter DSM\agent\units\00000001\uam\Wnnnnnnn.XML

On UNIX\Linux: /opt/CA/UnicenterDSM/Agent/AM/data/work/lnnnnnnn.xml

The software detector is launched via amosoftscan.exe (Windows) or amosoftscan (Linux) and writes to the TRC_UAM_0.log file. The scan applies any signature file differences provided by the agent in order to get a complete and up-to-date signature file.

Note: The signature scanner itself does not produce a log file; however, it does create a results file in the following locations:

On Windows: \Program Files\CA\Unicenter DSM\agent\units\00000001\uam\bak\amsoft.xml

On UNIX\Linux: /opt/CA/UnicenterDSM/Agent/AM/data/work/BAK/amosoft.xml

This creates a file containing the differences between the new scan result and the previous one. On UNIX\Linux, it is stored in the following location:

/opt/CA/UnicenterDSM/Agent/AM/data/work/amosoft.dat

The agent plug-in then takes this results file and sends it to the Scalability Server.

Tip: To run the signature scanner manually use the following syntax on Windows:

amswsigscan <signature file> <result file>

On UNIX\Linux, use the following syntax:

camevmscli <signature file> <result file>



In both cases the <signature file> would typically be the XML file located in the working directory and the results file will be the XML file containing the result of the scan.

The results file is sent to the Scalability Server in the same way as any other hardware or software inventory file and it ends up in the following folder:

On Windows: \Program Files\CA\Unicenter DSM\Server DB\SECTOR\COLLECT\00000001

On UNIX\Linux: /opt/CA/UnicenterDSM/Server/serverdb/SECTOR/COLLECT/00000001

The naming convention for the file is:

HOST_UUID.Wnn

The DSM Engine later collects the file and populates the MDB appropriately.

Using an Enterprise Server

It should be noted that only custom software signatures defined at an Enterprise Manager are replicated down to Domains. However, all discovered software is replicated up to the Enterprise Manager from the Domain Managers.

A Closer Look at the Import\Export Utility

The Import\Export utility, which is available in r11.2, is a command line tool configured through an XML file that provides the ability to share software definitions between DSM Domains that are offline. This supports custom created software definitions and CA provided software definitions as well.

The utility uses BULK functionality and requires installation of the Microsoft SQL Client. For more information see the Inside Asset Management Guide.

The Import\Export utility is executed through the following syntax:

Run \bin\Contentutility.exe

This creates a content_utility.xml file which MUST be modified prior to performing the actual import\export. Following is an example of this file:



Here you can see the process running:

The following log files are written to the \bin directory:

ContentUtility.log

Contentutility_%hostname%.log

By default, contents files are located in Windows application data folder under \ca\software_definitions:


Diagnosis Tips

Diagnosis Tips If you run into problems running a software scan, check to see that the latest XML file for the Engine is valid. To do this load the XML file with an XML viewer (for example, a web browser). If it contains errors (wrong XML) then delete all XML files in that directory. They will be automatically regenerated by the Engine.

If the signature file gets corrupted at the agent level the scan will most likely not produce any results. A simple way to check the file integrity is to load it in a web browser. If the browser complains about the syntax then it is likely that the scanner will too.

The software signature scanner can be run manually with the -DEBUG switch to reveal further information about what's going wrong.


Chapter 8: Remote Control Connection

This chapter provides a closer look at the Remote Control connection including:

General flow

Processes and log files

Getting the authority list

Connection to the desktop

Displaying confirmation dialogs

Starting remote control

Security components

RC messenger

Diagnosis tips



Inside Remote Control Guide


The following techdocs can also provide useful information:

“How to Centralize Security in URC r11” (TEC401138)

“Why does my 3D Application/DVD Player display as a black window on the URC Viewer?” (FAQ314784)

“Can I use Unified Login to establish a connection via Unicenter Remote Control Viewer or the Desktop and Server Management Explorer to a remote host with all security providers?” (FAQ394668)



Overview and Flow The Remote Control function essentially allows a user of a Windows computer to access a remote Windows or Linux computer as if they were sitting in front of the physical machine. All keyboard and mouse input is relayed to the remote computer.

September 2007 Chapter 8: Remote Control Connection 8–1


Overview and Flow

In a managed environment Remote Control Viewers and Hosts communicate with DSM Scalability Servers and Managers in order to retrieve address book information, validate/authenticate users and retrieve permissions for valid users. The process flow is as follows:

1. Obtain Connection Information

Global Address Book

Local Address Book

Quick Connect

2. Obtain Authority List

This is not required for “Local” security mode and the User doesn’t have to do this explicitly.

3. Validate Credentials via:

Locally Managed Security

Centralized Security

Security Cache/Fail-Safe

4. Connect to Target Desktop (control User Input)

5. Prompt User to Display/Connect to Host GUI

6. Start Remote Control Session and load video capture



Processes and Log files The remote control connection function utilizes the following processes and log files:

TRC_URC_HOST GUI_n.log TRC_URC_HOST_n.log TRC_URC_VIEWER_n.log

TRC_URC_UTILCMD_n.log

TRC_URC_SERVER_n.log

TRC_URC_MANSRV_n.log

Host GUI(cfSysTray.exe)

Capture Helper(rcUtilCmd.exe)

Host(rcHost.exe)

Viewer(EGC30n.exe+Gui_rcView.dll)

RC Server(rcServer.exe)

RC Manager(rcManSrv.exe)

TCP

RC Session

SMRegistration+ authentication

SM Address books

SM Host Commands

SM Registration + Authentication

SQL

Getting the Address Book When the Remote Control Viewer connects to the DSM Manager and requests up-to-date address book information RCAddressBookManager compiles the address book according to validated user’s permissions.

September 2007 Chapter 8: Remote Control Connection 8- 3

Getting the Authority List

Depending on which manager hierarchy is in place, the Global Address Book that is returned may be either a Domain Address Book or an Enterprise Address Book.

The following MDB Tables are used to store address book information:

urc_ab_computer – Computers in the address books

urc_ab_group_def – In which groups computers/groups appear

urc_ab_groups_member – In which groups computers/groups appear

urc_ab_permission – User permissions applied to a group

RCMgrAddressBook caches the information locally on the Viewer where it is only used if the manager connection fails.

Getting the Authority List The following process is used to obtain the Authority List:

1. Viewer establishes connection to Host and sends M_STATUSQUERY

2. For Centralized Security the following occurs:

RC Messenger sends request to RC Server (or Manager)

RC Server forwards request to RC Manager

Manager returns authority list and authentication scheme list from CCL security

Host caches the list

3. Host sends M_STATUSREPLY to Viewer containing results



Here you can see a graphical depiction of the process:



Centralized User Validation

As you can see in the following graphic, a series of communications occur across the Viewer, Host and Managers during centralized user validation:


Connecting to the Desktop

Cached\Fail Safe Validation

Following is a graphical depiction of cached\fail safe validation authentication process:

In this method there is no communication to the Domain Manager.

Connecting to the Desktop Terminal Services allows several users to log onto a machine at the same time. XP Fast User Switching is a specialized case of this multi-login capability. On Windows NT4 and earlier there is effectively only one Terminal Services session. On Linux each local X Server (in X terminology it is the X Server that is responsible for rendering a desktop) is treated as a Terminal Services session.

Each RC Session (CRCSession object) is associated with a CRCTerminal object. The CRCTerminal object represents the Terminal Services session to which the RC Control session is connected. Currently, RC can only control the “Console” TS session - the session currently connected to be controlled by the remote machine’s local keyboard, mouse and display. However, RC Sessions can switch between TS sessions if the console switches.



Terminal Services Obstacles

On Windows, a process can only interact with the desktop of a Terminal Services session if it is running in that session. On Linux, the processes that use the XLib API can be terminated by the API unexpectedly.

It is the RC Host that interacts with the desktop when simulating user input. The CRCInput object of rcOS.dll implements this functionality in the following manner:

If direct access to the target TS session is not possible, a CRCInputProxy object is created by CRCTerminal::GetInput.

CRCInputProxy::Init uses ICFOSTerminalServices::CreateProcessInSession to spawn a privileged instance of rcUtilCmd.exe in the target session.

Note: Prior to Windows Vista, a winlogon notification DLL, rcLoginExt.dll is sometimes required.



rcUtilCmd creates a CRCInputClient object, which opens an IPC pipe to the parent process. CRCInputProxy serializes the API calls made through IRCInput, and sends them via IPC to the Input Client. The Input client reads messages from a thread, CRCInputClient::ProcessPipeMessages and calls into a real CRCInput instance, returning the results through the IPC channel.

The RCInput API is synchronous. API calls which have a return value block until the results are returned. To the Host, CRCInputProxy behaves exactly like CRCInput

The rcHost.exe service process cannot display user interfaces directly, this is primarily due to security concerns running as the System user and Fast User Switching/Vista Compatibility.

rcHost controls the RCHostGUI component in another worker process. Normally RCHostGUI runs inside CAF’s system tray process (cfSysTray.exe) though it can be launched inside a dedicated rcUtilCmd process if cfSysTray is not available.


Displaying Confirmation Dialogs

rcHost controls the Host GUI through the IRCHostGUI interface while CRCHostGUI provides the actual implementation of the GUI, including the system tray menus.

CRCHostGUIProxy implements the IRCHostGUI interface, transparently proxying all calls to the CRCHostGUI object in the GUI worker process.

CRCHostGUIStub reads messages from the GUI Proxy, and converts them into calls into CRCHostGUI

CRCGUIPipe implements the IPC between the proxy and the Stub

The Chat GUI shares the RC GUI pipe connection with the system tray if available. Otherwise, a dedicated rcUtilCmd.exe process hosts the chat GUI for each Terminal Services session

Displaying Confirmation Dialogs Each CRCTerminalObject controls the Host GUI for that TS session. CRCTerminal objects are created on-demand. The Host GUIs run independently, and listen for connections on their IPC GUI Pipes

CRCSession::GetConfirmation() checks to see if end-user confirmation is required. If no one is logged on, the “override confirm at login” policy is used to determine what to do. If confirmation is required, a WAITFORCONFIRMATION message is sent to the viewer, to update the UI.

The IRCHostGUI::ShowConfirmDialog function is called to prompt the user. The result from the dialog is sent as a WM_ENDDIALOG message via the Host’s internal message loop, and processed in CRCSession::ProcessMessage.

If all is successful, CRCSession::AcceptLogin is called, which sends an M_CONNACC message to the Viewer.

Starting Remote Control Once the login is complete, the Viewer sends M_CONNACC, VIEWER_PROTOCOLS and VIEWER_FONT_CACHE messages to the Host. When received, the host calls CRCSession::StartViewing, from the main host thread.

The video capture components for the target TS session are managed by a CRCDisplay object owned by the CRCTerminal. The CRCDisplay object maintains a list of “Graphics Targets”, which includes RC Sessions, per-session host side recordings and manual recording sessions.


Diagnosis Tips

The CRCDisplay object owns the RCVideoCapture & RCGraphics components.

RCConfig and RCTrace

RCConfig emulates the old IRCConfig interface. It sits on top of DSM’s common configuration (i.e., comstore) and converts IRCConfig interface calls to CCNF Agent API.

RC Config Keys are DSM Paramsections

RC Config Values are DSM Parameters

RC Config Settings are DSM attributes within a Parameter

RCTrace emulates the old IRCTrace interface. It sits on top of DSM’s common tracing (i.e., cftrace) but it does not trace line numbers or source files. New RC code will use CCL tracer directly.

Diagnosis Tips The video capture threads process an incredible throughput of packets. There is no tracing during normal operation of the video capture after start up.

Beware of threads when analysing the Server or Manager logs. There can be several worker threads servicing different requests concurrently. Use a log analyser to filter out irrelevant execution paths.

The tracing from the RC Viewer GUI can be spread across a number of trace files. Some of the common components are shared between the different GUI plug-ins, so the trace from these components will appear in the wrong place. Use a log analyzer to combine the log output, and then filter.

CCNF, RC Messenger and Session Messaging produce a lot of tracing so filter it using a log analyser. The following trace files are available:

TRC_URC_HOST_n.log – rcHost process logs

TRC_URC_HOSTGUI_n.log – Host GUI logs, from system tray

TRC_URC_UTILCMD_n.log – rcUtilCmd worker logs

TRC_URC_VIEWER_n.log – RC Viewer GUI log

TRC_URC_WRAPPER_n.log, TRC_URC_REPLAYER_n.log – Viewer trace from CCL may appear here

TRC_URC_SERVER_n.log – Server logs, very heavily laden with noise

TRC_URC_MANSRV_n.log – Manager logs


Chapter 9: Delivering Software

This chapter provides a closer look at the software delivery process including:

General flow

USD Shares

USD Directory structure

Key USD files

Key USD MDB tables

OS processes, names, aliases and trace files for USD and DTS

Process flow and log files for USD and DTS

DSMinfo Collection Guide

Troubleshooting tips

Additional DTS Considerations


Inside Software Delivery Guide



The following techdocs provide useful information regarding Software Delivery:

“Creating a package to run Applyptf” (TEC401118)

“Controlling the content of a catalog based on the Active Directory (AD) organizational unit (OU) of a computer or user profile” (TEC424335)

“How to cancel a Software Delivery job that is scheduled for a later date” (TEC426102)

“Registering an MSI Install procedure via the command line” (TEC419921)



September 2007 Chapter 9: Delivering Software 9–1


Overview and Flow

Overview and Flow Following is a graphical overview of the Software Delivery architecture:

Common Stack

MDB File System File System File System

TASKMAN INSTMAN SDSERVER

SDMSIEXEAPISRV DIALOGM

MGRFT (not EM)

DTSFT

WAC

WS

SDDTAFLT

SDDTPUSH

EXPLORER

CADSMCMD

SDDTAFLT

SDSSCMD

SDJEXEC

SDPILOT

SDDTAFLT

CATALOG

SDACMD

Manager Scalability Server Agent

Software Delivery processing can be broken down as follows:

1. The software package is created.

The package must include an installation procedure. The package may optionally include configuration, activation and uninstallation procedures.

2. The software package is registered in the Software Delivery Library.

Depending on administration requirements this may occur at the Enterprise Manager or Domain Manager.

3. The package is distributed to target computers.

This can be either at the request of the administrator (push) or, if catalogs are used, at the request of the target user (pull).


Overview and Flow

4. The package installer is executed

This occurs after the package has been successfully delivered directly to the end system or to an accessible network share the package’s installer is executed.

5. The status of the package delivery/installation is reported back to the originating manager at various stages throughout the process.

One of the first steps in troubleshooting is to determine at which point in this process the problem occurred. For example, the failure of a software package to install on a target may be the result of a faulty package creation, an improper library registration, a communication failure between components during package transfer, or a resource/environmental deficiency on the part of the target system.

The following graphics are provided to give you a better understanding of the communications that occur between each of the Software Delivery components.

First is the relationship between the UI and the Manager:

September 2007 Chapter 9: Delivering Software 9- 3

Overview and Flow

Next is the relationship between the Enterprise and Domain Manager:

Here you can see the Domain Manager to Domain Manager communication:


Overview and Flow

Following demonstrates the distribution of Jobs to Agents:

Here is what it looks like when DTS is used:

Here is what it looks like when using NOS or NOS-less delivery:


Overview and Flow

When DTS is used, activation occurs as follows:


Overview and Flow

Following depicts the effect when NOS is used:

Following depicts the effect when NOS-less delivery is used:


Overview and Flow

Here you can see the response:

The following graphic demonstrates the distribution of orders between the Domain Manager and Scalability Server:


Overview and Flow

The following demonstrates the relationship between the Scalability Server and Agents:

DTS Integration

Here you can see how the process changes when DTS is used:


Overview and Flow

This impacts the relationship between the Enterprise and Domain Manager as follows:

Here you can see the relationship between the DTS Domain Manager and Scalability Server:


USD Shares

The following graphic depicts the relationship between the DTS Domain Manager, Scalability Server and Agent:

USD Shares The following shares are used by the Software Delivery component:

\\<Scalability Server>\SDLIBRARY$

\\<Scalability Server>\SDMSILIB

SDLIBRARY$ share is used by SDJEXEC to identify the location for NOS-based library access by agents. It uses the following configuration parameters:

Itrm/usd/shared/sdlib – specifies share name

Itrm/usd/shared/exportarchive – specifies full UNC

The SDMSILIB share is used by SDMSIEXE (via SDJEXEC) to identify the location for NOS-based access to MSI administrative installations by agents. It uses the following configuration parameters:

Itrm/usd/shared/msilib – specifies share name

Itrm/usd/shared/msiadminpathunc – specifies full UNC


USD Directories

USD Directories The following directories are used by the Software Delivery components:

Library Used By Used For Configuration Parameters

\SD\ASM\LIBRARY APISRV (EM + DM)

TASKMAN (EM + DM)

SDSERVER

SDSSCMD

SDDTAFLT

Permanent location for software packages

Itrm/usd/shared/archive

\SD\ASM\MSILIB SDSSCMD

SDMSIEXE (via SDJEXEC)

MSI administrative software pckgs

Itrm/usd/shared/msiadminpath

\SD\ASM\D TASKMAN (EM+DM)

SDSERVER

SDDTAFLT

Incoming and outgoing DTS transfers

Itrm/usd/shared/incoming

Itrm/usd/shared/outgoing

\SD\ASM\TMP

\FLTSTAGE

SDJEXEC

SDDTAFLT

Incoming DTS transfers

\SD\ASM\LIBRARY \ACTIVATE

TASKMAN (DM)

SDSERVER

SDJEXEC (via share)

Temporary location for s/w pckgs for NOS-based job execution. Uses junction points/symbolic links into \SD\ASM\LIBRARY when possible.

Temporary location for zipped s/w pckgs for NOS-less based job execution

Itrm/usd/shared/asmtemp (+”/activate’”)

\SD\ASM\DATABASE TASKMAN (DM)

SDSERVER

Non-MDB computer info, DTS control files, and host identity and notification data

Itrm/usd/shared/database

\SD\ASM\CONF SDJEXEC

SDMGRMIG

MSI detection file, migration MSI map file, agent state file and text-file based agent customization data


USD Directories

Library Used By Used For Configuration Parameters

\SD\ASM\DEVICE SDPILOT Integration DLL for Palm Pilots, and other device-specific data

\SD\TMP SDJEXEC

SDMGRMIG

Temporary files

\SD\IPC SDJEXEC

SDACMD

Signaling to agent from install programs

\SD\NLS Nearly all SD programs

Stores localized SD resources

\SD\AUTOREG TASKMAN DSM s/w pckgs are located here by the DSM installer and imported to the MDB and SW library at first CAF start of the SD manager

\SD\Legacy Administrator Contains USD 4.0 API install image. Prereq. For SDMGRMIG if API connection to USD 4.0 Local/Enterprise Server is to be successful. Only needed if no co-hosting exists

\ServerDB\SWJORDER SDSERVER Temporary location for s/w job orders and results and s/w detection records. Also location for server-specific agent identity data

Itrm/scalability_server/serverdb_path (+”/swjorder”)

\Agent\units\<unitID>\usd

SDJEXEC Temp location for s/w job orders, results and s/w detection records. Also each <unitID> can represent a computer, user profile or docking device


USD Files

USD Files The following files are used by Software Delivery:

\ServerDB\SWJORDER\<host_uuid>\appl.apc

Used by SDSERVER to queue Software Job orders for agents with HOSTUUID.

\ServerDB\SWJORDER\cachedagdata.xml

Used by SDSERVER for Job results which have not been sent to the manager yet. Also used in stage check mode.

\SD\ASM\DATABSE\hostcert.dat

Used by SDGENERAL.DLL/SO (SDSERVER, TASKMAN, INSTMAN) for storage of public host certificates of remote hosts. Also used for fallback when the remote host is not online when an encrypted S&F message is to be sent to that host.

\SD\ASM\DATABSE\imnothand.xml

Used by INSTMAN for notification events not yet handled by IM during shutdown are stored in this file. On startup these notification events will be loaded and handled before any queued notification events.

\SD\ASM\DATABSE\compdata\<host_dbuuid>.ini

Used by INSTMAN to store information about the agent’s previous domain manager.

\SD\ASM\DATABASE\compjobs\<ss_dbuuid>.tss

Used by TASKMAN to store information about ongoing DTS transfers between DM and SS. Also used to avoid transferring the same package in parallel.

\SD\ASM\DATABASE\compjobs\<job_dbuuid>.job/dtp/dts etc

Used by TASKMAN, DTSFT to exchange transfer information between TASKMAN and DTSFT. Note, no more job specific info here as the USD4.0 FileDB has been removed.

\Agent\units\<UnitID>\usd\sdjexec\<job_cnt_dbuuid>.cof/cwf/crf

Used by SDJEXEC to keep the state of job containers. The extensions are as follows:

*.cof = not started

*.cwf = working

*.crf = completed


MDB Tables

MDB Tables The Software Delivery function uses the following MDB tables:

Table Used for

Usd_swfold Software group, procedure group, catalog group (DM only)

Usd_job_cont Software job container, software policy

Usd_activity Software job, software policy job

Usd_rsw Software package

Usd_actproc Software procedure

Usd_applic Application (DM only)

Ca_group_def Asset group

Usd_v_target Asset

Usd_v_ownsite(EM)

Usd_v_csite (DM)

Enterprise Manager

Usd_v_ownsite (DM)

Usd_v_ls (EM)

Domain Manager

Usd_cont (+usd_cc, usd_carrier) Distribution container

Usd_order (+usd_distsw, usd_distap, usd_disttempl, usd_fio,usd_fitem)

Distribution order

In addition, other supplementary tables, prefixed by usd_* are used.


Process, Trace and Log Files

Process, Trace and Log Files The following process and log files are used at the Manager Level:

Process (EXE) Name

CAF Name Logical Name Description Trace File

Sd_taskm Sdmgr_tm Task Manager Main job evaluation Engine

Trc_usd_taskm_x.log

Sd_taskm Sdmgr_im Installation Mgr. Job results collecting Engine

Trc_usd_instman_x.log

Sd_mgr_ft Sdmgr_ft File Tranfer mgr. File transfer Engine (enterprise r11.2)

Trc_usd_sdmgrft_x.log

Sd_dtsft n/a DTS Integration Legacy file transfer Engine (removed in r11.2)

Trc_usd_dtsft_x.log

Sd_dtpush n/a DTS integration Legacy file transfer Engine (not in r11.2)

Trc_usd_sddtpush_x.log

Sd_apisrv Sdmgr_api_# API server Client counterpart used by UI to perform USD specific operations

TRC_usd_apiserver_x.log

Sd_dialog_m Sd_mgr_dm Dialog Mgr Client counterpart used by UI to obtain free sd_apisrv. Essentially, a dispatcher

Trc_usd_dialogm_x.log

Sd_ahdcmd n/a Service Desk Integration

Used for integration with Unicenter Service Desk

Trc_usd_sdahdcmd_x.log


Process, Trace and Log Files

The following table depicts the details for the DSM Explorer and Scalability Server components:

Process (EXE) Name


Egc30N n/a SD Explorer UI Trc_GUI_x.log

Sd_registerproduct n/a SW Package registrator

Registers SXP, PIF, PKG and RPM packages. Called by DSM Explorer

Sd_server Sdserver SD Scalability Server Plug-in

Handles all software jobs

Trc_usd_sdserver_x.log

The following table depicts the details for the DTS – on the Agent Tier:

Process (EXE) Name


Tngdta dtsagent DTS Transfer Agent

(Master) Persistent DTS agent plug-in that receives commands from TOS and DTS Initiator agent.

(Slave) Launched by master to perform data transfer and send status to TOS

Trc_dtsagent_x.log

Tngdoba DTS Browser DTS Object Browser

Not used by USD Trc_dtsbrowser_x.log

Dtsitrm.dll TCP Protocol wrapper using DSM Networker

Dtstcp11.dll TCP protocol wrapper


Install Packages and Trace Files

The following depicts the details for DTS on the Manager tier:

Process (EXE) Name


Tngdtos Dtstos DTS Transfer Object Server

Main DTS data transfer Engine. Responsible for all managed transfers

Trc_dtstos_x.log

Tngdtsnos Dtsnos DTS Network Object Server

(Not req. in r11.1). Calculates the best transfer route according to CCS WV.

Trc_dtsnos_x.log

Tngdt.dll n/a DTA API Main API used to communicate with DTS (USD, DTS CLI,etc)

TRC_DTS_x.log

Tngdtsos dtssos DTS Scheduler Object Server

Enables scheduling of transfer activations (not used by USD)s

Trc_dtssos_x.log

Install Packages and Trace Files Following is a list of install packages and trace files for Windows installs:

S/W Pckg AfterCopy DSM Install Trace Installer Trace

Manager.msi SDMgrAfterCopy TRC_inst_ITRM_x.log DSMSetupManager.log

Manager.msi DtsManagersAfterCopy +

DtsCommonAfterCopy

TRC_Inst_ITRM_x.log DSMSetupManager.log

Server.msi SDSvrAfterCopy TRC_Inst_ITRM_x.log DSMSetupScalability Server.log

AgtSD.msi SDAgAfterCopy TRC_Inst_ITRM_x.log DSMSetupAgentSD.log

AgtDTS.msi DtsAgentAfterCopy +

DtsCommonAfterCopy

Explorer.msi n/a TRC_Inst_iTRM_x.log DSMSetupExplorer.log


USD Logical Process Flows and Log Files

Following is the corresponding list for Linux installs:

S/W Pckg AfterCopy DSM Install Trace Installer Trace

Ca-dsm-sd-manager.Linux.@pif

SDMgrAfterCopy TRC_*_x.log Ca-dsm.*.log

Ca-dsm-sd-server.Linux.@pif

SDSvrAfterCopy TRC_*_x.log Ca-dsm.*.log

Ca-dsm-sd-agent.Linux.@pif

SDAgtAfterCopy TRC_*_x.log Ca-dsm.*.log

Ca-dsm-dts-agent.Linux.@pif

DtswAgentAfterCopy + DtsCommonAfterCopy

TRC_*_x.log Ca-dsm.*.log

If the installer is driven by the Install Shield master setup (in other words, it is running from the DVD) all installation trace files will end up in the %TEMP% directory of the user that initiated the install. On Linux, the interactive install will generate trace files in the /tmp directory.

If, on the other hand, the installer is driven by an SD Job all DSM install trace files will end up in the system %TEMP% and /tmp directories. The Installer trace will be appended as output to the SD job and reported up to the manager. There it can be viewed (and copied) using the DSM Explorer by navigating to the failed leaf computer job node and opening its properties and choosing the Output tab.

USD Logical Process Flows and Log Files The following graphics depict the relationship between USD logical processes and the log files that are generated. The first graphic applies to the r11.1 release:



Following is the corresponding information for r11.2:


Major Changes between 11.1 and 11.2

Following is the logical process flow and trace files for DTS:

Major Changes between 11.1 and 11.2 Several changes were introduced in the r11.2 update, the most major of which include the following:

CA Common Services (CCS) is bundled with DSM 11.2 which means DTS configuration can be done via WorldView and Calendar and Event functionality is re-enabled for both DTS and USD.

The functionality of Sd_dtsft(.exe) and sd_dtpush(.exe) have been moved to sd_mgr_ft(.exe) for performance reasons.


Collecting Information for Troubleshooting

Sd_gapi(.dll/.so) has been renamed to sd_api(.dll/.so) for binary backwards compatibility reasons.

Collecting Information for Troubleshooting The “dsminfo” tool should be used to collect information for those machines that show problems. If reproduction is required make sure to enable large trace files by issuing the following command:

Cftrace –c set –f USD –l DETAIL –s 300000

Cftrace –c set –f DTS –l DETAIL –s 300000

The –s parameter indicates “size” and specifying a size value of 300000 makes sure traces are not overwritten. After the problem has been successfully reproduced do not forget to change the trace level back to its previous level. This can be done by issuing the following command:

Cftrace –c set –f USD –l ERROR–s 2000

Cftrace –c set –f DTS –l ERROR–s 2000

Even though a failure may appear to only involve a single host most of the time it involves multiple hosts in a distributed environment. Therefore “dsminfo” should be collected from all machines that are involved. For example, if a job fails to execute on an agent, you should always collect the “dsminfo” from the appropriate Manager and Scalability Server in addition to the affected agent.

The USD and DTS audit messages are via the Event Logger; for 11.1 this means that these messages end up in the Windows Application event log and for 11.2 they will end up either in the Windows Application event log or the CCS Event console.

For a list of common troubleshooting tips consult the DSM Diagnostics Guide.

Additional DTS Considerations Be aware that CCS integration is not provided in DSM r11.0 and r11.1. This means that if DTS 3.0 (USD 4.0) has been configured with WorldView to use DTS Routing information then this information will not be available when upgrading to DSM r11.0 and r11.1.

All DTS versions prior to r11 are upgraded to DTS r11 when DSM r11 is installed; DTS does not co-exist with its earlier releases. In this respect DTS is backwards compatible with all earlier DTS versions.


Additional DTS Considerations

Due to an issue in the upgrade process, when DTS is upgraded to r11 it will continue to use its legacy TCP protocol instead of the r11 Networker (port multiplexer component). Whilst transfers will continue to be successful, in environments where firewalls have a limited number of ports opened DTS transfers may fail until the DTS legacy TCP ports are opened on the firewall or until DTS is configured to use the r11 Networker component.


Chapter 10: OSIM

This chapter takes a closer look at OSIM and includes:

Architectural and OSIM component overview

Process and Log file information

Process flow

Installation and configuration

Boot server behavior

Image Prepare System

Sample flow

Under the hood

OSIM and CADSMCMD


Inside Software Delivery Guide



The following techdocs provide useful information regarding OSIM:

“Corrected instructions for creating a WinPE ISO image for use with OS Installation Management” (TEC421113)

“How to manually create an entry on the domain for a PXE machine that has not registered itself yet or how to preregister a PXE machine” (TEC426115)

“Why installation of a Ghost image on a PXE machine overwrites the disk partition definition” (TEC413100)



OSIM Architecture OSIM provides bare metal Operating System (OS) installation on designated targets in an enterprise network provided those targets are able to boot from the network.

September 2007 Chapter 10: OSIM 10–1


OSIM Architecture

The OSIM infrastructure consists of the following:

Manager plug-in that controls the installation process

DSM Explorer and DSM CLI plug-ins

Support for preparation of OS and BOOT images

Tools to setup and configure OS

PXE/TFTP Book Server (a Scalability Server plug-in)

Here you can see how OSIM components fit into the DSM architecture:

Following is a more detailed graphic depicting the relationship between OSIM components:


OSIM Architecture

OSIM queries OSIM plugin OSIM extensions

DSM Explorer CADSMCMD

DSM MDB

OSIM Manager plug-in(CSM)

SD SW librarySD pkg of Boot and OS

image

DSM Domain Manager

OS installation jobs with boot parameter. State of Jobs, Boot Server and Image

Install boot and OS images in the image store of remote Boot

Server

Store info about Boot

and OS images

Register Boot and OS images as SD package

Boot and OS Image Store + FCOROSIM Boot Server

plug-inOSIM Boot and OS

Image Prepare System

Scalability Server DSM Packaging Tools

PXE Target Computer

PXE Data and Boot parameter

Load Boot, OS Image IPS can share

image store with Boot Server

DOS boot diskette and original OS

CD

Custom built WinPE,

including OSIM files

Here you can see:

OSIM Explorer plug-in provides the GUI support for management of OSIM Computers, Images and Jobs.

OSIM CADSMCMD extension provides a command line interface offering the same functionality as the GUI.

OSIM Manager plug-in manages all information about Target Computers, Boot Servers, OS and Boot Images. This information is stored in the MDB.

OSIM Boot Server plug-in runs the PXE and TFTP services that reply to PXE requests from targets and deliver Boot and OS Images respectively.

OSIM Image Prepare System (IPS) provides the functions necessary to prepare and register OS and Boot Images.

September 2007 Chapter 10: OSIM 10- 3

Process and Log Files

Process and Log Files The relationship between the OSIM processes and log files is demonstrated by the following graphic:

There are three steps to performing unattended installation on OSIM targets:

1. Pre-OS installation launched by a Boot Image (mini OS)

For example this may include hard disk partitioning and, in the case of GHOST images, unpacking the image on the partition.

2. OS setup launched by Boot Image (mini OS)

This is the unattended setup of OS Installation and, in the case of GHOST images, preparation of mini setup.

3. Post OS installation launched by OS run once

This includes the delivery of the Admin password, domain integration, and DSM agent installation.

Boot parameters control the auto answer files and installation scripts.

Imaging tools can be used for cloning. However, images must be prepared for unattended mini setup.



Note that the Software Delivery Agent is installed automatically. This ensures that Software Delivery can be use for subsequent installation of additional DSM Agents and applications.

Installation and Configuration The (CSM-OSIM) Domain Manager plug-in is always installed with the Software Delivery Domain Manager. It uses the MDB and the communication of the DSM Manager and has no special configurations itself.

The OSIM Boot Server is a DSM Scalability Server plug-in that requires the following configuration:

Enabling support for Windows network shares (default is tftp)

Selecting destination location for the image store

If the path is not during the installation it can be configured later in the local comstore of the Boot Server with the following command:

ccnfcmda –cmd setparametervalue

–ps /itrm/scalability-server/osim/ManagedPC –pn InstallPath –v <path>

If the Boot Server is configured for share access, on LINUX, the Samba server has to be installed.



If you plan to provide LINUX OSIM images from the Boot Server:

On LINUX the NFS server must be active

On Windows UNIX Services for Windows 3.5 or later must be installed

The Boot Server is active and answers to new targets if no other Boot Server answers. To deactivate and disable the Boot Server process, use the following commands:

caf stop sdmpcserver

caf disable sdmpcserver

To enable and activate the Boot Server process use the following commands:

caf enable sdmpcserver

caf start sdmpcserver

Multiple Boot Server (BS) in a PXE broadcast network

When there are multiple Boot Servers in a PXE broadcast network, the default behavior, from the administrator’s view, is that all new targets will be answered by all Boot Servers. The target picks up the first reply. However, you should be aware that, if two Boot Servers from two Domain Managers are in the same PXE broadcast network the following will occur:

If PXE is enabled later on an existing DSM target, the OSIM target can be picked up and reported to the wrong Domain Manager.

If the responsible Boot Server is down the computer will be picked up by the other Boot Server and can appear in both Domain Managers.

To install an additional Boot Server from the installation media you will need to install the Scalability Server as well because the Boot Server is part of it.

If the Boot Server system already has a DSM Agent installed you can also use Software Delivery to install the Boot Server by selecting the "CA Unicenter DSM Scalability Server" package from the DSM Explorer.

Prioritization of Boot Server with Remote Configuration

In a remote configuration, Boot Server prioritization is specified through the following values:



UseAcle (Use Answer Control List).

This value designates whether or not the Answer Control List (mac.acl) is used to determine which PXE requests are answered.

– If value is 0 the Boot Server answers all PXE requests immediately. Note that only one Boot Server may be in the broadcast network).

– If the value is 1 the Boot Server immediately answers PXE requests of already assigned targets only. See Answer Control List (mac.acl). PXE requests of other target machines will be answer only after a certain number of retries (designated by the DiscoveryRetriesBeforeAnswers setting).

– If the value is 2 the Boot Server immediately answers all PXE requests of known targets. Requests from unknown targets (i.e., not in mac.acl) will not be answered.

DiscoveryRetriesBeforeAnswer (Number of discoveries before answer)

This value specifies the number of retries before the Boot Server sends a default reply to the PXE request of a target not assigned to it.

Meaningful values: “1” to “4” Default value: “3”

This setting is only evaluated if "UseACL" is set to “1”.

DiscoveryTimeoutBeforeAnswer (Time to wait for discovery answer)

This value specifies the number of seconds to wait before a Boot Server sends a default reply to the PXE request of a target not assigned to it.

Meaningful values: “3” to “56” Default value: “10”


Image Prepare System (IPS)

This setting is only evaluated if "UseACL" is set to “1”.

Image Prepare System (IPS) The Image Prepare System (IPS) reads the OS files from the vendor’s media and combines this with the OSIM files to create OSIM OS images and Boot Images. Here you can see an architectural overview of the Image Prepare System (IPS):

Both Boot servers and IPS work with an existing image store, however, IPS also provides setup scripts, tools and configurations for most Windows and LINUX unattended set ups.

Note: OSIM OS images can be based on the original setup or, for cloning on GHOST, PQ images captured from a model computer.

OSIM currently supports the following target operating systems and releases out of the box:

Win9x, WinNT (DOS boot)

W2K, W2K Server (WinPE or DOS boot)

WXP, Win2003 (WinPE or DOS boot)

GHOST images of W2K, WXP, Win2003 (DOS boot)


Example

Redhat 9.0, 3.0, 3.04, 4.0-4.03 (DOS + LINUX boot)

Suse 8.2, 9.0 (DOS + LINUX boot)

OSIM does not include any OS files not owned by CA.

IPS can be installed from DVD from the Packaging Tools. It is installed with a Domain Manager, by default, and can only be installed on Windows. IPS setup is linked with the DSM Explorer.

IPS and Boot Server share the same Image Store (path can be set with the Boot Server setup). If no image store is on the system, IPS commands create a default.

Example This example walks through the following steps for using OSIM:

1. Create Boot Images

2. Register Boot Images

3. Create OS Image

4. Register OS Image

5. Prepare the Target for Network Boot

6. Boot the Target

7. Change the Target to Managed

8. Modify Job Parameters

9. Activate the Install Image

10. Boot the Target to Initiate the install

Create Boot Images

The first step is to create a Boot Image. You can create a DOS Boot Image from a Win98 Boot Floppy or MSClient (if the image is used for share access). The MSClient can be obtained from a Windows NT 4 Server CD or from a Microsoft FTP server.

Another option is to create a WinPE Boot Image. To do this you would start with prepared WinPE in a directory structure and add the CA tools to create an ISO image.

If you use a WinPE Boot image the BOOTDOS network bootloader is downloaded from the Boot Server and executed by the PXE BIOS as follows.


Example

STARTROM loads the WinPE ISO file into a RAMDISK and boots WinPE from the RAMDISK.

WinPE boots and executes osimrun.cmd.

Depending on "$~method$" it either loads the file in the parameter "$WinPEFile$ “ or “$WinPETftp$” from the Boot Server “camenu” and executes it.

The files from "$WinPEFile$“ and “$WinPETftp$” belongs to the OS image and control the OS installation via share or tftp.

If you use a DOS Boot image, the BOOTDOS network boot loader is downloaded from the Boot Server and executed by PXE BIOS as follows:

BOOTDOS simulates a RAMDISK and loads the DOS Boot image from Boot Server into the RAMDISK.

DOS then boots and executes the autoexec.bat.

Depending on the boot parameter "$~method$" (TFTP or SHARE) which is set by the Boot Server, it starts the MS-Client or uses the BIOS PXE TFTP for the next file transfers.

Depending on "$~method$" it loads the file "$BatchFile$“ or “$TftpFile$” from the Boot Server “camenu” and executes it.

The files "$BatchFile$“ and “$TftpFile$” belongs to the OS image and control the OS installation via share or tftp.

Use the CreateBTImages command to create the necessary Boot Image. You will need to provide a directory with the WinPE ISO file, and the WinPE Network boot loader files.


Example

CreateBTImages looks for the Win98SE DOS boot diskette on “A:“ (the A drive) and does the following:

1. Adds MS-Client from a Windows NT4 Server CD or from a given directory to A:\net ()

Note: This is the minimal configuration for share access. Without MS-Client, the image can only be used from Boot Servers using TFTP download.

2. Adds CA tools and files from IPS templates

..\osimips\templates\Dos\net\*.* to A:\net

tftp.exe (tftp download client)

canet,exe (partitioning tool)

ndis.dos (generic network driver using PXE protocol from BIOS)

setopdat.exe (parameter read, substitute)

netstart.bat, protocol.ini, system.ini, wfwsys.cfg, shares.pwl (MSclient configuration)

3. Adds CA autoexec.bat from the following directory:

..\osimips\templates\Dos\AUTOEXEC.BS2 to A:\autoexec.bat

4. Creates osinstal.2 image using copy144.exe


Example

Register DOS Boot Images

Boot Images are registered through the RegisterBTImages command. Here you can see the syntax:

In this example the following syntax was used to register DOS Boot images for both the osinstal.2 and osinstal.3 images to the 677-lab-osim25 DSM Manager:

Registerbtimages –i osinstal.2;osinstal.3 –s 677-lab-osim25


Example

Create OS Image

OS images are created using the CreateOSImage command. Here you can see the syntax:

For example:

Createosimage –i myhost2 –o GHOST-XP –s c:\myhost2 –k abcde-12345-abcde-12345-

abcde

This syntax creates an image called “myhost2” using a Windows XP GHOST image located on c:\myhost2 drive and directory with a product key of “abcde-12345-abcde-12345-abcde.”


Example

Register the OS Image

The OS image is registered using the RegisterOSImage command. The syntax is provided in the following screen:

For example, the following command:

Registerosimage –i myghost2 –s 677-lab-osim25

registers the myghost2 image to the DSM Manager named “677-lab-osim25”.

Here you can see the OS image in the DSM explorer:


Example

Prepare the Target for Network Boot

To prepare the target machine for network boot you need to enable Network Startup in BIOS as seen in the following example:


Example

Boot the Target

The next step is to boot the target in order to have it picked up by the Boot Server. The target returns the following information:

The MAC address of the target (Client MAC ADDR)

The IP address and network mask the target sent from the DHCP server

The IP address of the DHCP server

The PROXY IP which is the IP address of the selected OSIM Boot Server

The IP address of the default gateway sent from the DHCP server

The message that an OSIM Boot Server was selected (CA-Unicenter ManagedPC Boot Server)

Change Selected PXE Target to Managed

To change a PXE target to “managed” once it has been picked up right click on the target and select Managed(unmanaged) from the menu.

Select the OS Image to install and click OK.

Editing the Job Parameter

Installation parameters can be edited by selecting the OS Installation Parameters node as seen in the following example:


Example

Activate the OS Installation Job

Here you can see how the OS installation job can be activated based on a set date and time.

Click OK to set and the target OS installation will start with the next reboot.

Boot the Target to Execute the OS install job

Here you can see that the machine has been rebooted in order to activate and execute the OS installation job.


Under the Hood

Under the Hood The following topics present a more detailed discussion of various OSIM tasks and functions.

Boot Image Tools and Templates

Following is an example of the DOS\Net template files:

These files are introduced into the DOS boot images through the CreateBTImages command and can be used to specify the following:

network access


Under the Hood

boot parameter

OS image handling

The winpe\ca-osim template files are required to specify the following:

32bit access to the Boot Server

32bit parameter

OS image handling

The following file structure is used to store DOS and WinPE Boot Images on Image Prepare System and Boot Server

ManagePC\

images\

dosboot\ Boot disk operating system image store

bootdos DOS network boot loader

boothd Network boot loader which jumps to Hard Disk boot

UNDI\ RAM disk image files DOS, WinPE

osinstal.2 Raw DOS Diskette Boot image (first step)

osinstal.3 Raw DOS Diskette Boot image (second step)

winpex86.2 Boot image description files

winpex86.2\ Boot image directory belonging to the description file

Winpex86.iso

Winnt.sif

Ntdetect.com

ntldr

startrom Boot Loader

Here you can see the OS- image templates under the \camenu folder:


Under the Hood

This directory contains all of the OS templates for preinstall and OS setup including the following:

Windows original setup (for W2kP, W2KS, WXPP, WXPS, W98, WNT4, WME)

Cloning (GHOST, PQIMG (Note no *.ftp,*.cmd,*.ftw))

LINUX original setup

USEW, REDHATW

The following file types are used:

*.Inf: used for auto answer files for unattended setup

*.Osi: use for osinfo.ini with file names of files including parameters

*.Def: used for default.ini parameter definitions

*.Par: used for disk portioning schema

*.bat: Used for scripts to prepare and execute OS setup from DOS when using share access to Boot Server


Under the Hood

*.ftp: Used for scripts to prepare and execute the OS setup from DOS when TFTP access to the Boot Server is used.

*.cmd: Used for scripts to prepare and execute the OS setup from WinPE when share access to the Boot Server is used

*.Ftw: Used for scripts to prepare and execute OS setup from WinPE when TFTP access to the Boot Server is used

Here you can see the OS image template files maintained under \images:


Under the Hood

The template files are used for post installation functions. Each type has its own post install. If you add a driver to $oem$ in the template, all images of this type will get the driver.

Windows calls the i386\$OEM$\cmdlines.txt file upon initial startup after successful installation. This file executes custom.cmd (first time) which adds the target into a domain. Other “first step” tasks can and should be added here. runonce is also set configured to run after reboot and then the machine reboots.

The runonce command executes custom.cmd (a second time) which sets the administrator password. Other second step tasks can/should be added here. It also executes the sxpsetup.cmd command which executes the DSM Agent setup.

Template Files and OS Types

Here you can see how template files relate to OS Types:

For example, following is the template.ini definition of SUSEW90-CD type:

[SUSEW90-CD] type definition

typecomment=SUSE 9.0 Professional,Personal

comment in usage

ossubpath=suse

destination subpath for $OEM$ postinst files

imagetemplates=susew

take the $OEM$ templatefiles from susew dir


Under the Hood

createshare=MSNFS

The OS image needs MS and NFS share

batfile=susew.bat

tftpfile=susew.ftp

parameterdefinition=susew.def

responcefile=susew.inf

fileswithparameter=susew.osi

partitionfile=susew.par

stringtosubstitute=SUSEW

Substitute this string with the image name in template files

sdostype=251

SD type of this OS

;--The following lines specify what to read from the source CDs. Without these

lines all will be read

;--read files from path (-s <path>)

copyfrompath=SUSEWCD100

Copy details are in section SUSEWCD100

;--read setup files from CDs but image is on external NFS Server (-a <sharename>)

copytemplatesalways=yes

Templates although needed on Boot Server

morethanonealwayscd=1

Files from OS CD1 are needed on Boot Server

cd100=SUSEWCD10

Copy details are in section SUSEWCD10

;--read all files from CDs

morethanonecd=5

The image files will be read from 5 CDs

cd1=SUSEWCD1

Copy details from CD1 are in section SUSEWCD1

cd2=SUSEWCD2

cd3=SUSEWCD3

cd4=SUSEWCD4

cd5=SUSEWCD5

;--SUSEWXX contents of CD copy (-s <path>)

[SUSEWCD100]

identfile=dosutils\loadlin\loadlin.exe

check this file to accept the CD

content=content

copy directory (source = destination)

boot=boot

suse=suse

dosutils\loadlin\loadlin.exe=loadlin.exe

copy file (source = destination)

media.1=media.1

media.2=media.2

media.3=media.3


Under the Hood

media.4=media.4

media.5=media.5

;--Setup LINUX files on Boot Server even if it use a remote NFS share

[SUSEWCD10]


boot=boot


;--SUSEWXX files to copy from CDs

[SUSEWCD1]


content=content

boot=boot

suse=suse


media.1=media.1

[SUSEWCD2]

identfile=media.2\media

media.2=media.2

suse\i586=suse\i586

suse\noarch=suse\noarch

……………

There are 3 primary folders under the \managedpc subdirectory:

Agents contains agent install packages for target access

Camenu provides common store for preinstall scripts (DOS,WINPE)

Images contains Boot and OS images

Here you can see how OS images are stored in the \images subdirectory:


Under the Hood

Each OS image has an osinfo.ini description file in the root directory of the image. This file indicates that the image store directory contains an OS image


Under the Hood

Each OS image also has a default.ini describing parameters used in the image. This file contains several different sections. The [Default] section contains the default values for the parameters. The $xxx$ in the template are substituted by createosimage. The [Reserved] section contains a list of reserved internal parameter names and the [<Parameter>] section includes the definition of each parameter

To add a parameter to the auto answer file edit the auto answer file (in the above example, \ManagedPC\CAMENU\mywinxp.inf).

The [RegionalSettings] section identifies the Language=$localeID$ information. To edit this setting locate the following value:

[Default]

localeID=1033

Add the following new section at the end of the file:

[localeID]

Type=MapListExt

MaxLength=128

Comment=Language/locale to be installed

Trans=yes

item=5124 Chinese_Macau

item=1030 Danish

item=1033 English US


Under the Hood

item=2057 English UK

item=1036 French Standard

To check the new parameter execute the following command:

RegisterOSImage -i <image> -t

This checks the files in osinfo.ini for $xxx$ parameter definitions against default.ini . If no parameter definition is found in default.ini, parameter definitions are added with default settings. To register the parameter from a command line, execute the following:

RegisterOSImage –i <image> -s <manager>

Registering to Another Domain Manager

To register an OS Image from IPS to a remote Domain Manager, use the following syntax:

Registerosimage -i image -s “remote Domain Manager” -u user -p password -d

unixl://”remote DSM domain”

Then, export the OS image from local Domain Manager and import it to the remote Domain Manager using the following procedures:

tory to the remote site.

th the following command:

Registerosimage -w directory -s Domain Manager

in

1. Export the OS-SD package into a directory.

2. Transfer the direc

3. Import the OS-SD package wi


Under the Hood

Special Preparatio

(including the ghost.exe).

on on the model target.

3. Install the model OS (without DSM Agent) in the partition.

s to the model PC and execute sysprep.

re on IPS and execute ghost.exe from the share.

gisterosimage to create the OSIM image

Upgrade Procedure for OS-SD packages

The Software Delivery package upgrade procedure deploys the OS image package to the target via Software Delivery and executes the winnt32.exe /upgrade in the package.

Note: The unattended auto answer update.inf file also contains the Product ID.

To set the product key in the default.ini, use the following syntax:

CreateOSImage …. –k <key>

The following command makes a copy of the update.inf template to the OS image and sets the product key from the default.ini:

RegisterOSImage

OS to upgrade a live system

n for GHOST and PQIMG Based Images

Use the following steps to create a clone image:

1. Create a share (read, write) on IPS

2. Create a FAT, FAT32 primary partiti

4. Copy the MS sysprep file

5. Boot from a DOS Boot floppy with network access.

6. Mount the sha

7. Store the <image>.gho on the share.

8. Use createosimage and re

Note: The upgrade depends on the ability of the with a new OS version.


Under the Hood

OSIM Domain Man

lo

ager Plug-in

Fol wing depicts the OSIM Domain Manager plug in.

OS Installation Job States

You can monitor the state of the OS Job installation through the DSM Explorer. There are three possible job configurations:

The current OS is the last successfully installed OS

A planned OS is used to define an OS installation Job

An activated or pending job is awaiting installation


Under the Hood

Each job has to be defined in a planned configuration. After activation it becomes an activated, pending job and, after OS installation, it becomes

Only one OS can be installed on a physical or virtual target.

current.

OSIM (CSM) Data Base Design

database contains information about the following:

This informat

The OSIM

Boot and OS images

OS installation jobs (configurations)

Computer and Boot Server

ion is derived from the following classes:


Under the Hood

Class Name Class ID Properties

BootDiskImage 1006 Type, sdname, sdversion, d sdcomment, detecte

BootOSImage 1008 Type, sdtype, locale, externalos, batchfile, sdname, sdversion, sdcomment, detected

Bootparameter (for OS Images)

1002 Type, Maxlength, Minvalue, Maxvalue, Trans, item (additional parameter values)

Parametervalue (for OS images)

106 See below

Bootconfiguration (for OS installation jobs)

1004 Bootstatus, Configstate, Configstatetime, Activationtime, Waitforagent, Retrytime, requesttime

Computer 102 Dnsname, hostname, hostuuid, macaddr, firstseen, bootfile

Bootserver 1000 Lastheard, lastreportallrequest, lastreportall, status

Here you can see how the properties for Parameter value are derived:

….

Here you can see how properties for the Boot Server Class are derived:


Under the Hood

Special Bootstatus Pro

ues are used to identify

S

perty

The following val a job’s bootstatus:

Value tatus

1000 Current

2000 Stopped

3000 Cancel pending

4000 Failed

5000 Set if delete is ordered for job

6000 B oot server not responding

7000 Unmanaged

8000 ADS Managed

10000 Planned

11000 Activated

20000 Analyzing

21000 Pending

22000 Installing

The computer’s bootstatus will be taken over from the job (configuration). If there is more than one configuration (planned, current, activated) the state of the highest configuration will be set.


Under the Hood

OSIM Database Objects and Relationships

ationship between OS Database objects:

u can see the properties for an O

Here you can see the link between OS Job and used OS image:

Here you can see the rel

Here yo S Job:


Under the Hood


Under the Hood

Boot Server Components

Here you can see the various components used by the Boot Server:

More details about these functions is provided in the next few sections.

Boot Server Configuration

Sdmpcserver (sdmpcworker.exe) is a CAF process that uses multiple threads for TFTP, PXE, Agent-copy, ping and password change. These threads (MaximumThreadPoolSize) are created during startup and are dynamically assigned and released from the thread pool. If more threads are needed, the thread pool will be increased stepwise by 10. If this happens frequently, you should consider increasing the MaximumThreadPoolSize value.

The configuration can be changed through configuration policies maintained in the following location:


Under the Hood

/DSM/Scalability Server/osim/ManagedPC/server

value is 1000. The default value is 56.

The following values are used for Boot Server PXE configuration:

PXEDisabledAtStart (Disable PXE service at start)

If PXEDisabledAtStart is set to 1, the PXE process of the Boot Server is disabled after the next restart of the caf sdmpcserver. 0 means normal start of sdmpcserver.

CADHCPProxy (Enable DHCP proxy)

If CADHCPProxy is set to 1, the Boot Server will listen on port 67, and 4011 for DHCP discover and BINL request messages. If CADHCPProxy is set to 0, the Boot Server will only listen on 4011 for BINL request messages.

For Boot Server TFTP Configuration, the service consists of one TFTP connection thread and multiple data transfer threads. The TFTP server only supports reading of files from the Boot Server’s image store and monitors TFTP file transfers for special image files in order to set the next boot image in a sequence of images.

Following are parameters used for Boot Server Configuration:

TFTPD_RedirectPort (Port to redirect TFTP requests)

Min = 0, Max = 65535, Default = 0

Port to redirect tftp requests to, if another tftp server is available. 0 means no redirection.

LogTftpFileRequests (Log TFTP file requests)

If set to enabled(1) then all tftp file requests are reported to the event lo 0 means no reports. Default = 1

The level of detail to output to the TFTP log file. 5 means all, 1 only errors.

ies (TFTP retries before timeout)

ne

achine. This allows more simultaneous downloads on slower targets.

The Minimum value for MaximumThreadPoolSize 50 and the Maximum

g.

DebugLevel (Level to log TFTP file requests)

TftpRetr

Min = 1, Max = 5, Default = 3

The maximum number of retries to send a packet to a target machibefore timeout the transfer.

TftpThrottle (Back off time after TFTP send)

Value = 0, min = 0, max = 30

The maximum number of milliseconds to back off after sending a tftp packet to a target m


Under the Hood

TftpTimeout (TFTP timeout)

Min = 1, Max = 10, Default = 3

Maximum timeout in seconds to wait for the next packet from a target.

ver.

If U for offers from other Boot Servers.

If the PXE thread sees more than 3 dioffer.

The ed by the connection thread and will create a data transfer thread for each target.

Here you can see how the PXE and TFTP threads work together:

The PXE thread monitors port 67 for DHCP disco

SEacl=1 it also monitors port 68

scovers without an offer, it will send an

TFTP read request will be handl


Under the Hood

OSIM Boot Server Ping e

The onitors targets by doing the following:

er starting the OS installation it will be removed from the TFTP access list.

If the target is not accessible within the designated time period (2 hours by default) it will also be removed from the TFTP access list.

The following parameters are used to specify OSIM Boot Server ping configuration:

PingTimeout (PING timeout)

min =1, max = 10, default = 2

time in seconds to wait for a ping response.

PollIterations (PING poll iteration)

Min = 1, max = 500, default = 120

Number of times to ping a target machines before it is determined to be down.

PollInterval (PING poll interval)

Min = 1, max = 600, default = 60

Time in seconds between which pinging of all machines known by the Boot Server is performed.

Boot Server Password Setting

The Password change thread changes the password of the OSIM canonprv user (local user) on a regular basis. The encrypted password is stored in the local comstore, from which it is sent to the target with each PXE boot. This password is used in the Boot Image to get access to the shares on the Boot Server.

ssword change thread:


e in days between password changes for the user canonprv.

PW_length (Password length)

The maximum length of the password generated for user canonprv.

Thr ad

OSIM Boot Server Ping thread m

Pinging known targets and waiting for a ping response

Updating the TFTP access list. If the target answers a ping aft

The following parameters are used to configure the pa

PWCDays (Password change interval)

Tim

The following configuration parameters define the complexity of the created canonprv password:


Under the Hood


erating a

n

The minimum number of Uppercase Characters [A-Z] to be generated.

(Number of lower case characters in

ase Characters [a-z] to be generated.

bols in password)

rs to be generated. If the

gth.

Boot Server Agent Copy Th

The Agent copy thread browses the sdlib (library.dct) to find packages matching a specific naming pattern and takes the most specific version. The

cently copied agents are listed in the agent.inf file:

Agent store contains the .caz files which include the image format of the agent

PW_num_digits (Number of digits in password)

The minimum number of digits [0-9] to be generated when genrandom password for canonprv.


PW_num_upper_case_characters (Number of upper case characters ipassword)


PW_num_lower_case_characterspassword)

The minimum number of Lowerc


PW_num_symbols (Number of sym

The minimum number of special symbol charactevalue is larger then PW_length then this value will be truncated to PW_len


read

most re

for TFTP download.


Under the Hood

Boot Server csmagent and sdbsmstate

an OS installation job sent from the OSIM Manager to the Boot Server TRC

ows how delivery of the Boot Server hello message (alive) to the OSIM Manager is written in the TRC_CSMAGENT_0.log:

The following example demonstrates how the distribution of is listed in the

_CSMAGENT_0.log.

The next example sh


Under the Hood

the

Report Description

Following is a list of reports that can be launched to the Manager bysdbsmstate (Csmagent):

Bsinfo Report Boot Server status

Bscompinfo Report status of assigned PXE target machine(s)

Bsosinfo Report available OS images

Bsbtinfo Report available boot images

Bsbreginfo Report PXE boot requests and ADS devices

Following is a list of requests and jobs that can be sent from the Manager to the sdbsmstate (Csmagent):

Request Description

Bssync Synchronize list of assigned PXE targets with manager MDB

Bsstartpxe Start answering PXE requests

Bscompinstall Activate OS installation job

Bscompcancelinstall Cancel active OS installation job

Bscompremove Remove computer from list of assigned PXE target machines


Under the Hood

Request Description

Bscompserve Add computer to list of assigned PXE target machines and abort active OS installation

Bscompwol Wake up target computer

The OSIM Manager sends the reboot request for a target to the sdbsmboot (Csmagent) to the target’s agent. Bslocalreboot triggers local reboot (provided by DSM Agent).

Boot Server Administrative Files

Administrative files for sdbsmstate are kept in the following location:

c:\Program Files\CA\DSM\Server\SDBS\var\ManagedPC.

dbsmstate reports changes of Boot Server data to the manager only once.

ilename Contains

SThe following files are used as memory for reports:

F

Bsmbreq.dat t requests Reported boo

Bsmconf.dat to compare with FCORStart data of the job

Bsmimgb.dat Reported boot images

Bsmimgo.dat Reported OS images

Bsminfo.dat Sent hello (alive) messages

Bsmstat.dat Reported state changes of install jobs

Here you can an example of the contents for a bsmimgo.dat file:


Under the Hood

Following is the key to interpreting the contents:

Modified = 0 means “reported” while Modified = 1 means “not yet reported”

= OS image was found on B

and the AckId on the l es the report that recently accepted by

example of the con ile:

Following is the key to interpreting the contents:

:*osimage oot Server

AckId = report ID ast line identifiwas most the manager

Following is an tents of a bsmstat.dat f


Under the Hood

Pending = 0/1 identifies the pending OS job

Running = 1 indicates that the OS job is running while Running = 0 indicates that the boot sequence finished

Boot1st = boot loader file

1stFile = first boot file in the sequence

NextFile = Next boot file in the sequence

Following is an example of the contents of a bsmbreq.dat file:

Following is the key to interpreting the contents of this file:

Served = 0 indicates that no PXE request has been answered while Served = 1 indicates that the PXE request has been answered for the client

ADSclient = 0 indicates that the target is not managed by ADS while ADSclient = 1 indicates that it is

Data Exchange Between sdmpcserver and sdbsmstate

The following files are used for data exchange between sdmpcserver and sdbsmstate. They are found in the following location:

c:\Program Files\CA\DSM\Server\SDBS\var\ManagedPC


Under the Hood

name Contains File

Mac.acl MAC of all targets the Boot Server is ble for responsi

Ma agedPCDataFile (FCOR) basformat). A

n ic PXE data of targets (binary test tool listfcore shows the

contents

PXEBoot.log MAC of a newly picked up target until the manager accepted the boot sever relationship and the MAC is added to mac.acl

Boot Server WOL and Reboot

The WOL and Reboot request is sent in the install job to the Boot Server. The Boot Server sends the Job to the Domain Manager.

The DM synchronizes Reboot and WOL

– The DM sends the Reboot request to the target via sdbsmboot which uses the CAF Reboot service to restart the target.

– The DM sends a WOL request to the responsible Boot Server through sdbsmstate which uses the CAF WOL service to broadcast the WOL magic package.

Additionally the Boot Server plug-in, sdbsmstate, looks into the common sks) to create a list of subnet addresses

where DSM targets are located.

h

Boot Server Access from Target

Boot Server access from target is managed either through share mode access or TFTP access:

The target reads the OSIM OS image files from Boot Server’s image store

A Boot Server provides access to the image store via shares or via TFTP.

WOL broadcast and subnets:

The WOL (magic package) is sent as a broadcast package in the server’s sub network.

Most router configurations will not forward WOL magic packages to allsubnetworks

server target list (IP, subnet ma

The sdbsmstate sends a WOL package to the broadcast address of eaccalculated subnetwork.


Under the Hood

The target Boot Images are always load via TFTP but, depending on the Boot Server configuration, the OS files will be read from shares or via TFTP

GHOST32, PQIMG OS installed from shares.

can see how the OS insta for Windows releases (Win98 thru Win

GHOST, can only be

Here you llation occurs via share access of TFTP2003):

You can switch between Share mode and TFTP by configuring the Boot Serveracc ss mode. The sdbsswitch command creates or removes the OSIM shares

the i

e

and changes mage data between the shared directory structure and the

tches from share to tftp access.

onfiguration of the Boot Server.

Wheprocess and ng:

Searches the image store for all osinfo.ini.

each osinfo.ini for information about the shares and imagefile

ch is also for NFS)

image file for TFTP download.

sdbsswitch -t swi

sdbsswitch -s switches from tftp to share access.

sdbsswitch -l shows the current c

n either sdbsswitch -t or -s executes it shuts down the sdmpcserver does the followi

Looks in

– Createzip = imagefile (If TFTP, this imagefile must be created)

– Sharename = sharename (Name of the share whi


Under the Hood

– Createshare = MS or NFS or MSNFS (creates this type of share whereMS = Microsoft share; NFS = LINUX NFS share; MSNFS = both )

Remote Execution of sd

figure procedures to change the Boot Server access method via Software Delivery.

Access for LINUX OS im

Linux OS image setup always requires NFS shares. When the NFS shares are

ces for Windows 3.5 or later for

NFS ahow eanonymous.

bsswitch with Configure Job

The Scalability Server package includes con

ages

on the Boot Server the following applies:

Windows Boot Server requires UNIX servithe NFS shares.

LINUX Boot Server requires an active NFS server.

sh res can also be provided on a central Windows or Linux server, ev r, the directories and the NFS share must have read access rights for


Under the Hood

IPS and Boot Server on On

When Boot Server is in TFTP mode the Createosimage -i <imagename> command does not create a .caz file. This must be done later with the

For a Linux OS image, createosimage tries to create an NFS share if the following is fulfilled:

Unix services for Windows 3.5 is installed

LINUX image is not on an external NFS share (-a <share>)

Use of Microsoft Automated Deployment Services (ADS)

DSM Boot Server can coexist with the ADS Boot Server

Because of an arrangement between CA and Microsoft, ADS and DSM OSIM should be able to coexist

Microsoft ADS can be downloaded from Microsoft and requires Windows 2003 Enterprise Server

Microsoft ADS has it‘s own user interfaces and management functionality. DSM only synchronizes the target responsibility on Server level between DSM Boot Server and ADS Boot Server.

The ADS managed targets are contained in the MDB and visible (but not manageable) in DSM

If OSIM Boot Server is used as an ADS proxy the following applies:

The Boot Server will ask the ADS server before it answers PXE requests of a special target. The Boot Server will not answer if the target is ADS managed.

If the customer adds PXE targets to the ADS server, the configured OSIM will be notified from the ADS server.

erver reports the ADS managed targets to the DSM domain

OSIM jobs from that target.

If the PXE target is removed from the ADS server, the configured Boot Server and the Domain Manager will be notified from the ADS server. The target

e System

following command:

createosimage –z <imagename>

Boot Server

The Boot Smanager. These targets will be marked as ADS managed in the MDB.

The Domain Manager also removes all

becomes an unmanaged OSIM target again.


Under the Hood

m the MDB and make it managed again.

llowing:

Must be set to 1 or true to enable the ADS proxy

roller name)

ve been granted full permissions to the \\ADSProvider\ROOT\MicrosftADS namespace.

If the user is not the “Administrator” then new user's access rights can be

ate a new user from computer Management

ADSDomain (ADS domain name)

The domain to use to authenticate the user when connecting to the

cation type)

The type of authentication to use when connecting to the ADS controller. This value can be set to either ntlmdomain, or Kerberos.

You can also delete the ADS target fro

To configure the Boot server as an ADS proxy use the fo

ADSUse (Enable ADS proxy function)

ADSProvider (ADS cont

The IP address or hostname of the machine which contains the MicrosoftADS namespace.

ADSUserId (ADS user ID)

This user ID must be a member of the Administrators group on the ADS Controller and must ha

set by following these procedures:

– First cre

– Then configure WMI by going to the WMI Control properties page

ADSPassword (ADS password)

The password to login to the ADS controller for the given user id.

controller. This can be left blank if the user to authenticate has been defined on the ADS controller.

ADSAuthenticationType (ADS authenti


OSIM and CADSMCMD

OSIM Boot Server and Manager Events

Both the OSIM Boot Server (sdmpcworker) and OSIM Manager (DSM) write events to the Application event log.

For Guide.

TFTP OSIM Boot Server Eve

nent of the OSIM Boot Server (sdmpcworker) can be confinum off Log

t

OSIM and CADSCADS s aut and acti

ork

a complete list of events, refer to the OSIM Inside

nts

The TFTP communication compogured to write events for every TFTP read request. Since a large

ber of TFTP requests can overflow the event log, you may want to switchthe TFTP events in the common configuration by editing the TftpFileRequests parameter.

Set to true for a specific Boot Server, it enables logging of TFTP read requests.

Se to false it disables logging of TFTP read requests.

MCMD MCMD is a command line interface that can be used to support proces

omation for Desktop and Server Management. It includes commands ons for the following OSIM related functions:

Administering target systems

Setting up new OS configurations and maintaining them

Initiating and controlling OS installation requests via netw


OSIM and CADSMCMD

On Linux this includes the following:

d/lib)

cadsmcmd.enu (/opt/CA/DSM/sd/nls)

sd_bmscapi.enu (/opt/CA/DSM/sd/nls)

On Windows this includes the following:

cadsmcmd.exe (C:\Program Files\CA\DSM\bin)

sd_bmscapi.dll (C:\Program Files\CA\DSM\bin)

cadsmcmd.enu (C:\Program Files\CA\DSM\sd\NLS)

sd_bmscapi.enu (C:\Program Files\CA\DSM\sd\NLS)

The CADSMCMD also depends on the following client APIs:

CO CAPI (libcmObjectInterface.so, cmObjectInterface.dll)

CSM CAPI (libccsmclient.so, ccsmclient.dll)

SD CAPI (libsd_gapi.so, sd_gapi.dll)

capabilities of CADSMCMD can only be used under the following

Architectural Over

l

cadsmcmd (/opt/CA/DSM/sd/bin)

libsd_bmscapi.so (/opt/CA/DSM/s

CCNF CAPI (libccnfclient.so, ccnfclient.dll)

The OSIMconditions:

when the addressed DSM manager is a Domain Manager

when the addressed Domain Manager has SD capability

view

Fol owing is an architectural overview of CADSMCMD:


OSIM and CADSMCMD

CADSMCMD receives its requests via one of the following interfaces:

n a file and this file is on. The control is

r the file (and all of its requests)

d. The session to starts and terminates

equests results considered.

With the CADSMCMD start a named pipe is established and the ion remains until

ation. More ion or user and

do not suffer from the session

This is a menu driven interface that is not used for process automation.

breaks the request down into a sequence of atomic sub-requests t

further breaks

Utilizing the DSM Session Messaging the requests are transferred to a DSM manager for processing. The components addressed are the common

object manager, SD dialog manager / API, and CSM API.

If CADSMCMD is running on the addressed manager then the session managing and the common object manager is bypassed and the CO CAPI directly communicates with CO DAI (Database access interface).

Diagnosing Problems with CADSMCMD

The CADSMCMD writes a log file on demand based on the following environment variables:

SDCMD_TRACE={ALL|FILE|SCREEN}

SDCMD_FILE=<file_name>

SDCMD_TRACE_OPT=B3C9

Batch interface

A sequence of CADSMCMD requests are coded iprocessed by the CADSMCMD in one block and sessireturned to the application or user aftehave been processed.

Call interface

One request is passed with the CADSMCMD and processethe manager is established when the CADSMCMDwhen it ends. The application can now react on rimmediately but the session establishment overhead has to be

Pipe interface

CADSMCMD receives its requests via that pipe. The sessthe application or user explicitly requests for session terminthan one CLI request can be sent to the CLI by an applicatthey can directly react to request result andestablishment overhead.

Verbose interface

CADSMCMD that are handled by the API layer. These atomic requests can be for differenAPIs. The native OSIM stuff is handled by the OSIM CAPI thatthe requests down into a sequence of CSM CAPI requests.

domain


OSIM and CADSMCMD

C code should be set to 9 as CSM trace is no longer supported from CLI layer cfTrace commands now).

Thehow

The found in the TRC_USD_x.log in the DSM log

It islog f

(it has to be managed by

default log file, cadsmcmd.log, is located at the DSM log directory; ever, different CADSMCMD can write different logs.

CAPI trace entries are directory.

possible that several concurrent CADSMCMDs are logging into separate iles.

When CADSMCMD is started it records the following information about the established session at the console:

n: This is the first information recorded and it nformation for CADSMCMD and the copyright. The

version shown is the build information of the executable.

ther logging is enabled or not and in case of file logging the file where the information is stored.

The connection information: Shows information about the addressed ion of the session.

Identification informatioincludes identification i

Log information: Whe

manager and the authenticat


OSIM and CADSMCMD

– <default manager> is the manager specified at time of CO CAPI installation. It is a COCAPI parameter and not known to the CADSMCMD. If no local parameter is specified this manager is

lways used if no Login gon. If is one

sed.

main: Name of the database system the related MDB resides.

– Domain type: Records whether the manager is a domain or enterprise one

– Features supported: records the CLI capability for this session.

This information can also be found in the CLI log but is more distributed.

TargetComputer command

OSIM uses the CADSMCMD “targetComputer” command. The set of actions is nearly the same as with USD 4.0:

Action Description

addressed otherwise the local one is taken.

– <default user> is the current user. This user is ainformation is passed with the CADSMCMD. It forces a unified loauthentication information is passed with the Login parameter this u

– Manager: Name of the manager the CLI is connected to

– Do

Create Creates a computer DSM that is SD and OSIM enables

List Lists DSM computers that are SD agents and OSIM un-managed PC

showAttr Shows the attributes of a computer including OSIM information about OSIM configurations

setupOS Assigns a new OS image to an OSIM un-managed but registered computer

modifyOS Assigns a new OS image to an OSImanaged computer

M-

sho arameters of an wInstallParameter Lists the installation pOSIM configuration

modi ation parameters in a fyInstallParameter Modifies installplanned configuration

Dele pecified OSIM configuration of a required type

te {planned|scheduled}OS Deletes the s


OSIM and CADSMCMD

Act ion Description

activate uration n

OS Schedules a planned OS configfor installatio

reac ativ teOS Reschedules a failed or canceled configuration

reinstalconfiguration for reinstallation

lOS Schedules the current OS

cancelOS nstallation Cancels a schedules OS irequest (graceful)

Dele DSM

te Deletes a computer agent entry in

When it comes to OSIM support the CADSMCMD CLI is backwards compatible

due to the name change from SDCMD to CADSMCMD users may have to

me the SDCMD calls to CADSMCMD in their existing scripts on Windows

g scripts too on Linux

The “linkBMS” action is now obsolete. With USD 4.0 OSIM and USD used rent databases. There was no in B layer. If a computer registered at USD and becomes

registered with its MAC address and The linkBMS action was used to link the OSIM entry and the USD entry and name the system

SIM as in USD. In DSM this has a PXE enabled system registers at the re

ady a DSM registered system t links the entries. Since the it

is invoked a warning is given at the and a “0” is returned to the application.

andling of the password param

ameter“ and ”userName“ parameters ollParameter” have beco

arameter of typeadditional information had to be passed w password correctly. This additional information had been either the name of a parameter

e user id direcencrypting the password.

With DSM r11 OSIM has changed its en no longer needs a user id as a key; it is independently encrypted/decrypted of it.

with V4, however please note the following:

– rena

– provide a link for SDCMD to CADSMCMD or to rename SDCMD to CADSMCMD in their existin

diffe tegration on Dwas PXE enabled for the first time it

no name at OSIM.

in O changed due to use of the MDB. If OSIM side CSM checks whether the

is alrematch i

of the same MAC address and on linkBMS command is now obsolete if

console that this action is obsolete

The h eter has changed.

The “userPar“modifyInsta

f me obsolete.

With USD 4.0 when a p password was changed then for encrypting the ne

presenting a user id or th tly. This user id was the key for

cryption-decryption handling and


OSIM and CADSMCMD

In r11 the parameters “userParameter” and “userName” are ignored by CADSMCMD. No error or warning is given.

Enhancements/Changes

Here you can see how the command syntax has changed:

targetComputer action=create mputer name» pe={machine | user profile

address=«network address» erating system type»

[stagingServer=«staging server name»][calendarName=«calendar name»]

[sof a

name=«cocomputerTy | staging server | docking device}

os=«op

[user=«user»] [phone=«phone»] [location=«location»] [comment=«comment»]

tw reManagedSystem[={y|n}]] Po cy={[rac li common | disabled | deferred | automatic}]

«host na[hostName= me»] {[m A[bootS AC address»

TheandOSIandcodSerfrom

targname=

ac ddress=«MAC address»] | erver=«Boot Server name»] macAddress=«M

osImage=«os image name»}

syntax of the action “create” has been changed. The options “hostName” “macAddress” can also be coded without OSIM context now. To create an M entry beside the DSM common and USD entries the options macAddress osImage have to be coded, but “bootServer” has become optional. If not ed an OSIM computer entry is created without any relation to any Boot ver. This missing link is established when the computer registers in OSIM the network (PXE enabled).

etComputer action=activateOS «computer name»

[atTime=«YYYY-MM-DD hh:mm»] [wakeup[={y|n}]] [re tart[={y|s n}]]

tBs[={y|n[wai }]] [waitIm[={y|n}]]

The options “waitBs” and “waitIm” are new. If waitBs or waitBs=y is coded then the CSM will defer the processing of the related OS installation until a Boot Server is assigned to the target. In any other case the CSM will not waiand if the specified target i

t s not assigned to a Boot Server the order will fail.


OSIM and CADSMCMD

If waitIm or waitIm=y is coded then the CSM will defer the processing ofrelated OS installation until a BT and OS im

the ages associated wit this order are

staged at the related Boot Server. In any other case the CSM will not wait and if the associated images are not staged at the related Boot Server then the

fail.

name=«computer name» »]

order will

targetComputer action=reactivateOS

[atTime=«YYYY-MM-DD hh:mm[wakeup[={y|n}]] [restart[={y|n}]] [waitBs[={y|n}]] [waitIm[={y|n}]]

targetComputer actname=«computer name[atTime=«YYYY-MM-DD h[wakeup[={y|

ion=reinstallOS »

h:mm»] n}]]

[restart[={y|n}]] [waitBs[={y|n}]] [waitIm[={y|n}]]

Example Scenarios

Example 1

In this example a computer entry is provided in advance for a system that re. As long as the manufacturer provides

ress of such a system beforehand the user is able to

AC address, the following other details are needed:

abel or host name

its network address

The Boot Server on OSIM layer should reside on the same system as the Scalability Server on DSM layer but this is not a requirement.

Following are a series of examples demonstrating the use of CADSMCMD for OSIM purposes.

might be delivered in the (near) fututhe user with the MAC addprepare the systems setup.

In addition to the M

the system name or l

the Scalability Server the new system will be assigned to

the name of the Boot Server the new system will be assigned to

the OS image to be installed


OSIM and CADSMCMD

For the purposes of our example, the following values are used:

MAC address = FF:EE:CC:01:23:01

Name =osim_sy_1

network address=osim1.ca.com

e as above)

ge = myWinXP

targetComputer action=create

=osim_sy_1

computerType=machine

23:01

This command creates a DSM computer agent and makes it OSIM managed. The provided planned configuration can now be configured and monitored by

ing the modifyInstallParameter and showInstallParameter actions as in the past. Once the configuration requirements are met, it can then be scheduled

targetComputer action=activateOS

name=osim_sy_1

Assuming that the related images are all staged at the associated Boot Server

identifies the system by means of its MAC address (given as part of the request) and knows that it is responsible for it

o the request and with that response the system is informed to down load a boot

a e. The OS installation then starts h

installation tes and

the system runs up then a DSM agent is normally installed on it. That agent anager and starts processing the provided

USD installation requests.

Scalability Server = my_server

Boot Server = my_server (sam

targeted OS ima

Here is the syntax:

name

address=osim1.ca.com

os=win_xp_intel

stagingServer=my_server

macAddress=FF:EE:CC:01:

bootServer=my_server

osImage=myWinXP

us

for installation by launching the following command:

CSM starts will processing the request and, after a while, the scheduled configuration enters the “waiting” status. In this status when the new and PXE enabled system plugs in then the system launches a PXE request during the boot phase. The Boot Server

and has an installation request pending for it. The Boot Server responds t

im ge, related to the OS image request abovwit that boot image.

In addition to the OSIM installation request a Software Deliveryrequest can be provided in advance. When the OS installation comple

then registers at the appropriate m


OSIM and CADSMCMD

The final result is a new system on which the OS has been installed through I been installed and configured

Example 2

me is “osim_sy_2” and the This target will be prepared for a

Windows XP installation using the “myWinXP” OS image.

Unlike the previous example, this system will not be assigned to any Boot automatically be assigned when the PXE

s for the first time.

e

com

os=win_xp_intel

e of you who are familiar with the old SDCMD know that the newly created system in DSM is assigned to

anager, but in OSIM the system is not Boot Server.

ed OS

e

dy been forward to the old Scalability Server are now transferred to the new one.

OS M and the required applications havethrough Software Delivery.

In this next example, let us create an OSIM target for the MAC address “FF:EE:CC:01:23:02” in advance. The server nanetwork address is “osim2.ca.com”.

Server. Rather, the Boot Server willsystem register

Here is the syntax:

targetComputer action=creat

name=osim_sy_2


address=osim2.ca.

macAddress=FF:EE:CC:01:23:02

osImage=myWinXP

The command is nearly the same as in the first example but the options “stagingServer” and “bootServer” are not coded. Thos

the Scalability Server with the massigned to any

When the new PXE enabled system set ups and registers at OSIM the system is assigned to the Boot Server that detected that system first. The requirinstallation is now performed via this Boot Server. When it is completed the new systems runs up and the DSM agent installed with the OS registers at thDomain Manager. By default, this agent addresses the Boot Server as Scalability Server (this can be changed in the OS configuration). If this Scalability Server is different from the one on the manager then a computer move from the old Scalability Server to the new one is now initiated at the Domain Manager. This means that all Software Delivery requests for this system that have alrea


OSIM and CADSMCMD

Example 3

metal system that has registered at OSIM with MAC address “FF:EE:CC:01:23:03”. This system will be named “osim_sy_3” and assigned to the network address “osim3.ca.com” and the Scalability\Boot Server is “my_server”. It will then be set it up for the OS installation of the OS image “myWinXP”.

SM

Boot Server that has detected that system.

reate

name=osim_sy_3

.com

r

CC:01:23:03

ed

Example 4

PXE

ill

targetComputer action=setupOS

name=osim_sy_4

osImage=myWinXP

This command creates a planned configuration of myWinXP for the osim_sy_4 system. It does not change the Scalability or Boot Server assignments.

Next, let us consider a bare

This time the system that will become OSIM managed has already registeredas a bare metal system at OSIM. In other words, the only information Dhas about that system is its MAC address in OSIM and the

The following syntax makes the system predefined in DSM and OSIM managed:

targetComputer action=c


address=osim3.ca

os=win_xp_intel

stagingServer=my_serve

macAddress=FF:EE:

bootServer=my_server

osImage=myWinXP

Once this command is launched the PXE system is allocated as a predefinsystem in DSM named osim_sy_3 that is assigned to my_server as Scalability and Boot Server regardless of which Boot Server reported that system.

In this next example, the system named “osim_sy_4” has been registered in DSM but un-managed by OSIM. This system needs to be set up for the installation of the OS image “myWinXP”.

In this scenario the target system is already registered at DSM, but not enabled. Once the system is PXE-enabled and rebooted it will register at OSIMand be linked with the already existing DSM computer entry. However, it wremain OSIM un-managed because no OS configuration has been assignedyet. The syntax for making this system OSIM managed is:


OSIM and CADSMCMD

Example 5

In this example, a DSM registered but OSIM un-registered system “osim_sy_5” should become OSIM managed in advance and prepared for an installation of the OS image “myWinXP”.

In the last example it is again assumed that the target system is already DSM registered but not yet PXE enabled. It is planned to manage this system by

y

targetComputer action=setupOS

nXP

get OSIM managed but the Boot Server won’t be ntil it registers with OSIM.

can be used to schedule the installation request in

OS

n the installation request enters “waiting” status and the system is rebooted again the OS installation request will be processed and the new OS installed.

For the purposes of each of these examples it is assumed that all of the

OSIM too. You can wait until it registers with OSIM, as in the previous example, or you can use the following syntax to change it so that it is alreadmanaged when it is registered:

name=osim_sy_5

osImage=myWi

This command makes the tarassigned to it u

The following syntax advance:

targetComputer action=activate

name=osim_sy_5

waitBs=y

When the target becomes PXE enabled and is booted for the first time it will register at OSIM and the Boot Server reporting this system will be assigned to it. Next, the CSM starts transferring the request to the Boot Server. Whe

necessary OS images are already available at the Boot Server otherwise the request will fail.


Glossary

Application Programming Interface (API) An interface that allows programs to communicate with a product

ADSI Active Directory Services Interface

AMS Asset Maintenance System

BABLD Brightstor ARCcserve Backup for Latops and Desktops

Boot Server The OS Installation Management (OSIM) Boot Server is installed as part of a scalability server. The Boot Server installation automatically provides a TFTP server (with reduced access rights) and a PXE server.

CADSMCMD Command line utility for Desktop and Server Management.

CA Messaging (CAM) CAM (CA Messaging) is an established component used by several CA products to allow inter process communication, without the peer processes needing to be aware of exactly where their peer is located or without both entities or the network connecting them needing to be operational at the point of sending a message.

Common Configuration (CCNF) The Unicenter DSM products are configured centrally and locally through a shared component, typically referred to as “common config” or “CCNF”. This components acts like an “enhanced Windows registry.” It manages the runtime configuration of practically all of the DSM subcomponents and infrastructure features, though there are some exceptions.

Common Architecture Framework (CAF) Cross-platform service control manager, which provides a single point of control for all Unicenter DSM components. CAF dynamically provides Unicenter DSM services as required using an extensible plug-in model. Each CAF plug-in is a program, which provides agent, scalability server, or manager functionality. A CAF plug-in can also be an extension of CAF itself, which provides some common service, for example, registration with scalability servers or system event detection.

Command Line Interface (CLI) A user interface where the user communicates with a product by commands. This interface allows you to automate the usage of a product by using the cli commands from a script.

September 2007 Glossary–1

OSIM and CADSMCMD

Common Component Library (CCL) The CCL provides common services that are used by many DSM components, including trace, configuration, security, and directory integration.

Configuration and State Management (CSM) Configuration and State Management is a framework for configuring objects like software products or operating systems and tracking the status of those objects. It is used e.g. by OSIM.

Common Registration API (CORA) All Unicenter r11 products utilize the common MDB schema to store and manage their data. CORA provides the interface through which these assets are registered and as the only source for updating these tables, (CORA) ensures that asset data flows consistently, thereby supporting the data and referential integrity of the Mob’s master asset data model.

Content Management System (CMS) The content management system (CMS) is a central repository hosted by CA and available via the public internet. CMS contains information about all known software, including patch and fix recognition information (signatures).

Data Transport Services (DTS) The Data Transport Service (DTS) infrastructure provides end-to-end management of content delivery securely, reliably and efficiently across multiple platforms, protocols, networks and data formats, helping clients to synchronize, distribute, update, replicate and validate data across his/her enterprise. Data may be gathered from one system and transported to many others (one-to-many), or it may need to be gathered from multiple systems and then sent to one (many-to-one).

Database Access Interface (DAI) A standardized programming interface used by a component or process to access the DSM database.

Detailed Design Specification (DDS) A representation of a software system or component of a system created to facilitate analysis, planning, implementation and decision-making. The DDS is used as the primary medium for communicating software design information.

DMAPI The DMAPI is used by deployment consumers, such as damsel and the Deployment Wizard, to communicate with the manager. All user-visible deployment functionality is driven through the API.

DM Primer DM_Primer handles payload transfer and payload installation execution.

Domain Server (DS) Desktop and Server Manager architectural component that provides all management services to lower tiers an agents.

Glossary–2 Desktop and Server Management Advanced Topics Guide September 2007

OSIM and CADSMCMD

DSM Explorer The DSM Explorer is a single EGC framework-based Admin GUI. It consists of the framework itself, a common plug-in and a number of product specific plug-ins. The DSM Explorer provides a homogenized view and operation of all DSM products in which no product separation is apparent. As DSM products are purchased and installed the GUI simply becomes richer and more powerful.

Engine The Engine is a multi-instance, multi-function, distributable component. Its primary focus is the maintenance of computers and related information. Logic is encapsulated into a number of Engine Tasks which can be scheduled to run at regular intervals.

Enterprise Server (ES) Optional tier in Desktop and Server Management architecture which provides a single point of administration for multiple domains.

Graphical User Interface (GUI) A graphical user interface allows a user to communicate with a product. Because of its graphical elements it is easy to use.

Image Prepare System (IPS) Image Prepare System (IPS) reads the OS files from the vendor’s media and combines this with the OSIM files to create OSIM OS images and Boot Images.

Infrastructure Deployment The Infrastructure Deployment subsystem facilitates the initial deployment of DSM software components within a heterogeneous enterprise. Infrastructure Deployment is also sometimes known as DMDeploy v2. DSM infrastructure components, such as Agents and Scalability Servers, can be transferred and installed without the use of Unicenter Software Delivery. This functionality is typically used for an initial roll out of the DSM infrastructure. Infrastructure Deployment uses a DSM Explorer wizard to scan for deployment targets and to configure and initiate the deployment job.

Infrastructure Deployment Manager The Infrastructure Deployment Manager (dmdeploy) controls the overall deployment mechanism and maintains status among other tasks. It is a CAF plug-in

Inter Process Communication (IPC) IPC is a communication system that allows two process to interchange information. The DSM Manager utilizes CAM for IPC and uses the DSM Message Interface to run CAM.

IT Resource Management (DSM) A suite of products that enable the management of IT resources within an enterprise including: Unicenter Asset Management, Unicenter Software Delivery and Unicenter Remote Control.

Management Database (MDB) The MDB schema provides a unified and extensible model for enterprise IT management (EITM). It contains both common tables and product-specific tables that were previously implemented in separate product databases. The MDB serves as the enterprise database for all CA products and acts as a primary reference point.


OSIM and CADSMCMD

Network Address Translation (NAT) Internet standard that enables a local-area network (LAN) to use one set of IP addresses for internal traffic and a second set of addresses for external traffic. A NAT box located where the LAN meets the Internet makes all necessary IP address translations.

Networker The Networker is a generic, protocol-independent interface to stream based networking. This is a loadable component, which makes use of other loadable components to provide support for specific protocols, such as TCP/IP.

Network Object Server When a transfer job is activated the TOS contacts the Network Object Server (NOS) for the best route. Communication is managed via SM.

Operating System (OS) Every general-purpose computer must have an operating system to run other programs. Operating systems perform basic tasks, such as recognizing input from the keyboard, sending output to the display screen, keeping track of files and directories on the disk, and controlling peripheral devices such as disk drives and printers.

OS Installation Management (OSIM) OS Installation Management is a feature of USD that manages the preparation, installation, configuration, and upgrade of operating systems in an enterprise network.

Plug-in Computer program that interacts with a host application (a web browser or an email client, for example) to provide a certain, usually very specific, function "on demand.

Port Multiplexer (PMUX) The Port Multiplexer is a plug-in that listens for stream connections and forwards them to the process that requires them. It handles connection establishment and enables multiple applications to listen on a single port (by default that port is 4728). The Port Multiplexer only supports TCP.

Port Address Translation (PAT) Also known as "Network Address Port Translation" or "NAPT" PAT refers to network address translation where port number are mapped, allowing multiple machines to share a single IP address.

Report Extractor The Report Extractor is a separate EGC plug-in that is used to extract data from the MDB into result tables that are presented in the GUI and can be printed or exported in a number of standard formats. The Report Extractor plug-in is also used by the DSM Engine to generate result sets on a scheduled basis.

Sector Server The sector server is a component of UAM V4 that collects information from the attached agents and reports them to the UAM manager.

Glossary–4 Desktop and Server Management Advanced Topics Guide September 2007

OSIM and CADSMCMD

Scalability Server The Scalability Server is a component of the DSM R11 architecture that acts as a distribution point for software delivery activities and a collection point for asset inventory.

Session Messaging (SM) Session Messaging (SM) is a client-server layer that sits atop the DSM Messenger component. SM is provided in the form of a C-based interface DLL and a management daemon (CAF plug-in). SM is modular and utilizes many common components. It provides session management, encryption, compression, low-level authentication (X.509), high-level authentication (O/S or External), transactional calls and message forwarding.

Software Catalog The Software Catalog is an agent plug-in, which allows you "self-service". With this wizard based interface, you can install or remove software on your computer from a library provided by the administrator.

TOS DTS is implemented around an object model. These are the objects controlled by the Transfer Object Service (TOS).

Unicenter Asset Management (UAM) Unicenter Asset Management (UAM) is one of the worlds leading Enterprise Asset Management products. It is a scalable enterprise class product and its management capabilities allow clients to build an inventory of IT assets in a database and deploy management policy on remote desktops. It has a very broad platform and protocol coverage, utilizes CA Common Services and integrates with Unicenter NSM and other CA desktop products.

Unicenter Remote Control (URC) Unicenter Remote Control (URC) is a product that allows accessing and controlling a distant PC and its resources from any location – as if you were locally logged on.

Unicenter Software Delivery (USD) Unicenter Software Delivery (USD) is currently the world’s leading Enterprise Software Distribution product generating more revenue than any of its competition. It is a flexible tool that can build, distribute, install and manage software packages. Its management capabilities allow clients to install, configure, verify and remove software throughout their business environment in a controlled and standardized way. It has a very broad platform and protocol coverage, utilizes CA Common Services and integrates with Unicenter NSM and other CA desktop products.

Web Admin Console (WAC) The Web Console is a browser-based user interface to Unicenter DSM, which can be installed on Windows and Linux operating environments.
