DSM Adv Topics r11

Unicenter Desktop and Server Management
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 CAs 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 CAs sole discretion. The information in this publication is based upon CAs 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) CAs then-current maintenance and support policy for the referenced product. Certain information in this publication may outline CAs general product direction. All information in this publication is for your informational purposes only and may not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA provides this document AS IS without warranty of any kind, including, without limitation, any implied warranties of merchantability, fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost investment, business interruption, goodwill or lost data, even if CA is expressly advised of the possibility of such damages. Copyright License and Notice This publication contains sample application programming code and/or language which illustrate programming techniques on various operating systems. Notwithstanding anything to the contrary contained in this publication, such sample code does not constitute licensed products or software under any CA license or services agreement. You may copy, modify and use this sample code for the purposes of performing the installation methods and routines described in this document. These samples have not been tested. CA does not make, and you may not rely on, any promise, express or implied, of reliability, serviceability or function of the sample code. Copyright 2007 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
Contents
Chapter 1: Introduction
References ................................................................................... 1-1 Providing Feedback ........................................................................... 1-2
Chapter 2: Component Details

The Engine ................................................................................... 2-2 Engine Startup ........................................................................... 2-4 Engine Tasks ............................................................................. 2-5 Managers .................................................................................... 2-9 Infrastructure Deployment Manager ........................................................ 2-9 Common Object Manager................................................................. 2-10 The MDB .................................................................................... 2-11 MDB Installation ......................................................................... 2-12 Data Transfer Service (DTS).................................................................. 2-14 DTS Transfers ........................................................................... 2-15 DTS Components ........................................................................ 2-16 The Agent and DM Primer .................................................................... 2-25 Report Extractor ............................................................................. 2-25 Architectural Overview ................................................................... 2-26 Report Templates ........................................................................ 2-27 Communications ......................................................................... 2-29 Diagnosing Problems ..................................................................... 2-29 Web Admin Console (WAC) ................................................................... 2-31 WAC and AMS ........................................................................... 2-32 Diagnosing Problems ..................................................................... 2-32 Web Services ................................................................................ 2-33 Things to Note ........................................................................... 2-35 Diagnosing problems ..................................................................... 2-35
Chapter 3: DSM Explorer

Architectural Overview ........................................................................ 3-1 Diagnostic Tips ............................................................................... 3-2 Common Plug-in .............................................................................. 3-3 CCNF Plug-in ................................................................................. 3-5
September 2007
Contents iii
References
Reading Configuration Policies............................................................. 3-6 DM Deploy Plug-in ........................................................................... 3-8 Diagnosing Problems ..................................................................... 3-9 Directory Browser Plug-in .................................................................... 3-10 Directory Wizard ........................................................................ 3-10 Directory Synchronization ................................................................ 3-11 Directory Browsing ...................................................................... 3-12 Asset Manager (AM) Plug-in ................................................................. 3-12 Software Delivery (SD) Plug-in ............................................................... 3-16 Remote Control (RC) Plug-in ................................................................. 3-20 Things to Note .......................................................................... 3-23 OSIM Plug-in ............................................................................... 3-23
Chapter 4: CAF
What is CAF? ................................................................................ 4-2 OS Services ................................................................................. 4-5 Tracing .................................................................................. 4-5 Security ..................................................................................... 4-9 Authentication .......................................................................... 4-10 Encryption .............................................................................. 4-12 Authorization (Object Level Security) ..................................................... 4-13 Communication ............................................................................. 4-20 Streams ................................................................................ 4-20 The Messenger .......................................................................... 4-22
Chapter 5: Installation Topics

Infrastructure Deployment .................................................................... 5-2 Processes and Log files ................................................................... 5-4 Stage to and Deploy from Scalability Server................................................ 5-5 Diagnosis Tips ........................................................................... 5-6 Frequently asked Questions ............................................................... 5-7 Additional Considerations for r11.2 ........................................................ 5-8 Upgrading from a Previous Release ........................................................... 5-12 Data Migration .......................................................................... 5-13 DSM and NAT ............................................................................... 5-20 Overview ............................................................................... 5-20 Scenario 1: Scalability Server as Proxy Router ............................................ 5-21 Scenario 2: Agent as CAM Proxy ......................................................... 5-25
iv Desktop and Server Management Advanced Topics Guide
September 2007
References
Chapter 6: Startup and Configuration

What Happens at Startup? .................................................................... 6-1 Startup Under Windows ................................................................... 6-4 Startup under Linux ....................................................................... 6-6 Infrastructure Configuration ................................................................... 6-8 Configuration Policy ....................................................................... 6-8 Activating Computer Configuration ......................................................... 6-8 Enterprise and Domain Policies ........................................................... 6-10 Property Storage ........................................................................ 6-10 Processes and Log Files .................................................................. 6-14 Agent Registration ........................................................................... 6-15
Chapter 7: Software Scanning

Overview and Flow ........................................................................... 7-1 Processes and Log files ....................................................................... 7-3 A Closer Look at the Content Download Process ............................................. 7-4 A Closer Look at the XML Generation Process ............................................... 7-5 A Closer Look at the Engine Transfer Process ............................................... 7-6 A Closer Look at the Scalability Server Transfer Process ..................................... 7-6 Using an Enterprise Server ................................................................ 7-8 A Closer Look at the Import\Export Utility .................................................. 7-8 Diagnosis Tips ............................................................................... 7-10
Chapter 8: Remote Control Connection

Overview and Flow ........................................................................... 8-1 Processes and Log files ....................................................................... 8-3 Getting the Address Book ..................................................................... 8-3 Getting the Authority List ..................................................................... 8-4 Centralized User Validation ................................................................ 8-6 Cached\Fail Safe Validation ................................................................ 8-7 Connecting to the Desktop .................................................................... 8-7 Terminal Services Obstacles ............................................................... 8-8 Displaying Confirmation Dialogs .............................................................. 8-10 Starting Remote Control ..................................................................... 8-10 RCConfig and RCTrace ................................................................... 8-11 Diagnosis Tips ............................................................................... 8-11
September 2007
Contents v
References
Chapter 9: Delivering Software

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

OSIM Architecture........................................................................... 10-1 Process and Log Files ........................................................................ 10-4 Installation and Configuration ................................................................ 10-5 Multiple Boot Server (BS) in a PXE broadcast network ..................................... 10-6 Prioritization of Boot Server with Remote Configuration .................................... 10-6 Image Prepare System (IPS)................................................................. 10-8 Example .................................................................................... 10-9 Create Boot Images ..................................................................... 10-9 Register DOS Boot Images .............................................................. 10-12 Create OS Image ....................................................................... 10-13 Register the OS Image ................................................................. 10-14 Prepare the Target for Network Boot..................................................... 10-15 Boot the Target ........................................................................ 10-16 Change Selected PXE Target to Managed................................................. 10-16 Editing the Job Parameter ............................................................... 10-16 Activate the OS Installation Job ......................................................... 10-17 Boot the Target to Execute the OS install job ............................................. 10-17 Under the Hood ............................................................................ 10-18 Boot Image Tools and Templates ........................................................ 10-18 Template Files and OS Types ............................................................ 10-22 Registering to Another Domain Manager ................................................. 10-27 Special Preparation for GHOST and PQIMG Based Images ................................. 10-28 Upgrade Procedure for OS-SD packages ................................................. 10-28 OSIM Domain Manager Plug-in .......................................................... 10-29 OS Installation Job States ............................................................... 10-29
vi Desktop and Server Management Advanced Topics Guide
September 2007
References
OSIM (CSM) Data Base Design...........................................................10-30 OSIM Database Objects and Relationships ................................................10-33 Boot Server Components ................................................................10-35 OSIM and CADSMCMD ......................................................................10-50 Architectural Overview ..................................................................10-51 Diagnosing Problems with CADSMCMD ...................................................10-52 TargetComputer command ..............................................................10-54 Enhancements/Changes .................................................................10-56 Example Scenarios ......................................................................10-57
Glossary
September 2007
Contents vii
This guide provides a closer look at several key Unicenter Desktop and Server Management components and functions. It is intended to be used in conjunction with the product documentation and other supporting materials available through the Technical Support website. This information is presented in a series of chapters and topics that cover product specific and shared aspects of Unicenter DSM. The chapters are intended to be self-contained and randomly accessible. Updates and revisions will be provided on an ongoing basis and will be clearly noted.
References
The following additional documents are referenced and should be consulted for further details: Unicenter DSM r11.x Implementation Guide Unicenter DSM r11.x Release Impact Guide Inside Guides for Asset Management, Software Delivery and Remote Control Product Readme files and online HELP The most up-to-date technical guidelines and tips can also be found on the CA Support Online website (http:\\support.ca.com). In addition, best practice guidelines for both Unicenter DSM and its underlying database (the MDB) can be found at the following link: http://supportconnectw.ca.com/public/impcd/r11/StartHere.htm Included on this site is the Unicenter Desktop and Server Management Diagnostics Guide which includes basic troubleshooting procedures and a list of common symptoms and solutions. Following is the direct link to the CA Messaging Troubleshooting Guide which contains information on diagnosing problems with CAM and CAFT, common components used by Unicenter DSM: http://supportconnectw.ca.com/premium/unicenter30/infodocs/TEC418063.pd f Note that this document requires a login to the SupportConnect site.
September 2007
11
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.
12
Desktop and Server Management Advanced Topics Guide
September 2007

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
21
The Engine
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp
The Engine
The Engine is a multi-instance, multi-function, distributable component. Its primary focus is the maintenance of computers and related information. Logic is encapsulated into a number of Engine Tasks enabling them to be scheduled to run at regular intervals. The DSM Engine supports the following tasks Sector collect inventory collection from Scalability Server Data Replication copying of key data between Domain and Enterprise databases Dynamic Group Evaluation Evaluation of the membership of 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.
22
September 2007
The Engine
Note: When a DSM Domain Manager is running on Linux with an Ingres MDB and the Enterprise Manager is running on Windows with MS SQL Server then a Windows Domain Engine is required for successful replication.
September 2007
Chapter 2: Component Details 2- 3
The Engine
The following diagram provides an overview of the different pieces that comprise the Engine:
cfnotcli
CMEngine
amoDataClasses sqlexec
This includes the following: CmEngine responsible for server/manager registration, Enterprise/Domain linking and Server/Engine linking cfnotcli notification client side API Sqlexec generic database API amoDataClasses embedded library of data access classes
Engine Startup
Engine startup is comprised of the following tasks: 1. 2. 3. 4. 5. 6. 7. Engine started up by CAF Instance name passed on command line DSM Manager hostname read from comstore Database Name, Type, Credentials and other details are obtained from Common Manager Database is opened Jobs assigned to Engine are read Work begins!
24
September 2007
The Engine
Engine Tasks
As noted earlier, key Engine tasks include the following: Collection Replication Reporting Migration Evaluation of Polices/Dynamic Grouping Licenses
Sector Collection
During Sector Collection the Engine basically does a READ and WRITE to a Scalability Server. When an Agent initially connects to a Scalability Server it submits a request to be created and it will store all information it would like to push to the database in a collect area on the Scalability Server. When the Engine connects to a Scalability Server it first verifies the integrity of the Scalability Server (for example, does the Scalability Server contain all the information about the Assets that it is supposed to according to the database?). Next, it checks the Request Area (new area in UAM terms) to see if any assets have requested to be created. The Engine checks to see if those assets (or Users) already exist in the database and confirms that the Scalability Server information correctly identifies this Scalability Server (i.e., the one from which the information is currently being collected). If the Assets are new to the whole system they will be created in the database and in the Scalability Servers 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
September 2007
The Engine
Relation information (between Computers/Users/Devices etc) The information that is collected is then stored in the appropriate table in the MDB. For example: Computer information is stored in the ca_discovered_hardware table and created in the common asset model using the CORA API. User Accounts are stored in the ca_discovered_user table User Profiles are stored in the ca_link_dis_hw_user table Relationships (e.g. VMware host/guest) are stored in the ca_link_dis_hw table Additional information for each of these items is also stored in the ca_agent and ca_agent_component tables. When Computers are created in the ca_discovered_hardware table a call is made to CORA. CORA is responsible for maintaining the Common Asset Model and enables the integration between NSM, DSM and USVD/UAPM. One inventory table is set for each component while General/Common Inventory is stored in inv_generalinventory_item and inv_generalinventory_tree Note: Additional information regarding CORA can be found in the MDB Hardware Assets and CORA document available from the following link: http://supportconnectw.ca.com/public/impcd/r11/MDBMain/Doc/CORA_MDB_a nd_Assets_SC.pdf New Inventory tables are generated in the MDB by the Engine when new inventory is collected.
Query and Dynamic Group Evaluation

The basic functionality of the Query and Dynamic Group Evaluation tasks have not changed significantly since the previous 4.0 release of Unicenter Asset Management. In r11, however, group definition details are stored in ca_group_def table in the MDB and the link between Group and Member (Computer, Users, etc.) is stored in the ca_group_member table. Queries definitions are stored separately in the ca_query_def table. Query based groups and policies are evaluated by the Engine based either on set time intervals or when the servers are processed.
26
September 2007
The Engine
Replication
Replication functions utilize the following MDB tables: Database triggers/procedures are kept in the auto_rep_version table Creation of database triggers and procedures include the following: Update/insert on Ingres Delete on Ingres and MSSQL
Replication configuration information is kept in the ca_replication_conf Replication status is kept in the ca_replication_status table Replication deletion history is kept in the ca_replication_history When the Domain is linked to an Enterprise, Domain information is maintained in the ca_n_tier table while Manager information is maintained in the ca_manager table. Data is owned either by the Domain or the Enterprise and records are only replicated one way. If a record is changed on the target it will be overwritten. The sequence is as follows: Process deletes go from Domain -> Enterprise Process updates go from Domain -> Enterprise Process deletes go from Enterprise -> Domain Process updates go from Enterprise -> Domain To delete records select top 25000 * from ca_replication_history where table_name=ca_agent and auto_rep_version > last_deleted while (more records) { if (record owned by source database) delete record in target database last_deleted = record.auto_rep_version next record } To update records select top 25000 * from ca_agent where auto_rep_version > last_updated while (more records) {
September 2007
The Engine
if (record exist in target database) update record in target database else insert record into target database last_updated = record.auto_rep_version next record } On SQL server the auto_rep_version field is of type timestamp. This field type is always automatically updated and it contains a unique value for the table. On Ingres, however, this is a date type field and it is only populated when the triggers and procedures are created during linking. Furthermore, since the value is not unique some additional logic is implemented to make this work on Ingres. To unlink a Domain from the Enterprise you need to: Deregister assets on Enterprise Remove replicated data based on ca_replication_conf Remove database triggers and procedures To support the process of computers roaming between Domains linked to the same Enterprise before a computer is replicated to the Enterprise the replication mechanism checks to see if there is already a computer listed with the same host uuid but from another domain. If one is found, it is deleted from the Enterprise and a record is added to the Enterprise history table. The replication mechanism also checks the Enterprise history to see if any of the roamed computers belongs to this Domain.
28
September 2007
Managers
Managers
There are two types of managers that will be discussed here: the Infrastructure Deployment Manager and the Common Object Manager.
Infrastructure Deployment Manager

The Infrastructure Deployment Manager (dmdeploy) controls the overall deployment mechanism and maintains status among other tasks. It is a CAF plug-in that can be stopped and started through the following command:
caf stop dmdeploy caf start dmdeploy
Upon startup the Infrastructure Deployment manager generates public/private encryption keys if they are not already present. Old keys are retained, but can be generated afresh after removal though this requires 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: <PF>\CA\Unicenter DSM\Packages For Linux: $CA_ITRM_BASEDIR/Packages The \Public subdirectory contains the payloads which can be deployed (selectable in the wizard). The <PF>\CA\Unicenter DSM\Packages\Private folder contains the DMPrimer installation images and intermediate copies of payload data. The DMAPI is used by deployment consumers, such as dmsweep and the Deployment Wizard, to communicate with the manager. All user-visible deployment functionality is driven through the API. During installation, the software that is to be installed (i.e., the payload) is stored in the Deployment Packages/Public area on the Manager and subsequently staged on Scalability Servers. Only agents and servers are currently supported. Deployment components are decoupled from payloads. In other words, you can slot in new versions or even new payloads without altering the DMDeploy software. Payload configuration is managed through the dmdeploy.dat file which does the following:
September 2007
Managers
Defines payload name and version Defines the command line to use to install the payload. Optionally defines CLI parameters which must be supplied by customer prior to deployment. Since Dmdeploy.dat contents are processed on the fly by the Deployment Manager any changes that are made take effect for all subsequent deployments.
Common Object Manager

The Common Object Manager provides a set of core, prerequisite, fundamental services that all other Manager components build upon or use. It provides the following services: API access to common objects shared across the products Scalability Server registration and Engine linking Domain Manager to Enterprise Manager linking Examples of Common Objects include: Computers User Accounts User Profiles Managers Servers Domains Groups Engines Queries Companies Software Categories Software Definitions Agents Scalability Server Components Manager Components Agent Components The Common Object Manager is implemented as a set of executables and shared libraries:
210
September 2007
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.
September 2007
The MDB
The MDB schema includes the database objects used by CA products and their components. These include tables, columns, views, triggers, rules and procedures. The MDB manages operational and transactional data, as well as the analytical data used for intelligence and data mining. The integration point for all products is the common asset. Common registration of assets is handled by the CORA API.
Depending on a companys business needs, as well as its organizational and geographical structure, you can use a single MDB or multiple MDBs; both approaches utilize the same schema. In DSM MDBs reside at the Domain Manager and the Enterprise manager levels, though they are not necessarily co-located on the same physical machine as the manager.
MDB Installation
Ingres is supported on Windows and Linux while MS-SQL Server is supported on Windows only.
Ingres Notes
When using an Ingres-based MDB, keep the following in mind: Ingres will be installed by the DSM installer if not already installed
212
September 2007
The MDB
The Ingres installer will itself install the MDB (setupmdb) The DSM installer uses a response file to specify Ingres installation parameters The Ingres installer (setupmdb) will set the MDB_SIZE=medium by default MDB_SIZE is a configuration parameter which affects certain Ingres DBMS settings, such as DMF cache size, in an attempt to attain better performance based on expected load. The MDB_SIZE setting can be changed but the actual physical hardware used must be capable of supporting the increased MDB size. MDB patches are applied during the DSM installation if needed. The following process is used when an Ingres-based MDB is installed on Windows: 1. 2. The Install kit collects installation attributes (for example, which database server is to be used). 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. 4. The Install kit calls the dsmMdbPatch.bat script to apply MDB patches provided by Support. 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. 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. 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.
5.
6.
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.
September 2007
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):
214
September 2007
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
September 2007
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 theres only one transfer in a transfer job. You can use the DtsCli to view and monitor the transfers. For information on command syntax, execute the following:
Dtscli h
Useful commands for monitoring and debugging purposes are:

