DSM Advanced Topics Guide - SupportConnect - CA

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 


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 


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

Chapter 6: Startup and Configuration 

References 

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 


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 


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 

References 

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. 

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

f 

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

September 2007 Chapter 1: Introduction 1–1

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: 

ImpcdFeedback@ca.com 

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

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

m 

� Working with your CMS Solution 

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

tm 

� Scalability Considerations (includes information regarding sizing and 

performance considerations) 

http://supportconnectw.ca.com/public/impcd/r11/scalability/scalability_gui 

delines__udsm.htm 

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

September 2007 Chapter 2: Component Details 2–1

The Engine 

The Engine 

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

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 nonstatic 

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 

Engine Startup 

The following diagram provides an overview of the different pieces that 

comprise the Engine: 

CMEngine 

amoDataClasses 

sqlexec 

This includes the following: 

cfnotcli 

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


Engine Tasks 

Sector Collection 

As noted earlier, key Engine tasks include the following: 

� Collection 

� Replication 

� Reporting 

� Migration 

� Evaluation of Polices/Dynamic Grouping 

� Licenses 

The Engine 

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 

Query and Dynamic Group Evaluation 

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

nd_Assets_SC.pdf 

New Inventory tables are generated in the MDB by the Engine when new 

inventory is collected. 

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. 


Replication 

Replication functions utilize the following MDB tables: 

The Engine 

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

else 

update record in target database 

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 

Infrastructure Deployment Manager 

There are two types of managers that will be discussed here: the 

Infrastructure Deployment Manager and the Common Object Manager. 

Managers 

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

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

Common Object Manager 

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

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 

MDB Installation 

Ingres Notes 

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. 

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

on Windows only. 

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

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


� The Ingres installer will itself install the MDB (setupmdb) 

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

parameters 

The MDB 

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

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 



DTS Components 

� Broadcast/Multi-cast 

This type of transfer requires WorldView to be configured. Broadcast/Multicast 

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


Transfer Object Server (TOS) 


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

these components: 

DTS is implemented around an object model. These are the objects controlled 

by the Transfer Object Server (TOS). 



Network Object Server (NOS) 

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. 

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 



DTS Transfer Agent 

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 

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 

Event Management 

Installation and Configuration 

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


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 

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= 

MSGHEADER_GET_ENCRYPT= 

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 found in event queue for transfer , 

setting work to do flag 

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

|000295|DETAIL | Processing events for transfer 

Note, however, that all DTS trace statements have the function name (column 

5) prefixed with “Dts”. 


The Agent and DM Primer 

Report Extractor 

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: 

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

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. 



Architectural Overview 

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

architecture: 

User 

Application 

Data Access 

Database 

EGC 3.0 

DSM Reporter GUI 

Win: gui_rep.dll 

AM 

Manager 

Security 

Print 

AM Data Classes 

MDB 

Export 

modules 

Scheduled Reports 

Win: gui_rep_exec.dll 

Linux: lib_rep.so 

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



Following is a model of report results: 

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


Communications 

Diagnosing Problems 


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

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

are not overwritten! 

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: 

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. 

Communication with a remote Ingres database requires installation of the 

Ingres Net client on the Reporter machine 

(GUI or Engine box). To diagnose 

connection or start-up problems - consult the log files. 

DSM trace logs are maintained in the following location: 

/logs/TRC_REPORTER_n.LOG 

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

infrastructure components 

and dependencies. For a more concise reporterspecific 

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 



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, 

WARN and INFO. The DETAIL level is not used by the Reporter. As a result, 

when the alternative settings listed above are used, you will get all Reporter 

information and all significant 

information from AM Data Classes, while 

framework and stack output will be limited to errors and warnings. These 

settings are preferred when debugging Reporter 

functionality because they 

give a precise, reporter-focused log file. 

The follow are optional registry keys to log SQL statements. This enables 

input of additional log entries in the trace file for all ExecSQL, and most CRec 

record creations: 

[HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\ 

Unicenter ITRM\Reporter\Features] 

"LogSql"=dword:00000001 

For duration of SQL calls, add the following: 

" SqlTimer"=dword:00000001 

If the data is either missing or wrong you should inspect the 

result in the 

Reporter, using the Detail view instead of the HTML view. If the Detail view is 

correct, the problem may be related to the Custom HTML View defined for the 

report template. 

To inspect the raw data in result tables select the Results folder node to see 

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

reports. Set a break- 

point to inspect them before they are deleted. 


Web Admin Console 

(WAC) 

Web Admin Console (WAC) 

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

and relies on several technologies to supply the implementation of portions 

of 

the design. The following graphic provides an architectural overview of WAC: 

WAC is shipped as a WAR file “wac.war” (zip) which is expanded automatically 

when 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 folder the 

Tomcat configuration files are installed into DSM’s own “Web Console” folder 

and run up its own instance of Tomcat. 

Tomcat compiles jsp files at runtime into the Web Console\work folder. On 

occasion, if you modify jsp files the changes may not be picked up unless 

you 

delete the work folder. 

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

wac.war file. 



WAC and AMS 


AMS displays Discovered and Owned inventory and is launched embedded, and 

in context, in WAC and DSM 

Explorer. 

Web Services are used to create, configure, stop and restart software jobs and 

to retrieve product functionality based on what is installed on the manager 

(i.e., SD, AM or RC). This determines what 

is displayed by WAC. Web services 

are also used to retrieve Query results. 

A separate web application is installed by DSM installer into WAC’s Tomcat 

instance. The DSM Installer 

just calls AMS’s installer. 

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: 

\Web Console\webapps\wac\WEB-INF\classes\com\ca\wac\log\waclog.log 

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

log4j.logger.com=DEBUG 

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

\Web Console\logs 

Detailed tracing for AMS is set through the following file: 

CA\Unicenter 

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

Change the following line: 

log4j.rootCategory=ERROR, stdjlog 

to read 

log4j.rootCategory=DEBUG, stdjlog 

Detailed tracing for WAC 

