Unicenter® Desktop and Server
Mc® anagement
Advanced Topics R11.x
Legal Notice
This publication is based on current information and resource allocations as of its date of publication and is subject to change or withdrawal by CA at any time without notice. The information in this publication could include typographical errors or technical inaccuracies. CA may make modifications to any CA product, software program, method or procedure described in this publication at any time without notice.
Any reference in this publication to non-CA products and non-CA websites are provided for convenience only and shall not serve as CA’s endorsement of such products or websites. Your use of such products, websites, and any information regarding such products or any materials provided with such products or at such websites shall be at your own risk.
Notwithstanding anything in this publication to the contrary, this publication shall not (i) constitute product documentation or specifications under any existing or future written license agreement or services agreement relating to any CA software product, or be subject to any warranty set forth in any such written agreement; (ii) serve to affect the rights and/or obligations of CA or its licensees under any existing or future written license agreement or services agreement relating to any CA software product; or (iii) serve to amend any product documentation or specifications for any CA software product. The development, release and timing of any features or functionality described in this publication remain at CA’s sole discretion.
The information in this publication is based upon CA’s experiences with the referenced software products in a variety of development and customer environments. Past performance of the software products in such development and customer environments is not indicative of the future performance of such software products in identical, similar or different environments. CA does not warrant that the software products will operate as specifically set forth in this publication. CA will support only the referenced products in accordance with (i) the documentation and specifications provided with the referenced product, and (ii) CA’s then-current maintenance and support policy for the referenced product.
Certain information in this publication may outline CA’s general product direction. All information in this publication is for your informational purposes only and may not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA provides this document “AS IS” without warranty of any kind, including, without limitation, any implied warranties of merchantability, fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost investment, business interruption, goodwill or lost data, even if CA is expressly advised of the possibility of such damages.
Copyright License and Notice
This publication contains sample application programming code and/or language which illustrate programming techniques on various operating systems. Notwithstanding anything to the contrary contained in this publication, such sample code does not constitute licensed products or software under any CA license or services agreement. You may copy, modify and use this sample code for the purposes of performing the installation methods and routines described in this document. These samples have not been tested. CA does not make, and you may not rely on, any promise, express or implied, of reliability, serviceability or function of the sample code.
Copyright © 2007 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
Contents
Chapter 1: Introduction
References ...... 1-1 Providing Feedback ...... 1-2
Chapter 2: Component Details
The Engine ...... 2-2 Engine Startup ...... 2-4 Engine Tasks ...... 2-5 Managers ...... 2-9 Infrastructure Deployment Manager...... 2-9 Common Object Manager...... 2-10 The MDB ...... 2-11 MDB Installation ...... 2-12 Data Transfer Service (DTS)...... 2-14 DTS Transfers ...... 2-15 DTS Components ...... 2-16 The Agent and DM Primer ...... 2-25 Report Extractor...... 2-25 Architectural Overview ...... 2-26 Report Templates ...... 2-27 Communications ...... 2-29 Diagnosing Problems ...... 2-29 Web Admin Console (WAC)...... 2-31 WAC and AMS ...... 2-32 Diagnosing Problems ...... 2-32 Web Services...... 2-33 Things to Note...... 2-35 Diagnosing problems...... 2-35
Chapter 3: DSM Explorer
Architectural Overview ...... 3-1 Diagnostic Tips ...... 3-2 Common Plug-in...... 3-3 CCNF Plug-in ...... 3-5
September 2007 Contents iii References
Reading Configuration Policies...... 3-6 DM Deploy Plug-in ...... 3-8 Diagnosing Problems ...... 3-9 Directory Browser Plug-in...... 3-10 Directory Wizard ...... 3-10 Directory Synchronization...... 3-11 Directory Browsing ...... 3-12 Asset Manager (AM) Plug-in ...... 3-12 Software Delivery (SD) Plug-in...... 3-16 Remote Control (RC) Plug-in ...... 3-20 Things to Note ...... 3-23 OSIM Plug-in ...... 3-23
Chapter 4: CAF
What is CAF? ...... 4-2 OS Services ...... 4-5 Tracing ...... 4-5 Security ...... 4-9 Authentication ...... 4-10 Encryption ...... 4-12 Authorization (Object Level Security) ...... 4-13 Communication ...... 4-20 Streams ...... 4-20 The Messenger ...... 4-22
Chapter 5: Installation Topics
Infrastructure Deployment...... 5-2 Processes and Log files ...... 5-4 Stage to and Deploy from Scalability Server...... 5-5 Diagnosis Tips ...... 5-6 Frequently asked Questions ...... 5-7 Additional Considerations for r11.2 ...... 5-8 Upgrading from a Previous Release...... 5-12 Data Migration ...... 5-13 DSM and NAT ...... 5-20 Overview ...... 5-20 Scenario 1: Scalability Server as Proxy Router ...... 5-21 Scenario 2: Agent as CAM Proxy ...... 5-25
iv Desktop and Server Management Advanced Topics Guide September 2007 References
Chapter 6: Startup and Configuration
What Happens at Startup? ...... 6-1 Startup Under Windows ...... 6-4 Startup under Linux...... 6-6 Infrastructure Configuration ...... 6-8 Configuration Policy ...... 6-8 Activating Computer Configuration ...... 6-8 Enterprise and Domain Policies ...... 6-10 Property Storage ...... 6-10 Processes and Log Files ...... 6-14 Agent Registration ...... 6-15
Chapter 7: Software Scanning
Overview and Flow ...... 7-1 Processes and Log files ...... 7-3 A Closer Look at the Content Download Process...... 7-4 A Closer Look at the XML Generation Process ...... 7-5 A Closer Look at the Engine Transfer Process ...... 7-6 A Closer Look at the Scalability Server Transfer Process ...... 7-6 Using an Enterprise Server ...... 7-8 A Closer Look at the Import\Export Utility ...... 7-8 Diagnosis Tips ...... 7-10
Chapter 8: Remote Control Connection
Overview and Flow ...... 8-1 Processes and Log files ...... 8-3 Getting the Address Book ...... 8-3 Getting the Authority List ...... 8-4 Centralized User Validation ...... 8-6 Cached\Fail Safe Validation...... 8-7 Connecting to the Desktop ...... 8-7 Terminal Services Obstacles ...... 8-8 Displaying Confirmation Dialogs ...... 8-10 Starting Remote Control ...... 8-10 RCConfig and RCTrace ...... 8-11 Diagnosis Tips ...... 8-11
September 2007 Contents v References
Chapter 9: Delivering Software
Overview and Flow ...... 9-2 DTS Integration ...... 9-9 USD Shares...... 9-11 USD Directories ...... 9-12 USD Files ...... 9-14 MDB Tables ...... 9-15 Process, Trace and Log Files ...... 9-16 Install Packages and Trace Files...... 9-18 USD Logical Process Flows and Log Files ...... 9-19 Major Changes between 11.1 and 11.2 ...... 9-22 Collecting Information for Troubleshooting ...... 9-23 Additional DTS Considerations ...... 9-23
Chapter 10: OSIM
OSIM Architecture...... 10-1 Process and Log Files...... 10-4 Installation and Configuration ...... 10-5 Multiple Boot Server (BS) in a PXE broadcast network ...... 10-6 Prioritization of Boot Server with Remote Configuration ...... 10-6 Image Prepare System (IPS)...... 10-8 Example...... 10-9 Create Boot Images ...... 10-9 Register DOS Boot Images ...... 10-12 Create OS Image...... 10-13 Register the OS Image ...... 10-14 Prepare the Target for Network Boot...... 10-15 Boot the Target ...... 10-16 Change Selected PXE Target to Managed...... 10-16 Editing the Job Parameter...... 10-16 Activate the OS Installation Job ...... 10-17 Boot the Target to Execute the OS install job...... 10-17 Under the Hood ...... 10-18 Boot Image Tools and Templates ...... 10-18 Template Files and OS Types...... 10-22 Registering to Another Domain Manager ...... 10-27 Special Preparation for GHOST and PQIMG Based Images ...... 10-28 Upgrade Procedure for OS-SD packages ...... 10-28 OSIM Domain Manager Plug-in ...... 10-29 OS Installation Job States...... 10-29
vi Desktop and Server Management Advanced Topics Guide September 2007 References
OSIM (CSM) Data Base Design...... 10-30 OSIM Database Objects and Relationships ...... 10-33 Boot Server Components ...... 10-35 OSIM and CADSMCMD ...... 10-50 Architectural Overview ...... 10-51 Diagnosing Problems with CADSMCMD ...... 10-52 TargetComputer command ...... 10-54 Enhancements/Changes ...... 10-56 Example Scenarios...... 10-57
Glossary
September 2007 Contents vii
Chapter 1: Introduction
This guide provides a closer look at several key Unicenter Desktop and Server Management components and functions. It is intended to be used in conjunction with the product documentation and other supporting materials available through the Technical Support website.
This information is presented in a series of chapters and topics that cover product specific and shared aspects of Unicenter DSM. The chapters are intended to be self-contained and randomly accessible. Updates and revisions will be provided on an ongoing basis and will be clearly noted.
References
The following additional documents are referenced and should be consulted for further details:
Unicenter DSM r11.x – Implementation Guide
Unicenter DSM r11.x – Release Impact Guide
Inside Guides for Asset Management, Software Delivery and Remote Control
Product Readme files and online HELP
The most up-to-date technical guidelines and tips can also be found on the CA Support Online website (http:\\support.ca.com). In addition, best practice guidelines for both Unicenter DSM and its underlying database (the MDB) can be found at the following link:
http://supportconnectw.ca.com/public/impcd/r11/StartHere.htm
Included on this site is the Unicenter Desktop and Server Management Diagnostics Guide which includes basic troubleshooting procedures and a list of common symptoms and solutions.
Following is the direct link to the CA Messaging Troubleshooting Guide which contains information on diagnosing problems with CAM and CAFT, common components used by Unicenter DSM:
http://supportconnectw.ca.com/premium/unicenter30/infodocs/TEC418063.pd f
Note that this document requires a login to the SupportConnect site.
September 2007 Chapter 1: Introduction 1–1 Providing Feedback
Providing Feedback
This is the first edition of the Advanced Topics Guide. This document was produced in direct response to many requests for additional details regarding particular functions and component interactions provided in DSM. Feedback is welcome and can be sent to the following email address:
All feedback will be reviewed and considered for inclusion in future updates of these materials. Updates will be posted as they become available. If you have a technical question or if you require a more immediate response, you should consider opening an issue through CA Technical Support.
1–2 Desktop and Server Management Advanced Topics Guide September 2007
Chapter 2: Component Details
This chapter takes a closer look at the following DSM components:
Engine
Manager
MDB
DTS
Agent
Report Extractor
Web Admin Console (WAC)
Web Services
Both the DSM Explorer (and its plug-ins) as well as CAF are discussed in later chapters due to the extent of the information provided.
Note that this is not an exhaustive list of components and details regarding additional components may be added in the future.
These topics are also discussed in the following documents:
Implementation Guide (notably “Chapter 1: Understanding Unicenter DSM”)
DSM HTML Help Web Services Reference Guide
You should also consult the following links on the Implementation Best Practices site for further information:
Working with the MDB (includes information regarding the MDB and CORA):
http://supportconnectw.ca.com/public/impcd/r11/MDBMain/MDB_Frame.ht m
Working with your CMS Solution http://supportconnectw.ca.com/public/impcd/r11/Unicenter/CMS_Frame.h tm
Scalability Considerations (includes information regarding sizing and performance considerations)
http://supportconnectw.ca.com/public/impcd/r11/scalability/scalability_gui delines__udsm.htm
A full list of techdocs is also available from the following link:
September 2007 Chapter 2: Component Details 2–1 The Engine
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp
The Engine
The Engine is a multi-instance, multi-function, distributable component. Its primary focus is the maintenance of computers and related information. Logic is encapsulated into a number of Engine Tasks enabling them to be scheduled to run at regular intervals.
The DSM Engine supports the following tasks
Sector collect – inventory collection from Scalability Server
Data Replication – copying of key data between Domain and Enterprise databases
Dynamic Group Evaluation – Evaluation of the membership of non- static groups (e.g., query-based)
Query-Based Policy Evaluation – Evaluation of policy violators and execution of actions
Report Extractor Jobs – execution of scheduled report extractions
Query Evaluation – simple evaluation of a standalone query
Migration Sync – copy and transform of info from previous version implementations
Run Generic SQL
Run External exe
Architecturally, the Engine can be considered as part of the DSM Manager. Every DSM Manager contains at least one default Engine instance which is known as the “System Engine.” Additional Engine instances can be created on the primary DSM Manager machine or on other remote machines.
2–2 Desktop and Server Management Advanced Topics Guide 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. Engine started up by CAF 2. Instance name passed on command line 3. DSM Manager hostname read from comstore 4. Database Name, Type, Credentials and other details are obtained from Common Manager
5. Database is opened 6. Jobs assigned to Engine are read 7. Work begins!
2–4 Desktop and Server Management Advanced Topics Guide 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 Server’s “Unit” area. This enables the agent to “find itself” the next time it connects to the Scalability Server.
Next, the Engine processes all the information provided by Agents in the “Collect” area. The information collected can take various forms:
Inventory (Hardware/template information)
Software inventory (Software Found based in signature files, heuristic found software)
Configuration Files (i.e. Autoexec.bat or other ini files configured to be backup by the UAM system)
Job Status
Module Status
Time Stamps (Last Execution date)
Usage (Metering) Inventory
September 2007 Chapter 2: Component Details 2- 5 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.
2–6 Desktop and Server Management Advanced Topics Guide 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 Chapter 2: Component Details 2- 7 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.
2–8 Desktop and Server Management Advanced Topics Guide 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 re- authentication. Encryption key generation is managed through the dmkeydat.pri and dmkeydat.pmr files which are found in the DMdeploy/bin/ folder. Dmkeydat.pmr must be transferred to the target systems before deployment can be achieved.
The deployment library is kept on the manager machine under the following locations:
For Windows:
For Linux: $CA_ITRM_BASEDIR/Packages
The \Public subdirectory contains the payloads which can be deployed (selectable in the wizard). The
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 Chapter 2: Component Details 2- 9 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:
2–10 Desktop and Server Management Advanced Topics Guide 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 Chapter 2: Component Details 2- 11 The MDB
The MDB schema includes the database objects used by CA products and their components. These include tables, columns, views, triggers, rules and procedures. The MDB manages operational and transactional data, as well as the analytical data used for intelligence and data mining.
The integration point for all products is the common asset. Common registration of assets is handled by the CORA API.
Depending on a company’s business needs, as well as its organizational and geographical structure, you can use a single MDB or multiple MDBs; both approaches utilize the same schema.
In DSM MDBs reside at the Domain Manager and the Enterprise manager levels, though they are not necessarily co-located on the same physical machine as the manager.
MDB Installation
Ingres is supported on Windows and Linux while MS-SQL Server is supported on Windows only.
Ingres Notes
When using an Ingres-based MDB, keep the following in mind:
Ingres will be installed by the DSM installer if not already installed
2–12 Desktop and Server Management Advanced Topics Guide 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. The Install kit collects installation attributes (for example, which database server is to be used).
2. The Install kit uses the dbinfo.dll component to check certain prerequisites such as:
Has the MDB already been installed?
Is that MDB version OK?
Is MDB already initialized (in other words, has the DSM Domain already been installed)?
3. The Install kit calls the dsmMdbPatch.bat script to apply MDB patches provided by Support.
4. The Install kit calls a post_install.bat/.sh script to add a row into the ca_settings table that will be used as tag indicating that the MDB schema is OK.
5. The Install kit calls the dbDataAfterCopy.dll to initialize and populate the MDB with some basic content. The dbDataAfterCopy also sets the DB credentials to the comStore and the DSM is registered in the ca_application_registration table.
6. At the end of the installation the Install kit calls the data_install.bat script to load additional content, such as queries, report data and software definitions, into the MDB.
Note: It may take some time to load software definitions but this step is only done when the Asset Management component is installed.
The procedures used under Linux are very similar – the only major exception is that, under Linux, dbInfo and dbDataAfterCopyApl are processes and not libraries.
September 2007 Chapter 2: Component Details 2- 13 Data Transfer Service (DTS)
MS SQL Server Notes
If the MDB is to be installed under MS-SQL Server you must ensure that SQL Server already installed and properly configured before the MDB installation begins. The MDB schema will be installed automatically by the DSM installer.
During installation on MS SQL Server an additional library, mssqllogin.dll, is used to do the following:
Check if MDB is already installed
Create users (grant user access)
check server collation name
Note that if the MDB is installed on a machine that is remote from the Domain Manager, a trusted connection must be established between the two machines. One way to accomplish this is to have them reside in the same Windows domain.
Data Transfer Service (DTS)
The Data Transfer Service (DTS) is used by Software Delivery to manage the distribution of software through the network.
In USD terms a “USD job” is a “DTS transfer job” and the targets of those jobs are considered “DTS Transfers.” In the following screen shots you can see how DTS appears in the UI (the image on the left is r11.1 and the image on the right is from r11.2):
2–14 Desktop and Server Management Advanced Topics Guide September 2007 Data Transfer Service (DTS)
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 Chapter 2: Component Details 2- 15 Data Transfer Service (DTS)
Broadcast/Multi-cast This type of transfer requires WorldView to be configured. Broadcast/Multi- cast similar distributions are similar to fan-out distributions, however, the data is sent to targets using bcast/mcast processes
Point-to-point This type of transfer is usually used when there’s only one transfer in a transfer job.
You can use the DtsCli to view and monitor the transfers. For information on command syntax, execute the following:
Dtscli –h
Useful commands for monitoring and debugging purposes are:
dtscli –t method=status id=TheId dtscli –t method=status id=TheId method_parameters=implementation dtscli –j method=status id=TheId dtscli –j method=status id=TheId method_parameters=implementation dtsCli –j method=status id=TheId method_parameters=transfers
DTS Components
DTS consist of the DTS Transfer Agent, DTS Command Line Interface (DTSCLI) and three “servers” – the Network Object Server (NOS), Transfer Object Server (TOS) and Schedule Object Server (SOS) – that are distributed across the DSM r11 architecture as follows:
2–16 Desktop and Server Management Advanced Topics Guide September 2007 Data Transfer Service (DTS)
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 Chapter 2: Component Details 2- 17 Data Transfer Service (DTS)
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
2–18 Desktop and Server Management Advanced Topics Guide September 2007 Data Transfer Service (DTS)
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 Chapter 2: Component Details 2- 19 Data Transfer Service (DTS)
Right click on the DTS BPV and select DTS Auto-discovery
Integration with WorldView includes the ability to associate a CCS Calendar with a DTLink. This can be used to specify when the link can be used – DTS will suspend and resume transfers based on when the calendar is enabled.
The use of Dynamic Containers is also provided through WorldView integration, which includes limited dynamic routing functionality.
In the r11.2 release you should note that:
The TOS’s route lookup is no longer synchronous
The TOS asks for the routes of all transfers in the transfer job, not just one at a time
The NOS can be responsive to other route lookup requests
The transfer job’s status at this time is: Calculating
DTS Transfer Agent
The DTS Transfer Agent consists of the following components:
Following are the methods by which the DTS Agent receives a transfer request, connects to the responder and performs the data transfer:
2–20 Desktop and Server Management Advanced Topics Guide September 2007 Data Transfer Service (DTS)
Communication between TOS and Agent (Initiator) occurs via Session Messaging. Encryption and compression are used.
Communication between the Agent and the TOS occurs via Session Messaging, Store and Forward.
Communication between the Agents uses the Networker by default, although other protocols can be configured via WorldView.
The Networker uses the port-multiplexer and provides encryption and compression capability. When sending control messages (for example, transfer requests), the Networker’s encryption and compression are used, however, when sending data, they are not.
The following Agent Filters are provided:
Read File Filter: Applied to the file before it is sent
Write File Filter: Applied to the file after it has been received
Read Parcel Filter: Applied to the data stream as it is being sent
Write Parcel Filter: Applied to the data stream as it is being received
Other DTS filters used by USD in DSM include:
Directory tree (file filter)
Encryption filters (these have to be configured)
External Filters include Sddtfilt which is a UD filter executed by DTS after the data transfer has completed.
September 2007 Chapter 2: Component Details 2- 21 Data Transfer Service (DTS)
The following types of intermittent transfers are supported:
Transfers to agents that are off-line
Transfer’s state change to Interrupted
Once the agent sends a message to the TOS (via the port multiplexer) that it has restarted, interrupted transfers are resumed. USD’s representation of the state is ‘active’.
Full support is provided for the transfers of large files. This includes files that are larger than 2GB, directories whose combined size is larger than 2GB or that contains files larger than 2GB. The file system, however, has to support large files. HP file systems, for example, can be mounted as 64 bit or 32 bit.
2–22 Desktop and Server Management Advanced Topics Guide September 2007 Data Transfer Service (DTS)
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 Chapter 2: Component Details 2- 23 Data Transfer Service (DTS)
If a previous DTS release is detected it will be upgraded. DTS is backwards compatible, however. Transfers between different agent versions are supported. In the event of a partial (“staged”) upgrade, for example, when there is a version 3 manager and agent followed by an r11 Agent install, only the agent will be upgraded.
During an upgrade, the install location is not changed. Otherwise, the DTS components will be installed as follows:
Program files\ca\sharedcomponents\dts
Program files\ca\sc\dts
\dta\status is used for the DTS Agent’s checkpoint restart files
\dta\staging is used as a temporary folder to hold data before file filters are applied
In r11.2 these directories are not below the DTS install location (Program files\ca\dsm\dts).
Log files are not kept in the DTS installation directory. Rather, they are installed in the Program Files\dsm\logs directory. This includes the following log files:
TRC_DtsAgent_n.log (Master DTS Agent)
TRC_DtsAgentx_n.log (Slave DTS Agent)
TRC_DtsTOS_n.log (TOS log)
TRC_DtsNos_n.log (NOS log)
TRC_DtsSos_n.log (SOS log)
TRC_DTS_n.log (Anything that uses the DTS API)
Sometimes it can be difficult to see the DTS trace messages. For example:
141206-13:48:25.0164333L|000548|00000b44|DtsAgent0 |CCFNetwork::Send|CCFNetwork.cpp |000885|DETAIL | m_encryptOn=<0> MSGHEADER_GET_ENCRYPT=<0> 141206-13:48:25.0818844L|000548|00000b44|DtsAgent0 |dtsPWIEXT_Send_D|PWIEXT.c |000566|DETAIL | 524318 141206-13:48:25.0821777L|000548|00000b44|DtsAgent0 |dtsEQP_Outstandi|eqp.c |000400|DETAIL | Event <503> found in event queue for transfer
Note, however, that all DTS trace statements have the function name (column 5) prefixed with “Dts”.
2–24 Desktop and Server Management Advanced Topics Guide 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:
It is NOT a caf plug-in (because it installs CAF).
Primer install images are in the payload library, in the “Private” area (or possibly on an FTP server, mainly when deploying to *nix).
It can be installed automatically (pushed out by deployment manager) or installed manually (from DVD, login script, etc.). Information on manual install can be found in the Implementation Guide.
To establish connection with manager, an encryption public key must be obtained from the manager and placed in the expected location on the target. This proves that the deployment user has authority to install software.
Report Extractor
The Report Extractor is a separate EGC plug-in that is used to:
extract data from the MDB into result tables
present the results in the GUI
print the results
export the results in a number of standard formats
provide data on demand (for example, for portals and web servers)
The Report Extractor plug-in is also used by the DSM Engine to generate result sets on a scheduled basis.
The implementation includes a large number of canned reports, covering all functional areas of the suite as well as extensive features for designing new reports and data extracts.
The inner workings of the reporter feature generic data extraction and handling based on tables, columns and links, but knowledge about the product’s data model or implementation is not necessary to use the Report Extractor.
September 2007 Chapter 2: Component Details 2- 25 Report Extractor
Architectural Overview
The following graphic depicts how the Report Extractor fits into the general architecture:
Print Export User EGC 3.0 modules
Application DSM Reporter GUI Scheduled Reports Win: gui_rep.dll Win: gui_rep_exec.dll Linux: lib_rep.so
AM Data Access Manager AM Data Classes Security
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.
2–26 Desktop and Server Management Advanced Topics Guide 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 Chapter 2: Component Details 2- 27 Report Extractor
Following is a model of report results:
Here you can see the sequence in which reports are generated:
2–28 Desktop and Server Management Advanced Topics Guide 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\
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:
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:
Specify the DETAIL log level for CF and CSTACK to get all information for infrastructure components and dependencies. For a more concise reporter- specific log file, set reporter/AM at INFO level and others at WARN level:
cftrace set -f CSTACK -l WARN cftrace set -f CF -l WARN cftrace set -f CSTACK -mp "(Reporter|amlog)" –l INFO
September 2007 Chapter 2: Component Details 2- 29 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 break- poin t to inspect them before they are deleted.
2–30 Desktop and Server Management Advanced Topics Guide September 2007 Web Admin Console (WAC)
Web Admin Console (WAC)
The Web Admin Console (WAC) follows the MVC design pattern. It supports and relies on several technologies to supply the implementation of portions of the design. The following graphic provides an architectural overview of WAC:
WAC is shipped as a WAR file “wac.war” (zip) which is expanded automatically when Tomcat starts during the install. This enables DSM to modify configuration settings within the expanded files. This process is managed through WacAfterCopy .
Although Tomcat is installed into the common SharedComponents folder the Tomcat configuration files are installed into DSM’s own “Web Console” folder and run up its own instance of Tomcat.
Tomcat compiles jsp files at runtime into the Web Console\work folder. On occasion, if you modify jsp files the changes may not be picked up unless you delete the work folder.
Online help is expanded from zip file in CVS and then compressed into wac.war file.
September 2007 Chapter 2: Component Details 2- 31 Web Admin Console (WAC)
WAC and AMS
AMS displays Discovered and Owned inventory and is launched embedded, and in context, in WAC and DSM Explorer.
Web Services are used to create, configure, stop and restart software jobs and to retrieve product functionality based on what is installed on the manager (i.e., SD, AM or RC). This determines what is displayed by WAC. Web services are also used to retrieve Query results.
A separate web application is installed by DSM installer into WAC’s Tomcat instance. The DSM Installer just calls AMS’s installer.
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:
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:
Detailed tracing for AMS is set through the following file:
CA\Unicenter DSM\Web Console\webapps\AMS\WEB-INF\classes\log4j.properties
Change the following line:
log4j.rootCategory=ERROR, stdjlog
to read
log4j.rootCategory=DEBUG, stdjlog
Detailed tracing for WAC is defined through the following file:
CA\Unicenter DSM\Web Console\webapps\wac\WEB- INF\classes\com\ca\wac\config\waclog.properties
Change the lines that read:
log4j.logger.com=ERROR
2–32 Desktop and Server Management Advanced Topics Guide 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 Chapter 2: Component Details 2- 33 Web Services
Any errors raised by the high level API will be caught by the web service API and converted into a SOAP fault and sent back to the client.
The Highlevel API connects from webservices API layer to lower level client api’s. The primary purpose of this layer is to wrap the lower level API’s.
The purpose of the high level API is to present a standard interface to each of the lower level API’s. The high level API has no knowledge of web services etc. The interface is exposes is a C interface. The web service API layer is the bridge between the standard C high level API and mod_gsoap layer. The webservice API layer is gsoap dependent - in other words it uses gsoap constructs and is the layer called by gsoap.
When an HTTP XML message arrives at the web server it is routed to mod_gsoap.dll (via the url). The XML message (a Simple Object Access Protocol – SOAP) message gets converted into a function call onto Webservicesapi.dll.
The webservicesapi.dll performs any necessary validation and then calls the high level API function, which exposes a standardized C interface. This standardizes differences between lower layers.
Following is high level overview of the architecture on Linux using Apache Web Server. As you can see the runtime structure used by Apache is different than that used by IIS.
2–34 Desktop and Server Management Advanced Topics Guide 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://
You must use a GET request only for fetching WSDL ! see WebWare gsoap ISAPI module documentation for more details.
Then, type:
http://
Result…
mod_gsoap Apache SOAP Server Error
Only POST allowed as request for SOAP! Please see the documentation at WebWare for details.
This will establish that you have basic connectivity to the web server and gsoap layer. If this does not work then there is either a problem in IIS or in connectivity with gsoap
Check the webservice log file located in logs directory
Log filename is TRC_CF_WEBSERVICES_X.log
September 2007 Chapter 2: Component Details 2- 35
Chapter 3: DSM Explorer
This chapter takes a closer look at the DSM Explorer interface as well as the various plug-ins that are used. Additional details regarding other DSM components can be found in the previous chapter.
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
Architectural Overview
The DSM Explorer is a single EGC framework-based Admin GUI. It consists of the framework itself, a common plug-in and a number of product specific plug- ins. The DSM Explorer provides a homogenized view and operation of all DSM products in which no product separation is apparent. As DSM products are purchased and installed the GUI simply becomes richer and more powerful.
The EGC framework is a proven Win32 solution. It provides a basic tree/listview interface as well as numerous other common features. Product specific functionality is added via the concept of EGC plug-ins (DLLs which implement and exploit well defined programming interfaces).
The following graphic demonstrates the architecture that is used:
September 2007 Chapter 3: DSM Explorer 3–1 Diagnostic Tips
The EGC provides the basic explorer framework. This includes the treeview, listview, html view, tool bar, application menus as well as all the controls (widgets).
The plug-ins create and populate the controls. The Common plug-in provides the top level tree hierarchy and most of the cross product functionality (with the exceptions noted as blue/violet in the above graphic). All the other plug- ins add features and functions to the nodes, portals and menus that are provided by the common plug-in.
Visible functionality is controlled by the DSM components installed on the client and the manager
Diagnostic Tips
Most plug-ins write to the standard DSM trace file which is: TRC_GUI_
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\
3–2 Desktop and Server Management Advanced Topics Guide 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_
EGC3.0_
To display EGC node information select the node and press Ctrl+Alt+Shift+O
Common Plug-in
The purpose of the common plug-in is to glue the product specific plug-ins together in a common tree and provide common functionality and features. It provides the following:
A hierarchical representation of common data
Basic management services like grouping of objects
Support to forward control to product specific plug-ins
Common menu handling
September 2007 Chapter 3: DSM Explorer 3- 3 Common Plug-in
HTML interface for displaying basic information from relevant sources / products.
Seamless connectivity and security across managers
The following nodes are provided by the common plug-in:
Here you can see an example of the UI dialogs provided by the Common plug- in:
3–4 Desktop and Server Management Advanced Topics Guide 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 Chapter 3: DSM Explorer 3- 5 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:
3–6 Desktop and Server Management Advanced Topics Guide 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 Chapter 3: DSM Explorer 3- 7 DM Deploy Plug-in
When this node is selected an HTML page is displayed on the right hand side.
On the left it shows the policies that have been applied directly to this asset. In this example it is a policy call “UK Users”.
Below that it shows the policies that have been inherited. These policies have been applied to groups that this asset is a member of.
Details for the reported configuration that the CCNF agent returns from the agent computer can be viewed in a separate dialog.
A list of scheduled configurations is provided on the right hand side along with a list of any configurations which have failed.
In this example you can see a configuration that contains two policies. Because each contains different values for the same settings, the CCNF manager cannot determine which value to use – resulting in a conflict error. This error message instructs the user as to which parameters are causing the conflict so that the error can be remedied quickly.
DM Deploy Plug-in
The DSM Explorer provides access to the enhanced deployment technology available in DSM r11. The access is presented in the form of a deployment wizard which itself is an EGC plug-in.
The Deployment plug-in implements the following two nodes in the DSM Explorer’s Control Panel:
3–8 Desktop and Server Management Advanced Topics Guide 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 Chapter 3: DSM Explorer 3- 9 Directory Browser Plug-in
Directory Browser Plug-in
The Directory Browser plug-in provides support for browsing directory hierarchies. It includes the following:
Directory wizard
Directory synchronization configuration
Directory browsing
This particular plug-in is used by other plug-ins to manage their directory browsing such as:
Query designer
Security profiles
Deployment
Reporting
Directory Wizard
The Directory wizard consists of eight HTML pages that are used to specify directory details including:
Directory name
Server (which it attempts to resolve from directory name)
Port – default 389
User credentials
Base DN (which it attempts to resolve from directory name)
Directory schema to use
3–10 Desktop and Server Management Advanced Topics Guide September 2007 Directory Browser Plug-in
It is also used to edit schema and create directory objects. Following is an example of the Add Directory function dialog:
Directory Synchronization
Directory synchronization controls consists of two HTML pages which can be used to modify the directory synchronization Engine jobs.
September 2007 Chapter 3: DSM Explorer 3- 11 Asset Manager (AM) Plug-in
The user clicks Configure to change settings for job frequency and synchronization orders. These changes are saved in command line parameters for the Engine job.
Directory Browsing
This function provides directory browsing capabilities to other GUI plug-ins.
Asset Manager (AM) Plug-in
The Asset Manager (AM) Plug-in provides both AM specific and common functionality. It manages:
Hardware Inventory
Software Inventory
Custom Software Definitions
Asset Jobs
Queries
Query and Event Based Policies
Engine Portal
External Assets
For example:
3–12 Desktop and Server Management Advanced Topics Guide September 2007 Asset Manager (AM) Plug-in
Here you can see the type of information provided:
September 2007 Chapter 3: DSM Explorer 3- 13 Asset Manager (AM) Plug-in
3–14 Desktop and Server Management Advanced Topics Guide September 2007 Asset Manager (AM) Plug-in
September 2007 Chapter 3: DSM Explorer 3- 15 Software Delivery (SD) Plug-in
Software Delivery (SD) Plug-in
The SD plug-in is comprised of the following two files:
gui_sd.dll which contains all the functionality
gui_sd_res.en which is the English language locale. This contains the dialogs, icons and localized text
The SD plug-in provides the following controls:
Software Package Library
Software Jobs / Distributions
Software Policies
Delivery Engine
Software Job Management (configuration)
Here you can see the related controls on the DSM Explorer:
3–16 Desktop and Server Management Advanced Topics Guide September 2007 Software Delivery (SD) Plug-in
These controls are available through the Start menu as follows:
September 2007 Chapter 3: DSM Explorer 3- 17 Software Delivery (SD) Plug-in
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:
3–18 Desktop and Server Management Advanced Topics Guide September 2007 Software Delivery (SD) Plug-in
It also includes the following wizards:
Software Deployment Wizard
Software Staging Wizard
Software Policy creation Wizard
Software Publishing Wizard.
September 2007 Chapter 3: DSM Explorer 3- 19 Remote Control (RC) Plug-in
Remote Control (RC) Plug-in
The RC plug-in is comprised of the following two files:
gui_rc.dll which contains all the functionality
gui_rc_res.en which contains the English language locale. This contains dialogs, icons and localized text.
Here you can see the controls that are added to the DSM Explorer:
This includes:
Active Sessions – This is a list of current sessions that this manager has authenticated.
Previous Session – A log of sessions that have now completed.
Root Address book permissions – An area to define RC permissions that will be applied to all computers in RC address book groups.
You can also define Remote Control Permissions on each group by adding users to the Remote Control Permissions folder within the group’s details section.
3–20 Desktop and Server Management Advanced Topics Guide September 2007 Remote Control (RC) Plug-in
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 Chapter 3: DSM Explorer 3- 21 Remote Control (RC) Plug-in
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:
3–22 Desktop and Server Management Advanced Topics Guide 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 Chapter 3: DSM Explorer 3- 23 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)
3–24 Desktop and Server Management Advanced Topics Guide 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 3: DSM Explorer 3- 25
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 4–1 What is CAF?
What is CAF?
CAF provides a common, extensible runtime environment for all DSM program code. In its most basic form CAF provides the following general functionality:
Perceived single service CAF runs as a single service on a computer and acts as the hub for all of the Agent, Scalability server and Manager processes. CAF does not make distinctions between the types of entities plugged into it. They all support the same basic interface and make use of the same common components.
Process control CAF provides the following mechanisms for starting, stopping, pausing and restarting plug-ins:
– by networked API – by command line (which calls API) – by periodic start as defined by the scheduling component. – By auto-restart. if a plug-in such as an agent fails and is terminated by the operating system, the framework can restart it (as defined by policy).
Messaging An out of process messaging plug-in provides secure transmission of information. This is implemented using CAM. Messages can be routed directly to a process or to a plug-in via the framework's persistent process. In the latter case the framework will detect the intended recipient plug-in and route the message there via the plug-in's interface.
Stream communications with port multiplexing
Scheduling An in-process scheduling plug-in can be used to start/stop other plug-ins or send messages to plug-ins.
Registration An in-process registration plug-in is used to register end systems with a DSM Domain Manager via a Scalability Server, and basic inventory is collected and passed up during the registration process.
The CAF framework is dynamically extensible via the concept of plug-ins and the common component library (CCL).
CAF can be many things:
Periodic agent: running scheduler only. At given times it runs an agent via plug-in load/unload
Manager: It runs with a set of manager plug-ins and the messenger loaded, both persistently
4–2 Desktop and Server Management Advanced Topics Guide September 2007 What is CAF?
Remote control agent: It runs with the port multiplexer. When a URC viewer connects to it’s port, CAF starts up the URC host agent which then accepts the connection
Sector server: It runs with the AM Scalability Server plug-in running persistently
Much more: It runs with the AM metering agent, RC host, the registration plug-in, messenger and an AM Scalability Server plug-in, all loaded persistently
The major packages and components which are listed below are more fully described in other sections.
CAF: The DSM Common Service. To the user, this is the “CA Unicenter DSM r11 Common Application Framework” service. The service hosts the actual DSM Agents, Scalability Servers and Managers.
DSM Plug-in: a DSM plug-in is a component which contains DSM conformant functionality. A plug-in may also delegate the functionality to a “worker” process whose lifetime it manages.
Custom Plug-in: this is intended for any other functionality which is not strictly DSM conformant process.
September 2007 Chapter 4: CAF 4- 3 What is CAF?
DSM worker processes: the set of DSM processes covering Agents, Scalability Servers and Managers. These are managed by instances of the DSM plug-in. Note also that only a subset of Manager worker processes are dependent on the MDB.
Common Component Library (CCL): a set of components implementing shared, re-usable functionality, including: messaging, tracing, encryption, compression etc.
Common Config (CCNF): a component which accesses a store of configuration information. This is actually part of CCL but is shown separately here because it is critical to CAF. The config component provides a consistent means of getting and setting configuration values. The storage location of the values themselves is hidden from the client of the component. The values may be supplied at install time and may be locally or centrally managed.
Manager Proxy: this component is used to provide management capabilities for agents. It handles manager location, registration and commands sent by a manager (described elsewhere).
Scheduler: Manages scheduled execution of plug-ins.
Port MUX: the port multiplexer. This provides a single listening port for TCP and another for UDP connections. When a connection is made (for example, from the URC viewer), the multiplexer detects which plug-in the connection is intended for and gives it a new socket with which to continue. This allows multiple plug-ins to share the same port and is intended to make life easier for the customer when configuring firewalls.
Messenger: the messaging component. This is used for connectionless reliable and secure transfer of information. All messages from managers, GUI’s and command line tools use the messenger.
MDB: The common CA database. Only a subset of Manager worker processes uses this.
DSM Explorer: this is the common DSM admin GUI. It provides a single view of the DSM system.
System Tray Applet: This provides a single icon on the system tray and allows the user to see the status of CAF and issue some commands.
CLI: this is supported by caf.exe itself and is used by administrators to start, stop or interrogate plug-ins and consequently any worker processes they are associated with them. The command line sends messages to the service using the messenger component.
On Windows CAF runs as a windows service (CAF.EXE) called the “CA DSM Common Application Framework” while on Linux\UNIX it runs as a daemon (caf).
CAF provides a command line which allows administrators local and remote access to CAF functionality. The syntax is as follows:
4–4 Desktop and Server Management Advanced Topics Guide 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
where:
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
CAF Plug-in Binary Processor Plug-in Log file
- CAF CAF_CMD TRC_CF_CAF_CMD.log
- Caf CAF_CMD TRC_CF_CAF_CMD.log
- CAF CAF_SERVICE TRC_CF_CAF_SERVICE.log
- cafC CAF_SERVICE TRC_CF_CAF_SERVICE.log
systray cfSysTray SYSTRAY TRC_CF_SYSTRAY.log
ccsmagt - Ccsmagt TRC_CSMAGENT.log
ccnfagent ccnfAgent CcnfAgentWorker TRC_CCNFAGENT.log
pmux (lib) cfPmuxPlugin cfPmuxPlugin TRC_CFPMUXPLUGIN.log
smserver Cfsmsmd CFSMSMD TRC_CF_CFSMSMD.log
- Dmscript DMSInterpreter TRC_DMSINTERPRETER.log
cfnotsrvd Cfnotsrvd Cfnotsrvd TRC_CF_NOTSRVD.log
cfftplugin cfFTPlugin cfFTPlugin TRC_CF_FTPLUGIN.log
cfregister (lib) cfRegister cfRegister TRC_CF_REGISTER.log
- cfUsrNtf cfUsrNtf TRC_CF_USRNTF
sdagent sd_jexec SDAgent TRC_USD_SDAGENT.log
- sd_msiexe SDMSIExe TRC_USD_SDMSIEXE.log
amagent amagentsvc amagent TRC_AMAGENT.log
amagent amagent amagent TRC_AMAGENT.log
amswmagtu amswmagt UAM TRC_UAM.log
amswmagtw amswmagt UAM TRC_UAM.log
- Amsoftscan UAM TRC_UAM.log
ampmagent capmuamagt amperfagent TRC_AMPERFAGENT.log
rchost rcHost _HOST TRC_URC_HOST.log
4–6 Desktop and Server Management Advanced Topics Guide September 2007 OS Services
CAF Plug-in Binary Processor Plug-in Log file
rchost rcHost URC TRC_URC.log
ttsagent tngdta dtsagent TRC_DtsAgent.log
dtsmg tngdtmg dtsagent TRC_DtsAgent.log
dtsbrowser tngdoba dtsbrowser TRC_DtsBrowser.log
- - BACKUP_AGENT TRC_BACKUP_AGENT.log
- (lib) ammsapi Metering API TRC_AMMeterAPI.log
ccsmsvr- ccsmsvrd ccsmsvr TRC_CSMSERVER.log
cserver cserver cserver TRC_CSERVER.log
- sd_sscmd SSCMD TRC_USD_SSCMD.log
sdmpcserver sdmpcworker sdmpcworker TRC_USD_PMCWORKER.log
sdserver sd_server SDServer TRC_USD_SDSERVER.log
amms amms Metering Server TRC_AMMMS.log
amrss amrss RSS TRC_AMRSS.log
rcserver rcServer _SERVER TRC_URC_SERVER.log
- - BACKUP_SERVER TRC_BACKUP_SERVER.log
dtssos tngdtsos dtssos TRC_DtsSos.log
dtsnos tngdtnos dtsnos TRC_DtsNos.log
dtstos tngdttos dtstos TRC_DtsTos.log
rcmanager rcManSrv _MANSRV TRC_URC_MANSRV.log
- (lib)sqlexec sqlexec TRC_DBAPI.log
highlevelapi DSMHLAPI TRC_HLAPI.log
- ccnfclient ccnfclient TRC_CCNFCLIENT.log
ccsmact ccsmactd ccsmact TRC_CSMACT.log
ccsmapi ccsmapid ccsmapi TRC_CSMAPI.log
tomcat java cfjvmplugin TRC_CF_JVMPLUGIN.log
- webservieapi.dll DSMWebServices TRC_CF_WEBSERVICES.log
cmcontdiscover cmContDiscover cmContDiscover TRC_CF_CMCONTDISC.log
dmdeploy DMDeploy DMDeploy TRC_CF_DMDEPLOY.log
cmobjectmanager cmObjectManager cmObjectManager TRC_CMENGINE.log
- cmDirEngJob cmDirEngJob TRC_CMDIRENGJOB.log
September 2007 Chapter 4: CAF 4- 7 OS Services
CAF Plug-in Binary Processor Plug-in Log file
ammanager amObjectManager AMManager TRC_AMMGR.log
sdmgr_tm sd_taskm tm TaskMan TRC_USD_TASKMAN.log
sdmgr_dm sd_dialog_m DialogM TRC_USD_DIALOGM.log
sdmgr_api sd_apisrv ApiServer TRC_USD_APISERVER.log
sdmgr_im sd_taskm im InstMan TRC_USD_INSTMAN.log
- sd_ahdcmd sd_ahdcmd TRC_USD_SDAHDCMD.log
sdmgr_ft sd_mgr_ft SDMgrFT TRC_USD_SDMGRFT.log
sd_dtpush SdDtPush TRC_USD_SDDTPUSH.log
sd_dtsft DtsFT TRC_USD_DTSFT.log
BACKUP_WORKER TRC_BACKUP_WORKER.log
BACKUP_MANAGER TRC_BACKUP_MANAGER.log
Migration_CSM TRC_MIGRATION_CSM.log
Migration_USD TRC_MIGRATION_USD.log
rcManagerR11Migra Migration_URC TRC_MIGRATION_URC.log tion
Migration_UAM TRC_MIGRATION_UAM.log
(lib)amRsapi RSAPI TRC_AMRAPI.log
dmsedit DMSEditor TRC_DMSEDITOR.log
dsmreporter REPORTER TRC_REPORTER.log
dsmgui GUI TRC_GUI.log
(lib) dmapi DMAPI TRC_CF_DMAPI.log
BACKUP_MGUI TRC_BACKUP_MGUI.log
(lib) gui_rc _EXPLORER TRC_URC_EXPLORER.log
(lib) gui_rcView _VIEWER TRC_URC_VIEWER.log
(lib) gui_rcReplay _REPLAYER TRC_URC_REPLAYER.log
(lib) rcHostGUI _HOSTGUI TRC_URC_HOSTGUI.log
(lib) gui_rcWrap _WRAPPER TRC_URC_WRAPPER.log
rcUtilCmd(lib) _UTILCMD TRC_URC_UTILCMD.log
4–8 Desktop and Server Management Advanced Topics Guide 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 – “
Where
– winnt: Primarily Windows NT domain and local SAM’s. – unixl: Unix local account (shadow password file) – ldap: LDAP directory access – nds: NDS directory access – x509cert: X.509 V3 certificates and
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:
4–10 Desktop and Server Management Advanced Topics Guide 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 DC’s) or local machine (Unix) – Trusted – explicitly trusted domains
Note: There is no GUI mechanism to support implicitly trusted domains. These must be added using cfspsetpass – a supported tool in r11.2.
The security components are responsible for generating the URI’s which represent the current machine and the logged on user(s) in varying namespaces.
These only work where the URI’s can be reliably generated:
NT
Unix
NDS (with NW client support)
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-to- peer communication.
3DES session key is integrated in the Networker. It is used by CFFTPlug-in (NOSless file transfer), DTS agent, and RC host – viewer (supports legacy negotiation for URC 6.0 connections)
Run Time Requirements include Etpki 2.3.3. (OpenSSL 0.9.7d):
On Windows: ipthread.dll, libetpki2.dll, libetpki2_thread.dll
4–12 Desktop and Server Management Advanced Topics Guide 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 Chapter 4: CAF 4- 13 Security
Ownership An object is either owned by a user or is said to be unassigned. When a background process creates an object, that object is usually unassigned. If you create an object, your user ID is the owner of the object. As the owner of an object you inherit all permissions associated with the “Owner” security profile. “Owner” is a special security profile, created at install time and set to Full Access by default.
Take Ownership A user gets the ownership of an object
Access Control
Authorization concerns itself with the rights and privileges associated with an authenticated entity (typically a logged in user, but could be a machine/process/application). The common authorization sub-system covers class level, group level, object level and functional security.
It is based on the concept of an Access Control Entry (ACE), which is a bit- oriented integer. The following eight bits are currently used:
V View bit, allows you to show objects. C Create bit, allows you to create objects. R Read bit, allows you to read sub-objects of an object. W Write bit, allows you to change and object. X Execute bit, allows execution, depends on object type. D Delete bit, allows you to delete objects. P Permission bit, allows you to change the ACE itself. O Ownership bit, allows you to take ownership of an object.
A permission mask is the complete ACE for a specific entity. The way to obtain this is to OR every ACE associated with the specific secured entity. There are exceptions to this rule:
If one ACE is all zeros (no access) then the resulting permission mask will be zero (no access)
If it is the “everyone” profile that has all zero (no access) then the exception above is invalid.
4–14 Desktop and Server Management Advanced Topics Guide 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 OR’d together).
When permissions are defined for a group, rights are inherited. Inheritance can be enabled or disabled for each individual group.
Unlike the previous r4 USD release, the “No Access” permission does not override all other permissions.
There is no replication of security profiles or permissions.
Components that use OLS include:
Every DAI component using the DBAPI
Web Admin Console
DSM AM Manager ( AMO Data classes)
CLS-SD Stored procedures
Test of the permissions must be very fast. It needs to:
Use simple select for permission
Calculate the effective permissions when an object is created or a permission is changed
September 2007 Chapter 4: CAF 4- 15 Security
Applicable MDB Tables
Following are the MDB tables used by security:
Class level permissions are maintained in the ca_class_ace table
Object level permissions are maintained in the ca_object_ace table
Group level permissions are maintained in the ca_group_acen table
Following is the list of security profiles used:
Profile Name Purpose
Everyone This profile initially has class permissions. NO_ACCESS for all classes
Owner This profile is necessary for managing dynamically created objects so that every object will be assigned to an owner profile. Ownership may be changed via an application, such as a UI
Distributions This profile is used by the Enterprise. Administrators have class permissions FULL_CONTROL for all objects
Administrators This security profile is for the local user. User group is called ADMINISTRATORS. This profile initially has class permission FULL_CONTROL for all objects
4–16 Desktop and Server Management Advanced Topics Guide 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 DB Tables Security Class ID Security Level
Computers ca_discovered_hardware SEC_CLSID_COM_COMPUTER Class, Object
Users ca_discovered_user SEC_CLSID_COM_USER Class, Object
Computer Ca_link_dis_hw_user SEC_CLSID_COM_COMPUTER_USER Class, Object Users
Managers ca_manager SEC_CLSID_COM_MANAGER Class, Object
Servers ca_server SEC_CLSID_COM_SERVER Class, Object
Groups of all ca_group_def SEC_CLSID_COM_GROUP [1] Class, Group, above Object
Group of ca_group_def SEC_CLSID_COM_ASSET_GROUP Class, object assets
Group of Ca_group_def SEC_CLSID_COM_SERVER_GROUP Class, object servers
Group of ca_group_def SEC_CLSID_COM_DOMAIN_GROUP Class, object domains
Queries ca_query_def SEC_CLSID_COM_QUERY Class, object
The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used in the Security Table.
GUI Level DB Tables Security Class ID Security Level
Class ca_class_def SEC_CLSID_SEC_CLASS_SECURITY_ Class, Object Permission OBJECT
Security ca_security_profile SEC_CLSID_SEC_SECURITY_PROFILE Class, Object Profiles
MDB Access -- SEC_CLSID_MDB_ACCESS Class
September 2007 Chapter 4: CAF 4- 17 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 DB Tables Security Class ID Security Level
SW Packages usd_rsw SEC_CLSID_USD_SOFTWARE Class, Object
SW Procedures usd_actproc SEC_CLSID_USD_PROCEDURE Class, Object
SW Groups Usd_swfold & type=1 SEC_CLSID_USD_SW_GROUP Class, Object
Procedure groups Usd_swfold & type=2 SEC_CLSID_USD_PROC_GROUP Class, Object
Job containers Usd_job_cont SEC_CLSID_USD_JOB_CONTAINER Class, Object
Jobs Usd_activity SEC_CLSID_USD_JOB Class, Group, Object
Distribution Usd_contfold SEC_CLSID_USD_DIST_CONTAINER Class, object containers
TM Tasks Usd_task SEC_CLSID_USD_TASK Class
Container Usd_cont SEC_CLSID_USD_CONTAINER Class, object
The following table identifies the GUI level object and the corresponding DB tables, Security Class ID and Level used in the Asset Management Table.
GUI Level DB Tables Security Class ID Security Level
Jobs Ncjobcfg + column SEC_CLSID_ASSET_JOBS Class job_category SEC_CLSID_ENGINE_JOBS Class
Modules Ncmodcfg + column SEC_CLSID_MODUL_INVENTORY Class motype SEC_CLSID_MODUL_TEMPLATE Class SEC_CLSID_MODUL_SOFTWARE Class SEC_CLSID_MODUL_METERING Class
Policies Polidef SEC_CLSID_POLICY_QUERYBASED Class SEC_CLSID_POLICY_EVENTBASED Class
Software Ca_software_def SEC_CLSID_AMO_SW Class, Object
Engines Ca_Engine SEC_CLSID_AMO_ENGINE Class, object
4–18 Desktop and Server Management Advanced Topics Guide 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 Security Level
GUI task wizard [*] -- SEC_CLSID_COM_TASKWIZ Class (this is no longer used)
Enable Control -- SEC_CLSID_COM_CONTROL_PANEL Class Panel
Enable Remote -- SEC_CLSID_COM_REMOTE_CONTROL Class Control
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 Security Level
External directories Ca_directory_details SEC_CLSID_DIR_EXT_DIRECTORY Class, Object
Report Template Rptree & type = 3 SEC_CLSID_REPORT_TEMPLATE Class
Schedule Template Rptree & type = 40 SEC_CLSID_SCHEDULE_TEMPLATE Class
Configuration Csm_object and SEC_CLSID_CCNF_POLICY_COMP Policies computer csm_class is ConfPolicyComp
Configuration Csm_object and SEC_CLSID_CCNF_POLICY_USER Policies user csm_class is ConfPolicyComp
OSIM object – Csm_object and SEC_CLSID_OSIM_IMAGE Boot/OS images csm_class is “OSimage” OR csm_object and csm_class is “BootImage”
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 Chapter 4: CAF 4- 19 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.
4–20 Desktop and Server Management Advanced Topics Guide 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 Chapter 4: CAF 4- 21 Communication
The Port Multiplexer only supports TCP.
Since the Port Multiplexer has its own API set it is not necessary to convert existing applications to use the Networker (see below) in order to use the Networker services. The conversion is straightforward and adopting such an approach has benefits over using the Networker including: -
Existing pre-release 11 components can be communicated with (which might not be the case with the Networker, which imposes its own protocols on the data interchange). The Port Multiplexer can also listen directly on ‘legacy’ ports which allows applications which haven’t been converted to use the multiplexer to converse with those which have, without requiring the converted application to handle multiple concurrent connection styles.
Existing logic can be preserved. Often, changing to use the Networker will involve changing the style of interacting with the communications. Application logic is often based on the behavior of the interfaces used.
The Pmux API routines send a small message to the plug-in which is listening on port 4728. Message types include:
Listen
Legacy Listen
Connect
Query
PMUX and Networker Working Together
The Port Multiplexer and Networker are complementary solutions. The Networker will make use of the port multiplexer in order to make or allow connections. For example, instead of listening for a connection, a Networker will ask the Port Multiplexer to listen on its behalf and the Port Multiplexer will hand over connection to it. Similarly, when making a connection to another machine, the Networker will connect to a remote port multiplexer nominating the (virtual) port it wishes to connect to. That Port Multiplexer will accept its connection and hand it over to the ‘real’ listener. Thus, all DSM components on a machine can share a single port for all connections.
The Messenger
DSM r11 messaging is delivered via the Messenger common component. The Messenger provides an abstraction layer, implemented on top of CAM, which separates its users from the messaging system actually in use.
4–22 Desktop and Server Management Advanced Topics Guide 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 Chapter 4: CAF 4- 23 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.
4–24 Desktop and Server Management Advanced Topics Guide September 2007
Chapter 5: Installation Topics
This chapter discusses a several topics relating to the installation of Unicenter DSM architecture, including:
Infrastructure deployment
Migrating\upgrading from a previous installation\version
NAT Environments
For additional information you should consult the following sources:
Implementation Guide (notably “Chapter 2: Planning the Infrastructure Implementation”, “Chapter 3: Installation of Unicenter DSM” “Chapter 4: Infrastructure Deployment,” “Chapter 5: Upgrading Unicenter DSM”, “Chapter 8: Migration to Unicenter DSM,” “Appendix B: Software Delivery Procedures for Installation” and “Appendix G: Unicenter Software Delivery Query Migration Details”)
Chapter 5 in the Unicenter Desktop and Server Management Diagnostics Guide
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 Chapter 5: Installation Topics 5–1 Infrastructure Deployment
The following techdocs should also be noted:
“How Authentication Works in r11 for Centrally and Locally Managed Configurations” (TEC401105)
“How to Centralize Security in URC r11” (TEC401138)
“SQL Installation and Preparation for DSM r11 Domain and Enterprise Manager Installs” (TEC401106)
“How to Move a Domain from one Enterprise to Another” (TEC401299)
“How do you install the Software Delivery Agent without the need to also install the Software Catalog” (TEC430032)
“SQL Installation and Preparation for DSM R11 Domain and Enterprise Manager Installs” (TEC401106)
“When installing r11.2 with Common Services how does it handle having existing versions of NSM components already installed on the server?” (TEC426063)
“Creating a Pre-configured Standalone Customised install for the r11 Remote Control Agent” (TEC395449)
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
Infrastructure Deployment
The Infrastructure Deployment subsystem facilitates the initial deployment of DSM software components within a heterogeneous enterprise. Infrastructure Deployment is also sometimes known as DMDeploy v2. DSM infrastructure components, such as Agents and Scalability Servers, can be transferred and installed without the use of Unicenter Software Delivery. This functionality is typically used for an initial roll out of the DSM infrastructure.
Infrastructure Deployment uses a DSM Explorer wizard to scan for deployment targets and to configure and initiate the deployment job.
Important note: When the Infrastructure Deployment wizard is completed a deployment job is created which manages the progress of the deployment to all the selected end systems. The status of this job can be viewed via the DSM Explorer, but please note that the job is NOT persistent; it is maintained in the memory space of the DMDeploy manager process. If the DMDeploy manager exits for any reason (crashes, is restarted, machine rebooted) the job information is lost as are any unprocessed status messages from end system installations. These installations, however, will continue if already started.
5–2 Desktop and Server Management Advanced Topics Guide September 2007 Infrastructure Deployment
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 Infrastructure Deployment
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
5–4 Desktop and Server Management Advanced Topics Guide September 2007 Infrastructure Deployment
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
5. DMPrimer installer installs itself and CAM on the target machine using either Windows RPC, SSH or Telnet (or manually). Note that DMPrimer must run with elevated privileges.
Note: Some operating systems, such as Windows 9x, do not have a method for remote invocation. In these cases, it is necessary to configure the OS to install the primer on a significant operating system event, such as a reboot.
6. When install completes, DMPrimer notifies manager (via CAM) of successful installation so that package deployment can now be initiated.
Note: A DMDeploy manager that has either installed a DMPrimer or has authenticated with it can deploy packages without needing to re-supply usernames or passwords. This is achieved through authentication using public and private keys.
Any errors up to this point usually result in “No Primer Transport”
7. Manager sends payload data to Primer (using CAM messages).
Data appears as a “primer.packN” file in the Primer installation folder (‘N’ is a small number).
8. Primer unpacks the payload data, then sends a “package received” message to manager
9. Manager sends payload installation command in a CAM message to primer, which executes it
Payload installation is synchronous, no timeout
Install command is logged in dmprimer.log on target
10. Primer returns installation status to manager Also logged in dmprimer.log
Stage to and Deploy from Scalability Server
To reduce overall network traffic, deployment payloads can be “staged” to a Scalability Server. This operation is basically a normal deployment except that the installation command is replaced by a copy into a staging area.
On Windows: staging area is a share (DMDEPLOYSS$)
On Linux/UNIX: staging area is an FTP server.
September 2007 Chapter 5: Installation Topics 5- 5 Infrastructure Deployment
Deployment from a Scalability Server simply takes the payload data from the staging area rather than the manager library area.
Note: In r11.1 the primer installation image is transferred from the Manager while, in r11.2, it can be staged at the Scalability Server.
Even when a Scalability Server is used to stage and deploy software packages, control of the process is still handled by the manager.
Diagnosis Tips
Consult the following log files if you experience problems with Infrastructure Deployment:
Manager Logs use standard DSM log mechanism and the following naming convention:
TRC_CF_DMDEPLOY_*.LOG
Major deployment stages are logged at “INFO” level and log analyser rules are available. The Manager Logs include information regarding the connection to Windows target shares, job status and other deployment stages.
Primer Logs note the exact installation command that is run along with the exit code it produces upon completion. These logs are produced in the temporary directory (%TEMP% or /tmp).
Payload Installation Logs can typically be found in the following locations:
– On Windows: %TEMP% – On UNIX\Linux: /opt/CA/installer/log
You should also check the following logs for more information:
CAM logs, if you have communication issues
UNIX/Linux syslog on target computers can be useful to diagnose SSH/Telnet security issues
Don’t forget to….
Check Firewall settings!
Full automatic deployment is not always possible because…
– Windows 9x does not support remote installation of primer from the manager, and by default doesn’t let you map the ADMIN$ share.
– Later Linux versions are configured to disable remote non-interactive SSH sessions.
Further details can be found in the DSM Implementation Guide
5–6 Desktop and Server Management Advanced Topics Guide September 2007 Infrastructure Deployment
Upgrade of Primers
Primers are not automatically upgraded; therefore you will need to use the “force primer push” policy setting to achieve this. Deployment of DMPrimer uses native OS data transport mechanisms or is done manually, but, all subsequent network activity is performed via CAM (such as pushing payloads and returning payload installation status). This reliance on CAM isolates the main portion of the deployment process from networking issues and configuration.
Note: This process requires re-authentication (to push new encryption keys).
DSM session messaging (hence CAM) is used for all DSM Explorer Wizard to Manager communications.
Frequently asked Questions
Following are some frequently asked questions regarding Infrastructure Deployment:
What does “No Primer Transport” Job status mean? Can’t push primer to target (or it failed to install)
What does “Failed to Telnet” trace message mean? This error is usually associated with the No Primer Transport status and is preceded by “failed to map share” and “failed to SSH” errors!
Where have my deployment jobs gone? Jobs are not retained when the deployment manager is recycled.
What can I do to test CAM Connectivity issues? Ensure that you can execute “camping” both ways between manager & targets. Also, check DNS, and firewalls configurations.
Where are the agent configuration options documented?
In the Implementation Guide (
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 Chapter 5: Installation Topics 5- 7 Infrastructure Deployment
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
5–8 Desktop and Server Management Advanced Topics Guide September 2007 Infrastructure Deployment
The installer registers/deregisters a product by calling dmprimer with special args. The Infrastructure Deployment Manager asks “is product x version y installed?” not “what products have you got?”
Increasing Primer Log Level
To increase the primer log level do the following:
1. Change to the directory containing the dm_primer. On Windows this is:
Program Files\CA\Unicenter DSM\DMPrimer
2. Issue a 'dm_primer stop' command 3. Remove the old dmprimer.log 4. Edit the dmprimer.cfg file found in the above directory and change the TRACE_LEVEL value from 3 to 5.
5. Deploy the software
Note: There is no need to restart the primer as cam will do this automatically
Note: SE Testfix T18C872 allows log level updates without restarting primer.
Deploying to Linux over SSH
Deployment to Linux targets using DMDeploy over SSH (the default method for Linux) is quite complex and subject to a variety of environmental obstacles. Many things have to occur successfully before the deployment payload becomes active on a target system. Unfortunately, since no CA software is assumed to be present during deployment it is impossible to report accurate status and diagnostic messages during this operation. Therefore an understanding of the process is important.
Following is the sequence of events that occur when deploying to Linux using SSH, to a clean system. When diagnosing problems in this area identifying the point of failure within the sequence is crucial.
1. The dmdeploy manager connects to target system using ssh You should see the connection attempt logged into the system log file /var/log/secure.
2. If the connection is successful, the primer installation package is pushed to the target system using ssh/sftp
You should see OS processes with names containing these strings appear on the target system
3. Primer image is uploaded to /tmp/dmprimer
September 2007 Chapter 5: Installation Topics 5- 9 Infrastructure Deployment
You can do “ls –ltr” in this directory to monitor the growth of files as they are uploaded. In order to assist with tracking down installation issues this directory is not removed.
4. When the image stops growing, the primer install (installdmp) is launched. You should see a process with this name appear in your ps list. You should also see a process running lsm.exe.
5. After the primer install is finished, you should see two packages called “ca- dsm-dmprimer” and “ca-dsm-dmprimer-standalone” in the pif package list (“lsm –lOpif”). Primer files are installed into the following directory:
/opt/CA/UnicenterDSM/dmprimer
6. Dmprimer should then be started (you should see “dm_primer start” appear in the ps list). The dmprimer log file (/tmp/dmprimer.log) should also appear.
7. The transfer of the deployment payload (for example, UAM agent) starts. You should see the “transferring xx%” messages appear in the GUI/CLI. This is quite quick in comparison to the primer upload in step 2.
8. Package installation starts. You will see the “installdsm” process in the ps listing. The command “lsm – lOpif “will display the PIF packages currently installed. After completion, the package ca-dsm will be present. Other sub-components will be present depending on which payload you are installing.
That’s it – package installation status is sent back to the manager and displayed in the GUI/CLI.
Deploying to Windows over a Network Share
Deployment to Windows targets using DMDeploy is subject to a number of environmental obstacles as well. As with Linux deployments, many things have to occur successfully before the deployment payload becomes active on a target system. Unfortunately, since no CA software is assumed to be present during deployment it is impossible to report accurate status and diagnostic messages during this operation. Therefore an understanding of the process is important.
Following is the sequence of events that occurs when Windows is deployed to a clean system using shares. When diagnosing problems in this area identifying the point of failure within the sequence is crucial.
1. DMDeploy manager attempts to open a share (by default “admin$”) on the target system.
2. If the share is opened successfully the primer installation package is copied to the target system. This consists of the following 4 files:
DMBoot.exe
5–10 Desktop and Server Management Advanced Topics Guide September 2007 Infrastructure Deployment
dmkeydat.pmr
dmsetup.exe
msvcr71.dll
3. Primer image is uploaded to admin$, or whatever share the user has configured the manager to use for deployment.
4. When the image stops growing, the primer install is launched by the MSI installer. The task manager will show at least one msiexec.exe process running.
5. After the primer install is finished, you should see the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\DMPrimer
The key’s data will show where the primer files have been installed. The usual location is:
C:\Program Files\CA\Unicenter DSM\DMPrimer
6. The primer should now have started and “dm_primer.exe” should appear in the task manager.
The primer log file, C:\Documents and Settings\
7. The transfer of the deployment payload (for example, UAM agent) starts and you should see the “transferring xx%” messages appear in the GUI or the CLI. This is quite quick in comparison to the primer upload in step 2.
8. Package installation starts and you should see a ‘.msi’ process corresponding to the package being installed (for example, ‘AgtAM.msi’ for the Agent + Asset Management plug-in package), in the Task Manager. The ‘Add or Remove Programs’ utility, accessible from the Control Panel, will display the packages currently installed. After completion, the deployed package will be present, the exact entry obviously depending on which payload you installed.
That’s it – the package installation status is sent back to the manager and displayed in the GUI/CLI.
September 2007 Chapter 5: Installation Topics 5- 11 Upgrading from a Previous Release
Upgrading from a Previous Release
Detailed procedures and guidelines for upgrading to the r11 release from a previous version of Unicenter Software Deliver, Unicenter Asset Management or Unicenter Remote Control can be found in the Implementation Guide. Following is an overview and additional tips to further assist you in upgrading.
Direct software upgrade to release 11 is not supported. Rather, the upgrade path uses a “parallel” or “side-by-side” approach. First, the new r11 components are deployed (Domain Managers, Scalability Servers and other) typically using a new, more optimal, topology. Then data is migrated from the pre-r11 databases to the new r11 CA-MDB. Following is a list of supported upgrade paths:
Unicenter Software Delivery r11 can be migrated from Version 3.1 and Version 4.0
Unicenter Asset Management r11 can be migrated from Version 3.2 and Version 4.0
Unicenter Remote Control r11 can be migrated from Version 6.0
The migration to DSM r11 is about homogenization of three distributed solutions with different architectures and separate databases into one consolidated r11 architecture.
5–12 Desktop and Server Management Advanced Topics Guide September 2007 Upgrading from a Previous Release
The change is a significant one in that three formerly disparate and independent technologies have now merged into a single technology employing a single management database structure. Additionally, as each product is multi-tiered, an upgrade approach would require extensive backwards compatibility support between the tiers during the migration process that would not add any value post migration.
The end result is a simple upgrade strategy will not suffice.
The DSM Implementation Guide includes a migration chapter which describes the general migration approach, limitations and challenges, as well as the specifics regarding ASM.CNF keys, MSI library migration and lots more! We strongly suggest you read this chapter.
Migration to r11 is achieved via 3 distinct steps:
1. The installation of management infrastructure (see the earlier discussion of Infrastructure Deployment)
2. The migration of data 3. The installation of new agent software
Data Migration
The Data Migration step is driven by Engine Tasks, with one Task type per product (UAM, USD, OSIM, URC). There may be multiple legacy managers and multiple tasks for each legacy manager – which could add up to “a lot of tasks!”
Migration is a continuous process and all migrated computers are visible in system group “All Legacy Computers.” The process ends when r11 Agents are registered with the MDB – at which point you should STOP managing those assets through legacy managers.
The Engine reads migration job from database using the following method based on which product is being migrated:
For Software Delivery, Remote Control and OSIM: An XML file is created containing Job contents. The product specific migration DLL is loaded and executed with this XML file as a parameter.
For Asset Management: A call internal Engine code is made to migrate AM data
September 2007 Chapter 5: Installation Topics 5- 13 Upgrading from a Previous Release
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
5–14 Desktop and Server Management Advanced Topics Guide September 2007 Upgrading from a Previous Release
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 Chapter 5: Installation Topics 5- 15 Upgrading from a Previous Release
Migration is invoked by agent installer if selected by user.
Migrated configuration settings are protected by CCNF from override by DSM r11 default policy. Only custom policy will override the migrated settings.
On Managers, the library is copied by a migration task - it is NOT automated on Scalability Servers. You will need to run sd_sscmd import to copy or move packages from legacy staging servers.
MSILIB is not automatically migrated on Domain Managers and Scalability Servers. You will need to run sd_sscmd importmsi to copy or move packages from a legacy local or staging server MSILIB.
In r11 software packages are identified by DSM UUID – NOT by their MSI Product Code.
This appears in MSILIB in folder named with this DSM UUID
DSM UUID maintained during export and Enterprise to Domain distribution
Important to use the same DSM UUID throughout Enterprise and all Domains to improve roaming source list updates
The new MSILIB share name is “SDMSILIB” and a new MSI dictionary file is provided to improve roaming source list update. In addition, new MSI procedure macros replace old macros used to find admin installs in new locations. The old macros are updated during package import. For more details, consult the Implementation Guide.
USD Data Migration Implementation
The process of migrating USD specific data is as follows:
1. Engine loads the usdLegacy DLL/SLIB 2. usdLegacy DLL/SLIB calls the sdmgrmig executable using instructions it received from the Engine
3. Sdmgrmig loads usd40sp1 DLL/SLIB to connect to legacy manager 4. Sdmgrmig loads ps DLL/SLIB to connect to r11 database 5. Sdmgrmig loads coApi DLL/SLIB to connect to r11 common manager 6. Migration is done for each selected object class All tracing goes to TRC_MIGRATION_USD.
7. As with previous installations, all SD events are also logged to the NT(/CCS) event console.
8. Very limited feedback is written to Engine task portal but you can see if the task has completed and what the result of the run was.
5–16 Desktop and Server Management Advanced Topics Guide September 2007 Upgrading from a Previous Release
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 Chapter 5: Installation Topics 5- 17 Upgrading from a Previous Release
OSIM Data Migration Implementation
OSIM data migration runs as an Engine job and is implemented as a DLL (ccsmmig.dll) or a UNIX library (libccsmmig.so) depending on the platform.
Unicenter Asset Management Specific Information
The following Asset Management data is migrated:
Computers – including State “Legacy.” Use migration scope to identify which computers to migrate.
Static Groups (also link members)
Dynamic Groups - depending on which queries are migrated
Computer General Inventory
Computer Software Inventory - depending on which Software Definitions are migrated
Jobs. Note that these are not linked to groups or assets. Status will not be migrated.
Templates
Configuration Files
Queries. Although most will be migrated automatically, those that are not migrated successfully will be flagged.
Query based policies - depending on which queries are migrated
Event Policies
Categories
Publishers
Application Definitions. Note that heuristic applications will not be migrated.
Only Software Definitions with corresponding software in UAM 4.0 will be migrated, unless the Software Definitions belong to a Category labeled 'Migration'.
Report templates
Scheduled Reports
Asset Management Specific Data Migration Process
Following is the process by which Asset Management specific data is migrated:
1. DSM connects to the Legacy Database 2. Important data is verified and loaded into cache
5–18 Desktop and Server Management Advanced Topics Guide September 2007 Upgrading from a Previous Release
3. Each individual configured item is migrated 4. Legacy Database is closed
The list of legacy objects is maintained in the amlegacy_objects table. This table maps UAM 4.0 primary key and r11 primary key for each object. Objects that are mapped will not be migrated again (with the exception of an update of inventory on Computers).
With the exception of Computers, objects will be mapped to existing r11 object if the object name matches. Computers are mapped to existing computers if host_uuid are the same or if host_name is the same.
A computer’s General Inventory and filescan based Software Inventory is migrated (Software Definitions for these, however, have to be migrated).
To verify migration status, check the TRC_MIGRATION_UAM_0.LOG which is found in the \CA\Unicenter DSM\logs directory. This file provides runtime logging.
Remote Control Specific Information
The following data is migrated for the Remote Control component:
Computer Groups
Global/Local Address Book Information
Computers. State will be listed as “migrated.” Use migration scope to identify which computers to include.
Configuration Policy Data
All necessary data for each object type is copied from the Remote Control r6 database to memory and each object is inserted repeatedly. Some object types are updated if already present depending on responsibility. Inserting duplicates does not interfere with migration.
Computer -> ca_discovered_hardware(machine), ca_agent( RC status “Migrated”), ca_group_member(group membership)
ComputerGroup -> ca_group_def(r11 group), ca_agent, ca_group_member(group membership)
Address book data -> ca_group_def(r11 group), ca_agent, ca_group_member(group membership), urc_ab_group_member(indicating address book), urc_ab_computer(with connection addresses), urc_ab_permission(permissions for address book groups)
You can delete objects in the DSM Explorer and migrate again to recreate them.
September 2007 Chapter 5: Installation Topics 5- 19 DSM and NAT
Note that configuration policies are not deleted instantly although you cannot see them in the GUI any longer.
Remote Control r6 address book groups are transformed into standard r11 groups plus some extra address book properties. R6configuration policies are added to the r11 configuration via CCNF client calls. The sequence of calls is generated from the r6 data in memory.
To view migration status, check the TRC_MIGRATION_URC_0.LOG file. You can also check the Engine Status.
Remote Control Data Migration
Data migration for URC is managed through the rcLegacy.dll and the rcManagerR11Migration.exe. The Engine calls rcLegacy with the data provided by the Migration Wizard and rcLegacy builds a command from the data and executes it.
This command can also be run standalone. For information on the syntax, execute the following:
rcManagerR11Migration.exe -?
DSM and NAT
DSM r11 can function within a network using Network Address Translation (NAT) or Port Address Translation (PAT) network but there are some additional considerations, limitations and configuration requirements that need to be understood. This section describes some basic testing that was carried out on a DSM r11 deployment within a NAT’d network environment.
Note: No firewalls were in place during testing.
Overview
There are different types of NAT:
Static NAT - Maps an unregistered IP address to a registered IP address on a one-to-one basis.
Dynamic NAT - Maps an unregistered IP address to a registered IP address from a pool of registered IP addresses.
Overloading – Similar to dynamic NAT, it maps multiple unregistered IP addresses to a single registered IP address by using different ports. This is also called PAT (Port Address Translation).
5–20 Desktop and Server Management Advanced Topics Guide 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 system’s internal, configured IP address is never exposed to systems beyond the router. In the latter case, PAT or NAT Overloading is used to counter the decreasing number of available registered IP addresses.
PAT presents the biggest challenges for DSM and is, therefore, the focus of the following tests. PAT essentially stops any direct connections from beyond the router from reaching systems connected to the local LAN.
DSM uses the following two proprietary communications technologies:
CAM
TCP Stream via Port Mux (used by DTS, the NOS-less file transfer component and the RC video stream).
Since CAM uses the message’s source IP address to identify an end system this may cause a problem in an Overloaded NAT network where the source IP address will always be that of the router. When CAM receives a second connection from the same IP address it discards the first as an apparent duplicate. Since response messages would not be able to get back to the system that made the first request this could cause a problem.
With the exception of Asset Management the same behavior was used in the previous releases. Prior to r11 Asset Management could use file shares as sectors, or use the AM connectivity server. As a result, users were able to design different working solutions through these alternate mechanisms in order to suit their needs and their network configuration. In r11, these options are replaced by CAM.
Fortunately, CAM will work when communicating out from a PAT configured network but only if something else from the same PAT configured network doesn’t come along in the middle of a message exchange. The effect of this may be minimal in a normally quiescent network and, even in a DSM network with moderate activity where application code may experience connection failures or timeouts – though the code should retry and recover. A very active CAM network, however, may be significantly affected.
Scenario 1: Scalability Server as Proxy Router
In this example, the network incorporating a NAT/PAT router was configured as follows:
A DSM Domain Manager was connected to the example Corporate Network
A DSM Scalability Server was connected to the NAT router with a static NAT address appearing as 10.100.1.100 to connections via the WAN and 192.168.2.10 locally.
September 2007 Chapter 5: Installation Topics 5- 21 DSM and NAT
2 DSM Agents were connected to the DHCP based, NAT’d (PAT’d) LAN.
In this scenario the Scalability Server is essentially in the DMZ, so that both the WAN and NAT’d LAN can see it, but with different IP addresses. The DSM Agents are hidden from the WAN.
The test network was not connected to the domain network for security reasons and, as such, a DNS service was not available. To that end etc/hosts file entries were used for machine naming.
Also NOTE that no firewalls were in place.
5–22 Desktop and Server Management Advanced Topics Guide 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 Manager’s perspective, the Scalability Server is known by its external address (10.100.1.100) and, therefore, CAM messages are directed to this address. The Scalability Server, however, actually knows itself by its NAT address (192.168.2.100) and so attempts to forward the messages sent from the Manager to an address that is unreachable.
Solution
CAM needs to be configured on the Scalability Server to route messages sent to its WAN address to itself via a simple cam.cfg rule. Add a ROUTING rule to the cam.cfg file that directs messages destined for 10.100.1.100 to localhost. For example:
*ROUTING forward localhost 10.100.1.100
The Engine can now successfully contact the Scalability Server and the new computers and their inventory is collected.
With this solution in place the following functionality has been validated as functioning correctly via limited, ad-hoc testing.
Agent registration
Inventory collection
Common configuration
Asset Jobs
Agent RC Viewer Global Address Book retrieval
Agent RC Host Authentication
Agent RC Viewer to Agent RC Host
Agent RC Viewer to Scalability Server RC Host
Manager RC Viewer to Scalability Server RC Host
Scalability Server RC Viewer to Agent RC Host
September 2007 Chapter 5: Installation Topics 5- 23 DSM and NAT
Note how the latter two entries mean that an RC Viewer running at the Manager can control an Agent by hopping through a Scalability Server.
Problem 2: Infrastructure Deployment
Infrastructure Deployment fails to discover the end systems during the scan phase and, even if it could, file share and telnet access is not possible because the end systems are hidden from the Manager.
Solution
Failure to discover and connect directly to end systems is, as it should be, and, as such, there is no real solution for the discovery and primer transfer. However, it is possible to instruct the Deployment Manager to skip the IP ping that it uses to detect end systems. If the ping is skipped the Deployment Manager attempts to connect to the dm_primer directly. If the dm_primer is already installed on the end systems with the appropriate Manager key file (perhaps via logon script execution of the dm_setup package) and CAM traffic intended for the NAT network is routed through the Scalability Server then deployment is possible and successful.
Note: This problem also occurred in previous product releases.
The Manager’s instance of CAM is configured to route all messages to the Agent addresses via the Scalability Server as follows
*ROUTING forward 10.100.1.100 192.168.1.*
This enables CAM communications from Manager to end system via Scalability Server.
Problem 3: AM/SD Job Checks
An AM/SD job check request from DSM Explorer to Agent does not work.
Solution
A combination of CAM routing rules at the Manager and host file entries solves this problem. First, hosts file entries for the end systems are added as follows:
agent1 192.168.1.129 agent2 192.168.1.130
5–24 Desktop and Server Management Advanced Topics Guide September 2007 DSM and NAT
This enables the names of the end systems to be resolved to IP addresses. Next, the Manager’s instance of CAM is configured to route all messages to these addresses via the Scalability Server as follows
*ROUTING forward 10.100.1.100 192.168.1.*
This enables CAM communications from Manager to end system via the Scalability Server. However, this is not ideal since, in a domain with multiple NAT’d networks, each private NAT addressing scheme would have to be different (in other words, the end system’s private IP addresses would have to be unique within the DSM domain). In addition, since a DNS is not used to resolve the addresses and DHCP is used on the NAT’d networks, agent addresses might change and become out of sync with the hosts file.
Recommendation
In this case, our recommendation is simply to not run manual, ad hoc job checks. There should be very little need to do so in a properly configured, managed enterprise.
Scenario 2: Agent as CAM Proxy
In this scenario all CAM communications are routed through the CAM proxy using appropriate CAM ROUTING rules on the Agents and Scalability Server.
September 2007 Chapter 5: Installation Topics 5- 25 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
5–26 Desktop and Server Management Advanced Topics Guide 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 Chapter 5: Installation Topics 5- 27
Chapter 6: Startup and Configuration
This chapter takes a closer look at the interaction between components including:
what happens when DSM r11 boots up
infrastructure configuration process
Agent registration process
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 Chapter 6: Startup and Configuration 6–1 What Happens at Startup?
Nearly every DSM process is controlled via CAF. In essence CAF starts up and then starts up all configured plug-ins.
There are a couple of exceptions which are mentioned here for completeness
cfusrntf.exe is invoked transiently whenever a user logs in to a system. This is used to capture user accounts.
sxplog32.exe is invoked persistently whenever a user logs in to a system. This is used to apply sxp package settings within a user context i.e. it is only used when an sxp package is installed. This is started via the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\DsmSxplog
cf_SysTray.exe is invoked persistently whenever a user logs in to a system. This is used to provide a menu applet within the system tray area of the desktop. It is started via the registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\CAF_SystemTr ay
The following diagram provides an overview of the startup process.
6–2 Desktop and Server Management Advanced Topics Guide September 2007 What Happens at Startup?
CAF reaches a steady state with the following threads awaiting stimulus:
Main thread is waiting on Service Control events
ServiceMain thread is waiting within the main CAF message processing loop
Scheduler thread is waiting in timed loop on scheduled events
SM endpoint (U-CAF) is waiting on CAM messages (with thread pool of 1)
PortMux thread is waiting in timed loop on status change flag and socket connections
Each instance of cfPlug-in has a thread waiting for messages from the cfRuntime IPC pipe.
Tip! You can run the following command to query CAF for the current status of all plug-ins.
caf status
The output should look something like this…
Querying caf for status information... Unicenter DSM r11 Common Application Framework 11.0.8024.234
Showing running DSM services...
[1] Asset Management manager (ammanager) [2] Asset Management performance agent (ampmagent) [3] Asset Management server (amrss) [4] Asset Management usage server (amms) [5] Certificate exchange plug-in (cfcertex) [6] Common Server (cserver) [7] Common object manager (cmobjectmanager) [8] Configuration agent (ccnfagent) [9] Configuration and State Management agent (ccsmagt) [10] Configuration and State Management agent controller (ccsmact) [11] Configuration and State Management database api server (ccsmapi) [12] Configuration and State Management server (ccsmsvr) [13] DSM Service Locator plug-in (cfsvclocator) [14] Data Transport network object server (dtsnos) [15] Data Transport schedule object server (dtssos) [16] Data Transport transfer agent (dtsagent) [17] Data Transport transfer object server (dtstos) [18] Deployment Manager (dmdeploy) [19] Engine (SystemEngine) [20] Event notification plug-in (cfnotify) [21] File transfer server (cfftplug-in) [22] Notification Server (cfnotsrvd) [23] Port multiplexer (pmux) [24] Registration plug-in (cfregister)
September 2007 Chapter 6: Startup and Configuration 6- 3 What Happens at Startup?
[25] Remote Control host agent (rchost) [26] Remote Control manager (rcmanager) [27] Remote Control server (rcserver) [28] Session messaging server (smserver) [29] Software Delivery Boot Server (sdmpcserver) [30] Software Delivery manager: api server (sdmgr_api_2) [31] Software Delivery manager: dialog manager (sdmgr_dm) [32] Software Delivery manager: file transfer (sdmgr_ft) [33] Software Delivery manager: installation manager (sdmgr_im) [34] Software Delivery manager: task manager (sdmgr_tm) [35] Software Delivery server (sdserver) [36] tomcat server (tomcat)
Note that the list of plug-ins is sorted alphabetically – not in the order in which they are started.
Startup Under Windows
On the Windows platform the following specific actions occur at startup:
1. Session messaging plug-in starts C:\Program Files\CA\Unicenter DSM\bin\cfsmsmd.exe -t
2. CAF’s own session messaging end point U-CAF is set up 3. Common config agent plug-in (ccnfagent) starts up C:\Program Files\CA\Unicenter DSM\Bin\ccnfagent.exe
These three actions always occur first and are, essentially, hardcoded. The following actions occur based on configuration within comstore.
1. Tomcat starts up 2. Infrastructure Deployment Manager (DMDeploy) starts up C:\Program Files\CA\Unicenter DSM\Bin\DMDeploy.exe start
3. Boot Server starts up C:\Program Files\CA\Unicenter DSM\Bin\sdmpcworker.exe
4. CSM Server starts up C:\Program Files\CA\Unicenter DSM\Bin\ccsmsvrd.exe
5. CSM Agent Controller starts up C:\Program Files\CA\Unicenter DSM\Bin\ccsmactd.exe
6. CSM API Server starts up C:\Program Files\CA\Unicenter DSM\Bin\ccsmapid.exe
7. Notification server starts up
6–4 Desktop and Server Management Advanced Topics Guide September 2007 What Happens at Startup?
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 Chapter 6: Startup and Configuration 6- 5 What Happens at Startup?
27. SD Scalability Server plug-in starts up C:\Program Files\CA\Unicenter DSM\Bin\sd_server.exe
28. Common Object Manager starts up C:\Program Files\CA\Unicenter DSM\Bin\cmObjectManager.exe
29. AM Object Manager starts up C:\Program Files\CA\Unicenter DSM\Bin\amObjectManager.exe
30. Engine starts up C:\Program Files\CA\Unicenter DSM\Bin\cmEngine.exe
31. CAF event notifier (cfnotify) starts up using SM end point = CFNOTIFY 32. Common registration plug-in (cfregister) starts up using SM end point = CAITRMAGENT
33. CAF service locator (cfsvlocator) starts up 34. Scheduler is enabled 35. Register job is executed 36. Begin waiting for CAF messages 37. AM Agent starts up C:\Program Files\CA\Unicenter DSM\Bin\amagentsvc.exe UNIT=
38. SD Agent (sd_jexec.exe UNIT=.AfterReboot) starts up
Startup under Linux
Following is what happens during startup of cmObjectManager under Linux:
1. If Windows, init COM 2. Configuration information is read 3. SM end point (registering callback function) opened 4. OS Event created for shutdown 5. CAF notified that it is ready 6. Wait for shutdown event.
When a shutdown event is received, the cmObjectManager does the following:
1. Stops processing messages 2. Enters an infinite loop waiting for all open threads to finish 3. When all open threads have finished cmObjectManager exits
6–6 Desktop and Server Management Advanced Topics Guide September 2007 What Happens at Startup?
Following is what happens during startup of common server:
1. Init common components 2. Parse command line 3. Load config 4. Register with CAF 5. Register Server with Manager
Then, it reaches steady state with the following:
1. Main thread waiting on m_trigger_event 2. Notifier thread waiting on m_notify_event 3. CFRuntime thread waiting on IPC CAF messages 4. SM endpoint waiting on SM messages (with thread pool of 1)
By Default, the common server is actually single threaded in terms of processing workload but that configuration can be increased to use SM thread pool.
Following are the key startup activities (in order) when the Engine starts up:
1. Command line args parsed 2. Connect to CAF 3. Configuration read 4. One (1) second delayed loop entered - checking for work every 20 seconds.
Then, it reaches steady state with the following:
1. Main Thread in 1 second timed loop 2. Thread waiting on CAF pipe
Engine tasks may include the following:
Sector collect
Query Evaluation
SQL Script Execute
Reporter job
Legacy Sync (migration)
Replication
External Exe
Domain Dynamic Groups Evaluation
Domain Policy Evaluation
September 2007 Chapter 6: Startup and Configuration 6- 7 Infrastructure Configuration
Infrastructure Configuration
The Unicenter DSM products are configured centrally and locally through a shared component typically referred to as “common config” or “CCNF”. This components acts like an “enhanced Windows registry.” It manages the runtime configuration of practically all of the DSM subcomponents and infrastructure features, though there are some exceptions.
Configuration Policy
In order to simplify administration of configuration parameters, you can group a collection of those parameters into a single configuration policy. Therefore, instead of assigning single parameters to computers or groups, configuration policies are assigned. Configuration policy can be assigned to multiple computers or groups. From the administrator’s point of view, configuration policies are created and maintained independently of any specific computer or group.
There may be some overlap in the parameters defined in configuration policies – one parameter could be defined in more than one configuration policy destined for the same end system. Since only a unique parameter value can be set on a computer, the following rules are used to determine how to proceed when configuration policies overlap:
Policies assigned to a group are inherited by the children of the group. A child can be a group or computer.
In a hierarchy, policies assigned on the child level override the ones on the parent level. In other words, all parameters defined on the parent level are also defined for the child, however, when a child policy overlaps with a parent policy, the child policy ‘wins’.
In all other cases where overlapping policies present a conflict the user will be prompted to resolve the conflict.
Activating Computer Configuration
When the time comes for a computer configuration job to be activated the manager collects the parameters that need to be sent down to the computer.
The configuration job sent down to the target computer will only contain the parameters that have changed since the last time the configuration was sent down.
6–8 Desktop and Server Management Advanced Topics Guide September 2007 Infrastructure Configuration
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 Chapter 6: Startup and Configuration 6- 9 Infrastructure Configuration
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.
6–10 Desktop and Server Management Advanced Topics Guide September 2007 Infrastructure Configuration
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
Both comstore.enc and userstore.enc are encrypted to avoid direct manipulation.
In addition the file can be decrypted and written to a standard XML format file using the following command.
ccnfcmda –cmd GetConfigStore –fi c:\MyComStore.xml
Below is some example content. It shows some nested parameter sections e.g. “itrm/usd/shared”, as well as a parameter “nos” and it’s value “MS”.
A managed parameter is indicated by an entity value of “Manager.” For example:
When the attribute “write” is set to agent this means the local end system may update the parameter value. For example:
September 2007 Chapter 6: Startup and Configuration 6- 11 Infrastructure Configuration
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:
6–12 Desktop and Server Management Advanced Topics Guide September 2007 Infrastructure Configuration
Then register the new parameter by executing the following command on the Manager machine:
ccnfregdb.exe –mlocalhost –fC:\addparam.xml
September 2007 Chapter 6: Startup and Configuration 6- 13 Infrastructure Configuration
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.
6–14 Desktop and Server Management Advanced Topics Guide 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:
This list is initially sent by the manager and will be updated when the DefaultPolicy has been updated.
Ccnfcsmplug-in.dll is triggered by CSM Agent on a regular basis to check for delta reports. It requests a delta report from CCNF Agent and forwards the parameters according to the template list via CSM Agent.
CSM Agent calls ccnfcsmplug-in.dll if a report request arrives from the manager. Ccnfcsmplug-in.dll requests the full report from the CCNF Agent and forwards the data according to the template list via CSM Agent to the manager.
Agent Registration
When a DSM agent is installed on an end system the first thing it does is attempt to register its existence with the Domain Manager via its Scalability Server. This registration process is common across all products and includes a limited amount of inventory information (known as “Basic Inventory” or sometimes “Basic Hardware Inventory”). Note that agents register on a regular basis but basic inventory information is delta’d after the first registration.
September 2007 Chapter 6: Startup and Configuration 6- 15 Agent Registration
trace TRC_CMENGINE_0.log Engine [cmEngine.exe] 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 trace CAF – [caf.exe]
trace CF Register – [cfRegister.dll] TRC_CF_REGISTER_0.log
Create Process
Basic Inv Collector – [cfbasichwwnt.exe]
6–16 Desktop and Server Management Advanced Topics Guide September 2007
Chapter 7: Software Scanning
This chapter provides a closer look at the Asset Management software scanning process including:
General flow
Processes and log files
Content download process
XML generation process
Transfers from Engine to Scalability Server and from Scalability Server to agent
Enterprise Manager considerations
Import\Export utility
Diagnosis Tips
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 Chapter 7: Software Scanning 7–1 Overview and Flow
The following diagram illustrates the various modules and their interaction:
7–2 Desktop and Server Management Advanced Topics Guide September 2007 Processes and Log files
Processes and Log files
The software scanning function uses the following processes and log files:
September 2007 Chapter 7: Software Scanning 7- 3 Processes and Log files
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
7–4 Desktop and Server Management Advanced Topics Guide September 2007 Processes and Log files
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 Chapter 7: Software Scanning 7- 5 Processes and Log files
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.
7–6 Desktop and Server Management Advanced Topics Guide September 2007 Processes and Log files
The DSM Agent launches the Asset Management agent plug-in (amagents.exe for Windows and amagent for Linux) which, assuming software detection is configured to run at that time, first contacts the DSM Scalability Server to get the latest XML Signature file.
The first time the DSM Agent pulls the signature database file from the server it will also retrieve the revision number. The second and subsequent times that the agent requests the signatures it passes the current revision number to the Scalability Server and will only get a new signature database if there is a new revision.
After transfer, the file is stored (uncompressed) locally on the following locations of the end system’s hard drive:
On Windows: \Program Files\CA\Unicenter DSM\agent\units\00000001\uam\Wnnnnnnn.XML
On UNIX\Linux: /opt/CA/UnicenterDSM/Agent/AM/data/work/lnnnnnnn.xml
The software detector is launched via amosoftscan.exe (Windows) or amosoftscan (Linux) and writes to the TRC_UAM_0.log file. The scan applies any signature file differences provided by the agent in order to get a complete and up-to-date signature file.
Note: The signature scanner itself does not produce a log file; however, it does create a results file in the following locations:
On Windows: \Program Files\CA\Unicenter DSM\agent\units\00000001\uam\bak\amsoft.xml
On UNIX\Linux: /opt/CA/UnicenterDSM/Agent/AM/data/work/BAK/amosoft.xml
This creates a file containing the differences between the new scan result and the previous one. On UNIX\Linux, it is stored in the following location:
/opt/CA/UnicenterDSM/Agent/AM/data/work/amosoft.dat
The agent plug-in then takes this results file and sends it to the Scalability Server.
Tip: To run the signature scanner manually use the following syntax on Windows:
amswsigscan
On UNIX\Linux, use the following syntax:
camevmscli
September 2007 Chapter 7: Software Scanning 7- 7 Processes and Log files
In both cases the
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:
7–8 Desktop and Server Management Advanced Topics Guide September 2007 Processes and Log files
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 Chapter 7: Software Scanning 7- 9 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.
7–10 Desktop and Server Management Advanced Topics Guide September 2007
Chapter 8: Remote Control Connection
This chapter provides a closer look at the Remote Control connection including:
General flow
Processes and log files
Getting the authority list
Connection to the desktop
Displaying confirmation dialogs
Starting remote control
Security components
RC messenger
Diagnosis tips
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 Chapter 8: Remote Control Connection 8–1 Overview and Flow
In a managed environment Remote Control Viewers and Hosts communicate with DSM Scalability Servers and Managers in order to retrieve address book information, validate/authenticate users and retrieve permissions for valid users. The process flow is as follows:
1. Obtain Connection Information
Global Address Book
Local Address Book
Quick Connect
2. Obtain Authority List This is not required for “Local” security mode and the User doesn’t have to do this explicitly.
3. Validate Credentials via:
Locally Managed Security
Centralized Security
Security Cache/Fail-Safe
4. Connect to Target Desktop (control User Input) 5. Prompt User to Display/Connect to Host GUI 6. Start Remote Control Session and load video capture
8–2 Desktop and Server Management Advanced Topics Guide September 2007 Processes and Log files
Processes and Log files
The remote control connection function utilizes the following processes and log files:
TRC_URC_HOST TRC_URC_HOST_n.log TRC_URC_VIEWER_n.log GUI_n.log
Host GUI (cfSysTray.exe) Viewer TCP (EGC30n.exe+ Host Gui_rcView.dll) (rcHost.exe) RC Session
Capture Helper (rcUtilCmd.exe)
SM SM Address books TRC_URC_UTILCMD_ Registration+ SM Host Commands n.log authentication
SQL RC Server RC Manager (rcServer.exe) SM (rcManSrv.exe) Registration + Authentication
TRC_URC_SERVER_n TRC_URC_MANSRV_ .log 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 user’s permissions.
September 2007 Chapter 8: Remote Control Connection 8- 3 Getting the Authority List
Depending on which manager hierarchy is in place, the Global Address Book that is returned may be either a Domain Address Book or an Enterprise Address Book.
The following MDB Tables are used to store address book information:
urc_ab_computer – Computers in the address books
urc_ab_group_def – In which groups computers/groups appear
urc_ab_groups_member – In which groups computers/groups appear
urc_ab_permission – User permissions applied to a group
RCMgrAddressBook caches the information locally on the Viewer where it is only used if the manager connection fails.
Getting the Authority List
The following process is used to obtain the Authority List:
1. Viewer establishes connection to Host and sends M_STATUSQUERY 2. For Centralized Security the following occurs:
RC Messenger sends request to RC Server (or Manager)
RC Server forwards request to RC Manager
Manager returns authority list and authentication scheme list from CCL security
Host caches the list
3. Host sends M_STATUSREPLY to Viewer containing results
8–4 Desktop and Server Management Advanced Topics Guide September 2007 Getting the Authority List
Here you can see a graphical depiction of the process:
September 2007 Chapter 8: Remote Control Connection 8- 5 Getting the Authority List
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:
8–6 Desktop and Server Management Advanced Topics Guide 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.
Connecting to the Desktop
Terminal Services allows several users to log onto a machine at the same time. XP Fast User Switching is a specialized case of this multi-login capability. On Windows NT4 and earlier there is effectively only one Terminal Services session. On Linux each local X Server (in X terminology it is the X Server that is responsible for rendering a desktop) is treated as a Terminal Services session.
Each RC Session (CRCSession object) is associated with a CRCTerminal object. The CRCTerminal object represents the Terminal Services session to which the RC Control session is connected. Currently, RC can only control the “Console” TS session - the session currently connected to be controlled by the remote machine’s local keyboard, mouse and display. However, RC Sessions can switch between TS sessions if the console switches.
September 2007 Chapter 8: Remote Control Connection 8- 7 Connecting to the Desktop
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.
8–8 Desktop and Server Management Advanced Topics Guide September 2007 Connecting to the Desktop
rcUtilCmd creates a CRCInputClient object, which opens an IPC pipe to the parent process. CRCInputProxy serializes the API calls made through IRCInput, and sends them via IPC to the Input Client. The Input client reads messages from a thread, CRCInputClient::ProcessPipeMessages and calls into a real CRCInput instance, returning the results through the IPC channel.
The RCInput API is synchronous. API calls which have a return value block until the results are returned. To the Host, CRCInputProxy behaves exactly like CRCInput
The rcHost.exe service process cannot display user interfaces directly, this is primarily due to security concerns running as the System user and Fast User Switching/Vista Compatibility.
rcHost controls the RCHostGUI component in another worker process. Normally RCHostGUI runs inside CAF’s system tray process (cfSysTray.exe) though it can be launched inside a dedicated rcUtilCmd process if cfSysTray is not available.
September 2007 Chapter 8: Remote Control Connection 8- 9 Displaying Confirmation Dialogs
rcHost controls the Host GUI through the IRCHostGUI interface while CRCHostGUI provides the actual implementation of the GUI, including the system tray menus.
CRCHostGUIProxy implements the IRCHostGUI interface, transparently proxying all calls to the CRCHostGUI object in the GUI worker process.
CRCHostGUIStub reads messages from the GUI Proxy, and converts them into calls into CRCHostGUI
CRCGUIPipe implements the IPC between the proxy and the Stub
The Chat GUI shares the RC GUI pipe connection with the system tray if available. Otherwise, a dedicated rcUtilCmd.exe process hosts the chat GUI for each Terminal Services session
Displaying Confirmation Dialogs
Each CRCTerminalObject controls the Host GUI for that TS session. CRCTerminal objects are created on-demand. The Host GUIs run independently, and listen for connections on their IPC GUI Pipes
CRCSession::GetConfirmation() checks to see if end-user confirmation is required. If no one is logged on, the “override confirm at login” policy is used to determine what to do. If confirmation is required, a WAITFORCONFIRMATION message is sent to the viewer, to update the UI.
The IRCHostGUI::ShowConfirmDialog function is called to prompt the user. The result from the dialog is sent as a WM_ENDDIALOG message via the Host’s internal message loop, and processed in CRCSession::ProcessMessage.
If all is successful, CRCSession::AcceptLogin is called, which sends an M_CONNACC message to the Viewer.
Starting Remote Control
Once the login is complete, the Viewer sends M_CONNACC, VIEWER_PROTOCOLS and VIEWER_FONT_CACHE messages to the Host. When received, the host calls CRCSession::StartViewing, from the main host thread.
The video capture components for the target TS session are managed by a CRCDisplay object owned by the CRCTerminal. The CRCDisplay object maintains a list of “Graphics Targets”, which includes RC Sessions, per-session host side recordings and manual recording sessions.
8–10 Desktop and Server Management Advanced Topics Guide 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 DSM’s common configuration (i.e., comstore) and converts IRCConfig interface calls to CCNF Agent API.
RC Config Keys are DSM Paramsections
RC Config Values are DSM Parameters
RC Config Settings are DSM attributes within a Parameter
RCTrace emulates the old IRCTrace interface. It sits on top of DSM’s common tracing (i.e., cftrace) but it does not trace line numbers or source files. New RC code will use CCL tracer directly.
Diagnosis Tips
The video capture threads process an incredible throughput of packets. There is no tracing during normal operation of the video capture after start up.
Beware of threads when analysing the Server or Manager logs. There can be several worker threads servicing different requests concurrently. Use a log analyser to filter out irrelevant execution paths.
The tracing from the RC Viewer GUI can be spread across a number of trace files. Some of the common components are shared between the different GUI plug-ins, so the trace from these components will appear in the wrong place. Use a log analyzer to combine the log output, and then filter.
CCNF, RC Messenger and Session Messaging produce a lot of tracing so filter it using a log analyser. The following trace files are available:
TRC_URC_HOST_n.log – rcHost process logs
TRC_URC_HOSTGUI_n.log – Host GUI logs, from system tray
TRC_URC_UTILCMD_n.log – rcUtilCmd worker logs
TRC_URC_VIEWER_n.log – RC Viewer GUI log
TRC_URC_WRAPPER_n.log, TRC_URC_REPLAYER_n.log – Viewer trace from CCL may appear here
TRC_URC_SERVER_n.log – Server logs, very heavily laden with noise
TRC_URC_MANSRV_n.log – Manager logs
September 2007 Chapter 8: Remote Control Connection 8- 11
Chapter 9: Delivering Software
This chapter provides a closer look at the software delivery process including:
General flow
USD Shares
USD Directory structure
Key USD files
Key USD MDB tables
OS processes, names, aliases and trace files for USD and DTS
Process flow and log files for USD and DTS
DSMinfo Collection Guide
Troubleshooting tips
Additional DTS Considerations
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 Chapter 9: Delivering Software 9–1 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).
9–2 Desktop and Server Management Advanced Topics Guide 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 package’s installer is executed.
5. The status of the package delivery/installation is reported back to the originating manager at various stages throughout the process.
One of the first steps in troubleshooting is to determine at which point in this process the problem occurred. For example, the failure of a software package to install on a target may be the result of a faulty package creation, an improper library registration, a communication failure between components during package transfer, or a resource/environmental deficiency on the part of the target system.
The following graphics are provided to give you a better understanding of the communications that occur between each of the Software Delivery components.
First is the relationship between the UI and the Manager:
September 2007 Chapter 9: Delivering Software 9- 3 Overview and Flow
Next is the relationship between the Enterprise and Domain Manager:
Here you can see the Domain Manager to Domain Manager communication:
9–4 Desktop and Server Management Advanced Topics Guide 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 Chapter 9: Delivering Software 9- 5 Overview and Flow
When DTS is used, activation occurs as follows:
9–6 Desktop and Server Management Advanced Topics Guide 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 Chapter 9: Delivering Software 9- 7 Overview and Flow
Here you can see the response:
The following graphic demonstrates the distribution of orders between the Domain Manager and Scalability Server:
9–8 Desktop and Server Management Advanced Topics Guide 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 Chapter 9: Delivering Software 9- 9 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:
9–10 Desktop and Server Management Advanced Topics Guide 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:
\\
\\
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 Chapter 9: Delivering Software 9- 11 USD Directories
USD Directories
The following directories are used by the Software Delivery components:
Library Used By Used For Configuration Parameters
\SD\ASM\LIBRARY APISRV (EM + DM) Permanent location for Itrm/usd/shared/archive TASKMAN (EM + software packages DM) SDSERVER SDSSCMD SDDTAFLT
\SD\ASM\MSILIB SDSSCMD MSI administrative Itrm/usd/shared/msiadminp SDMSIEXE (via software pckgs ath SDJEXEC)
\SD\ASM\D TASKMAN (EM+DM) Incoming and outgoing Itrm/usd/shared/incoming SDSERVER DTS transfers Itrm/usd/shared/outgoing SDDTAFLT
\SD\ASM\TMP SDJEXEC Incoming DTS transfers \FLTSTAGE SDDTAFLT
\SD\ASM\LIBRARY TASKMAN (DM) Temporary location for Itrm/usd/shared/asmtemp \ACTIVATE SDSERVER s/w pckgs for NOS- (+”/activate’”) 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) Non-MDB computer info, Itrm/usd/shared/database SDSERVER DTS control files, and host identity and notification data
\SD\ASM\CONF SDJEXEC MSI detection file, SDMGRMIG migration MSI map file, agent state file and text-file based agent customization data
9–12 Desktop and Server Management Advanced Topics Guide September 2007 USD Directories
Library Used By Used For Configuration Parameters
\SD\ASM\DEVICE SDPILOT Integration DLL for Palm Pilots, and other device- specific data
\SD\TMP SDJEXEC Temporary files SDMGRMIG
\SD\IPC SDJEXEC Signaling to agent from SDACMD install programs
\SD\NLS Nearly all SD Stores localized SD programs resources
\SD\AUTOREG TASKMAN DSM s/w pckgs are located here by the DSM installer and imported to the MDB and SW library at first CAF start of the SD manager
\SD\Legacy Administrator Contains USD 4.0 API install image. Prereq. For SDMGRMIG if API connection to USD 4.0 Local/Enterprise Server is to be successful. Only needed if no co- hosting exists
\ServerDB\SWJORDER SDSERVER Temporary location for Itrm/scalability_server/serv s/w job orders and erdb_path (+”/swjorder”) results and s/w detection records. Also location for server- specific agent identity data
\Agent\units\
September 2007 Chapter 9: Delivering Software 9- 13 USD Files
USD Files
The following files are used by Software Delivery:
\ServerDB\SWJORDER\
\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\
\SD\ASM\DATABASE\compjobs\
\SD\ASM\DATABASE\compjobs\
\Agent\units\
Used by SDJEXEC to keep the state of job containers. The extensions are as follows:
*.cof = not started *.cwf = working *.crf = completed
9–14 Desktop and Server Management Advanced Topics Guide September 2007 MDB Tables
MDB Tables
The Software Delivery function uses the following MDB tables:
Table Used for
Usd_swfold Software group, procedure group, catalog group (DM only)
Usd_job_cont Software job container, software policy
Usd_activity Software job, software policy job
Usd_rsw Software package
Usd_actproc Software procedure
Usd_applic Application (DM only)
Ca_group_def Asset group
Usd_v_target Asset
Usd_v_ownsite(EM) Enterprise Manager Usd_v_csite (DM)
Usd_v_ownsite (DM) Domain Manager Usd_v_ls (EM)
Usd_cont (+usd_cc, usd_carrier) Distribution container
Usd_order (+usd_distsw, Distribution order usd_distap, usd_disttempl, usd_fio,usd_fitem)
In addition, other supplementary tables, prefixed by usd_* are used.
September 2007 Chapter 9: Delivering Software 9- 15 Process, Trace and Log Files
Process, Trace and Log Files
The following process and log files are used at the Manager Level:
Process (EXE) CAF Name Logical Name Description Trace File Name
Sd_taskm Sdmgr_tm Task Manager Main job evaluation Trc_usd_taskm_x.log Engine
Sd_taskm Sdmgr_im Installation Mgr. Job results collecting Trc_usd_instman_x.log Engine
Sd_mgr_ft Sdmgr_ft File Tranfer mgr. File transfer Engine Trc_usd_sdmgrft_x.log (enterprise r11.2)
Sd_dtsft n/a DTS Integration Legacy file transfer Trc_usd_dtsft_x.log Engine (removed in r11.2)
Sd_dtpush n/a DTS integration Legacy file transfer Trc_usd_sddtpush_x.log Engine (not in r11.2)
Sd_apisrv Sdmgr_api_# API server Client counterpart TRC_usd_apiserver_x.log used by UI to perform USD specific operations
Sd_dialog_m Sd_mgr_dm Dialog Mgr Client counterpart Trc_usd_dialogm_x.log used by UI to obtain free sd_apisrv. Essentially, a dispatcher
Sd_ahdcmd n/a Service Desk Used for integration Trc_usd_sdahdcmd_x.log Integration with Unicenter Service Desk
9–16 Desktop and Server Management Advanced Topics Guide September 2007 Process, Trace and Log Files
The following table depicts the details for the DSM Explorer and Scalability Server components:
Process (EXE) CAF Name Logical Name Description Trace File Name
Egc30N n/a SD Explorer UI Trc_GUI_x.log
Sd_registerproduct n/a SW Package Registers SXP, PIF, registrator PKG and RPM packages. Called by DSM Explorer
Sd_server Sdserver SD Scalability Handles all software Trc_usd_sdserver_x.log Server Plug-in jobs
The following table depicts the details for the DTS – on the Agent Tier:
Process (EXE) CAF Name Logical Name Description Trace File Name
Tngdta dtsagent DTS Transfer (Master) Persistent Trc_dtsagent_x.log Agent 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 DTS Browser DTS Object Not used by USD Trc_dtsbrowser_x.log Browser
Dtsitrm.dll TCP Protocol wrapper using DSM Networker
Dtstcp11.dll TCP protocol wrapper
September 2007 Chapter 9: Delivering Software 9- 17 Install Packages and Trace Files
The following depicts the details for DTS on the Manager tier:
Process (EXE) CAF Name Logical Name Description Trace File Name
Tngdtos Dtstos DTS Transfer Main DTS data Trc_dtstos_x.log Object Server transfer Engine. Responsible for all managed transfers
Tngdtsnos Dtsnos DTS Network (Not req. in r11.1). Trc_dtsnos_x.log Object Server Calculates the best transfer route according to CCS WV.
Tngdt.dll n/a DTA API Main API used to TRC_DTS_x.log communicate with DTS (USD, DTS CLI,etc)
Tngdtsos dtssos DTS Scheduler Enables scheduling of Trc_dtssos_x.log Object Server 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 AfterCopy DSM Install Trace Installer Trace
Manager.msi SDMgrAfterCopy TRC_inst_ITRM_x.log DSMSetupManager.log
Manager.msi DtsManagersAfterCopy + TRC_Inst_ITRM_x.log DSMSetupManager.log DtsCommonAfterCopy
Server.msi SDSvrAfterCopy TRC_Inst_ITRM_x.log DSMSetupScalability Server.log
AgtSD.msi SDAgAfterCopy TRC_Inst_ITRM_x.log DSMSetupAgentSD.log
AgtDTS.msi DtsAgentAfterCopy + DtsCommonAfterCopy
Explorer.msi n/a TRC_Inst_iTRM_x.log DSMSetupExplorer.log
9–18 Desktop and Server Management Advanced Topics Guide September 2007 USD Logical Process Flows and Log Files
Following is the corresponding list for Linux installs:
S/W Pckg AfterCopy DSM Install Trace Installer Trace
Ca-dsm-sd- SDMgrAfterCopy TRC_*_x.log Ca-dsm.*.log manager.Linux.@pif
Ca-dsm-sd- SDSvrAfterCopy TRC_*_x.log Ca-dsm.*.log server.Linux.@pif
Ca-dsm-sd- SDAgtAfterCopy TRC_*_x.log Ca-dsm.*.log agent.Linux.@pif
Ca-dsm-dts- DtswAgentAfterCopy + TRC_*_x.log Ca-dsm.*.log agent.Linux.@pif DtsCommonAfterCopy
If the installer is driven by the Install Shield master setup (in other words, it is running from the DVD) all installation trace files will end up in the %TEMP% directory of the user that initiated the install. On Linux, the interactive install will generate trace files in the /tmp directory.
If, on the other hand, the installer is driven by an SD Job all DSM install trace files will end up in the system %TEMP% and /tmp directories. The Installer trace will be appended as output to the SD job and reported up to the manager. There it can be viewed (and copied) using the DSM Explorer by navigating to the failed leaf computer job node and opening its properties and choosing the Output tab.
USD Logical Process Flows and Log Files
The following graphics depict the relationship between USD logical processes and the log files that are generated. The first graphic applies to the r11.1 release:
September 2007 Chapter 9: Delivering Software 9- 19 USD Logical Process Flows and Log Files
9–20 Desktop and Server Management Advanced Topics Guide September 2007 USD Logical Process Flows and Log Files
Following is the corresponding information for r11.2:
September 2007 Chapter 9: Delivering Software 9- 21 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.
9–22 Desktop and Server Management Advanced Topics Guide 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 ERROR–s 2000 Cftrace –c set –f DTS –l ERROR–s 2000
Even though a failure may appear to only involve a single host most of the time it involves multiple hosts in a distributed environment. Therefore “dsminfo” should be collected from all machines that are involved. For example, if a job fails to execute on an agent, you should always collect the “dsminfo” from the appropriate Manager and Scalability Server in addition to the affected agent.
The USD and DTS audit messages are via the Event Logger; for 11.1 this means that these messages end up in the Windows Application event log and for 11.2 they will end up either in the Windows Application event log or the CCS Event console.
For a list of common troubleshooting tips consult the DSM Diagnostics Guide.
Additional DTS Considerations
Be aware that CCS integration is not provided in DSM r11.0 and r11.1. This means that if DTS 3.0 (USD 4.0) has been configured with WorldView to use DTS Routing information then this information will not be available when upgrading to DSM r11.0 and r11.1.
All DTS versions prior to r11 are upgraded to DTS r11 when DSM r11 is installed; DTS does not co-exist with its earlier releases. In this respect DTS is backwards compatible with all earlier DTS versions.
September 2007 Chapter 9: Delivering Software 9- 23 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.
9–24 Desktop and Server Management Advanced Topics Guide 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 10–1 OSIM Architecture
The OSIM infrastructure consists of the following:
Manager plug-in that controls the installation process
DSM Explorer and DSM CLI plug-ins
Support for preparation of OS and BOOT images
Tools to setup and configure OS
PXE/TFTP Book Server (a Scalability Server plug-in)
Here you can see how OSIM components fit into the DSM architecture:
Following is a more detailed graphic depicting the relationship between OSIM components:
10–2 Desktop and Server Management Advanced Topics Guide September 2007 OSIM Architecture
DSM Explorer CADSMCMD
OSIM queries OSIM plugin OSIM extensions
DSM Domain Manager
SD SW library OSIM Manager plug-in DSM SD pkg of Boot and OS (CSM) MDB image
Store info Install boot and OS OS installation jobs about Boot images in the Register Boot with boot parameter. and OS image store of and OS images State of Jobs, Boot images Server and Image remote Boot as SD package Server
Scalability Server DSM Packaging Tools
Boot and OS Image OSIM Boot Server Store + FCOR OSIM Boot and OS plug-in Image Prepare System
Load Boot, OS PXE Data and Boot DOS boot Image IPS can share parameter diskette and Custom built image store with original OS WinPE, PXE Target Boot Server including OSIM Computer CD 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.
10–4 Desktop and Server Management Advanced Topics Guide September 2007 Installation and Configuration
Note that the Software Delivery Agent is installed automatically. This ensures that Software Delivery can be use for subsequent installation of additional DSM Agents and applications.
Installation and Configuration
The (CSM-OSIM) Domain Manager plug-in is always installed with the Software Delivery Domain Manager. It uses the MDB and the communication of the DSM Manager and has no special configurations itself.
The OSIM Boot Server is a DSM Scalability Server plug-in that requires the following configuration:
Enabling support for Windows network shares (default is tftp)
Selecting destination location for the image store
If the path is not during the installation it can be configured later in the local comstore of the Boot Server with the following command:
ccnfcmda –cmd setparametervalue –ps /itrm/scalability-server/osim/ManagedPC –pn InstallPath –v
If the Boot Server is configured for share access, on LINUX, the Samba server has to be installed.
September 2007 Chapter 10: OSIM 10- 5 Installation and Configuration
If you plan to provide LINUX OSIM images from the Boot Server:
On LINUX the NFS server must be active
On Windows UNIX Services for Windows 3.5 or later must be installed
The Boot Server is active and answers to new targets if no other Boot Server answers. To deactivate and disable the Boot Server process, use the following commands:
caf stop sdmpcserver caf disable sdmpcserver
To enable and activate the Boot Server process use the following commands:
caf enable sdmpcserver caf start sdmpcserver
Multiple Boot Server (BS) in a PXE broadcast network
When there are multiple Boot Servers in a PXE broadcast network, the default behavior, from the administrator’s view, is that all new targets will be answered by all Boot Servers. The target picks up the first reply. However, you should be aware that, if two Boot Servers from two Domain Managers are in the same PXE broadcast network the following will occur:
If PXE is enabled later on an existing DSM target, the OSIM target can be picked up and reported to the wrong Domain Manager.
If the responsible Boot Server is down the computer will be picked up by the other Boot Server and can appear in both Domain Managers.
To install an additional Boot Server from the installation media you will need to install the Scalability Server as well because the Boot Server is part of it.
If the Boot Server system already has a DSM Agent installed you can also use Software Delivery to install the Boot Server by selecting the "CA Unicenter DSM Scalability Server" package from the DSM Explorer.
Prioritization of Boot Server with Remote Configuration
In a remote configuration, Boot Server prioritization is specified through the following values:
10–6 Desktop and Server Management Advanced Topics Guide September 2007 Installation and Configuration
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 Chapter 10: OSIM 10- 7 Image Prepare System (IPS)
This setting is only evaluated if "UseACL" is set to “1”.
Image Prepare System (IPS)
The Image Prepare System (IPS) reads the OS files from the vendor’s media and combines this with the OSIM files to create OSIM OS images and Boot Images. Here you can see an architectural overview of the Image Prepare System (IPS):
Both Boot servers and IPS work with an existing image store, however, IPS also provides setup scripts, tools and configurations for most Windows and LINUX unattended set ups.
Note: OSIM OS images can be based on the original setup or, for cloning on GHOST, PQ images captured from a model computer.
OSIM currently supports the following target operating systems and releases out of the box:
Win9x, WinNT (DOS boot)
W2K, W2K Server (WinPE or DOS boot)
WXP, Win2003 (WinPE or DOS boot)
GHOST images of W2K, WXP, Win2003 (DOS boot)
10–8 Desktop and Server Management Advanced Topics Guide 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. Create Boot Images 2. Register Boot Images 3. Create OS Image 4. Register OS Image 5. Prepare the Target for Network Boot 6. Boot the Target 7. Change the Target to Managed 8. Modify Job Parameters 9. Activate the Install Image 10. Boot the Target to Initiate the install
Create Boot Images
The first step is to create a Boot Image. You can create a DOS Boot Image from a Win98 Boot Floppy or MSClient (if the image is used for share access). The MSClient can be obtained from a Windows NT 4 Server CD or from a Microsoft FTP server.
Another option is to create a WinPE Boot Image. To do this you would start with prepared WinPE in a directory structure and add the CA tools to create an ISO image.
If you use a WinPE Boot image the BOOTDOS network bootloader is downloaded from the Boot Server and executed by the PXE BIOS as follows.
September 2007 Chapter 10: OSIM 10- 9 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.
10–10 Desktop and Server Management Advanced Topics Guide 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 MS- Client, the image can only be used from Boot Servers using TFTP download.
2. Adds CA tools and files from IPS templates ..\osimips\templates\Dos\net\*.* to A:\net
tftp.exe (tftp download client)
canet,exe (partitioning tool)
ndis.dos (generic network driver using PXE protocol from BIOS)
setopdat.exe (parameter read, substitute)
netstart.bat, protocol.ini, system.ini, wfwsys.cfg, shares.pwl (MSclient configuration)
3. Adds CA autoexec.bat from the following directory:
..\osimips\templates\Dos\AUTOEXEC.BS2 to A:\autoexec.bat
4. Creates osinstal.2 image using copy144.exe
September 2007 Chapter 10: OSIM 10- 11 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
10–12 Desktop and Server Management Advanced Topics Guide 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-12345- abcde
This syntax creates an image called “myhost2” using a Windows XP GHOST image located on c:\myhost2 drive and directory with a product key of “abcde- 12345-abcde-12345-abcde.”
September 2007 Chapter 10: OSIM 10- 13 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:
10–14 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 15 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:
10–16 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 17 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
10–18 Desktop and Server Management Advanced Topics Guide 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\ Boot disk operating system image store
bootdos DOS network boot loader
boothd Network boot loader which jumps to Hard Disk boot
UNDI\ RAM disk image files DOS, WinPE
osinstal.2 Raw DOS Diskette Boot image (first step)
osinstal.3 Raw DOS Diskette Boot image (second step)
winpex86.2 Boot image description files
winpex86.2\ Boot image directory belonging to the description file
Winpex86.iso
Winnt.sif
Ntdetect.com
ntldr
startrom Boot Loader
Here you can see the OS- image templates under the \camenu folder:
September 2007 Chapter 10: OSIM 10- 19 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
10–20 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 21 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
10–22 Desktop and Server Management Advanced Topics Guide 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
;--read setup files from CDs but image is on external NFS Server (-a
;--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
September 2007 Chapter 10: OSIM 10- 23 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 files to copy from CDs [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 ……………
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:
10–24 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 25 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 [
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
10–26 Desktop and Server Management Advanced Topics Guide September 2007 Under the Hood
item=2057 English UK item=1036 French Standard
To check the new parameter execute the following command:
RegisterOSImage -i
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
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 in to the remote Domain Manager using the following procedures:
1. Export the OS-SD package into a directory.
2. Transfer the directory to the remote site. 3. Import the OS-SD package with the following command:
Registerosimage -w directory -s Domain Manager
September 2007 Chapter 10: OSIM 10- 27 Under the Hood
Special Preparation for GHOST and PQIMG Based Images
Use the following steps to create a clone image:
1. Create a share (read, write) on IPS (including the ghost.exe). 2. Create a FAT, FAT32 primary partition on the model target. 3. Install the model OS (without DSM Agent) in the partition. 4. Copy the MS sysprep files to the model PC and execute sysprep. 5. Boot from a DOS Boot floppy with network access. 6. Mount the share on IPS and execute ghost.exe from the share. 7. Store the
Upgrade Procedure for OS-SD packages
The Software Delivery package upgrade procedure deploys the OS image package to the target via Software Delivery and executes the winnt32.exe /upgrade in the package.
Note: The unattended auto answer update.inf file also contains the Product ID.
To set the product key in the default.ini, use the following syntax:
CreateOSImage …. –k
The following command makes a copy of the update.inf template to the OS image and sets the product key from the default.ini:
RegisterOSImage
Note: The upgrade depends on the ability of the OS to upgrade a live system with a new OS version.
10–28 Desktop and Server Management Advanced Topics Guide September 2007 Under the Hood
OSIM Domain Manager Plug-in
Follo wing depicts the OSIM Domain Manager plug in.
OS Installation Job States
You can monitor the state of the OS Job installation through the DSM Explorer. There are three possible job configurations:
The current OS is the last successfully installed OS
A planned OS is used to define an OS installation Job
An activated or pending job is awaiting installation
September 2007 Chapter 10: OSIM 10- 29 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:
10–30 Desktop and Server Management Advanced Topics Guide September 2007 Under the Hood
Class Name Class ID Properties
BootDiskImage 1006 Type, sdname, sdversion, sdcomment, detected
BootOSImage 1008 Type, sdtype, locale, externalos, batchfile, sdname, sdversion, sdcomment, detected
Bootparameter (for OS 1002 Type, Maxlength, Minvalue, Images) Maxvalue, Trans, item (additional parameter values)
Parametervalue (for OS 106 See below images)
Bootconfiguration (for OS 1004 Bootstatus, Configstate, installation jobs) Configstatetime, Activationtime, Waitforagent, Retrytime, requesttime
Computer 102 Dnsname, hostname, hostuuid, macaddr, firstseen, bootfile
Bootserver 1000 Lastheard, lastreportallrequest, lastreportall, status
Here you can see how the properties for Parameter value are derived:
….
Here you can see how properties for the Boot Server Class are derived:
September 2007 Chapter 10: OSIM 10- 31 Under the Hood
Special Bootstatus Property
The following values are used to identify a job’s bootstatus:
Value Status
1000 Current
2000 Stopped
3000 Cancel pending
4000 Failed
5000 Set if delete is ordered for job
6000 Boot server not responding
7000 Unmanaged
8000 ADS Managed
10000 Planned
11000 Activated
20000 Analyzing
21000 Pending
22000 Installing
The computer’s bootstatus will be taken over from the job (configuration). If there is more than one configuration (planned, current, activated) the state of the highest configuration will be set.
10–32 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 33 Under the Hood
10–34 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 35 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 Server’s image store and monitors TFTP file transfers for special image files in order to set the next boot image in a sequence of images.
Following are parameters used for Boot Server Configuration:
TFTPD_RedirectPort (Port to redirect TFTP requests) Min = 0, Max = 65535, Default = 0 Port to redirect tftp requests to, if another tftp server is available. 0 means no redirection.
LogTftpFileRequests (Log TFTP file requests) If set to enabled(1) then all tftp file requests are reported to the event 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.
10–36 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 37 Under the Hood
OSIM Boot Server Ping Thr e ad
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.
10–38 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 39 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:
10–40 Desktop and Server Management Advanced Topics Guide September 2007 Under the Hood
Following is a list of reports that can be launched to the Manager by the sdbsmstate (Csmagent):
Report Description
Bsinfo Report Boot Server status
Bscompinfo Report status of assigned PXE target machine(s)
Bsosinfo Report available OS images
Bsbtinfo Report available boot images
Bsbreginfo Report PXE boot requests and ADS devices
Following is a list of requests and jobs that can be sent from the Manager to the sdbsmstate (Csmagent):
Request Description
Bssync Synchronize list of assigned PXE targets with manager MDB
Bsstartpxe Start answering PXE requests
Bscompinstall Activate OS installation job
Bscompcancelinstall Cancel active OS installation job
Bscompremove Remove computer from list of assigned PXE target machines
September 2007 Chapter 10: OSIM 10- 41 Under the Hood
Request Description
Bscompserve Add computer to list of assigned PXE target machines and abort active OS installation
Bscompwol Wake up target computer
The OSIM Manager sends the reboot request for a target to the sdbsmboot (Csmagent) to the target’s agent. Bslocalreboot triggers local reboot (provided by DSM Agent).
Boot Server Administrative Files
Administrative files for sdbsmstate are kept in the following location:
c:\Program Files\CA\DSM\Server\SDBS\var\ManagedPC.
Sdbsmstate reports changes of Boot Server data to the manager only once. The following files are used as memory for reports:
Filename Contains
Bsmbreq.dat Reported boot requests
Bsmconf.dat Start data of the job to compare with FCOR
Bsmimgb.dat Reported boot images
Bsmimgo.dat Reported OS images
Bsminfo.dat Sent hello (alive) messages
Bsmstat.dat Reported state changes of install jobs
Here you can an example of the contents for a bsmimgo.dat file:
10–42 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 43 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
10–44 Desktop and Server Management Advanced Topics Guide September 2007 Under the Hood
File name Contains
Mac.acl MAC of all targets the Boot Server is responsible for
Man agedPCDataFile (FCOR) basic PXE data of targets (binary format). A test tool listfcore shows the contents
PXEBoot.log MAC of a newly picked up target until the manager accepted the boot sever relationship and the MAC is added to mac.acl
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 server’s sub network.
Most router configurations will not forward WOL magic packages to all subnetworks
Additionally the Boot Server plug-in, sdbsmstate, looks into the common server target list (IP, subnet masks) to create a list of subnet addresses where DSM targets are located.
The sdbsmstate sends a WOL package to the broadcast address of each calculated subnetwork.
Boot Server Access from Target
Boot Server access from target is managed either through share mode access or TFTP access:
The target reads the OSIM OS image files from Boot Server’s image store
A Boot Server provides access to the image store via shares or via TFTP.
September 2007 Chapter 10: OSIM 10- 45 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 acce ss mode. The sdbsswitch command creates or removes the OSIM shares and changes the i mage 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)
10–46 Desktop and Server Management Advanced Topics Guide 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 sh a res can also be provided on a central Windows or Linux server, howev e r, the directories and the NFS share must have read access rights for anonymous.
September 2007 Chapter 10: OSIM 10- 47 Under the Hood
IPS and Boot Server on One System
When Boot Server is in TFTP mode the Createosimage -i
createosimage –z
For a Linux OS image, createosimage tries to create an NFS share if the following is fulfilled:
Unix services for Windows 3.5 is installed
LINUX image is not on an external NFS share (-a
Use of Microsoft Automated Deployment Services (ADS)
DSM Boot Server can coexist with the ADS Boot Server
Because of an arrangement between CA and Microsoft, ADS and DSM OSIM should be able to coexist
Microsoft ADS can be downloaded from Microsoft and requires Windows 2003 Enterprise Server
Microsoft ADS has it‘s own user interfaces and management functionality. DSM only synchronizes the target responsibility on Server level between DSM Boot Server and ADS Boot Server.
The ADS managed targets are contained in the MDB and visible (but not manageable) in DSM
If OSIM Boot Server is used as an ADS proxy the following applies:
The Boot Server will ask the ADS server before it answers PXE requests of a special target. The Boot Server will not answer if the target is ADS managed.
If the customer adds PXE targets to the ADS server, the configured OSIM Boot Server will be notified from the ADS server.
The Boot Server reports the ADS managed targets to the DSM domain manager. These targets will be marked as ADS managed in the MDB.
The Domain Manager also removes all OSIM jobs from that target.
If the PXE target is removed from the ADS server, the configured Boot Server and the Domain Manager will be notified from the ADS server. The target becomes an unmanaged OSIM target again.
10–48 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 49 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
10–50 Desktop and Server Management Advanced Topics Guide 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
Architectural Overview
Foll owing is an architectural overview of CADSMCMD:
September 2007 Chapter 10: OSIM 10- 51 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=
SDCMD_TRACE_OPT=B3C9
10–52 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 53 OSIM and CADSMCMD
–
–
– 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 Description
Create Creates a computer DSM that is SD and OSIM enables
List Lists DSM computers that are SD agents and OSIM un-managed PC
showAttr Shows the attributes of a computer including OSIM information about OSIM configurations
setupOS Assigns a new OS image to an OSIM un-managed but registered computer
modifyOS Assigns a new OS image to an OSIM- managed computer
showInstallParameter Lists the installation parameters of an OSIM configuration
modifyInstallParameter Modifies installation parameters in a planned configuration
Delete {planned|scheduled}OS Deletes the specified OSIM configuration of a required type
10–54 Desktop and Server Management Advanced Topics Guide September 2007 OSIM and CADSMCMD
Action Description
activateOS Schedules a planned OS configuration for installation
reactiv a teOS Reschedules a failed or canceled configuration
reinstallOS Schedules the current OS configuration for reinstallation
cancelOS Cancels a schedules OS installation request (graceful)
Delete 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 Chapter 10: OSIM 10- 55 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»] [softw a reManagedSystem[={y|n}]] [racPo li cy={common | disabled | deferred | automatic}] [hostName=«host name»] {[mac A ddress=«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}]] [res tart[={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.
10–56 Desktop and Server Management Advanced Topics Guide 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 Chapter 10: OSIM 10- 57 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 ima ge, 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.
10–58 Desktop and Server Management Advanced Topics Guide September 2007 OSIM and CADSMCMD
The final result is a new system on which the OS has been installed through OSI M and the required applications have been installed and configured through Software Delivery.
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 Chapter 10: OSIM 10- 59 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.
10–60 Desktop and Server Management Advanced Topics Guide 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 won’t 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 Chapter 10: OSIM 10- 61
Glossary
Application Programming Interface (API) An interface that allows programs to communicate with a product
ADSI Active Directory Services Interface
AMS Asset Maintenance System
BABLD Brightstor ARCcserve Backup for Latops and Desktops
Boot Server The OS Installation Management (OSIM) Boot Server is installed as part of a scalability server. The Boot Server installation automatically provides a TFTP server (with reduced access rights) and a PXE server.
CADSMCMD Command line utility for Desktop and Server Management.
CA Messaging (CAM) CAM (CA Messaging) is an established component used by several CA products to allow inter process communication, without the peer processes needing to be aware of exactly where their peer is located or without both entities or the network connecting them needing to be operational at the point of sending a message.
Common Configuration (CCNF) The Unicenter DSM products are configured centrally and locally through a shared component, typically referred to as “common config” or “CCNF”. This components acts like an “enhanced Windows registry.” It manages the runtime configuration of practically all of the DSM subcomponents and infrastructure features, though there are some exceptions.
Common Architecture Framework (CAF) Cross-platform service control manager, which provides a single point of control for all Unicenter DSM components. CAF dynamically provides Unicenter DSM services as required using an extensible plug- in model. Each CAF plug-in is a program, which provides agent, scalability server, or manager functionality. A CAF plug-in can also be an extension of CAF itself, which provides some common service, for example, registration with scalability servers or system event detection.
Command Line Interface (CLI) A user interface where the user communicates with a product by commands. This interface allows you to automate the usage of a product by using the cli commands from a script.
September 2007 Glossary–1 OSIM and CADSMCMD
Common Component Library (CCL) The CCL provides common services that are used by many DSM components, including trace, configuration, security, and directory integration.
Configuration and State Management (CSM) Configuration and State Management is a framework for configuring objects like software products or operating systems and tracking the status of those objects. It is used e.g. by OSIM.
Common Registration API (CORA) All Unicenter r11 products utilize the common MDB schema to store and manage their data. CORA provides the interface through which these assets are registered and as the only source for updating these tables, (CORA) ensures that asset data flows consistently, thereby supporting the data and referential integrity of the Mob’s master asset data model.
Content Management System (CMS) The content management system (CMS) is a central repository hosted by CA and available via the public internet. CMS contains information about all known software, including patch and fix recognition information (signatures).
Data Transport Services (DTS) The Data Transport Service (DTS) infrastructure provides end-to-end management of content delivery securely, reliably and efficiently across multiple platforms, protocols, networks and data formats, helping clients to synchronize, distribute, update, replicate and validate data across his/her enterprise. Data may be gathered from one system and transported to many others (one-to-many), or it may need to be gathered from multiple systems and then sent to one (many-to-one).
Database Access Interface (DAI) A standardized programming interface used by a component or process to access the DSM database.
Detailed Design Specification (DDS) A representation of a software system or component of a system created to facilitate analysis, planning, implementation and decision-making. The DDS is used as the primary medium for communicating software design information.
DMAPI The DMAPI is used by deployment consumers, such as damsel and the Deployment Wizard, to communicate with the manager. All user-visible deployment functionality is driven through the API.
DM Primer DM_Primer handles payload transfer and payload installation execution.
Domain Server (DS) Desktop and Server Manager architectural component that provides all management services to lower tiers an agents.
Glossary–2 Desktop and Server Management Advanced Topics Guide September 2007 OSIM and CADSMCMD
DSM Explorer The DSM Explorer is a single EGC framework-based Admin GUI. It consists of the framework itself, a common plug-in and a number of product specific plug-ins. The DSM Explorer provides a homogenized view and operation of all DSM products in which no product separation is apparent. As DSM products are purchased and installed the GUI simply becomes richer and more powerful.
Engine The Engine is a multi-instance, multi-function, distributable component. Its primary focus is the maintenance of computers and related information. Logic is encapsulated into a number of Engine Tasks which can be scheduled to run at regular intervals.
Enterprise Server (ES) Optional tier in Desktop and Server Management architecture which provides a single point of administration for multiple domains.
Graphical User Interface (GUI) A graphical user interface allows a user to communicate with a product. Because of its graphical elements it is easy to use.
Image Prepare System (IPS) Image Prepare System (IPS) reads the OS files from the vendor’s media and combines this with the OSIM files to create OSIM OS images and Boot Images.
Infrastructure Deployment The Infrastructure Deployment subsystem facilitates the initial deployment of DSM software components within a heterogeneous enterprise. Infrastructure Deployment is also sometimes known as DMDeploy v2. DSM infrastructure components, such as Agents and Scalability Servers, can be transferred and installed without the use of Unicenter Software Delivery. This functionality is typically used for an initial roll out of the DSM infrastructure. Infrastructure Deployment uses a DSM Explorer wizard to scan for deployment targets and to configure and initiate the deployment job.
Infrastructure Deployment Manager The Infrastructure Deployment Manager (dmdeploy) controls the overall deployment mechanism and maintains status among other tasks. It is a CAF plug-in
Inter Process Communication (IPC) IPC is a communication system that allows two process to interchange information. The DSM Manager utilizes CAM for IPC and uses the DSM Message Interface to run CAM.
IT Resource Management (DSM) A suite of products that enable the management of IT resources within an enterprise including: Unicenter Asset Management, Unicenter Software Delivery and Unicenter Remote Control.
Management Database (MDB) The MDB schema provides a unified and extensible model for enterprise IT management (EITM). It contains both common tables and product-specific tables that were previously implemented in separate product databases. The MDB serves as the enterprise database for all CA products and acts as a primary reference point.
September 2007 Glossary–3 OSIM and CADSMCMD
Network Address Translation (NAT) Internet standard that enables a local-area network (LAN) to use one set of IP addresses for internal traffic and a second set of addresses for external traffic. A NAT box located where the LAN meets the Internet makes all necessary IP address translations.
Networker The Networker is a generic, protocol-independent interface to stream based networking. This is a loadable component, which makes use of other loadable components to provide support for specific protocols, such as TCP/IP.
Network Object Server When a transfer job is activated the TOS contacts the Network Object Server (NOS) for the best route. Communication is managed via SM.
Operating System (OS) Every general-purpose computer must have an operating system to run other programs. Operating systems perform basic tasks, such as recognizing input from the keyboard, sending output to the display screen, keeping track of files and directories on the disk, and controlling peripheral devices such as disk drives and printers.
OS Installation Management (OSIM) OS Installation Management is a feature of USD that manages the preparation, installation, configuration, and upgrade of operating systems in an enterprise network.
Plug-in Computer program that interacts with a host application (a web browser or an email client, for example) to provide a certain, usually very specific, function "on demand.
Port Multiplexer (PMUX) The Port Multiplexer is a plug-in that listens for stream connections and forwards them to the process that requires them. It handles connection establishment and enables multiple applications to listen on a single port (by default that port is 4728). The Port Multiplexer only supports TCP.
Port Address Translation (PAT) Also known as "Network Address Port Translation" or "NAPT" PAT refers to network address translation where port number are mapped, allowing multiple machines to share a single IP address.
Report Extractor The Report Extractor is a separate EGC plug-in that is used to extract data from the MDB into result tables that are presented in the GUI and can be printed or exported in a number of standard formats. The Report Extractor plug-in is also used by the DSM Engine to generate result sets on a scheduled basis.
Sector Server The sector server is a component of UAM V4 that collects information from the attached agents and reports them to the UAM manager.
Glossary–4 Desktop and Server Management Advanced Topics Guide September 2007 OSIM and CADSMCMD
Scalability Server The Scalability Server is a component of the DSM R11 architecture that acts as a distribution point for software delivery activities and a collection point for asset inventory.
Session Messaging (SM) Session Messaging (SM) is a client-server layer that sits atop the DSM Messenger component. SM is provided in the form of a C-based interface DLL and a management daemon (CAF plug-in). SM is modular and utilizes many common components. It provides session management, encryption, compression, low-level authentication (X.509), high-level authentication (O/S or External), transactional calls and message forwarding.
Software Catalog The Software Catalog is an agent plug-in, which allows you "self-service". With this wizard based interface, you can install or remove software on your computer from a library provided by the administrator.
TOS DTS is implemented around an object model. These are the objects controlled by the Transfer Object Service (TOS).
Unicenter Asset Management (UAM) Unicenter Asset Management (UAM) is one of the worlds leading Enterprise Asset Management products. It is a scalable enterprise class product and its management capabilities allow clients to build an inventory of IT assets in a database and deploy management policy on remote desktops.
It has a very broad platform and protocol coverage, utilizes CA Common Services and integrates with Unicenter NSM and other CA desktop products.
Unicenter Remote Control (URC) Unicenter Remote Control (URC) is a product that allows accessing and controlling a distant PC and its resources from any location – as if you were locally logged on.
Unicenter Software Delivery (USD) Unicenter Software Delivery (USD) is currently the world’s leading Enterprise Software Distribution product generating more revenue than any of its competition.
It is a flexible tool that can build, distribute, install and manage software packages. Its management capabilities allow clients to install, configure, verify and remove software throughout their business environment in a controlled and standardized way. It has a very broad platform and protocol coverage, utilizes CA Common Services and integrates with Unicenter NSM and other CA desktop products.
Web Admin Console (WAC) The Web Console is a browser-based user interface to Unicenter DSM, which can be installed on Windows and Linux operating environments.
September 2007 Glossary–5