dtscli t method=status id=TheId dtscli t method=status id=TheId method_parameters=implementation dtscli j method=status id=TheId dtscli j method=status id=TheId method_parameters=implementation dtsCli j method=status id=TheId method_parameters=transfers
DTS Components
DTS consist of the DTS Transfer Agent, DTS Command Line Interface (DTSCLI) and three servers the Network Object Server (NOS), Transfer Object Server (TOS) and Schedule Object Server (SOS) that are distributed across the DSM r11 architecture as follows:
216
September 2007
Here you can see the individual processes and log files and log files used by these components:
Transfer Object Server (TOS)

DTS is implemented around an object model. These are the objects controlled by the Transfer Object Server (TOS).
September 2007
The client tells the TOS to create, manage and activate transfers and jobs. Session messaging is used (previously it was TCP) as is encryption, compression and certificates. DTTransferGroup This class of object defines a group of transfers that are to be controlled together. DTTransfer Fully defines a single data transfer from one computer to another. DTFilter Specifies how data is to be read or written and also any processing that should be performed on the data before or after the transfer. DTS TOS is multi-threaded and uses information in DSM tables.
Network Object Server (NOS)

When a transfer job is activated the TOS contacts the Network Object Server (NOS) for the best route. Communication is managed via SM.
WorldView integration is used to model the network and to: Define routes between machines Set parcel size Designate throttle factor Select protocols other than TCP
218
September 2007
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
September 2007
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 TOSs 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 jobs status at this time is: Calculating
DTS Transfer Agent

The DTS Transfer Agent consists of the following components:
Following are the methods by which the DTS Agent receives a transfer request, connects to the responder and performs the data transfer:
220
September 2007
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 Networkers 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.
September 2007
The following types of intermittent transfers are supported: Transfers to agents that are off-line Transfers 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. USDs 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.
222
September 2007
MDB Tables
Here you can see which MDB tables are used by DTS:
Event Management
The Common Eventing component is used therefore Dtaaudit.log is no longer employed. The Common Eventing component outputs to the following locations: Program files\ca\dsm\logs\Events_n.log Windows Event console CCS Event console
Installation and Configuration

DTS is integrated into DSM configuration policy. The Tngdts.ini that was used to configure DTS in previous releases is no longer used except for legacy purposes. Further, the former DTS Administration client is no longer used.
September 2007
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 Agents 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 MSGHEADER_GET_ENCRYPT=<0> 141206-13:48:25.0818844L|000548|00000b44|DtsAgent0 |dtsPWIEXT_Send_D|PWIEXT.c |000566|DETAIL | 524318 141206-13:48:25.0821777L|000548|00000b44|DtsAgent0 |dtsEQP_Outstandi|eqp.c |000400|DETAIL | Event <503> found in event queue for transfer <I1522leh>, setting work to do flag 141206-13:48:25.2856018L|000548|00000b44|DtsAgent0 |dtsEQP_Process_E|eqp.c |000295|DETAIL | Processing events for transfer <I1522leh> |000885|DETAIL | m_encryptOn=<0>
Note, however, that all DTS trace statements have the function name (column 5) prefixed with Dts.
224
September 2007
The Agent and DM Primer
The Agent and DM Primer

DM_Primer handles payload transfer and payload installation execution. dm_primer[.exe] (renamed from dmprimer.exe in V1) It is installed in the following location: <PF>\CA\Unicenter DSM\dmprimer or /opt/CA/UnicenterDSM/dmprimer It is NOT a caf plug-in (because it installs CAF). Primer install images are in the payload library, in the Private area (or possibly on an FTP server, mainly when deploying to *nix). It can be installed automatically (pushed out by deployment manager) or installed manually (from DVD, login script, etc.). Information on manual install can be found in the Implementation Guide. To establish connection with manager, an encryption public key must be obtained from the manager and placed in the expected location on the target. This proves that the deployment user has authority to install software.
Report Extractor
The Report Extractor is a separate EGC plug-in that is used to: extract data from the MDB into result tables present the results in the GUI print the results export the results in a number of standard formats provide data on demand (for example, for portals and web servers) The Report Extractor plug-in is also used by the DSM Engine to generate result sets on a scheduled basis. The implementation includes a large number of canned reports, covering all functional areas of the suite as well as extensive features for designing new reports and data extracts. The inner workings of the reporter feature generic data extraction and handling based on tables, columns and links, but knowledge about the products data model or implementation is not necessary to use the Report Extractor.
September 2007
Report Extractor
Architectural Overview
The following graphic depicts how the Report Extractor fits into the general architecture:
User
EGC 3.0
Print
Export modules
Application
DSM Reporter GUI

Win: gui_rep.dll
Scheduled Reports
Win: gui_rep_exec.dll Linux: lib_rep.so
Data Access
AM Manager Security
AM Data Classes
Database
MDB
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.
226
September 2007
Report Extractor
Report Templates
Reports are defined by their templates which contain information such as report name and description, a list of which fields are included, and how the data is supposed to be viewed. The Report Template does not contain data it is only a recipe for generating results, which will, in turn, contain the current data. You can either use the report templates that are provided with the Reporter or create your own. Report Templates are organized in a file-system-like folder structure, but this can be customized as well.
September 2007
Report Extractor
Following is a model of report results:
Here you can see the sequence in which reports are generated:
228
September 2007
Report Extractor
System Templates are installed silently, skipping existing templates whereas non-system template issue a prompt for overwrite. All templates in default contents should be System Templates. Never use a text editor to edit a template definition in a text editor! Import is controlled by the timestamp of the library file. The last import time is stored in registry as follows:
[HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\ Unicenter ITRM\Reporter\Library\<domain_id>]
When library file is newer, templates are imported. Already existing templates are not overwritten!
Communications
The Report Extractor communicates with the Manager using the manager address set in the comstore during installation. This value can be overridden through the following:
dsmreporter.exe manager:<manager_address>
Database connection information is obtained through the common manager. After that, direct database access is used. Security implementation uses the AM Manager while Directory integration uses the common manager. 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.
Diagnosing Problems
DSM trace logs are maintained in the following location:
<dsm_install_dir>/logs/TRC_REPORTER_n.LOG
Specify the DETAIL log level for CF and CSTACK to get all information for infrastructure 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
September 2007
Report Extractor
Prior to the r11 release, the Reporter used 3 log levels: Error, Warning and Information. In the r11 model, these have been mapped directly to ERROR, 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 breakpoint to inspect them before they are deleted.
230
September 2007
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 DSMs 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.
September 2007
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 WACs Tomcat instance. The DSM Installer just calls AMSs installer.
Diagnosing Problems
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:
<install dir>\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:
<install dir>\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\WEBINF\classes\com\ca\wac\config\waclog.properties
Change the lines that read:

log4j.logger.com=ERROR
232
September 2007
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.
September 2007
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 apis. The primary purpose of this layer is to wrap the lower level APIs. The purpose of the high level API is to present a standard interface to each of the lower level APIs. 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.
234
September 2007
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.
Things to Note
All users connecting to the web service need to be authenticated. When Unicenter DSM Web Services (Web Services) is installed on a machine running IIS 6 it will enable IIS 5.0 isolation mode within IIS 6 automatically. This is required in order for Web Services to function correctly. However, there is a slight risk that this change may adversely affect existing web applications.
Diagnosing problems
If you experience problems with the web services first verify that you can reach IIS and the gsoap layer. To do this under Windows type
http://<machine>/UDSM_R11_WebService/mod_gsoap.dll
You must use a GET request only for fetching WSDL ! see WebWare gsoap ISAPI module documentation for more details. Then, type:
http://<machine>/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
September 2007

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. 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 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: http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp
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
31
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
Diagnostic Tips
Most plug-ins write to the standard DSM trace file which is: TRC_GUI_<n>.log If you are experiencing problems with the DSM Explorer you will need to disable the plug-ins in order to isolate the problem. To do this, make the following modification:
HKLM\SOFTWARE\ComputerAssociates\EGC3.0N\Plug-ins\<Plug-in> [DWORD] Plug-inEnabled = 0
32
September 2007
Common Plug-in
To enable EGC Tracing edit the following:

HKCU\Software\ComputerAssociates\EGC3.0N\Trace [DWORD] Enabled = 1 [DWORD] Level = 5 [STRING] Location=C:\
When you restart EGC the following files are created: EGC3.0_<date>_<time>_<pid>_info.txt EGC3.0_<date>_<time>_<pid>_log.txt (modules loaded by EGC) (trace information)
To display EGC node information select the node and press Ctrl+Alt+Shift+O
Common Plug-in
The purpose of the common plug-in is to glue the product specific plug-ins together in a common tree and provide common functionality and features. It provides the following: A hierarchical representation of common data Basic management services like grouping of objects Support to forward control to product specific plug-ins Common menu handling
September 2007
Chapter 3: DSM Explorer 3- 3
Common Plug-in
HTML interface for displaying basic information from relevant sources / products. Seamless connectivity and security across managers The following nodes are provided by the common plug-in:
Here you can see an example of the UI dialogs provided by the Common plugin:
34
September 2007
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:
September 2007
CCNF Plug-in
Here is where you can see which configuration policies already exist and also where the user can create new policies. Note: Policies have to be sealed before they can be applied, and have to be unsealed before they can be modified.
Reading Configuration Policies

To locate the default policy requesting a policy but leave the name blank. Giving the default policy a blank name at the manager allows the GUI to localise the display name for the default policy. A GUI policy object is created for each policy that is found. For example:
36
September 2007
CCNF Plug-in
The default policy contains all the managed settings while a user-defined policy, in this case the policy Centralised Security, only contains the sections that have been modified. When a user-defined policy is unsealed the GUI displays all the available settings, so that it matches the default policy, but only the settings that are modified from the default are actually added to the policy. These folders below the individual policy folders are called ParamSections.
Configuration Portal
Under each group and asset, you will find a configuration policy node.
September 2007
DM Deploy Plug-in
When this node is selected an HTML page is displayed on the right hand side.
On the left it shows the policies that have been applied directly to this asset. In this example it is a policy call UK Users. Below that it shows the policies that have been inherited. These policies have been applied to groups that this asset is a member of. Details for the reported configuration that the CCNF agent returns from the agent computer can be viewed in a separate dialog. A list of scheduled configurations is provided on the right hand side along with a list of any configurations which have failed. In this example you can see a configuration that contains two policies. Because each contains different values for the same settings, the CCNF manager cannot determine which value to use resulting in a conflict error. This error message instructs the user as to which parameters are causing the conflict so that the error can be remedied quickly.
DM Deploy Plug-in
The DSM Explorer provides access to the enhanced deployment technology available in DSM r11. The access is presented in the form of a deployment wizard which itself is an EGC plug-in. The Deployment plug-in implements the following two nodes in the DSM Explorers Control Panel:
38
September 2007
DM Deploy Plug-in
When selected, a connection is made to the Deployment Manager, and a list of the available packages is retrieved and displayed for selection. The wizard prompts for target information and allows the administrator to scan targets for suitability and to create deployment jobs. The user can suspend the scan and go back to previous pages, but cannot move onto the next page in the wizard until the scan is complete. The EGC plug-in that contains all the functionality is Gui_dm.dll while Gui_dep_res.en is the resource plug-in that contains all the localised resources, html file, graphics, strings etc.
Diagnosing Problems
Most of the current tracing for this plug-in is focuses on calls to the DmApi, so it is best to search for DmAPI function names such as DmPack, DmLogin, and DmStatus. To diagnose problems use the following DmApi and DmDeploy log files: TRC_CF_DMAPI_n.log (client api) TRC_CF_DMDEPLOY_n.log (manager)
September 2007
Directory Browser Plug-in