is defined through the following file: 

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

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

Change the lines that read: 

log4j.logger.com=ERROR 


Web Services 

to read: 

log4j.logger.com=DEBUG 

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

caf stop tomcat 

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 

(when IIS 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. 


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. 

Following is high level overview of the architecture on Linux using Apache Web 

Server. As you can see the runtime structure used by Apache is different than 

that used by IIS. 


Things to Note 

Diagnosing problems 

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 and 

reliability, however, in the web service, the state is held internally. It holds 

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

webservice design relies on all requests for a session being directed to the 

same process. The above design solves this problem. 

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. 

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:///UDSM_R11_WebService/mod_gsoap.dll 

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

ISAPI module documentation for more details. 

Then, type: 

http:///UDSM_R11_WebService 

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






tm 







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

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 

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 plugins 

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 

Most plug-ins write to the standard DSM trace file which is: TRC_GUI_.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\ 

[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____info.txt (modules loaded by EGC) 

� EGC3.0____log.txt (trace information) 

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

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


� 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 plugin: 


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 

Reading Configuration Policies 

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. 

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: 


Configuration Portal 

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. 

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. 

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: 




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. 

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 Wizard 

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 

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 Synchronization 


It is also used to edit schema and create directory objects. Following is an 

example of the Add Directory function dialog: 

Directory synchronization controls consists of two HTML pages which can be 

used to modify the directory synchronization Engine jobs. 


Asset Manager (AM) Plug-in 

Directory Browsing 

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. 

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


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 


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 


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: 

OSIM Plug-in 

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

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

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) 


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) 

OSIM Plug-in 


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





CORA): 


m 



tm 

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? 


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 



� 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


� 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 

Tracing 

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

OS Services 

Please refer to the CA Unicenter DSM r11 Implementation Guide for full details 

of the CAF command line options. 

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. 

The syntax for running a CAF trace is as follows: 

cftrace –c set –f –pp –l DETAIL –s 

where: 

= UAM, USD, URC, DTS, CSTACK or CF 

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



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 


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 

rcManagerR11Migra 

tion 

BACKUP_WORKER TRC_BACKUP_WORKER.log 

BACKUP_MANAGER TRC_BACKUP_MANAGER.log 

Migration_CSM TRC_MIGRATION_CSM.log 

Migration_USD TRC_MIGRATION_USD.log 

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 

There are three primary aspects to common security: 

� Authentication 

Security 

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 – “:///” 

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

Authentication 

Authority Browsing 

CCL Security provides 

� Authentication 

� Authorization assistance & access tests 

� Authority browsing 

� Authority management 

� Identity reporting 

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. 

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: 


� Users 

� Groups 

� Computers 

� Management 

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

and certificates. 

Security 

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

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 


Authorization (Object Level Security) 

� On Unix: libetpki2.so, libetpki2_thread_posix.so 

Logging is done to the file of the calling component. 

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 

Access Control 

� 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 

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 bitoriented 

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 

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 


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 

Group of 

assets 

Group of 

servers 

Group of 

domains 

ca_group_def SEC_CLSID_COM_GROUP [1] Class, Group, 

Object 

ca_group_def SEC_CLSID_COM_ASSET_GROUP Class, object 

Ca_group_def SEC_CLSID_COM_SERVER_GROUP Class, object 

ca_group_def SEC_CLSID_COM_DOMAIN_GROUP Class, object 

Queries ca_query_def SEC_CLSID_COM_QUERY Class, object 

Security 

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 

Security 

Profiles 

ca_class_def SEC_CLSID_SEC_CLASS_SECURITY_ 

OBJECT 

Class, Object 

ca_security_profile SEC_CLSID_SEC_SECURITY_PROFILE Class, Object 

MDB Access -- SEC_CLSID_MDB_ACCESS Class 


Security 


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 


tables, Security Class ID and Level used in the Asset Management Table. 


Jobs Ncjobcfg + column 

job_category 

Modules Ncmodcfg + column 

motype 

SEC_CLSID_ASSET_JOBS 

SEC_CLSID_ENGINE_JOBS 

SEC_CLSID_MODUL_INVENTORY 

SEC_CLSID_MODUL_TEMPLATE 

SEC_CLSID_MODUL_SOFTWARE 

SEC_CLSID_MODUL_METERING 

Policies Polidef SEC_CLSID_POLICY_QUERYBASED 

SEC_CLSID_POLICY_EVENTBASED 

Class 

Class 

Class 

Class 

Class 

Class 

Class 

Class 

Software Ca_software_def SEC_CLSID_AMO_SW Class, Object 

Engines Ca_Engine SEC_CLSID_AMO_ENGINE Class, object 


Security 


tables, Security Class ID and Level used by the DSM Explorer Table. 


GUI task wizard [*] -- SEC_CLSID_COM_TASKWIZ 

(this is no longer used) 

Enable Control 

Panel 

Enable Remote 

Control 

Class 

-- SEC_CLSID_COM_CONTROL_PANEL Class 

-- SEC_CLSID_COM_REMOTE_CONTROL Class 


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 

Configuration 

Policies user 

OSIM object – 

Boot/OS images 

Troubleshooting 

Csm_object and 

csm_class is 

ConfPolicyComp 


csm_class is 

ConfPolicyComp 


csm_class is “OSimage” 

OR 

csm_object and 

csm_class is 

“BootImage” 

SEC_CLSID_CCNF_POLICY_COMP 

SEC_CLSID_CCNF_POLICY_USER 

SEC_CLSID_OSIM_IMAGE 

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 

Streams 

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. 

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. 


Networker 

Port Multiplexer 

Communication 

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. 

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 Messenger 

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. 

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. 


Session Messaging 

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

Message Forwarding 

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. 

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 




CORA): 


m 



tm 





� Upgrade checklist 