The Directory Browser plug-in provides support for browsing directory hierarchies. It includes the following: Directory wizard Directory synchronization configuration Directory browsing This particular plug-in is used by other plug-ins to manage their directory browsing such as: Query designer Security profiles Deployment Reporting
Directory Wizard
The Directory wizard consists of eight HTML pages that are used to specify directory details including: Directory name Server (which it attempts to resolve from directory name) Port default 389 User credentials Base DN (which it attempts to resolve from directory name) Directory schema to use
310
September 2007
It is also used to edit schema and create directory objects. Following is an example of the Add Directory function dialog:
Directory Synchronization
Directory synchronization controls consists of two HTML pages which can be used to modify the directory synchronization Engine jobs.
September 2007
Asset Manager (AM) Plug-in
The user clicks Configure to change settings for job frequency and synchronization orders. These changes are saved in command line parameters for the Engine job.
Directory Browsing
This function provides directory browsing capabilities to other GUI plug-ins.

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:
312
September 2007
Here you can see the type of information provided:
September 2007
314
September 2007
September 2007
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:
316
September 2007
These controls are available through the Start menu as follows:
September 2007
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:
318
September 2007
It also includes the following wizards: Software Deployment Wizard Software Staging Wizard Software Policy creation Wizard Software Publishing Wizard.
September 2007
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 groups details section.
320
September 2007
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
September 2007
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:
322
September 2007
OSIM Plug-in
The computer context menu includes the following RC options: Effective Settings this allows you to see the RC permissions that have been granted for a specific user on a specific machine. Connection Addresses - this allows you to view the addresses that this computer has reported it is listening on. You can add additional addresses also, and these will be added to the Address Books distributed to viewers. Actions including lock, unlock and reboot.
Things to Note
Take Control functionality is maintained in different plug-in: gui_rcView.dll.
OSIM Plug-in
The GUI components for the OSIM plug-in are based on EGC 3.0 and Common Plug-in and include: DSM Explorer nodes Domain and Asset portal Dialogs Property Pages OS Installation Wizard Messages Here you can see how the OSIM plug-in relates to the Common plug-in and Common API.
September 2007
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)
324
September 2007
OSIM Plug-in
The overview Portlet includes controls for: Software: current installed OS image Jobs: planned and scheduled OS installations Configuration: PXE managed
The OSIM plug-in implements the OSIM methods for the following CCSM database objects: Computer, Bootconfiguration, Bootserver BootParameter, Parametervalue Bootdiskimage, BootOSimage The APIs include: CCSM API (mainly) common API (special: make managed computer)
September 2007
Chapter 4: CAF
This chapter provides a detailed discussion of the Common Application Framework (CAF) used by DSM, including information These topics are also discussed in the following documents: Implementation Guide (notably Chapter 1: Understanding Unicenter DSM and Appendix M: CAF Scheduled Jobs 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 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: http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp
September 2007
Chapter 4: CAF
41
What is CAF?
What is CAF?
CAF provides a common, extensible runtime environment for all DSM program code. In its most basic form CAF provides the following general functionality: Perceived single service CAF runs as a single service on a computer and acts as the hub for all of the Agent, Scalability server and Manager processes. CAF does not make distinctions between the types of entities plugged into it. They all support the same basic interface and make use of the same common components. Process control CAF provides the following mechanisms for starting, stopping, pausing and restarting plug-ins: by networked API by command line (which calls API) by periodic start as defined by the scheduling component. By auto-restart. if a plug-in such as an agent fails and is terminated by the operating system, the framework can restart it (as defined by policy).
Messaging An out of process messaging plug-in provides secure transmission of information. This is implemented using CAM. Messages can be routed directly to a process or to a plug-in via the framework's persistent process. In the latter case the framework will detect the intended recipient plug-in and route the message there via the plug-in's interface. Stream communications with port multiplexing Scheduling An in-process scheduling plug-in can be used to start/stop other plug-ins or send messages to plug-ins. Registration An in-process registration plug-in is used to register end systems with a DSM Domain Manager via a Scalability Server, and basic inventory is collected and passed up during the registration process. The CAF framework is dynamically extensible via the concept of plug-ins and the common component library (CCL). CAF can be many things: Periodic agent: running scheduler only. At given times it runs an agent via plug-in load/unload Manager: It runs with a set of manager plug-ins and the messenger loaded, both persistently
42
September 2007
What is CAF?
Remote control agent: It runs with the port multiplexer. When a URC viewer connects to its port, CAF starts up the URC host agent which then accepts the connection Sector server: It runs with the AM Scalability Server plug-in running persistently Much more: It runs with the AM metering agent, RC host, the registration plug-in, messenger and an AM Scalability Server plug-in, all loaded persistently
The major packages and components which are listed below are more fully described in other sections. CAF: The DSM Common Service. To the user, this is the CA Unicenter DSM r11 Common Application Framework service. The service hosts the actual DSM Agents, Scalability Servers and Managers. DSM Plug-in: a DSM plug-in is a component which contains DSM conformant functionality. A plug-in may also delegate the functionality to a worker process whose lifetime it manages. Custom Plug-in: this is intended for any other functionality which is not strictly DSM conformant process.
September 2007
Chapter 4: CAF 4- 3
What is CAF?
DSM worker processes: the set of DSM processes covering Agents, Scalability Servers and Managers. These are managed by instances of the DSM plug-in. Note also that only a subset of Manager worker processes are dependent on the MDB. Common Component Library (CCL): a set of components implementing shared, re-usable functionality, including: messaging, tracing, encryption, compression etc. Common Config (CCNF): a component which accesses a store of configuration information. This is actually part of CCL but is shown separately here because it is critical to CAF. The config component provides a consistent means of getting and setting configuration values. The storage location of the values themselves is hidden from the client of the component. The values may be supplied at install time and may be locally or centrally managed. Manager Proxy: this component is used to provide management capabilities for agents. It handles manager location, registration and commands sent by a manager (described elsewhere). Scheduler: Manages scheduled execution of plug-ins. Port MUX: the port multiplexer. This provides a single listening port for TCP and another for UDP connections. When a connection is made (for example, from the URC viewer), the multiplexer detects which plug-in the connection is intended for and gives it a new socket with which to continue. This allows multiple plug-ins to share the same port and is intended to make life easier for the customer when configuring firewalls. Messenger: the messaging component. This is used for connectionless reliable and secure transfer of information. All messages from managers, GUIs 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:
44
September 2007
OS Services
caf command [options | arguments ...] [output | append filename]
Please refer to the CA Unicenter DSM r11 Implementation Guide for full details of the CAF command line options.
OS Services
In addition to communication (messaging and networking) CAF provides the following OS services: Tracing Security Localization Configuration Compression Encryption Basic Inventory Common Utilities XML Parser Directory Integration Event Logging All common components are built using a straightforward, proprietary component interface and take the form of DLLs that can be dynamically loaded and unloaded as and when required. Backward compatibility is provided for interface versions. CAF checks that the version the client wants is the one that a component offers. Old interface versions can also be offered so that changes to the interface do not break clients compiled with the older versions.
Tracing
The syntax for running a CAF trace is as follows:
cftrace c set f <product> pp <processorpplug-in> > l DETAIL s <tracefilesize
where: <product> = UAM, USD, URC, DTS, CSTACK or CF <processorplug-in> = See table below
September 2007
Chapter 4: CAF 4- 5
OS Services
tracefilesize is size of file in Kb before it flips. For example:

cftrace c set f UAM l DETAIL s 30000
Sets detailed tracing on for all Asset Management-specific components and a log file size of 30Mb, which flips and cycles when full so the total amount of data captured will be approx 60Mb. Valid values for <processorplug-in> are listed in the following table: CAF Plug-in systray ccsmagt ccnfagent pmux smserver cfnotsrvd cfftplugin cfregister sdagent amagent amagent amswmagtu amswmagtw ampmagent rchost Binary CAF Caf CAF cafC cfSysTray ccnfAgent (lib) cfPmuxPlugin Cfsmsmd Dmscript Cfnotsrvd cfFTPlugin (lib) cfRegister cfUsrNtf sd_jexec sd_msiexe amagentsvc amagent amswmagt amswmagt Amsoftscan capmuamagt rcHost Processor Plug-in CAF_CMD CAF_CMD CAF_SERVICE CAF_SERVICE SYSTRAY Ccsmagt CcnfAgentWorker cfPmuxPlugin CFSMSMD DMSInterpreter Cfnotsrvd cfFTPlugin cfRegister cfUsrNtf SDAgent SDMSIExe amagent amagent UAM UAM UAM amperfagent _HOST Log file TRC_CF_CAF_CMD.log TRC_CF_CAF_CMD.log TRC_CF_CAF_SERVICE.log TRC_CF_CAF_SERVICE.log TRC_CF_SYSTRAY.log TRC_CSMAGENT.log TRC_CCNFAGENT.log TRC_CFPMUXPLUGIN.log TRC_CF_CFSMSMD.log TRC_DMSINTERPRETER.log TRC_CF_NOTSRVD.log TRC_CF_FTPLUGIN.log TRC_CF_REGISTER.log TRC_CF_USRNTF TRC_USD_SDAGENT.log TRC_USD_SDMSIEXE.log TRC_AMAGENT.log TRC_AMAGENT.log TRC_UAM.log TRC_UAM.log TRC_UAM.log TRC_AMPERFAGENT.log TRC_URC_HOST.log
46
September 2007
OS Services
CAF Plug-in rchost ttsagent dtsmg dtsbrowser ccsmsvrcserver sdmpcserver sdserver amms amrss rcserver dtssos dtsnos dtstos rcmanager -
Binary rcHost tngdta tngdtmg tngdoba (lib) ammsapi ccsmsvrd cserver sd_sscmd sdmpcworker sd_server amms amrss rcServer tngdtsos tngdtnos tngdttos rcManSrv (lib)sqlexec highlevelapi
Processor Plug-in URC dtsagent dtsagent dtsbrowser BACKUP_AGENT Metering API ccsmsvr cserver SSCMD sdmpcworker SDServer Metering Server RSS _SERVER BACKUP_SERVER dtssos dtsnos dtstos _MANSRV sqlexec DSMHLAPI ccnfclient ccsmact ccsmapi cfjvmplugin DSMWebServices cmContDiscover DMDeploy cmObjectManager cmDirEngJob
Log file TRC_URC.log TRC_DtsAgent.log TRC_DtsAgent.log TRC_DtsBrowser.log TRC_BACKUP_AGENT.log TRC_AMMeterAPI.log TRC_CSMSERVER.log TRC_CSERVER.log TRC_USD_SSCMD.log TRC_USD_PMCWORKER.log TRC_USD_SDSERVER.log TRC_AMMMS.log TRC_AMRSS.log TRC_URC_SERVER.log TRC_BACKUP_SERVER.log TRC_DtsSos.log TRC_DtsNos.log TRC_DtsTos.log TRC_URC_MANSRV.log TRC_DBAPI.log TRC_HLAPI.log TRC_CCNFCLIENT.log TRC_CSMACT.log TRC_CSMAPI.log TRC_CF_JVMPLUGIN.log TRC_CF_WEBSERVICES.log TRC_CF_CMCONTDISC.log TRC_CF_DMDEPLOY.log TRC_CMENGINE.log TRC_CMDIRENGJOB.log
ccsmact ccsmapi tomcat cmcontdiscover dmdeploy cmobjectmanager -
ccnfclient ccsmactd ccsmapid java webservieapi.dll cmContDiscover DMDeploy cmObjectManager cmDirEngJob
September 2007
Chapter 4: CAF 4- 7
OS Services
CAF Plug-in ammanager sdmgr_tm sdmgr_dm sdmgr_api sdmgr_im sdmgr_ft
Binary amObjectManager sd_taskm tm sd_dialog_m sd_apisrv sd_taskm im sd_ahdcmd sd_mgr_ft sd_dtpush sd_dtsft
Processor Plug-in AMManager TaskMan DialogM ApiServer InstMan sd_ahdcmd SDMgrFT SdDtPush DtsFT BACKUP_WORKER BACKUP_MANAGER Migration_CSM Migration_USD
Log file TRC_AMMGR.log TRC_USD_TASKMAN.log TRC_USD_DIALOGM.log TRC_USD_APISERVER.log TRC_USD_INSTMAN.log TRC_USD_SDAHDCMD.log TRC_USD_SDMGRFT.log TRC_USD_SDDTPUSH.log TRC_USD_DTSFT.log TRC_BACKUP_WORKER.log TRC_BACKUP_MANAGER.log TRC_MIGRATION_CSM.log TRC_MIGRATION_USD.log TRC_MIGRATION_URC.log TRC_MIGRATION_UAM.log TRC_AMRAPI.log TRC_DMSEDITOR.log TRC_REPORTER.log TRC_GUI.log TRC_CF_DMAPI.log TRC_BACKUP_MGUI.log TRC_URC_EXPLORER.log TRC_URC_VIEWER.log TRC_URC_REPLAYER.log TRC_URC_HOSTGUI.log TRC_URC_WRAPPER.log TRC_URC_UTILCMD.log
rcManagerR11Migra Migration_URC tion Migration_UAM (lib)amRsapi dmsedit dsmreporter dsmgui (lib) dmapi RSAPI DMSEditor REPORTER GUI DMAPI BACKUP_MGUI (lib) gui_rc (lib) gui_rcView (lib) gui_rcReplay (lib) rcHostGUI (lib) gui_rcWrap rcUtilCmd(lib) _EXPLORER _VIEWER _REPLAYER _HOSTGUI _WRAPPER _UTILCMD
48
September 2007
Security
Security
There are three primary aspects to common security: Authentication Authentication provides confidence that the requesting object is who they say they are. It is employed for login and machine to machine communications (application to application). Authorization (Permissions) Components use the verified identities to lookup rights and privileges to apply to the requested operation. This occurs in the MDB via an API. Data Encryption This can occur on the disk or over the network. Some common terms you should be familiar with for this topic include: URI - Uniform Resource Identifier. Similar to a URL. The format of a URI is:
Format <scheme>://<authority>/<object>
Where <scheme> is the namespace (a.k.a Provider). For example: winnt: Primarily Windows NT domain and local SAMs. unixl: Unix local account (shadow password file) ldap: LDAP directory access nds: NDS directory access x509cert: X.509 V3 certificates
and <authority> identifies a security database of some form local SAM, domain SAM, NDS directory, Unix password file. Security Scheme. Each security component may be able to use one or more protocols to provide authentication. For example: winnt:(ntlm) NTLM authentication using SSPI winnt:(krb5) Kerberos authentication using SSPI winnt:(plain) LogonUser authentication using RSA crypto unixl:(plain) shadow file access using RSA crypto x509cert:(dsm) certificates using DSM RSA crypto local: special represent O/S local interface
Security Schemes are usually hidden only used explicitly by SM and RC.
September 2007
Chapter 4: CAF 4- 9
Security
CCL Security provides Authentication Authorization assistance & access tests Authority browsing Authority management Identity reporting
Authentication
Authentication is the process of a security principal proving they are who they say they are through: Something I know for example, a password Something I have such as a smart card / certificate Something I am - in other words, biometrics The CCL Security Authentication component provides authentication services to local and remote services. It links closely with the Session Messaging services to provide authentication services for messaging clients. It also provides mechanisms for being inserted into other transports, such as a networking stream, to allow for the same authentication methods to be used by all services. Authentication is used by Networker, RC, Configuration, COAPI, AM, SD, Session Messaging - nearly everywhere! CCL security does NOT provide authorization - in DSM this is provided by the OLS component. CCL Security does provide: Membership evaluation Upper security layers also require group membership tests for authorization Access restriction The NDS provider has to manually test for logon-hours, etc., as the API does not enforce these.
Authority Browsing
An authority is a security database of some form for example, a local SAM, domain SAM, NDS directory, Unix password file. It provides a generic interface for browsing for:
410
September 2007
Security
Users Groups Computers Management Some authorities are always enabled for authentication, such as O/S native and certificates. Some authorities are specified by manager policy, such as External directories LDAP, NDS. The security components manage the list of available authorities and security schemes including those that are: Implicit: where certificate authority always enabled (DSM r11) Explicit: where external directories always enabled by manager policy Derived: where O/S providers are calculated in priority order: Global domain Local local SAM (Windows but not DCs) 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 URIs which represent the current machine and the logged on user(s) in varying namespaces. These only work where the URIs can be reliably generated: NT Unix NDS (with NW client support)
September 2007
Chapter 4: CAF 4- 11
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
412
September 2007
Security
On Unix: libetpki2.so, libetpki2_thread_posix.so Logging is done to the file of the calling component.
Authorization (Object Level Security)

DSM Object Level Security (OLS) is based on the USD 4 permissions model:
Security Profile This is a role/group/individual user mapped from a security provider (for example, an NT domain group). Class ACE (Class level security) For each profile one Class ACE will be assigned for each type of secured object. From the start only Class ACE exists for all objects. This is the default ACE for an object of a given type. This ACE value is used. Object ACE (Object Access Control Element) Permissions assigned to an object
September 2007
Security
Ownership An object is either owned by a user or is said to be unassigned. When a background process creates an object, that object is usually unassigned. If you create an object, your user ID is the owner of the object. As the owner of an object you inherit all permissions associated with the Owner security profile. Owner is a special security profile, created at install time and set to Full Access by default. Take Ownership A user gets the ownership of an object
Access Control
Authorization concerns itself with the rights and privileges associated with an authenticated entity (typically a logged in user, but could be a machine/process/application). The common authorization sub-system covers class level, group level, object level and functional security. It is based on the concept of an Access Control Entry (ACE), which is a bitoriented integer. The following eight bits are currently used: V C R View bit, allows you to show objects. Create bit, allows you to create objects. Read bit, allows you to read sub-objects of an object.
W Write bit, allows you to change and object. X D P O Execute bit, allows execution, depends on object type. Delete bit, allows you to delete objects. Permission bit, allows you to change the ACE itself. 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.
414
September 2007
Security
Things to Note
It is very important that you understand the relationship between the User and the Security Profile. A user can be a member of more than one Security Profile and, in that case, the user has cumulative rights (i.e., permissions are ORd 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
September 2007
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 Everyone Owner Purpose This profile initially has class permissions. NO_ACCESS for all classes 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
416
September 2007
Security
The following table identifies the relationship between the GUI level object, their corresponding DB tables, Security Class ID and Level used in the Common Table.
GUI Level Computers Users Computer Users Managers Servers Groups of all above Group of assets Group of servers Group of domains Queries
DB Tables ca_discovered_hardware ca_discovered_user Ca_link_dis_hw_user ca_manager ca_server ca_group_def ca_group_def Ca_group_def ca_group_def ca_query_def
Security Class ID SEC_CLSID_COM_COMPUTER SEC_CLSID_COM_USER SEC_CLSID_COM_COMPUTER_USER SEC_CLSID_COM_MANAGER SEC_CLSID_COM_SERVER SEC_CLSID_COM_GROUP [1] SEC_CLSID_COM_ASSET_GROUP SEC_CLSID_COM_SERVER_GROUP SEC_CLSID_COM_DOMAIN_GROUP SEC_CLSID_COM_QUERY
Security Level Class, Object Class, Object Class, Object Class, Object Class, Object Class, Group, Object Class, object Class, object Class, object Class, object
The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used in the Security Table. GUI Level Class Permission Security Profiles MDB Access DB Tables ca_class_def ca_security_profile -Security Class ID SEC_CLSID_SEC_CLASS_SECURITY_ OBJECT Security Level Class, Object
SEC_CLSID_SEC_SECURITY_PROFILE Class, Object SEC_CLSID_MDB_ACCESS Class
September 2007
Security
The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used in the Software Delivery Table. GUI Level SW Packages SW Procedures SW Groups Procedure groups Job containers Jobs Distribution containers TM Tasks Container DB Tables usd_rsw usd_actproc Usd_swfold & type=1 Usd_swfold & type=2 Usd_job_cont Usd_activity Usd_contfold Usd_task Usd_cont Security Class ID SEC_CLSID_USD_SOFTWARE SEC_CLSID_USD_PROCEDURE SEC_CLSID_USD_SW_GROUP SEC_CLSID_USD_PROC_GROUP SEC_CLSID_USD_JOB_CONTAINER SEC_CLSID_USD_JOB SEC_CLSID_USD_DIST_CONTAINER SEC_CLSID_USD_TASK SEC_CLSID_USD_CONTAINER Security Level Class, Object Class, Object Class, Object Class, Object Class, Object Class, Group, Object Class, object Class Class, object
The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used in the Asset Management Table. GUI Level Jobs Modules DB Tables Ncjobcfg + column job_category Ncmodcfg + column motype Security Class ID SEC_CLSID_ASSET_JOBS SEC_CLSID_ENGINE_JOBS SEC_CLSID_MODUL_INVENTORY SEC_CLSID_MODUL_TEMPLATE SEC_CLSID_MODUL_SOFTWARE SEC_CLSID_MODUL_METERING SEC_CLSID_POLICY_QUERYBASED SEC_CLSID_POLICY_EVENTBASED SEC_CLSID_AMO_SW SEC_CLSID_AMO_ENGINE Security Level Class Class Class Class Class Class Class Class Class, Object Class, object
Policies Software Engines
Polidef Ca_software_def Ca_Engine
418
September 2007
Security
The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used by the DSM Explorer Table. GUI Level DB Tables Security Class ID SEC_CLSID_COM_TASKWIZ (this is no longer used) SEC_CLSID_COM_CONTROL_PANEL Security Level Class Class
GUI task wizard [*] -Enable Control Panel Enable Remote Control ---
SEC_CLSID_COM_REMOTE_CONTROL Class
The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used by Other MDB Tables. GUI Level DB Tables Security Class ID SEC_CLSID_DIR_EXT_DIRECTORY SEC_CLSID_REPORT_TEMPLATE SEC_CLSID_SCHEDULE_TEMPLATE SEC_CLSID_CCNF_POLICY_COMP Security Level Class, Object Class Class
External directories Ca_directory_details Report Template Rptree & type = 3
Schedule Template Rptree & type = 40 Configuration Policies computer Configuration Policies user OSIM object Boot/OS images Csm_object and csm_class is ConfPolicyComp Csm_object and csm_class is ConfPolicyComp Csm_object and csm_class is OSimage OR csm_object and csm_class is BootImage
SEC_CLSID_CCNF_POLICY_USER
SEC_CLSID_OSIM_IMAGE
Troubleshooting
There may occasionally be problems with a long running query such as a query created by the DBAPI. If object are not visible in the Explorer but full control is provided: Check permissions in the MDB Check stored procedures
September 2007
Communication
Communication
In an attempt to reduce port usage, complexity, volume of code and to improve reliability and supportability DSM r11 introduces two types of common communications:connection-oriented, multiplexed, stream-based networking. Provided by two components; the Networker and The Port Multiplexer connectionless, message-based messaging. Provided by two components; The Messenger and Session Messaging The diagram below illustrates the conceptual position of these components within the DSM R11 stack.
Streams
Stream-based communications is provided by the common networking component which provides an interface to support (primarily) stream- based communications but also includes support for low volume datagram-based networking. In other words, for datagrams, it provides the ability to unicast, broadcast or multicast trigger packets and handle responses to these packets. There are two distinct parts to the networking component: the Networker and the Port Multiplexer.
420
September 2007
Communication
Networker
The Networker is a generic, protocol-independent interface to stream based networking. This is a loadable component, which makes use of other loadable components to provide support for specific protocols, such as TCP/IP. The Networker supports Synchronous or Asynchronous (API). The Asynchronous (non-blocking) API uses the CCL Notification object and separate threads for sending, receiving and listening. The Synchronous (blocking) API uses CCFNetwork::Select to process incoming connections in the case of a listening networker and to determine if there is data to process on the receive queue. Synchronous/Asynchronous mode is determined by passing a notification object to the CCFNetwork::Init routine. As most datagram-style communications are intended to use the messenger component, the Networker restricts the messaging styles it supports. Datagram messaging is needed especially when interfacing with external resources. The Networker makes use of a lower level interface to protocol specific components. These components are given logical names (which may map on to well known protocols such a TCP or may be something less obvious). The logical name is associated with a configuration set which conditions the behavior of the component. Some of the configuration information is used by the generic layer and some by the specific layer (and some may be shared and exposed externally). One important detail included in the configuration set is the name of the dll/shared library which implements protocol support. The configuration set may also include information used by the protocol support itself, such as the entity it should act as when listening for incoming connections. This model gives great flexibility is allowing a single DLL to act for multiple protocols, where the protocols are well known or convenient tailoring of a particular implementation.
Port Multiplexer
The Port Multiplexer is a plug-in that listens for stream connections and forwards them to the process that requires them. It handles connection establishment and enables multiple applications to listen on a single port. The default listen port is 4728. Applications use virtual ports and incoming connections handed off to waiting applications.
September 2007
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 havent been converted to use the multiplexer to converse with those which have, without requiring the converted application to handle multiple concurrent connection styles. Existing logic can be preserved. Often, changing to use the Networker will involve changing the style of interacting with the communications. Application logic is often based on the behavior of the interfaces used. The Pmux API routines send a small message to the plug-in which is listening on port 4728. Message types include: Listen Legacy Listen Connect Query
PMUX and Networker Working Together

The Port Multiplexer and Networker are complementary solutions. The Networker will make use of the port multiplexer in order to make or allow connections. For example, instead of listening for a connection, a Networker will ask the Port Multiplexer to listen on its behalf and the Port Multiplexer will hand over connection to it. Similarly, when making a connection to another machine, the Networker will connect to a remote port multiplexer nominating the (virtual) port it wishes to connect to. That Port Multiplexer will accept its connection and hand it over to the real listener. Thus, all DSM components on a machine can share a single port for all connections.
The Messenger
DSM r11 messaging is delivered via the Messenger common component. The Messenger provides an abstraction layer, implemented on top of CAM, which separates its users from the messaging system actually in use.
422
September 2007
Communication
Each component allocates its own CAM queue along with a worker thread to poll messages from this queue. The Messenger component will then deliver messages asynchronously to the component subscriber. The Messenger is message format-agnostic and includes the capabilities to build additional layers on top of it. These layers may be generic (for example, supporting encryption or compression) or specific (for example, building a remote procedure call (RPC) model with its particular message structure on top). Each Messenger object represents a distinct logical connection to the messaging system with its own identity. Message objects provide a convenient method of encapsulating incoming messages. An object/structure is also provided to abstract the addressing of messages. This has two components. The first is the machine the message should be directed to and the second is the identity of the component, relative to that machine. (In CAM terms, this equates to a host name and a queue name). The Messenger API provides an interface to declare an interest in a messenger connection and to give that connection a logical name. It also provides a means of sending messages. Message receipt and failure notifications are notified asynchronously. Such notification will normally take place in a thread different from the one used to send messages.
Session Messaging
Session Messaging (SM) is a client-server layer that sits atop the DSM Messenger component. SM is provided in the form of a C-based interface DLL and a management daemon (CAF plug-in). SM is modular and utilizes many common components. It provides the following Session management Encryption Compression Low-level authentication (X.509) High-level authentication (O/S or External) Transactional calls Message forwarding
September 2007
Communication
Receiving Data
SM supports 3 modes of data receipt Call-back asynchronous call made into application space. Message released on call-back termination. Scan with call-back synchronous call made into application space when application asks. Message release on call-back termination. Scan with output synchronous call that returns pointer to message. Message released by application when finished with.
Message Forwarding
Session Messaging is provided as a tri-interface DLL. This means that it differs slightly from other components in that it provides three interfaces for most text based APIs Wide (Unicode UCS16) Narrow (MBCS Current code page) Native (UTF8 UCS8) Internally, SM tries to work in UTF8 as much as possible to be forward capable with new messaging providers. Following is an overview of the process SM uses to communicate: Client establishes a session with Dispatcher. Session bound between Client and Dispatcher. Dispatcher forwards request to a server endpoint on the local machine. Session now bound between Client and Server n. Session holds authentication and encryption Server responds to the request. Session still bound between Client and Server n. When finished, Server unbinds. Client now re-binds to Dispatcher.
424
September 2007

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 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 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
51
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) 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: http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp
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.
52
September 2007
Important note: All Operation Systems are not created equal. The deployment manager has different capabilities on different platforms. Two major restrictions on the Linux manager are that: it cannot push out a primer to Windows shares since it cannot run the installation command it cannot enumerate Windows domains You will get an error if you try to do the latter. The Windows manager however is fully capable of SSH and telnet/FTP deployment to UNIX variant targets. Important note: Deployment using FTP can seem back to front until you think about it. This method of deployment works as follows: First DMDeploy Manager connects to target using telnet Then DMDeploy Manager issues FTP commands over telnet on the target, pulling the primer installation image from manager to target in other words, initiating the FTP get request on the target. This is different for deployment via shares and ssh, which are pushes from the manager to target. This method only requires that a single FTP server be set up on the Manager, rather than having to have one on each target.
September 2007
Chapter 5: Installation Topics 5- 3
Processes and Log files

The diagram below gives an overview of the processes and data flow involved.
Initially the DMDeploy EGC plug-in will make a request via DMAPI to install the package on a remote target(s). The following process flow is then used by the infrastructure deployment to deploy the software: 1. Select payload to deploy & specify targets Using Wizard or dmsweep Can use IP addresses, directory, Windows domain All target source mechanisms result in a list of addresses to deploy to. 2. Scan for targets/payload is machine in DNS? try to open socket (7) cam ping determines presence of primer 3. Transfer Manager Public Key to target Using Windows (ADMIN$) Share, SSH or Telnet/FTP (or manually). From <manager root>\dmdeploy\bin\dmkeydat.pmr
54
September 2007
4.
DMDeploy manager will transfer DMPrimer Installer image to target (if not already installed) and, if necessary, (e.g., Windows 9x systems), DMBoot. This can be done through SMB shares, telnet/ftp or SSH depending on the type of target platform and the security that has been enabled on them. Note: Image placed in <ADMIN$>\dmsetup.exe, or /tmp/dmprimer/* on *nix
5.
DMPrimer installer installs itself and CAM on the target machine using either Windows RPC, SSH or Telnet (or manually). Note that DMPrimer must run with elevated privileges. Note: Some operating systems, such as Windows 9x, do not have a method for remote invocation. In these cases, it is necessary to configure the OS to install the primer on a significant operating system event, such as a reboot.
6.
When install completes, DMPrimer notifies manager (via CAM) of successful installation so that package deployment can now be initiated. Note: A DMDeploy manager that has either installed a DMPrimer or has authenticated with it can deploy packages without needing to re-supply usernames or passwords. This is achieved through authentication using public and private keys. Any errors up to this point usually result in No Primer Transport
7.
Manager sends payload data to Primer (using CAM messages). Data appears as a primer.packN file in the Primer installation folder (N is a small number).
8. 9.
Primer unpacks the payload data, then sends a package received message to manager 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.
September 2007
Deployment from a Scalability Server simply takes the payload data from the staging area rather than the manager library area. Note: In r11.1 the primer installation image is transferred from the Manager while, in r11.2, it can be staged at the Scalability Server. Even when a Scalability Server is used to stage and deploy software packages, control of the process is still handled by the manager.
Diagnosis Tips
Consult the following log files if you experience problems with Infrastructure Deployment: Manager Logs use standard DSM log mechanism and the following naming convention:
TRC_CF_DMDEPLOY_*.LOG
Major deployment stages are logged at INFO level and log analyser rules are available. The Manager Logs include information regarding the connection to Windows target shares, job status and other deployment stages. Primer Logs note the exact installation command that is run along with the exit code it produces upon completion. These logs are produced in the temporary directory (%TEMP% or /tmp). Payload Installation Logs can typically be found in the following locations: On Windows: %TEMP% On UNIX\Linux: /opt/CA/installer/log
You should also check the following logs for more information: CAM logs, if you have communication issues UNIX/Linux syslog on target computers can be useful to diagnose SSH/Telnet security issues Dont 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 doesnt 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
56
September 2007
Upgrade of Primers
Primers are not automatically upgraded; therefore you will need to use the force primer push policy setting to achieve this. Deployment of DMPrimer uses native OS data transport mechanisms or is done manually, but, all subsequent network activity is performed via CAM (such as pushing payloads and returning payload installation status). This reliance on CAM isolates the main portion of the deployment process from networking issues and configuration. Note: This process requires re-authentication (to push new encryption keys). DSM session messaging (hence CAM) is used for all DSM Explorer Wizard to Manager communications.
Frequently asked Questions

Following are some frequently asked questions regarding Infrastructure Deployment: What does No Primer Transport Job status mean? Cant push primer to target (or it failed to install) What does Failed to Telnet trace message mean? This error is usually associated with the No Primer Transport status and is preceded by failed to map share and failed to SSH errors! Where have my deployment jobs gone? Jobs are not retained when the deployment manager is recycled. What can I do to test CAM Connectivity issues? Ensure that you can execute camping both ways between manager & targets. Also, check DNS, and firewalls configurations. Where are the agent configuration options documented? In the Implementation Guide (<DVD>\doc\r11impl.pdf). See sections Modifying Installation Property Values (for Linux) and Installation Tool msiexec (for Windows). How do we add new package versions/packages for new platforms? Use the dsmPush.dms script (included on the distribution image) to do this.
September 2007
Additional Considerations for r11.2

The following are additional considerations when using the r11.2 release: Hidden CLI passwords Primer Arguments can be used to change primer installation location. A target credentials file assists with offline specification of bulk targets Less bandwidth is used between Manager and targets when a Scalability Server is used since the primer image is now transferred from Scalability Server You can now suspend a scan and proceed with deployment using current scan results - no need to wait for a scan to complete!
CCNF Parameters
A number of common configuration policy parameters can be modified and affect infrastructure deployment behavior as described below: AlwaysDeploy Will force payload push/install even if a newer version of the payload is detected on the target computer. AlwaysDeployPrimer Will always push the primer image and reinstall. Useful if primer install image got corrupted in some way. PingCheckSkip Eliminates the quick ping of a target during scanning. This setting is necessary when TCP port 7 is protected by a firewall.
Detection of Deployed Packages

Detection of deployed packages differs based on the operating system involved. On Windows this is done through MSI product codes. The DSM payloads (packages) include MSI product codes within dmdeploy.dat. The primer uses this code and interrogates the MSI database to check whether a product has already been deployed. Note: A payload may consist of multiple MSI products (e.g. all agents package). On Linux/UNIX, registration is recorded in the following file:
$CA_ITRM_BASEDIR/dmprimer/bin/dmdeploy.reg
58
September 2007
The installer registers/deregisters a product by calling dmprimer with special args. The Infrastructure Deployment Manager asks is product x version y installed? not what products have you got?
Increasing Primer Log Level

To increase the primer log level do the following: 1. Change to the directory containing the dm_primer. On Windows this is:
Program Files\CA\Unicenter DSM\DMPrimer
2. 3. 4. 5.
Issue a 'dm_primer stop' command Remove the old dmprimer.log Edit the dmprimer.cfg file found in the above directory and change the TRACE_LEVEL value from 3 to 5. Deploy the software
Note: There is no need to restart the primer as cam will do this automatically Note: SE Testfix T18C872 allows log level updates without restarting primer.
Deploying to Linux over SSH

Deployment to Linux targets using DMDeploy over SSH (the default method for Linux) is quite complex and subject to a variety of environmental obstacles. Many things have to occur successfully before the deployment payload becomes active on a target system. Unfortunately, since no CA software is assumed to be present during deployment it is impossible to report accurate status and diagnostic messages during this operation. Therefore an understanding of the process is important. Following is the sequence of events that occur when deploying to Linux using SSH, to a clean system. When diagnosing problems in this area identifying the point of failure within the sequence is crucial. 1. The dmdeploy manager connects to target system using ssh You should see the connection attempt logged into the system log file /var/log/secure. 2. If the connection is successful, the primer installation package is pushed to the target system using ssh/sftp You should see OS processes with names containing these strings appear on the target system 3. Primer image is uploaded to /tmp/dmprimer
September 2007
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. 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. 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.
7.
8.
Thats 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. 2. DMDeploy manager attempts to open a share (by default admin$) on the target system. 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
510
September 2007
dmkeydat.pmr dmsetup.exe msvcr71.dll 3. 4. Primer image is uploaded to admin$, or whatever share the user has configured the manager to use for deployment. 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. After the primer install is finished, you should see the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\DMPrimer
5.
The keys data will show where the primer files have been installed. The usual location is:
C:\Program Files\CA\Unicenter DSM\DMPrimer
6.
The primer should now have started and dm_primer.exe should appear in the task manager. The primer log file, C:\Documents and Settings\<user name>\Local Settings\Temp\dmprimer.log, should also appear at this point.
7.
The transfer of the deployment payload (for example, UAM agent) starts and you should see the transferring xx% messages appear in the GUI or the CLI. This is quite quick in comparison to the primer upload in step 2. 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.
8.
Thats it the package installation status is sent back to the manager and displayed in the GUI/CLI.
September 2007
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.
512
September 2007
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. 2. 3. The installation of management infrastructure (see the earlier discussion of Infrastructure Deployment) The migration of data The installation of new agent software
Data Migration
The Data Migration step is driven by Engine Tasks, with one Task type per product (UAM, USD, OSIM, URC). There may be multiple legacy managers and multiple tasks for each legacy manager which could add up to a lot of tasks! Migration is a continuous process and all migrated computers are visible in system group All Legacy Computers. The process ends when r11 Agents are registered with the MDB at which point you should STOP managing those assets through legacy managers. The Engine reads migration job from database using the following method based on which product is being migrated: For Software Delivery, Remote Control and OSIM: An XML file is created containing Job contents. The product specific migration DLL is loaded and executed with this XML file as a parameter. For Asset Management: A call internal Engine code is made to migrate AM data
September 2007
Software Delivery Specific Information

There is a slight difference between what can be migrated at the Enterprise and Domain levels in terms of: Software Packages Software Groups Software Policies Computer and User Groups Computers and Users (Domain only) Computer Job History (Domain only) Security To use USD 4.0 SP1 SDGAPI to get to v4.0 data do the following: On Windows install the legacy API from DSM Installpath\SD\Legacy\usd40sp1\sdapi.w32 IF and only IF USD 4.0 SP1 and DSM r11 are not co-hosted. On Linux the legacy API is installed with the DSM r11 manager and no additional actions need to be taken Migration of Software Packages: Exports packages and added procedures and imports them to r11 Is only done once Limited Group Membership update on each run unlinking not detected on legacy manager Migration of Software Groups: Is only done once Limited Group Membership update on each run unlinking not detected on legacy manager Migration of Software Policies (aka Software Templates): Is only done once Never sealed automatically Sealed Software Policies are migrated on Domain only Migration of Computer and User Groups: Is only done once Limited Group Membership update on each run unlinking on legacy manager not detected
514
September 2007
Limited query migration. Many queries cannot be migrated properly but they will appear in r11 as disabled and can be redefined using the DSM Explorer post migration Migration of Computers and Users (Domain only): Is only done once Limited Group Membership update on each run unlinking on legacy manager not detected Scoped able to specify migration scope by naming Computer and User group on legacy manager. Only members of that group will get migrated Watch out for duplicate HOST UUIDs! HOST UUID used as primary identifier of computers in r11. Duplicates WILL mess things up! Migration of Computer Job History (Domain only): Migrated every time Records replaced on consecutive runs Records merged on last run Migration of SD Security: Only migrated once Security Profiles migrated regardless of security provider conflicts (winnt/unix). Can be remapped to other OS security groups post migration using DSM r11 Explorer. Object ownership only migrated if security providers match (winnt/winnt, unix/unix, not winnt/unix) The migration of computer and user data occurs in the following phases: Computer or User created by migration task and set in state locked by migration on DSM r11 manager to prevent DSM r11 manager from setting up jobs for it When r11 Agent registers with DSM r11 manager the agent version is updated. Computer or User remains in state locked by migration on DSM r11 manager Next time migration task is run the installation history from the legacy manager is merged with the existing history in r11 DSM Manager and Computer or User state is unlocked from migration Management of Agent using r11 manager can begin. At this point you should STOP managing the agent using legacy manager as no further migration of job history will be performed! Detail on how ASM.CNF is migrated into r11 comstore is documented in Implementation Guide. This includes the migration of user data including: User, Room, Phone and Comment and customized agent name.
September 2007
Migration is invoked by agent installer if selected by user. Migrated configuration settings are protected by CCNF from override by DSM r11 default policy. Only custom policy will override the migrated settings. On Managers, the library is copied by a migration task - it is NOT automated on Scalability Servers. You will need to run sd_sscmd import to copy or move packages from legacy staging servers. MSILIB is not automatically migrated on Domain Managers and Scalability Servers. You will need to run sd_sscmd importmsi to copy or move packages from a legacy local or staging server MSILIB. In r11 software packages are identified by DSM UUID NOT by their MSI Product Code. This appears in MSILIB in folder named with this DSM UUID DSM UUID maintained during export and Enterprise to Domain distribution Important to use the same DSM UUID throughout Enterprise and all Domains to improve roaming source list updates The new MSILIB share name is SDMSILIB and a new MSI dictionary file is provided to improve roaming source list update. In addition, new MSI procedure macros replace old macros used to find admin installs in new locations. The old macros are updated during package import. For more details, consult the Implementation Guide.
USD Data Migration Implementation

The process of migrating USD specific data is as follows: 1. 2. 3. 4. 5. 6. Engine loads the usdLegacy DLL/SLIB usdLegacy DLL/SLIB calls the sdmgrmig executable using instructions it received from the Engine Sdmgrmig loads usd40sp1 DLL/SLIB to connect to legacy manager Sdmgrmig loads ps DLL/SLIB to connect to r11 database Sdmgrmig loads coApi DLL/SLIB to connect to r11 common manager Migration is done for each selected object class All tracing goes to TRC_MIGRATION_USD. 7. 8. As with previous installations, all SD events are also logged to the NT(/CCS) event console. 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.
516
September 2007
9.
Sdmgrmig can be executed from a command line as well. For information on parameters supported by this command execute it without providing parameters.
The installer sdcnfmig executable is used for information regarding migration of the ASM.CNF file. This executable loads rdcnf DLL/SLIB to read local ASM.CNF and write to the r11 comstore. It can be executed on command line as well. To view the list of supported parameters execute the command without providing any parameters.
OSIM Specific Information

The following OSIM data is migrated: OSIM OS images and OSIM Boot images. Default parameters are kept synchronized. OSIM Configuration. Current states of OSIM computers are migrated OSIM Computer Groups The prerequisites include: Target computers must be migrated first (run the SD migration job) OS Images must be migrated manually (see the DSM Implementation Guide for a description) Collect all information to access the SD 4.0 database (including database type, host, database name, credentials) OSIM Migration imports data related to Operating System installation from a SD 4.0 Local Server into r11. This includes parameter values and SD 4.0 OSIM groups. There are two kinds of parameter sets: default parameter values of OS images. The parameters of each SD 4.0 OS Image are mirrored to the r11 OS image with the same name. current parameter values of target computers (taken from the last successful installation). The current parameters of each SD 4.0 OSIM computer are mirrored to the r11 computer with the same name. Log file: TRC_Migration_CSM.log An r11 group is created for each SD 4.0 OSIM group and an -r4 suffix is added to the name of the new r11 groups. Memberships are updated on the next run.
September 2007
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. 2. DSM connects to the Legacy Database Important data is verified and loaded into cache
518
September 2007
3. 4.
Each individual configured item is migrated 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 computers General Inventory and filescan based Software Inventory is migrated (Software Definitions for these, however, have to be migrated). To verify migration status, check the TRC_MIGRATION_UAM_0.LOG which is found in the \CA\Unicenter DSM\logs directory. This file provides runtime logging.
Remote Control Specific Information

The following data is migrated for the Remote Control component: Computer Groups Global/Local Address Book Information Computers. State will be listed as migrated. Use migration scope to identify which computers to include. Configuration Policy Data All necessary data for each object type is copied from the Remote Control r6 database to memory and each object is inserted repeatedly. Some object types are updated if already present depending on responsibility. Inserting duplicates does not interfere with migration. Computer -> ca_discovered_hardware(machine), ca_agent( RC status Migrated), ca_group_member(group membership) ComputerGroup -> ca_group_def(r11 group), ca_agent, ca_group_member(group membership) Address book data -> ca_group_def(r11 group), ca_agent, ca_group_member(group membership), urc_ab_group_member(indicating address book), urc_ab_computer(with connection addresses), urc_ab_permission(permissions for address book groups) You can delete objects in the DSM Explorer and migrate again to recreate them.
September 2007
DSM and NAT
Note that configuration policies are not deleted instantly although you cannot see them in the GUI any longer. Remote Control r6 address book groups are transformed into standard r11 groups plus some extra address book properties. R6configuration policies are added to the r11 configuration via CCNF client calls. The sequence of calls is generated from the r6 data in memory. To view migration status, check the TRC_MIGRATION_URC_0.LOG file. You can also check the Engine Status.
Remote Control Data Migration

Data migration for URC is managed through the rcLegacy.dll and the rcManagerR11Migration.exe. The Engine calls rcLegacy with the data provided by the Migration Wizard and rcLegacy builds a command from the data and executes it. This command can also be run standalone. For information on the syntax, execute the following:
rcManagerR11Migration.exe -?
DSM and NAT

DSM r11 can function within a network using Network Address Translation (NAT) or Port Address Translation (PAT) network but there are some additional considerations, limitations and configuration requirements that need to be understood. This section describes some basic testing that was carried out on a DSM r11 deployment within a NATd network environment. Note: No firewalls were in place during testing.
Overview
There are different types of NAT: Static NAT - Maps an unregistered IP address to a registered IP address on a one-to-one basis. Dynamic NAT - Maps an unregistered IP address to a registered IP address from a pool of registered IP addresses. Overloading Similar to dynamic NAT, it maps multiple unregistered IP addresses to a single registered IP address by using different ports. This is also called PAT (Port Address Translation).
520
September 2007
DSM and NAT
Typically, NAT routers are used to provide a degree of security and to enable re-use of IP addresses. In the former case, end systems are hidden behind a NAT router using either Static or Dynamic NAT. In this way the end systems 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 messages 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 doesnt 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.
September 2007
DSM and NAT
2 DSM Agents were connected to the DHCP based, NATd (PATd) LAN.
In this scenario the Scalability Server is essentially in the DMZ, so that both the WAN and NATd 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.
522
September 2007
DSM and NAT
In this scenario the Scalability Server successfully registered with the Domain Manager and agents successfully connected to the Scalability Server for registration and inventory upload. However, this information was not collected by the Engine.
Problem 1: CAM in the DMZ

The DSM Domain Manager Engine was unable to connect to the DMZ Scalability Server and Unable to Open. Messages were written to the Engine event log. From the Managers perspective, the Scalability Server is known by its external address (10.100.1.100) and, therefore, CAM messages are directed to this address. The Scalability Server, however, actually knows itself by its NAT address (192.168.2.100) and so attempts to forward the messages sent from the Manager to an address that is unreachable.
Solution
CAM needs to be configured on the Scalability Server to route messages sent to its WAN address to itself via a simple cam.cfg rule. Add a ROUTING rule to the cam.cfg file that directs messages destined for 10.100.1.100 to localhost. For example:
*ROUTING forward localhost 10.100.1.100
The Engine can now successfully contact the Scalability Server and the new computers and their inventory is collected. With this solution in place the following functionality has been validated as functioning correctly via limited, ad-hoc testing. Agent registration Inventory collection Common configuration Asset Jobs Agent RC Viewer Global Address Book retrieval Agent RC Host Authentication Agent RC Viewer to Agent RC Host Agent RC Viewer to Scalability Server RC Host Manager RC Viewer to Scalability Server RC Host Scalability Server RC Viewer to Agent RC Host
September 2007
DSM and NAT
Note how the latter two entries mean that an RC Viewer running at the Manager can control an Agent by hopping through a Scalability Server.
Problem 2: Infrastructure Deployment

Infrastructure Deployment fails to discover the end systems during the scan phase and, even if it could, file share and telnet access is not possible because the end systems are hidden from the Manager.
Solution
Failure to discover and connect directly to end systems is, as it should be, and, as such, there is no real solution for the discovery and primer transfer. However, it is possible to instruct the Deployment Manager to skip the IP ping that it uses to detect end systems. If the ping is skipped the Deployment Manager attempts to connect to the dm_primer directly. If the dm_primer is already installed on the end systems with the appropriate Manager key file (perhaps via logon script execution of the dm_setup package) and CAM traffic intended for the NAT network is routed through the Scalability Server then deployment is possible and successful. Note: This problem also occurred in previous product releases. The Managers instance of CAM is configured to route all messages to the Agent addresses via the Scalability Server as follows
*ROUTING forward 10.100.1.100 192.168.1.*
This enables CAM communications from Manager to end system via Scalability Server.
Problem 3: AM/SD Job Checks

An AM/SD job check request from DSM Explorer to Agent does not work.
Solution
A combination of CAM routing rules at the Manager and host file entries solves this problem. First, hosts file entries for the end systems are added as follows:
agent1 192.168.1.129 agent2 192.168.1.130
524
September 2007
DSM and NAT
This enables the names of the end systems to be resolved to IP addresses. Next, the Managers instance of CAM is configured to route all messages to these addresses via the Scalability Server as follows
*ROUTING forward 10.100.1.100 192.168.1.*
This enables CAM communications from Manager to end system via the Scalability Server. However, this is not ideal since, in a domain with multiple NATd networks, each private NAT addressing scheme would have to be different (in other words, the end systems 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 NATd networks, agent addresses might change and become out of sync with the hosts file.
Recommendation
In this case, our recommendation is simply to not run manual, ad hoc job checks. There should be very little need to do so in a properly configured, managed enterprise.
Scenario 2: Agent as CAM Proxy

In this scenario all CAM communications are routed through the CAM proxy using appropriate CAM ROUTING rules on the Agents and Scalability Server.
September 2007
DSM and NAT
Similar to the previous topology, the agent1 machine is placed in the DMZ and, since it is known by a different IP address externally, a CAM ROUTING rule is required to ensure all traffic sent to its external address is processed locally. To do this, add a ROUTING rule to the cam.cfg file that directs messages destined for 10.100.1.100 to localhost. For example:
*ROUTING forward localhost 10.100.1.100
In addition, now that agent1 is acting as a CAM proxy, CAM traffic from the Scalability Server destined for agent2 must be forwarded to agent1. So the following routing rule must be added to the Scalability Server:
*ROUTING
526
September 2007
DSM and NAT
forward 10.100.1.100 192.168.1.*
With this solution in place the following functionality has been validated as functioning correctly via limited, ad-hoc testing. Agent registration Inventory collection Common configuration Asset Jobs SD jobs SD Catalog Agent RC Viewer Global Address Book retrieval Agent RC Host Authentication Agent RC Viewer to Agent RC Host Manager RC Viewer to agent1 RC Host Scalability Server RC Viewer to agent1 RC Host
Problem Infrastructure Deployment

Infrastructure Deployment fails to discover agent2 during the scan phase and, even if it could, file share and telnet access is not possible because the end system is hidden from the Manager.
Solution
Failure to discover and connect directly to end systems is, as it should be, and, as such, there is no real solution for the discovery and primer transfer. However, it is possible to instruct the Deployment Manager to skip the IP ping that it uses to detect end systems. If the ping is skipped the Deployment Manager attempts to connect to the dm_primer directly. If the dm_primer is already installed on the end systems with the appropriate Manager key file (perhaps via logon script execution of the dm_setup package) and CAM traffic intended for the NAT network is routed through agent2 then deployment is possible. Note: This was also the case with previous versions of the products.
September 2007

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 These topics are also discussed in the following documents: Implementation Guide 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 your CMS Solution http://supportconnectw.ca.com/public/impcd/r11/Unicenter/CMS_Frame.h 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: http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp
What Happens at Startup?

What happens when a machine running DSM r11 boots up? To answer this let us first consider a computer that is running a full DSM Domain Manager with all products (UAM, URC, USD) and components installed (including Scalability Server, Agent and Web components).
September 2007
61
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.
62
September 2007
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] [2] [3] [4] [5] [6] [7] [8] [9] Asset Management manager (ammanager) Asset Management performance agent (ampmagent) Asset Management server (amrss) Asset Management usage server (amms) Certificate exchange plug-in (cfcertex) Common Server (cserver) Common object manager (cmobjectmanager) Configuration agent (ccnfagent) Configuration and State Management agent (ccsmagt)
[10] Configuration and State Management agent controller (ccsmact) [11] Configuration and State Management database api server (ccsmapi) [12] Configuration and State Management server (ccsmsvr) [13] DSM Service Locator plug-in (cfsvclocator) [14] Data Transport network object server (dtsnos) [15] Data Transport schedule object server (dtssos) [16] Data Transport transfer agent (dtsagent) [17] Data Transport transfer object server (dtstos) [18] Deployment Manager (dmdeploy) [19] Engine (SystemEngine) [20] Event notification plug-in (cfnotify) [21] File transfer server (cfftplug-in) [22] Notification Server (cfnotsrvd) [23] Port multiplexer (pmux) [24] Registration plug-in (cfregister)
September 2007
Chapter 6: Startup and Configuration 6- 3
[25] Remote Control host agent (rchost) [26] Remote Control manager (rcmanager) [27] Remote Control server (rcserver) [28] Session messaging server (smserver) [29] Software Delivery Boot Server (sdmpcserver) [30] Software Delivery manager: api server (sdmgr_api_2) [31] Software Delivery manager: dialog manager (sdmgr_dm) [32] Software Delivery manager: file transfer (sdmgr_ft) [33] Software Delivery manager: installation manager (sdmgr_im) [34] Software Delivery manager: task manager (sdmgr_tm) [35] Software Delivery server (sdserver) [36] tomcat server (tomcat)
Note that the list of plug-ins is sorted alphabetically not in the order in which they are started.
Startup Under Windows

On the Windows platform the following specific actions occur at startup: 1. Session messaging plug-in starts C:\Program Files\CA\Unicenter DSM\bin\cfsmsmd.exe -t 2. 3. CAFs own session messaging end point U-CAF is set up 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. 2. Tomcat starts up 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
64
September 2007
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
September 2007
27. SD Scalability Server plug-in starts up C:\Program Files\CA\Unicenter DSM\Bin\sd_server.exe 28. Common Object Manager starts up C:\Program Files\CA\Unicenter DSM\Bin\cmObjectManager.exe 29. AM Object Manager starts up C:\Program Files\CA\Unicenter DSM\Bin\amObjectManager.exe 30. Engine starts up C:\Program Files\CA\Unicenter DSM\Bin\cmEngine.exe 31. CAF event notifier (cfnotify) starts up using SM end point = CFNOTIFY 32. Common registration plug-in (cfregister) starts up using SM end point = CAITRMAGENT 33. CAF service locator (cfsvlocator) starts up 34. Scheduler is enabled 35. Register job is executed 36. Begin waiting for CAF messages 37. AM Agent starts up C:\Program Files\CA\Unicenter DSM\Bin\amagentsvc.exe UNIT= 38. SD Agent (sd_jexec.exe UNIT=.AfterReboot) starts up
Startup under Linux

Following is what happens during startup of cmObjectManager under Linux: 1. 2. 3. 4. 5. 6. If Windows, init COM Configuration information is read SM end point (registering callback function) opened OS Event created for shutdown CAF notified that it is ready Wait for shutdown event.
When a shutdown event is received, the cmObjectManager does the following: 1. 2. 3. Stops processing messages Enters an infinite loop waiting for all open threads to finish When all open threads have finished cmObjectManager exits
66
September 2007
Following is what happens during startup of common server: 1. 2. 3. 4. 5. Init common components Parse command line Load config Register with CAF Register Server with Manager
Then, it reaches steady state with the following: 1. 2. 3. 4. Main thread waiting on m_trigger_event Notifier thread waiting on m_notify_event CFRuntime thread waiting on IPC CAF messages 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. 2. 3. 4. Command line args parsed Connect to CAF Configuration read One (1) second delayed loop entered - checking for work every 20 seconds.
Then, it reaches steady state with the following: 1. 2. Main Thread in 1 second timed loop 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
September 2007
Infrastructure Configuration
The Unicenter DSM products are configured centrally and locally through a shared component typically referred to as common config or CCNF. This components acts like an enhanced Windows registry. It manages the runtime configuration of practically all of the DSM subcomponents and infrastructure features, though there are some exceptions.
Configuration Policy
In order to simplify administration of configuration parameters, you can group a collection of those parameters into a single configuration policy. Therefore, instead of assigning single parameters to computers or groups, configuration policies are assigned. Configuration policy can be assigned to multiple computers or groups. From the administrators point of view, configuration policies are created and maintained independently of any specific computer or group. There may be some overlap in the parameters defined in configuration policies one parameter could be defined in more than one configuration policy destined for the same end system. Since only a unique parameter value can be set on a computer, the following rules are used to determine how to proceed when configuration policies overlap: Policies assigned to a group are inherited by the children of the group. A child can be a group or computer. In a hierarchy, policies assigned on the child level override the ones on the parent level. In other words, all parameters defined on the parent level are also defined for the child, however, when a child policy overlaps with a parent policy, the child policy wins. In all other cases where overlapping policies present a conflict the user will be prompted to resolve the conflict.
Activating Computer Configuration

When the time comes for a computer configuration job to be activated the manager collects the parameters that need to be sent down to the computer. The configuration job sent down to the target computer will only contain the parameters that have changed since the last time the configuration was sent down.
68
September 2007
Reported Configuration
The agent reports parameter settings to the manager. On the manager, these settings are stored in the database where they are referred to by the GUI as the reported configuration. A full report of all parameters is returned after the very first configuration job has been applied. Subsequent reports only contain deltas.
Configuration Properties
Configuration properties can be: Centrally managed Configuration properties are set up through the DSM Explorer and stored in the MDB. They are then evaluated and transmitted down to end systems via the CCNF and CSM (Configuration and State Management) sub-systems. Locally managed Here, although the MDB contains entries for the configuration properties the values are set and stored locally. Locally unmanaged This state can be set and reset only locally via the ccnfAgentApi. In other words, locally unmanaged parameters can be set to centrally managed by the local end system. This essentially puts the manageability of these parameters under end-system control. These managed properties are collected together hierarchically under a configuration policy. Configuration policies can be viewed and manipulated within the DSM Explorer under /Control Panel/Configuration/Configuration Policy. Tip: When viewing managed properties within the DSM Explorer by default you will see their display names. To view their real internal names right clicking on the list view column header and select the display internal names option. Unmanaged Configuration properties exist only on the end systems. These properties typically contain values that are specific to and only useful to the processes that execute on the managed computer.
September 2007
Enterprise and Domain Policies

On the Enterprise, the following rules apply to policies: Enterprise policies are replicated to Domains Enterprise group configuration jobs are replicated to Domains Enterprise policies can only be applied to groups On the Domain, the following rules apply to policies: Enterprise default policy replaces Domain default policy Policies can be applied to group OR to individual assets. Reported configuration is only available at the Domain level
Property Storage
Property storage (also known as persistence) is maintained in different locations in the MDB and on the end system itself.
In the MDB
Centrally managed properties and their values, as well as locally managed property definitions (without values), are stored in the following MDB tables csm_property csm_object csm_class csm_link Important Note: These tables are also used for storage of OSIM data since CCNF and OSIM both utilize CSM. The configuration manager processes the configuration policies applied to a specific computer as well as policies applied to any groups that the computer belongs to. It will eventually work out which properties should be set to what value and then pushes these property values down to the end system.
On the End System

The configuration settings for an end system ultimately end up in an encrypted XML file. If you want to know what property values are really being used by DSM on a particular machine, this is the place to look.
610
September 2007
Configuration is stored locally in comstore.enc and userstore.enc on each node. This replaces pre-r11 mechanisms such as ASM.CNF, TNGDTS.INI, and Registry. comstore.enc is stored in <DSM install path>\Agent\CCNF while userstore.enc is stored in <Documents and Settings>\<DSM install path>\Agent\CCNF. Both comstore.enc and userstore.enc are encrypted to avoid direct manipulation. In addition the file can be decrypted and written to a standard XML format file using the following command. ccnfcmda cmd GetConfigStore fi c:\MyComStore.xml Below is some example content. It shows some nested parameter sections e.g. itrm/usd/shared, as well as a parameter nos and its 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:
September 2007
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:
612
September 2007
Then register the new parameter by executing the following command on the Manager machine:
ccnfregdb.exe mlocalhost fC:\addparam.xml
September 2007
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.
614
September 2007
Agent Registration
All CAF plug-ins and worker processes are notified about the configuration changes using the internal CAF notification mechanism. CCNF Agent keeps track of any configuration changes in the common store. The list of parameters to be reported is kept in the following file:
<Unicenter DSM>/Agent/CCNF/paramlist.xml.
This list is initially sent by the manager and will be updated when the DefaultPolicy has been updated. Ccnfcsmplug-in.dll is triggered by CSM Agent on a regular basis to check for delta reports. It requests a delta report from CCNF Agent and forwards the parameters according to the template list via CSM Agent. CSM Agent calls ccnfcsmplug-in.dll if a report request arrives from the manager. Ccnfcsmplug-in.dll requests the full report from the CCNF Agent and forwards the data according to the template list via CSM Agent to the manager.
Agent Registration
When a DSM agent is installed on an end system the first thing it does is attempt to register its existence with the Domain Manager via its Scalability Server. This registration process is common across all products and includes a limited amount of inventory information (known as Basic Inventory or sometimes Basic Hardware Inventory). Note that agents register on a regular basis but basic inventory information is deltad after the first registration.
September 2007
Agent Registration
Engine [cmEngine.exe]
trace
TRC_CMENGINE_0.log am.log
Domain Manager Session Messaging trace Common Server [cserver.exe] TRC_CF_DMDEPLOY_0.log
Scalability Server Agent TRC_CF_CAF_SERVICE_0.log
CAF [caf.exe]
trace
CF Register [cfRegister.dll]
trace
TRC_CF_REGISTER_0.log
Create Process
Basic Inv Collector [cfbasichwwnt.exe]
616
September 2007

This chapter provides a closer look at the Asset Management software scanning process including: General flow Processes and log files Content download process XML generation process Transfers from Engine to Scalability Server and from Scalability Server to agent Enterprise Manager considerations Import\Export utility Diagnosis Tips For additional information you should consult the following sources: DSM HTML Help Web Services Reference Guide Inside Asset Management Guide Unicenter Desktop and Server Management Diagnostics Guide A full list of techdocs is also available from the following link: http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp
Overview and Flow

DSM r11 has fully incorporated the eVM signature scanner technology which supports the download of a signature database from the online CA Content Management System. This information is stored within the MDB, converted to an XML file and transmitted down to the DSM agent for use by the software detection component. The key difference between this technique and the technique employed in the previous Asset Management release is that the signatures are available to the agent, and it is the agent that does the software detection. Previously, a list of file information was returned to the manager and the analysis took place there. Shifting the task to the agents helps reduce the load on the manager system.
September 2007
71
Overview and Flow
The following diagram illustrates the various modules and their interaction:
72
September 2007

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
74
September 2007
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:
September 2007
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.
76
September 2007
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 systems hard drive: On Windows: \Program Files\CA\Unicenter DSM\agent\units\00000001\uam\Wnnnnnnn.XML On UNIX\Linux: /opt/CA/UnicenterDSM/Agent/AM/data/work/lnnnnnnn.xml The software detector is launched via amosoftscan.exe (Windows) or amosoftscan (Linux) and writes to the TRC_UAM_0.log file. The scan applies any signature file differences provided by the agent in order to get a complete and up-to-date signature file. Note: The signature scanner itself does not produce a log file; however, it does create a results file in the following locations: On Windows: \Program Files\CA\Unicenter DSM\agent\units\00000001\uam\bak\amsoft.xml On UNIX\Linux: /opt/CA/UnicenterDSM/Agent/AM/data/work/BAK/amosoft.xml This creates a file containing the differences between the new scan result and the previous one. On UNIX\Linux, it is stored in the following location: /opt/CA/UnicenterDSM/Agent/AM/data/work/amosoft.dat The agent plug-in then takes this results file and sends it to the Scalability Server. Tip: To run the signature scanner manually use the following syntax on Windows:
amswsigscan <signature file> <result file>
On UNIX\Linux, use the following syntax:

camevmscli <signature file> <result file>
September 2007
In both cases the <signature file> would typically be the XML file located in the working directory and the results file will be the XML file containing the result of the scan. The results file is sent to the Scalability Server in the same way as any other hardware or software inventory file and it ends up in the following folder: On Windows: \Program Files\CA\Unicenter DSM\Server DB\SECTOR\COLLECT\00000001 On UNIX\Linux: /opt/CA/UnicenterDSM/Server/serverdb/SECTOR/COLLECT/00000001 The naming convention for the file is:
HOST_UUID.Wnn
The DSM Engine later collects the file and populates the MDB appropriately.
Using an Enterprise Server

It should be noted that only custom software signatures defined at an Enterprise Manager are replicated down to Domains. However, all discovered software is replicated up to the Enterprise Manager from the Domain Managers.
A Closer Look at the Import\Export Utility

The Import\Export utility, which is available in r11.2, is a command line tool configured through an XML file that provides the ability to share software definitions between DSM Domains that are offline. This supports custom created software definitions and CA provided software definitions as well. The utility uses BULK functionality and requires installation of the Microsoft SQL Client. For more information see the Inside Asset Management Guide. The Import\Export utility is executed through the following syntax:
Run \bin\Contentutility.exe
This creates a content_utility.xml file which MUST be modified prior to performing the actual import\export. Following is an example of this file:
78
September 2007
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:
September 2007
Diagnosis Tips
Diagnosis Tips
If you run into problems running a software scan, check to see that the latest XML file for the Engine is valid. To do this load the XML file with an XML viewer (for example, a web browser). If it contains errors (wrong XML) then delete all XML files in that directory. They will be automatically regenerated by the Engine. If the signature file gets corrupted at the agent level the scan will most likely not produce any results. A simple way to check the file integrity is to load it in a web browser. If the browser complains about the syntax then it is likely that the scanner will too. The software signature scanner can be run manually with the -DEBUG switch to reveal further information about what's going wrong.
710
September 2007

This chapter provides a closer look at the Remote Control connection including: General flow Processes and log files Getting the authority list Connection to the desktop Displaying confirmation dialogs Starting remote control Security components RC messenger Diagnosis tips For additional information you should consult the following sources: DSM HTML Help Web Services Reference Guide Inside Remote Control Guide Unicenter Desktop and Server Management Diagnostics 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) A full list of techdocs is also available from the following link: http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp
Overview and Flow

The Remote Control function essentially allows a user of a Windows computer to access a remote Windows or Linux computer as if they were sitting in front of the physical machine. All keyboard and mouse input is relayed to the remote computer.
September 2007
81
Overview and Flow
In a managed environment Remote Control Viewers and Hosts communicate with DSM Scalability Servers and Managers in order to retrieve address book information, validate/authenticate users and retrieve permissions for valid users. The process flow is as follows: 1. Obtain Connection Information Global Address Book Local Address Book Quick Connect 2. Obtain Authority List This is not required for Local security mode and the User doesnt have to do this explicitly. 3. Validate Credentials via: Locally Managed Security Centralized Security Security Cache/Fail-Safe 4. 5. 6. Connect to Target Desktop (control User Input) Prompt User to Display/Connect to Host GUI Start Remote Control Session and load video capture
82
September 2007

The remote control connection function utilizes the following processes and log files:
TRC_URC_HOST GUI_n.log
TRC_URC_HOST_n.log
TRC_URC_VIEWER_n.log
Host GUI (cfSysTray.exe) Host (rcHost.exe)
TCP RC Session
Viewer (EGC30n.exe+ Gui_rcView.dll)
Capture Helper (rcUtilCmd.exe) SM Address books
TRC_URC_UTILCMD_ n.log
SM Registration+ authentication
SM Host Commands
RC Server (rcServer.exe)
SM Registration + Authentication
RC Manager (rcManSrv.exe)
SQL
TRC_URC_SERVER_n .log
TRC_URC_MANSRV_ n.log
Getting the Address Book

When the Remote Control Viewer connects to the DSM Manager and requests up-to-date address book information RCAddressBookManager compiles the address book according to validated users permissions.
September 2007
Chapter 8: Remote Control Connection 8- 3
Getting the Authority List
Depending on which manager hierarchy is in place, the Global Address Book that is returned may be either a Domain Address Book or an Enterprise Address Book. The following MDB Tables are used to store address book information: urc_ab_computer Computers in the address books urc_ab_group_def In which groups computers/groups appear urc_ab_groups_member In which groups computers/groups appear urc_ab_permission User permissions applied to a group RCMgrAddressBook caches the information locally on the Viewer where it is only used if the manager connection fails.

The following process is used to obtain the Authority List: 1. 2. Viewer establishes connection to Host and sends M_STATUSQUERY 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
84
September 2007
Here you can see a graphical depiction of the process:
September 2007
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:
86
September 2007
Connecting to the Desktop
Cached\Fail Safe Validation

Following is a graphical depiction of cached\fail safe validation authentication process:
In this method there is no communication to the Domain Manager.

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 machines local keyboard, mouse and display. However, RC Sessions can switch between TS sessions if the console switches.
September 2007
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.
88
September 2007
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 CAFs system tray process (cfSysTray.exe) though it can be launched inside a dedicated rcUtilCmd process if cfSysTray is not available.
September 2007
Displaying Confirmation Dialogs
rcHost controls the Host GUI through the IRCHostGUI interface while CRCHostGUI provides the actual implementation of the GUI, including the system tray menus. CRCHostGUIProxy implements the IRCHostGUI interface, transparently proxying all calls to the CRCHostGUI object in the GUI worker process. CRCHostGUIStub reads messages from the GUI Proxy, and converts them into calls into CRCHostGUI CRCGUIPipe implements the IPC between the proxy and the Stub The Chat GUI shares the RC GUI pipe connection with the system tray if available. Otherwise, a dedicated rcUtilCmd.exe process hosts the chat GUI for each Terminal Services session
Displaying Confirmation Dialogs

Each CRCTerminalObject controls the Host GUI for that TS session. CRCTerminal objects are created on-demand. The Host GUIs run independently, and listen for connections on their IPC GUI Pipes CRCSession::GetConfirmation() checks to see if end-user confirmation is required. If no one is logged on, the override confirm at login policy is used to determine what to do. If confirmation is required, a WAITFORCONFIRMATION message is sent to the viewer, to update the UI. The IRCHostGUI::ShowConfirmDialog function is called to prompt the user. The result from the dialog is sent as a WM_ENDDIALOG message via the Hosts internal message loop, and processed in CRCSession::ProcessMessage. If all is successful, CRCSession::AcceptLogin is called, which sends an M_CONNACC message to the Viewer.
Starting Remote Control

Once the login is complete, the Viewer sends M_CONNACC, VIEWER_PROTOCOLS and VIEWER_FONT_CACHE messages to the Host. When received, the host calls CRCSession::StartViewing, from the main host thread. The video capture components for the target TS session are managed by a CRCDisplay object owned by the CRCTerminal. The CRCDisplay object maintains a list of Graphics Targets, which includes RC Sessions, per-session host side recordings and manual recording sessions.
810
September 2007
Diagnosis Tips
The CRCDisplay object owns the RCVideoCapture & RCGraphics components.
RCConfig and RCTrace

RCConfig emulates the old IRCConfig interface. It sits on top of DSMs 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 DSMs common tracing (i.e., cftrace) but it does not trace line numbers or source files. New RC code will use CCL tracer directly.
Diagnosis Tips
The video capture threads process an incredible throughput of packets. There is no tracing during normal operation of the video capture after start up. Beware of threads when analysing the Server or Manager logs. There can be several worker threads servicing different requests concurrently. Use a log analyser to filter out irrelevant execution paths. The tracing from the RC Viewer GUI can be spread across a number of trace files. Some of the common components are shared between the different GUI plug-ins, so the trace from these components will appear in the wrong place. Use a log analyzer to combine the log output, and then filter. CCNF, RC Messenger and Session Messaging produce a lot of tracing so filter it using a log analyser. The following trace files are available: TRC_URC_HOST_n.log rcHost process logs TRC_URC_HOSTGUI_n.log Host GUI logs, from system tray TRC_URC_UTILCMD_n.log rcUtilCmd worker logs TRC_URC_VIEWER_n.log RC Viewer GUI log TRC_URC_WRAPPER_n.log, TRC_URC_REPLAYER_n.log Viewer trace from CCL may appear here TRC_URC_SERVER_n.log Server logs, very heavily laden with noise TRC_URC_MANSRV_n.log Manager logs
September 2007

This chapter provides a closer look at the software delivery process including: General flow USD Shares USD Directory structure Key USD files Key USD MDB tables OS processes, names, aliases and trace files for USD and DTS Process flow and log files for USD and DTS DSMinfo Collection Guide Troubleshooting tips Additional DTS Considerations For additional information you should consult the following sources: Inside Software Delivery Guide DSM HTML Help Web Services Reference Guide Unicenter Desktop and Server Management Diagnostics 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) A full list of techdocs is also available from the following link: http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp
September 2007
91
Overview and Flow
Overview and Flow

Following is a graphical overview of the Software Delivery architecture:
Manager
Scalability Server
Agent
Common Stack
MDB
File System
File System
File System
TASKMAN
INSTMAN
SDSERVER
SDJEXEC
APISRV
DIALOGM
SDDTAFLT
SDMSIEXE
MGRFT (not EM)
SDDTAFLT
SDPILOT
DTSFT
SDDTPUSH
SDDTAFLT
WAC
EXPLORER
CATALOG
WS
CADSMCMD
SDSSCMD
SDACMD
Software Delivery processing can be broken down as follows: 1. The software package is created. The package must include an installation procedure. The package may optionally include configuration, activation and uninstallation procedures. 2. The software package is registered in the Software Delivery Library. Depending on administration requirements this may occur at the Enterprise Manager or Domain Manager. 3. The package is distributed to target computers. This can be either at the request of the administrator (push) or, if catalogs are used, at the request of the target user (pull).
92
September 2007
Overview and Flow
4.
The package installer is executed This occurs after the package has been successfully delivered directly to the end system or to an accessible network share the packages installer is executed.
5.
The status of the package delivery/installation is reported back to the originating manager at various stages throughout the process.
One of the first steps in troubleshooting is to determine at which point in this process the problem occurred. For example, the failure of a software package to install on a target may be the result of a faulty package creation, an improper library registration, a communication failure between components during package transfer, or a resource/environmental deficiency on the part of the target system. The following graphics are provided to give you a better understanding of the communications that occur between each of the Software Delivery components. First is the relationship between the UI and the Manager:
September 2007
Chapter 9: Delivering Software 9- 3
Overview and Flow
Next is the relationship between the Enterprise and Domain Manager:
Here you can see the Domain Manager to Domain Manager communication:
94
September 2007
Overview and Flow
Following demonstrates the distribution of Jobs to Agents:
Here is what it looks like when DTS is used:
Here is what it looks like when using NOS or NOS-less delivery:
September 2007
Overview and Flow
When DTS is used, activation occurs as follows:
96
September 2007
Overview and Flow
Following depicts the effect when NOS is used:
Following depicts the effect when NOS-less delivery is used:
September 2007
Overview and Flow
Here you can see the response:
The following graphic demonstrates the distribution of orders between the Domain Manager and Scalability Server:
98
September 2007
Overview and Flow
The following demonstrates the relationship between the Scalability Server and Agents:
DTS Integration
Here you can see how the process changes when DTS is used:
September 2007
Overview and Flow
This impacts the relationship between the Enterprise and Domain Manager as follows:
Here you can see the relationship between the DTS Domain Manager and Scalability Server:
910
September 2007
USD Shares
The following graphic depicts the relationship between the DTS Domain Manager, Scalability Server and Agent:
USD Shares
The following shares are used by the Software Delivery component: \\<Scalability Server>\SDLIBRARY$ \\<Scalability Server>\SDMSILIB SDLIBRARY$ share is used by SDJEXEC to identify the location for NOS-based library access by agents. It uses the following configuration parameters: Itrm/usd/shared/sdlib specifies share name Itrm/usd/shared/exportarchive specifies full UNC The SDMSILIB share is used by SDMSIEXE (via SDJEXEC) to identify the location for NOS-based access to MSI administrative installations by agents. It uses the following configuration parameters: Itrm/usd/shared/msilib specifies share name Itrm/usd/shared/msiadminpathunc specifies full UNC
September 2007
USD Directories
USD Directories
The following directories are used by the Software Delivery components: Library \SD\ASM\LIBRARY Used By 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) Temporary location for s/w pckgs for NOSSDSERVER based job execution. SDJEXEC (via share) Uses junction points/symbolic links into \SD\ASM\LIBRARY when possible. Temporary location for zipped s/w pckgs for NOS-less based job execution \SD\ASM\DATABASE TASKMAN (DM) SDSERVER Non-MDB computer info, Itrm/usd/shared/database 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/asmtemp (+/activate) Incoming DTS transfers MSI administrative software pckgs Itrm/usd/shared/msiadminp ath Used For Permanent location for software packages Configuration Parameters Itrm/usd/shared/archive
Incoming and outgoing DTS transfers
Itrm/usd/shared/incoming Itrm/usd/shared/outgoing
\SD\ASM\CONF
SDJEXEC SDMGRMIG
912
September 2007
USD Directories
Library \SD\ASM\DEVICE
Used By SDPILOT
Used For Integration DLL for Palm Pilots, and other devicespecific data Temporary files
Configuration Parameters
\SD\TMP
SDJEXEC SDMGRMIG
\SD\IPC
SDJEXEC SDACMD
Signaling to agent from install programs Stores localized SD resources 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 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 Temporary location for Itrm/scalability_server/serv erdb_path (+/swjorder) s/w job orders and results and s/w detection records. Also location for serverspecific agent identity data Temp location for s/w job orders, results and s/w detection records. Also each <unitID> can represent a computer, user profile or docking device
\SD\NLS \SD\AUTOREG
Nearly all SD programs TASKMAN
\SD\Legacy
Administrator
\ServerDB\SWJORDER
SDSERVER
\Agent\units\<unitID>\u sd
SDJEXEC
September 2007
USD Files
USD Files
The following files are used by Software Delivery: \ServerDB\SWJORDER\<host_uuid>\appl.apc Used by SDSERVER to queue Software Job orders for agents with HOSTUUID. \ServerDB\SWJORDER\cachedagdata.xml Used by SDSERVER for Job results which have not been sent to the manager yet. Also used in stage check mode. \SD\ASM\DATABSE\hostcert.dat Used by SDGENERAL.DLL/SO (SDSERVER, TASKMAN, INSTMAN) for storage of public host certificates of remote hosts. Also used for fallback when the remote host is not online when an encrypted S&F message is to be sent to that host. \SD\ASM\DATABSE\imnothand.xml Used by INSTMAN for notification events not yet handled by IM during shutdown are stored in this file. On startup these notification events will be loaded and handled before any queued notification events. \SD\ASM\DATABSE\compdata\<host_dbuuid>.ini Used by INSTMAN to store information about the agents previous domain manager. \SD\ASM\DATABASE\compjobs\<ss_dbuuid>.tss Used by TASKMAN to store information about ongoing DTS transfers between DM and SS. Also used to avoid transferring the same package in parallel. \SD\ASM\DATABASE\compjobs\<job_dbuuid>.job/dtp/dts etc Used by TASKMAN, DTSFT to exchange transfer information between TASKMAN and DTSFT. Note, no more job specific info here as the USD4.0 FileDB has been removed. \Agent\units\<UnitID>\usd\sdjexec\<job_cnt_dbuuid>.cof/cwf/ crf Used by SDJEXEC to keep the state of job containers. The extensions are as follows: *.cof = not started *.cwf = working *.crf = completed
914
September 2007
MDB Tables
MDB Tables
The Software Delivery function uses the following MDB tables: Table Usd_swfold Usd_job_cont Usd_activity Usd_rsw Usd_actproc Usd_applic Ca_group_def Usd_v_target Usd_v_ownsite(EM) Usd_v_csite (DM) Usd_v_ownsite (DM) Usd_v_ls (EM) Usd_cont (+usd_cc, usd_carrier) Distribution container Usd_order (+usd_distsw, usd_distap, usd_disttempl, usd_fio,usd_fitem) Distribution order Domain Manager Used for Software group, procedure group, catalog group (DM only) Software job container, software policy Software job, software policy job Software package Software procedure Application (DM only) Asset group Asset Enterprise Manager
In addition, other supplementary tables, prefixed by usd_* are used.
September 2007
Process, Trace and Log Files

The following process and log files are used at the Manager Level: Process (EXE) Name Sd_taskm Sd_taskm Sd_mgr_ft Sd_dtsft CAF Name Sdmgr_tm Sdmgr_im Sdmgr_ft n/a Logical Name Task Manager Installation Mgr. File Tranfer mgr. DTS Integration Description Main job evaluation Engine Trace File Trc_usd_taskm_x.log
Job results collecting Trc_usd_instman_x.log Engine File transfer Engine (enterprise r11.2) Legacy file transfer Engine (removed in r11.2) Trc_usd_sdmgrft_x.log Trc_usd_dtsft_x.log
Sd_dtpush Sd_apisrv
n/a Sdmgr_api_#
DTS integration API server
Legacy file transfer Trc_usd_sddtpush_x.log Engine (not in r11.2) TRC_usd_apiserver_x.log Client counterpart used by UI to perform USD specific operations Trc_usd_dialogm_x.log Client counterpart used by UI to obtain free sd_apisrv. Essentially, a dispatcher Used for integration Trc_usd_sdahdcmd_x.log with Unicenter Service Desk
Sd_dialog_m
Sd_mgr_dm
Dialog Mgr
Sd_ahdcmd
n/a
Service Desk Integration
916
September 2007
The following table depicts the details for the DSM Explorer and Scalability Server components: Process (EXE) Name Egc30N Sd_registerproduct CAF Name n/a n/a Logical Name Description SD Explorer SW Package registrator UI Registers SXP, PIF, PKG and RPM packages. Called by DSM Explorer Handles all software Trc_usd_sdserver_x.log jobs Trace File Trc_GUI_x.log
Sd_server
Sdserver
SD Scalability Server Plug-in
The following table depicts the details for the DTS on the Agent Tier: Process (EXE) Name Tngdta CAF Name dtsagent Logical Name DTS Transfer Agent Description Trace File
Trc_dtsagent_x.log (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
Tngdoba Dtsitrm.dll Dtstcp11.dll
DTS Browser
DTS Object Browser
Not used by USD TCP Protocol wrapper using DSM Networker TCP protocol wrapper
Trc_dtsbrowser_x.log
September 2007
Install Packages and Trace Files
The following depicts the details for DTS on the Manager tier: Process (EXE) Name Tngdtos CAF Name Dtstos Logical Name DTS Transfer Object Server Description Main DTS data transfer Engine. Responsible for all managed transfers (Not req. in r11.1). Calculates the best transfer route according to CCS WV. Main API used to communicate with DTS (USD, DTS CLI,etc) Trace File Trc_dtstos_x.log
Tngdtsnos
Dtsnos
DTS Network Object Server
Trc_dtsnos_x.log
Tngdt.dll
n/a
DTA API
TRC_DTS_x.log
Tngdtsos
dtssos
DTS Scheduler Object Server
Enables scheduling of Trc_dtssos_x.log transfer activations (not used by USD)s
Install Packages and Trace Files

Following is a list of install packages and trace files for Windows installs: S/W Pckg Manager.msi Manager.msi AfterCopy SDMgrAfterCopy DtsManagersAfterCopy + DtsCommonAfterCopy Server.msi AgtSD.msi AgtDTS.msi SDSvrAfterCopy SDAgAfterCopy DtsAgentAfterCopy + DtsCommonAfterCopy Explorer.msi n/a TRC_Inst_iTRM_x.log DSMSetupExplorer.log TRC_Inst_ITRM_x.log TRC_Inst_ITRM_x.log DSMSetupScalability Server.log DSMSetupAgentSD.log DSM Install Trace TRC_inst_ITRM_x.log TRC_Inst_ITRM_x.log Installer Trace DSMSetupManager.log DSMSetupManager.log
918
September 2007
USD Logical Process Flows and Log Files
Following is the corresponding list for Linux installs: S/W Pckg Ca-dsm-sdmanager.Linux.@pif Ca-dsm-sdserver.Linux.@pif Ca-dsm-sdagent.Linux.@pif Ca-dsm-dtsagent.Linux.@pif AfterCopy SDMgrAfterCopy SDSvrAfterCopy SDAgtAfterCopy DtswAgentAfterCopy + DtsCommonAfterCopy DSM Install Trace TRC_*_x.log TRC_*_x.log TRC_*_x.log TRC_*_x.log Installer Trace Ca-dsm.*.log Ca-dsm.*.log Ca-dsm.*.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:
September 2007
920
September 2007
Following is the corresponding information for r11.2:
September 2007
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.
922
September 2007
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 ERRORs 2000 Cftrace c set f DTS l ERRORs 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.
September 2007
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.
924
September 2007
Chapter 10: OSIM

This chapter takes a closer look at OSIM and includes: Architectural and OSIM component overview Process and Log file information Process flow Installation and configuration Boot server behavior Image Prepare System Sample flow Under the hood OSIM and CADSMCMD For additional information you should consult the following sources: Inside Software Delivery Guide DSM HTML Help Web Services Reference Guide Unicenter Desktop and Server Management Diagnostics 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) A full list of techdocs is also available from the following link: http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp
OSIM Architecture
OSIM provides bare metal Operating System (OS) installation on designated targets in an enterprise network provided those targets are able to boot from the network.
September 2007
Chapter 10: OSIM
101
OSIM Architecture
The OSIM infrastructure consists of the following: Manager plug-in that controls the installation process DSM Explorer and DSM CLI plug-ins Support for preparation of OS and BOOT images Tools to setup and configure OS PXE/TFTP Book Server (a Scalability Server plug-in) Here you can see how OSIM components fit into the DSM architecture:
Following is a more detailed graphic depicting the relationship between OSIM components:
102
September 2007
OSIM Architecture
DSM Explorer OSIM queries OSIM plugin
CADSMCMD
OSIM extensions
DSM Domain Manager
DSM MDB
OSIM Manager plug-in (CSM)
SD SW library SD pkg of Boot and OS image Store info about Boot and OS images
OS installation jobs with boot parameter. State of Jobs, Boot Server and Image
Install boot and OS images in the image store of remote Boot Server
Register Boot and OS images as SD package
Scalability Server OSIM Boot Server plug-in PXE Data and Boot parameter Load Boot, OS Image PXE Target Computer Boot and OS Image Store + FCOR DOS boot diskette and original OS CD
DSM Packaging Tools OSIM Boot and OS Image Prepare System
IPS can share image store with Boot Server
Custom built WinPE, including OSIM files
Here you can see: OSIM Explorer plug-in provides the GUI support for management of OSIM Computers, Images and Jobs. OSIM CADSMCMD extension provides a command line interface offering the same functionality as the GUI. OSIM Manager plug-in manages all information about Target Computers, Boot Servers, OS and Boot Images. This information is stored in the MDB. OSIM Boot Server plug-in runs the PXE and TFTP services that reply to PXE requests from targets and deliver Boot and OS Images respectively. OSIM Image Prepare System (IPS) provides the functions necessary to prepare and register OS and Boot Images.
September 2007
Chapter 10: OSIM 10- 3
Process and Log Files
Process and Log Files

The relationship between the OSIM processes and log files is demonstrated by the following graphic:
There are three steps to performing unattended installation on OSIM targets: 1. Pre-OS installation launched by a Boot Image (mini OS) For example this may include hard disk partitioning and, in the case of GHOST images, unpacking the image on the partition. 2. OS setup launched by Boot Image (mini OS) This is the unattended setup of OS Installation and, in the case of GHOST images, preparation of mini setup. 3. Post OS installation launched by OS run once This includes the delivery of the Admin password, domain integration, and DSM agent installation. Boot parameters control the auto answer files and installation scripts. Imaging tools can be used for cloning. However, images must be prepared for unattended mini setup.
104
September 2007
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 <path>
If the Boot Server is configured for share access, on LINUX, the Samba server has to be installed.
September 2007
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 administrators 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:
106
September 2007
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
September 2007
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 vendors 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)
108
September 2007
Example
Redhat 9.0, 3.0, 3.04, 4.0-4.03 (DOS + LINUX boot) Suse 8.2, 9.0 (DOS + LINUX boot) OSIM does not include any OS files not owned by CA. IPS can be installed from DVD from the Packaging Tools. It is installed with a Domain Manager, by default, and can only be installed on Windows. IPS setup is linked with the DSM Explorer. IPS and Boot Server share the same Image Store (path can be set with the Boot Server setup). If no image store is on the system, IPS commands create a default.
Example
This example walks through the following steps for using OSIM: 1. 2. 3. 4. 5. 6. 7. 8. 9. Create Boot Images Register Boot Images Create OS Image Register OS Image Prepare the Target for Network Boot Boot the Target Change the Target to Managed Modify Job Parameters Activate the Install Image
10. Boot the Target to Initiate the install
Create Boot Images

The first step is to create a Boot Image. You can create a DOS Boot Image from a Win98 Boot Floppy or MSClient (if the image is used for share access). The MSClient can be obtained from a Windows NT 4 Server CD or from a Microsoft FTP server. Another option is to create a WinPE Boot Image. To do this you would start with prepared WinPE in a directory structure and add the CA tools to create an ISO image. If you use a WinPE Boot image the BOOTDOS network bootloader is downloaded from the Boot Server and executed by the PXE BIOS as follows.
September 2007
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.
1010
September 2007
Example
CreateBTImages looks for the Win98SE DOS boot diskette on A: (the A drive) and does the following: 1. Adds MS-Client from a Windows NT4 Server CD or from a given directory to A:\net () Note: This is the minimal configuration for share access. Without MSClient, 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\*.* 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
to A:\net
4.
Creates osinstal.2 image using copy144.exe
September 2007
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
1012
September 2007
Example
Create OS Image
OS images are created using the CreateOSImage command. Here you can see the syntax:
For example:
Createosimage i myhost2 o GHOST-XP s c:\myhost2 k abcde-12345-abcde-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 abcde12345-abcde-12345-abcde.
September 2007
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:
1014
September 2007
Example
Prepare the Target for Network Boot

To prepare the target machine for network boot you need to enable Network Startup in BIOS as seen in the following example:
September 2007
Example
Boot the Target

The next step is to boot the target in order to have it picked up by the Boot Server. The target returns the following information: The MAC address of the target (Client MAC ADDR) The IP address and network mask the target sent from the DHCP server The IP address of the DHCP server The PROXY IP which is the IP address of the selected OSIM Boot Server The IP address of the default gateway sent from the DHCP server The message that an OSIM Boot Server was selected (CA-Unicenter ManagedPC Boot Server)
Change Selected PXE Target to Managed

To change a PXE target to managed once it has been picked up right click on the target and select Managed(unmanaged) from the menu.
Select the OS Image to install and click OK.
Editing the Job Parameter

Installation parameters can be edited by selecting the OS Installation Parameters node as seen in the following example:
1016
September 2007
Example
Activate the OS Installation Job

Here you can see how the OS installation job can be activated based on a set date and time.
Click OK to set and the target OS installation will start with the next reboot.
Boot the Target to Execute the OS install job

Here you can see that the machine has been rebooted in order to activate and execute the OS installation job.
September 2007
Under the Hood
Under the Hood

The following topics present a more detailed discussion of various OSIM tasks and functions.
Boot Image Tools and Templates

Following is an example of the DOS\Net template files:
These files are introduced into the DOS boot images through the CreateBTImages command and can be used to specify the following: network access
1018
September 2007
Under the Hood
boot parameter OS image handling The winpe\ca-osim template files are required to specify the following: 32bit access to the Boot Server 32bit parameter OS image handling The following file structure is used to store DOS and WinPE Boot Images on Image Prepare System and Boot Server ManagePC\ images\ dosboot\ bootdos boothd UNDI\ osinstal.2 osinstal.3 winpex86.2 winpex86.2\ Winpex86.iso Winnt.sif Ntdetect.com ntldr startrom Boot Loader Boot disk operating system image store DOS network boot loader Network boot loader which jumps to Hard Disk boot RAM disk image files DOS, WinPE Raw DOS Diskette Boot image (first step) Raw DOS Diskette Boot image (second step) Boot image description files Boot image directory belonging to the description file
Here you can see the OS- image templates under the \camenu folder:
September 2007
Under the Hood
This directory contains all of the OS templates for preinstall and OS setup including the following: Windows original setup (for W2kP, W2KS, WXPP, WXPS, W98, WNT4, WME) Cloning (GHOST, PQIMG (Note no *.ftp,*.cmd,*.ftw)) LINUX original setup USEW, REDHATW The following file types are used: *.Inf: used for auto answer files for unattended setup *.Osi: use for osinfo.ini with file names of files including parameters *.Def: used for default.ini parameter definitions *.Par: used for disk portioning schema *.bat: Used for scripts to prepare and execute OS setup from DOS when using share access to Boot Server
1020
September 2007
Under the Hood
*.ftp: Used for scripts to prepare and execute the OS setup from DOS when TFTP access to the Boot Server is used. *.cmd: Used for scripts to prepare and execute the OS setup from WinPE when share access to the Boot Server is used *.Ftw: Used for scripts to prepare and execute OS setup from WinPE when TFTP access to the Boot Server is used Here you can see the OS image template files maintained under \images:
September 2007
Under the Hood
The template files are used for post installation functions. Each type has its own post install. If you add a driver to $oem$ in the template, all images of this type will get the driver. Windows calls the i386\$OEM$\cmdlines.txt file upon initial startup after successful installation. This file executes custom.cmd (first time) which adds the target into a domain. Other first step tasks can and should be added here. runonce is also set configured to run after reboot and then the machine reboots. The runonce command executes custom.cmd (a second time) which sets the administrator password. Other second step tasks can/should be added here. It also executes the sxpsetup.cmd command which executes the DSM Agent setup.
Template Files and OS Types

Here you can see how template files relate to OS Types:
For example, following is the template.ini definition of SUSEW90-CD type:

[SUSEW90-CD] type definition typecomment=SUSE 9.0 Professional,Personal comment in usage ossubpath=suse destination subpath for $OEM$ postinst files imagetemplates=susew take the $OEM$ templatefiles from susew dir
1022
September 2007
Under the Hood
createshare=MSNFS The OS image needs MS and NFS share batfile=susew.bat tftpfile=susew.ftp parameterdefinition=susew.def responcefile=susew.inf fileswithparameter=susew.osi partitionfile=susew.par stringtosubstitute=SUSEW Substitute this string with the image name in template files sdostype=251 SD type of this OS ;--The following lines specify what to read from the source CDs. Without these lines all will be read ;--read files from path (-s <path>) copyfrompath=SUSEWCD100 Copy details are in section SUSEWCD100 ;--read setup files from CDs but image is on external NFS Server (-a <sharename>) copytemplatesalways=yes Templates although needed on Boot Server morethanonealwayscd=1 Files from OS CD1 are needed on Boot Server cd100=SUSEWCD10 Copy details are in section SUSEWCD10 ;--read all files from CDs morethanonecd=5 The image files will be read from 5 CDs cd1=SUSEWCD1 Copy details from CD1 are in section SUSEWCD1 cd2=SUSEWCD2 cd3=SUSEWCD3 cd4=SUSEWCD4 cd5=SUSEWCD5 ;--SUSEWXX contents of CD copy (-s <path>) [SUSEWCD100] identfile=dosutils\loadlin\loadlin.exe check this file to accept the CD content=content copy directory (source = destination) boot=boot suse=suse dosutils\loadlin\loadlin.exe=loadlin.exe copy file (source = destination) media.1=media.1 media.2=media.2 media.3=media.3
September 2007
Under the Hood
media.4=media.4 media.5=media.5 ;--Setup LINUX files on Boot Server even if it use a remote NFS share [SUSEWCD10] identfile=dosutils\loadlin\loadlin.exe boot=boot dosutils\loadlin\loadlin.exe=loadlin.exe ;--SUSEWXX [SUSEWCD1] identfile=dosutils\loadlin\loadlin.exe content=content boot=boot suse=suse dosutils\loadlin\loadlin.exe=loadlin.exe media.1=media.1 [SUSEWCD2] identfile=media.2\media media.2=media.2 suse\i586=suse\i586 suse\noarch=suse\noarch files to copy from CDs
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:
1024
September 2007
Under the Hood
Each OS image has an osinfo.ini description file in the root directory of the image. This file indicates that the image store directory contains an OS image
September 2007
Under the Hood
Each OS image also has a default.ini describing parameters used in the image. This file contains several different sections. The [Default] section contains the default values for the parameters. The $xxx$ in the template are substituted by createosimage. The [Reserved] section contains a list of reserved internal parameter names and the [<Parameter>] section includes the definition of each parameter
To add a parameter to the auto answer file edit the auto answer file (in the above example, \ManagedPC\CAMENU\mywinxp.inf). The [RegionalSettings] section identifies the Language=$localeID$ information. To edit this setting locate the following value:
[Default] localeID=1033
Add the following new section at the end of the file:

[localeID] Type=MapListExt MaxLength=128 Comment=Language/locale to be installed Trans=yes item=5124 Chinese_Macau item=1030 Danish item=1033 English US
1026
September 2007
Under the Hood
item=2057 English UK item=1036 French Standard
To check the new parameter execute the following command:

RegisterOSImage -i <image> -t
This checks the files in osinfo.ini for $xxx$ parameter definitions against default.ini . If no parameter definition is found in default.ini, parameter definitions are added with default settings. To register the parameter from a command line, execute the following:
RegisterOSImage i <image> -s <manager>
Registering to Another Domain Manager

To register an OS Image from IPS to a remote Domain Manager, use the following syntax:
Registerosimage -i image -s remote Domain Manager -u user -p password -d unixl://remote DSM domain
Then, export the OS image from local Domain Manager and import it into the remote Domain Manager using the following procedures: 1. Export the OS-SD package into a directory.
2. 3.
Transfer the directory to the remote site. Import the OS-SD package with the following command:
Registerosimage -w directory -s Domain Manager
September 2007
Under the Hood
Special Preparation for GHOST and PQIMG Based Images

Use the following steps to create a clone image: 1. 2. 3. 4. 5. 6. 7. 8. Create a share (read, write) on IPS (including the ghost.exe). Create a FAT, FAT32 primary partition on the model target. Install the model OS (without DSM Agent) in the partition. Copy the MS sysprep files to the model PC and execute sysprep. Boot from a DOS Boot floppy with network access. Mount the share on IPS and execute ghost.exe from the share. Store the <image>.gho on the share. 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 <key>
The following command makes a copy of the update.inf template to the OS image and sets the product key from the default.ini:
RegisterOSImage
Note: The upgrade depends on the ability of the OS to upgrade a live system with a new OS version.
1028
September 2007
Under the Hood
OSIM Domain Manager Plug-in

Following depicts the OSIM Domain Manager plug in.
OS Installation Job States

You can monitor the state of the OS Job installation through the DSM Explorer. There are three possible job configurations: The current OS is the last successfully installed OS A planned OS is used to define an OS installation Job An activated or pending job is awaiting installation
September 2007
Under the Hood
Each job has to be defined in a planned configuration. After activation it becomes an activated, pending job and, after OS installation, it becomes current. Only one OS can be installed on a physical or virtual target.
OSIM (CSM) Data Base Design

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:
1030
September 2007
Under the Hood
Class Name BootDiskImage BootOSImage
Class ID 1006 1008
Properties Type, sdname, sdversion, sdcomment, detected Type, sdtype, locale, externalos, batchfile, sdname, sdversion, sdcomment, detected Type, Maxlength, Minvalue, Maxvalue, Trans, item (additional parameter values) See below Bootstatus, Configstate, Configstatetime, Activationtime, Waitforagent, Retrytime, requesttime Dnsname, hostname, hostuuid, macaddr, firstseen, bootfile Lastheard, lastreportallrequest, lastreportall, status
Bootparameter (for OS Images) Parametervalue (for OS images)
1002
106
Bootconfiguration (for OS 1004 installation jobs) Computer Bootserver 102 1000
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:
September 2007
Under the Hood
Special Bootstatus Property

The following values are used to identify a jobs bootstatus: Value 1000 2000 3000 4000 5000 6000 7000 8000 10000 11000 20000 21000 22000 Status Current Stopped Cancel pending Failed Set if delete is ordered for job Boot server not responding Unmanaged ADS Managed Planned Activated Analyzing Pending Installing
The computers 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.
1032
September 2007
Under the Hood
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:
September 2007
Under the Hood
1034
September 2007
Under the Hood
Boot Server Components

Here you can see the various components used by the Boot Server:
More details about these functions is provided in the next few sections.
Boot Server Configuration

Sdmpcserver (sdmpcworker.exe) is a CAF process that uses multiple threads for TFTP, PXE, Agent-copy, ping and password change. These threads (MaximumThreadPoolSize) are created during startup and are dynamically assigned and released from the thread pool. If more threads are needed, the thread pool will be increased stepwise by 10. If this happens frequently, you should consider increasing the MaximumThreadPoolSize value. The configuration can be changed through configuration policies maintained in the following location:
September 2007
Under the Hood
/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 Servers 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 log. 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) Min = 1, Max = 5, Default = 3 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.
1036
September 2007
Under the Hood
TftpTimeout (TFTP timeout) Min = 1, Max = 10, Default = 3 Maximum timeout in seconds to wait for the next packet from a target. Here you can see how the PXE and TFTP threads work together:
The PXE thread monitors port 67 for DHCP discover. If USEacl=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.
September 2007
Under the Hood
OSIM Boot Server Ping Thread

The OSIM Boot Server Ping thread monitors targets by doing the following: Pinging known targets and waiting for a ping response 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. If the target is not accessible within the designated time period (2 hours by default) it will also be removed from the TFTP access list. The following parameters are used to specify OSIM Boot Server ping configuration: PingTimeout (PING timeout) min =1, max = 10, default = 2 time in seconds to wait for a ping response. PollIterations (PING poll iteration) Min = 1, max = 500, default = 120 Number of times to ping a target machines before it is determined to be down. PollInterval (PING poll interval) Min = 1, max = 600, default = 60 Time in seconds between which pinging of all machines known by the Boot Server is performed.
Boot Server Password Setting

The Password change thread changes the password of the OSIM canonprv user (local user) on a regular basis. The encrypted password is stored in the local comstore, from which it is sent to the target with each PXE boot. This password is used in the Boot Image to get access to the shares on the Boot Server. The following parameters are used to configure the password change thread: PWCDays (Password change interval) Min = 1, max = 365, default = 1 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.
1038
September 2007
Under the Hood
Min = 8, max = 128, default = 14 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. Min = 0, max = 128, default = 5 PW_num_upper_case_characters (Number of upper case characters in password) The minimum number of Uppercase Characters [A-Z] to be generated. Min = 0, max = 128, default = 3 PW_num_lower_case_characters (Number of lower case characters in password) The minimum number of Lowercase Characters [a-z] to be generated. Min = 0, max = 128, default = 3 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. Min = 0, max = 128, default = 3
Boot Server Agent Copy Thread

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.
September 2007
Under the Hood
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:
1040
September 2007
Under the Hood
Following is a list of reports that can be launched to the Manager by the sdbsmstate (Csmagent): Report Bsinfo Bscompinfo Bsosinfo Bsbtinfo Bsbreginfo Description Report Boot Server status Report status of assigned PXE target machine(s) Report available OS images Report available boot images 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 Bssync Bsstartpxe Bscompinstall Bscompcancelinstall Bscompremove
Description Synchronize list of assigned PXE targets with manager MDB Start answering PXE requests Activate OS installation job Cancel active OS installation job Remove computer from list of assigned PXE target machines
September 2007
Under the Hood
Request Bscompserve Bscompwol
Description Add computer to list of assigned PXE target machines and abort active OS installation Wake up target computer
The OSIM Manager sends the reboot request for a target to the sdbsmboot (Csmagent) to the targets agent. Bslocalreboot triggers local reboot (provided by DSM Agent).
Boot Server Administrative Files

Administrative files for sdbsmstate are kept in the following location:
c:\Program Files\CA\DSM\Server\SDBS\var\ManagedPC.
Sdbsmstate reports changes of Boot Server data to the manager only once. The following files are used as memory for reports: Filename Bsmbreq.dat Bsmconf.dat Bsmimgb.dat Bsmimgo.dat Bsminfo.dat Bsmstat.dat Contains Reported boot requests Start data of the job to compare with FCOR Reported boot images Reported OS images Sent hello (alive) messages Reported state changes of install jobs
Here you can an example of the contents for a bsmimgo.dat file:
1042
September 2007
Under the Hood
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:
September 2007
Under the Hood
Pending = 0/1 identifies the pending OS job Running = 1 indicates that the OS job is running while Running = 0 indicates that the boot sequence finished Boot1st = boot loader file 1stFile = first boot file in the sequence NextFile = Next boot file in the sequence Following is an example of the contents of a bsmbreq.dat file:
Following is the key to interpreting the contents of this file: Served = 0 indicates that no PXE request has been answered while Served = 1 indicates that the PXE request has been answered for the client ADSclient = 0 indicates that the target is not managed by ADS while ADSclient = 1 indicates that it is
Data Exchange Between sdmpcserver and sdbsmstate

The following files are used for data exchange between sdmpcserver and sdbsmstate. They are found in the following location:
c:\Program Files\CA\DSM\Server\SDBS\var\ManagedPC
1044
September 2007
Under the Hood
File name Mac.acl ManagedPCDataFile
Contains MAC of all targets the Boot Server is responsible for (FCOR) basic PXE data of targets (binary format). A test tool listfcore shows the contents MAC of a newly picked up target until the manager accepted the boot sever relationship and the MAC is added to mac.acl
PXEBoot.log
Boot Server WOL and Reboot

The WOL and Reboot request is sent in the install job to the Boot Server. The Boot Server sends the Job to the Domain Manager. The DM synchronizes Reboot and WOL The DM sends the Reboot request to the target via sdbsmboot which uses the CAF Reboot service to restart the target. The DM sends a WOL request to the responsible Boot Server through sdbsmstate which uses the CAF WOL service to broadcast the WOL magic package.
WOL broadcast and subnets: The WOL (magic package) is sent as a broadcast package in the servers 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

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 Servers image store A Boot Server provides access to the image store via shares or via TFTP.
September 2007
Under the Hood
The target Boot Images are always load via TFTP but, depending on the Boot Server configuration, the OS files will be read from shares or via TFTP GHOST, GHOST32, PQIMG OS can only be installed from shares. Here you can see how the OS installation 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)
1046
September 2007
Under the Hood
Createshare = MS or NFS or MSNFS (creates this type of share where MS = Microsoft share; NFS = LINUX NFS share; MSNFS = both )
Remote Execution of sdbsswitch with Configure Job

The Scalability Server package includes configure procedures to change the Boot Server access method via Software Delivery.
Access for LINUX OS images

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.
September 2007
Under the Hood
IPS and Boot Server on One System

When Boot Server is in TFTP mode the Createosimage -i <imagename> command does not create a .caz file. This must be done later with the following command:
createosimage z <imagename>
For a Linux OS image, createosimage tries to create an NFS share if the following is fulfilled: Unix services for Windows 3.5 is installed LINUX image is not on an external NFS share (-a <share>)
Use of Microsoft Automated Deployment Services (ADS)

DSM Boot Server can coexist with the ADS Boot Server Because of an arrangement between CA and Microsoft, ADS and DSM OSIM should be able to coexist Microsoft ADS can be downloaded from Microsoft and requires Windows 2003 Enterprise Server Microsoft ADS has its 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.
1048
September 2007
Under the Hood
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.
September 2007
OSIM and CADSMCMD
OSIM Boot Server and Manager Events

Both the OSIM Boot Server (sdmpcworker) and OSIM Manager (DSM) write events to the Application event log.
For a complete list of events, refer to the OSIM Inside Guide.
TFTP OSIM Boot Server Events

The TFTP communication component of the OSIM Boot Server (sdmpcworker) can be configured to write events for every TFTP read request. Since a large number 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. Set to true for a specific Boot Server, it enables logging of TFTP read requests. Set to false it disables logging of TFTP read requests.
OSIM and CADSMCMD

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: Administering target systems Setting up new OS configurations and maintaining them Initiating and controlling OS installation requests via network
1050
September 2007
OSIM and CADSMCMD
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:
September 2007
OSIM and 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=<file_name> SDCMD_TRACE_OPT=B3C9
1052
September 2007
OSIM and CADSMCMD
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.
September 2007
OSIM and CADSMCMD
<default manager> is the manager specified at time of CO CAPI installation. It is a COCAPI parameter and not known to the CADSMCMD. If no local parameter is specified this manager is addressed otherwise the local one is taken. <default user> 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.
TargetComputer command
OSIM uses the CADSMCMD targetComputer command. The set of actions is nearly the same as with USD 4.0: Action Create List showAttr Description Creates a computer DSM that is SD and OSIM enables Lists DSM computers that are SD agents and OSIM un-managed PC Shows the attributes of a computer including OSIM information about OSIM configurations Assigns a new OS image to an OSIM un-managed but registered computer Assigns a new OS image to an OSIMmanaged computer Lists the installation parameters of an OSIM configuration Modifies installation parameters in a planned configuration Deletes the specified OSIM configuration of a required type
setupOS modifyOS showInstallParameter modifyInstallParameter Delete {planned|scheduled}OS
1054
September 2007
OSIM and CADSMCMD
Action activateOS reactivateOS reinstallOS cancelOS Delete
Description Schedules a planned OS configuration for installation Reschedules a failed or canceled configuration Schedules the current OS configuration for reinstallation Cancels a schedules OS installation request (graceful) 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 OSIM 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 parameter 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.
September 2007
OSIM and CADSMCMD
In r11 the parameters userParameter and userName are ignored by CADSMCMD. No error or warning is given.
Enhancements/Changes
Here you can see how the command syntax has changed: targetComputer action=create name=computer name computerType={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}]] [waitBs[={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.
1056
September 2007
OSIM and CADSMCMD
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 [atTime=YYYY-MM-DD hh:mm] [wakeup[={y|n}]] [restart[={y|n}]] [waitBs[={y|n}]] [waitIm[={y|n}]]
targetComputer action=reinstallOS name=computer name [atTime=YYYY-MM-DD hh:mm] [wakeup[={y|n}]] [restart[={y|n}]] [waitBs[={y|n}]] [waitIm[={y|n}]]
Example Scenarios
Following are a series of examples demonstrating the use of CADSMCMD for OSIM purposes.
Example 1
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.
September 2007
OSIM and CADSMCMD
For the purposes of our example, the following values are used: MAC address = FF:EE:CC:01:23:01 Name =osim_sy_1 network address=osim1.ca.com Scalability Server = my_server Boot Server = my_server (same as above) targeted OS image = myWinXP Here is the syntax:
targetComputer action=create 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 name=osim_sy_1
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 with 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.
1058
September 2007
OSIM and CADSMCMD
The final result is a new system on which the OS has been installed through OSIM and the required applications have been installed and configured through Software Delivery.
Example 2
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:
targetComputer action=create name=osim_sy_2 computerType=machine address=osim2.ca.com os=win_xp_intel macAddress=FF:EE:CC:01:23:02 osImage=myWinXP
The command is nearly the same as in the first example but the options stagingServer and bootServer are not coded. 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.
September 2007
OSIM and CADSMCMD
Example 3
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:
targetComputer action=create name=osim_sy_3 computerType=machine address=osim3.ca.com os=win_xp_intel stagingServer=my_server macAddress=FF:EE:CC:01:23:03 bootServer=my_server osImage=myWinXP
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.
Example 4
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 name=osim_sy_4 osImage=myWinXP
This command creates a planned configuration of myWinXP for the osim_sy_4 system. It does not change the Scalability or Boot Server assignments.
1060
September 2007
OSIM and CADSMCMD
Example 5
In this example, a DSM registered but OSIM un-registered system osim_sy_5 should become OSIM managed in advance and prepared for an installation of the OS image myWinXP. In the last example it is again assumed that the target system is already DSM registered but not yet PXE enabled. It is planned to manage this system by 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 name=osim_sy_5 osImage=myWinXP
This command makes the target OSIM managed but the Boot Server wont be assigned to it until it registers with OSIM. The following syntax can be used to schedule the installation request in advance:
targetComputer action=activateOS name=osim_sy_5 waitBs=y
When the target becomes PXE enabled and is booted for the first time it will register at OSIM and the Boot Server reporting this system will be assigned to it. Next, the CSM starts transferring the request to the Boot Server. 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.
September 2007
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
Glossary1
OSIM and CADSMCMD
Common Component Library (CCL)

The CCL provides common services that are used by many DSM components, including trace, configuration, security, and directory integration.
Configuration and State Management (CSM)

Configuration and State Management is a framework for configuring objects like software products or operating systems and tracking the status of those objects. It is used e.g. by OSIM.
Common Registration API (CORA)

All Unicenter r11 products utilize the common MDB schema to store and manage their data. CORA provides the interface through which these assets are registered and as the only source for updating these tables, (CORA) ensures that asset data flows consistently, thereby supporting the data and referential integrity of the Mobs 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.
Glossary2
September 2007
OSIM and CADSMCMD
DSM Explorer
The DSM Explorer is a single EGC framework-based Admin GUI. It consists of the framework itself, a common plug-in and a number of product specific plug-ins. The DSM Explorer provides a homogenized view and operation of all DSM products in which no product separation is apparent. As DSM products are purchased and installed the GUI simply becomes richer and more powerful.
Engine
The Engine is a multi-instance, multi-function, distributable component. Its primary focus is the maintenance of computers and related information. Logic is encapsulated into a number of Engine Tasks which can be scheduled to run at regular intervals.
Enterprise Server (ES)

Optional tier in Desktop and Server Management architecture which provides a single point of administration for multiple domains.
Graphical User Interface (GUI)

A graphical user interface allows a user to communicate with a product. Because of its graphical elements it is easy to use.

Image Prepare System (IPS) reads the OS files from the vendors 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.
September 2007
Glossary3
OSIM and CADSMCMD
Network Address Translation (NAT)

Internet standard that enables a local-area network (LAN) to use one set of IP addresses for internal traffic and a second set of addresses for external traffic. A NAT box located where the LAN meets the Internet makes all necessary IP address translations.
Networker
The Networker is a generic, protocol-independent interface to stream based networking. This is a loadable component, which makes use of other loadable components to provide support for specific protocols, such as TCP/IP.
Network Object Server

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

Every general-purpose computer must have an operating system to run other programs. Operating systems perform basic tasks, such as recognizing input from the keyboard, sending output to the display screen, keeping track of files and directories on the disk, and controlling peripheral devices such as disk drives and printers.
OS Installation Management (OSIM)

OS Installation Management is a feature of USD that manages the preparation, installation, configuration, and upgrade of operating systems in an enterprise network.
Plug-in
Computer program that interacts with a host application (a web browser or an email client, for example) to provide a certain, usually very specific, function "on demand.
Port Multiplexer (PMUX)

The Port Multiplexer is a plug-in that listens for stream connections and forwards them to the process that requires them. It handles connection establishment and enables multiple applications to listen on a single port (by default that port is 4728). The Port Multiplexer only supports TCP.
Port Address Translation (PAT)

Also known as "Network Address Port Translation" or "NAPT" PAT refers to network address translation where port number are mapped, allowing multiple machines to share a single IP address.
Report Extractor
The Report Extractor is a separate EGC plug-in that is used to extract data from the MDB into result tables that are presented in the GUI and can be printed or exported in a number of standard formats. The Report Extractor plug-in is also used by the DSM Engine to generate result sets on a scheduled basis.
Sector Server
The sector server is a component of UAM V4 that collects information from the attached agents and reports them to the UAM manager.
Glossary4
September 2007
OSIM and CADSMCMD
Scalability Server
The Scalability Server is a component of the DSM R11 architecture that acts as a distribution point for software delivery activities and a collection point for asset inventory.
Session Messaging (SM)

Session Messaging (SM) is a client-server layer that sits atop the DSM Messenger component. SM is provided in the form of a C-based interface DLL and a management daemon (CAF plug-in). SM is modular and utilizes many common components. It provides session management, encryption, compression, low-level authentication (X.509), high-level authentication (O/S or External), transactional calls and message forwarding.
Software Catalog
The Software Catalog is an agent plug-in, which allows you "self-service". With this wizard based interface, you can install or remove software on your computer from a library provided by the administrator.
TOS
DTS is implemented around an object model. These are the objects controlled by the Transfer Object Service (TOS).
Unicenter Asset Management (UAM)

Unicenter Asset Management (UAM) is one of the worlds leading Enterprise Asset Management products. It is a scalable enterprise class product and its management capabilities allow clients to build an inventory of IT assets in a database and deploy management policy on remote desktops. It has a very broad platform and protocol coverage, utilizes CA Common Services and integrates with Unicenter NSM and other CA desktop products.
Unicenter Remote Control (URC)

Unicenter Remote Control (URC) is a product that allows accessing and controlling a distant PC and its resources from any location as if you were locally logged on.
Unicenter Software Delivery (USD)

Unicenter Software Delivery (USD) is currently the worlds 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.
September 2007
Glossary5

DSM Adv Topics r11

Uploaded by

Copyright:

Available Formats

DSM Adv Topics r11

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DSM Adv Topics r11

Uploaded by

Copyright:

Available Formats

Unicenter Desktop and Server Management

Chapter 2: Component Details

Chapter 3: DSM Explorer

Chapter 5: Installation Topics

iv Desktop and Server Management Advanced Topics Guide

Chapter 6: Startup and Configuration

Chapter 7: Software Scanning

Chapter 8: Remote Control Connection

Chapter 9: Delivering Software

Chapter 10: OSIM

vi Desktop and Server Management Advanced Topics Guide

Desktop and Server Management Advanced Topics Guide

Chapter 2: Component Details

Chapter 2: Component Details

Desktop and Server Management Advanced Topics Guide

Chapter 2: Component Details 2- 3

Desktop and Server Management Advanced Topics Guide

Chapter 2: Component Details 2- 5

Query and Dynamic Group Evaluation

Desktop and Server Management Advanced Topics Guide

Chapter 2: Component Details 2- 7

Desktop and Server Management Advanced Topics Guide

Infrastructure Deployment Manager

Chapter 2: Component Details 2- 9

Common Object Manager

Desktop and Server Management Advanced Topics Guide

Chapter 2: Component Details 2- 11

Desktop and Server Management Advanced Topics Guide

Chapter 2: Component Details 2- 13

Data Transfer Service (DTS)

MS SQL Server Notes

Data Transfer Service (DTS)

Desktop and Server Management Advanced Topics Guide

Data Transfer Service (DTS)

Chapter 2: Component Details 2- 15

Data Transfer Service (DTS)

Useful commands for monitoring and debugging purposes are:

Desktop and Server Management Advanced Topics Guide

Data Transfer Service (DTS)

Transfer Object Server (TOS)

Chapter 2: Component Details 2- 17

Data Transfer Service (DTS)

Network Object Server (NOS)

Desktop and Server Management Advanced Topics Guide

Data Transfer Service (DTS)

Chapter 2: Component Details 2- 19

Data Transfer Service (DTS)

DTS Transfer Agent

Desktop and Server Management Advanced Topics Guide

Data Transfer Service (DTS)

Chapter 2: Component Details 2- 21

Data Transfer Service (DTS)

Desktop and Server Management Advanced Topics Guide

Data Transfer Service (DTS)

Installation and Configuration

Chapter 2: Component Details 2- 23

Data Transfer Service (DTS)

Desktop and Server Management Advanced Topics Guide

The Agent and DM Primer

The Agent and DM Primer