(http://supportconnectw.ca.com/public/impcd/r11/administration_and_ma 

intenance/unicenter_udsm_r11_upgrade_checkl.htm 

� Managing hostname changes 

http://supportconnectw.ca.com/public/impcd/r11/Unicenter/cms_main.ht 

m#namechange 

September 2007 Chapter 5: Installation Topics 5–1

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) 




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



Diagnosis Tips 

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. 

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 

Frequently asked Questions 


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. 

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

CCNF Parameters 

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! 

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 

Detection of Deployed Packages 

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


Increasing Primer Log Level 

Deploying to Linux over SSH 


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

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. 

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 “cadsm-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\\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 


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. 


Data Migration 


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 

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: 


� Limited Group Membership update on each run – unlinking not detected on 

legacy manager 

Migration of Software Policies (aka Software Templates): 


� Never sealed automatically 

� Sealed Software Policies are migrated on Domain only 

Migration of Computer and User Groups: 


� 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): 


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



USD Data Migration Implementation 

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. 

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. 


OSIM Specific Information 


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. 

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 


Remote Control Specific Information 

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. 

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 

Remote Control Data Migration 


Overview 

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. 

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

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



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. 



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


Problem 1: CAM in the DMZ 

Solution 


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. 

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. 

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 


� 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 



Problem 2: Infrastructure Deployment 

Solution 

Problem 3: AM/SD Job Checks 

Solution 

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. 

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. 

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. 

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

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 


Recommendation 


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

Scenario 2: Agent as CAM Proxy 

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. 

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. 

In this scenario all CAM communications are routed through the CAM proxy 

using appropriate CAM ROUTING rules on the Agents and Scalability Server. 



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 


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 


� SD jobs 

� SD Catalog 

Problem – Infrastructure Deployment 

Solution 

� 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 

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. 

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 





What Happens at Startup? 


tm 

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


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


Startup Under Windows 

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

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 



Startup under Linux 

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 

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 


Configuration Policy 

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

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. 

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 

Configuration Properties 


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

Property Storage 

In the MDB 

On the End System 

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 (also known as “persistence”) is maintained in different 

locations – in the MDB and on the end system itself. 

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. 

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 \Agent\CCNF while 

userstore.enc is stored in \\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: 

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

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. 



Domain Manager 

Engine [cmEngine.exe] 

Common Server – [cserver.exe] 

Scalability Server 

Agent 

CAF – [caf.exe] 

CF Register – [cfRegister.dll] 

Session Messaging 

Create Process 

Basic Inv Collector – [cfbasichwwnt.exe] 

trace 

trace 

trace 

trace 

TRC_CMENGINE_0.log 

am.log 

TRC_CF_DMDEPLOY_0.log 

TRC_CF_CAF_SERVICE_0.log 

TRC_CF_REGISTER_0.log 


Chapter 7: Software Scanning 

This chapter provides a closer look at the Asset Management software 

scanning process including: 

� General flow 

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



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


The following diagram illustrates the various modules and their interaction: 




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 


/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 

On UNIX\Linux, use the following syntax: 

camevmscli 



In both cases the 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 


/opt/CA/UnicenterDSM/Server/serverdb/SECTOR/COLLECT/00000001 

The naming convention for the file is: 

HOST_UUID.Wnn 

Using an Enterprise Server 

The DSM Engine later collects the file and populates the MDB appropriately. 

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: 




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: 



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



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


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 



TRC_URC_HOST 

GUI_n.log 

Host GUI 

(cfSysTray.exe) 

Capture Helper 

(rcUtilCmd.exe) 

TRC_URC_UTILCMD_ 

n.log 


The remote control connection function utilizes the following processes and log 

files: 

TRC_URC_HOST_n.log TRC_URC_VIEWER_n.log 

Host 

(rcHost.exe) 

RC Server 

(rcServer.exe) 

TRC_URC_SERVER_n 

.log 

Getting the Address Book 

SM 

Registration+ 

authentication 

TCP 

RC 

Session 

SM Host Commands 

SM 

Registration + 

Authentication 

Viewer 

(EGC30n.exe+ 

Gui_rcView.dll) 

SM 

Address books 

RC Manager 

(rcManSrv.exe) 

TRC_URC_MANSRV_ 

n.log 

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 

SQL

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. 

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: 


September 2007 Chapter 8: Remote Control Connection 8- 5


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: 


Cached\Fail Safe Validation 

Connecting to the Desktop 


Following is a graphical depiction of cached\fail safe validation authentication 

process: 

In this method there is no communication to the Domain Manager. 

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 

Starting Remote Control 

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. 

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. 


RCConfig and RCTrace 



The CRCDisplay object owns the RCVideoCapture & RCGraphics components. 

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. 

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: 


� 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



Following is a graphical overview of the Software Delivery architecture: 

Common Stack 

MDB File System File System File System 

TASKMAN INSTMAN SDSERVER 

APISRV DIALOGM 

MGRFT (not EM) 

DTSFT 

WAC 

WS 

Manager Scalability Server Agent 

SDDTAFLT 

SDDTPUSH 

EXPLORER 

CADSMCMD 

SDDTAFLT 

SDSSCMD 

Software Delivery processing can be broken down as follows: 

1. The software package is created. 

SDJEXEC 

SDMSIEXE 

SDPILOT 

SDDTAFLT 

CATALOG 

SDACMD 

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


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


Next is the relationship between the Enterprise and Domain Manager: 

Here you can see the Domain Manager to Domain Manager 

communication: 


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: 




When DTS is used, activation occurs as follows: 


Following depicts the effect when NOS is used: 

Following depicts the effect when NOS-less delivery is used: 




Here you can see the response: 

The following graphic demonstrates the distribution of orders between the 

Domain Manager and Scalability Server: 


DTS Integration 


The following demonstrates the relationship between the Scalability Server 

and Agents: 

Here you can see how the process changes when DTS is used: 



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: 

The following shares are used by the Software Delivery component: 

� \\\SDLIBRARY$ 

� \\\SDMSILIB 

USD Shares 

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 


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 

\SD\ASM\MSILIB SDSSCMD 

SDMSIEXE (via 

SDJEXEC) 

\SD\ASM\D TASKMAN (EM+DM) 

SDSERVER 

SDDTAFLT 

\SD\ASM\TMP 

\FLTSTAGE 

\SD\ASM\LIBRARY 

\ACTIVATE 

SDJEXEC 

SDDTAFLT 

TASKMAN (DM) 

SDSERVER 

SDJEXEC (via share) 

\SD\ASM\DATABASE TASKMAN (DM) 

SDSERVER 

\SD\ASM\CONF SDJEXEC 

SDMGRMIG 

Permanent location for 

software packages 

MSI administrative 

software pckgs 

Incoming and outgoing 

DTS transfers 

Incoming DTS transfers 

Temporary location for 

s/w pckgs for NOSbased 

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 

Non-MDB computer info, 

DTS control files, and 

host identity and 

notification data 

MSI detection file, 

migration MSI map file, 

agent state file and 

text-file based agent 

customization data 

Itrm/usd/shared/archive 

Itrm/usd/shared/msiadminp 

ath 

Itrm/usd/shared/incoming 

Itrm/usd/shared/outgoing 

Itrm/usd/shared/asmtemp 

(+”/activate’”) 

Itrm/usd/shared/database 


Library Used By Used For Configuration 

Parameters 

\SD\ASM\DEVICE SDPILOT Integration DLL for Palm 

Pilots, and other devicespecific 

data 

\SD\TMP SDJEXEC 

SDMGRMIG 

\SD\IPC SDJEXEC 

SDACMD 

\SD\NLS Nearly all SD 

programs 

Temporary files 

Signaling to agent from 

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

exists 

\ServerDB\SWJORDER SDSERVER Temporary location for 

s/w job orders and 

results and s/w 

detection records. Also 

location for serverspecific 

agent identity 

data 

\Agent\units\\u 

sd 

SDJEXEC Temp location for s/w 

job orders, results and 

s/w detection records. 

Also each can 

represent a computer, 

user profile or docking 

device 


Itrm/scalability_server/serv 

erdb_path (+”/swjorder”) 


USD Files 

USD Files 

The following files are used by Software Delivery: 

� \ServerDB\SWJORDER\\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\.ini 

Used by INSTMAN to store information about the agent’s previous domain 

manager. 

� \SD\ASM\DATABASE\compjobs\.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/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\\usd\sdjexec\.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 

The Software Delivery function uses the following MDB tables: 

Table Used for 

MDB Tables 

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) 

Usd_v_ownsite (DM) 

Usd_v_ls (EM) 

Enterprise Manager 

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 (EXE) 

Name 

The following process and log files are used at the Manager Level: 

CAF Name Logical Name Description Trace File 

Sd_taskm Sdmgr_tm Task Manager Main job evaluation 

Engine 

Sd_taskm Sdmgr_im Installation Mgr. Job results collecting 

Engine 

Sd_mgr_ft Sdmgr_ft File Tranfer mgr. File transfer Engine 

(enterprise r11.2) 

Sd_dtsft n/a DTS Integration Legacy file transfer 

Engine (removed in 

r11.2) 

Trc_usd_taskm_x.log 

Trc_usd_instman_x.log 

Trc_usd_sdmgrft_x.log 

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 

Sd_ahdcmd n/a Service Desk 

Integration 

Used for integration 

with Unicenter 

Service Desk 

Trc_usd_dialogm_x.log 

Trc_usd_sdahdcmd_x.log 


Process (EXE) 

Name 


The following table depicts the details for the DSM Explorer and Scalability 

Server components: 


Egc30N n/a SD Explorer UI Trc_GUI_x.log 

Sd_registerproduct n/a SW Package 

registrator 

Sd_server Sdserver SD Scalability 

Server Plug-in 

Process (EXE) 

Name 

Registers SXP, PIF, 

PKG and RPM 

packages. Called by 

DSM Explorer 

Handles all software 

jobs 

Trc_usd_sdserver_x.log 

The following table depicts the details for the DTS – on the Agent Tier: 


Tngdta dtsagent DTS Transfer 

Agent 

Tngdoba DTS Browser DTS Object 

Browser 

(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 

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 

Process (EXE) 

Name 

The following depicts the details for DTS on the Manager tier: 


Tngdtos Dtstos DTS Transfer 

Object Server 

Tngdtsnos Dtsnos DTS Network 

Object Server 

Main DTS data 

transfer Engine. 

Responsible for all 

managed transfers 

(Not req. in r11.1). 

Calculates the best 

transfer route 

according to CCS 

WV. 

Tngdt.dll n/a DTA API Main API used to 

communicate with 

DTS (USD, DTS 

CLI,etc) 

Tngdtsos dtssos DTS Scheduler 

Object Server 

Install Packages and Trace Files 

Trc_dtstos_x.log 

Trc_dtsnos_x.log 

TRC_DTS_x.log 

Enables scheduling of Trc_dtssos_x.log 

transfer activations 

(not used by USD)s 

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 + 


Explorer.msi n/a TRC_Inst_iTRM_x.log DSMSetupExplorer.log 


Following is the corresponding list for Linux installs: 

USD Logical Process Flows and Log Files 

S/W Pckg AfterCopy DSM Install Trace Installer Trace 

Ca-dsm-sdmanager.Linux.@pif 

Ca-dsm-sdserver.Linux.@pif 

Ca-dsm-sdagent.Linux.@pif 

Ca-dsm-dtsagent.Linux.@pif 

SDMgrAfterCopy TRC_*_x.log Ca-dsm.*.log 

SDSvrAfterCopy TRC_*_x.log Ca-dsm.*.log 

SDAgtAfterCopy TRC_*_x.log Ca-dsm.*.log 

DtswAgentAfterCopy + 


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. 


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 

OSIM Architecture 

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


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: 


DSM Explorer CADSMCMD 

OSIM queries OSIM plugin 

DSM 

MDB 

OS installation jobs 

with boot parameter. 

State of Jobs, Boot 

Server and Image 

OSIM Boot Server 

plug-in 

DSM Domain Manager 

OSIM Manager plug-in 

(CSM) 

Install boot and OS 

images in the 

image store of 

remote Boot 

Server 

Boot and OS Image 

Store + FCOR 

Store info 

about Boot 

and OS 

images 


OSIM extensions 

SD SW library 

SD pkg of Boot and OS 

image 

Register Boot 

and OS images 

as SD package 

Scalability Server DSM Packaging Tools 

PXE Data and Boot 

parameter 

Load Boot, OS 

Image 

PXE Target 

Computer 

Here you can see: 

IPS can share 

image store with 

Boot Server 

DOS boot 

diskette and 

original OS 

CD 

OSIM Boot and OS 

Image Prepare System 

Custom built 

WinPE, 

including OSIM 

files 

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


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 

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

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 

Create Boot Images 

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

Example 

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. 

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 

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. 


CreateBTImages looks for the Win98SE DOS boot diskette on “A:“ (the A 

drive) and does the following: 

Example 

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 


Create OS Image 

Example 

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

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: 


Prepare the Target for Network Boot 

Example 

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 

Editing the Job Parameter 

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. 

Installation parameters can be edited by selecting the OS Installation 

Parameters node as seen in the following example: 


Activate the OS Installation Job 

Example 

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 


Boot Image Tools and Templates 

The following topics present a more detailed discussion of various OSIM tasks 

and functions. 

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 


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



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 



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



Template Files and OS Types 

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. 

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 


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 ) 

copyfrompath=SUSEWCD100 

Copy details are in section SUSEWCD100 

;--read setup files from CDs but image is on external NFS Server (-a ) 

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 ) 

[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 







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



[SUSEWCD2] 

identfile=media.2\media 


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: 



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 



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


item=2057 English UK 

item=1036 French Standard 

To check the new parameter execute the following command: 

RegisterOSImage -i -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 -s 

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 into 

the 

remote Domain Manager using the following procedures: 

1. Export the OS-SD package into a directory. 

2. Transfer the directory 

to the remote site. 

3. Import the OS-SD package with 

the following command: 

Registerosimage -w directory -s Domain Manager 



Special Preparation 

for GHOST and PQIMG Based Images 

Use the following steps to create a clone image: 

1. Create a share (read, write) on IPS (including the ghost.exe). 

2. Create a FAT, FAT32 primary partition 

on the model target. 

3. Install the model OS (without DSM Agent) in the partition. 

4. Copy the MS sysprep files 

to the model PC and execute sysprep. 

5. Boot from a DOS Boot floppy with network access. 

6. Mount the share 

on IPS and execute ghost.exe from the share. 

7. Store the .gho on the share. 

8. Use createosimage and registerosimage 

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 

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 

Note: The upgrade depends on the ability of the 

with a new OS version. 

OS to upgrade a live system 


OSIM Domain Manager 

Plug-in 

OS Installation Job States 

Following depicts the OSIM Domain Manager plug in. 


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 



OSIM (CSM) Data Base Design 

Each job has to be defined in a planned configuration. After activation it 

becomes an activated, pending job and, after OS installation, it becomes 

current. 

Only one OS can be installed on a physical or virtual target. 

The OSIM database contains information about the following: 

� Boot and OS images 

� OS installation jobs (configurations) 

� Computer and Boot Server 

This information 

is derived from the following classes: 


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) 

Parametervalue (for OS 

images) 

Bootconfiguration (for OS 

installation jobs) 

1002 Type, Maxlength, Minvalue, 

Maxvalue, Trans, item (additional 

parameter values) 

106 See below 

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: 



Special Bootstatus Property 

The following values are used to identify a job’s bootstatus: 

Value Status 

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. 


OSIM Database Objects and Relationships 

Here you can see the relationship 

between OS Database objects: 

Here you can see the properties for an OS 

Job: 

Here you can see the link between OS Job and used OS image: 





Boot Server Components 

Boot Server Configuration 

Here you can see the various components used by the Boot Server: 

More details about these functions is provided in the next few sections. 


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: 



/DSM/Scalability Server/osim/ManagedPC/server 

The Minimum value for MaximumThreadPoolSize 50 and the Maximum 

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

0 means no reports. Default = 1 

� DebugLevel (Level to log TFTP file requests) 

The level of detail to output to the TFTP log file. 5 means all, 1 only errors. 

� TftpRetries 

(TFTP retries before timeout) 


The maximum number of retries to send a packet to a target machine 

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

This allows more simultaneous downloads on 

slower targets. 


� TftpTimeout (TFTP timeout) 



Maximum timeout in seconds to wait for the next packet from a target. 

Here you can see how the PXE and TFTP threads work together: 

The PXE thread monitors port 67 for DHCP discover. 

If U SEacl=1 it also monitors port 68 for offers from other Boot Servers. 

If the PXE thread sees more than 3 discovers 

without an offer, it will send an 

offer. 

The TFTP read request will be handled 

by the connection thread and will create 

a data transfer thread for each target. 



OSIM Boot Server Ping Thread Boot Server Password Setting 

The OSIM Boot Server Ping thread monitors 

targets by doing the following: 

� 

� Updating the TFTP access list. If the target answers a ping after 

starting 

the OS installation it will be removed from the TFTP access list. 

� 

Pinging known targets and waiting for a ping response 

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) 


Time in seconds between which pinging of all machines known by the Boot 

Server is performed. 

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. 

The following parameters are used to configure the password 

change thread: 

� PWCDays (Password change interval) 


Time 

in days between password changes for the user canonprv. 

The following configuration parameters define the complexity of the created 

canonprv password: 

� PW_length (Password length) 

The maximum length of the password generated for user canonprv. 


Boot Server Agent Copy Thread 


� PW_num_digits (Number of digits in password) 


The minimum number of digits [0-9] to be generated when generating 

a 

random password for canonprv. 


� PW_num_upper_case_characters (Number of upper case characters in 

password) 

The minimum number of Uppercase Characters [A-Z] to be generated. 


� PW_num_lower_case_characters 

password) 

(Number of lower case characters in 

The minimum number of Lowercase 

Characters [a-z] to be generated. 


� PW_num_symbols (Number of symbols 

in password) 

The minimum number of special symbol characters 

to be generated. If the 

value is larger then PW_length then this value will be truncated to 

PW_length. 


The Agent copy thread browses the sdlib (library.dct) to find packages 

matching a specific naming pattern and takes the most specific version. The 

most recently 

copied agents are listed in the agent.inf file: 

Agent store contains the .caz files which include the image format of the agent 

for TFTP download. 



Boot Server csmagent and sdbsmstate 

The following example demonstrates how the distribution of an OS installation 

job sent from the OSIM Manager to the Boot Server is listed in the 

TRC_CSMAGENT_0.log. 

The next example shows 

how delivery of the Boot Server hello message (alive) 

to the OSIM Manager is written in the TRC_CSMAGENT_0.log: 


Following is a list of reports that can be launched to the Manager by 

sdbsmstate (Csmagent): 

Report Description 

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 

September 2007 Chapter 10: OSIM 10- 41 

the


Boot Server Administrative Files 

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

Administrative files for sdbsmstate are kept in the following location: 

c:\Program Files\CA\DSM\Server\SDBS\var\ManagedPC. 

Sdbsmstate 

reports changes of Boot Server data to the manager only once. 

The following files are used as memory for reports: 

Filename 

Contains 

Bsmbreq.dat Reported boot 

requests 

Bsmconf.dat Start data of the job to compare with FCOR 

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: 


Following is the key to interpreting the contents: 

� Modified = 0 means “reported” while Modified = 1 means “not yet 

reported” 

� :*osimage = OS image was found on Boot 

Server 


� AckId = report ID and the AckId on the last line identifies 

the report that 

was most recently accepted by the manager 

Following is an example of the contents of a bsmstat.dat file: 

Following is the key to interpreting the contents: 



� 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 


Boot Server WOL and Reboot 

Boot Server Access from Target 

File name Contains 

Mac.acl MAC of all targets the Boot Server is 

ble for 

responsi 


ManagedPCDataFile (FCOR) basic 

PXE data of targets (binary 

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

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. 

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 all 

subnetworks 

� Additionally the Boot Server plug-in, sdbsmstate, looks into the common 

server target list (IP, subnet masks) 

to create a list of subnet addresses 

where DSM targets are located. 

The sdbsmstate sends a WOL package to the broadcast address of each 

calculated subnetwork. 

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. 



� 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 

� GHOST, GHOST32, PQIMG OS can only be installed from shares. 

Here you can see how the OS insta llation occurs via share access of TFTP for 

Windows releases (Win98 thru Win2003): 

You can switch between Share mode and TFTP by configuring the Boot Server 

access mode. The sdbsswitch command creates or removes the OSIM shares 

and changes the image 

data between the shared directory structure and the 

image file for TFTP download. 

� sdbsswitch -t switches 

from share to tftp access. 

� sdbsswitch -s switches from tftp to share access. 

� sdbsswitch -l shows the current configuration 

of the Boot Server. 

When 

either sdbsswitch -t or -s executes it shuts down the sdmpcserver 

process and does the following: 

� 

Searches the image store for all osinfo.ini. 

� Looks in each osinfo.ini for information about the shares and imagefile 

– Createzip = imagefile (If TFTP, this imagefile must be created) 

– Sharename = sharename (Name of the share which 

is also for NFS) 


Remote Execution of sdbsswitch 

with Configure Job 

Access for LINUX OS images 


– Createshare = MS or NFS or MSNFS (creates this type of share where 

MS = Microsoft share; NFS = LINUX NFS share; MSNFS = both ) 

The Scalability Server package includes configure 

procedures to change the 

Boot Server access method via Software Delivery. 

Linux OS image setup always requires NFS shares. When the NFS shares are 

on the Boot Server the following applies: 

� Windows Boot Server requires UNIX services 

for Windows 3.5 or later for 

the NFS shares. 

� LINUX Boot Server requires an active NFS server. 

NFS shares can also be provided on a central Windows or Linux server, 

however, the directories and the NFS share must have read access rights for 

anonymous. 



IPS and Boot Server on One 

System 

When Boot Server is in TFTP mode the Createosimage -i 

command does not create a .caz file. This must be done later with the 

following command: 

createosimage –z 

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 ) 

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 

Boot Server will be notified from the ADS server. 

� The Boot Server 

reports the ADS managed targets to the DSM domain 

manager. These targets will be marked as ADS managed in the MDB. 

� The Domain Manager also removes all 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 

becomes an unmanaged OSIM target again. 



You can also delete the ADS target from 

the MDB and make it managed again. 

To configure the Boot server as an ADS proxy use the following: 

� ADSUse (Enable ADS proxy function) 

Must be set to 1 or true to enable the ADS proxy 

� ADSProvider (ADS controller 

name) 

� 

� 

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 have 

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 

set by following these procedures: 

– First create 

a new user from computer Management 

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

� ADSDomain (ADS domain name) 

The domain to use to authenticate the user when connecting to the 

controller. This can be left blank if the user to authenticate has been 

defined on the ADS controller. 

� ADSAuthenticationType (ADS authentication 

type) 

The type of authentication to use when connecting to the ADS controller. 

This value can be set to either ntlmdomain, or Kerberos. 


OSIM and CADSMCMD 

OSIM Boot Server and Manager Events 

TFTP OSIM Boot Server Events 


Both the OSIM Boot Server (sdmpcworker) and OSIM Manager (DSM) write 

events to the Application event log. 

For a complete list of events, refer to the OSIM Inside Guide. 

The TFTP communication component 

of the OSIM Boot Server (sdmpcworker) 

can be configured 

to write events for every TFTP read request. Since a large 

num ber of TFTP requests can overflow the event log, you may want to switch 

off the TFTP events in the common configuration by editing the 

LogTftpFileRequests 

parameter. 

� 

� Se t to false it disables logging of TFTP read requests. 

CADSMCMD is a command line interface that can be used to support process 

automation for Desktop and Server Management. It includes commands and 

actions 

for the following OSIM related functions: 

� 

Set to true for a specific Boot Server, it enables logging of TFTP read 

requests. 

� Administering target systems 

Setting up new OS configurations and maintaining them 

� Initiating and controlling OS installation requests via network 



On Linux this includes the following: 

� cadsmcmd (/opt/CA/DSM/sd/bin) 

� libsd_bmscapi.so (/opt/CA/DSM/sd/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) 

� CCNF CAPI (libccnfclient.so, ccnfclient.dll) 

� SD CAPI (libsd_gapi.so, sd_gapi.dll) 


The OSIM capabilities of CADSMCMD can only be used under the following 

conditions: 

� when the addressed DSM manager is a Domain Manager 

� when the addressed Domain Manager has SD capability 

Following is an architectural overview of CADSMCMD: 



CADSMCMD receives its requests via one of the following interfaces: 

� Batch interface 

A sequence of CADSMCMD requests are coded in 

a file and this file is 

processed by the CADSMCMD in one block and session. 

The control is 

returned to the application or user after 

the file (and all of its requests) 

have been processed. 

� Call interface 

One request is passed with the CADSMCMD and processed. 

The session to 

the manager is established when the CADSMCMD starts and terminates 

when it ends. The application can now react on requests 

results 

immediately but the session establishment overhead has to be considered. 

� Pipe interface 

With the CADSMCMD start a named pipe is established and the 

CADSMCMD receives its requests via that pipe. The session 

remains until 

the application or user explicitly requests for session termination. 

More 

than one CLI request can be sent to the CLI by an application 

or user and 

they can directly react to request result and do not suffer from the session 

establishment overhead. 

� Verbose interface 

This is a menu driven interface that is not used for process automation. 

CADSMCMD breaks the request down into a sequence of atomic sub-requests 

that are handled by the API layer. These atomic requests can be for different 

APIs. The native OSIM stuff is handled by the OSIM CAPI that further breaks 

the requests down into a sequence of CSM CAPI requests. 

Utilizing the DSM Session Messaging the requests are transferred to a DSM 

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

� SDCMD_TRACE_OPT=B3C9 



C code should be set to 9 as CSM trace is no longer supported from CLI layer 

(it has to be managed by cfTrace commands now). 

The default log file, cadsmcmd.log, is located at the DSM log directory; 

however, 

different CADSMCMD can write different logs. 

The CAPI trace entries are found in the TRC_USD_x.log in the DSM log 

directory. 

It is possible that several concurrent CADSMCMDs are logging into separate 

log files. 

When CADSMCMD is started it records the following information about the 

established session at the console: 

� Identification information: 

This is the first information recorded and it 

includes identification information 

for CADSMCMD and the copyright. The 

version shown is the build information of the executable. 

� Log information: Whether 

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 

manager and the authentication 

of the session. 



TargetComputer command 

– 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 

addressed otherwise the local one is taken. 

– is the current user. This user is always 

used if no Login 

information is passed with the CADSMCMD. It forces a unified logon. 

If 

authentication information is passed with the Login parameter this 

one 

is used. 

– Manager: Name of the manager the CLI is connected to 

– Domain: 

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. 

OSIM uses the CADSMCMD “targetComputer” command. The set of actions is 

nearly the same as with USD 4.0: 

Action Description 

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 OSIM 

managed computer 

showInstallParameter Lists the installation parameters 

of an 

OSIM configuration 

modifyInstallParameter Modifies installation 

parameters in a 

planned configuration 

Delete {planned|scheduled}OS Deletes the specified 

OSIM 

configuration of a required type 


Act ion Description 


activateOS Schedules a planned OS configuration 

for installation 

reactivateOS Reschedules a failed or canceled 

configuration 

reinstallOS 

Schedules the current OS 

configuration for reinstallation 

cancelOS Cancels a schedules OS installation 

request (graceful) 

Dele te Deletes a computer agent entry in 

DSM 

When it comes to OSIM support the CADSMCMD CLI is backwards compatible 

with V4, however please note the following: 

� due to the name change from SDCMD to CADSMCMD users may have to 

– rename 

the SDCMD calls to CADSMCMD in their existing scripts on 

Windows 

– provide a link for SDCMD to CADSMCMD or to rename SDCMD to 

CADSMCMD in their existing 

scripts too on Linux 

� 

The “linkBMS” action is now obsolete. With USD 4.0 OSIM and USD used 

different databases. There was no integration on DB 

layer. If a computer 

was registered at USD and becomes PXE enabled for the first time it 

registered with its MAC address and no name at OSIM. The linkBMS action 

was used to link the OSIM entry and the USD entry and name the system 

in O SIM as in USD. In DSM this has changed due to use of the MDB. If a 

PXE enabled system registers at the OSIM side CSM checks whether there 

is already 

a DSM registered system of the same MAC address and on 

match it 

links the entries. Since the linkBMS command is now obsolete if it 

is invoked a warning is given at the console that this action is obsolete and 

a “0” is returned to the application. 

� The handling of the password parameter 

has changed. 

� The “userParameter“ 

and ”userName“ parameters of 

“modifyInstallParameter” 

have become 

obsolete. 

With USD 4.0 when a p arameter of type password was changed then 

additional information had to be passed for encrypting the new 

password 

correctly. This additional information had been either the name of a parameter 

presenting a user id or the user id directly. 

This user id was the key for 

encrypting the password. 

With DSM r11 OSIM has changed its encryption-decryption handling and no 

longer needs a user id as a key; it is independently encrypted/decrypted of it. 



Enhancements/Changes 

In r11 the parameters “userParameter” and “userName” are ignored by 

CADSMCMD. No error or warning is given. 

Here you can see how the command syntax has changed: 

targetComputer action=create 

name=«computer 

name» 

computerTy pe={machine | user profile | staging server | docking device} 

address=«network address» 

os=«operating 

system type» 

[stagingServer=«staging server name»] 

[calendarName=«calendar name»] 

[user=«user»] 

[phone=«phone»] 

[location=«location»] 

[comment=«comment»] 

[softwareManagedSystem[={y|n}]] [racPolicy={ common | disabled | deferred | automatic}] 

[hostName= «host name»] 

{[macAddress=«MAC address»] | 

[bootServer=«Boot Server name»] macAddress=«MAC 

address» 

osImage=«os image name»} 

The syntax of the action “create” has been changed. The options “hostName” 

and “macAddress” can also be coded without OSIM context now. To create an 

OSIM 

entry beside the DSM common and USD entries the options macAddress 

and osImage have to be coded, but “bootServer” has become optional. If not 

coded 

an OSIM computer entry is created without any relation to any Boot 

Server. 

This missing link is established when the computer registers in OSIM 

from the network (PXE enabled). 

targetComputer 

action=activateOS 

name= «computer name» 

[atTime=«YYYY-MM-DD hh:mm»] 

[wakeup[={y|n}]] 

[restart[={y| n}]] 

[wai tBs[={y|n}]] 

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

and if the specified target is 

not assigned to a Boot Server the order will fail. 


Example Scenarios 

Example 1 


If waitIm or waitIm=y is coded then the CSM will defer the processing of the 

related OS installation until a BT and OS images 

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 

order will fail. 

targetComputer action=reactivateOS 

name=«computer name» 


[wakeup[={y|n}]] 

[restart[={y|n}]] 

[waitBs[={y|n}]] 


targetComputer action=reinstallOS 

name=«computer name» 


[wakeup[={y| n}]] 

[restart[={y|n}]] 

[waitBs[={y|n}]] 


Following are a series of examples demonstrating the use of CADSMCMD for 

OSIM purposes. 

In this example a computer entry is provided in advance for a system that 

might be delivered in the (near) future. 

As long as the manufacturer provides 

the user with the MAC address 

of such a system beforehand the user is able to 

prepare the systems setup. 

In addition to the MAC 

address, the following other details are needed: 

� the system name or label 

or host name 

� its network address 

� 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 

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. 



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 

� Scalability Server = my_server 

� Boot Server = my_server (same 

as above) 

� targeted OS image 

= myWinXP 

Here is the syntax: 


name=osim_sy_1 

computerType=machine 

address=osim1.ca.com 

os=win_xp_intel 

stagingServer=my_server 

macAddress=FF:EE:CC:01: 23:01 

bootServer=my_server 

osImage=myWinXP 

This command creates a DSM computer agent and makes it OSIM managed. 

The provided planned configuration can now be configured and monitored by 

using 

the modifyInstallParameter and showInstallParameter actions as in the 

past. Once the configuration requirements are met, it can then be scheduled 

for installation by launching the following command: 

targetComputer action=activateOS 


Assuming that the related images are all staged at the associated Boot Server 

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 identifies the system by means of its MAC 

address (given as part of the request) and knows that it is responsible for it 

and has an installation request pending for it. The Boot Server responds to 

the 

request and with that response the system is informed to down load a boot 

image, related to the OS image request above. 

The OS installation then starts 

wit h that boot image. 

In addition to the OSIM installation request a Software Delivery installation 

request can be provided in advance. When the OS installation completes 

and 

the system runs up then a DSM agent is normally installed on it. That agent 

then registers at the appropriate manager 

and starts processing the provided 

USD installation requests. 


Example 2 


The final result is a new system on which the OS has been installed through 

OSI M and the required applications have been installed and configured 

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

is “osim_sy_2” and the 

network address is “osim2.ca.com”. 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 

Server. Rather, the Boot Server will automatically be assigned when the PXE 

system registers 

for the first time. 

Here is the syntax: 




address=osim2.ca. com 


macAddress=FF:EE:CC:01:23:02 


The command is nearly the same as in the first example but the options 

“stagingServer” and “bootServer” are not coded. Those 

of you who are familiar 

with the old SDCMD know that the newly created system in DSM is assigned to 

the Scalability Server with the manager, 

but in OSIM the system is not 

assigned to any Boot Server. 

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 required 

OS 

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

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

been forward to the old Scalability Server are now 

transferred to the new one. 



Example 3 

Example 4 

Next, let us consider a bare 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”. 

This time the system that will become OSIM managed has already registered 

as a bare metal system at OSIM. In other words, the only information DSM 

has about that system is its MAC address in OSIM and the Boot Server that 

has detected that system. 

The following syntax makes the system predefined in DSM and OSIM 

managed: 




address=osim3.ca.com 


stagingServer=my_server 

macAddress=FF:EE: CC:01:23:03 

bootServer=my_server 


Once this command is launched the PXE system is allocated as a predefined 

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

enabled. Once the system is PXE-enabled and rebooted it will register at OSIM 

and be linked with the already existing DSM computer entry. However, it will 

remain OSIM un-managed because no OS configuration has been assigned 

yet. The syntax for making this system OSIM managed is: 

targetComputer action=setupOS 



This command creates a planned configuration of myWinXP for the osim_sy_4 

system. It does not change the Scalability or Boot Server assignments. 


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 

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 already 

managed when it is registered: 

targetComputer action=setupOS 



This command makes the target 

OSIM managed but the Boot Server won’t be 

assigned to it until 

it registers with OSIM. 

The following syntax 

advance: 

targetComputer action=activateOS 


waitBs=y 

can be used to schedule the installation request in 

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

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 

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 plugin 

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


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


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) reads the OS files from the vendor’s media and combines this with the 

OSIM files to create OSIM OS images and Boot Images. 


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. 



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. 


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


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. 


The Web Console is a browser-based user interface to Unicenter DSM, which can be installed on 

Windows and Linux operating environments.

DSM Advanced Topics Guide - SupportConnect - CA

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?