DSM Advanced Topics Guide - SupportConnect - CA
DSM Advanced Topics Guide - SupportConnect - CA
DSM Advanced Topics Guide - SupportConnect - CA
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Unicenter ®<br />
Desktop and Server<br />
Mc®<br />
anagement<br />
<strong>Advanced</strong> <strong>Topics</strong><br />
R11.x
Legal Notice<br />
This publication is based on current information and resource allocations as of its date of publication and is subject<br />
to change or withdrawal by <strong>CA</strong> at any time without notice. The information in this publication could include<br />
typographical errors or technical inaccuracies. <strong>CA</strong> may make modifications to any <strong>CA</strong> product, software program,<br />
method or procedure described in this publication at any time without notice.<br />
Any reference in this publication to non-<strong>CA</strong> products and non-<strong>CA</strong> websites are provided for convenience only and<br />
shall not serve as <strong>CA</strong>’s endorsement of such products or websites. Your use of such products, websites, and any<br />
information regarding such products or any materials provided with such products or at such websites shall be at<br />
your own risk.<br />
Notwithstanding anything in this publication to the contrary, this publication shall not (i) constitute product<br />
documentation or specifications under any existing or future written license agreement or services agreement<br />
relating to any <strong>CA</strong> software product, or be subject to any warranty set forth in any such written agreement; (ii)<br />
serve to affect the rights and/or obligations of <strong>CA</strong> or its licensees under any existing or future written license<br />
agreement or services agreement relating to any <strong>CA</strong> software product; or (iii) serve to amend any product<br />
documentation or specifications for any <strong>CA</strong> software product. The development, release and timing of any features<br />
or functionality described in this publication remain at <strong>CA</strong>’s sole discretion.<br />
The information in this publication is based upon <strong>CA</strong>’s experiences with the referenced software products in a<br />
variety of development and customer environments. Past performance of the software products in such<br />
development and customer environments is not indicative of the future performance of such software products in<br />
identical, similar or different environments. <strong>CA</strong> does not warrant that the software products will operate as<br />
specifically set forth in this publication. <strong>CA</strong> will support only the referenced products in accordance with (i) the<br />
documentation and specifications provided with the referenced product, and (ii) <strong>CA</strong>’s then-current maintenance and<br />
support policy for the referenced product.<br />
Certain information in this publication may outline <strong>CA</strong>’s general product direction. All information in this publication<br />
is for your informational purposes only and may not be incorporated into any contract. <strong>CA</strong> assumes no<br />
responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, <strong>CA</strong><br />
provides this document “AS IS” without warranty of any kind, including, without limitation, any implied warranties<br />
of merchantability, fitness for a particular purpose, or non-infringement. In no event will <strong>CA</strong> be liable for any loss<br />
or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost<br />
investment, business interruption, goodwill or lost data, even if <strong>CA</strong> is expressly advised of the possibility of such<br />
damages.<br />
Copyright License and Notice<br />
This publication contains sample application programming code and/or language which illustrate programming<br />
techniques on various operating systems. Notwithstanding anything to the contrary contained in this publication,<br />
such sample code does not constitute licensed products or software under any <strong>CA</strong> license or services agreement.<br />
You may copy, modify and use this sample code for the purposes of performing the installation methods and<br />
routines described in this document. These samples have not been tested. <strong>CA</strong> does not make, and you may not<br />
rely on, any promise, express or implied, of reliability, serviceability or function of the sample code.<br />
Copyright © 2007 <strong>CA</strong>. All rights reserved. All trademarks, trade names, service marks and logos referenced herein<br />
belong to their respective companies.
Contents<br />
Chapter 1: Introduction<br />
References ................................................................................... 1-1<br />
Providing Feedback ........................................................................... 1-2<br />
Chapter 2: Component Details<br />
The Engine ................................................................................... 2-2<br />
Engine Startup ........................................................................... 2-4<br />
Engine Tasks ............................................................................. 2-5<br />
Managers .................................................................................... 2-9<br />
Infrastructure Deployment Manager........................................................ 2-9<br />
Common Object Manager................................................................. 2-10<br />
The MDB .................................................................................... 2-11<br />
MDB Installation ......................................................................... 2-12<br />
Data Transfer Service (DTS).................................................................. 2-14<br />
DTS Transfers ...........................................................................2-15<br />
DTS Components ........................................................................ 2-16<br />
The Agent and DM Primer .................................................................... 2-25<br />
Report Extractor............................................................................. 2-25<br />
Architectural Overview ................................................................... 2-26<br />
Report Templates ........................................................................ 2-27<br />
Communications ......................................................................... 2-29<br />
Diagnosing Problems ..................................................................... 2-29<br />
Web Admin Console (WAC)................................................................... 2-31<br />
WAC and AMS ........................................................................... 2-32<br />
Diagnosing Problems ..................................................................... 2-32<br />
Web Services................................................................................ 2-33<br />
Things to Note ........................................................................... 2-35<br />
Diagnosing problems..................................................................... 2-35<br />
Chapter 3: <strong>DSM</strong> Explorer<br />
Architectural Overview ........................................................................ 3-1<br />
Diagnostic Tips ............................................................................... 3-2<br />
Common Plug-in.............................................................................. 3-3<br />
CCNF Plug-in ................................................................................. 3-5<br />
September 2007 Contents iii
References<br />
Reading Configuration Policies............................................................. 3-6<br />
DM Deploy Plug-in ........................................................................... 3-8<br />
Diagnosing Problems ..................................................................... 3-9<br />
Directory Browser Plug-in.................................................................... 3-10<br />
Directory Wizard ........................................................................ 3-10<br />
Directory Synchronization................................................................ 3-11<br />
Directory Browsing ...................................................................... 3-12<br />
Asset Manager (AM) Plug-in ................................................................. 3-12<br />
Software Delivery (SD) Plug-in............................................................... 3-16<br />
Remote Control (RC) Plug-in ................................................................. 3-20<br />
Things to Note .......................................................................... 3-23<br />
OSIM Plug-in ............................................................................... 3-23<br />
Chapter 4: <strong>CA</strong>F<br />
What is <strong>CA</strong>F? ................................................................................ 4-2<br />
OS Services ................................................................................. 4-5<br />
Tracing .................................................................................. 4-5<br />
Security ..................................................................................... 4-9<br />
Authentication .......................................................................... 4-10<br />
Encryption .............................................................................. 4-12<br />
Authorization (Object Level Security) ..................................................... 4-13<br />
Communication ............................................................................. 4-20<br />
Streams ................................................................................ 4-20<br />
The Messenger .......................................................................... 4-22<br />
Chapter 5: Installation <strong>Topics</strong><br />
Infrastructure Deployment.................................................................... 5-2<br />
Processes and Log files ................................................................... 5-4<br />
Stage to and Deploy from Scalability Server................................................ 5-5<br />
Diagnosis Tips ........................................................................... 5-6<br />
Frequently asked Questions ............................................................... 5-7<br />
Additional Considerations for r11.2 ........................................................ 5-8<br />
Upgrading from a Previous Release........................................................... 5-12<br />
Data Migration .......................................................................... 5-13<br />
<strong>DSM</strong> and NAT ............................................................................... 5-20<br />
Overview ............................................................................... 5-20<br />
Scenario 1: Scalability Server as Proxy Router ............................................ 5-21<br />
Scenario 2: Agent as <strong>CA</strong>M Proxy ......................................................... 5-25<br />
iv Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Chapter 6: Startup and Configuration<br />
References<br />
What Happens at Startup? .................................................................... 6-1<br />
Startup Under Windows ................................................................... 6-4<br />
Startup under Linux....................................................................... 6-6<br />
Infrastructure Configuration ................................................................... 6-8<br />
Configuration Policy ....................................................................... 6-8<br />
Activating Computer Configuration ......................................................... 6-8<br />
Enterprise and Domain Policies ........................................................... 6-10<br />
Property Storage ........................................................................ 6-10<br />
Processes and Log Files .................................................................. 6-14<br />
Agent Registration ........................................................................... 6-15<br />
Chapter 7: Software Scanning<br />
Overview and Flow ........................................................................... 7-1<br />
Processes and Log files ....................................................................... 7-3<br />
A Closer Look at the Content Download Process............................................. 7-4<br />
A Closer Look at the XML Generation Process ............................................... 7-5<br />
A Closer Look at the Engine Transfer Process ............................................... 7-6<br />
A Closer Look at the Scalability Server Transfer Process ..................................... 7-6<br />
Using an Enterprise Server ................................................................ 7-8<br />
A Closer Look at the Import\Export Utility .................................................. 7-8<br />
Diagnosis Tips ............................................................................... 7-10<br />
Chapter 8: Remote Control Connection<br />
Overview and Flow ........................................................................... 8-1<br />
Processes and Log files ....................................................................... 8-3<br />
Getting the Address Book ..................................................................... 8-3<br />
Getting the Authority List ..................................................................... 8-4<br />
Centralized User Validation ................................................................ 8-6<br />
Cached\Fail Safe Validation................................................................ 8-7<br />
Connecting to the Desktop .................................................................... 8-7<br />
Terminal Services Obstacles ............................................................... 8-8<br />
Displaying Confirmation Dialogs .............................................................. 8-10<br />
Starting Remote Control ..................................................................... 8-10<br />
RCConfig and RCTrace ................................................................... 8-11<br />
Diagnosis Tips ............................................................................... 8-11<br />
September 2007 Contents v
References<br />
Chapter 9: Delivering Software<br />
Overview and Flow ........................................................................... 9-2<br />
DTS Integration .......................................................................... 9-9<br />
USD Shares................................................................................. 9-11<br />
USD Directories ............................................................................. 9-12<br />
USD Files ................................................................................... 9-14<br />
MDB Tables ................................................................................. 9-15<br />
Process, Trace and Log Files ................................................................. 9-16<br />
Install Packages and Trace Files.............................................................. 9-18<br />
USD Logical Process Flows and Log Files ...................................................... 9-19<br />
Major Changes between 11.1 and 11.2 ....................................................... 9-22<br />
Collecting Information for Troubleshooting .................................................... 9-23<br />
Additional DTS Considerations ............................................................... 9-23<br />
Chapter 10: OSIM<br />
OSIM Architecture........................................................................... 10-1<br />
Process and Log Files........................................................................ 10-4<br />
Installation and Configuration ................................................................ 10-5<br />
Multiple Boot Server (BS) in a PXE broadcast network ..................................... 10-6<br />
Prioritization of Boot Server with Remote Configuration .................................... 10-6<br />
Image Prepare System (IPS)................................................................. 10-8<br />
Example.................................................................................... 10-9<br />
Create Boot Images ..................................................................... 10-9<br />
Register DOS Boot Images .............................................................. 10-12<br />
Create OS Image....................................................................... 10-13<br />
Register the OS Image ................................................................. 10-14<br />
Prepare the Target for Network Boot..................................................... 10-15<br />
Boot the Target ........................................................................ 10-16<br />
Change Selected PXE Target to Managed................................................. 10-16<br />
Editing the Job Parameter............................................................... 10-16<br />
Activate the OS Installation Job ......................................................... 10-17<br />
Boot the Target to Execute the OS install job............................................. 10-17<br />
Under the Hood ............................................................................ 10-18<br />
Boot Image Tools and Templates ........................................................ 10-18<br />
Template Files and OS Types............................................................ 10-22<br />
Registering to Another Domain Manager ................................................. 10-27<br />
Special Preparation for GHOST and PQIMG Based Images ................................. 10-28<br />
Upgrade Procedure for OS-SD packages ................................................. 10-28<br />
OSIM Domain Manager Plug-in .......................................................... 10-29<br />
OS Installation Job States............................................................... 10-29<br />
vi Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
References<br />
OSIM (CSM) Data Base Design...........................................................10-30<br />
OSIM Database Objects and Relationships ................................................10-33<br />
Boot Server Components ................................................................10-35<br />
OSIM and <strong>CA</strong><strong>DSM</strong>CMD ......................................................................10-50<br />
Architectural Overview ..................................................................10-51<br />
Diagnosing Problems with <strong>CA</strong><strong>DSM</strong>CMD ...................................................10-52<br />
TargetComputer command ..............................................................10-54<br />
Enhancements/Changes .................................................................10-56<br />
Example Scenarios......................................................................10-57<br />
Glossary<br />
September 2007 Contents vii
Chapter 1: Introduction<br />
References<br />
This guide provides a closer look at several key Unicenter Desktop and Server<br />
Management components and functions. It is intended to be used in<br />
conjunction with the product documentation and other supporting materials<br />
available through the Technical Support website.<br />
This information is presented in a series of chapters and topics that cover<br />
product specific and shared aspects of Unicenter <strong>DSM</strong>. The chapters are<br />
intended to be self-contained and randomly accessible. Updates and revisions<br />
will be provided on an ongoing basis and will be clearly noted.<br />
The following additional documents are referenced and should be consulted for<br />
further details:<br />
Unicenter <strong>DSM</strong> r11.x – Implementation <strong>Guide</strong><br />
Unicenter <strong>DSM</strong> r11.x – Release Impact <strong>Guide</strong><br />
Inside <strong>Guide</strong>s for Asset Management, Software Delivery and Remote<br />
Control<br />
Product Readme files and online HELP<br />
The most up-to-date technical guidelines and tips can also be found on the <strong>CA</strong><br />
Support Online website (http:\\support.ca.com). In addition, best practice<br />
guidelines for both Unicenter <strong>DSM</strong> and its underlying database (the MDB) can<br />
be found at the following link:<br />
http://supportconnectw.ca.com/public/impcd/r11/StartHere.htm<br />
Included on this site is the Unicenter Desktop and Server Management<br />
Diagnostics <strong>Guide</strong> which includes basic troubleshooting procedures and a list of<br />
common symptoms and solutions.<br />
Following is the direct link to the <strong>CA</strong> Messaging Troubleshooting <strong>Guide</strong> which<br />
contains information on diagnosing problems with <strong>CA</strong>M and <strong>CA</strong>FT, common<br />
components used by Unicenter <strong>DSM</strong>:<br />
http://supportconnectw.ca.com/premium/unicenter30/infodocs/TEC418063.pd<br />
f<br />
Note that this document requires a login to the <strong>SupportConnect</strong> site.<br />
September 2007 Chapter 1: Introduction 1–1
Providing Feedback<br />
Providing Feedback<br />
This is the first edition of the <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong>. This document was<br />
produced in direct response to many requests for additional details regarding<br />
particular functions and component interactions provided in <strong>DSM</strong>. Feedback is<br />
welcome and can be sent to the following email address:<br />
ImpcdFeedback@ca.com<br />
All feedback will be reviewed and considered for inclusion in future updates of<br />
these materials. Updates will be posted as they become available. If you have<br />
a technical question or if you require a more immediate response, you should<br />
consider opening an issue through <strong>CA</strong> Technical Support.<br />
1–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Chapter 2: Component Details<br />
This chapter takes a closer look at the following <strong>DSM</strong> components:<br />
Engine<br />
Manager<br />
MDB<br />
DTS<br />
Agent<br />
Report Extractor<br />
Web Admin Console (WAC)<br />
Web Services<br />
Both the <strong>DSM</strong> Explorer (and its plug-ins) as well as <strong>CA</strong>F are discussed in later<br />
chapters due to the extent of the information provided.<br />
Note that this is not an exhaustive list of components and details regarding<br />
additional components may be added in the future.<br />
These topics are also discussed in the following documents:<br />
Implementation <strong>Guide</strong> (notably “Chapter 1: Understanding Unicenter<br />
<strong>DSM</strong>”)<br />
<strong>DSM</strong> HTML Help Web Services Reference <strong>Guide</strong><br />
You should also consult the following links on the Implementation Best<br />
Practices site for further information:<br />
Working with the MDB (includes information regarding the MDB and<br />
CORA):<br />
http://supportconnectw.ca.com/public/impcd/r11/MDBMain/MDB_Frame.ht<br />
m<br />
Working with your CMS Solution<br />
http://supportconnectw.ca.com/public/impcd/r11/Unicenter/CMS_Frame.h<br />
tm<br />
Scalability Considerations (includes information regarding sizing and<br />
performance considerations)<br />
http://supportconnectw.ca.com/public/impcd/r11/scalability/scalability_gui<br />
delines__udsm.htm<br />
A full list of techdocs is also available from the following link:<br />
September 2007 Chapter 2: Component Details 2–1
The Engine<br />
The Engine<br />
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp<br />
The Engine is a multi-instance, multi-function, distributable component. Its<br />
primary focus is the maintenance of computers and related information. Logic<br />
is encapsulated into a number of Engine Tasks enabling them to be scheduled<br />
to run at regular intervals.<br />
The <strong>DSM</strong> Engine supports the following tasks<br />
Sector collect – inventory collection from Scalability Server<br />
Data Replication – copying of key data between Domain and Enterprise<br />
databases<br />
Dynamic Group Evaluation – Evaluation of the membership of nonstatic<br />
groups (e.g., query-based)<br />
Query-Based Policy Evaluation – Evaluation of policy violators and<br />
execution of actions<br />
Report Extractor Jobs – execution of scheduled report extractions<br />
Query Evaluation – simple evaluation of a standalone query<br />
Migration Sync – copy and transform of info from previous version<br />
implementations<br />
Run Generic SQL<br />
Run External exe<br />
Architecturally, the Engine can be considered as part of the <strong>DSM</strong> Manager.<br />
Every <strong>DSM</strong> Manager contains at least one default Engine instance which is<br />
known as the “System Engine.” Additional Engine instances can be created on<br />
the primary <strong>DSM</strong> Manager machine or on other remote machines.<br />
2–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
The Engine<br />
Note: When a <strong>DSM</strong> Domain Manager is running on Linux with an Ingres MDB<br />
and the Enterprise Manager is running on Windows with MS SQL Server then a<br />
Windows Domain Engine is required for successful replication.<br />
September 2007 Chapter 2: Component Details 2- 3
The Engine<br />
Engine Startup<br />
The following diagram provides an overview of the different pieces that<br />
comprise the Engine:<br />
CMEngine<br />
amoDataClasses<br />
sqlexec<br />
This includes the following:<br />
cfnotcli<br />
CmEngine – responsible for server/manager registration,<br />
Enterprise/Domain linking and Server/Engine linking<br />
cfnotcli – notification client side API<br />
Sqlexec – generic database API<br />
amoDataClasses – embedded library of data access classes<br />
Engine startup is comprised of the following tasks:<br />
1. Engine started up by <strong>CA</strong>F<br />
2. Instance name passed on command line<br />
3. <strong>DSM</strong> Manager hostname read from comstore<br />
4. Database Name, Type, Credentials and other details are obtained from<br />
Common Manager<br />
5. Database is opened<br />
6. Jobs assigned to Engine are read<br />
7. Work begins!<br />
2–4 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Engine Tasks<br />
Sector Collection<br />
As noted earlier, key Engine tasks include the following:<br />
Collection<br />
Replication<br />
Reporting<br />
Migration<br />
Evaluation of Polices/Dynamic Grouping<br />
Licenses<br />
The Engine<br />
During Sector Collection the Engine basically does a READ and WRITE to a<br />
Scalability Server. When an Agent initially connects to a Scalability Server it<br />
submits a request to be created and it will store all information it would like to<br />
push to the database in a “collect” area on the Scalability Server.<br />
When the Engine connects to a Scalability Server it first “verifies” the integrity<br />
of the Scalability Server (for example, does the Scalability Server contain all<br />
the information about the Assets that it is supposed to according to the<br />
database?). Next, it checks the “Request Area” (“new” area in UAM terms) to<br />
see if any assets have requested to be created. The Engine checks to see if<br />
those assets (or Users) already exist in the database and confirms that the<br />
Scalability Server information correctly identifies this Scalability Server (i.e.,<br />
the one from which the information is currently being “collected”).<br />
If the Assets are new to the whole system they will be created in the database<br />
and in the Scalability Server’s “Unit” area. This enables the agent to “find<br />
itself” the next time it connects to the Scalability Server.<br />
Next, the Engine processes all the information provided by Agents in the<br />
“Collect” area. The information collected can take various forms:<br />
Inventory (Hardware/template information)<br />
Software inventory (Software Found based in signature files, heuristic<br />
found software)<br />
Configuration Files (i.e. Autoexec.bat or other ini files configured to be<br />
backup by the UAM system)<br />
Job Status<br />
Module Status<br />
Time Stamps (Last Execution date)<br />
Usage (Metering) Inventory<br />
September 2007 Chapter 2: Component Details 2- 5
The Engine<br />
Query and Dynamic Group Evaluation<br />
Relation information (between Computers/Users/Devices etc)<br />
The information that is collected is then stored in the appropriate table in the<br />
MDB. For example:<br />
Computer information is stored in the ca_discovered_hardware table<br />
and created in the common asset model using the CORA API.<br />
User Accounts are stored in the ca_discovered_user table<br />
User Profiles are stored in the ca_link_dis_hw_user table<br />
Relationships (e.g. VMware host/guest) are stored in the ca_link_dis_hw<br />
table<br />
Additional information for each of these items is also stored in the ca_agent<br />
and ca_agent_component tables.<br />
When Computers are created in the ca_discovered_hardware table a call is<br />
made to CORA. CORA is responsible for maintaining the Common Asset Model<br />
and enables the integration between NSM, <strong>DSM</strong> and USVD/UAPM. One<br />
inventory table is set for each component while General/Common Inventory is<br />
stored in inv_generalinventory_item and inv_generalinventory_tree<br />
Note: Additional information regarding CORA can be found in the “MDB<br />
Hardware Assets and CORA” document available from the following link:<br />
http://supportconnectw.ca.com/public/impcd/r11/MDBMain/Doc/CORA_MDB_a<br />
nd_Assets_SC.pdf<br />
New Inventory tables are generated in the MDB by the Engine when new<br />
inventory is collected.<br />
The basic functionality of the Query and Dynamic Group Evaluation tasks have<br />
not changed significantly since the previous 4.0 release of Unicenter Asset<br />
Management. In r11, however, group definition details are stored in<br />
ca_group_def table in the MDB and the link between Group and Member<br />
(Computer, Users, etc.) is stored in the ca_group_member table.<br />
Queries definitions are stored separately in the ca_query_def table.<br />
Query based groups and policies are evaluated by the Engine based either on<br />
set time intervals or when the servers are processed.<br />
2–6 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Replication<br />
Replication functions utilize the following MDB tables:<br />
The Engine<br />
Database triggers/procedures are kept in the auto_rep_version table<br />
Creation of database triggers and procedures include the following:<br />
– Update/insert on Ingres<br />
– Delete on Ingres and MSSQL<br />
Replication configuration information is kept in the ca_replication_conf<br />
Replication status is kept in the ca_replication_status table<br />
Replication deletion history is kept in the ca_replication_history<br />
When the Domain is linked to an Enterprise, Domain information is maintained<br />
in the ca_n_tier table while Manager information is maintained in the<br />
ca_manager table. Data is owned either by the Domain or the Enterprise and<br />
records are only replicated one way. If a record is changed on the target it will<br />
be overwritten. The sequence is as follows:<br />
Process deletes go from Domain -> Enterprise<br />
Process updates go from Domain -> Enterprise<br />
Process deletes go from Enterprise -> Domain<br />
Process updates go from Enterprise -> Domain<br />
To delete records select top 25000 * from ca_replication_history where<br />
table_name=’ca_agent’ and auto_rep_version > last_deleted<br />
while (more records)<br />
{<br />
}<br />
if (record owned by source database)<br />
delete record in target database<br />
last_deleted = record.auto_rep_version<br />
next record<br />
To update records select top 25000 * from ca_agent where auto_rep_version<br />
> last_updated<br />
while (more records)<br />
{<br />
September 2007 Chapter 2: Component Details 2- 7
The Engine<br />
}<br />
if (record exist in target database)<br />
else<br />
update record in target database<br />
insert record into target database<br />
last_updated = record.auto_rep_version<br />
next record<br />
On SQL server the auto_rep_version field is of type timestamp. This field type<br />
is always automatically updated and it contains a unique value for the table.<br />
On Ingres, however, this is a date type field and it is only populated when the<br />
triggers and procedures are created during linking. Furthermore, since the<br />
value is not unique some additional logic is implemented to make this work on<br />
Ingres.<br />
To unlink a Domain from the Enterprise you need to:<br />
Deregister assets on Enterprise<br />
Remove replicated data based on ca_replication_conf<br />
Remove database triggers and procedures<br />
To support the process of computers roaming between Domains linked to the<br />
same Enterprise before a computer is replicated to the Enterprise the<br />
replication mechanism checks to see if there is already a computer listed with<br />
the same host uuid but from another domain. If one is found, it is deleted<br />
from the Enterprise and a record is added to the Enterprise history table. The<br />
replication mechanism also checks the Enterprise history to see if any of the<br />
roamed computers belongs to this Domain.<br />
2–8 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Managers<br />
Infrastructure Deployment Manager<br />
There are two types of managers that will be discussed here: the<br />
Infrastructure Deployment Manager and the Common Object Manager.<br />
Managers<br />
The Infrastructure Deployment Manager (dmdeploy) controls the overall<br />
deployment mechanism and maintains status among other tasks. It is a <strong>CA</strong>F<br />
plug-in that can be stopped and started through the following command:<br />
caf stop dmdeploy<br />
caf start dmdeploy<br />
Upon startup the Infrastructure Deployment manager generates public/private<br />
encryption keys if they are not already present. Old keys are retained, but<br />
can be generated afresh after removal – though this requires reauthentication.<br />
Encryption key generation is managed through the<br />
dmkeydat.pri and dmkeydat.pmr files which are found in the DMdeploy/bin/<br />
folder. Dmkeydat.pmr must be transferred to the target systems before<br />
deployment can be achieved.<br />
The deployment library is kept on the manager machine under the following<br />
locations:<br />
For Windows: \<strong>CA</strong>\Unicenter <strong>DSM</strong>\Packages<br />
For Linux: $<strong>CA</strong>_ITRM_BASEDIR/Packages<br />
The \Public subdirectory contains the payloads which can be deployed<br />
(selectable in the wizard). The \<strong>CA</strong>\Unicenter <strong>DSM</strong>\Packages\Private<br />
folder contains the DMPrimer installation images and intermediate copies of<br />
payload data.<br />
The DMAPI is used by deployment consumers, such as dmsweep and the<br />
Deployment Wizard, to communicate with the manager. All user-visible<br />
deployment functionality is driven through the API.<br />
During installation, the software that is to be installed (i.e., “the payload”) is<br />
stored in the Deployment “Packages/Public” area on the Manager and<br />
subsequently staged on Scalability Servers. Only agents and servers are<br />
currently supported.<br />
Deployment components are decoupled from payloads. In other words, you<br />
can “slot in” new versions or even new payloads without altering the<br />
DMDeploy software.<br />
Payload configuration is managed through the dmdeploy.dat file which does<br />
the following:<br />
September 2007 Chapter 2: Component Details 2- 9
Managers<br />
Common Object Manager<br />
Defines payload name and version<br />
Defines the command line to use to install the payload.<br />
Optionally defines CLI parameters which must be supplied by customer<br />
prior to deployment.<br />
Since Dmdeploy.dat contents are processed “on the fly” by the Deployment<br />
Manager any changes that are made take effect for all subsequent<br />
deployments.<br />
The Common Object Manager provides a set of core, prerequisite, fundamental<br />
services that all other Manager components build upon or use. It provides the<br />
following services:<br />
API access to common objects shared across the products<br />
Scalability Server registration and Engine linking<br />
Domain Manager to Enterprise Manager linking<br />
Examples of Common Objects include:<br />
Computers<br />
User Accounts<br />
User Profiles<br />
Managers<br />
Servers<br />
Domains<br />
Groups<br />
Engines<br />
Queries<br />
Companies<br />
Software Categories<br />
Software Definitions<br />
Agents<br />
Scalability Server Components<br />
Manager Components<br />
Agent Components<br />
The Common Object Manager is implemented as a set of executables and<br />
shared libraries:<br />
2–10 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
The MDB<br />
This includes the following components:<br />
cmRegister – server/manager registration, Enterprise/Domain linking,<br />
Server/Engine linking<br />
cmObjectInterface – common object client interface<br />
cmObjectManager – common object manager<br />
am_api – amManager client side API<br />
cmObjectDAI – Data Access Interface for common objects<br />
Sqlexec – generic database API<br />
amManager – provides access to common objects provided by<br />
amoDataClasses<br />
amoDataClasses – embedded library of data access classes<br />
The MDB<br />
The MDB schema provides a unified and extensible model for enterprise IT<br />
management (EITM). It contains both common tables and product-specific<br />
tables that were previously implemented in separate product databases. The<br />
MDB serves as the enterprise database for all <strong>CA</strong> products and acts as a<br />
primary reference point.<br />
September 2007 Chapter 2: Component Details 2- 11
The MDB<br />
MDB Installation<br />
Ingres Notes<br />
The MDB schema includes the database objects used by <strong>CA</strong> products and their<br />
components. These include tables, columns, views, triggers, rules and<br />
procedures. The MDB manages operational and transactional data, as well as<br />
the analytical data used for intelligence and data mining.<br />
The integration point for all products is the common asset. Common<br />
registration of assets is handled by the CORA API.<br />
Depending on a company’s business needs, as well as its organizational and<br />
geographical structure, you can use a single MDB or multiple MDBs; both<br />
approaches utilize the same schema.<br />
In <strong>DSM</strong> MDBs reside at the Domain Manager and the Enterprise manager<br />
levels, though they are not necessarily co-located on the same physical<br />
machine as the manager.<br />
Ingres is supported on Windows and Linux while MS-SQL Server is supported<br />
on Windows only.<br />
When using an Ingres-based MDB, keep the following in mind:<br />
Ingres will be installed by the <strong>DSM</strong> installer if not already installed<br />
2–12 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
The Ingres installer will itself install the MDB (setupmdb)<br />
The <strong>DSM</strong> installer uses a response file to specify Ingres installation<br />
parameters<br />
The MDB<br />
The Ingres installer (setupmdb) will set the MDB_SIZE=medium by default<br />
MDB_SIZE is a configuration parameter which affects certain Ingres DBMS<br />
settings, such as DMF cache size, in an attempt to attain better<br />
performance based on expected load.<br />
The MDB_SIZE setting can be changed but the actual physical hardware<br />
used must be capable of supporting the increased MDB size.<br />
MDB patches are applied during the <strong>DSM</strong> installation if needed.<br />
The following process is used when an Ingres-based MDB is installed on<br />
Windows:<br />
1. The Install kit collects installation attributes (for example, which database<br />
server is to be used).<br />
2. The Install kit uses the dbinfo.dll component to check certain prerequisites<br />
such as:<br />
Has the MDB already been installed?<br />
Is that MDB version OK?<br />
Is MDB already initialized (in other words, has the <strong>DSM</strong> Domain<br />
already been installed)?<br />
3. The Install kit calls the dsmMdbPatch.bat script to apply MDB patches<br />
provided by Support.<br />
4. The Install kit calls a post_install.bat/.sh script to add a row into the<br />
ca_settings table that will be used as tag indicating that the MDB schema<br />
is OK.<br />
5. The Install kit calls the dbDataAfterCopy.dll to initialize and populate the<br />
MDB with some basic content. The dbDataAfterCopy also sets the DB<br />
credentials to the comStore and the <strong>DSM</strong> is registered in the<br />
ca_application_registration table.<br />
6. At the end of the installation the Install kit calls the data_install.bat script<br />
to load additional content, such as queries, report data and software<br />
definitions, into the MDB.<br />
Note: It may take some time to load software definitions but this step is only<br />
done when the Asset Management component is installed.<br />
The procedures used under Linux are very similar – the only major exception<br />
is that, under Linux, dbInfo and dbDataAfterCopyApl are processes and not<br />
libraries.<br />
September 2007 Chapter 2: Component Details 2- 13
Data Transfer Service (DTS)<br />
MS SQL Server Notes<br />
If the MDB is to be installed under MS-SQL Server you must ensure that SQL<br />
Server already installed and properly configured before the MDB installation<br />
begins. The MDB schema will be installed automatically by the <strong>DSM</strong> installer.<br />
During installation on MS SQL Server an additional library, mssqllogin.dll, is<br />
used to do the following:<br />
Check if MDB is already installed<br />
Create users (grant user access)<br />
check server collation name<br />
Data Transfer Service (DTS)<br />
Note that if the MDB is installed on a machine that is remote from the Domain<br />
Manager, a trusted connection must be established between the two<br />
machines. One way to accomplish this is to have them reside in the same<br />
Windows domain.<br />
The Data Transfer Service (DTS) is used by Software Delivery to manage the<br />
distribution of software through the network.<br />
In USD terms a “USD job” is a “DTS transfer job” and the targets of those jobs<br />
are considered “DTS Transfers.” In the following screen shots you can see<br />
how DTS appears in the UI (the image on the left is r11.1 and the image on<br />
the right is from r11.2):<br />
2–14 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
DTS Transfers<br />
DTS supports the following types of transfers:<br />
Fan-out (read once and send to many)<br />
Data Transfer Service (DTS)<br />
USD transfers will resolve to a transfer job. Fan-out reads the source data<br />
once and sends it to each of the targets.<br />
This type of transfer requires that the following properties be identical:<br />
– input data<br />
– output data<br />
– initiating machine identity<br />
– initiator security tokens. In other words, the initiator User and<br />
Password are the same for each transfer.<br />
– responder security tokens. In other words, the responder User and<br />
Password are the same for each transfer.<br />
– Read Parcel and Read File filters<br />
– Parcel Size<br />
September 2007 Chapter 2: Component Details 2- 15
Data Transfer Service (DTS)<br />
DTS Components<br />
Broadcast/Multi-cast<br />
This type of transfer requires WorldView to be configured. Broadcast/Multicast<br />
similar distributions are similar to fan-out distributions, however, the<br />
data is sent to targets using bcast/mcast processes<br />
Point-to-point<br />
This type of transfer is usually used when there’s only one transfer in a<br />
transfer job.<br />
You can use the DtsCli to view and monitor the transfers. For information on<br />
command syntax, execute the following:<br />
Dtscli –h<br />
Useful commands for monitoring and debugging purposes are:<br />
dtscli –t method=status id=TheId<br />
dtscli –t method=status id=TheId method_parameters=implementation<br />
dtscli –j method=status id=TheId<br />
dtscli –j method=status id=TheId method_parameters=implementation<br />
dtsCli –j method=status id=TheId method_parameters=transfers<br />
DTS consist of the DTS Transfer Agent, DTS Command Line Interface (DTSCLI)<br />
and three “servers” – the Network Object Server (NOS), Transfer Object<br />
Server (TOS) and Schedule Object Server (SOS) – that are distributed across<br />
the <strong>DSM</strong> r11 architecture as follows:<br />
2–16 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Transfer Object Server (TOS)<br />
Data Transfer Service (DTS)<br />
Here you can see the individual processes and log files and log files used by<br />
these components:<br />
DTS is implemented around an object model. These are the objects controlled<br />
by the Transfer Object Server (TOS).<br />
September 2007 Chapter 2: Component Details 2- 17
Data Transfer Service (DTS)<br />
Network Object Server (NOS)<br />
The client tells the TOS to create, manage and activate transfers and jobs.<br />
Session messaging is used (previously it was TCP) as is encryption,<br />
compression and certificates.<br />
DTTransferGroup This class of object defines a group of transfers that<br />
are to be controlled together.<br />
DTTransfer Fully defines a single data transfer from one computer to<br />
another.<br />
DTFilter Specifies how data is to be read or written and also any<br />
processing that should be performed on the data before or after the<br />
transfer.<br />
DTS TOS is multi-threaded and uses information in <strong>DSM</strong> tables.<br />
When a transfer job is activated the TOS contacts the Network Object Server<br />
(NOS) for the best route. Communication is managed via SM.<br />
WorldView integration is used to model the network and to:<br />
Define routes between machines<br />
Set parcel size<br />
Designate throttle factor<br />
Select protocols other than TCP<br />
2–18 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Configure Multi-cast and Broadcast methods<br />
Data Transfer Service (DTS)<br />
This is the same functionality that was used in v3.0, however, note that it is<br />
not available in r11 or r11.1.<br />
Modeling the network involves creating logical links among the network<br />
computers to satisfy data transport requirements. By default, when DTS is<br />
installed, it assumes that all computers are connected directly to one another.<br />
Not only is this unlikely to be the case (and this would, obviously, cause<br />
problems) more likely than not, it is not what is logically required anyway.<br />
Thus, the first task is to model the network to satisfy the logical requirements.<br />
The first step is to analyze the DTS network topology in order to determine<br />
whether the data should be transferred directly between two machines or via<br />
one or more others (multi-hop).<br />
DTS objects population can be done through:<br />
Self discovery<br />
– CCS objects are no longer automatically created<br />
– DTS objects are automatically created, provided the associated CCS<br />
object exists<br />
– IP addresses are not automatically updated in CCS<br />
Auto discovery<br />
September 2007 Chapter 2: Component Details 2- 19
Data Transfer Service (DTS)<br />
DTS Transfer Agent<br />
Right click on the DTS BPV and select DTS Auto-discovery<br />
Integration with WorldView includes the ability to associate a CCS Calendar<br />
with a DTLink. This can be used to specify when the link can be used – DTS<br />
will suspend and resume transfers based on when the calendar is enabled.<br />
The use of Dynamic Containers is also provided through WorldView<br />
integration, which includes limited dynamic routing functionality.<br />
In the r11.2 release you should note that:<br />
The TOS’s route lookup is no longer synchronous<br />
The TOS asks for the routes of all transfers in the transfer job, not just one<br />
at a time<br />
The NOS can be responsive to other route lookup requests<br />
The transfer job’s status at this time is: Calculating<br />
The DTS Transfer Agent consists of the following components:<br />
Following are the methods by which the DTS Agent receives a transfer<br />
request, connects to the responder and performs the data transfer:<br />
2–20 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Data Transfer Service (DTS)<br />
Communication between TOS and Agent (Initiator) occurs via Session<br />
Messaging. Encryption and compression are used.<br />
Communication between the Agent and the TOS occurs via Session<br />
Messaging, Store and Forward.<br />
Communication between the Agents uses the Networker by default,<br />
although other protocols can be configured via WorldView.<br />
The Networker uses the port-multiplexer and provides encryption and<br />
compression capability. When sending control messages (for example,<br />
transfer requests), the Networker’s encryption and compression are used,<br />
however, when sending data, they are not.<br />
The following Agent Filters are provided:<br />
Read File Filter: Applied to the file before it is sent<br />
Write File Filter: Applied to the file after it has been received<br />
Read Parcel Filter: Applied to the data stream as it is being sent<br />
Write Parcel Filter: Applied to the data stream as it is being received<br />
Other DTS filters used by USD in <strong>DSM</strong> include:<br />
Directory tree (file filter)<br />
Encryption filters (these have to be configured)<br />
External Filters include Sddtfilt which is a UD filter executed by DTS after the<br />
data transfer has completed.<br />
September 2007 Chapter 2: Component Details 2- 21
Data Transfer Service (DTS)<br />
The following types of intermittent transfers are supported:<br />
Transfers to agents that are off-line<br />
Transfer’s state change to Interrupted<br />
Once the agent sends a message to the TOS (via the port multiplexer) that it<br />
has restarted, interrupted transfers are resumed. USD’s representation of the<br />
state is ‘active’.<br />
Full support is provided for the transfers of large files. This includes files that<br />
are larger than 2GB, directories whose combined size is larger than 2GB or<br />
that contains files larger than 2GB. The file system, however, has to support<br />
large files. HP file systems, for example, can be mounted as 64 bit or 32 bit.<br />
2–22 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
MDB Tables<br />
Event Management<br />
Installation and Configuration<br />
Here you can see which MDB tables are used by DTS:<br />
Data Transfer Service (DTS)<br />
The Common Eventing component is used therefore Dtaaudit.log is no longer<br />
employed. The Common Eventing component outputs to the following<br />
locations:<br />
Program files\ca\dsm\logs\Events_n.log<br />
Windows Event console<br />
CCS Event console<br />
DTS is integrated into <strong>DSM</strong> configuration policy. The Tngdts.ini that was used<br />
to configure DTS in previous releases is no longer used except for legacy<br />
purposes. Further, the former DTS Administration client is no longer used.<br />
September 2007 Chapter 2: Component Details 2- 23
Data Transfer Service (DTS)<br />
If a previous DTS release is detected it will be upgraded. DTS is backwards<br />
compatible, however. Transfers between different agent versions are<br />
supported. In the event of a partial (“staged”) upgrade, for example, when<br />
there is a version 3 manager and agent followed by an r11 Agent install, only<br />
the agent will be upgraded.<br />
During an upgrade, the install location is not changed. Otherwise, the DTS<br />
components will be installed as follows:<br />
Program files\ca\sharedcomponents\dts<br />
Program files\ca\sc\dts<br />
\dta\status is used for the DTS Agent’s checkpoint restart files<br />
\dta\staging is used as a temporary folder to hold data before file filters<br />
are applied<br />
In r11.2 these directories are not below the DTS install location (Program<br />
files\ca\dsm\dts).<br />
Log files are not kept in the DTS installation directory. Rather, they are<br />
installed in the Program Files\dsm\logs directory. This includes the following<br />
log files:<br />
TRC_DtsAgent_n.log (Master DTS Agent)<br />
TRC_DtsAgentx_n.log (Slave DTS Agent)<br />
TRC_DtsTOS_n.log (TOS log)<br />
TRC_DtsNos_n.log (NOS log)<br />
TRC_DtsSos_n.log (SOS log)<br />
TRC_DTS_n.log (Anything that uses the DTS API)<br />
Sometimes it can be difficult to see the DTS trace messages. For example:<br />
141206-13:48:25.0164333L|000548|00000b44|DtsAgent0<br />
|CCFNetwork::Send|CCFNetwork.cpp |000885|DETAIL | m_encryptOn=<br />
MSGHEADER_GET_ENCRYPT=<br />
141206-13:48:25.0818844L|000548|00000b44|DtsAgent0 |dtsPWIEXT_Send_D|PWIEXT.c<br />
|000566|DETAIL | 524318<br />
141206-13:48:25.0821777L|000548|00000b44|DtsAgent0 |dtsEQP_Outstandi|eqp.c<br />
|000400|DETAIL | Event found in event queue for transfer ,<br />
setting work to do flag<br />
141206-13:48:25.2856018L|000548|00000b44|DtsAgent0 |dtsEQP_Process_E|eqp.c<br />
|000295|DETAIL | Processing events for transfer <br />
Note, however, that all DTS trace statements have the function name (column<br />
5) prefixed with “Dts”.<br />
2–24 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
The Agent and DM Primer<br />
Report Extractor<br />
The Agent and DM Primer<br />
DM_Primer handles payload transfer and payload installation execution.<br />
dm_primer[.exe] (renamed from dmprimer.exe in V1)<br />
It is installed in the following location:<br />
\<strong>CA</strong>\Unicenter <strong>DSM</strong>\dmprimer or /opt/<strong>CA</strong>/Unicenter<strong>DSM</strong>/dmprimer<br />
It is NOT a caf plug-in (because it installs <strong>CA</strong>F).<br />
Primer install images are in the payload library, in the “Private” area (or<br />
possibly on an FTP server, mainly when deploying to *nix).<br />
It can be installed automatically (pushed out by deployment manager) or<br />
installed manually (from DVD, login script, etc.). Information on manual<br />
install can be found in the Implementation <strong>Guide</strong>.<br />
To establish connection with manager, an encryption public key must be<br />
obtained from the manager and placed in the expected location on the target.<br />
This proves that the deployment user has authority to install software.<br />
The Report Extractor is a separate EGC plug-in that is used to:<br />
extract data from the MDB into result tables<br />
present the results in the GUI<br />
print the results<br />
export the results in a number of standard formats<br />
provide data on demand (for example, for portals and web servers)<br />
The Report Extractor plug-in is also used by the <strong>DSM</strong> Engine to generate result<br />
sets on a scheduled basis.<br />
The implementation includes a large number of canned reports, covering all<br />
functional areas of the suite as well as extensive features for designing new<br />
reports and data extracts.<br />
The inner workings of the reporter feature generic data extraction and<br />
handling based on tables, columns and links, but knowledge about the<br />
product’s data model or implementation is not necessary to use the Report<br />
Extractor.<br />
September 2007 Chapter 2: Component Details 2- 25
Report Extractor<br />
Architectural Overview<br />
The following graphic depicts how the Report Extractor fits into the general<br />
architecture:<br />
User<br />
Application<br />
Data Access<br />
Database<br />
EGC 3.0<br />
<strong>DSM</strong> Reporter GUI<br />
Win: gui_rep.dll<br />
AM<br />
Manager<br />
Security<br />
Print<br />
AM Data Classes<br />
MDB<br />
Export<br />
modules<br />
Scheduled Reports<br />
Win: gui_rep_exec.dll<br />
Linux: lib_rep.so<br />
In this graphic yellow arrows represent data flow from the MDB to the UI,<br />
prints and exports.<br />
Scheduled reports are initiated by the Engine, but neither the data nor the<br />
code is shared with the Engine. Scheduled reports run in Engine context,<br />
meaning that all data can be accessed. In the Reporter all security is applied<br />
at the time the data is viewed, printed or exported. All results are “complete”,<br />
no matter what user generates them. This is because the results can be<br />
viewed later and used by other users – under their own security settings - so<br />
the native result cannot be limited.<br />
Under Windows the Report Extractor is implemented through the gui_rep.dll<br />
program which utilizes the following resources:<br />
gui_rep_res.enu<br />
gui_rep_htmlres.enu<br />
Report Templates are maintained in gui_rep_template.enu and the Engine<br />
library for scheduled reports is implemented through gui_rep_exec.dll.<br />
Under Linux the Engine library for scheduled reports is implemented through<br />
the lib_rep.so library.<br />
2–26 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Report Templates<br />
Report Extractor<br />
Reports are defined by their templates which contain information such as<br />
report name and description, a list of which fields are included, and how the<br />
data is supposed to be viewed. The Report Template does not contain data – it<br />
is only a recipe for generating results, which will, in turn, contain the current<br />
data. You can either use the report templates that are provided with the<br />
Reporter or create your own.<br />
Report Templates are organized in a file-system-like folder structure, but this<br />
can be customized as well.<br />
September 2007 Chapter 2: Component Details 2- 27
Report Extractor<br />
Following is a model of report results:<br />
Here you can see the sequence in which reports are generated:<br />
2–28 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Communications<br />
Diagnosing Problems<br />
Report Extractor<br />
System Templates are installed silently, skipping existing templates whereas<br />
non-system template issue a prompt for overwrite. All templates in default<br />
contents should be System Templates.<br />
Never use a text editor to edit a template definition in a text editor!<br />
Import is controlled by the timestamp of the library file. The last import time<br />
is stored in registry as follows:<br />
[HKEY_LO<strong>CA</strong>L_MACHINE\SOFTWARE\ComputerAssociates\<br />
Unicenter ITRM\Reporter\Library\]<br />
When library file is newer, templates are imported. Already existing templates<br />
are not overwritten!<br />
The Report Extractor communicates with the Manager using the manager<br />
address set in the comstore during installation. This value can be overridden<br />
through the following:<br />
dsmreporter.exe manager:<br />
Database connection information is obtained through the common manager.<br />
After that, direct database access is used.<br />
Security implementation uses the AM Manager while Directory integration uses<br />
the common manager.<br />
Communication with a remote Ingres database requires installation of the<br />
Ingres Net client on the Reporter machine<br />
(GUI or Engine box). To diagnose<br />
connection or start-up problems - consult the log files.<br />
<strong>DSM</strong> trace logs are maintained in the following location:<br />
/logs/TRC_REPORTER_n.LOG<br />
Specify the DETAIL log level for CF and CSTACK to get all information for<br />
infrastructure components<br />
and dependencies. For a more concise reporterspecific<br />
log file, set reporter/AM at INFO level and others at WARN level:<br />
cftrace set -f CSTACK -l WARN<br />
cftrace set -f CF -l WARN<br />
cftrace set -f CSTACK -mp "(Reporter|amlog)" –l INFO<br />
September 2007 Chapter 2: Component Details 2- 29
Report Extractor<br />
Prior to the r11 release, the Reporter used 3 log levels: Error, Warning and<br />
Information. In the r11 model, these have been mapped directly to ERROR,<br />
WARN and INFO. The DETAIL level is not used by the Reporter. As a result,<br />
when the alternative settings listed above are used, you will get all Reporter<br />
information and all significant<br />
information from AM Data Classes, while<br />
framework and stack output will be limited to errors and warnings. These<br />
settings are preferred when debugging Reporter<br />
functionality because they<br />
give a precise, reporter-focused log file.<br />
The follow are optional registry keys to log SQL statements. This enables<br />
input of additional log entries in the trace file for all ExecSQL, and most CRec<br />
record creations:<br />
[HKEY_LO<strong>CA</strong>L_MACHINE\SOFTWARE\ComputerAssociates\<br />
Unicenter ITRM\Reporter\Features]<br />
"LogSql"=dword:00000001<br />
For duration of SQL calls, add the following:<br />
" SqlTimer"=dword:00000001<br />
If the data is either missing or wrong you should inspect the<br />
result in the<br />
Reporter, using the Detail view instead of the HTML view. If the Detail view is<br />
correct, the problem may be related to the Custom HTML View defined for the<br />
report template.<br />
To inspect the raw data in result tables select the Results folder node to see<br />
table names for the results, and inspect the table using DBMS tools. If raw<br />
data is correct, the problem may be related to the result data formatting.<br />
Temporary tables are used for Directory and Software<br />
reports. Set a break-<br />
point to inspect them before they are deleted.<br />
2–30 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Web Admin Console<br />
(WAC)<br />
Web Admin Console (WAC)<br />
The Web Admin Console (WAC) follows the MVC design pattern. It supports<br />
and relies on several technologies to supply the implementation of portions<br />
of<br />
the design. The following graphic provides an architectural overview of WAC:<br />
WAC is shipped as a WAR file “wac.war” (zip) which is expanded automatically<br />
when Tomcat starts during the install. This enables <strong>DSM</strong> to modify<br />
configuration settings within the expanded files. This process is managed<br />
through WacAfterCopy .<br />
Although Tomcat is installed into the common SharedComponents folder the<br />
Tomcat configuration files are installed into <strong>DSM</strong>’s own “Web Console” folder<br />
and run up its own instance of Tomcat.<br />
Tomcat compiles jsp files at runtime into the Web Console\work folder. On<br />
occasion, if you modify jsp files the changes may not be picked up unless<br />
you<br />
delete the work folder.<br />
Online help is expanded from zip file in CVS and then compressed into<br />
wac.war file.<br />
September 2007 Chapter 2: Component Details 2- 31
Web Admin Console (WAC)<br />
WAC and AMS<br />
Diagnosing Problems<br />
AMS displays Discovered and Owned inventory and is launched embedded, and<br />
in context, in WAC and <strong>DSM</strong><br />
Explorer.<br />
Web Services are used to create, configure, stop and restart software jobs and<br />
to retrieve product functionality based on what is installed on the manager<br />
(i.e., SD, AM or RC). This determines what<br />
is displayed by WAC. Web services<br />
are also used to retrieve Query results.<br />
A separate web application is installed by <strong>DSM</strong> installer into WAC’s Tomcat<br />
instance. The <strong>DSM</strong> Installer<br />
just calls AMS’s installer.<br />
The most useful tool for diagnosing a problem with WAC is dsminfo. SetTrace<br />
batch files do not currently increase trace levels of AMS or main WAC log. The<br />
primary log file for WAC is:<br />
\Web Console\webapps\wac\WEB-INF\classes\com\ca\wac\log\waclog.log<br />
You can increase trace by setting the following in “waclog.properties”:<br />
log4j.logger.com=DEBUG<br />
Tomcat and isapi redirector logs can be found in the following location:<br />
\Web Console\logs<br />
Detailed tracing for AMS is set through the following file:<br />
<strong>CA</strong>\Unicenter<br />
<strong>DSM</strong>\Web Console\webapps\AMS\WEB-INF\classes\log4j.properties<br />
Change the following line:<br />
log4j.rootCategory=ERROR, stdjlog<br />
to read<br />
log4j.rootCategory=DEBUG, stdjlog<br />
Detailed tracing for WAC<br />
is defined through the following file:<br />
<strong>CA</strong>\Unicenter <strong>DSM</strong>\Web Console\webapps\wac\WEB-<br />
INF\classes\com\ca\wac\config\waclog.properties<br />
Change the lines that read:<br />
log4j.logger.com=ERROR<br />
2–32 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Web Services<br />
to read:<br />
log4j.logger.com=DEBUG<br />
Then, restart tomcat to pick up the changes for AMS and WAC:<br />
caf stop tomcat<br />
caf start tomcat<br />
Note: The folder path varies slightly on Linux.<br />
Web Services<br />
Following is an architectural overview of the <strong>DSM</strong> Web Services on Windows<br />
(when IIS Web Server is used):<br />
The mod_gsoap.dll originates from gsoap but has been slightly modified for<br />
use by <strong>DSM</strong>.<br />
The Webservices api connects the gsoap layer to high level API layer which<br />
provides validation and parsing of the input.<br />
The first step to using the Web Services is to login. Upon receipt of a login call<br />
the webservice api will establish a session to the high level api and will also<br />
manage the timing out of this session when it is not used.<br />
September 2007 Chapter 2: Component Details 2- 33
Web Services<br />
Any errors raised by the high level API will be caught by the web service API<br />
and converted into a SOAP fault and sent back to the client.<br />
The Highlevel API connects from webservices API layer to lower level client<br />
api’s. The primary purpose of this layer is to wrap the lower level API’s.<br />
The purpose of the high level API is to present a standard interface to each of<br />
the lower level API’s. The high level API has no knowledge of web services<br />
etc. The interface is exposes is a C interface. The web service API layer is the<br />
bridge between the standard C high level API and mod_gsoap layer. The<br />
webservice API layer is gsoap dependent - in other words it uses gsoap<br />
constructs and is the layer called by gsoap.<br />
When an HTTP XML message arrives at the web server it is routed to<br />
mod_gsoap.dll (via the url). The XML message (a Simple Object Access<br />
Protocol – SOAP) message gets converted into a function call onto<br />
Webservicesapi.dll.<br />
The webservicesapi.dll performs any necessary validation and then calls the<br />
high level API function, which exposes a standardized C interface. This<br />
standardizes differences between lower layers.<br />
Following is high level overview of the architecture on Linux using Apache Web<br />
Server. As you can see the runtime structure used by Apache is different than<br />
that used by IIS.<br />
2–34 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Things to Note<br />
Diagnosing problems<br />
Web Services<br />
When a request is made Apache can deliver that request to any one of<br />
potentially many mod_gsoap.so processes. This helps improve scalability and<br />
reliability, however, in the web service, the state is held internally. It holds<br />
interface pointers to CO, SD and AM client APIs. Therefore, the current<br />
webservice design relies on all requests for a session being directed to the<br />
same process. The above design solves this problem.<br />
All users connecting to the web service need to be authenticated.<br />
When Unicenter <strong>DSM</strong> Web Services (Web Services) is installed on a machine<br />
running IIS 6 it will enable “IIS 5.0 isolation mode” within IIS 6 automatically.<br />
This is required in order for Web Services to function correctly. However, there<br />
is a slight risk that this change may adversely affect existing web applications.<br />
If you experience problems with the web services first verify that you can<br />
reach IIS and the gsoap layer. To do this under Windows type<br />
http:///U<strong>DSM</strong>_R11_WebService/mod_gsoap.dll<br />
You must use a GET request only for fetching WSDL ! see WebWare gsoap<br />
ISAPI module documentation for more details.<br />
Then, type:<br />
http:///U<strong>DSM</strong>_R11_WebService<br />
Result…<br />
mod_gsoap Apache SOAP Server Error<br />
Only POST allowed as request for SOAP! Please see the documentation at<br />
WebWare for details.<br />
This will establish that you have basic connectivity to the web server and<br />
gsoap layer. If this does not work then there is either a problem in IIS or in<br />
connectivity with gsoap<br />
Check the webservice log file located in logs directory<br />
Log filename is TRC_CF_WEBSERVICES_X.log<br />
September 2007 Chapter 2: Component Details 2- 35
Chapter 3: <strong>DSM</strong> Explorer<br />
Architectural Overview<br />
This chapter takes a closer look at the <strong>DSM</strong> Explorer interface as well as the<br />
various plug-ins that are used. Additional details regarding other <strong>DSM</strong><br />
components can be found in the previous chapter.<br />
These topics are also discussed in the following documents:<br />
Implementation <strong>Guide</strong> (notably “Chapter 1: Understanding Unicenter<br />
<strong>DSM</strong>”)<br />
<strong>DSM</strong> HTML Help Web Services Reference <strong>Guide</strong><br />
You should also consult the following links on the Implementation Best<br />
Practices site for further information:<br />
Working with your CMS Solution<br />
http://supportconnectw.ca.com/public/impcd/r11/Unicenter/CMS_Frame.h<br />
tm<br />
Scalability Considerations (includes information regarding sizing and<br />
performance considerations)<br />
http://supportconnectw.ca.com/public/impcd/r11/scalability/scalability_gui<br />
delines__udsm.htm<br />
A full list of techdocs is also available from the following link:<br />
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp<br />
The <strong>DSM</strong> Explorer is a single EGC framework-based Admin GUI. It consists of<br />
the framework itself, a common plug-in and a number of product specific plugins.<br />
The <strong>DSM</strong> Explorer provides a homogenized view and operation of all <strong>DSM</strong><br />
products in which no product separation is apparent. As <strong>DSM</strong> products are<br />
purchased and installed the GUI simply becomes richer and more powerful.<br />
The EGC framework is a proven Win32 solution. It provides a basic<br />
tree/listview interface as well as numerous other common features. Product<br />
specific functionality is added via the concept of EGC plug-ins (DLLs which<br />
implement and exploit well defined programming interfaces).<br />
The following graphic demonstrates the architecture that is used:<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3–1
Diagnostic Tips<br />
Diagnostic Tips<br />
The EGC provides the basic explorer framework. This includes the treeview,<br />
listview, html view, tool bar, application menus as well as all the controls<br />
(widgets).<br />
The plug-ins create and populate the controls. The Common plug-in provides<br />
the top level tree hierarchy and most of the cross product functionality (with<br />
the exceptions noted as blue/violet in the above graphic). All the other plugins<br />
add features and functions to the nodes, portals and menus that are<br />
provided by the common plug-in.<br />
Visible functionality is controlled by the <strong>DSM</strong> components installed on the<br />
client and the manager<br />
Most plug-ins write to the standard <strong>DSM</strong> trace file which is: TRC_GUI_.log<br />
If you are experiencing problems with the <strong>DSM</strong> Explorer you will need to<br />
disable the plug-ins in order to isolate the problem. To do this, make the<br />
following modification:<br />
HKLM\SOFTWARE\ComputerAssociates\EGC3.0N\Plug-ins\<br />
[DWORD] Plug-inEnabled = 0<br />
3–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Common Plug-in<br />
To enable EGC Tracing edit the following:<br />
HKCU\Software\ComputerAssociates\EGC3.0N\Trace<br />
[DWORD] Enabled = 1<br />
[DWORD] Level = 5<br />
[STRING] Location=“C:\”<br />
When you restart EGC the following files are created:<br />
Common Plug-in<br />
EGC3.0____info.txt (modules loaded by EGC)<br />
EGC3.0____log.txt (trace information)<br />
To display EGC node information select the node and press Ctrl+Alt+Shift+O<br />
The purpose of the common plug-in is to glue the product specific plug-ins<br />
together in a common tree and provide common functionality and features. It<br />
provides the following:<br />
A hierarchical representation of common data<br />
Basic management services like grouping of objects<br />
Support to forward control to product specific plug-ins<br />
Common menu handling<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 3
Common Plug-in<br />
HTML interface for displaying basic information from relevant sources /<br />
products.<br />
Seamless connectivity and security across managers<br />
The following nodes are provided by the common plug-in:<br />
Here you can see an example of the UI dialogs provided by the Common plugin:<br />
3–4 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
CCNF Plug-in<br />
CCNF Plug-in<br />
The CCNF plug-in manages the configuration policies for centralized security<br />
and default computer policies. Here you can see the nodes in the tree that are<br />
implemented by the configuration GUI:<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 5
CCNF Plug-in<br />
Reading Configuration Policies<br />
Here is where you can see which configuration policies already exist and also<br />
where the user can create new policies.<br />
Note: Policies have to be sealed before they can be applied, and have to be<br />
unsealed before they can be modified.<br />
To locate the default policy requesting a policy but leave the name blank.<br />
Giving the default policy a blank name at the manager allows the GUI to<br />
localise the display name for the default policy.<br />
A GUI policy object is created for each policy that is found. For example:<br />
3–6 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Configuration Portal<br />
CCNF Plug-in<br />
The default policy contains all the managed settings while a user-defined<br />
policy, in this case the policy “Centralised Security”, only contains the sections<br />
that have been modified.<br />
When a user-defined policy is unsealed the GUI displays all the available<br />
settings, so that it matches the default policy, but only the settings that are<br />
modified from the default are actually added to the policy.<br />
These folders below the individual policy folders are called ParamSections.<br />
Under each group and asset, you will find a configuration policy node.<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 7
DM Deploy Plug-in<br />
DM Deploy Plug-in<br />
When this node is selected an HTML page is displayed on the right hand side.<br />
On the left it shows the policies that have been applied directly to this asset.<br />
In this example it is a policy call “UK Users”.<br />
Below that it shows the policies that have been inherited. These policies have<br />
been applied to groups that this asset is a member of.<br />
Details for the reported configuration that the CCNF agent returns from the<br />
agent computer can be viewed in a separate dialog.<br />
A list of scheduled configurations is provided on the right hand side along with<br />
a list of any configurations which have failed.<br />
In this example you can see a configuration that contains two policies.<br />
Because each contains different values for the same settings, the CCNF<br />
manager cannot determine which value to use – resulting in a conflict error.<br />
This error message instructs the user as to which parameters are causing the<br />
conflict so that the error can be remedied quickly.<br />
The <strong>DSM</strong> Explorer provides access to the enhanced deployment technology<br />
available in <strong>DSM</strong> r11. The access is presented in the form of a deployment<br />
wizard which itself is an EGC plug-in.<br />
The Deployment plug-in implements the following two nodes in the <strong>DSM</strong><br />
Explorer’s Control Panel:<br />
3–8 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Diagnosing Problems<br />
DM Deploy Plug-in<br />
When selected, a connection is made to the Deployment Manager, and a list of<br />
the available packages is retrieved and displayed for selection.<br />
The wizard prompts for target information and allows the administrator to scan<br />
targets for suitability and to create deployment jobs.<br />
The user can suspend the scan and go back to previous pages, but cannot<br />
move onto the next page in the wizard until the scan is complete.<br />
The EGC plug-in that contains all the functionality is Gui_dm.dll while<br />
Gui_dep_res.en is the resource plug-in that contains all the localised<br />
resources, html file, graphics, strings etc.<br />
Most of the current tracing for this plug-in is focuses on calls to the DmApi, so<br />
it is best to search for DmAPI function names such as DmPack, DmLogin, and<br />
DmStatus.<br />
To diagnose problems use the following DmApi and DmDeploy log files:<br />
TRC_CF_DMAPI_n.log (client api)<br />
TRC_CF_DMDEPLOY_n.log (manager)<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 9
Directory Browser Plug-in<br />
Directory Browser Plug-in<br />
Directory Wizard<br />
The Directory Browser plug-in provides support for browsing directory<br />
hierarchies. It includes the following:<br />
Directory wizard<br />
Directory synchronization configuration<br />
Directory browsing<br />
This particular plug-in is used by other plug-ins to manage their directory<br />
browsing such as:<br />
Query designer<br />
Security profiles<br />
Deployment<br />
Reporting<br />
The Directory wizard consists of eight HTML pages that are used to specify<br />
directory details including:<br />
Directory name<br />
Server (which it attempts to resolve from directory name)<br />
Port – default 389<br />
User credentials<br />
Base DN (which it attempts to resolve from directory name)<br />
Directory schema to use<br />
3–10 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Directory Synchronization<br />
Directory Browser Plug-in<br />
It is also used to edit schema and create directory objects. Following is an<br />
example of the Add Directory function dialog:<br />
Directory synchronization controls consists of two HTML pages which can be<br />
used to modify the directory synchronization Engine jobs.<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 11
Asset Manager (AM) Plug-in<br />
Directory Browsing<br />
The user clicks Configure to change settings for job frequency and<br />
synchronization orders. These changes are saved in command line parameters<br />
for the Engine job.<br />
This function provides directory browsing capabilities to other GUI plug-ins.<br />
Asset Manager (AM) Plug-in<br />
The Asset Manager (AM) Plug-in provides both AM specific and common<br />
functionality. It manages:<br />
Hardware Inventory<br />
Software Inventory<br />
Custom Software Definitions<br />
Asset Jobs<br />
Queries<br />
Query and Event Based Policies<br />
Engine Portal<br />
External Assets<br />
For example:<br />
3–12 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Here you can see the type of information provided:<br />
Asset Manager (AM) Plug-in<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 13
Asset Manager (AM) Plug-in<br />
3–14 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Asset Manager (AM) Plug-in<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 15
Software Delivery (SD) Plug-in<br />
Software Delivery (SD) Plug-in<br />
The SD plug-in is comprised of the following two files:<br />
gui_sd.dll which contains all the functionality<br />
gui_sd_res.en which is the English language locale. This contains the<br />
dialogs, icons and localized text<br />
The SD plug-in provides the following controls:<br />
Software Package Library<br />
Software Jobs / Distributions<br />
Software Policies<br />
Delivery Engine<br />
Software Job Management (configuration)<br />
Here you can see the related controls on the <strong>DSM</strong> Explorer:<br />
3–16 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
These controls are available through the Start menu as follows:<br />
Software Delivery (SD) Plug-in<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 17
Software Delivery (SD) Plug-in<br />
It includes the following menus:<br />
Computer menu<br />
User Profile menu<br />
Asset Group menu<br />
Server menu<br />
Server Group menu<br />
Domain menu<br />
Here you can see an example of the Domain Portal:<br />
3–18 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
It also includes the following wizards:<br />
Software Deployment Wizard<br />
Software Staging Wizard<br />
Software Policy creation Wizard<br />
Software Publishing Wizard.<br />
Software Delivery (SD) Plug-in<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 19
Remote Control (RC) Plug-in<br />
Remote Control (RC) Plug-in<br />
The RC plug-in is comprised of the following two files:<br />
gui_rc.dll which contains all the functionality<br />
gui_rc_res.en which contains the English language locale. This contains<br />
dialogs, icons and localized text.<br />
Here you can see the controls that are added to the <strong>DSM</strong> Explorer:<br />
This includes:<br />
Active Sessions – This is a list of current sessions that this manager has<br />
authenticated.<br />
Previous Session – A log of sessions that have now completed.<br />
Root Address book permissions – An area to define RC permissions that<br />
will be applied to all computers in RC address book groups.<br />
You can also define Remote Control Permissions on each group by adding<br />
users to the Remote Control Permissions folder within the group’s details<br />
section.<br />
3–20 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Remote Control (RC) Plug-in<br />
After a user has been selected, each of the following permissions can be set to<br />
“allow” or “deny.”<br />
View<br />
Stealth view<br />
Classroom<br />
Exclusive Control<br />
Secure Control<br />
Chat<br />
Send Files<br />
Receive Files<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 21
Remote Control (RC) Plug-in<br />
Require Local Confirmation<br />
Record<br />
Record on Host<br />
You can also call up this Address Book properties dialog box by right clicking<br />
on the RC Permissions node and selecting Properties. From here you specify if<br />
the Group should be a remote control address book, and if you want it to<br />
inherit the Remote Control permissions of its parent.<br />
There is also the option to “override permissions” on derived groups. This<br />
forces the same permissions onto the groups that this group contains, and all<br />
their subgroups.<br />
This is accessed from the <strong>DSM</strong> Explorer menu as follows:<br />
3–22 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Things to Note<br />
OSIM Plug-in<br />
The computer context menu includes the following RC options:<br />
OSIM Plug-in<br />
Effective Settings – this allows you to see the RC permissions that have<br />
been granted for a specific user on a specific machine.<br />
Connection Addresses - this allows you to view the addresses that this<br />
computer has reported it is listening on. You can add additional addresses<br />
also, and these will be added to the Address Books distributed to viewers.<br />
Actions – including lock, unlock and reboot.<br />
Take Control functionality is maintained in different plug-in: gui_rcView.dll.<br />
The GUI components for the OSIM plug-in are based on EGC 3.0 and Common<br />
Plug-in and include:<br />
<strong>DSM</strong> Explorer nodes<br />
Domain and Asset portal<br />
Dialogs<br />
Property Pages<br />
OS Installation Wizard<br />
Messages<br />
Here you can see how the OSIM plug-in relates to the Common plug-in and<br />
Common API.<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 23
OSIM Plug-in<br />
Here you can see an example of tree integration for Asset Groups dialog that<br />
is added by this plug-in:<br />
The System Status Portlet identifies Failed Jobs (configurable), noting:<br />
OS Image Installations, Image oriented<br />
Erroneous Boot Servers (extremely rarely)<br />
3–24 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
The overview Portlet includes controls for:<br />
Software: current installed OS image<br />
Jobs: planned and scheduled OS installations<br />
Configuration: PXE managed<br />
The OSIM plug-in implements the OSIM methods for the following CCSM<br />
database objects:<br />
Computer, Bootconfiguration, Bootserver<br />
BootParameter, Parametervalue<br />
Bootdiskimage, BootOSimage<br />
The APIs include:<br />
CCSM API (mainly)<br />
common API (special: make managed computer)<br />
OSIM Plug-in<br />
September 2007 Chapter 3: <strong>DSM</strong> Explorer 3- 25
Chapter 4: <strong>CA</strong>F<br />
This chapter provides a detailed discussion of the Common Application<br />
Framework (<strong>CA</strong>F) used by <strong>DSM</strong>, including information<br />
These topics are also discussed in the following documents:<br />
Implementation <strong>Guide</strong> (notably “Chapter 1: Understanding Unicenter <strong>DSM</strong>”<br />
and “Appendix M: <strong>CA</strong>F Scheduled Jobs” <strong>DSM</strong>”)<br />
<strong>DSM</strong> HTML Help Web Services Reference <strong>Guide</strong><br />
You should also consult the following links on the Implementation Best<br />
Practices site for further information:<br />
Working with the MDB (includes information regarding the MDB and<br />
CORA):<br />
http://supportconnectw.ca.com/public/impcd/r11/MDBMain/MDB_Frame.ht<br />
m<br />
Working with your CMS Solution<br />
http://supportconnectw.ca.com/public/impcd/r11/Unicenter/CMS_Frame.h<br />
tm<br />
The following techdocs also provide useful information:<br />
“When installing R11.2 with Common Services how does it handle having<br />
existing versions of NSM components already installed on the server”<br />
(TEC426063)<br />
“Configuration Policy to hide the System tray applet from users<br />
(TEC425430)<br />
“Initialization failed error when the caf command is used at the UNIX<br />
console” (TEC422439)<br />
Keep in mind that additional techdocs may be available after publication of this<br />
document. A full list of techdocs is also available from the following link:<br />
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp<br />
September 2007 Chapter 4: <strong>CA</strong>F 4–1
What is <strong>CA</strong>F?<br />
What is <strong>CA</strong>F?<br />
<strong>CA</strong>F provides a common, extensible runtime environment for all <strong>DSM</strong> program<br />
code. In its most basic form <strong>CA</strong>F provides the following general functionality:<br />
Perceived single service<br />
<strong>CA</strong>F runs as a single service on a computer and acts as the hub for all of<br />
the Agent, Scalability server and Manager processes. <strong>CA</strong>F does not make<br />
distinctions between the types of entities plugged into it. They all support<br />
the same basic interface and make use of the same common components.<br />
Process control<br />
<strong>CA</strong>F provides the following mechanisms for starting, stopping, pausing and<br />
restarting plug-ins:<br />
– by networked API<br />
– by command line (which calls API)<br />
– by periodic start as defined by the scheduling component.<br />
– By auto-restart. if a plug-in such as an agent fails and is terminated by<br />
the operating system, the framework can restart it (as defined by<br />
policy).<br />
Messaging<br />
An out of process messaging plug-in provides secure transmission of<br />
information. This is implemented using <strong>CA</strong>M. Messages can be routed<br />
directly to a process or to a plug-in via the framework's persistent process.<br />
In the latter case the framework will detect the intended recipient plug-in<br />
and route the message there via the plug-in's interface.<br />
Stream communications with port multiplexing<br />
Scheduling<br />
An in-process scheduling plug-in can be used to start/stop other plug-ins<br />
or send messages to plug-ins.<br />
Registration<br />
An in-process registration plug-in is used to register end systems with a<br />
<strong>DSM</strong> Domain Manager via a Scalability Server, and basic inventory is<br />
collected and passed up during the registration process.<br />
The <strong>CA</strong>F framework is dynamically extensible via the concept of plug-ins and<br />
the common component library (CCL).<br />
<strong>CA</strong>F can be many things:<br />
Periodic agent: running scheduler only. At given times it runs an agent<br />
via plug-in load/unload<br />
Manager: It runs with a set of manager plug-ins and the messenger<br />
loaded, both persistently<br />
4–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
What is <strong>CA</strong>F?<br />
Remote control agent: It runs with the port multiplexer. When a URC<br />
viewer connects to it’s port, <strong>CA</strong>F starts up the URC host agent which then<br />
accepts the connection<br />
Sector server: It runs with the AM Scalability Server plug-in running<br />
persistently<br />
Much more: It runs with the AM metering agent, RC host, the registration<br />
plug-in, messenger and an AM Scalability Server plug-in, all loaded<br />
persistently<br />
The major packages and components which are listed below are more fully<br />
described in other sections.<br />
<strong>CA</strong>F: The <strong>DSM</strong> Common Service. To the user, this is the “<strong>CA</strong> Unicenter<br />
<strong>DSM</strong> r11 Common Application Framework” service. The service hosts the<br />
actual <strong>DSM</strong> Agents, Scalability Servers and Managers.<br />
<strong>DSM</strong> Plug-in: a <strong>DSM</strong> plug-in is a component which contains <strong>DSM</strong><br />
conformant functionality. A plug-in may also delegate the functionality to a<br />
“worker” process whose lifetime it manages.<br />
Custom Plug-in: this is intended for any other functionality which is not<br />
strictly <strong>DSM</strong> conformant process.<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 3
What is <strong>CA</strong>F?<br />
<strong>DSM</strong> worker processes: the set of <strong>DSM</strong> processes covering Agents,<br />
Scalability Servers and Managers. These are managed by instances of the<br />
<strong>DSM</strong> plug-in. Note also that only a subset of Manager worker processes<br />
are dependent on the MDB.<br />
Common Component Library (CCL): a set of components implementing<br />
shared, re-usable functionality, including: messaging, tracing, encryption,<br />
compression etc.<br />
Common Config (CCNF): a component which accesses a store of<br />
configuration information. This is actually part of CCL but is shown<br />
separately here because it is critical to <strong>CA</strong>F. The config component<br />
provides a consistent means of getting and setting configuration values.<br />
The storage location of the values themselves is hidden from the client of<br />
the component. The values may be supplied at install time and may be<br />
locally or centrally managed.<br />
Manager Proxy: this component is used to provide management<br />
capabilities for agents. It handles manager location, registration and<br />
commands sent by a manager (described elsewhere).<br />
Scheduler: Manages scheduled execution of plug-ins.<br />
Port MUX: the port multiplexer. This provides a single listening port for<br />
TCP and another for UDP connections. When a connection is made (for<br />
example, from the URC viewer), the multiplexer detects which plug-in the<br />
connection is intended for and gives it a new socket with which to<br />
continue. This allows multiple plug-ins to share the same port and is<br />
intended to make life easier for the customer when configuring firewalls.<br />
Messenger: the messaging component. This is used for connectionless<br />
reliable and secure transfer of information. All messages from managers,<br />
GUI’s and command line tools use the messenger.<br />
MDB: The common <strong>CA</strong> database. Only a subset of Manager worker<br />
processes uses this.<br />
<strong>DSM</strong> Explorer: this is the common <strong>DSM</strong> admin GUI. It provides a single<br />
view of the <strong>DSM</strong> system.<br />
System Tray Applet: This provides a single icon on the system tray and<br />
allows the user to see the status of <strong>CA</strong>F and issue some commands.<br />
CLI: this is supported by caf.exe itself and is used by administrators to<br />
start, stop or interrogate plug-ins and consequently any worker processes<br />
they are associated with them. The command line sends messages to the<br />
service using the messenger component.<br />
On Windows <strong>CA</strong>F runs as a windows service (<strong>CA</strong>F.EXE) called the “<strong>CA</strong> <strong>DSM</strong><br />
Common Application Framework” while on Linux\UNIX it runs as a daemon<br />
(caf).<br />
<strong>CA</strong>F provides a command line which allows administrators local and remote<br />
access to <strong>CA</strong>F functionality. The syntax is as follows:<br />
4–4 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
OS Services<br />
Tracing<br />
caf command [options … | arguments ...] [output | append filename]<br />
OS Services<br />
Please refer to the <strong>CA</strong> Unicenter <strong>DSM</strong> r11 Implementation <strong>Guide</strong> for full details<br />
of the <strong>CA</strong>F command line options.<br />
In addition to communication (messaging and networking) <strong>CA</strong>F provides the<br />
following OS services:<br />
Tracing<br />
Security<br />
Localization<br />
Configuration<br />
Compression<br />
Encryption<br />
Basic Inventory<br />
Common Utilities<br />
XML Parser<br />
Directory Integration<br />
Event Logging<br />
All common components are built using a straightforward, proprietary<br />
component interface and take the form of DLLs that can be dynamically loaded<br />
and unloaded as and when required.<br />
Backward compatibility is provided for interface versions. <strong>CA</strong>F checks that the<br />
version the client wants is the one that a component offers. Old interface<br />
versions can also be offered so that changes to the interface do not break<br />
clients compiled with the older versions.<br />
The syntax for running a <strong>CA</strong>F trace is as follows:<br />
cftrace –c set –f –pp –l DETAIL –s <br />
where:<br />
= UAM, USD, URC, DTS, CSTACK or CF<br />
= See table below<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 5
OS Services<br />
tracefilesize is size of file in Kb before it flips.<br />
For example:<br />
cftrace –c set –f UAM –l DETAIL –s 30000<br />
Sets detailed tracing on for all Asset Management-specific components and a<br />
log file size of 30Mb, which flips and cycles when full so the total amount of<br />
data captured will be approx 60Mb.<br />
Valid values for are listed in the following table:<br />
<strong>CA</strong>F Plug-in Binary Processor Plug-in Log file<br />
- <strong>CA</strong>F <strong>CA</strong>F_CMD TRC_CF_<strong>CA</strong>F_CMD.log<br />
- Caf <strong>CA</strong>F_CMD TRC_CF_<strong>CA</strong>F_CMD.log<br />
- <strong>CA</strong>F <strong>CA</strong>F_SERVICE TRC_CF_<strong>CA</strong>F_SERVICE.log<br />
- cafC <strong>CA</strong>F_SERVICE TRC_CF_<strong>CA</strong>F_SERVICE.log<br />
systray cfSysTray SYSTRAY TRC_CF_SYSTRAY.log<br />
ccsmagt - Ccsmagt TRC_CSMAGENT.log<br />
ccnfagent ccnfAgent CcnfAgentWorker TRC_CCNFAGENT.log<br />
pmux (lib) cfPmuxPlugin cfPmuxPlugin TRC_CFPMUXPLUGIN.log<br />
smserver Cfsmsmd CFSMSMD TRC_CF_CFSMSMD.log<br />
- Dmscript DMSInterpreter TRC_DMSINTERPRETER.log<br />
cfnotsrvd Cfnotsrvd Cfnotsrvd TRC_CF_NOTSRVD.log<br />
cfftplugin cfFTPlugin cfFTPlugin TRC_CF_FTPLUGIN.log<br />
cfregister (lib) cfRegister cfRegister TRC_CF_REGISTER.log<br />
- cfUsrNtf cfUsrNtf TRC_CF_USRNTF<br />
sdagent sd_jexec SDAgent TRC_USD_SDAGENT.log<br />
- sd_msiexe SDMSIExe TRC_USD_SDMSIEXE.log<br />
amagent amagentsvc amagent TRC_AMAGENT.log<br />
amagent amagent amagent TRC_AMAGENT.log<br />
amswmagtu amswmagt UAM TRC_UAM.log<br />
amswmagtw amswmagt UAM TRC_UAM.log<br />
- Amsoftscan UAM TRC_UAM.log<br />
ampmagent capmuamagt amperfagent TRC_AMPERFAGENT.log<br />
rchost rcHost _HOST TRC_URC_HOST.log<br />
4–6 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
<strong>CA</strong>F Plug-in Binary Processor Plug-in Log file<br />
rchost rcHost URC TRC_URC.log<br />
ttsagent tngdta dtsagent TRC_DtsAgent.log<br />
dtsmg tngdtmg dtsagent TRC_DtsAgent.log<br />
dtsbrowser tngdoba dtsbrowser TRC_DtsBrowser.log<br />
- - BACKUP_AGENT TRC_BACKUP_AGENT.log<br />
- (lib) ammsapi Metering API TRC_AMMeterAPI.log<br />
ccsmsvr- ccsmsvrd ccsmsvr TRC_CSMSERVER.log<br />
cserver cserver cserver TRC_CSERVER.log<br />
- sd_sscmd SSCMD TRC_USD_SSCMD.log<br />
sdmpcserver sdmpcworker sdmpcworker TRC_USD_PMCWORKER.log<br />
sdserver sd_server SDServer TRC_USD_SDSERVER.log<br />
amms amms Metering Server TRC_AMMMS.log<br />
amrss amrss RSS TRC_AMRSS.log<br />
rcserver rcServer _SERVER TRC_URC_SERVER.log<br />
- - BACKUP_SERVER TRC_BACKUP_SERVER.log<br />
dtssos tngdtsos dtssos TRC_DtsSos.log<br />
dtsnos tngdtnos dtsnos TRC_DtsNos.log<br />
dtstos tngdttos dtstos TRC_DtsTos.log<br />
rcmanager rcManSrv _MANSRV TRC_URC_MANSRV.log<br />
- (lib)sqlexec sqlexec TRC_DBAPI.log<br />
highlevelapi <strong>DSM</strong>HLAPI TRC_HLAPI.log<br />
- ccnfclient ccnfclient TRC_CCNFCLIENT.log<br />
ccsmact ccsmactd ccsmact TRC_CSMACT.log<br />
ccsmapi ccsmapid ccsmapi TRC_CSMAPI.log<br />
tomcat java cfjvmplugin TRC_CF_JVMPLUGIN.log<br />
- webservieapi.dll <strong>DSM</strong>WebServices TRC_CF_WEBSERVICES.log<br />
cmcontdiscover cmContDiscover cmContDiscover TRC_CF_CMCONTDISC.log<br />
dmdeploy DMDeploy DMDeploy TRC_CF_DMDEPLOY.log<br />
cmobjectmanager cmObjectManager cmObjectManager TRC_CMENGINE.log<br />
- cmDirEngJob cmDirEngJob TRC_CMDIRENGJOB.log<br />
OS Services<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 7
OS Services<br />
<strong>CA</strong>F Plug-in Binary Processor Plug-in Log file<br />
ammanager amObjectManager AMManager TRC_AMMGR.log<br />
sdmgr_tm sd_taskm tm TaskMan TRC_USD_TASKMAN.log<br />
sdmgr_dm sd_dialog_m DialogM TRC_USD_DIALOGM.log<br />
sdmgr_api sd_apisrv ApiServer TRC_USD_APISERVER.log<br />
sdmgr_im sd_taskm im InstMan TRC_USD_INSTMAN.log<br />
- sd_ahdcmd sd_ahdcmd TRC_USD_SDAHDCMD.log<br />
sdmgr_ft sd_mgr_ft SDMgrFT TRC_USD_SDMGRFT.log<br />
sd_dtpush SdDtPush TRC_USD_SDDTPUSH.log<br />
sd_dtsft DtsFT TRC_USD_DTSFT.log<br />
rcManagerR11Migra<br />
tion<br />
BACKUP_WORKER TRC_BACKUP_WORKER.log<br />
BACKUP_MANAGER TRC_BACKUP_MANAGER.log<br />
Migration_CSM TRC_MIGRATION_CSM.log<br />
Migration_USD TRC_MIGRATION_USD.log<br />
Migration_URC TRC_MIGRATION_URC.log<br />
Migration_UAM TRC_MIGRATION_UAM.log<br />
(lib)amRsapi RSAPI TRC_AMRAPI.log<br />
dmsedit DMSEditor TRC_DMSEDITOR.log<br />
dsmreporter REPORTER TRC_REPORTER.log<br />
dsmgui GUI TRC_GUI.log<br />
(lib) dmapi DMAPI TRC_CF_DMAPI.log<br />
BACKUP_MGUI TRC_BACKUP_MGUI.log<br />
(lib) gui_rc _EXPLORER TRC_URC_EXPLORER.log<br />
(lib) gui_rcView _VIEWER TRC_URC_VIEWER.log<br />
(lib) gui_rcReplay _REPLAYER TRC_URC_REPLAYER.log<br />
(lib) rcHostGUI _HOSTGUI TRC_URC_HOSTGUI.log<br />
(lib) gui_rcWrap _WRAPPER TRC_URC_WRAPPER.log<br />
rcUtilCmd(lib) _UTILCMD TRC_URC_UTILCMD.log<br />
4–8 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Security<br />
There are three primary aspects to common security:<br />
Authentication<br />
Security<br />
Authentication provides confidence that the requesting object is who they<br />
say they are. It is employed for login and machine to machine<br />
communications (application to application).<br />
Authorization (Permissions)<br />
Components use the verified identities to lookup rights and privileges to<br />
apply to the requested operation. This occurs in the MDB via an API.<br />
Data Encryption<br />
This can occur on the disk or over the network.<br />
Some common terms you should be familiar with for this topic include:<br />
URI - Uniform Resource Identifier. Similar to a URL. The format of a<br />
URI is:<br />
Format – “:///”<br />
Where is the namespace (a.k.a “Provider”). For example:<br />
– winnt: Primarily Windows NT domain and local SAM’s.<br />
– unixl: Unix local account (shadow password file)<br />
– ldap: LDAP directory access<br />
– nds: NDS directory access<br />
– x509cert: X.509 V3 certificates<br />
and identifies a security database of some form – local SAM,<br />
domain SAM, NDS directory, Unix password file.<br />
Security Scheme. Each security component may be able to use one or<br />
more protocols to provide authentication. For example:<br />
– winnt:(ntlm) – NTLM authentication using SSPI<br />
– winnt:(krb5) – Kerberos authentication using SSPI<br />
– winnt:(plain) – LogonUser authentication using RSA crypto<br />
– unixl:(plain) – shadow file access using RSA crypto<br />
– x509cert:(dsm) – certificates using <strong>DSM</strong> RSA crypto<br />
– local: special – represent O/S local interface<br />
Security Schemes are usually hidden – only used explicitly by SM and RC.<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 9
Security<br />
Authentication<br />
Authority Browsing<br />
CCL Security provides<br />
Authentication<br />
Authorization assistance & access tests<br />
Authority browsing<br />
Authority management<br />
Identity reporting<br />
Authentication is the process of a security principal proving they are who they<br />
say they are through:<br />
“Something I know” – for example, a password<br />
“Something I have” – such as a smart card / certificate<br />
“Something I am” - in other words, biometrics<br />
The CCL Security Authentication component provides authentication services<br />
to local and remote services. It links closely with the Session Messaging<br />
services to provide authentication services for messaging clients.<br />
It also provides mechanisms for being inserted into other transports, such as a<br />
networking stream, to allow for the same authentication methods to be used<br />
by all services.<br />
Authentication is used by Networker, RC, Configuration, COAPI, AM, SD,<br />
Session Messaging - nearly everywhere! CCL security does NOT provide<br />
authorization - in <strong>DSM</strong> this is provided by the OLS component. CCL Security<br />
does provide:<br />
Membership evaluation<br />
Upper security layers also require group membership tests for<br />
authorization<br />
Access restriction<br />
The NDS provider has to manually test for logon-hours, etc., as the API does<br />
not enforce these.<br />
An “authority” is a security database of some form – for example, a local SAM,<br />
domain SAM, NDS directory, Unix password file. It provides a generic<br />
interface for browsing for:<br />
4–10 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Users<br />
Groups<br />
Computers<br />
Management<br />
Some authorities are always enabled for authentication, such as O/S native<br />
and certificates.<br />
Security<br />
Some authorities are specified by manager policy, such as External directories<br />
– LDAP, NDS.<br />
The security components manage the list of available authorities and security<br />
schemes including those that are:<br />
Implicit: where certificate authority always enabled (<strong>DSM</strong> r11)<br />
Explicit: where external directories always enabled by manager policy<br />
Derived: where O/S providers are calculated in priority order:<br />
– Global – domain<br />
– Local – local SAM (Windows – but not DC’s) or local machine (Unix)<br />
– Trusted – explicitly trusted domains<br />
Note: There is no GUI mechanism to support implicitly trusted domains. These<br />
must be added using cfspsetpass – a supported tool in r11.2.<br />
The security components are responsible for generating the URI’s which<br />
represent the current machine and the logged on user(s) in varying<br />
namespaces.<br />
These only work where the URI’s can be reliably generated:<br />
NT<br />
Unix<br />
NDS (with NW client support)<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 11
Security<br />
Encryption<br />
Encryption is used to secure data and secure communication. Here you can<br />
see the relationship between the encryption function and the common<br />
configuration:<br />
Encryption provides a low-level wrapper around the eTPKI that is used for:<br />
Digital signatures<br />
Generating, importing, exporting keys<br />
Data encryption<br />
Supported cryptographic algorithms: RSA/DES/3DES<br />
Used by:<br />
CCNF (comstore)<br />
Session Messaging<br />
High-level interface for data encryption.<br />
Automatic key handling<br />
User based encryption is used by RC viewer (local address book)<br />
System based encryption is used by RC host (users for local security)<br />
ITRM encryption mode is used to secure the DB password<br />
The 3DES algorithm is used in NETWORK mode to negotiate secure peer-topeer<br />
communication.<br />
3DES session key is integrated in the Networker. It is used by CFFTPlug-in<br />
(NOSless file transfer), DTS agent, and RC host – viewer (supports legacy<br />
negotiation for URC 6.0 connections)<br />
Run Time Requirements include Etpki 2.3.3. (OpenSSL 0.9.7d):<br />
On Windows: ipthread.dll, libetpki2.dll, libetpki2_thread.dll<br />
4–12 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Authorization (Object Level Security)<br />
On Unix: libetpki2.so, libetpki2_thread_posix.so<br />
Logging is done to the file of the calling component.<br />
Security<br />
<strong>DSM</strong> Object Level Security (OLS) is based on the USD 4 permissions model:<br />
Security Profile<br />
This is a role/group/individual user mapped from a security provider (for<br />
example, an NT domain group).<br />
Class ACE (Class level security)<br />
For each profile one Class ACE will be assigned for each type of secured<br />
object.<br />
From the start only Class ACE exists for all objects. This is the default ACE<br />
for an object of a given type. This ACE value is used.<br />
Object ACE (Object Access Control Element)<br />
Permissions assigned to an object<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 13
Security<br />
Access Control<br />
Ownership<br />
An object is either owned by a user or is said to be unassigned. When a<br />
background process creates an object, that object is usually unassigned. If<br />
you create an object, your user ID is the owner of the object. As the owner<br />
of an object you inherit all permissions associated with the “Owner”<br />
security profile. “Owner” is a special security profile, created at install time<br />
and set to Full Access by default.<br />
Take Ownership<br />
A user gets the ownership of an object<br />
Authorization concerns itself with the rights and privileges associated with an<br />
authenticated entity (typically a logged in user, but could be a<br />
machine/process/application). The common authorization sub-system covers<br />
class level, group level, object level and functional security.<br />
It is based on the concept of an Access Control Entry (ACE), which is a bitoriented<br />
integer. The following eight bits are currently used:<br />
V View bit, allows you to show objects.<br />
C Create bit, allows you to create objects.<br />
R Read bit, allows you to read sub-objects of an object.<br />
W Write bit, allows you to change and object.<br />
X Execute bit, allows execution, depends on object type.<br />
D Delete bit, allows you to delete objects.<br />
P Permission bit, allows you to change the ACE itself.<br />
O Ownership bit, allows you to take ownership of an object.<br />
A permission mask is the complete ACE for a specific entity. The way to<br />
obtain this is to OR every ACE associated with the specific secured entity.<br />
There are exceptions to this rule:<br />
If one ACE is all zeros (no access) then the resulting permission mask will<br />
be zero (no access)<br />
If it is the “everyone” profile that has all zero (no access) then the<br />
exception above is invalid.<br />
4–14 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Things to Note<br />
Security<br />
It is very important that you understand the relationship between the User and<br />
the Security Profile. A user can be a member of more than one Security<br />
Profile and, in that case, the user has cumulative rights (i.e., permissions are<br />
OR’d together).<br />
When permissions are defined for a group, rights are inherited. Inheritance<br />
can be enabled or disabled for each individual group.<br />
Unlike the previous r4 USD release, the “No Access” permission does not<br />
override all other permissions.<br />
There is no replication of security profiles or permissions.<br />
Components that use OLS include:<br />
Every DAI component using the DBAPI<br />
Web Admin Console<br />
<strong>DSM</strong> AM Manager ( AMO Data classes)<br />
CLS-SD Stored procedures<br />
Test of the permissions must be very fast. It needs to:<br />
Use simple select for permission<br />
Calculate the effective permissions when an object is created or a<br />
permission is changed<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 15
Security<br />
Applicable MDB Tables<br />
Following are the MDB tables used by security:<br />
Class level permissions are maintained in the ca_class_ace table<br />
Object level permissions are maintained in the ca_object_ace table<br />
Group level permissions are maintained in the ca_group_acen table<br />
Following is the list of security profiles used:<br />
Profile Name Purpose<br />
Everyone This profile initially has class permissions.<br />
NO_ACCESS for all classes<br />
Owner This profile is necessary for managing dynamically<br />
created objects so that every object will be assigned<br />
to an owner profile.<br />
Ownership may be changed via an application, such as<br />
a UI<br />
Distributions This profile is used by the Enterprise. Administrators<br />
have class permissions<br />
FULL_CONTROL for all objects<br />
Administrators This security profile is for the local user. User group is<br />
called ADMINISTRATORS. This profile initially has<br />
class permission FULL_CONTROL for all objects<br />
4–16 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
The following table identifies the relationship between the GUI level object,<br />
their corresponding DB tables, Security Class ID and Level used in the<br />
Common Table.<br />
GUI Level DB Tables Security Class ID Security Level<br />
Computers ca_discovered_hardware SEC_CLSID_COM_COMPUTER Class, Object<br />
Users ca_discovered_user SEC_CLSID_COM_USER Class, Object<br />
Computer<br />
Users<br />
Ca_link_dis_hw_user SEC_CLSID_COM_COMPUTER_USER Class, Object<br />
Managers ca_manager SEC_CLSID_COM_MANAGER Class, Object<br />
Servers ca_server SEC_CLSID_COM_SERVER Class, Object<br />
Groups of all<br />
above<br />
Group of<br />
assets<br />
Group of<br />
servers<br />
Group of<br />
domains<br />
ca_group_def SEC_CLSID_COM_GROUP [1] Class, Group,<br />
Object<br />
ca_group_def SEC_CLSID_COM_ASSET_GROUP Class, object<br />
Ca_group_def SEC_CLSID_COM_SERVER_GROUP Class, object<br />
ca_group_def SEC_CLSID_COM_DOMAIN_GROUP Class, object<br />
Queries ca_query_def SEC_CLSID_COM_QUERY Class, object<br />
Security<br />
The following table identifies the GUI level object and the corresponding DB<br />
tables, Security Class ID and Level used in the Security Table.<br />
GUI Level DB Tables Security Class ID Security Level<br />
Class<br />
Permission<br />
Security<br />
Profiles<br />
ca_class_def SEC_CLSID_SEC_CLASS_SECURITY_<br />
OBJECT<br />
Class, Object<br />
ca_security_profile SEC_CLSID_SEC_SECURITY_PROFILE Class, Object<br />
MDB Access -- SEC_CLSID_MDB_ACCESS Class<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 17
Security<br />
The following table identifies the GUI level object and the corresponding DB<br />
tables, Security Class ID and Level used in the Software Delivery Table.<br />
GUI Level DB Tables Security Class ID Security Level<br />
SW Packages usd_rsw SEC_CLSID_USD_SOFTWARE Class, Object<br />
SW Procedures usd_actproc SEC_CLSID_USD_PROCEDURE Class, Object<br />
SW Groups Usd_swfold & type=1 SEC_CLSID_USD_SW_GROUP Class, Object<br />
Procedure groups Usd_swfold & type=2 SEC_CLSID_USD_PROC_GROUP Class, Object<br />
Job containers Usd_job_cont SEC_CLSID_USD_JOB_CONTAINER Class, Object<br />
Jobs Usd_activity SEC_CLSID_USD_JOB Class, Group,<br />
Object<br />
Distribution<br />
containers<br />
Usd_contfold SEC_CLSID_USD_DIST_CONTAINER Class, object<br />
TM Tasks Usd_task SEC_CLSID_USD_TASK Class<br />
Container Usd_cont SEC_CLSID_USD_CONTAINER Class, object<br />
The following table identifies the GUI level object and the corresponding DB<br />
tables, Security Class ID and Level used in the Asset Management Table.<br />
GUI Level DB Tables Security Class ID Security Level<br />
Jobs Ncjobcfg + column<br />
job_category<br />
Modules Ncmodcfg + column<br />
motype<br />
SEC_CLSID_ASSET_JOBS<br />
SEC_CLSID_ENGINE_JOBS<br />
SEC_CLSID_MODUL_INVENTORY<br />
SEC_CLSID_MODUL_TEMPLATE<br />
SEC_CLSID_MODUL_SOFTWARE<br />
SEC_CLSID_MODUL_METERING<br />
Policies Polidef SEC_CLSID_POLICY_QUERYBASED<br />
SEC_CLSID_POLICY_EVENTBASED<br />
Class<br />
Class<br />
Class<br />
Class<br />
Class<br />
Class<br />
Class<br />
Class<br />
Software Ca_software_def SEC_CLSID_AMO_SW Class, Object<br />
Engines Ca_Engine SEC_CLSID_AMO_ENGINE Class, object<br />
4–18 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Security<br />
The following table identifies the GUI level object and the corresponding DB<br />
tables, Security Class ID and Level used by the <strong>DSM</strong> Explorer Table.<br />
GUI Level DB Tables Security Class ID Security Level<br />
GUI task wizard [*] -- SEC_CLSID_COM_TASKWIZ<br />
(this is no longer used)<br />
Enable Control<br />
Panel<br />
Enable Remote<br />
Control<br />
Class<br />
-- SEC_CLSID_COM_CONTROL_PANEL Class<br />
-- SEC_CLSID_COM_REMOTE_CONTROL Class<br />
The following table identifies the GUI level object and the corresponding DB<br />
tables, Security Class ID and Level used by Other MDB Tables.<br />
GUI Level DB Tables Security Class ID Security Level<br />
External directories Ca_directory_details SEC_CLSID_DIR_EXT_DIRECTORY Class, Object<br />
Report Template Rptree & type = 3 SEC_CLSID_REPORT_TEMPLATE Class<br />
Schedule Template Rptree & type = 40 SEC_CLSID_SCHEDULE_TEMPLATE Class<br />
Configuration<br />
Policies computer<br />
Configuration<br />
Policies user<br />
OSIM object –<br />
Boot/OS images<br />
Troubleshooting<br />
Csm_object and<br />
csm_class is<br />
ConfPolicyComp<br />
Csm_object and<br />
csm_class is<br />
ConfPolicyComp<br />
Csm_object and<br />
csm_class is “OSimage”<br />
OR<br />
csm_object and<br />
csm_class is<br />
“BootImage”<br />
SEC_CLSID_CCNF_POLICY_COMP<br />
SEC_CLSID_CCNF_POLICY_USER<br />
SEC_CLSID_OSIM_IMAGE<br />
There may occasionally be problems with a long running query such as a query<br />
created by the DBAPI.<br />
If object are not visible in the Explorer but full control is provided:<br />
Check permissions in the MDB<br />
Check stored procedures<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 19
Communication<br />
Communication<br />
Streams<br />
In an attempt to reduce port usage, complexity, volume of code and to<br />
improve reliability and supportability <strong>DSM</strong> r11 introduces two types of common<br />
communications:-<br />
connection-oriented, multiplexed, stream-based networking. Provided by<br />
two components; “the Networker” and “The Port Multiplexer”<br />
connectionless, message-based messaging. Provided by two<br />
components; “The Messenger” and “Session Messaging”<br />
The diagram below illustrates the conceptual position of these components<br />
within the <strong>DSM</strong> R11 stack.<br />
Stream-based communications is provided by the common networking<br />
component which provides an interface to support (primarily) stream- based<br />
communications but also includes support for low volume datagram-based<br />
networking. In other words, for datagrams, it provides the ability to unicast,<br />
broadcast or multicast ‘trigger’ packets and handle responses to these<br />
packets.<br />
There are two distinct parts to the networking component: the Networker and<br />
the Port Multiplexer.<br />
4–20 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Networker<br />
Port Multiplexer<br />
Communication<br />
The Networker is a generic, protocol-independent interface to stream based<br />
networking. This is a loadable component, which makes use of other loadable<br />
components to provide support for specific protocols, such as TCP/IP.<br />
The Networker supports Synchronous or Asynchronous (API). The<br />
Asynchronous (non-blocking) API uses the CCL Notification object and<br />
separate threads for sending, receiving and listening. The Synchronous<br />
(blocking) API uses CCFNetwork::Select to process incoming connections in<br />
the case of a listening networker and to determine if there is data to process<br />
on the receive queue.<br />
Synchronous/Asynchronous mode is determined by passing a notification<br />
object to the CCFNetwork::Init routine.<br />
As most datagram-style communications are intended to use the messenger<br />
component, the Networker restricts the messaging styles it supports.<br />
Datagram messaging is needed especially when interfacing with external<br />
resources.<br />
The Networker makes use of a lower level interface to protocol specific<br />
components. These components are given logical names (which may map on<br />
to ‘well known’ protocols such a ‘TCP’ or may be something less obvious). The<br />
logical name is associated with a ‘configuration set’ which conditions the<br />
behavior of the component. Some of the configuration information is used by<br />
the generic layer and some by the specific layer (and some may be shared and<br />
exposed externally).<br />
One important detail included in the configuration set is the name of the<br />
dll/shared library which implements protocol support. The configuration set<br />
may also include information used by the protocol support itself, such as the<br />
entity it should act as when listening for incoming connections.<br />
This model gives great flexibility is allowing a single DLL to act for multiple<br />
protocols, where the protocols are ‘well known’ or convenient tailoring of a<br />
particular implementation.<br />
The Port Multiplexer is a plug-in that listens for stream connections and<br />
forwards them to the process that requires them. It handles connection<br />
establishment and enables multiple applications to listen on a single port.<br />
The default listen port is 4728.<br />
Applications use virtual ports and incoming connections handed off to waiting<br />
applications.<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 21
Communication<br />
The Port Multiplexer only supports TCP.<br />
Since the Port Multiplexer has its own API set it is not necessary to convert<br />
existing applications to use the Networker (see below) in order to use the<br />
Networker services. The conversion is straightforward and adopting such an<br />
approach has benefits over using the Networker including: -<br />
Existing pre-release 11 components can be communicated with<br />
(which might not be the case with the Networker, which imposes its own<br />
protocols on the data interchange). The Port Multiplexer can also listen<br />
directly on ‘legacy’ ports which allows applications which haven’t been<br />
converted to use the multiplexer to converse with those which have,<br />
without requiring the converted application to handle multiple concurrent<br />
connection styles.<br />
Existing logic can be preserved. Often, changing to use the Networker<br />
will involve changing the style of interacting with the communications.<br />
Application logic is often based on the behavior of the interfaces used.<br />
The Pmux API routines send a small message to the plug-in which is listening<br />
on port 4728. Message types include:<br />
Listen<br />
Legacy Listen<br />
Connect<br />
Query<br />
PMUX and Networker Working Together<br />
The Messenger<br />
The Port Multiplexer and Networker are complementary solutions. The<br />
Networker will make use of the port multiplexer in order to make or allow<br />
connections. For example, instead of listening for a connection, a Networker<br />
will ask the Port Multiplexer to listen on its behalf and the Port Multiplexer will<br />
hand over connection to it. Similarly, when making a connection to another<br />
machine, the Networker will connect to a remote port multiplexer nominating<br />
the (virtual) port it wishes to connect to. That Port Multiplexer will accept its<br />
connection and hand it over to the ‘real’ listener. Thus, all <strong>DSM</strong> components<br />
on a machine can share a single port for all connections.<br />
<strong>DSM</strong> r11 messaging is delivered via the Messenger common component. The<br />
Messenger provides an abstraction layer, implemented on top of <strong>CA</strong>M, which<br />
separates its users from the messaging system actually in use.<br />
4–22 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Session Messaging<br />
Communication<br />
Each component allocates its own <strong>CA</strong>M queue along with a worker thread to<br />
poll messages from this queue. The Messenger component will then deliver<br />
messages asynchronously to the component subscriber.<br />
The Messenger is message format-agnostic and includes the capabilities to<br />
build additional layers on top of it. These layers may be generic (for example,<br />
supporting encryption or compression) or specific (for example, building a<br />
remote procedure call (RPC) model with its particular message structure on<br />
top).<br />
Each Messenger ‘object’ represents a distinct logical connection to the<br />
messaging system with its own identity. Message objects provide a convenient<br />
method of encapsulating incoming messages.<br />
An object/structure is also provided to abstract the addressing of messages.<br />
This has two components. The first is the machine the message should be<br />
directed to and the second is the identity of the component, relative to that<br />
machine. (In <strong>CA</strong>M terms, this equates to a ‘host name’ and a ‘queue name’).<br />
The Messenger API provides an interface to declare an interest in a messenger<br />
connection and to give that connection a logical name. It also provides a<br />
means of sending messages.<br />
Message receipt and failure notifications are notified asynchronously. Such<br />
notification will normally take place in a thread different from the one used to<br />
send messages.<br />
Session Messaging (SM) is a client-server layer that sits atop the <strong>DSM</strong><br />
Messenger component. SM is provided in the form of a C-based interface DLL<br />
and a management daemon (<strong>CA</strong>F plug-in). SM is modular and utilizes many<br />
common components. It provides the following<br />
Session management<br />
Encryption<br />
Compression<br />
Low-level authentication (X.509)<br />
High-level authentication (O/S or External)<br />
Transactional calls<br />
Message forwarding<br />
September 2007 Chapter 4: <strong>CA</strong>F 4- 23
Communication<br />
Receiving Data<br />
Message Forwarding<br />
SM supports 3 modes of data receipt<br />
Call-back – asynchronous call made into application space. Message<br />
released on call-back termination.<br />
Scan with call-back – synchronous call made into application space<br />
when application asks. Message release on call-back termination.<br />
Scan with output – synchronous call that returns pointer to message.<br />
Message released by application when finished with.<br />
Session Messaging is provided as a tri-interface DLL. This means that it differs<br />
slightly from other components in that it provides three interfaces for most<br />
text based APIs<br />
Wide (Unicode – UCS16)<br />
Narrow (MBCS – Current code page)<br />
Native (UTF8 – UCS8)<br />
Internally, SM tries to work in UTF8 as much as possible to be forward capable<br />
with new messaging providers. Following is an overview of the process SM<br />
uses to communicate:<br />
Client establishes a session with Dispatcher.<br />
Session bound between Client and Dispatcher.<br />
Dispatcher forwards request to a server endpoint on the local machine.<br />
Session now bound between Client and Server n.<br />
Session holds authentication and encryption<br />
Server responds to the request.<br />
Session still bound between Client and Server n.<br />
When finished, Server unbinds.<br />
Client now re-binds to Dispatcher.<br />
4–24 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Chapter 5: Installation <strong>Topics</strong><br />
This chapter discusses a several topics relating to the installation of Unicenter<br />
<strong>DSM</strong> architecture, including:<br />
Infrastructure deployment<br />
Migrating\upgrading from a previous installation\version<br />
NAT Environments<br />
For additional information you should consult the following sources:<br />
Implementation <strong>Guide</strong> (notably “Chapter 2: Planning the Infrastructure<br />
Implementation”, “Chapter 3: Installation of Unicenter <strong>DSM</strong>” “Chapter 4:<br />
Infrastructure Deployment,” “Chapter 5: Upgrading Unicenter <strong>DSM</strong>”,<br />
“Chapter 8: Migration to Unicenter <strong>DSM</strong>,” “Appendix B: Software Delivery<br />
Procedures for Installation” and “Appendix G: Unicenter Software Delivery<br />
Query Migration Details”)<br />
Chapter 5 in the Unicenter Desktop and Server Management Diagnostics<br />
<strong>Guide</strong><br />
You should also consult the following links on the Implementation Best<br />
Practices site for further information:<br />
Working with the MDB (includes information regarding the MDB and<br />
CORA):<br />
http://supportconnectw.ca.com/public/impcd/r11/MDBMain/MDB_Frame.ht<br />
m<br />
Working with your CMS Solution<br />
http://supportconnectw.ca.com/public/impcd/r11/Unicenter/CMS_Frame.h<br />
tm<br />
Scalability Considerations (includes information regarding sizing and<br />
performance considerations)<br />
http://supportconnectw.ca.com/public/impcd/r11/scalability/scalability_gui<br />
delines__udsm.htm<br />
Upgrade checklist<br />
(http://supportconnectw.ca.com/public/impcd/r11/administration_and_ma<br />
intenance/unicenter_udsm_r11_upgrade_checkl.htm<br />
Managing hostname changes<br />
http://supportconnectw.ca.com/public/impcd/r11/Unicenter/cms_main.ht<br />
m#namechange<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5–1
Infrastructure Deployment<br />
Infrastructure Deployment<br />
The following techdocs should also be noted:<br />
“How Authentication Works in r11 for Centrally and Locally Managed<br />
Configurations” (TEC401105)<br />
“How to Centralize Security in URC r11” (TEC401138)<br />
“SQL Installation and Preparation for <strong>DSM</strong> r11 Domain and Enterprise<br />
Manager Installs” (TEC401106)<br />
“How to Move a Domain from one Enterprise to Another” (TEC401299)<br />
“How do you install the Software Delivery Agent without the need to also<br />
install the Software Catalog” (TEC430032)<br />
“SQL Installation and Preparation for <strong>DSM</strong> R11 Domain and Enterprise<br />
Manager Installs” (TEC401106)<br />
“When installing r11.2 with Common Services how does it handle having<br />
existing versions of NSM components already installed on the server?”<br />
(TEC426063)<br />
“Creating a Pre-configured Standalone Customised install for the r11<br />
Remote Control Agent” (TEC395449)<br />
Keep in mind that additional techdocs may be available after publication of this<br />
document. A full list of techdocs is also available from the following link:<br />
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp<br />
The Infrastructure Deployment subsystem facilitates the initial deployment of<br />
<strong>DSM</strong> software components within a heterogeneous enterprise. Infrastructure<br />
Deployment is also sometimes known as DMDeploy v2. <strong>DSM</strong> infrastructure<br />
components, such as Agents and Scalability Servers, can be transferred and<br />
installed without the use of Unicenter Software Delivery. This functionality is<br />
typically used for an initial roll out of the <strong>DSM</strong> infrastructure.<br />
Infrastructure Deployment uses a <strong>DSM</strong> Explorer wizard to scan for deployment<br />
targets and to configure and initiate the deployment job.<br />
Important note: When the Infrastructure Deployment wizard is completed a<br />
deployment job is created which manages the progress of the deployment to<br />
all the selected end systems. The status of this job can be viewed via the <strong>DSM</strong><br />
Explorer, but please note that the job is NOT persistent; it is maintained in the<br />
memory space of the DMDeploy manager process. If the DMDeploy manager<br />
exits for any reason (crashes, is restarted, machine rebooted) the job<br />
information is lost as are any unprocessed status messages from end system<br />
installations. These installations, however, will continue if already started.<br />
5–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Infrastructure Deployment<br />
Important note: All Operation Systems are not created equal. The<br />
deployment manager has different capabilities on different platforms. Two<br />
major restrictions on the Linux manager are that:<br />
it cannot push out a primer to Windows shares since it cannot run the<br />
installation command<br />
it cannot enumerate Windows domains<br />
You will get an error if you try to do the latter. The Windows manager however<br />
is fully capable of SSH and telnet/FTP deployment to UNIX variant targets.<br />
Important note: Deployment using FTP can seem back to front until you<br />
think about it. This method of deployment works as follows:<br />
First DMDeploy Manager connects to target using telnet<br />
Then DMDeploy Manager issues FTP commands over telnet on the target,<br />
pulling the primer installation image from manager to target – in other<br />
words, initiating the FTP “get” request on the target.<br />
This is different for deployment via shares and ssh, which are pushes from the<br />
manager to target. This method only requires that a single FTP server be set<br />
up on the Manager, rather than having to have one on each target.<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 3
Infrastructure Deployment<br />
Processes and Log files<br />
The diagram below gives an overview of the processes and data flow involved.<br />
Initially the DMDeploy EGC plug-in will make a request via DMAPI to install the<br />
package on a remote target(s). The following process flow is then used by the<br />
infrastructure deployment to deploy the software:<br />
1. Select payload to deploy & specify targets<br />
Using Wizard or dmsweep<br />
Can use IP addresses, directory, Windows domain<br />
All target source mechanisms result in a list of addresses to deploy to.<br />
2. Scan for targets/payload<br />
is machine in DNS?<br />
try to open socket (7)<br />
cam ping – determines presence of primer<br />
3. Transfer Manager Public Key to target<br />
Using Windows (ADMIN$) Share, SSH or Telnet/FTP (or manually).<br />
From \dmdeploy\bin\dmkeydat.pmr<br />
5–4 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Infrastructure Deployment<br />
4. DMDeploy manager will transfer DMPrimer Installer image to target (if not<br />
already installed) and, if necessary, (e.g., Windows 9x systems), DMBoot.<br />
This can be done through SMB shares, telnet/ftp or SSH depending on the<br />
type of target platform and the security that has been enabled on them.<br />
Note: Image placed in \dmsetup.exe, or /tmp/dmprimer/* on<br />
*nix<br />
5. DMPrimer installer installs itself and <strong>CA</strong>M on the target machine using<br />
either Windows RPC, SSH or Telnet (or manually). Note that DMPrimer<br />
must run with elevated privileges.<br />
Note: Some operating systems, such as Windows 9x, do not have a<br />
method for remote invocation. In these cases, it is necessary to configure<br />
the OS to install the primer on a significant operating system event, such<br />
as a reboot.<br />
6. When install completes, DMPrimer notifies manager (via <strong>CA</strong>M) of<br />
successful installation so that package deployment can now be initiated.<br />
Note: A DMDeploy manager that has either installed a DMPrimer or has<br />
authenticated with it can deploy packages without needing to re-supply<br />
usernames or passwords. This is achieved through authentication using<br />
public and private keys.<br />
Any errors up to this point usually result in “No Primer Transport”<br />
7. Manager sends payload data to Primer (using <strong>CA</strong>M messages).<br />
Data appears as a “primer.packN” file in the Primer installation folder<br />
(‘N’ is a small number).<br />
8. Primer unpacks the payload data, then sends a “package received”<br />
message to manager<br />
9. Manager sends payload installation command in a <strong>CA</strong>M message to primer,<br />
which executes it<br />
Payload installation is synchronous, no timeout<br />
Install command is logged in dmprimer.log on target<br />
10. Primer returns installation status to manager<br />
Also logged in dmprimer.log<br />
Stage to and Deploy from Scalability Server<br />
To reduce overall network traffic, deployment payloads can be “staged” to a<br />
Scalability Server. This operation is basically a normal deployment except that<br />
the installation command is replaced by a copy into a staging area.<br />
On Windows: staging area is a share (DMDEPLOYSS$)<br />
On Linux/UNIX: staging area is an FTP server.<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 5
Infrastructure Deployment<br />
Diagnosis Tips<br />
Deployment from a Scalability Server simply takes the payload data from the<br />
staging area rather than the manager library area.<br />
Note: In r11.1 the primer installation image is transferred from the Manager<br />
while, in r11.2, it can be staged at the Scalability Server.<br />
Even when a Scalability Server is used to stage and deploy software packages,<br />
control of the process is still handled by the manager.<br />
Consult the following log files if you experience problems with Infrastructure<br />
Deployment:<br />
Manager Logs use standard <strong>DSM</strong> log mechanism and the following<br />
naming convention:<br />
TRC_CF_DMDEPLOY_*.LOG<br />
Major deployment stages are logged at “INFO” level and log analyser rules<br />
are available. The Manager Logs include information regarding the<br />
connection to Windows target shares, job status and other deployment<br />
stages.<br />
Primer Logs note the exact installation command that is run along with<br />
the exit code it produces upon completion. These logs are produced in the<br />
temporary directory (%TEMP% or /tmp).<br />
Payload Installation Logs can typically be found in the following<br />
locations:<br />
– On Windows: %TEMP%<br />
– On UNIX\Linux: /opt/<strong>CA</strong>/installer/log<br />
You should also check the following logs for more information:<br />
<strong>CA</strong>M logs, if you have communication issues<br />
UNIX/Linux syslog on target computers can be useful to diagnose<br />
SSH/Telnet security issues<br />
Don’t forget to….<br />
Check Firewall settings!<br />
Full automatic deployment is not always possible because…<br />
– Windows 9x does not support remote installation of primer from the<br />
manager, and by default doesn’t let you map the ADMIN$ share.<br />
– Later Linux versions are configured to disable remote non-interactive<br />
SSH sessions.<br />
Further details can be found in the <strong>DSM</strong> Implementation <strong>Guide</strong><br />
5–6 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Upgrade of Primers<br />
Frequently asked Questions<br />
Infrastructure Deployment<br />
Primers are not automatically upgraded; therefore you will need to use the<br />
“force primer push” policy setting to achieve this. Deployment of DMPrimer<br />
uses native OS data transport mechanisms or is done manually, but, all<br />
subsequent network activity is performed via <strong>CA</strong>M (such as pushing payloads<br />
and returning payload installation status). This reliance on <strong>CA</strong>M isolates the<br />
main portion of the deployment process from networking issues and<br />
configuration.<br />
Note: This process requires re-authentication (to push new encryption keys).<br />
<strong>DSM</strong> session messaging (hence <strong>CA</strong>M) is used for all <strong>DSM</strong> Explorer Wizard to<br />
Manager communications.<br />
Following are some frequently asked questions regarding Infrastructure<br />
Deployment:<br />
What does “No Primer Transport” Job status mean?<br />
Can’t push primer to target (or it failed to install)<br />
What does “Failed to Telnet” trace message mean?<br />
This error is usually associated with the No Primer Transport status and is<br />
preceded by “failed to map share” and “failed to SSH” errors!<br />
Where have my deployment jobs gone?<br />
Jobs are not retained when the deployment manager is recycled.<br />
What can I do to test <strong>CA</strong>M Connectivity issues?<br />
Ensure that you can execute “camping” both ways between manager &<br />
targets. Also, check DNS, and firewalls configurations.<br />
Where are the agent configuration options documented?<br />
In the Implementation <strong>Guide</strong> (\doc\r11impl.pdf). See sections<br />
“Modifying Installation Property Values” (for Linux) and “Installation Tool<br />
msiexec” (for Windows).<br />
How do we add new package versions/packages for new<br />
platforms?<br />
Use the dsmPush.dms script (included on the distribution image) to do<br />
this.<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 7
Infrastructure Deployment<br />
Additional Considerations for r11.2<br />
CCNF Parameters<br />
The following are additional considerations when using the r11.2 release:<br />
Hidden CLI passwords<br />
Primer Arguments can be used to change primer installation location.<br />
A target credentials file assists with offline specification of bulk targets<br />
Less bandwidth is used between Manager and targets when a Scalability<br />
Server is used since the primer image is now transferred from Scalability<br />
Server<br />
You can now suspend a scan and proceed with deployment using current<br />
scan results - no need to wait for a scan to complete!<br />
A number of common configuration policy parameters can be modified and<br />
affect infrastructure deployment behavior as described below:<br />
AlwaysDeploy<br />
Will force payload push/install even if a newer version of the payload is<br />
detected on the target computer.<br />
AlwaysDeployPrimer<br />
Will always push the primer image and reinstall. Useful if primer install<br />
image got corrupted in some way.<br />
PingCheckSkip<br />
Detection of Deployed Packages<br />
Eliminates the quick “ping” of a target during scanning. This setting is<br />
necessary when TCP port 7 is protected by a firewall.<br />
Detection of deployed packages differs based on the operating system<br />
involved.<br />
On Windows this is done through MSI product codes. The <strong>DSM</strong> payloads<br />
(packages) include MSI product codes within dmdeploy.dat. The primer<br />
uses this code and interrogates the MSI database to check whether a<br />
product has already been deployed.<br />
Note: A payload may consist of multiple MSI products (e.g. “all agents”<br />
package).<br />
On Linux/UNIX, registration is recorded in the following file:<br />
$<strong>CA</strong>_ITRM_BASEDIR/dmprimer/bin/dmdeploy.reg<br />
5–8 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Increasing Primer Log Level<br />
Deploying to Linux over SSH<br />
Infrastructure Deployment<br />
The installer registers/deregisters a product by calling dmprimer with<br />
special args. The Infrastructure Deployment Manager asks “is product x<br />
version y installed?” not “what products have you got?”<br />
To increase the primer log level do the following:<br />
1. Change to the directory containing the dm_primer. On Windows this is:<br />
Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\DMPrimer<br />
2. Issue a 'dm_primer stop' command<br />
3. Remove the old dmprimer.log<br />
4. Edit the dmprimer.cfg file found in the above directory and change the<br />
TRACE_LEVEL value from 3 to 5.<br />
5. Deploy the software<br />
Note: There is no need to restart the primer as cam will do this automatically<br />
Note: SE Testfix T18C872 allows log level updates without restarting primer.<br />
Deployment to Linux targets using DMDeploy over SSH (the default method<br />
for Linux) is quite complex and subject to a variety of environmental<br />
obstacles. Many things have to occur successfully before the deployment<br />
payload becomes active on a target system. Unfortunately, since no <strong>CA</strong><br />
software is assumed to be present during deployment it is impossible to report<br />
accurate status and diagnostic messages during this operation. Therefore an<br />
understanding of the process is important.<br />
Following is the sequence of events that occur when deploying to Linux using<br />
SSH, to a clean system. When diagnosing problems in this area identifying the<br />
point of failure within the sequence is crucial.<br />
1. The dmdeploy manager connects to target system using ssh<br />
You should see the connection attempt logged into the system log file<br />
/var/log/secure.<br />
2. If the connection is successful, the primer installation package is pushed to<br />
the target system using ssh/sftp<br />
You should see OS processes with names containing these strings appear<br />
on the target system<br />
3. Primer image is uploaded to /tmp/dmprimer<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 9
Infrastructure Deployment<br />
You can do “ls –ltr” in this directory to monitor the growth of files as they<br />
are uploaded. In order to assist with tracking down installation issues this<br />
directory is not removed.<br />
4. When the image stops growing, the primer install (installdmp) is launched.<br />
You should see a process with this name appear in your ps list. You should<br />
also see a process running lsm.exe.<br />
5. After the primer install is finished, you should see two packages called “cadsm-dmprimer”<br />
and “ca-dsm-dmprimer-standalone” in the pif package list<br />
(“lsm –lOpif”). Primer files are installed into the following directory:<br />
/opt/<strong>CA</strong>/Unicenter<strong>DSM</strong>/dmprimer<br />
6. Dmprimer should then be started (you should see “dm_primer start”<br />
appear in the ps list). The dmprimer log file (/tmp/dmprimer.log) should<br />
also appear.<br />
7. The transfer of the deployment payload (for example, UAM agent) starts.<br />
You should see the “transferring xx%” messages appear in the GUI/CLI.<br />
This is quite quick in comparison to the primer upload in step 2.<br />
8. Package installation starts.<br />
You will see the “installdsm” process in the ps listing. The command “lsm –<br />
lOpif “will display the PIF packages currently installed. After completion,<br />
the package ca-dsm will be present. Other sub-components will be present<br />
depending on which payload you are installing.<br />
That’s it – package installation status is sent back to the manager and<br />
displayed in the GUI/CLI.<br />
Deploying to Windows over a Network Share<br />
Deployment to Windows targets using DMDeploy is subject to a number of<br />
environmental obstacles as well. As with Linux deployments, many things<br />
have to occur successfully before the deployment payload becomes active on a<br />
target system. Unfortunately, since no <strong>CA</strong> software is assumed to be present<br />
during deployment it is impossible to report accurate status and diagnostic<br />
messages during this operation. Therefore an understanding of the process is<br />
important.<br />
Following is the sequence of events that occurs when Windows is deployed to<br />
a clean system using shares. When diagnosing problems in this area<br />
identifying the point of failure within the sequence is crucial.<br />
1. DMDeploy manager attempts to open a share (by default “admin$”) on the<br />
target system.<br />
2. If the share is opened successfully the primer installation package is<br />
copied to the target system. This consists of the following 4 files:<br />
DMBoot.exe<br />
5–10 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
dmkeydat.pmr<br />
dmsetup.exe<br />
msvcr71.dll<br />
Infrastructure Deployment<br />
3. Primer image is uploaded to admin$, or whatever share the user has<br />
configured the manager to use for deployment.<br />
4. When the image stops growing, the primer install is launched by the MSI<br />
installer. The task manager will show at least one msiexec.exe process<br />
running.<br />
5. After the primer install is finished, you should see the following registry<br />
key:<br />
HKEY_LO<strong>CA</strong>L_MACHINE\SOFTWARE\ComputerAssociates\DMPrimer<br />
The key’s data will show where the primer files have been installed. The<br />
usual location is:<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\DMPrimer<br />
6. The primer should now have started and “dm_primer.exe” should appear<br />
in the task manager.<br />
The primer log file, C:\Documents and Settings\\Local<br />
Settings\Temp\dmprimer.log, should also appear at this point.<br />
7. The transfer of the deployment payload (for example, UAM agent) starts<br />
and you should see the “transferring xx%” messages appear in the GUI or<br />
the CLI. This is quite quick in comparison to the primer upload in step 2.<br />
8. Package installation starts and you should see a ‘.msi’ process<br />
corresponding to the package being installed (for example, ‘AgtAM.msi’<br />
for the Agent + Asset Management plug-in package), in the Task Manager.<br />
The ‘Add or Remove Programs’ utility, accessible from the Control Panel,<br />
will display the packages currently installed. After completion, the<br />
deployed package will be present, the exact entry obviously depending on<br />
which payload you installed.<br />
That’s it – the package installation status is sent back to the manager and<br />
displayed in the GUI/CLI.<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 11
Upgrading from a Previous Release<br />
Upgrading from a Previous Release<br />
Detailed procedures and guidelines for upgrading to the r11 release from a<br />
previous version of Unicenter Software Deliver, Unicenter Asset Management<br />
or Unicenter Remote Control can be found in the Implementation<br />
<strong>Guide</strong>. Following is an overview and additional tips to further assist you in<br />
upgrading.<br />
Direct software upgrade to release 11 is not supported. Rather, the upgrade<br />
path uses a “parallel” or “side-by-side” approach. First, the new r11<br />
components are deployed (Domain Managers, Scalability Servers and other)<br />
typically using a new, more optimal, topology. Then data is migrated from the<br />
pre-r11 databases to the new r11 <strong>CA</strong>-MDB. Following is a list of supported<br />
upgrade paths:<br />
Unicenter Software Delivery r11 can be migrated from Version 3.1 and<br />
Version 4.0<br />
Unicenter Asset Management r11 can be migrated from Version 3.2 and<br />
Version 4.0<br />
Unicenter Remote Control r11 can be migrated from Version 6.0<br />
The migration to <strong>DSM</strong> r11 is about homogenization of three distributed<br />
solutions with different architectures and separate databases into one<br />
consolidated r11 architecture.<br />
5–12 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Data Migration<br />
Upgrading from a Previous Release<br />
The change is a significant one in that three formerly disparate and<br />
independent technologies have now merged into a single technology<br />
employing a single management database structure. Additionally, as each<br />
product is multi-tiered, an upgrade approach would require extensive<br />
backwards compatibility support between the tiers during the migration<br />
process that would not add any value post migration.<br />
The end result is a simple upgrade strategy will not suffice.<br />
The <strong>DSM</strong> Implementation <strong>Guide</strong> includes a migration chapter which describes<br />
the general migration approach, limitations and challenges, as well as the<br />
specifics regarding ASM.CNF keys, MSI library migration and lots more! We<br />
strongly suggest you read this chapter.<br />
Migration to r11 is achieved via 3 distinct steps:<br />
1. The installation of management infrastructure (see the earlier discussion of<br />
Infrastructure Deployment)<br />
2. The migration of data<br />
3. The installation of new agent software<br />
The Data Migration step is driven by Engine Tasks, with one Task type per<br />
product (UAM, USD, OSIM, URC). There may be multiple legacy managers<br />
and multiple tasks for each legacy manager – which could add up to “a lot of<br />
tasks!”<br />
Migration is a continuous process and all migrated computers are visible in<br />
system group “All Legacy Computers.” The process ends when r11 Agents are<br />
registered with the MDB – at which point you should STOP managing those<br />
assets through legacy managers.<br />
The Engine reads migration job from database using the following method<br />
based on which product is being migrated:<br />
For Software Delivery, Remote Control and OSIM:<br />
An XML file is created containing Job contents. The product specific<br />
migration DLL is loaded and executed with this XML file as a parameter.<br />
For Asset Management:<br />
A call internal Engine code is made to migrate AM data<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 13
Upgrading from a Previous Release<br />
Software Delivery Specific Information<br />
There is a slight difference between what can be migrated at the Enterprise<br />
and Domain levels in terms of:<br />
Software Packages<br />
Software Groups<br />
Software Policies<br />
Computer and User Groups<br />
Computers and Users (Domain only)<br />
Computer Job History (Domain only)<br />
Security<br />
To use USD 4.0 SP1 SDGAPI to get to v4.0 data do the following:<br />
On Windows install the legacy API from <strong>DSM</strong><br />
Installpath\SD\Legacy\usd40sp1\sdapi.w32 IF and only IF USD 4.0 SP1<br />
and <strong>DSM</strong> r11 are not co-hosted.<br />
On Linux the legacy API is installed with the <strong>DSM</strong> r11 manager and no<br />
additional actions need to be taken<br />
Migration of Software Packages:<br />
Exports packages and added procedures and imports them to r11<br />
Is only done once<br />
Limited Group Membership update on each run – unlinking not detected on<br />
legacy manager<br />
Migration of Software Groups:<br />
Is only done once<br />
Limited Group Membership update on each run – unlinking not detected on<br />
legacy manager<br />
Migration of Software Policies (aka Software Templates):<br />
Is only done once<br />
Never sealed automatically<br />
Sealed Software Policies are migrated on Domain only<br />
Migration of Computer and User Groups:<br />
Is only done once<br />
Limited Group Membership update on each run – unlinking on legacy<br />
manager not detected<br />
5–14 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Upgrading from a Previous Release<br />
Limited query migration. Many queries cannot be migrated properly but<br />
they will appear in r11 as “disabled” and can be redefined using the <strong>DSM</strong><br />
Explorer post migration<br />
Migration of Computers and Users (Domain only):<br />
Is only done once<br />
Limited Group Membership update on each run – unlinking on legacy<br />
manager not detected<br />
Scoped – able to specify migration scope by naming Computer and User<br />
group on legacy manager. Only members of that group will get migrated<br />
Watch out for duplicate HOST UUIDs! HOST UUID used as primary<br />
identifier of computers in r11. Duplicates WILL mess things up!<br />
Migration of Computer Job History (Domain only):<br />
Migrated every time<br />
Records replaced on consecutive runs<br />
Records merged on last run<br />
Migration of SD Security:<br />
Only migrated once<br />
Security Profiles migrated regardless of security provider conflicts<br />
(winnt/unix). Can be remapped to other OS security groups post migration<br />
using <strong>DSM</strong> r11 Explorer.<br />
Object ownership only migrated if security providers match (winnt/winnt,<br />
unix/unix, not winnt/unix)<br />
The migration of computer and user data occurs in the following phases:<br />
Computer or User created by migration task and set in state locked by<br />
migration on <strong>DSM</strong> r11 manager to prevent <strong>DSM</strong> r11 manager from setting<br />
up jobs for it<br />
When r11 Agent registers with <strong>DSM</strong> r11 manager the agent version is<br />
updated. Computer or User remains in state locked by migration on <strong>DSM</strong><br />
r11 manager<br />
Next time migration task is run the installation history from the legacy<br />
manager is merged with the existing history in r11 <strong>DSM</strong> Manager and<br />
Computer or User state is unlocked from migration<br />
Management of Agent using r11 manager can begin. At this point you<br />
should STOP managing the agent using legacy manager as no further<br />
migration of job history will be performed!<br />
Detail on how ASM.CNF is migrated into r11 comstore is documented in<br />
Implementation <strong>Guide</strong>. This includes the migration of user data including:<br />
User, Room, Phone and Comment and customized agent name.<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 15
Upgrading from a Previous Release<br />
USD Data Migration Implementation<br />
Migration is invoked by agent installer if selected by user.<br />
Migrated configuration settings are protected by CCNF from override by <strong>DSM</strong><br />
r11 default policy. Only custom policy will override the migrated settings.<br />
On Managers, the library is copied by a migration task - it is NOT automated<br />
on Scalability Servers. You will need to run sd_sscmd import to copy or move<br />
packages from legacy staging servers.<br />
MSILIB is not automatically migrated on Domain Managers and Scalability<br />
Servers. You will need to run sd_sscmd importmsi to copy or move packages<br />
from a legacy local or staging server MSILIB.<br />
In r11 software packages are identified by <strong>DSM</strong> UUID – NOT by their MSI<br />
Product Code.<br />
This appears in MSILIB in folder named with this <strong>DSM</strong> UUID<br />
<strong>DSM</strong> UUID maintained during export and Enterprise to Domain distribution<br />
Important to use the same <strong>DSM</strong> UUID throughout Enterprise and all<br />
Domains to improve roaming source list updates<br />
The new MSILIB share name is “SDMSILIB” and a new MSI dictionary file is<br />
provided to improve roaming source list update. In addition, new MSI<br />
procedure macros replace old macros used to find admin installs in new<br />
locations. The old macros are updated during package import. For more<br />
details, consult the Implementation <strong>Guide</strong>.<br />
The process of migrating USD specific data is as follows:<br />
1. Engine loads the usdLegacy DLL/SLIB<br />
2. usdLegacy DLL/SLIB calls the sdmgrmig executable using instructions it<br />
received from the Engine<br />
3. Sdmgrmig loads usd40sp1 DLL/SLIB to connect to legacy manager<br />
4. Sdmgrmig loads ps DLL/SLIB to connect to r11 database<br />
5. Sdmgrmig loads coApi DLL/SLIB to connect to r11 common manager<br />
6. Migration is done for each selected object class<br />
All tracing goes to TRC_MIGRATION_USD.<br />
7. As with previous installations, all SD events are also logged to the<br />
NT(/CCS) event console.<br />
8. Very limited feedback is written to Engine task portal but you can see if<br />
the task has completed and what the result of the run was.<br />
5–16 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
OSIM Specific Information<br />
Upgrading from a Previous Release<br />
9. Sdmgrmig can be executed from a command line as well. For information<br />
on parameters supported by this command execute it without providing<br />
parameters.<br />
The installer sdcnfmig executable is used for information regarding migration<br />
of the ASM.CNF file. This executable loads rdcnf DLL/SLIB to read local<br />
ASM.CNF and write to the r11 comstore. It can be executed on command line<br />
as well. To view the list of supported parameters execute the command<br />
without providing any parameters.<br />
The following OSIM data is migrated:<br />
OSIM OS images and OSIM Boot images. Default parameters are kept<br />
synchronized.<br />
OSIM Configuration. Current states of OSIM computers are migrated<br />
OSIM Computer Groups<br />
The prerequisites include:<br />
Target computers must be migrated first (run the SD migration job)<br />
OS Images must be migrated manually (see the <strong>DSM</strong> Implementation<br />
<strong>Guide</strong> for a description)<br />
Collect all information to access the SD 4.0 database (including database<br />
type, host, database name, credentials)<br />
OSIM Migration imports data related to Operating System installation<br />
from a SD 4.0 Local Server into r11. This includes parameter values and SD<br />
4.0 OSIM groups.<br />
There are two kinds of parameter sets:<br />
default parameter values of OS images. The parameters of each SD 4.0<br />
OS Image are mirrored to the r11 OS image with the same name.<br />
current parameter values of target computers (taken from the last<br />
successful installation). The current parameters of each SD 4.0 OSIM<br />
computer are mirrored to the r11 computer with the same name.<br />
Log file: TRC_Migration_CSM.log<br />
An r11 group is created for each SD 4.0 OSIM group and an ‘-r4’ suffix is<br />
added to the name of the new r11 groups. Memberships are updated on the<br />
next run.<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 17
Upgrading from a Previous Release<br />
OSIM Data Migration Implementation<br />
OSIM data migration runs as an Engine job and is implemented as a DLL<br />
(ccsmmig.dll) or a UNIX library (libccsmmig.so) depending on the platform.<br />
Unicenter Asset Management Specific Information<br />
The following Asset Management data is migrated:<br />
Computers – including State “Legacy.” Use migration scope to identify<br />
which computers to migrate.<br />
Static Groups (also link members)<br />
Dynamic Groups - depending on which queries are migrated<br />
Computer General Inventory<br />
Computer Software Inventory - depending on which Software Definitions<br />
are migrated<br />
Jobs. Note that these are not linked to groups or assets. Status will not<br />
be migrated.<br />
Templates<br />
Configuration Files<br />
Queries. Although most will be migrated automatically, those that are not<br />
migrated successfully will be flagged.<br />
Query based policies - depending on which queries are migrated<br />
Event Policies<br />
Categories<br />
Publishers<br />
Application Definitions. Note that heuristic applications will not be<br />
migrated.<br />
Only Software Definitions with corresponding software in UAM 4.0 will be<br />
migrated, unless the Software Definitions belong to a Category labeled<br />
'Migration'.<br />
Report templates<br />
Scheduled Reports<br />
Asset Management Specific Data Migration Process<br />
Following is the process by which Asset Management specific data is migrated:<br />
1. <strong>DSM</strong> connects to the Legacy Database<br />
2. Important data is verified and loaded into cache<br />
5–18 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Remote Control Specific Information<br />
3. Each individual configured item is migrated<br />
4. Legacy Database is closed<br />
Upgrading from a Previous Release<br />
The list of legacy objects is maintained in the amlegacy_objects table. This<br />
table maps UAM 4.0 primary key and r11 primary key for each object. Objects<br />
that are mapped will not be migrated again (with the exception of an update of<br />
inventory on Computers).<br />
With the exception of Computers, objects will be mapped to existing r11 object<br />
if the object name matches. Computers are mapped to existing computers if<br />
host_uuid are the same or if host_name is the same.<br />
A computer’s General Inventory and filescan based Software Inventory is<br />
migrated (Software Definitions for these, however, have to be migrated).<br />
To verify migration status, check the TRC_MIGRATION_UAM_0.LOG which is<br />
found in the \<strong>CA</strong>\Unicenter <strong>DSM</strong>\logs directory. This file provides runtime<br />
logging.<br />
The following data is migrated for the Remote Control component:<br />
Computer Groups<br />
Global/Local Address Book Information<br />
Computers. State will be listed as “migrated.” Use migration scope to<br />
identify which computers to include.<br />
Configuration Policy Data<br />
All necessary data for each object type is copied from the Remote Control r6<br />
database to memory and each object is inserted repeatedly. Some object<br />
types are updated if already present depending on responsibility. Inserting<br />
duplicates does not interfere with migration.<br />
Computer -> ca_discovered_hardware(machine), ca_agent( RC status<br />
“Migrated”), ca_group_member(group membership)<br />
ComputerGroup -> ca_group_def(r11 group), ca_agent,<br />
ca_group_member(group membership)<br />
Address book data -> ca_group_def(r11 group), ca_agent,<br />
ca_group_member(group membership), urc_ab_group_member(indicating<br />
address book), urc_ab_computer(with connection addresses),<br />
urc_ab_permission(permissions for address book groups)<br />
You can delete objects in the <strong>DSM</strong> Explorer and migrate again to recreate<br />
them.<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 19
<strong>DSM</strong> and NAT<br />
Remote Control Data Migration<br />
<strong>DSM</strong> and NAT<br />
Overview<br />
Note that configuration policies are not deleted instantly although you cannot<br />
see them in the GUI any longer.<br />
Remote Control r6 address book groups are transformed into standard r11<br />
groups plus some extra address book properties. R6configuration policies are<br />
added to the r11 configuration via CCNF client calls. The sequence of calls is<br />
generated from the r6 data in memory.<br />
To view migration status, check the TRC_MIGRATION_URC_0.LOG file. You<br />
can also check the Engine Status.<br />
Data migration for URC is managed through the rcLegacy.dll and the<br />
rcManagerR11Migration.exe. The Engine calls rcLegacy with the data provided<br />
by the Migration Wizard and rcLegacy builds a command from the data and<br />
executes it.<br />
This command can also be run standalone. For information on the syntax,<br />
execute the following:<br />
rcManagerR11Migration.exe -?<br />
<strong>DSM</strong> r11 can function within a network using Network Address Translation<br />
(NAT) or Port Address Translation (PAT) network but there are some additional<br />
considerations, limitations and configuration requirements that need to be<br />
understood. This section describes some basic testing that was carried out on<br />
a <strong>DSM</strong> r11 deployment within a NAT’d network environment.<br />
Note: No firewalls were in place during testing.<br />
There are different types of NAT:<br />
Static NAT - Maps an unregistered IP address to a registered IP address<br />
on a one-to-one basis.<br />
Dynamic NAT - Maps an unregistered IP address to a registered IP<br />
address from a pool of registered IP addresses.<br />
Overloading – Similar to dynamic NAT, it maps multiple unregistered IP<br />
addresses to a single registered IP address by using different ports. This is<br />
also called PAT (Port Address Translation).<br />
5–20 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
<strong>DSM</strong> and NAT<br />
Typically, NAT routers are used to provide a degree of security and to enable<br />
re-use of IP addresses. In the former case, end systems are hidden behind a<br />
NAT router using either Static or Dynamic NAT. In this way the end system’s<br />
internal, configured IP address is never exposed to systems beyond the router.<br />
In the latter case, PAT or NAT Overloading is used to counter the decreasing<br />
number of available registered IP addresses.<br />
PAT presents the biggest challenges for <strong>DSM</strong> and is, therefore, the focus of the<br />
following tests. PAT essentially stops any direct connections from beyond the<br />
router from reaching systems connected to the local LAN.<br />
<strong>DSM</strong> uses the following two proprietary communications technologies:<br />
<strong>CA</strong>M<br />
TCP Stream via Port Mux (used by DTS, the NOS-less file transfer<br />
component and the RC video stream).<br />
Since <strong>CA</strong>M uses the message’s source IP address to identify an end system<br />
this may cause a problem in an Overloaded NAT network where the source IP<br />
address will always be that of the router. When <strong>CA</strong>M receives a second<br />
connection from the same IP address it discards the first as an apparent<br />
duplicate. Since response messages would not be able to get back to the<br />
system that made the first request this could cause a problem.<br />
With the exception of Asset Management the same behavior was used in the<br />
previous releases. Prior to r11 Asset Management could use file shares as<br />
sectors, or use the AM connectivity server. As a result, users were able to<br />
design different working solutions through these alternate mechanisms in<br />
order to suit their needs and their network configuration. In r11, these<br />
options are replaced by <strong>CA</strong>M.<br />
Fortunately, <strong>CA</strong>M will work when communicating out from a PAT configured<br />
network but only if something else from the same PAT configured network<br />
doesn’t come along in the middle of a message exchange. The effect of this<br />
may be minimal in a normally quiescent network and, even in a <strong>DSM</strong> network<br />
with moderate activity where application code may experience connection<br />
failures or timeouts – though the code should retry and recover. A very active<br />
<strong>CA</strong>M network, however, may be significantly affected.<br />
Scenario 1: Scalability Server as Proxy Router<br />
In this example, the network incorporating a NAT/PAT router was configured<br />
as follows:<br />
A <strong>DSM</strong> Domain Manager was connected to the example Corporate Network<br />
A <strong>DSM</strong> Scalability Server was connected to the NAT router with a static<br />
NAT address appearing as 10.100.1.100 to connections via the WAN and<br />
192.168.2.10 locally.<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 21
<strong>DSM</strong> and NAT<br />
2 <strong>DSM</strong> Agents were connected to the DHCP based, NAT’d (PAT’d) LAN.<br />
In this scenario the Scalability Server is essentially in the DMZ, so that both<br />
the WAN and NAT’d LAN can see it, but with different IP addresses. The <strong>DSM</strong><br />
Agents are hidden from the WAN.<br />
The test network was not connected to the domain network for security<br />
reasons and, as such, a DNS service was not available. To that end etc/hosts<br />
file entries were used for machine naming.<br />
Also NOTE that no firewalls were in place.<br />
5–22 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Problem 1: <strong>CA</strong>M in the DMZ<br />
Solution<br />
<strong>DSM</strong> and NAT<br />
In this scenario the Scalability Server successfully registered with the Domain<br />
Manager and agents successfully connected to the Scalability Server for<br />
registration and inventory upload. However, this information was not collected<br />
by the Engine.<br />
The <strong>DSM</strong> Domain Manager Engine was unable to connect to the DMZ<br />
Scalability Server and “Unable to Open….” Messages were written to the<br />
Engine event log.<br />
From the Manager’s perspective, the Scalability Server is known by its external<br />
address (10.100.1.100) and, therefore, <strong>CA</strong>M messages are directed to this<br />
address. The Scalability Server, however, actually knows itself by its NAT<br />
address (192.168.2.100) and so attempts to forward the messages sent from<br />
the Manager to an address that is unreachable.<br />
<strong>CA</strong>M needs to be configured on the Scalability Server to route messages sent<br />
to its WAN address to itself via a simple cam.cfg rule. Add a ROUTING rule to<br />
the cam.cfg file that directs messages destined for 10.100.1.100 to localhost.<br />
For example:<br />
*ROUTING<br />
forward localhost 10.100.1.100<br />
The Engine can now successfully contact the Scalability Server and the new<br />
computers and their inventory is collected.<br />
With this solution in place the following functionality has been validated as<br />
functioning correctly via limited, ad-hoc testing.<br />
Agent registration<br />
Inventory collection<br />
Common configuration<br />
Asset Jobs<br />
Agent RC Viewer Global Address Book retrieval<br />
Agent RC Host Authentication<br />
Agent RC Viewer to Agent RC Host<br />
Agent RC Viewer to Scalability Server RC Host<br />
Manager RC Viewer to Scalability Server RC Host<br />
Scalability Server RC Viewer to Agent RC Host<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 23
<strong>DSM</strong> and NAT<br />
Problem 2: Infrastructure Deployment<br />
Solution<br />
Problem 3: AM/SD Job Checks<br />
Solution<br />
Note how the latter two entries mean that an RC Viewer running at the<br />
Manager can control an Agent by hopping through a Scalability Server.<br />
Infrastructure Deployment fails to discover the end systems during the scan<br />
phase and, even if it could, file share and telnet access is not possible because<br />
the end systems are hidden from the Manager.<br />
Failure to discover and connect directly to end systems is, as it should be, and,<br />
as such, there is no real solution for the discovery and primer transfer.<br />
However, it is possible to instruct the Deployment Manager to skip the IP ping<br />
that it uses to detect end systems. If the ping is skipped the Deployment<br />
Manager attempts to connect to the dm_primer directly. If the dm_primer is<br />
already installed on the end systems with the appropriate Manager key file<br />
(perhaps via logon script execution of the dm_setup package) and <strong>CA</strong>M traffic<br />
intended for the NAT network is routed through the Scalability Server then<br />
deployment is possible and successful.<br />
Note: This problem also occurred in previous product releases.<br />
The Manager’s instance of <strong>CA</strong>M is configured to route all messages to the<br />
Agent addresses via the Scalability Server as follows<br />
*ROUTING<br />
forward 10.100.1.100 192.168.1.*<br />
This enables <strong>CA</strong>M communications from Manager to end system via Scalability<br />
Server.<br />
An AM/SD job check request from <strong>DSM</strong> Explorer to Agent does not work.<br />
A combination of <strong>CA</strong>M routing rules at the Manager and host file entries solves<br />
this problem. First, hosts file entries for the end systems are added as follows:<br />
agent1 192.168.1.129<br />
agent2 192.168.1.130<br />
5–24 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Recommendation<br />
<strong>DSM</strong> and NAT<br />
This enables the names of the end systems to be resolved to IP addresses.<br />
Next, the Manager’s instance of <strong>CA</strong>M is configured to route all messages to<br />
these addresses via the Scalability Server as follows<br />
*ROUTING<br />
forward 10.100.1.100 192.168.1.*<br />
Scenario 2: Agent as <strong>CA</strong>M Proxy<br />
This enables <strong>CA</strong>M communications from Manager to end system via the<br />
Scalability Server. However, this is not ideal since, in a domain with multiple<br />
NAT’d networks, each private NAT addressing scheme would have to be<br />
different (in other words, the end system’s private IP addresses would have to<br />
be unique within the <strong>DSM</strong> domain). In addition, since a DNS is not used to<br />
resolve the addresses and DHCP is used on the NAT’d networks, agent<br />
addresses might change and become out of sync with the hosts file.<br />
In this case, our recommendation is simply to not run manual, ad hoc job<br />
checks. There should be very little need to do so in a properly configured,<br />
managed enterprise.<br />
In this scenario all <strong>CA</strong>M communications are routed through the <strong>CA</strong>M proxy<br />
using appropriate <strong>CA</strong>M ROUTING rules on the Agents and Scalability Server.<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 25
<strong>DSM</strong> and NAT<br />
Similar to the previous topology, the agent1 machine is placed in the DMZ<br />
and, since it is known by a different IP address externally, a <strong>CA</strong>M ROUTING<br />
rule is required to ensure all traffic sent to its external address is processed<br />
locally.<br />
To do this, add a ROUTING rule to the cam.cfg file that directs messages<br />
destined for 10.100.1.100 to localhost. For example:<br />
*ROUTING<br />
forward localhost 10.100.1.100<br />
In addition, now that agent1 is acting as a <strong>CA</strong>M proxy, <strong>CA</strong>M traffic from the<br />
Scalability Server destined for agent2 must be forwarded to agent1. So the<br />
following routing rule must be added to the Scalability Server:<br />
*ROUTING<br />
5–26 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
forward 10.100.1.100 192.168.1.*<br />
<strong>DSM</strong> and NAT<br />
With this solution in place the following functionality has been validated as<br />
functioning correctly via limited, ad-hoc testing.<br />
Agent registration<br />
Inventory collection<br />
Common configuration<br />
Asset Jobs<br />
SD jobs<br />
SD Catalog<br />
Problem – Infrastructure Deployment<br />
Solution<br />
Agent RC Viewer Global Address Book retrieval<br />
Agent RC Host Authentication<br />
Agent RC Viewer to Agent RC Host<br />
Manager RC Viewer to agent1 RC Host<br />
Scalability Server RC Viewer to agent1 RC Host<br />
Infrastructure Deployment fails to discover agent2 during the scan phase and,<br />
even if it could, file share and telnet access is not possible because the end<br />
system is hidden from the Manager.<br />
Failure to discover and connect directly to end systems is, as it should be, and,<br />
as such, there is no real solution for the discovery and primer transfer.<br />
However, it is possible to instruct the Deployment Manager to skip the IP ping<br />
that it uses to detect end systems. If the ping is skipped the Deployment<br />
Manager attempts to connect to the dm_primer directly. If the dm_primer is<br />
already installed on the end systems with the appropriate Manager key file<br />
(perhaps via logon script execution of the dm_setup package) and <strong>CA</strong>M traffic<br />
intended for the NAT network is routed through agent2 then deployment is<br />
possible.<br />
Note: This was also the case with previous versions of the products.<br />
September 2007 Chapter 5: Installation <strong>Topics</strong> 5- 27
Chapter 6: Startup and Configuration<br />
This chapter takes a closer look at the interaction between components<br />
including:<br />
what happens when <strong>DSM</strong> r11 boots up<br />
infrastructure configuration process<br />
Agent registration process<br />
These topics are also discussed in the following documents:<br />
Implementation <strong>Guide</strong><br />
<strong>DSM</strong> HTML Help Web Services Reference <strong>Guide</strong><br />
You should also consult the following links on the Implementation Best<br />
Practices site for further information:<br />
Working with your CMS Solution<br />
What Happens at Startup?<br />
http://supportconnectw.ca.com/public/impcd/r11/Unicenter/CMS_Frame.h<br />
tm<br />
The following techdocs also provide useful information:<br />
“When installing R11.2 with Common Services how does it handle having<br />
existing versions of NSM components already installed on the server”<br />
(TEC426063)<br />
“Configuration Policy to hide the System tray applet from users<br />
(TEC425430)<br />
“Initialization failed error when the <strong>CA</strong>F command is used at the UNIX<br />
console” (TEC422439)<br />
Keep in mind that additional techdocs may be available after publication of this<br />
document. A full list of techdocs is also available from the following link:<br />
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp<br />
What happens when a machine running <strong>DSM</strong> r11 boots up? To answer this let<br />
us first consider a computer that is running a full <strong>DSM</strong> Domain Manager with<br />
all products (UAM, URC, USD) and components installed (including Scalability<br />
Server, Agent and Web components).<br />
September 2007 Chapter 6: Startup and Configuration 6–1
What Happens at Startup?<br />
Nearly every <strong>DSM</strong> process is controlled via <strong>CA</strong>F. In essence <strong>CA</strong>F starts up and<br />
then starts up all configured plug-ins.<br />
There are a couple of exceptions which are mentioned here for completeness<br />
cfusrntf.exe is invoked transiently whenever a user logs in to a system.<br />
This is used to capture user accounts.<br />
sxplog32.exe is invoked persistently whenever a user logs in to a system.<br />
This is used to apply sxp package settings within a user context i.e. it is<br />
only used when an sxp package is installed. This is started via the registry<br />
key<br />
HKEY_LO<strong>CA</strong>L_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\DsmSxplog<br />
cf_SysTray.exe is invoked persistently whenever a user logs in to a<br />
system. This is used to provide a menu applet within the system tray area<br />
of the desktop. It is started via the registry key:<br />
HKEY_LO<strong>CA</strong>L_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\<strong>CA</strong>F_SystemTr<br />
ay<br />
The following diagram provides an overview of the startup process.<br />
6–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
What Happens at Startup?<br />
<strong>CA</strong>F reaches a steady state with the following threads awaiting stimulus:<br />
Main thread is waiting on Service Control events<br />
ServiceMain thread is waiting within the main <strong>CA</strong>F message processing<br />
loop<br />
Scheduler thread is waiting in timed loop on scheduled events<br />
SM endpoint (U-<strong>CA</strong>F) is waiting on <strong>CA</strong>M messages (with thread pool of 1)<br />
PortMux thread is waiting in timed loop on status change flag and socket<br />
connections<br />
Each instance of cfPlug-in has a thread waiting for messages from the<br />
cfRuntime IPC pipe.<br />
Tip! You can run the following command to query <strong>CA</strong>F for the current status of<br />
all plug-ins.<br />
caf status<br />
The output should look something like this…<br />
Querying caf for status information...<br />
Unicenter <strong>DSM</strong> r11 Common Application Framework 11.0.8024.234<br />
Showing running <strong>DSM</strong> services...<br />
[1] Asset Management manager (ammanager)<br />
[2] Asset Management performance agent (ampmagent)<br />
[3] Asset Management server (amrss)<br />
[4] Asset Management usage server (amms)<br />
[5] Certificate exchange plug-in (cfcertex)<br />
[6] Common Server (cserver)<br />
[7] Common object manager (cmobjectmanager)<br />
[8] Configuration agent (ccnfagent)<br />
[9] Configuration and State Management agent (ccsmagt)<br />
[10] Configuration and State Management agent controller (ccsmact)<br />
[11] Configuration and State Management database api server (ccsmapi)<br />
[12] Configuration and State Management server (ccsmsvr)<br />
[13] <strong>DSM</strong> Service Locator plug-in (cfsvclocator)<br />
[14] Data Transport network object server (dtsnos)<br />
[15] Data Transport schedule object server (dtssos)<br />
[16] Data Transport transfer agent (dtsagent)<br />
[17] Data Transport transfer object server (dtstos)<br />
[18] Deployment Manager (dmdeploy)<br />
[19] Engine (SystemEngine)<br />
[20] Event notification plug-in (cfnotify)<br />
[21] File transfer server (cfftplug-in)<br />
[22] Notification Server (cfnotsrvd)<br />
[23] Port multiplexer (pmux)<br />
[24] Registration plug-in (cfregister)<br />
September 2007 Chapter 6: Startup and Configuration 6- 3
What Happens at Startup?<br />
Startup Under Windows<br />
[25] Remote Control host agent (rchost)<br />
[26] Remote Control manager (rcmanager)<br />
[27] Remote Control server (rcserver)<br />
[28] Session messaging server (smserver)<br />
[29] Software Delivery Boot Server (sdmpcserver)<br />
[30] Software Delivery manager: api server (sdmgr_api_2)<br />
[31] Software Delivery manager: dialog manager (sdmgr_dm)<br />
[32] Software Delivery manager: file transfer (sdmgr_ft)<br />
[33] Software Delivery manager: installation manager (sdmgr_im)<br />
[34] Software Delivery manager: task manager (sdmgr_tm)<br />
[35] Software Delivery server (sdserver)<br />
[36] tomcat server (tomcat)<br />
Note that the list of plug-ins is sorted alphabetically – not in the order in<br />
which they are started.<br />
On the Windows platform the following specific actions occur at startup:<br />
1. Session messaging plug-in starts<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\bin\cfsmsmd.exe -t<br />
2. <strong>CA</strong>F’s own session messaging end point U-<strong>CA</strong>F is set up<br />
3. Common config agent plug-in (ccnfagent) starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\ccnfagent.exe<br />
These three actions always occur first and are, essentially, hardcoded. The<br />
following actions occur based on configuration within comstore.<br />
1. Tomcat starts up<br />
2. Infrastructure Deployment Manager (DMDeploy) starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\DMDeploy.exe start<br />
3. Boot Server starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\sdmpcworker.exe<br />
4. CSM Server starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\ccsmsvrd.exe<br />
5. CSM Agent Controller starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\ccsmactd.exe<br />
6. CSM API Server starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\ccsmapid.exe<br />
7. Notification server starts up<br />
6–4 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\cfnotsrvd.exe<br />
8. CSM Agent starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\ccsmagtd.exe<br />
9. Port Multiplexer starts up<br />
10. Software Usage Server starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\amms.exe<br />
11. Sector Server (amrss.exe) starts up<br />
12. Common Server starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\cserver.exe start<br />
13. RC Host starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\rcHost.exe start<br />
14. RC Server starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\rcServer.exe<br />
15. RC Manager starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\rcManSrv.exe<br />
16. DTS Agent starts up<br />
C:\Program Files\<strong>CA</strong>\SharedComponents\DTS\bin\tngdta.exe<br />
17. DTS TOS starts up<br />
What Happens at Startup?<br />
C:\Program Files\<strong>CA</strong>\SharedComponents\DTS\bin\tngdttos.exe<br />
18. DTS NOS starts up<br />
C:\Program Files\<strong>CA</strong>\SharedComponents\DTS\bin\tngdtnos.exe<br />
19. DTS SOS starts up<br />
C:\Program Files\<strong>CA</strong>\SharedComponents\DTS\bin\tngdtsos.exe<br />
20. System Performance Agent starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\PMAgent\capmuamagt.exe debug<br />
21. Certificate Exchange plug-in starts up<br />
SM end point = U-CFCERTEX<br />
22. SD Installation Manager (sd_taskm.exe im) starts up<br />
23. SD Task Manager (sd_taskm.exe tm) starts up<br />
24. SD Dialog Manager (sd_dialog_m.exe /L) starts up<br />
25. Common File Transfer plug-in starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\cfftplug-in.exe)<br />
26. SD Manager file transfer (sd_mgr_ft.exe) starts up<br />
September 2007 Chapter 6: Startup and Configuration 6- 5
What Happens at Startup?<br />
Startup under Linux<br />
27. SD Scalability Server plug-in starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\sd_server.exe<br />
28. Common Object Manager starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\cmObjectManager.exe<br />
29. AM Object Manager starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\amObjectManager.exe<br />
30. Engine starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\cmEngine.exe<br />
31. <strong>CA</strong>F event notifier (cfnotify) starts up using SM end point = CFNOTIFY<br />
32. Common registration plug-in (cfregister) starts up using SM end point =<br />
<strong>CA</strong>ITRMAGENT<br />
33. <strong>CA</strong>F service locator (cfsvlocator) starts up<br />
34. Scheduler is enabled<br />
35. Register job is executed<br />
36. Begin waiting for <strong>CA</strong>F messages<br />
37. AM Agent starts up<br />
C:\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Bin\amagentsvc.exe UNIT=<br />
38. SD Agent (sd_jexec.exe UNIT=.AfterReboot) starts up<br />
Following is what happens during startup of cmObjectManager under Linux:<br />
1. If Windows, init COM<br />
2. Configuration information is read<br />
3. SM end point (registering callback function) opened<br />
4. OS Event created for shutdown<br />
5. <strong>CA</strong>F notified that it is ready<br />
6. Wait for shutdown event.<br />
When a shutdown event is received, the cmObjectManager does the following:<br />
1. Stops processing messages<br />
2. Enters an infinite loop waiting for all open threads to finish<br />
3. When all open threads have finished cmObjectManager exits<br />
6–6 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Following is what happens during startup of common server:<br />
1. Init common components<br />
2. Parse command line<br />
3. Load config<br />
4. Register with <strong>CA</strong>F<br />
5. Register Server with Manager<br />
Then, it reaches steady state with the following:<br />
1. Main thread waiting on m_trigger_event<br />
2. Notifier thread waiting on m_notify_event<br />
3. CFRuntime thread waiting on IPC <strong>CA</strong>F messages<br />
4. SM endpoint waiting on SM messages (with thread pool of 1)<br />
What Happens at Startup?<br />
By Default, the common server is actually single threaded in terms of<br />
processing workload but that configuration can be increased to use SM thread<br />
pool.<br />
Following are the key startup activities (in order) when the Engine starts up:<br />
1. Command line args parsed<br />
2. Connect to <strong>CA</strong>F<br />
3. Configuration read<br />
4. One (1) second delayed loop entered - checking for work every 20<br />
seconds.<br />
Then, it reaches steady state with the following:<br />
1. Main Thread in 1 second timed loop<br />
2. Thread waiting on <strong>CA</strong>F pipe<br />
Engine tasks may include the following:<br />
Sector collect<br />
Query Evaluation<br />
SQL Script Execute<br />
Reporter job<br />
Legacy Sync (migration)<br />
Replication<br />
External Exe<br />
Domain Dynamic Groups Evaluation<br />
Domain Policy Evaluation<br />
September 2007 Chapter 6: Startup and Configuration 6- 7
Infrastructure Configuration<br />
Infrastructure Configuration<br />
Configuration Policy<br />
Activating Computer Configuration<br />
The Unicenter <strong>DSM</strong> products are configured centrally and locally through a<br />
shared component typically referred to as “common config” or “CCNF”. This<br />
components acts like an “enhanced Windows registry.” It manages the<br />
runtime configuration of practically all of the <strong>DSM</strong> subcomponents and<br />
infrastructure features, though there are some exceptions.<br />
In order to simplify administration of configuration parameters, you can group<br />
a collection of those parameters into a single configuration policy. Therefore,<br />
instead of assigning single parameters to computers or groups, configuration<br />
policies are assigned. Configuration policy can be assigned to multiple<br />
computers or groups. From the administrator’s point of view, configuration<br />
policies are created and maintained independently of any specific computer or<br />
group.<br />
There may be some overlap in the parameters defined in configuration policies<br />
– one parameter could be defined in more than one configuration policy<br />
destined for the same end system. Since only a unique parameter value can<br />
be set on a computer, the following rules are used to determine how to<br />
proceed when configuration policies overlap:<br />
Policies assigned to a group are inherited by the children of the group. A<br />
child can be a group or computer.<br />
In a hierarchy, policies assigned on the child level override the ones on the<br />
parent level. In other words, all parameters defined on the parent level are<br />
also defined for the child, however, when a child policy overlaps with a<br />
parent policy, the child policy ‘wins’.<br />
In all other cases where overlapping policies present a conflict the user will<br />
be prompted to resolve the conflict.<br />
When the time comes for a computer configuration job to be activated the<br />
manager collects the parameters that need to be sent down to the computer.<br />
The configuration job sent down to the target computer will only contain the<br />
parameters that have changed since the last time the configuration was sent<br />
down.<br />
6–8 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Reported Configuration<br />
Configuration Properties<br />
Infrastructure Configuration<br />
The agent reports parameter settings to the manager. On the manager, these<br />
settings are stored in the database where they are referred to by the GUI as<br />
the ‘reported configuration’. A full report of all parameters is returned after the<br />
very first configuration job has been applied. Subsequent reports only contain<br />
deltas.<br />
Configuration properties can be:<br />
Centrally managed<br />
Configuration properties are set up through the <strong>DSM</strong> Explorer and stored<br />
in the MDB. They are then evaluated and transmitted down to end<br />
systems via the CCNF and CSM (Configuration and State Management)<br />
sub-systems.<br />
Locally managed<br />
Here, although the MDB contains entries for the configuration properties<br />
the values are set and stored locally.<br />
Locally unmanaged<br />
This state can be set and reset only locally via the ccnfAgentApi. In other<br />
words, locally unmanaged parameters can be set to “centrally managed”<br />
by the local end system. This essentially puts the manageability of these<br />
parameters under end-system control.<br />
These “managed” properties are collected together hierarchically under a<br />
configuration policy. Configuration policies can be viewed and manipulated<br />
within the <strong>DSM</strong> Explorer under /Control Panel/Configuration/Configuration<br />
Policy.<br />
Tip: When viewing “managed” properties within the <strong>DSM</strong> Explorer by<br />
default you will see their display names. To view their “real” internal<br />
names right clicking on the list view column header and select the display<br />
“internal names” option.<br />
Unmanaged<br />
Configuration properties exist only on the end systems. These properties<br />
typically contain values that are specific to and only useful to the<br />
processes that execute on the managed computer.<br />
September 2007 Chapter 6: Startup and Configuration 6- 9
Infrastructure Configuration<br />
Enterprise and Domain Policies<br />
Property Storage<br />
In the MDB<br />
On the End System<br />
On the Enterprise, the following rules apply to policies:<br />
Enterprise policies are replicated to Domains<br />
Enterprise group configuration jobs are replicated to Domains<br />
Enterprise policies can only be applied to groups<br />
On the Domain, the following rules apply to policies:<br />
Enterprise default policy replaces Domain default policy<br />
Policies can be applied to group OR to individual assets.<br />
Reported configuration is only available at the Domain level<br />
Property storage (also known as “persistence”) is maintained in different<br />
locations – in the MDB and on the end system itself.<br />
Centrally managed properties and their values, as well as locally managed<br />
property definitions (without values), are stored in the following MDB tables<br />
csm_property<br />
csm_object<br />
csm_class<br />
csm_link<br />
Important Note: These tables are also used for storage of OSIM data since<br />
CCNF and OSIM both utilize CSM.<br />
The configuration manager processes the configuration policies applied to a<br />
specific computer as well as policies applied to any groups that the computer<br />
belongs to. It will eventually work out which properties should be set to what<br />
value and then pushes these property values down to the end system.<br />
The configuration settings for an end system ultimately end up in an encrypted<br />
XML file. If you want to know what property values are really being used by<br />
<strong>DSM</strong> on a particular machine, this is the place to look.<br />
6–10 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Infrastructure Configuration<br />
Configuration is stored locally in comstore.enc and userstore.enc on each<br />
node. This replaces pre-r11 mechanisms such as ASM.CNF, TNGDTS.INI, and<br />
Registry. comstore.enc is stored in \Agent\CCNF while<br />
userstore.enc is stored in \\Agent\CCNF.<br />
Both comstore.enc and userstore.enc are encrypted to avoid direct<br />
manipulation.<br />
In addition the file can be decrypted and written to a standard XML format file<br />
using the following command.<br />
ccnfcmda –cmd GetConfigStore –fi c:\MyComStore.xml<br />
Below is some example content. It shows some nested parameter sections e.g.<br />
“itrm/usd/shared”, as well as a parameter “nos” and it’s value “MS”.<br />
A managed parameter is indicated by an entity value of “Manager.” For<br />
example:<br />
When the attribute “write” is set to agent this means the local end system may<br />
update the parameter value. For example:<br />
September 2007 Chapter 6: Startup and Configuration 6- 11
Infrastructure Configuration<br />
Here you can see an example of a migrated parameter:<br />
Here is an example of locally unmanaged parameters:<br />
Here is an example of an unmanaged parameter:<br />
Extending the Configuration Policy<br />
Additional parameters can be added to the <strong>DSM</strong> CCNF by doing the following:<br />
1. Create an XML file containing the following definitions:<br />
Parameter name<br />
Location within the hierarchical structure of configuration parameters<br />
Information about how to edit the parameter regarding type, range,<br />
description<br />
Default value<br />
2. Register parameter to the database.<br />
For example, to add the parameter “processreportstime” first create an XML<br />
(for example “addparam.xml”) and populate it with the following XML<br />
definition:<br />
6–12 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Infrastructure Configuration<br />
Then register the new parameter by executing the following command on the<br />
Manager machine:<br />
ccnfregdb.exe –mlocalhost –fC:\addparam.xml<br />
September 2007 Chapter 6: Startup and Configuration 6- 13
Infrastructure Configuration<br />
Processes and Log Files<br />
The following diagram illustrates the various modules and their interaction:<br />
The CcnfAgentApi can work in “direct access mode” and in “message mode”.<br />
Direct access mode is used when the ccnfAgent is not running (such as<br />
during setup and <strong>CA</strong>F startup). In direct access mode ccnfAgentApi reads<br />
directly from and writes directly to the comstore.enc and userstore.enc files.<br />
Message mode is used when the ccnfAgent is running. In message mode the<br />
ccnfAgentApi communicates with the ccnfAgent via cfMessenger to access<br />
configuration data.<br />
The CcnfAgentApi can switch modes as appropriate, such as when the<br />
ccnfAgent starts up, terminates or when the underlying messaging component<br />
goes down.<br />
The CSM Agent calls ccnfcsmplug-in.dll to process configuration jobs from the<br />
manager.<br />
Configuration data is set using the ccnfAgentApi.<br />
6–14 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Agent Registration<br />
Agent Registration<br />
All <strong>CA</strong>F plug-ins and worker processes are notified about the configuration<br />
changes using the internal <strong>CA</strong>F notification mechanism.<br />
CCNF Agent keeps track of any configuration changes in the common store.<br />
The list of parameters to be reported is kept in the following file:<br />
/Agent/CCNF/paramlist.xml.<br />
This list is initially sent by the manager and will be updated when the<br />
DefaultPolicy has been updated.<br />
Ccnfcsmplug-in.dll is triggered by CSM Agent on a regular basis to check for<br />
delta reports. It requests a delta report from CCNF Agent and forwards the<br />
parameters according to the template list via CSM Agent.<br />
CSM Agent calls ccnfcsmplug-in.dll if a report request arrives from the<br />
manager. Ccnfcsmplug-in.dll requests the full report from the CCNF Agent and<br />
forwards the data according to the template list via CSM Agent to the<br />
manager.<br />
When a <strong>DSM</strong> agent is installed on an end system the first thing it does is<br />
attempt to register its existence with the Domain Manager via its Scalability<br />
Server. This registration process is common across all products and includes a<br />
limited amount of inventory information (known as “Basic Inventory” or<br />
sometimes “Basic Hardware Inventory”). Note that agents register on a<br />
regular basis but basic inventory information is delta’d after the first<br />
registration.<br />
September 2007 Chapter 6: Startup and Configuration 6- 15
Agent Registration<br />
Domain Manager<br />
Engine [cmEngine.exe]<br />
Common Server – [cserver.exe]<br />
Scalability Server<br />
Agent<br />
<strong>CA</strong>F – [caf.exe]<br />
CF Register – [cfRegister.dll]<br />
Session Messaging<br />
Create Process<br />
Basic Inv Collector – [cfbasichwwnt.exe]<br />
trace<br />
trace<br />
trace<br />
trace<br />
TRC_CMENGINE_0.log<br />
am.log<br />
TRC_CF_DMDEPLOY_0.log<br />
TRC_CF_<strong>CA</strong>F_SERVICE_0.log<br />
TRC_CF_REGISTER_0.log<br />
6–16 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Chapter 7: Software Scanning<br />
This chapter provides a closer look at the Asset Management software<br />
scanning process including:<br />
General flow<br />
Overview and Flow<br />
Processes and log files<br />
Content download process<br />
XML generation process<br />
Transfers from Engine to Scalability Server and from Scalability Server to<br />
agent<br />
Enterprise Manager considerations<br />
Import\Export utility<br />
Diagnosis Tips<br />
For additional information you should consult the following sources:<br />
<strong>DSM</strong> HTML Help Web Services Reference <strong>Guide</strong><br />
Inside Asset Management <strong>Guide</strong><br />
Unicenter Desktop and Server Management Diagnostics <strong>Guide</strong><br />
A full list of techdocs is also available from the following link:<br />
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp<br />
<strong>DSM</strong> r11 has fully incorporated the eVM signature scanner technology which<br />
supports the download of a signature database from the online <strong>CA</strong> Content<br />
Management System. This information is stored within the MDB, converted to<br />
an XML file and transmitted down to the <strong>DSM</strong> agent for use by the software<br />
detection component.<br />
The key difference between this technique and the technique employed in the<br />
previous Asset Management release is that the signatures are available to the<br />
agent, and it is the agent that does the software detection. Previously, a list of<br />
file information was returned to the manager and the analysis took place<br />
there. Shifting the task to the agents helps reduce the load on the manager<br />
system.<br />
September 2007 Chapter 7: Software Scanning 7–1
Overview and Flow<br />
The following diagram illustrates the various modules and their interaction:<br />
7–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Processes and Log files<br />
Processes and Log files<br />
The software scanning function uses the following processes and log files:<br />
September 2007 Chapter 7: Software Scanning 7- 3
Processes and Log files<br />
The Content Management System (CMS) is a central repository hosted by <strong>CA</strong><br />
and available via the public internet. CMS contains information about all<br />
known software, including patch and fix recognition information (signatures).<br />
A Closer Look at the Content Download Process<br />
The Content Downloader is a Java program that is kicked off by the <strong>DSM</strong><br />
Engine on a scheduled basis. This program, ImportClient.jar, can be found in<br />
the following locations:<br />
On Windows: \Program Files\Unicenter <strong>DSM</strong>\bin\upm<br />
On Linux: /opt/<strong>CA</strong>/Unicenter<strong>DSM</strong>/Engine/bin/upm<br />
It writes to the following log file:<br />
On Windows: Unicenter <strong>DSM</strong>\bin\upm.log<br />
On Linux: /opt/<strong>CA</strong>/Unicenter<strong>DSM</strong>/Engine/bin/upm/UPM.log<br />
Tip: The location and format of the log file does not conform to <strong>DSM</strong><br />
standards. If the downloader fails for any reason it will be indicated in the<br />
upm.log file. To check connectivity look for "Contacting ACME Server<br />
(contentupdate.ca.com)" messages.<br />
The Content Downloader reads settings from the following configuration file:<br />
Unicenter <strong>DSM</strong>\bin\upm\config.properties<br />
This file contains information about which database to publish, proxy-server,<br />
username and password. Passwords are encrypted and proxy server<br />
information is actually read by the Engine from published configuration policy<br />
settings and written to the config.properties file.<br />
When the Content Downloader connects to the Content Management System,<br />
it downloads new signatures and publishes them to the MDB. Tables affected<br />
by the updates to the MDB can include the following:<br />
ca_software_def<br />
ca_company<br />
ca_company_type<br />
ca_country<br />
ca_dir_schema_map<br />
ca_download_file<br />
ca_install_package<br />
ca_install_step<br />
ca_language<br />
7–4 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
ca_location<br />
chip_set<br />
ca_software_signature<br />
ca_category_def<br />
ca_category_member<br />
ca_link_sw_def<br />
ca_class_def<br />
ca_class_hierarchy<br />
ca_source_type<br />
ca_software_type<br />
ca_link_type<br />
ca_software_def_types<br />
ca_software_def_class_def_matrix<br />
Processes and Log files<br />
The Content Management System and downloader use a message numbering<br />
system to ensure that only changes are downloaded. For each object type the<br />
downloader asks the content server if any messages above a particular<br />
message number (“X”) are available. The value of “X” for each object type is<br />
stored in the ca_acme_checkpoint MDB table.<br />
A Closer Look at the XML Generation Process<br />
Whenever changes are made to the ca_software_signature MDB table (via<br />
Content Downloader, <strong>DSM</strong> Explorer, or some other mechanism) a trigger is<br />
executed which updates a record indicating that changes have occurred.<br />
"select set_val_lng from ca_settings where set_id=4" will indicate (=1) if the<br />
version has changed for Windows<br />
"select set_val_lng from ca_settings where set_id=5" will indicate (=1) if the<br />
version has changed for UNIX<br />
"select set_val_lng from ca_settings where set_id=6" will give you the version<br />
number for Windows<br />
"select set_val_lng from ca_settings where set_id=7" will give you the version<br />
number for UNIX<br />
When the Engine contacts a Scalability Server with the intention of updating<br />
signatures it does the following for both Windows and Linux signatures:<br />
September 2007 Chapter 7: Software Scanning 7- 5
Processes and Log files<br />
Checks if the “version has changed” flag is set (see above). If it is, the<br />
version number is incremented by one and the "version has changed” flag<br />
is reset.<br />
Compares the MDB contents version number with the latest version<br />
number that the Engine has. This is extracted from the file names of the<br />
existing signature files.<br />
For Windows signatures, the file name is “Wnnnnnnn.XML” and for UNIX<br />
signatures the file name is “Ummmmmmm.XML” where nnnnnnn and<br />
mmmmmmm designate the version. For example, “W0000006.XML” is<br />
version 6 of Windows while “U0000005.XML” is version 5 for UNIX.<br />
If the MDB version is higher than what the Engine has, the Engine<br />
generates a new XML file and puts this into the following locations:<br />
– For Windows: \Documents and Settings\All Users\Application<br />
Data\<strong>CA</strong>\eso_fingerprints<br />
– For UNIX\Linux: /var/eso_fingerprints<br />
A Closer Look at the Engine Transfer Process<br />
Next, the Engine checks to see if the Scalability Server has the latest<br />
signatures (in comparison to the ones most recently generated by the Engine).<br />
If not, it sends them down to the Scalability Server. The signatures are<br />
compressed during the transfer process in order to keep network load down.<br />
The Scalability Server stores the updated, compressed signature files in the<br />
following locations:<br />
For Windows:<br />
\Program Files\<strong>CA</strong>\Unicenter<br />
<strong>DSM</strong>\ServerDB\SECTOR\SSFW\Wnnnnnnn.ZML<br />
\Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\ServerDB\SECTOR\SSFU\Lnnnnnnn.ZML<br />
For UNIX\Linux:<br />
/opt/<strong>CA</strong>/Unicenter<strong>DSM</strong>/Server/serverdb/SECTOR/SSFW/Wnnnnnnn.ZML<br />
/opt/<strong>CA</strong>/Unicenter<strong>DSM</strong>/Server/serverdb/SECTOR/SSFL /Lnnnnnnn.ZML<br />
A Closer Look at the Scalability Server Transfer Process<br />
The XML documents are used by the software detector module that runs on<br />
the end system and they are downloaded by the <strong>DSM</strong> Agent from the<br />
Scalability Server if appropriate.<br />
7–6 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Processes and Log files<br />
The <strong>DSM</strong> Agent launches the Asset Management agent plug-in (amagents.exe<br />
for Windows and amagent for Linux) which, assuming software detection is<br />
configured to run at that time, first contacts the <strong>DSM</strong> Scalability Server to get<br />
the latest XML Signature file.<br />
The first time the <strong>DSM</strong> Agent pulls the signature database file from the server<br />
it will also retrieve the revision number. The second and subsequent times that<br />
the agent requests the signatures it passes the current revision number to the<br />
Scalability Server and will only get a new signature database if there is a new<br />
revision.<br />
After transfer, the file is stored (uncompressed) locally on the following<br />
locations of the end system’s hard drive:<br />
On Windows: \Program Files\<strong>CA</strong>\Unicenter<br />
<strong>DSM</strong>\agent\units\00000001\uam\Wnnnnnnn.XML<br />
On UNIX\Linux:<br />
/opt/<strong>CA</strong>/Unicenter<strong>DSM</strong>/Agent/AM/data/work/lnnnnnnn.xml<br />
The software detector is launched via amosoftscan.exe (Windows) or<br />
amosoftscan (Linux) and writes to the TRC_UAM_0.log file. The scan applies<br />
any signature file differences provided by the agent in order to get a complete<br />
and up-to-date signature file.<br />
Note: The signature scanner itself does not produce a log file; however, it<br />
does create a results file in the following locations:<br />
On Windows: \Program Files\<strong>CA</strong>\Unicenter<br />
<strong>DSM</strong>\agent\units\00000001\uam\bak\amsoft.xml<br />
On UNIX\Linux:<br />
/opt/<strong>CA</strong>/Unicenter<strong>DSM</strong>/Agent/AM/data/work/BAK/amosoft.xml<br />
This creates a file containing the differences between the new scan result and<br />
the previous one. On UNIX\Linux, it is stored in the following location:<br />
/opt/<strong>CA</strong>/Unicenter<strong>DSM</strong>/Agent/AM/data/work/amosoft.dat<br />
The agent plug-in then takes this results file and sends it to the Scalability<br />
Server.<br />
Tip: To run the signature scanner manually use the following syntax on<br />
Windows:<br />
amswsigscan <br />
On UNIX\Linux, use the following syntax:<br />
camevmscli <br />
September 2007 Chapter 7: Software Scanning 7- 7
Processes and Log files<br />
In both cases the would typically be the XML file located in<br />
the working directory and the results file will be the XML file containing the<br />
result of the scan.<br />
The results file is sent to the Scalability Server in the same way as any other<br />
hardware or software inventory file and it ends up in the following folder:<br />
On Windows: \Program Files\<strong>CA</strong>\Unicenter <strong>DSM</strong>\Server<br />
DB\SECTOR\COLLECT\00000001<br />
On UNIX\Linux:<br />
/opt/<strong>CA</strong>/Unicenter<strong>DSM</strong>/Server/serverdb/SECTOR/COLLECT/00000001<br />
The naming convention for the file is:<br />
HOST_UUID.Wnn<br />
Using an Enterprise Server<br />
The <strong>DSM</strong> Engine later collects the file and populates the MDB appropriately.<br />
It should be noted that only custom software signatures defined at an<br />
Enterprise Manager are replicated down to Domains. However, all discovered<br />
software is replicated up to the Enterprise Manager from the Domain<br />
Managers.<br />
A Closer Look at the Import\Export Utility<br />
The Import\Export utility, which is available in r11.2, is a command line tool<br />
configured through an XML file that provides the ability to share software<br />
definitions between <strong>DSM</strong> Domains that are offline. This supports custom<br />
created software definitions and <strong>CA</strong> provided software definitions as well.<br />
The utility uses BULK functionality and requires installation of the Microsoft<br />
SQL Client. For more information see the Inside Asset Management <strong>Guide</strong>.<br />
The Import\Export utility is executed through the following syntax:<br />
Run \bin\Contentutility.exe<br />
This creates a content_utility.xml file which MUST be modified prior to<br />
performing the actual import\export. Following is an example of this file:<br />
7–8 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Here you can see the process running:<br />
The following log files are written to the \bin directory:<br />
ContentUtility.log<br />
Contentutility_%hostname%.log<br />
Processes and Log files<br />
By default, contents files are located in Windows application data folder under<br />
\ca\software_definitions:<br />
September 2007 Chapter 7: Software Scanning 7- 9
Diagnosis Tips<br />
Diagnosis Tips<br />
If you run into problems running a software scan, check to see that the latest<br />
XML file for the Engine is valid. To do this load the XML file with an XML viewer<br />
(for example, a web browser). If it contains errors (wrong XML) then delete all<br />
XML files in that directory. They will be automatically regenerated by the<br />
Engine.<br />
If the signature file gets corrupted at the agent level the scan will most likely<br />
not produce any results. A simple way to check the file integrity is to load it in<br />
a web browser. If the browser complains about the syntax then it is likely that<br />
the scanner will too.<br />
The software signature scanner can be run manually with the -DEBUG switch<br />
to reveal further information about what's going wrong.<br />
7–10 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Chapter 8: Remote Control Connection<br />
This chapter provides a closer look at the Remote Control connection<br />
including:<br />
General flow<br />
Overview and Flow<br />
Processes and log files<br />
Getting the authority list<br />
Connection to the desktop<br />
Displaying confirmation dialogs<br />
Starting remote control<br />
Security components<br />
RC messenger<br />
Diagnosis tips<br />
For additional information you should consult the following sources:<br />
<strong>DSM</strong> HTML Help Web Services Reference <strong>Guide</strong><br />
Inside Remote Control <strong>Guide</strong><br />
Unicenter Desktop and Server Management Diagnostics <strong>Guide</strong><br />
The following techdocs can also provide useful information:<br />
“How to Centralize Security in URC r11” (TEC401138)<br />
“Why does my 3D Application/DVD Player display as a black window on the<br />
URC Viewer?” (FAQ314784)<br />
“Can I use Unified Login to establish a connection via Unicenter Remote<br />
Control Viewer or the Desktop and Server Management Explorer to a<br />
remote host with all security providers?” (FAQ394668)<br />
A full list of techdocs is also available from the following link:<br />
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp<br />
The Remote Control function essentially allows a user of a Windows computer<br />
to access a remote Windows or Linux computer as if they were sitting in front<br />
of the physical machine. All keyboard and mouse input is relayed to the<br />
remote computer.<br />
September 2007 Chapter 8: Remote Control Connection 8–1
Overview and Flow<br />
In a managed environment Remote Control Viewers and Hosts communicate<br />
with <strong>DSM</strong> Scalability Servers and Managers in order to retrieve address book<br />
information, validate/authenticate users and retrieve permissions for valid<br />
users. The process flow is as follows:<br />
1. Obtain Connection Information<br />
Global Address Book<br />
Local Address Book<br />
Quick Connect<br />
2. Obtain Authority List<br />
This is not required for “Local” security mode and the User doesn’t have to<br />
do this explicitly.<br />
3. Validate Credentials via:<br />
Locally Managed Security<br />
Centralized Security<br />
Security Cache/Fail-Safe<br />
4. Connect to Target Desktop (control User Input)<br />
5. Prompt User to Display/Connect to Host GUI<br />
6. Start Remote Control Session and load video capture<br />
8–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Processes and Log files<br />
TRC_URC_HOST<br />
GUI_n.log<br />
Host GUI<br />
(cfSysTray.exe)<br />
Capture Helper<br />
(rcUtilCmd.exe)<br />
TRC_URC_UTILCMD_<br />
n.log<br />
Processes and Log files<br />
The remote control connection function utilizes the following processes and log<br />
files:<br />
TRC_URC_HOST_n.log TRC_URC_VIEWER_n.log<br />
Host<br />
(rcHost.exe)<br />
RC Server<br />
(rcServer.exe)<br />
TRC_URC_SERVER_n<br />
.log<br />
Getting the Address Book<br />
SM<br />
Registration+<br />
authentication<br />
TCP<br />
RC<br />
Session<br />
SM Host Commands<br />
SM<br />
Registration +<br />
Authentication<br />
Viewer<br />
(EGC30n.exe+<br />
Gui_rcView.dll)<br />
SM<br />
Address books<br />
RC Manager<br />
(rcManSrv.exe)<br />
TRC_URC_MANSRV_<br />
n.log<br />
When the Remote Control Viewer connects to the <strong>DSM</strong> Manager and requests<br />
up-to-date address book information R<strong>CA</strong>ddressBookManager compiles the<br />
address book according to validated user’s permissions.<br />
September 2007 Chapter 8: Remote Control Connection 8- 3<br />
SQL
Getting the Authority List<br />
Getting the Authority List<br />
Depending on which manager hierarchy is in place, the Global Address Book<br />
that is returned may be either a Domain Address Book or an Enterprise<br />
Address Book.<br />
The following MDB Tables are used to store address book information:<br />
urc_ab_computer – Computers in the address books<br />
urc_ab_group_def – In which groups computers/groups appear<br />
urc_ab_groups_member – In which groups computers/groups appear<br />
urc_ab_permission – User permissions applied to a group<br />
RCMgrAddressBook caches the information locally on the Viewer where it is<br />
only used if the manager connection fails.<br />
The following process is used to obtain the Authority List:<br />
1. Viewer establishes connection to Host and sends M_STATUSQUERY<br />
2. For Centralized Security the following occurs:<br />
RC Messenger sends request to RC Server (or Manager)<br />
RC Server forwards request to RC Manager<br />
Manager returns authority list and authentication scheme list from CCL<br />
security<br />
Host caches the list<br />
3. Host sends M_STATUSREPLY to Viewer containing results<br />
8–4 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Here you can see a graphical depiction of the process:<br />
Getting the Authority List<br />
September 2007 Chapter 8: Remote Control Connection 8- 5
Getting the Authority List<br />
Centralized User Validation<br />
As you can see in the following graphic, a series of communications occur<br />
across the Viewer, Host and Managers during centralized user validation:<br />
8–6 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Cached\Fail Safe Validation<br />
Connecting to the Desktop<br />
Connecting to the Desktop<br />
Following is a graphical depiction of cached\fail safe validation authentication<br />
process:<br />
In this method there is no communication to the Domain Manager.<br />
Terminal Services allows several users to log onto a machine at the same<br />
time. XP Fast User Switching is a specialized case of this multi-login capability.<br />
On Windows NT4 and earlier there is effectively only one Terminal Services<br />
session. On Linux each local X Server (in X terminology it is the X Server that<br />
is responsible for rendering a desktop) is treated as a Terminal Services<br />
session.<br />
Each RC Session (CRCSession object) is associated with a CRCTerminal object.<br />
The CRCTerminal object represents the Terminal Services session to which the<br />
RC Control session is connected. Currently, RC can only control the “Console”<br />
TS session - the session currently connected to be controlled by the remote<br />
machine’s local keyboard, mouse and display. However, RC Sessions can<br />
switch between TS sessions if the console switches.<br />
September 2007 Chapter 8: Remote Control Connection 8- 7
Connecting to the Desktop<br />
Terminal Services Obstacles<br />
On Windows, a process can only interact with the desktop of a Terminal<br />
Services session if it is running in that session. On Linux, the processes that<br />
use the XLib API can be terminated by the API unexpectedly.<br />
It is the RC Host that interacts with the desktop when simulating user input.<br />
The CRCInput object of rcOS.dll implements this functionality in the following<br />
manner:<br />
If direct access to the target TS session is not possible, a CRCInputProxy<br />
object is created by CRCTerminal::GetInput.<br />
CRCInputProxy::Init uses ICFOSTerminalServices::CreateProcessInSession to<br />
spawn a privileged instance of rcUtilCmd.exe in the target session.<br />
Note: Prior to Windows Vista, a winlogon notification DLL, rcLoginExt.dll is<br />
sometimes required.<br />
8–8 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Connecting to the Desktop<br />
rcUtilCmd creates a CRCInputClient object, which opens an IPC pipe to the<br />
parent process. CRCInputProxy serializes the API calls made through IRCInput,<br />
and sends them via IPC to the Input Client. The Input client reads messages<br />
from a thread, CRCInputClient::ProcessPipeMessages and calls into a real<br />
CRCInput instance, returning the results through the IPC channel.<br />
The RCInput API is synchronous. API calls which have a return value block<br />
until the results are returned. To the Host, CRCInputProxy behaves exactly like<br />
CRCInput<br />
The rcHost.exe service process cannot display user interfaces directly, this is<br />
primarily due to security concerns running as the System user and Fast User<br />
Switching/Vista Compatibility.<br />
rcHost controls the RCHostGUI component in another worker process.<br />
Normally RCHostGUI runs inside <strong>CA</strong>F’s system tray process (cfSysTray.exe)<br />
though it can be launched inside a dedicated rcUtilCmd process if cfSysTray is<br />
not available.<br />
September 2007 Chapter 8: Remote Control Connection 8- 9
Displaying Confirmation Dialogs<br />
rcHost controls the Host GUI through the IRCHostGUI interface while<br />
CRCHostGUI provides the actual implementation of the GUI, including the<br />
system tray menus.<br />
CRCHostGUIProxy implements the IRCHostGUI interface, transparently<br />
proxying all calls to the CRCHostGUI object in the GUI worker process.<br />
CRCHostGUIStub reads messages from the GUI Proxy, and converts them into<br />
calls into CRCHostGUI<br />
CRCGUIPipe implements the IPC between the proxy and the Stub<br />
The Chat GUI shares the RC GUI pipe connection with the system tray if<br />
available. Otherwise, a dedicated rcUtilCmd.exe process hosts the chat GUI<br />
for each Terminal Services session<br />
Displaying Confirmation Dialogs<br />
Starting Remote Control<br />
Each CRCTerminalObject controls the Host GUI for that TS session.<br />
CRCTerminal objects are created on-demand. The Host GUIs run<br />
independently, and listen for connections on their IPC GUI Pipes<br />
CRCSession::GetConfirmation() checks to see if end-user confirmation is<br />
required. If no one is logged on, the “override confirm at login” policy is used<br />
to determine what to do. If confirmation is required, a<br />
WAITFORCONFIRMATION message is sent to the viewer, to update the UI.<br />
The IRCHostGUI::ShowConfirmDialog function is called to prompt the user.<br />
The result from the dialog is sent as a WM_ENDDIALOG message via the<br />
Host’s internal message loop, and processed in CRCSession::ProcessMessage.<br />
If all is successful, CRCSession::AcceptLogin is called, which sends an<br />
M_CONNACC message to the Viewer.<br />
Once the login is complete, the Viewer sends M_CONNACC,<br />
VIEWER_PROTOCOLS and VIEWER_FONT_<strong>CA</strong>CHE messages to the Host. When<br />
received, the host calls CRCSession::StartViewing, from the main host thread.<br />
The video capture components for the target TS session are managed by a<br />
CRCDisplay object owned by the CRCTerminal. The CRCDisplay object<br />
maintains a list of “Graphics Targets”, which includes RC Sessions, per-session<br />
host side recordings and manual recording sessions.<br />
8–10 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
RCConfig and RCTrace<br />
Diagnosis Tips<br />
Diagnosis Tips<br />
The CRCDisplay object owns the RCVideoCapture & RCGraphics components.<br />
RCConfig emulates the old IRCConfig interface. It sits on top of <strong>DSM</strong>’s<br />
common configuration (i.e., comstore) and converts IRCConfig interface calls<br />
to CCNF Agent API.<br />
RC Config Keys are <strong>DSM</strong> Paramsections<br />
RC Config Values are <strong>DSM</strong> Parameters<br />
RC Config Settings are <strong>DSM</strong> attributes within a Parameter<br />
RCTrace emulates the old IRCTrace interface. It sits on top of <strong>DSM</strong>’s common<br />
tracing (i.e., cftrace) but it does not trace line numbers or source files. New RC<br />
code will use CCL tracer directly.<br />
The video capture threads process an incredible throughput of packets. There<br />
is no tracing during normal operation of the video capture after start up.<br />
Beware of threads when analysing the Server or Manager logs. There can be<br />
several worker threads servicing different requests concurrently. Use a log<br />
analyser to filter out irrelevant execution paths.<br />
The tracing from the RC Viewer GUI can be spread across a number of trace<br />
files. Some of the common components are shared between the different GUI<br />
plug-ins, so the trace from these components will appear in the wrong place.<br />
Use a log analyzer to combine the log output, and then filter.<br />
CCNF, RC Messenger and Session Messaging produce a lot of tracing so filter it<br />
using a log analyser. The following trace files are available:<br />
TRC_URC_HOST_n.log – rcHost process logs<br />
TRC_URC_HOSTGUI_n.log – Host GUI logs, from system tray<br />
TRC_URC_UTILCMD_n.log – rcUtilCmd worker logs<br />
TRC_URC_VIEWER_n.log – RC Viewer GUI log<br />
TRC_URC_WRAPPER_n.log, TRC_URC_REPLAYER_n.log – Viewer trace<br />
from CCL may appear here<br />
TRC_URC_SERVER_n.log – Server logs, very heavily laden with noise<br />
TRC_URC_MANSRV_n.log – Manager logs<br />
September 2007 Chapter 8: Remote Control Connection 8- 11
Chapter 9: Delivering Software<br />
This chapter provides a closer look at the software delivery process including:<br />
General flow<br />
USD Shares<br />
USD Directory structure<br />
Key USD files<br />
Key USD MDB tables<br />
OS processes, names, aliases and trace files for USD and DTS<br />
Process flow and log files for USD and DTS<br />
<strong>DSM</strong>info Collection <strong>Guide</strong><br />
Troubleshooting tips<br />
Additional DTS Considerations<br />
For additional information you should consult the following sources:<br />
Inside Software Delivery <strong>Guide</strong><br />
<strong>DSM</strong> HTML Help Web Services Reference <strong>Guide</strong><br />
Unicenter Desktop and Server Management Diagnostics <strong>Guide</strong><br />
The following techdocs provide useful information regarding Software Delivery:<br />
“Creating a package to run Applyptf” (TEC401118)<br />
“Controlling the content of a catalog based on the Active Directory (AD)<br />
organizational unit (OU) of a computer or user profile” (TEC424335)<br />
“How to cancel a Software Delivery job that is scheduled for a later date”<br />
(TEC426102)<br />
“Registering an MSI Install procedure via the command line” (TEC419921)<br />
A full list of techdocs is also available from the following link:<br />
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp<br />
September 2007 Chapter 9: Delivering Software 9–1
Overview and Flow<br />
Overview and Flow<br />
Following is a graphical overview of the Software Delivery architecture:<br />
Common Stack<br />
MDB File System File System File System<br />
TASKMAN INSTMAN SDSERVER<br />
APISRV DIALOGM<br />
MGRFT (not EM)<br />
DTSFT<br />
WAC<br />
WS<br />
Manager Scalability Server Agent<br />
SDDTAFLT<br />
SDDTPUSH<br />
EXPLORER<br />
<strong>CA</strong><strong>DSM</strong>CMD<br />
SDDTAFLT<br />
SDSSCMD<br />
Software Delivery processing can be broken down as follows:<br />
1. The software package is created.<br />
SDJEXEC<br />
SDMSIEXE<br />
SDPILOT<br />
SDDTAFLT<br />
<strong>CA</strong>TALOG<br />
SDACMD<br />
The package must include an installation procedure. The package may<br />
optionally include configuration, activation and uninstallation procedures.<br />
2. The software package is registered in the Software Delivery Library.<br />
Depending on administration requirements this may occur at the<br />
Enterprise Manager or Domain Manager.<br />
3. The package is distributed to target computers.<br />
This can be either at the request of the administrator (push) or, if catalogs<br />
are used, at the request of the target user (pull).<br />
9–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
4. The package installer is executed<br />
Overview and Flow<br />
This occurs after the package has been successfully delivered directly to<br />
the end system or to an accessible network share the package’s installer is<br />
executed.<br />
5. The status of the package delivery/installation is reported back to<br />
the originating manager at various stages throughout the process.<br />
One of the first steps in troubleshooting is to determine at which point in this<br />
process the problem occurred. For example, the failure of a software package<br />
to install on a target may be the result of a faulty package creation, an<br />
improper library registration, a communication failure between components<br />
during package transfer, or a resource/environmental deficiency on the part of<br />
the target system.<br />
The following graphics are provided to give you a better understanding of the<br />
communications that occur between each of the Software Delivery<br />
components.<br />
First is the relationship between the UI and the Manager:<br />
September 2007 Chapter 9: Delivering Software 9- 3
Overview and Flow<br />
Next is the relationship between the Enterprise and Domain Manager:<br />
Here you can see the Domain Manager to Domain Manager<br />
communication:<br />
9–4 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Following demonstrates the distribution of Jobs to Agents:<br />
Here is what it looks like when DTS is used:<br />
Here is what it looks like when using NOS or NOS-less delivery:<br />
Overview and Flow<br />
September 2007 Chapter 9: Delivering Software 9- 5
Overview and Flow<br />
When DTS is used, activation occurs as follows:<br />
9–6 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Following depicts the effect when NOS is used:<br />
Following depicts the effect when NOS-less delivery is used:<br />
Overview and Flow<br />
September 2007 Chapter 9: Delivering Software 9- 7
Overview and Flow<br />
Here you can see the response:<br />
The following graphic demonstrates the distribution of orders between the<br />
Domain Manager and Scalability Server:<br />
9–8 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
DTS Integration<br />
Overview and Flow<br />
The following demonstrates the relationship between the Scalability Server<br />
and Agents:<br />
Here you can see how the process changes when DTS is used:<br />
September 2007 Chapter 9: Delivering Software 9- 9
Overview and Flow<br />
This impacts the relationship between the Enterprise and Domain Manager as<br />
follows:<br />
Here you can see the relationship between the DTS Domain Manager and<br />
Scalability Server:<br />
9–10 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
USD Shares<br />
The following graphic depicts the relationship between the DTS Domain<br />
Manager, Scalability Server and Agent:<br />
The following shares are used by the Software Delivery component:<br />
\\\SDLIBRARY$<br />
\\\SDMSILIB<br />
USD Shares<br />
SDLIBRARY$ share is used by SDJEXEC to identify the location for NOS-based<br />
library access by agents. It uses the following configuration parameters:<br />
Itrm/usd/shared/sdlib – specifies share name<br />
Itrm/usd/shared/exportarchive – specifies full UNC<br />
The SDMSILIB share is used by SDMSIEXE (via SDJEXEC) to identify the<br />
location for NOS-based access to MSI administrative installations by agents. It<br />
uses the following configuration parameters:<br />
Itrm/usd/shared/msilib – specifies share name<br />
Itrm/usd/shared/msiadminpathunc – specifies full UNC<br />
September 2007 Chapter 9: Delivering Software 9- 11
USD Directories<br />
USD Directories<br />
The following directories are used by the Software Delivery components:<br />
Library Used By Used For Configuration<br />
Parameters<br />
\SD\ASM\LIBRARY APISRV (EM + DM)<br />
TASKMAN (EM +<br />
DM)<br />
SDSERVER<br />
SDSSCMD<br />
SDDTAFLT<br />
\SD\ASM\MSILIB SDSSCMD<br />
SDMSIEXE (via<br />
SDJEXEC)<br />
\SD\ASM\D TASKMAN (EM+DM)<br />
SDSERVER<br />
SDDTAFLT<br />
\SD\ASM\TMP<br />
\FLTSTAGE<br />
\SD\ASM\LIBRARY<br />
\ACTIVATE<br />
SDJEXEC<br />
SDDTAFLT<br />
TASKMAN (DM)<br />
SDSERVER<br />
SDJEXEC (via share)<br />
\SD\ASM\DATABASE TASKMAN (DM)<br />
SDSERVER<br />
\SD\ASM\CONF SDJEXEC<br />
SDMGRMIG<br />
Permanent location for<br />
software packages<br />
MSI administrative<br />
software pckgs<br />
Incoming and outgoing<br />
DTS transfers<br />
Incoming DTS transfers<br />
Temporary location for<br />
s/w pckgs for NOSbased<br />
job execution.<br />
Uses junction<br />
points/symbolic links<br />
into \SD\ASM\LIBRARY<br />
when possible.<br />
Temporary location for<br />
zipped s/w pckgs for<br />
NOS-less based job<br />
execution<br />
Non-MDB computer info,<br />
DTS control files, and<br />
host identity and<br />
notification data<br />
MSI detection file,<br />
migration MSI map file,<br />
agent state file and<br />
text-file based agent<br />
customization data<br />
Itrm/usd/shared/archive<br />
Itrm/usd/shared/msiadminp<br />
ath<br />
Itrm/usd/shared/incoming<br />
Itrm/usd/shared/outgoing<br />
Itrm/usd/shared/asmtemp<br />
(+”/activate’”)<br />
Itrm/usd/shared/database<br />
9–12 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Library Used By Used For Configuration<br />
Parameters<br />
\SD\ASM\DEVICE SDPILOT Integration DLL for Palm<br />
Pilots, and other devicespecific<br />
data<br />
\SD\TMP SDJEXEC<br />
SDMGRMIG<br />
\SD\IPC SDJEXEC<br />
SDACMD<br />
\SD\NLS Nearly all SD<br />
programs<br />
Temporary files<br />
Signaling to agent from<br />
install programs<br />
Stores localized SD<br />
resources<br />
\SD\AUTOREG TASKMAN <strong>DSM</strong> s/w pckgs are<br />
located here by the <strong>DSM</strong><br />
installer and imported to<br />
the MDB and SW library<br />
at first <strong>CA</strong>F start of the<br />
SD manager<br />
\SD\Legacy Administrator Contains USD 4.0 API<br />
install image. Prereq.<br />
For SDMGRMIG if API<br />
connection to USD 4.0<br />
Local/Enterprise Server<br />
is to be successful.<br />
Only needed if no cohosting<br />
exists<br />
\ServerDB\SWJORDER SDSERVER Temporary location for<br />
s/w job orders and<br />
results and s/w<br />
detection records. Also<br />
location for serverspecific<br />
agent identity<br />
data<br />
\Agent\units\\u<br />
sd<br />
SDJEXEC Temp location for s/w<br />
job orders, results and<br />
s/w detection records.<br />
Also each can<br />
represent a computer,<br />
user profile or docking<br />
device<br />
USD Directories<br />
Itrm/scalability_server/serv<br />
erdb_path (+”/swjorder”)<br />
September 2007 Chapter 9: Delivering Software 9- 13
USD Files<br />
USD Files<br />
The following files are used by Software Delivery:<br />
\ServerDB\SWJORDER\\appl.apc<br />
Used by SDSERVER to queue Software Job orders for agents with<br />
HOSTUUID.<br />
\ServerDB\SWJORDER\cachedagdata.xml<br />
Used by SDSERVER for Job results which have not been sent to the<br />
manager yet. Also used in stage check mode.<br />
\SD\ASM\DATABSE\hostcert.dat<br />
Used by SDGENERAL.DLL/SO (SDSERVER, TASKMAN, INSTMAN) for<br />
storage of public host certificates of remote hosts. Also used for fallback<br />
when the remote host is not online when an encrypted S&F message is to<br />
be sent to that host.<br />
\SD\ASM\DATABSE\imnothand.xml<br />
Used by INSTMAN for notification events not yet handled by IM during<br />
shutdown are stored in this file. On startup these notification events will be<br />
loaded and handled before any queued notification events.<br />
\SD\ASM\DATABSE\compdata\.ini<br />
Used by INSTMAN to store information about the agent’s previous domain<br />
manager.<br />
\SD\ASM\DATABASE\compjobs\.tss<br />
Used by TASKMAN to store information about ongoing DTS transfers<br />
between DM and SS. Also used to avoid transferring the same package in<br />
parallel.<br />
\SD\ASM\DATABASE\compjobs\.job/dtp/dts etc<br />
Used by TASKMAN, DTSFT to exchange transfer information between<br />
TASKMAN and DTSFT. Note, no more job specific info here as the USD4.0<br />
FileDB has been removed.<br />
\Agent\units\\usd\sdjexec\.cof/cwf/<br />
crf<br />
Used by SDJEXEC to keep the state of job containers. The extensions are<br />
as follows:<br />
*.cof = not started<br />
*.cwf = working<br />
*.crf = completed<br />
9–14 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
MDB Tables<br />
The Software Delivery function uses the following MDB tables:<br />
Table Used for<br />
MDB Tables<br />
Usd_swfold Software group, procedure group, catalog<br />
group (DM only)<br />
Usd_job_cont Software job container, software policy<br />
Usd_activity Software job, software policy job<br />
Usd_rsw Software package<br />
Usd_actproc Software procedure<br />
Usd_applic Application (DM only)<br />
Ca_group_def Asset group<br />
Usd_v_target Asset<br />
Usd_v_ownsite(EM)<br />
Usd_v_csite (DM)<br />
Usd_v_ownsite (DM)<br />
Usd_v_ls (EM)<br />
Enterprise Manager<br />
Domain Manager<br />
Usd_cont (+usd_cc, usd_carrier) Distribution container<br />
Usd_order (+usd_distsw,<br />
usd_distap, usd_disttempl,<br />
usd_fio,usd_fitem)<br />
Distribution order<br />
In addition, other supplementary tables, prefixed by usd_* are used.<br />
September 2007 Chapter 9: Delivering Software 9- 15
Process, Trace and Log Files<br />
Process, Trace and Log Files<br />
Process (EXE)<br />
Name<br />
The following process and log files are used at the Manager Level:<br />
<strong>CA</strong>F Name Logical Name Description Trace File<br />
Sd_taskm Sdmgr_tm Task Manager Main job evaluation<br />
Engine<br />
Sd_taskm Sdmgr_im Installation Mgr. Job results collecting<br />
Engine<br />
Sd_mgr_ft Sdmgr_ft File Tranfer mgr. File transfer Engine<br />
(enterprise r11.2)<br />
Sd_dtsft n/a DTS Integration Legacy file transfer<br />
Engine (removed in<br />
r11.2)<br />
Trc_usd_taskm_x.log<br />
Trc_usd_instman_x.log<br />
Trc_usd_sdmgrft_x.log<br />
Trc_usd_dtsft_x.log<br />
Sd_dtpush n/a DTS integration Legacy file transfer<br />
Engine (not in r11.2)<br />
Trc_usd_sddtpush_x.log<br />
Sd_apisrv Sdmgr_api_# API server Client counterpart<br />
used by UI to<br />
perform USD specific<br />
operations<br />
TRC_usd_apiserver_x.log<br />
Sd_dialog_m Sd_mgr_dm Dialog Mgr Client counterpart<br />
used by UI to obtain<br />
free sd_apisrv.<br />
Essentially, a<br />
dispatcher<br />
Sd_ahdcmd n/a Service Desk<br />
Integration<br />
Used for integration<br />
with Unicenter<br />
Service Desk<br />
Trc_usd_dialogm_x.log<br />
Trc_usd_sdahdcmd_x.log<br />
9–16 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Process (EXE)<br />
Name<br />
Process, Trace and Log Files<br />
The following table depicts the details for the <strong>DSM</strong> Explorer and Scalability<br />
Server components:<br />
<strong>CA</strong>F Name Logical Name Description Trace File<br />
Egc30N n/a SD Explorer UI Trc_GUI_x.log<br />
Sd_registerproduct n/a SW Package<br />
registrator<br />
Sd_server Sdserver SD Scalability<br />
Server Plug-in<br />
Process (EXE)<br />
Name<br />
Registers SXP, PIF,<br />
PKG and RPM<br />
packages. Called by<br />
<strong>DSM</strong> Explorer<br />
Handles all software<br />
jobs<br />
Trc_usd_sdserver_x.log<br />
The following table depicts the details for the DTS – on the Agent Tier:<br />
<strong>CA</strong>F Name Logical Name Description Trace File<br />
Tngdta dtsagent DTS Transfer<br />
Agent<br />
Tngdoba DTS Browser DTS Object<br />
Browser<br />
(Master) Persistent<br />
DTS agent plug-in<br />
that receives<br />
commands from TOS<br />
and DTS Initiator<br />
agent.<br />
(Slave) Launched by<br />
master to perform<br />
data transfer and<br />
send status to TOS<br />
Trc_dtsagent_x.log<br />
Not used by USD Trc_dtsbrowser_x.log<br />
Dtsitrm.dll TCP Protocol wrapper<br />
using <strong>DSM</strong> Networker<br />
Dtstcp11.dll TCP protocol wrapper<br />
September 2007 Chapter 9: Delivering Software 9- 17
Install Packages and Trace Files<br />
Process (EXE)<br />
Name<br />
The following depicts the details for DTS on the Manager tier:<br />
<strong>CA</strong>F Name Logical Name Description Trace File<br />
Tngdtos Dtstos DTS Transfer<br />
Object Server<br />
Tngdtsnos Dtsnos DTS Network<br />
Object Server<br />
Main DTS data<br />
transfer Engine.<br />
Responsible for all<br />
managed transfers<br />
(Not req. in r11.1).<br />
Calculates the best<br />
transfer route<br />
according to CCS<br />
WV.<br />
Tngdt.dll n/a DTA API Main API used to<br />
communicate with<br />
DTS (USD, DTS<br />
CLI,etc)<br />
Tngdtsos dtssos DTS Scheduler<br />
Object Server<br />
Install Packages and Trace Files<br />
Trc_dtstos_x.log<br />
Trc_dtsnos_x.log<br />
TRC_DTS_x.log<br />
Enables scheduling of Trc_dtssos_x.log<br />
transfer activations<br />
(not used by USD)s<br />
Following is a list of install packages and trace files for Windows installs:<br />
S/W Pckg AfterCopy <strong>DSM</strong> Install Trace Installer Trace<br />
Manager.msi SDMgrAfterCopy TRC_inst_ITRM_x.log <strong>DSM</strong>SetupManager.log<br />
Manager.msi DtsManagersAfterCopy +<br />
DtsCommonAfterCopy<br />
TRC_Inst_ITRM_x.log <strong>DSM</strong>SetupManager.log<br />
Server.msi SDSvrAfterCopy TRC_Inst_ITRM_x.log <strong>DSM</strong>SetupScalability<br />
Server.log<br />
AgtSD.msi SDAgAfterCopy TRC_Inst_ITRM_x.log <strong>DSM</strong>SetupAgentSD.log<br />
AgtDTS.msi DtsAgentAfterCopy +<br />
DtsCommonAfterCopy<br />
Explorer.msi n/a TRC_Inst_iTRM_x.log <strong>DSM</strong>SetupExplorer.log<br />
9–18 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Following is the corresponding list for Linux installs:<br />
USD Logical Process Flows and Log Files<br />
S/W Pckg AfterCopy <strong>DSM</strong> Install Trace Installer Trace<br />
Ca-dsm-sdmanager.Linux.@pif <br />
Ca-dsm-sdserver.Linux.@pif <br />
Ca-dsm-sdagent.Linux.@pif <br />
Ca-dsm-dtsagent.Linux.@pif<br />
SDMgrAfterCopy TRC_*_x.log Ca-dsm.*.log<br />
SDSvrAfterCopy TRC_*_x.log Ca-dsm.*.log<br />
SDAgtAfterCopy TRC_*_x.log Ca-dsm.*.log<br />
DtswAgentAfterCopy +<br />
DtsCommonAfterCopy<br />
TRC_*_x.log Ca-dsm.*.log<br />
If the installer is driven by the Install Shield master setup (in other words, it is<br />
running from the DVD) all installation trace files will end up in the %TEMP%<br />
directory of the user that initiated the install. On Linux, the interactive install<br />
will generate trace files in the /tmp directory.<br />
If, on the other hand, the installer is driven by an SD Job all <strong>DSM</strong> install trace<br />
files will end up in the system %TEMP% and /tmp directories. The Installer<br />
trace will be appended as output to the SD job and reported up to the<br />
manager. There it can be viewed (and copied) using the <strong>DSM</strong> Explorer by<br />
navigating to the failed leaf computer job node and opening its properties and<br />
choosing the Output tab.<br />
USD Logical Process Flows and Log Files<br />
The following graphics depict the relationship between USD logical processes<br />
and the log files that are generated. The first graphic applies to the r11.1<br />
release:<br />
September 2007 Chapter 9: Delivering Software 9- 19
USD Logical Process Flows and Log Files<br />
9–20 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Following is the corresponding information for r11.2:<br />
USD Logical Process Flows and Log Files<br />
September 2007 Chapter 9: Delivering Software 9- 21
Major Changes between 11.1 and 11.2<br />
Following is the logical process flow and trace files for DTS:<br />
Major Changes between 11.1 and 11.2<br />
Several changes were introduced in the r11.2 update, the most major of which<br />
include the following:<br />
<strong>CA</strong> Common Services (CCS) is bundled with <strong>DSM</strong> 11.2 which means DTS<br />
configuration can be done via WorldView and Calendar and Event<br />
functionality is re-enabled for both DTS and USD.<br />
The functionality of Sd_dtsft(.exe) and sd_dtpush(.exe) have been moved<br />
to sd_mgr_ft(.exe) for performance reasons.<br />
9–22 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Collecting Information for Troubleshooting<br />
Sd_gapi(.dll/.so) has been renamed to sd_api(.dll/.so) for binary<br />
backwards compatibility reasons.<br />
Collecting Information for Troubleshooting<br />
The “dsminfo” tool should be used to collect information for those machines<br />
that show problems. If reproduction is required make sure to enable large<br />
trace files by issuing the following command:<br />
Cftrace –c set –f USD –l DETAIL –s 300000<br />
Cftrace –c set –f DTS –l DETAIL –s 300000<br />
The –s parameter indicates “size” and specifying a size value of 300000 makes<br />
sure traces are not overwritten. After the problem has been successfully<br />
reproduced do not forget to change the trace level back to its previous level.<br />
This can be done by issuing the following command:<br />
Cftrace –c set –f USD –l ERROR–s 2000<br />
Cftrace –c set –f DTS –l ERROR–s 2000<br />
Even though a failure may appear to only involve a single host most of the<br />
time it involves multiple hosts in a distributed environment. Therefore<br />
“dsminfo” should be collected from all machines that are involved. For<br />
example, if a job fails to execute on an agent, you should always collect the<br />
“dsminfo” from the appropriate Manager and Scalability Server in addition to<br />
the affected agent.<br />
The USD and DTS audit messages are via the Event Logger; for 11.1 this<br />
means that these messages end up in the Windows Application event log and<br />
for 11.2 they will end up either in the Windows Application event log or the<br />
CCS Event console.<br />
For a list of common troubleshooting tips consult the <strong>DSM</strong> Diagnostics <strong>Guide</strong>.<br />
Additional DTS Considerations<br />
Be aware that CCS integration is not provided in <strong>DSM</strong> r11.0 and r11.1. This<br />
means that if DTS 3.0 (USD 4.0) has been configured with WorldView to use<br />
DTS Routing information then this information will not be available when<br />
upgrading to <strong>DSM</strong> r11.0 and r11.1.<br />
All DTS versions prior to r11 are upgraded to DTS r11 when <strong>DSM</strong> r11 is<br />
installed; DTS does not co-exist with its earlier releases. In this respect DTS is<br />
backwards compatible with all earlier DTS versions.<br />
September 2007 Chapter 9: Delivering Software 9- 23
Additional DTS Considerations<br />
Due to an issue in the upgrade process, when DTS is upgraded to r11 it will<br />
continue to use its legacy TCP protocol instead of the r11 Networker (port<br />
multiplexer component). Whilst transfers will continue to be successful, in<br />
environments where firewalls have a limited number of ports opened DTS<br />
transfers may fail until the DTS legacy TCP ports are opened on the firewall or<br />
until DTS is configured to use the r11 Networker component.<br />
9–24 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Chapter 10: OSIM<br />
OSIM Architecture<br />
This chapter takes a closer look at OSIM and includes:<br />
Architectural and OSIM component overview<br />
Process and Log file information<br />
Process flow<br />
Installation and configuration<br />
Boot server behavior<br />
Image Prepare System<br />
Sample flow<br />
Under the hood<br />
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
For additional information you should consult the following sources:<br />
Inside Software Delivery <strong>Guide</strong><br />
<strong>DSM</strong> HTML Help Web Services Reference <strong>Guide</strong><br />
Unicenter Desktop and Server Management Diagnostics <strong>Guide</strong><br />
The following techdocs provide useful information regarding OSIM:<br />
“Corrected instructions for creating a WinPE ISO image for use with OS<br />
Installation Management” (TEC421113)<br />
“How to manually create an entry on the domain for a PXE machine that<br />
has not registered itself yet or how to preregister a PXE machine”<br />
(TEC426115)<br />
“Why installation of a Ghost image on a PXE machine overwrites the disk<br />
partition definition” (TEC413100)<br />
A full list of techdocs is also available from the following link:<br />
http://supportconnectw.ca.com/public/unidsm/infodocs/unidsm-tecdoc.asp<br />
OSIM provides bare metal Operating System (OS) installation on designated<br />
targets in an enterprise network provided those targets are able to boot from<br />
the network.<br />
September 2007 Chapter 10: OSIM 10–1
OSIM Architecture<br />
The OSIM infrastructure consists of the following:<br />
Manager plug-in that controls the installation process<br />
<strong>DSM</strong> Explorer and <strong>DSM</strong> CLI plug-ins<br />
Support for preparation of OS and BOOT images<br />
Tools to setup and configure OS<br />
PXE/TFTP Book Server (a Scalability Server plug-in)<br />
Here you can see how OSIM components fit into the <strong>DSM</strong> architecture:<br />
Following is a more detailed graphic depicting the relationship between OSIM<br />
components:<br />
10–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
<strong>DSM</strong> Explorer <strong>CA</strong><strong>DSM</strong>CMD<br />
OSIM queries OSIM plugin<br />
<strong>DSM</strong><br />
MDB<br />
OS installation jobs<br />
with boot parameter.<br />
State of Jobs, Boot<br />
Server and Image<br />
OSIM Boot Server<br />
plug-in<br />
<strong>DSM</strong> Domain Manager<br />
OSIM Manager plug-in<br />
(CSM)<br />
Install boot and OS<br />
images in the<br />
image store of<br />
remote Boot<br />
Server<br />
Boot and OS Image<br />
Store + FCOR<br />
Store info<br />
about Boot<br />
and OS<br />
images<br />
OSIM Architecture<br />
OSIM extensions<br />
SD SW library<br />
SD pkg of Boot and OS<br />
image<br />
Register Boot<br />
and OS images<br />
as SD package<br />
Scalability Server <strong>DSM</strong> Packaging Tools<br />
PXE Data and Boot<br />
parameter<br />
Load Boot, OS<br />
Image<br />
PXE Target<br />
Computer<br />
Here you can see:<br />
IPS can share<br />
image store with<br />
Boot Server<br />
DOS boot<br />
diskette and<br />
original OS<br />
CD<br />
OSIM Boot and OS<br />
Image Prepare System<br />
Custom built<br />
WinPE,<br />
including OSIM<br />
files<br />
OSIM Explorer plug-in provides the GUI support for management of<br />
OSIM Computers, Images and Jobs.<br />
OSIM <strong>CA</strong><strong>DSM</strong>CMD extension provides a command line interface offering<br />
the same functionality as the GUI.<br />
OSIM Manager plug-in manages all information about Target<br />
Computers, Boot Servers, OS and Boot Images. This information is stored<br />
in the MDB.<br />
OSIM Boot Server plug-in runs the PXE and TFTP services that reply to<br />
PXE requests from targets and deliver Boot and OS Images respectively.<br />
OSIM Image Prepare System (IPS) provides the functions necessary to<br />
prepare and register OS and Boot Images.<br />
September 2007 Chapter 10: OSIM 10- 3
Process and Log Files<br />
Process and Log Files<br />
The relationship between the OSIM processes and log files is demonstrated by<br />
the following graphic:<br />
There are three steps to performing unattended installation on OSIM targets:<br />
1. Pre-OS installation launched by a Boot Image (mini OS)<br />
For example this may include hard disk partitioning and, in the case of<br />
GHOST images, unpacking the image on the partition.<br />
2. OS setup launched by Boot Image (mini OS)<br />
This is the unattended setup of OS Installation and, in the case of GHOST<br />
images, preparation of mini setup.<br />
3. Post OS installation launched by OS run once<br />
This includes the delivery of the Admin password, domain integration, and<br />
<strong>DSM</strong> agent installation.<br />
Boot parameters control the auto answer files and installation scripts.<br />
Imaging tools can be used for cloning. However, images must be prepared for<br />
unattended mini setup.<br />
10–4 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Installation and Configuration<br />
Note that the Software Delivery Agent is installed automatically. This ensures<br />
that Software Delivery can be use for subsequent installation of additional<br />
<strong>DSM</strong> Agents and applications.<br />
Installation and Configuration<br />
The (CSM-OSIM) Domain Manager plug-in is always installed with the Software<br />
Delivery Domain Manager. It uses the MDB and the communication of the<br />
<strong>DSM</strong> Manager and has no special configurations itself.<br />
The OSIM Boot Server is a <strong>DSM</strong> Scalability Server plug-in that requires the<br />
following configuration:<br />
Enabling support for Windows network shares (default is tftp)<br />
Selecting destination location for the image store<br />
If the path is not during the installation it can be configured later in the local<br />
comstore of the Boot Server with the following command:<br />
ccnfcmda –cmd setparametervalue<br />
–ps /itrm/scalability-server/osim/ManagedPC –pn InstallPath –v <br />
If the Boot Server is configured for share access, on LINUX, the Samba server<br />
has to be installed.<br />
September 2007 Chapter 10: OSIM 10- 5
Installation and Configuration<br />
If you plan to provide LINUX OSIM images from the Boot Server:<br />
On LINUX the NFS server must be active<br />
On Windows UNIX Services for Windows 3.5 or later must be installed<br />
The Boot Server is active and answers to new targets if no other Boot Server<br />
answers. To deactivate and disable the Boot Server process, use the following<br />
commands:<br />
caf stop sdmpcserver<br />
caf disable sdmpcserver<br />
To enable and activate the Boot Server process use the following commands:<br />
caf enable sdmpcserver<br />
caf start sdmpcserver<br />
Multiple Boot Server (BS) in a PXE broadcast network<br />
When there are multiple Boot Servers in a PXE broadcast network, the default<br />
behavior, from the administrator’s view, is that all new targets will be<br />
answered by all Boot Servers. The target picks up the first reply. However, you<br />
should be aware that, if two Boot Servers from two Domain Managers<br />
are in the same PXE broadcast network the following will occur:<br />
If PXE is enabled later on an existing <strong>DSM</strong> target, the OSIM target can be<br />
picked up and reported to the wrong Domain Manager.<br />
If the responsible Boot Server is down the computer will be picked up by<br />
the other Boot Server and can appear in both Domain Managers.<br />
To install an additional Boot Server from the installation media you will need to<br />
install the Scalability Server as well because the Boot Server is part of it.<br />
If the Boot Server system already has a <strong>DSM</strong> Agent installed you can also use<br />
Software Delivery to install the Boot Server by selecting the "<strong>CA</strong> Unicenter<br />
<strong>DSM</strong> Scalability Server" package from the <strong>DSM</strong> Explorer.<br />
Prioritization of Boot Server with Remote Configuration<br />
In a remote configuration, Boot Server prioritization is specified through the<br />
following values:<br />
10–6 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
UseAcle (Use Answer Control List).<br />
Installation and Configuration<br />
This value designates whether or not the Answer Control List (mac.acl) is<br />
used to determine which PXE requests are answered.<br />
– If value is 0 the Boot Server answers all PXE requests immediately.<br />
Note that only one Boot Server may be in the broadcast network).<br />
– If the value is 1 the Boot Server immediately answers PXE requests of<br />
already assigned targets only. See Answer Control List (mac.acl).<br />
PXE requests of other target machines will be answer only after a<br />
certain number of retries (designated by the<br />
DiscoveryRetriesBeforeAnswers setting).<br />
– If the value is 2 the Boot Server immediately answers all PXE requests<br />
of known targets. Requests from unknown targets (i.e., not in<br />
mac.acl) will not be answered.<br />
DiscoveryRetriesBeforeAnswer (Number of discoveries before answer)<br />
This value specifies the number of retries before the Boot Server sends a<br />
default reply to the PXE request of a target not assigned to it.<br />
Meaningful values: “1” to “4” Default value: “3”<br />
This setting is only evaluated if "UseACL" is set to “1”.<br />
DiscoveryTimeoutBeforeAnswer (Time to wait for discovery answer)<br />
This value specifies the number of seconds to wait before a Boot Server<br />
sends a default reply to the PXE request of a target not assigned to it.<br />
Meaningful values: “3” to “56” Default value: “10”<br />
September 2007 Chapter 10: OSIM 10- 7
Image Prepare System (IPS)<br />
Image Prepare System (IPS)<br />
This setting is only evaluated if "UseACL" is set to “1”.<br />
The Image Prepare System (IPS) reads the OS files from the vendor’s media<br />
and combines this with the OSIM files to create OSIM OS images and Boot<br />
Images. Here you can see an architectural overview of the Image Prepare<br />
System (IPS):<br />
Both Boot servers and IPS work with an existing image store, however, IPS<br />
also provides setup scripts, tools and configurations for most Windows and<br />
LINUX unattended set ups.<br />
Note: OSIM OS images can be based on the original setup or, for cloning on<br />
GHOST, PQ images captured from a model computer.<br />
OSIM currently supports the following target operating systems and releases<br />
out of the box:<br />
Win9x, WinNT (DOS boot)<br />
W2K, W2K Server (WinPE or DOS boot)<br />
WXP, Win2003 (WinPE or DOS boot)<br />
GHOST images of W2K, WXP, Win2003 (DOS boot)<br />
10–8 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Example<br />
Create Boot Images<br />
Redhat 9.0, 3.0, 3.04, 4.0-4.03 (DOS + LINUX boot)<br />
Suse 8.2, 9.0 (DOS + LINUX boot)<br />
OSIM does not include any OS files not owned by <strong>CA</strong>.<br />
Example<br />
IPS can be installed from DVD from the Packaging Tools. It is installed with a<br />
Domain Manager, by default, and can only be installed on Windows. IPS setup<br />
is linked with the <strong>DSM</strong> Explorer.<br />
IPS and Boot Server share the same Image Store (path can be set with the<br />
Boot Server setup). If no image store is on the system, IPS commands create<br />
a default.<br />
This example walks through the following steps for using OSIM:<br />
1. Create Boot Images<br />
2. Register Boot Images<br />
3. Create OS Image<br />
4. Register OS Image<br />
5. Prepare the Target for Network Boot<br />
6. Boot the Target<br />
7. Change the Target to Managed<br />
8. Modify Job Parameters<br />
9. Activate the Install Image<br />
10. Boot the Target to Initiate the install<br />
The first step is to create a Boot Image. You can create a DOS Boot Image<br />
from a Win98 Boot Floppy or MSClient (if the image is used for share access).<br />
The MSClient can be obtained from a Windows NT 4 Server CD or from a<br />
Microsoft FTP server.<br />
Another option is to create a WinPE Boot Image. To do this you would start<br />
with prepared WinPE in a directory structure and add the <strong>CA</strong> tools to create an<br />
ISO image.<br />
If you use a WinPE Boot image the BOOTDOS network bootloader is<br />
downloaded from the Boot Server and executed by the PXE BIOS as follows.<br />
September 2007 Chapter 10: OSIM 10- 9
Example<br />
STARTROM loads the WinPE ISO file into a RAMDISK and boots WinPE<br />
from the RAMDISK.<br />
WinPE boots and executes osimrun.cmd.<br />
Depending on "$~method$" it either loads the file in the parameter<br />
"$WinPEFile$ “ or “$WinPETftp$” from the Boot Server “camenu” and<br />
executes it.<br />
The files from "$WinPEFile$“ and “$WinPETftp$” belongs to the OS image<br />
and control the OS installation via share or tftp.<br />
If you use a DOS Boot image, the BOOTDOS network boot loader is<br />
downloaded from the Boot Server and executed by PXE BIOS as follows:<br />
BOOTDOS simulates a RAMDISK and loads the DOS Boot image from Boot<br />
Server into the RAMDISK.<br />
DOS then boots and executes the autoexec.bat.<br />
Depending on the boot parameter "$~method$" (TFTP or SHARE) which is<br />
set by the Boot Server, it starts the MS-Client or uses the BIOS PXE TFTP<br />
for the next file transfers.<br />
Depending on "$~method$" it loads the file "$BatchFile$“ or “$TftpFile$”<br />
from the Boot Server “camenu” and executes it.<br />
The files "$BatchFile$“ and “$TftpFile$” belongs to the OS image and<br />
control the OS installation via share or tftp.<br />
Use the CreateBTImages command to create the necessary Boot Image. You<br />
will need to provide a directory with the WinPE ISO file, and the WinPE<br />
Network boot loader files.<br />
10–10 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
CreateBTImages looks for the Win98SE DOS boot diskette on “A:“ (the A<br />
drive) and does the following:<br />
Example<br />
1. Adds MS-Client from a Windows NT4 Server CD or from a given directory<br />
to A:\net ()<br />
Note: This is the minimal configuration for share access. Without MS-<br />
Client, the image can only be used from Boot Servers using TFTP<br />
download.<br />
2. Adds <strong>CA</strong> tools and files from IPS templates<br />
..\osimips\templates\Dos\net\*.* to A:\net<br />
tftp.exe (tftp download client)<br />
canet,exe (partitioning tool)<br />
ndis.dos (generic network driver using PXE protocol from BIOS)<br />
setopdat.exe (parameter read, substitute)<br />
netstart.bat, protocol.ini, system.ini, wfwsys.cfg, shares.pwl (MSclient<br />
configuration)<br />
3. Adds <strong>CA</strong> autoexec.bat from the following directory:<br />
..\osimips\templates\Dos\AUTOEXEC.BS2 to A:\autoexec.bat<br />
4. Creates osinstal.2 image using copy144.exe<br />
September 2007 Chapter 10: OSIM 10- 11
Example<br />
Register DOS Boot Images<br />
Boot Images are registered through the RegisterBTImages command. Here<br />
you can see the syntax:<br />
In this example the following syntax was used to register DOS Boot images for<br />
both the osinstal.2 and osinstal.3 images to the 677-lab-osim25 <strong>DSM</strong><br />
Manager:<br />
Registerbtimages –i osinstal.2;osinstal.3 –s 677-lab-osim25<br />
10–12 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Create OS Image<br />
Example<br />
OS images are created using the CreateOSImage command. Here you can see<br />
the syntax:<br />
For example:<br />
Createosimage –i myhost2 –o GHOST-XP –s c:\myhost2 –k abcde-12345-abcde-12345abcde<br />
This syntax creates an image called “myhost2” using a Windows XP GHOST<br />
image located on c:\myhost2 drive and directory with a product key of “abcde-<br />
12345-abcde-12345-abcde.”<br />
September 2007 Chapter 10: OSIM 10- 13
Example<br />
Register the OS Image<br />
The OS image is registered using the RegisterOSImage command. The syntax<br />
is provided in the following screen:<br />
For example, the following command:<br />
Registerosimage –i myghost2 –s 677-lab-osim25<br />
registers the myghost2 image to the <strong>DSM</strong> Manager named “677-lab-osim25”.<br />
Here you can see the OS image in the <strong>DSM</strong> explorer:<br />
10–14 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Prepare the Target for Network Boot<br />
Example<br />
To prepare the target machine for network boot you need to enable Network<br />
Startup in BIOS as seen in the following example:<br />
September 2007 Chapter 10: OSIM 10- 15
Example<br />
Boot the Target<br />
The next step is to boot the target in order to have it picked up by the Boot<br />
Server. The target returns the following information:<br />
The MAC address of the target (Client MAC ADDR)<br />
The IP address and network mask the target sent from the DHCP server<br />
The IP address of the DHCP server<br />
The PROXY IP which is the IP address of the selected OSIM Boot Server<br />
The IP address of the default gateway sent from the DHCP server<br />
The message that an OSIM Boot Server was selected (<strong>CA</strong>-Unicenter<br />
ManagedPC Boot Server)<br />
Change Selected PXE Target to Managed<br />
Editing the Job Parameter<br />
To change a PXE target to “managed” once it has been picked up right click on<br />
the target and select Managed(unmanaged) from the menu.<br />
Select the OS Image to install and click OK.<br />
Installation parameters can be edited by selecting the OS Installation<br />
Parameters node as seen in the following example:<br />
10–16 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Activate the OS Installation Job<br />
Example<br />
Here you can see how the OS installation job can be activated based on a set<br />
date and time.<br />
Click OK to set and the target OS installation will start with the next reboot.<br />
Boot the Target to Execute the OS install job<br />
Here you can see that the machine has been rebooted in order to activate and<br />
execute the OS installation job.<br />
September 2007 Chapter 10: OSIM 10- 17
Under the Hood<br />
Under the Hood<br />
Boot Image Tools and Templates<br />
The following topics present a more detailed discussion of various OSIM tasks<br />
and functions.<br />
Following is an example of the DOS\Net template files:<br />
These files are introduced into the DOS boot images through the<br />
CreateBTImages command and can be used to specify the following:<br />
network access<br />
10–18 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
oot parameter<br />
OS image handling<br />
The winpe\ca-osim template files are required to specify the following:<br />
32bit access to the Boot Server<br />
32bit parameter<br />
OS image handling<br />
Under the Hood<br />
The following file structure is used to store DOS and WinPE Boot Images on<br />
Image Prepare System and Boot Server<br />
ManagePC\<br />
images\<br />
dosboot\ Boot disk operating system image store<br />
bootdos DOS network boot loader<br />
boothd Network boot loader which jumps to Hard Disk boot<br />
UNDI\ RAM disk image files DOS, WinPE<br />
osinstal.2 Raw DOS Diskette Boot image (first step)<br />
osinstal.3 Raw DOS Diskette Boot image (second step)<br />
winpex86.2 Boot image description files<br />
winpex86.2\ Boot image directory belonging to the description file<br />
Winpex86.iso<br />
Winnt.sif<br />
Ntdetect.com<br />
ntldr<br />
startrom Boot Loader<br />
Here you can see the OS- image templates under the \camenu folder:<br />
September 2007 Chapter 10: OSIM 10- 19
Under the Hood<br />
This directory contains all of the OS templates for preinstall and OS setup<br />
including the following:<br />
Windows original setup (for W2kP, W2KS, WXPP, WXPS, W98, WNT4,<br />
WME)<br />
Cloning (GHOST, PQIMG (Note no *.ftp,*.cmd,*.ftw))<br />
LINUX original setup<br />
USEW, REDHATW<br />
The following file types are used:<br />
*.Inf: used for auto answer files for unattended setup<br />
*.Osi: use for osinfo.ini with file names of files including parameters<br />
*.Def: used for default.ini parameter definitions<br />
*.Par: used for disk portioning schema<br />
*.bat: Used for scripts to prepare and execute OS setup from DOS when<br />
using share access to Boot Server<br />
10–20 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Under the Hood<br />
*.ftp: Used for scripts to prepare and execute the OS setup from DOS<br />
when TFTP access to the Boot Server is used.<br />
*.cmd: Used for scripts to prepare and execute the OS setup from WinPE<br />
when share access to the Boot Server is used<br />
*.Ftw: Used for scripts to prepare and execute OS setup from WinPE<br />
when TFTP access to the Boot Server is used<br />
Here you can see the OS image template files maintained under \images:<br />
September 2007 Chapter 10: OSIM 10- 21
Under the Hood<br />
Template Files and OS Types<br />
The template files are used for post installation functions. Each type has its<br />
own post install. If you add a driver to $oem$ in the template, all images of<br />
this type will get the driver.<br />
Windows calls the i386\$OEM$\cmdlines.txt file upon initial startup after<br />
successful installation. This file executes custom.cmd (first time) which adds<br />
the target into a domain. Other “first step” tasks can and should be added<br />
here. runonce is also set configured to run after reboot and then the machine<br />
reboots.<br />
The runonce command executes custom.cmd (a second time) which sets the<br />
administrator password. Other second step tasks can/should be added here. It<br />
also executes the sxpsetup.cmd command which executes the <strong>DSM</strong> Agent<br />
setup.<br />
Here you can see how template files relate to OS Types:<br />
For example, following is the template.ini definition of SUSEW90-CD type:<br />
[SUSEW90-CD] type definition<br />
typecomment=SUSE 9.0 Professional,Personal<br />
comment in usage<br />
ossubpath=suse<br />
destination subpath for $OEM$ postinst files<br />
imagetemplates=susew<br />
take the $OEM$ templatefiles from susew dir<br />
10–22 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
createshare=MSNFS<br />
The OS image needs MS and NFS share<br />
batfile=susew.bat<br />
tftpfile=susew.ftp<br />
parameterdefinition=susew.def<br />
responcefile=susew.inf<br />
fileswithparameter=susew.osi<br />
partitionfile=susew.par<br />
stringtosubstitute=SUSEW<br />
Substitute this string with the image name in template files<br />
sdostype=251<br />
SD type of this OS<br />
Under the Hood<br />
;--The following lines specify what to read from the source CDs. Without these<br />
lines all will be read<br />
;--read files from path (-s )<br />
copyfrompath=SUSEWCD100<br />
Copy details are in section SUSEWCD100<br />
;--read setup files from CDs but image is on external NFS Server (-a )<br />
copytemplatesalways=yes<br />
Templates although needed on Boot Server<br />
morethanonealwayscd=1<br />
Files from OS CD1 are needed on Boot Server<br />
cd100=SUSEWCD10<br />
Copy details are in section SUSEWCD10<br />
;--read all files from CDs<br />
morethanonecd=5<br />
The image files will be read from 5 CDs<br />
cd1=SUSEWCD1<br />
Copy details from CD1 are in section SUSEWCD1<br />
cd2=SUSEWCD2<br />
cd3=SUSEWCD3<br />
cd4=SUSEWCD4<br />
cd5=SUSEWCD5<br />
;--SUSEWXX contents of CD copy (-s )<br />
[SUSEWCD100]<br />
identfile=dosutils\loadlin\loadlin.exe<br />
check this file to accept the CD<br />
content=content<br />
copy directory (source = destination)<br />
boot=boot<br />
suse=suse<br />
dosutils\loadlin\loadlin.exe=loadlin.exe<br />
copy file (source = destination)<br />
media.1=media.1<br />
media.2=media.2<br />
media.3=media.3<br />
September 2007 Chapter 10: OSIM 10- 23
Under the Hood<br />
media.4=media.4<br />
media.5=media.5<br />
;--Setup LINUX files on Boot Server even if it use a remote NFS share<br />
[SUSEWCD10]<br />
identfile=dosutils\loadlin\loadlin.exe<br />
boot=boot<br />
dosutils\loadlin\loadlin.exe=loadlin.exe<br />
;--SUSEWXX files to copy from CDs<br />
[SUSEWCD1]<br />
identfile=dosutils\loadlin\loadlin.exe<br />
content=content<br />
boot=boot<br />
suse=suse<br />
dosutils\loadlin\loadlin.exe=loadlin.exe<br />
media.1=media.1<br />
[SUSEWCD2]<br />
identfile=media.2\media<br />
media.2=media.2<br />
suse\i586=suse\i586<br />
suse\noarch=suse\noarch<br />
……………<br />
There are 3 primary folders under the \managedpc subdirectory:<br />
Agents contains agent install packages for target access<br />
Camenu provides common store for preinstall scripts (DOS,WINPE)<br />
Images contains Boot and OS images<br />
Here you can see how OS images are stored in the \images subdirectory:<br />
10–24 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Under the Hood<br />
Each OS image has an osinfo.ini description file in the root directory of the<br />
image. This file indicates that the image store directory contains an OS image<br />
September 2007 Chapter 10: OSIM 10- 25
Under the Hood<br />
Each OS image also has a default.ini describing parameters used in the<br />
image. This file contains several different sections. The [Default] section<br />
contains the default values for the parameters. The $xxx$ in the template are<br />
substituted by createosimage. The [Reserved] section contains a list of<br />
reserved internal parameter names and the [] section includes<br />
the definition of each parameter<br />
To add a parameter to the auto answer file edit the auto answer file (in the<br />
above example, \ManagedPC\<strong>CA</strong>MENU\mywinxp.inf).<br />
The [RegionalSettings] section identifies the Language=$localeID$<br />
information. To edit this setting locate the following value:<br />
[Default]<br />
localeID=1033<br />
Add the following new section at the end of the file:<br />
[localeID]<br />
Type=MapListExt<br />
MaxLength=128<br />
Comment=Language/locale to be installed<br />
Trans=yes<br />
item=5124 Chinese_Macau<br />
item=1030 Danish<br />
item=1033 English US<br />
10–26 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
item=2057 English UK<br />
item=1036 French Standard<br />
To check the new parameter execute the following command:<br />
RegisterOSImage -i -t<br />
Under the Hood<br />
This checks the files in osinfo.ini for $xxx$ parameter definitions against<br />
default.ini . If no parameter definition is found in default.ini, parameter<br />
definitions are added with default settings. To register the parameter from a<br />
command line, execute the following:<br />
RegisterOSImage –i -s <br />
Registering to Another Domain Manager<br />
To register an OS Image from IPS to a remote Domain Manager, use the<br />
following syntax:<br />
Registerosimage -i image -s “remote Domain Manager” -u user -p password -d<br />
unixl://”remote <strong>DSM</strong> domain”<br />
Then, export the OS image from local Domain Manager and import it into<br />
the<br />
remote Domain Manager using the following procedures:<br />
1. Export the OS-SD package into a directory.<br />
2. Transfer the directory<br />
to the remote site.<br />
3. Import the OS-SD package with<br />
the following command:<br />
Registerosimage -w directory -s Domain Manager<br />
September 2007 Chapter 10: OSIM 10- 27
Under the Hood<br />
Special Preparation<br />
for GHOST and PQIMG Based Images<br />
Use the following steps to create a clone image:<br />
1. Create a share (read, write) on IPS (including the ghost.exe).<br />
2. Create a FAT, FAT32 primary partition<br />
on the model target.<br />
3. Install the model OS (without <strong>DSM</strong> Agent) in the partition.<br />
4. Copy the MS sysprep files<br />
to the model PC and execute sysprep.<br />
5. Boot from a DOS Boot floppy with network access.<br />
6. Mount the share<br />
on IPS and execute ghost.exe from the share.<br />
7. Store the .gho on the share.<br />
8. Use createosimage and registerosimage<br />
to create the OSIM image<br />
Upgrade Procedure for OS-SD packages<br />
The Software Delivery package upgrade procedure deploys the OS image<br />
package to the target via Software Delivery and executes the winnt32.exe<br />
/upgrade in the package.<br />
Note: The unattended auto answer update.inf file also contains the Product<br />
ID.<br />
To set the product key in the default.ini, use the following syntax:<br />
CreateOSImage …. –k <br />
The following command makes a copy of the update.inf template to the OS<br />
image and sets the product key from the default.ini:<br />
RegisterOSImage<br />
Note: The upgrade depends on the ability of the<br />
with a new OS version.<br />
OS to upgrade a live system<br />
10–28 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
OSIM Domain Manager<br />
Plug-in<br />
OS Installation Job States<br />
Following depicts the OSIM Domain Manager plug in.<br />
Under the Hood<br />
You can monitor the state of the OS Job installation through the <strong>DSM</strong> Explorer.<br />
There are three possible job configurations:<br />
The current OS is the last successfully installed OS<br />
A planned OS is used to define an OS installation Job<br />
An activated or pending job is awaiting installation<br />
September 2007 Chapter 10: OSIM 10- 29
Under the Hood<br />
OSIM (CSM) Data Base Design<br />
Each job has to be defined in a planned configuration. After activation it<br />
becomes an activated, pending job and, after OS installation, it becomes<br />
current.<br />
Only one OS can be installed on a physical or virtual target.<br />
The OSIM database contains information about the following:<br />
Boot and OS images<br />
OS installation jobs (configurations)<br />
Computer and Boot Server<br />
This information<br />
is derived from the following classes:<br />
10–30 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Class Name Class ID Properties<br />
BootDiskImage 1006 Type, sdname, sdversion,<br />
d<br />
sdcomment, detecte<br />
Under the Hood<br />
BootOSImage 1008 Type, sdtype, locale, externalos,<br />
batchfile, sdname, sdversion,<br />
sdcomment, detected<br />
Bootparameter (for OS<br />
Images)<br />
Parametervalue (for OS<br />
images)<br />
Bootconfiguration (for OS<br />
installation jobs)<br />
1002 Type, Maxlength, Minvalue,<br />
Maxvalue, Trans, item (additional<br />
parameter values)<br />
106 See below<br />
1004 Bootstatus, Configstate,<br />
Configstatetime, Activationtime,<br />
Waitforagent, Retrytime, requesttime<br />
Computer 102 Dnsname, hostname, hostuuid,<br />
macaddr, firstseen, bootfile<br />
Bootserver 1000 Lastheard, lastreportallrequest,<br />
lastreportall, status<br />
Here you can see how the properties for Parameter value are derived:<br />
….<br />
Here you can see how properties for the Boot Server Class are derived:<br />
September 2007 Chapter 10: OSIM 10- 31
Under the Hood<br />
Special Bootstatus Property<br />
The following values are used to identify a job’s bootstatus:<br />
Value Status<br />
1000 Current<br />
2000 Stopped<br />
3000 Cancel pending<br />
4000 Failed<br />
5000 Set if delete is ordered for job<br />
6000 B oot server not responding<br />
7000 Unmanaged<br />
8000 ADS Managed<br />
10000 Planned<br />
11000 Activated<br />
20000 Analyzing<br />
21000 Pending<br />
22000 Installing<br />
The computer’s bootstatus will be taken over from the job (configuration). If<br />
there is more than one configuration (planned, current, activated) the state of<br />
the highest configuration will be set.<br />
10–32 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
OSIM Database Objects and Relationships<br />
Here you can see the relationship<br />
between OS Database objects:<br />
Here you can see the properties for an OS<br />
Job:<br />
Here you can see the link between OS Job and used OS image:<br />
Under the Hood<br />
September 2007 Chapter 10: OSIM 10- 33
Under the Hood<br />
10–34 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Boot Server Components<br />
Boot Server Configuration<br />
Here you can see the various components used by the Boot Server:<br />
More details about these functions is provided in the next few sections.<br />
Under the Hood<br />
Sdmpcserver (sdmpcworker.exe) is a <strong>CA</strong>F process that uses multiple threads<br />
for TFTP, PXE, Agent-copy, ping and password change. These threads<br />
(MaximumThreadPoolSize) are created during startup and are dynamically<br />
assigned and released from the thread pool. If more threads are needed, the<br />
thread pool will be increased stepwise by 10. If this happens frequently, you<br />
should consider increasing the MaximumThreadPoolSize value.<br />
The configuration can be changed through configuration policies maintained in<br />
the following location:<br />
September 2007 Chapter 10: OSIM 10- 35
Under the Hood<br />
/<strong>DSM</strong>/Scalability Server/osim/ManagedPC/server<br />
The Minimum value for MaximumThreadPoolSize 50 and the Maximum<br />
value is 1000. The default value is 56.<br />
The following values are used for Boot Server PXE configuration:<br />
PXEDisabledAtStart (Disable PXE service at start)<br />
If PXEDisabledAtStart is set to 1, the PXE process of the Boot Server is<br />
disabled after the next restart of the caf sdmpcserver. 0 means normal<br />
start of sdmpcserver.<br />
<strong>CA</strong>DHCPProxy (Enable DHCP proxy)<br />
If <strong>CA</strong>DHCPProxy is set to 1, the Boot Server will listen on port 67, and<br />
4011 for DHCP discover and BINL request messages. If <strong>CA</strong>DHCPProxy is<br />
set to 0, the Boot Server will only listen on 4011 for BINL request<br />
messages.<br />
For Boot Server TFTP Configuration, the service consists of one TFTP<br />
connection thread and multiple data transfer threads. The TFTP server only<br />
supports reading of files from the Boot Server’s image store and monitors<br />
TFTP file transfers for special image files in order to set the next boot image in<br />
a sequence of images.<br />
Following are parameters used for Boot Server Configuration:<br />
TFTPD_RedirectPort (Port to redirect TFTP requests)<br />
Min = 0, Max = 65535, Default = 0<br />
Port to redirect tftp requests to, if another tftp server is available. 0 means<br />
no redirection.<br />
LogTftpFileRequests (Log TFTP file requests)<br />
If set to enabled(1) then all tftp file requests are reported to the event lo g.<br />
0 means no reports. Default = 1<br />
DebugLevel (Level to log TFTP file requests)<br />
The level of detail to output to the TFTP log file. 5 means all, 1 only errors.<br />
TftpRetries<br />
(TFTP retries before timeout)<br />
Min = 1, Max = 5, Default = 3<br />
The maximum number of retries to send a packet to a target machine<br />
before timeout the transfer.<br />
TftpThrottle (Back off time after TFTP send)<br />
Value = 0, min = 0, max = 30<br />
The maximum number of milliseconds to back off after sending a tftp<br />
packet to a target machine.<br />
This allows more simultaneous downloads on<br />
slower targets.<br />
10–36 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
TftpTimeout (TFTP timeout)<br />
Min = 1, Max = 10, Default = 3<br />
Under the Hood<br />
Maximum timeout in seconds to wait for the next packet from a target.<br />
Here you can see how the PXE and TFTP threads work together:<br />
The PXE thread monitors port 67 for DHCP discover.<br />
If U SEacl=1 it also monitors port 68 for offers from other Boot Servers.<br />
If the PXE thread sees more than 3 discovers<br />
without an offer, it will send an<br />
offer.<br />
The TFTP read request will be handled<br />
by the connection thread and will create<br />
a data transfer thread for each target.<br />
September 2007 Chapter 10: OSIM 10- 37
Under the Hood<br />
OSIM Boot Server Ping Thread Boot Server Password Setting<br />
The OSIM Boot Server Ping thread monitors<br />
targets by doing the following:<br />
<br />
Updating the TFTP access list. If the target answers a ping after<br />
starting<br />
the OS installation it will be removed from the TFTP access list.<br />
<br />
Pinging known targets and waiting for a ping response<br />
If the target is not accessible within the designated time period (2 hours<br />
by default) it will also be removed from the TFTP access list.<br />
The following parameters are used to specify OSIM Boot Server ping<br />
configuration:<br />
PingTimeout (PING timeout)<br />
min =1, max = 10, default = 2<br />
time in seconds to wait for a ping response.<br />
PollIterations (PING poll iteration)<br />
Min = 1, max = 500, default = 120<br />
Number of times to ping a target machines before it is determined to be<br />
down.<br />
PollInterval (PING poll interval)<br />
Min = 1, max = 600, default = 60<br />
Time in seconds between which pinging of all machines known by the Boot<br />
Server is performed.<br />
The Password change thread changes the password of the OSIM canonprv user<br />
(local user) on a regular basis. The encrypted password is stored in the local<br />
comstore, from which it is sent to the target with each PXE boot. This<br />
password is used in the Boot Image to get access to the shares on the Boot<br />
Server.<br />
The following parameters are used to configure the password<br />
change thread:<br />
PWCDays (Password change interval)<br />
Min = 1, max = 365, default = 1<br />
Time<br />
in days between password changes for the user canonprv.<br />
The following configuration parameters define the complexity of the created<br />
canonprv password:<br />
PW_length (Password length)<br />
The maximum length of the password generated for user canonprv.<br />
10–38 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Boot Server Agent Copy Thread<br />
Min = 8, max = 128, default = 14<br />
PW_num_digits (Number of digits in password)<br />
Under the Hood<br />
The minimum number of digits [0-9] to be generated when generating<br />
a<br />
random password for canonprv.<br />
Min = 0, max = 128, default = 5<br />
PW_num_upper_case_characters (Number of upper case characters in<br />
password)<br />
The minimum number of Uppercase Characters [A-Z] to be generated.<br />
Min = 0, max = 128, default = 3<br />
PW_num_lower_case_characters<br />
password)<br />
(Number of lower case characters in<br />
The minimum number of Lowercase<br />
Characters [a-z] to be generated.<br />
Min = 0, max = 128, default = 3<br />
PW_num_symbols (Number of symbols<br />
in password)<br />
The minimum number of special symbol characters<br />
to be generated. If the<br />
value is larger then PW_length then this value will be truncated to<br />
PW_length.<br />
Min = 0, max = 128, default = 3<br />
The Agent copy thread browses the sdlib (library.dct) to find packages<br />
matching a specific naming pattern and takes the most specific version. The<br />
most recently<br />
copied agents are listed in the agent.inf file:<br />
Agent store contains the .caz files which include the image format of the agent<br />
for TFTP download.<br />
September 2007 Chapter 10: OSIM 10- 39
Under the Hood<br />
Boot Server csmagent and sdbsmstate<br />
The following example demonstrates how the distribution of an OS installation<br />
job sent from the OSIM Manager to the Boot Server is listed in the<br />
TRC_CSMAGENT_0.log.<br />
The next example shows<br />
how delivery of the Boot Server hello message (alive)<br />
to the OSIM Manager is written in the TRC_CSMAGENT_0.log:<br />
10–40 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Following is a list of reports that can be launched to the Manager by<br />
sdbsmstate (Csmagent):<br />
Report Description<br />
Bsinfo Report Boot Server status<br />
Under the Hood<br />
Bscompinfo Report status of assigned PXE target machine(s)<br />
Bsosinfo Report available OS images<br />
Bsbtinfo Report available boot images<br />
Bsbreginfo Report PXE boot requests and ADS devices<br />
Following is a list of requests and jobs that can be sent from the Manager to<br />
the sdbsmstate (Csmagent):<br />
Request Description<br />
Bssync Synchronize list of assigned PXE targets with<br />
manager MDB<br />
Bsstartpxe Start answering PXE requests<br />
Bscompinstall Activate OS installation job<br />
Bscompcancelinstall Cancel active OS installation job<br />
Bscompremove Remove computer from list of assigned PXE target<br />
machines<br />
September 2007 Chapter 10: OSIM 10- 41<br />
the
Under the Hood<br />
Boot Server Administrative Files<br />
Request Description<br />
Bscompserve Add computer to list of assigned PXE target<br />
machines and abort active OS installation<br />
Bscompwol Wake up target computer<br />
The OSIM Manager sends the reboot request for a target to the sdbsmboot<br />
(Csmagent) to the target’s agent. Bslocalreboot triggers local reboot<br />
(provided by <strong>DSM</strong> Agent).<br />
Administrative files for sdbsmstate are kept in the following location:<br />
c:\Program Files\<strong>CA</strong>\<strong>DSM</strong>\Server\SDBS\var\ManagedPC.<br />
Sdbsmstate<br />
reports changes of Boot Server data to the manager only once.<br />
The following files are used as memory for reports:<br />
Filename<br />
Contains<br />
Bsmbreq.dat Reported boot<br />
requests<br />
Bsmconf.dat Start data of the job to compare with FCOR<br />
Bsmimgb.dat Reported boot images<br />
Bsmimgo.dat Reported OS images<br />
Bsminfo.dat Sent hello (alive) messages<br />
Bsmstat.dat<br />
Reported state changes of install jobs<br />
Here you can an example of the contents for a bsmimgo.dat file:<br />
10–42 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Following is the key to interpreting the contents:<br />
Modified = 0 means “reported” while Modified = 1 means “not yet<br />
reported”<br />
:*osimage = OS image was found on Boot<br />
Server<br />
Under the Hood<br />
AckId = report ID and the AckId on the last line identifies<br />
the report that<br />
was most recently accepted by the manager<br />
Following is an example of the contents of a bsmstat.dat file:<br />
Following is the key to interpreting the contents:<br />
September 2007 Chapter 10: OSIM 10- 43
Under the Hood<br />
Pending = 0/1 identifies the pending OS job<br />
Running = 1 indicates that the OS job is running while Running = 0<br />
indicates that the boot sequence finished<br />
Boot1st = boot loader file<br />
1stFile = first boot file in the sequence<br />
NextFile = Next boot file in the sequence<br />
Following is an example of the contents of a bsmbreq.dat file:<br />
Following is the key to interpreting the contents of this file:<br />
Served = 0 indicates that no PXE request has been answered while Served<br />
= 1 indicates that the PXE request has been answered for the client<br />
ADSclient = 0 indicates that the target is not managed by ADS while<br />
ADSclient = 1 indicates that it is<br />
Data Exchange Between sdmpcserver and sdbsmstate<br />
The following files are used for data exchange between sdmpcserver and<br />
sdbsmstate. They are found in the following location:<br />
c:\Program Files\<strong>CA</strong>\<strong>DSM</strong>\Server\SDBS\var\ManagedPC<br />
10–44 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Boot Server WOL and Reboot<br />
Boot Server Access from Target<br />
File name Contains<br />
Mac.acl MAC of all targets the Boot Server is<br />
ble for<br />
responsi<br />
Under the Hood<br />
ManagedPCDataFile (FCOR) basic<br />
PXE data of targets (binary<br />
format). A test tool listfcore shows the<br />
contents<br />
PXEBoot.log MAC of a newly picked up target until the<br />
manager accepted the boot sever<br />
relationship and the MAC is added to<br />
mac.acl<br />
The WOL and Reboot request is sent in the install job to the Boot Server. The<br />
Boot Server sends the Job to the Domain Manager.<br />
The DM synchronizes Reboot and WOL<br />
– The DM sends the Reboot request to the target via sdbsmboot which<br />
uses the <strong>CA</strong>F Reboot service to restart the target.<br />
– The DM sends a WOL request to the responsible Boot Server through<br />
sdbsmstate which uses the <strong>CA</strong>F WOL service to broadcast the WOL<br />
magic package.<br />
WOL broadcast and subnets:<br />
The WOL (magic package) is sent as a broadcast package in the server’s<br />
sub network.<br />
Most router configurations will not forward WOL magic packages to all<br />
subnetworks<br />
Additionally the Boot Server plug-in, sdbsmstate, looks into the common<br />
server target list (IP, subnet masks)<br />
to create a list of subnet addresses<br />
where <strong>DSM</strong> targets are located.<br />
The sdbsmstate sends a WOL package to the broadcast address of each<br />
calculated subnetwork.<br />
Boot Server access from target is managed either through share mode access<br />
or TFTP access:<br />
The target reads the OSIM OS image files from Boot Server’s image store<br />
A Boot Server provides access to the image store via shares or via TFTP.<br />
September 2007 Chapter 10: OSIM 10- 45
Under the Hood<br />
The target Boot Images are always load via TFTP but, depending on the<br />
Boot Server configuration, the OS files will be read from shares or via TFTP<br />
GHOST, GHOST32, PQIMG OS can only be installed from shares.<br />
Here you can see how the OS insta llation occurs via share access of TFTP for<br />
Windows releases (Win98 thru Win2003):<br />
You can switch between Share mode and TFTP by configuring the Boot Server<br />
access mode. The sdbsswitch command creates or removes the OSIM shares<br />
and changes the image<br />
data between the shared directory structure and the<br />
image file for TFTP download.<br />
sdbsswitch -t switches<br />
from share to tftp access.<br />
sdbsswitch -s switches from tftp to share access.<br />
sdbsswitch -l shows the current configuration<br />
of the Boot Server.<br />
When<br />
either sdbsswitch -t or -s executes it shuts down the sdmpcserver<br />
process and does the following:<br />
<br />
Searches the image store for all osinfo.ini.<br />
Looks in each osinfo.ini for information about the shares and imagefile<br />
– Createzip = imagefile (If TFTP, this imagefile must be created)<br />
– Sharename = sharename (Name of the share which<br />
is also for NFS)<br />
10–46 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Remote Execution of sdbsswitch<br />
with Configure Job<br />
Access for LINUX OS images<br />
Under the Hood<br />
– Createshare = MS or NFS or MSNFS (creates this type of share where<br />
MS = Microsoft share; NFS = LINUX NFS share; MSNFS = both )<br />
The Scalability Server package includes configure<br />
procedures to change the<br />
Boot Server access method via Software Delivery.<br />
Linux OS image setup always requires NFS shares. When the NFS shares are<br />
on the Boot Server the following applies:<br />
Windows Boot Server requires UNIX services<br />
for Windows 3.5 or later for<br />
the NFS shares.<br />
LINUX Boot Server requires an active NFS server.<br />
NFS shares can also be provided on a central Windows or Linux server,<br />
however, the directories and the NFS share must have read access rights for<br />
anonymous.<br />
September 2007 Chapter 10: OSIM 10- 47
Under the Hood<br />
IPS and Boot Server on One<br />
System<br />
When Boot Server is in TFTP mode the Createosimage -i <br />
command does not create a .caz file. This must be done later with the<br />
following command:<br />
createosimage –z <br />
For a Linux OS image, createosimage tries to create an NFS share if the<br />
following is fulfilled:<br />
Unix services for Windows 3.5 is installed<br />
LINUX image is not on an external NFS share (-a )<br />
Use of Microsoft Automated Deployment Services (ADS)<br />
<strong>DSM</strong> Boot Server can coexist with the ADS Boot Server<br />
Because of an arrangement between <strong>CA</strong> and Microsoft, ADS and <strong>DSM</strong><br />
OSIM should be able to coexist<br />
Microsoft ADS can be downloaded from Microsoft and requires Windows<br />
2003 Enterprise Server<br />
Microsoft ADS has it‘s own user interfaces and management functionality.<br />
<strong>DSM</strong> only synchronizes the target responsibility on Server level between<br />
<strong>DSM</strong> Boot Server and ADS Boot Server.<br />
The ADS managed targets are contained in the MDB and visible (but not<br />
manageable) in <strong>DSM</strong><br />
If OSIM Boot Server is used as an ADS proxy the following applies:<br />
The Boot Server will ask the ADS server before it answers PXE requests of<br />
a special target. The Boot Server will not answer if the target is ADS<br />
managed.<br />
If the customer adds PXE targets to the ADS server, the configured OSIM<br />
Boot Server will be notified from the ADS server.<br />
The Boot Server<br />
reports the ADS managed targets to the <strong>DSM</strong> domain<br />
manager. These targets will be marked as ADS managed in the MDB.<br />
The Domain Manager also removes all OSIM jobs from that target.<br />
If the PXE target is removed from the ADS server, the configured Boot Server<br />
and the Domain Manager will be notified from the ADS server. The target<br />
becomes an unmanaged OSIM target again.<br />
10–48 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Under the Hood<br />
You can also delete the ADS target from<br />
the MDB and make it managed again.<br />
To configure the Boot server as an ADS proxy use the following:<br />
ADSUse (Enable ADS proxy function)<br />
Must be set to 1 or true to enable the ADS proxy<br />
ADSProvider (ADS controller<br />
name)<br />
<br />
<br />
The IP address or hostname of the machine which contains the<br />
MicrosoftADS namespace.<br />
ADSUserId (ADS user ID)<br />
This user ID must be a member of the Administrators group on the ADS<br />
Controller and must have<br />
been granted full permissions to the<br />
\\ADSProvider\ROOT\MicrosftADS namespace.<br />
If the user is not the “Administrator” then new user's access rights can be<br />
set by following these procedures:<br />
– First create<br />
a new user from computer Management<br />
– Then configure WMI by going to the WMI Control properties page<br />
ADSPassword (ADS password)<br />
The password to login to the ADS controller for the given user id.<br />
ADSDomain (ADS domain name)<br />
The domain to use to authenticate the user when connecting to the<br />
controller. This can be left blank if the user to authenticate has been<br />
defined on the ADS controller.<br />
ADSAuthenticationType (ADS authentication<br />
type)<br />
The type of authentication to use when connecting to the ADS controller.<br />
This value can be set to either ntlmdomain, or Kerberos.<br />
September 2007 Chapter 10: OSIM 10- 49
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
OSIM Boot Server and Manager Events<br />
TFTP OSIM Boot Server Events<br />
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
Both the OSIM Boot Server (sdmpcworker) and OSIM Manager (<strong>DSM</strong>) write<br />
events to the Application event log.<br />
For a complete list of events, refer to the OSIM Inside <strong>Guide</strong>.<br />
The TFTP communication component<br />
of the OSIM Boot Server (sdmpcworker)<br />
can be configured<br />
to write events for every TFTP read request. Since a large<br />
num ber of TFTP requests can overflow the event log, you may want to switch<br />
off the TFTP events in the common configuration by editing the<br />
LogTftpFileRequests<br />
parameter.<br />
<br />
Se t to false it disables logging of TFTP read requests.<br />
<strong>CA</strong><strong>DSM</strong>CMD is a command line interface that can be used to support process<br />
automation for Desktop and Server Management. It includes commands and<br />
actions<br />
for the following OSIM related functions:<br />
<br />
Set to true for a specific Boot Server, it enables logging of TFTP read<br />
requests.<br />
Administering target systems<br />
Setting up new OS configurations and maintaining them<br />
Initiating and controlling OS installation requests via network<br />
10–50 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Architectural Overview<br />
On Linux this includes the following:<br />
cadsmcmd (/opt/<strong>CA</strong>/<strong>DSM</strong>/sd/bin)<br />
libsd_bmscapi.so (/opt/<strong>CA</strong>/<strong>DSM</strong>/sd/lib)<br />
cadsmcmd.enu (/opt/<strong>CA</strong>/<strong>DSM</strong>/sd/nls)<br />
sd_bmscapi.enu (/opt/<strong>CA</strong>/<strong>DSM</strong>/sd/nls)<br />
On Windows this includes the following:<br />
cadsmcmd.exe (C:\Program Files\<strong>CA</strong>\<strong>DSM</strong>\bin)<br />
sd_bmscapi.dll (C:\Program Files\<strong>CA</strong>\<strong>DSM</strong>\bin)<br />
cadsmcmd.enu (C:\Program Files\<strong>CA</strong>\<strong>DSM</strong>\sd\NLS)<br />
sd_bmscapi.enu (C:\Program Files\<strong>CA</strong>\<strong>DSM</strong>\sd\NLS)<br />
The <strong>CA</strong><strong>DSM</strong>CMD also depends on the following client APIs:<br />
CO <strong>CA</strong>PI (libcmObjectInterface.so, cmObjectInterface.dll)<br />
CSM <strong>CA</strong>PI (libccsmclient.so, ccsmclient.dll)<br />
CCNF <strong>CA</strong>PI (libccnfclient.so, ccnfclient.dll)<br />
SD <strong>CA</strong>PI (libsd_gapi.so, sd_gapi.dll)<br />
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
The OSIM capabilities of <strong>CA</strong><strong>DSM</strong>CMD can only be used under the following<br />
conditions:<br />
when the addressed <strong>DSM</strong> manager is a Domain Manager<br />
when the addressed Domain Manager has SD capability<br />
Following is an architectural overview of <strong>CA</strong><strong>DSM</strong>CMD:<br />
September 2007 Chapter 10: OSIM 10- 51
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
<strong>CA</strong><strong>DSM</strong>CMD receives its requests via one of the following interfaces:<br />
Batch interface<br />
A sequence of <strong>CA</strong><strong>DSM</strong>CMD requests are coded in<br />
a file and this file is<br />
processed by the <strong>CA</strong><strong>DSM</strong>CMD in one block and session.<br />
The control is<br />
returned to the application or user after<br />
the file (and all of its requests)<br />
have been processed.<br />
Call interface<br />
One request is passed with the <strong>CA</strong><strong>DSM</strong>CMD and processed.<br />
The session to<br />
the manager is established when the <strong>CA</strong><strong>DSM</strong>CMD starts and terminates<br />
when it ends. The application can now react on requests<br />
results<br />
immediately but the session establishment overhead has to be considered.<br />
Pipe interface<br />
With the <strong>CA</strong><strong>DSM</strong>CMD start a named pipe is established and the<br />
<strong>CA</strong><strong>DSM</strong>CMD receives its requests via that pipe. The session<br />
remains until<br />
the application or user explicitly requests for session termination.<br />
More<br />
than one CLI request can be sent to the CLI by an application<br />
or user and<br />
they can directly react to request result and do not suffer from the session<br />
establishment overhead.<br />
Verbose interface<br />
This is a menu driven interface that is not used for process automation.<br />
<strong>CA</strong><strong>DSM</strong>CMD breaks the request down into a sequence of atomic sub-requests<br />
that are handled by the API layer. These atomic requests can be for different<br />
APIs. The native OSIM stuff is handled by the OSIM <strong>CA</strong>PI that further breaks<br />
the requests down into a sequence of CSM <strong>CA</strong>PI requests.<br />
Utilizing the <strong>DSM</strong> Session Messaging the requests are transferred to a <strong>DSM</strong><br />
domain manager for processing. The components addressed are the common<br />
object manager, SD dialog manager / API, and CSM API.<br />
If <strong>CA</strong><strong>DSM</strong>CMD is running on the addressed manager then the session<br />
managing and the common object manager is bypassed and the CO <strong>CA</strong>PI<br />
directly communicates with CO DAI (Database access interface).<br />
Diagnosing Problems with <strong>CA</strong><strong>DSM</strong>CMD<br />
The <strong>CA</strong><strong>DSM</strong>CMD writes a log file on demand based on the following<br />
environment variables:<br />
SDCMD_TRACE={ALL|FILE|SCREEN}<br />
SDCMD_FILE=<br />
SDCMD_TRACE_OPT=B3C9<br />
10–52 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
C code should be set to 9 as CSM trace is no longer supported from CLI layer<br />
(it has to be managed by cfTrace commands now).<br />
The default log file, cadsmcmd.log, is located at the <strong>DSM</strong> log directory;<br />
however,<br />
different <strong>CA</strong><strong>DSM</strong>CMD can write different logs.<br />
The <strong>CA</strong>PI trace entries are found in the TRC_USD_x.log in the <strong>DSM</strong> log<br />
directory.<br />
It is possible that several concurrent <strong>CA</strong><strong>DSM</strong>CMDs are logging into separate<br />
log files.<br />
When <strong>CA</strong><strong>DSM</strong>CMD is started it records the following information about the<br />
established session at the console:<br />
Identification information:<br />
This is the first information recorded and it<br />
includes identification information<br />
for <strong>CA</strong><strong>DSM</strong>CMD and the copyright. The<br />
version shown is the build information of the executable.<br />
Log information: Whether<br />
logging is enabled or not and in case of file<br />
logging the file where the information is stored.<br />
The connection information: Shows information about the addressed<br />
manager and the authentication<br />
of the session.<br />
September 2007 Chapter 10: OSIM 10- 53
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
TargetComputer command<br />
– is the manager specified at time of CO <strong>CA</strong>PI<br />
installation. It is a CO<strong>CA</strong>PI parameter and not known to the<br />
<strong>CA</strong><strong>DSM</strong>CMD. If no local parameter is specified this manager is<br />
addressed otherwise the local one is taken.<br />
– is the current user. This user is always<br />
used if no Login<br />
information is passed with the <strong>CA</strong><strong>DSM</strong>CMD. It forces a unified logon.<br />
If<br />
authentication information is passed with the Login parameter this<br />
one<br />
is used.<br />
– Manager: Name of the manager the CLI is connected to<br />
– Domain:<br />
Name of the database system the related MDB resides.<br />
– Domain type: Records whether the manager is a domain or enterprise<br />
one<br />
– Features supported: records the CLI capability for this session.<br />
This information can also be found in the CLI log but is more distributed.<br />
OSIM uses the <strong>CA</strong><strong>DSM</strong>CMD “targetComputer” command. The set of actions is<br />
nearly the same as with USD 4.0:<br />
Action Description<br />
Create Creates a computer <strong>DSM</strong> that is SD<br />
and OSIM enables<br />
List Lists <strong>DSM</strong> computers that are SD<br />
agents and OSIM un-managed PC<br />
showAttr Shows the attributes of a computer<br />
including OSIM information about<br />
OSIM configurations<br />
setupOS Assigns a new OS image to an OSIM<br />
un-managed but registered computer<br />
modifyOS Assigns a new OS image to an OSIM<br />
managed computer<br />
showInstallParameter Lists the installation parameters<br />
of an<br />
OSIM configuration<br />
modifyInstallParameter Modifies installation<br />
parameters in a<br />
planned configuration<br />
Delete {planned|scheduled}OS Deletes the specified<br />
OSIM<br />
configuration of a required type<br />
10–54 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Act ion Description<br />
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
activateOS Schedules a planned OS configuration<br />
for installation<br />
reactivateOS Reschedules a failed or canceled<br />
configuration<br />
reinstallOS<br />
Schedules the current OS<br />
configuration for reinstallation<br />
cancelOS Cancels a schedules OS installation<br />
request (graceful)<br />
Dele te Deletes a computer agent entry in<br />
<strong>DSM</strong><br />
When it comes to OSIM support the <strong>CA</strong><strong>DSM</strong>CMD CLI is backwards compatible<br />
with V4, however please note the following:<br />
due to the name change from SDCMD to <strong>CA</strong><strong>DSM</strong>CMD users may have to<br />
– rename<br />
the SDCMD calls to <strong>CA</strong><strong>DSM</strong>CMD in their existing scripts on<br />
Windows<br />
– provide a link for SDCMD to <strong>CA</strong><strong>DSM</strong>CMD or to rename SDCMD to<br />
<strong>CA</strong><strong>DSM</strong>CMD in their existing<br />
scripts too on Linux<br />
<br />
The “linkBMS” action is now obsolete. With USD 4.0 OSIM and USD used<br />
different databases. There was no integration on DB<br />
layer. If a computer<br />
was registered at USD and becomes PXE enabled for the first time it<br />
registered with its MAC address and no name at OSIM. The linkBMS action<br />
was used to link the OSIM entry and the USD entry and name the system<br />
in O SIM as in USD. In <strong>DSM</strong> this has changed due to use of the MDB. If a<br />
PXE enabled system registers at the OSIM side CSM checks whether there<br />
is already<br />
a <strong>DSM</strong> registered system of the same MAC address and on<br />
match it<br />
links the entries. Since the linkBMS command is now obsolete if it<br />
is invoked a warning is given at the console that this action is obsolete and<br />
a “0” is returned to the application.<br />
The handling of the password parameter<br />
has changed.<br />
The “userParameter“<br />
and ”userName“ parameters of<br />
“modifyInstallParameter”<br />
have become<br />
obsolete.<br />
With USD 4.0 when a p arameter of type password was changed then<br />
additional information had to be passed for encrypting the new<br />
password<br />
correctly. This additional information had been either the name of a parameter<br />
presenting a user id or the user id directly.<br />
This user id was the key for<br />
encrypting the password.<br />
With <strong>DSM</strong> r11 OSIM has changed its encryption-decryption handling and no<br />
longer needs a user id as a key; it is independently encrypted/decrypted of it.<br />
September 2007 Chapter 10: OSIM 10- 55
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
Enhancements/Changes<br />
In r11 the parameters “userParameter” and “userName” are ignored by<br />
<strong>CA</strong><strong>DSM</strong>CMD. No error or warning is given.<br />
Here you can see how the command syntax has changed:<br />
targetComputer action=create<br />
name=«computer<br />
name»<br />
computerTy pe={machine | user profile | staging server | docking device}<br />
address=«network address»<br />
os=«operating<br />
system type»<br />
[stagingServer=«staging server name»]<br />
[calendarName=«calendar name»]<br />
[user=«user»]<br />
[phone=«phone»]<br />
[location=«location»]<br />
[comment=«comment»]<br />
[softwareManagedSystem[={y|n}]] [racPolicy={ common | disabled | deferred | automatic}]<br />
[hostName= «host name»]<br />
{[macAddress=«MAC address»] |<br />
[bootServer=«Boot Server name»] macAddress=«MAC<br />
address»<br />
osImage=«os image name»}<br />
The syntax of the action “create” has been changed. The options “hostName”<br />
and “macAddress” can also be coded without OSIM context now. To create an<br />
OSIM<br />
entry beside the <strong>DSM</strong> common and USD entries the options macAddress<br />
and osImage have to be coded, but “bootServer” has become optional. If not<br />
coded<br />
an OSIM computer entry is created without any relation to any Boot<br />
Server.<br />
This missing link is established when the computer registers in OSIM<br />
from the network (PXE enabled).<br />
targetComputer<br />
action=activateOS<br />
name= «computer name»<br />
[atTime=«YYYY-MM-DD hh:mm»]<br />
[wakeup[={y|n}]]<br />
[restart[={y| n}]]<br />
[wai tBs[={y|n}]]<br />
[waitIm[={y|n}]]<br />
The options “waitBs” and “waitIm” are new. If waitBs or waitBs=y is coded<br />
then the CSM will defer the processing of the related OS installation until a<br />
Boot Server is assigned to the target. In any other case the CSM will not wait<br />
and if the specified target is<br />
not assigned to a Boot Server the order will fail.<br />
10–56 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Example Scenarios<br />
Example 1<br />
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
If waitIm or waitIm=y is coded then the CSM will defer the processing of the<br />
related OS installation until a BT and OS images<br />
associated wit this order are<br />
staged at the related Boot Server. In any other case the CSM will not wait and<br />
if the associated images are not staged at the related Boot Server then the<br />
order will fail.<br />
targetComputer action=reactivateOS<br />
name=«computer name»<br />
[atTime=«YYYY-MM-DD hh:mm»]<br />
[wakeup[={y|n}]]<br />
[restart[={y|n}]]<br />
[waitBs[={y|n}]]<br />
[waitIm[={y|n}]]<br />
targetComputer action=reinstallOS<br />
name=«computer name»<br />
[atTime=«YYYY-MM-DD hh:mm»]<br />
[wakeup[={y| n}]]<br />
[restart[={y|n}]]<br />
[waitBs[={y|n}]]<br />
[waitIm[={y|n}]]<br />
Following are a series of examples demonstrating the use of <strong>CA</strong><strong>DSM</strong>CMD for<br />
OSIM purposes.<br />
In this example a computer entry is provided in advance for a system that<br />
might be delivered in the (near) future.<br />
As long as the manufacturer provides<br />
the user with the MAC address<br />
of such a system beforehand the user is able to<br />
prepare the systems setup.<br />
In addition to the MAC<br />
address, the following other details are needed:<br />
the system name or label<br />
or host name<br />
its network address<br />
the Scalability Server the new system will be assigned to<br />
the name of the Boot Server the new system will be assigned to<br />
the OS image to be installed<br />
The Boot Server on OSIM layer should reside on the same system as the<br />
Scalability Server on <strong>DSM</strong> layer but this is not a requirement.<br />
September 2007 Chapter 10: OSIM 10- 57
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
For the purposes of our example, the following values are used:<br />
MAC address = FF:EE:CC:01:23:01<br />
Name =osim_sy_1<br />
network address=osim1.ca.com<br />
Scalability Server = my_server<br />
Boot Server = my_server (same<br />
as above)<br />
targeted OS image<br />
= myWinXP<br />
Here is the syntax:<br />
targetComputer action=create<br />
name=osim_sy_1<br />
computerType=machine<br />
address=osim1.ca.com<br />
os=win_xp_intel<br />
stagingServer=my_server<br />
macAddress=FF:EE:CC:01: 23:01<br />
bootServer=my_server<br />
osImage=myWinXP<br />
This command creates a <strong>DSM</strong> computer agent and makes it OSIM managed.<br />
The provided planned configuration can now be configured and monitored by<br />
using<br />
the modifyInstallParameter and showInstallParameter actions as in the<br />
past. Once the configuration requirements are met, it can then be scheduled<br />
for installation by launching the following command:<br />
targetComputer action=activateOS<br />
name=osim_sy_1<br />
Assuming that the related images are all staged at the associated Boot Server<br />
CSM starts will processing the request and, after a while, the scheduled<br />
configuration enters the “waiting” status. In this status when the new and PXE<br />
enabled system plugs in then the system launches a PXE request during the<br />
boot phase. The Boot Server identifies the system by means of its MAC<br />
address (given as part of the request) and knows that it is responsible for it<br />
and has an installation request pending for it. The Boot Server responds to<br />
the<br />
request and with that response the system is informed to down load a boot<br />
image, related to the OS image request above.<br />
The OS installation then starts<br />
wit h that boot image.<br />
In addition to the OSIM installation request a Software Delivery installation<br />
request can be provided in advance. When the OS installation completes<br />
and<br />
the system runs up then a <strong>DSM</strong> agent is normally installed on it. That agent<br />
then registers at the appropriate manager<br />
and starts processing the provided<br />
USD installation requests.<br />
10–58 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Example 2<br />
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
The final result is a new system on which the OS has been installed through<br />
OSI M and the required applications have been installed and configured<br />
through Software Delivery.<br />
In this next example, let us create an OSIM target for the MAC address<br />
“FF:EE:CC:01:23:02” in advance. The server name<br />
is “osim_sy_2” and the<br />
network address is “osim2.ca.com”. This target will be prepared for a<br />
Windows XP installation using the “myWinXP” OS image.<br />
Unlike the previous example, this system will not be assigned to any Boot<br />
Server. Rather, the Boot Server will automatically be assigned when the PXE<br />
system registers<br />
for the first time.<br />
Here is the syntax:<br />
targetComputer action=create<br />
name=osim_sy_2<br />
computerType=machine<br />
address=osim2.ca. com<br />
os=win_xp_intel<br />
macAddress=FF:EE:CC:01:23:02<br />
osImage=myWinXP<br />
The command is nearly the same as in the first example but the options<br />
“stagingServer” and “bootServer” are not coded. Those<br />
of you who are familiar<br />
with the old SDCMD know that the newly created system in <strong>DSM</strong> is assigned to<br />
the Scalability Server with the manager,<br />
but in OSIM the system is not<br />
assigned to any Boot Server.<br />
When the new PXE enabled system set ups and registers at OSIM the system<br />
is assigned to the Boot Server that detected that system first. The required<br />
OS<br />
installation is now performed via this Boot Server. When it is completed the<br />
new systems runs up and the <strong>DSM</strong> agent installed with the OS registers at the<br />
Domain Manager. By default, this agent addresses the Boot Server as<br />
Scalability Server (this can be changed in the OS configuration). If this<br />
Scalability Server is different from the one on the manager then a computer<br />
move from the old Scalability Server to the new one is now initiated at the<br />
Domain Manager. This means that all Software Delivery requests for this<br />
system that have already<br />
been forward to the old Scalability Server are now<br />
transferred to the new one.<br />
September 2007 Chapter 10: OSIM 10- 59
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
Example 3<br />
Example 4<br />
Next, let us consider a bare metal system that has registered at OSIM with<br />
MAC address “FF:EE:CC:01:23:03”. This system will be named “osim_sy_3”<br />
and assigned to the network address “osim3.ca.com” and the Scalability\Boot<br />
Server is “my_server”. It will then be set it up for the OS installation of the OS<br />
image “myWinXP”.<br />
This time the system that will become OSIM managed has already registered<br />
as a bare metal system at OSIM. In other words, the only information <strong>DSM</strong><br />
has about that system is its MAC address in OSIM and the Boot Server that<br />
has detected that system.<br />
The following syntax makes the system predefined in <strong>DSM</strong> and OSIM<br />
managed:<br />
targetComputer action=create<br />
name=osim_sy_3<br />
computerType=machine<br />
address=osim3.ca.com<br />
os=win_xp_intel<br />
stagingServer=my_server<br />
macAddress=FF:EE: CC:01:23:03<br />
bootServer=my_server<br />
osImage=myWinXP<br />
Once this command is launched the PXE system is allocated as a predefined<br />
system in <strong>DSM</strong> named osim_sy_3 that is assigned to my_server as Scalability<br />
and Boot Server regardless of which Boot Server reported that system.<br />
In this next example, the system named “osim_sy_4” has been registered in<br />
<strong>DSM</strong> but un-managed by OSIM. This system needs to be set up for the<br />
installation of the OS image “myWinXP”.<br />
In this scenario the target system is already registered at <strong>DSM</strong>, but not PXE<br />
enabled. Once the system is PXE-enabled and rebooted it will register at OSIM<br />
and be linked with the already existing <strong>DSM</strong> computer entry. However, it will<br />
remain OSIM un-managed because no OS configuration has been assigned<br />
yet. The syntax for making this system OSIM managed is:<br />
targetComputer action=setupOS<br />
name=osim_sy_4<br />
osImage=myWinXP<br />
This command creates a planned configuration of myWinXP for the osim_sy_4<br />
system. It does not change the Scalability or Boot Server assignments.<br />
10–60 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
Example 5<br />
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
In this example, a <strong>DSM</strong> registered but OSIM un-registered system<br />
“osim_sy_5” should become OSIM managed in advance and prepared for an<br />
installation of the OS image “myWinXP”.<br />
In the last example it is again assumed that the target system is already <strong>DSM</strong><br />
registered but not yet PXE enabled. It is planned to manage this system by<br />
OSIM too. You can wait until it registers with OSIM, as in the previous<br />
example, or you can use the following syntax to change it so that it is already<br />
managed when it is registered:<br />
targetComputer action=setupOS<br />
name=osim_sy_5<br />
osImage=myWinXP<br />
This command makes the target<br />
OSIM managed but the Boot Server won’t be<br />
assigned to it until<br />
it registers with OSIM.<br />
The following syntax<br />
advance:<br />
targetComputer action=activateOS<br />
name=osim_sy_5<br />
waitBs=y<br />
can be used to schedule the installation request in<br />
When the target becomes PXE enabled and is booted for the first time it will<br />
register at OSIM and the Boot Server reporting this system will be assigned to<br />
it. Next, the CSM starts transferring the request to the Boot Server. When<br />
the<br />
installation request enters “waiting” status and the system is rebooted again<br />
the OS installation request will be processed and the new OS installed.<br />
For the purposes of each of these examples it is assumed that all of the<br />
necessary OS images are already available at the Boot Server otherwise the<br />
request will fail.<br />
September 2007 Chapter 10: OSIM 10- 61
Glossary<br />
Application Programming Interface (API)<br />
An interface that allows programs to communicate with a product<br />
ADSI<br />
Active Directory Services Interface<br />
AMS<br />
Asset Maintenance System<br />
BABLD<br />
Brightstor ARCcserve Backup for Latops and Desktops<br />
Boot Server<br />
The OS Installation Management (OSIM) Boot Server is installed as part of a scalability server. The<br />
Boot Server installation automatically provides a TFTP server (with reduced access rights) and a PXE<br />
server.<br />
<strong>CA</strong><strong>DSM</strong>CMD<br />
Command line utility for Desktop and Server Management.<br />
<strong>CA</strong> Messaging (<strong>CA</strong>M)<br />
<strong>CA</strong>M (<strong>CA</strong> Messaging) is an established component used by several <strong>CA</strong> products to allow inter process<br />
communication, without the peer processes needing to be aware of exactly where their peer is located<br />
or without both entities or the network connecting them needing to be operational at the point of<br />
sending a message.<br />
Common Configuration (CCNF)<br />
The Unicenter <strong>DSM</strong> products are configured centrally and locally through a shared component,<br />
typically referred to as “common config” or “CCNF”. This components acts like an “enhanced Windows<br />
registry.” It manages the runtime configuration of practically all of the <strong>DSM</strong> subcomponents and<br />
infrastructure features, though there are some exceptions.<br />
Common Architecture Framework (<strong>CA</strong>F)<br />
Cross-platform service control manager, which provides a single point of control for all Unicenter <strong>DSM</strong><br />
components. <strong>CA</strong>F dynamically provides Unicenter <strong>DSM</strong> services as required using an extensible plugin<br />
model. Each <strong>CA</strong>F plug-in is a program, which provides agent, scalability server, or manager<br />
functionality. A <strong>CA</strong>F plug-in can also be an extension of <strong>CA</strong>F itself, which provides some common<br />
service, for example, registration with scalability servers or system event detection.<br />
Command Line Interface (CLI)<br />
A user interface where the user communicates with a product by commands. This interface allows you<br />
to automate the usage of a product by using the cli commands from a script.<br />
September 2007 Glossary–1
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
Common Component Library (CCL)<br />
The CCL provides common services that are used by many <strong>DSM</strong> components, including trace,<br />
configuration, security, and directory integration.<br />
Configuration and State Management (CSM)<br />
Configuration and State Management is a framework for configuring objects like software products or<br />
operating systems and tracking the status of those objects. It is used e.g. by OSIM.<br />
Common Registration API (CORA)<br />
All Unicenter r11 products utilize the common MDB schema to store and manage their data. CORA<br />
provides the interface through which these assets are registered and as the only source for updating<br />
these tables, (CORA) ensures that asset data flows consistently, thereby supporting the data and<br />
referential integrity of the Mob’s master asset data model.<br />
Content Management System (CMS)<br />
The content management system (CMS) is a central repository hosted by <strong>CA</strong> and available via the<br />
public internet. CMS contains information about all known software, including patch and fix<br />
recognition information (signatures).<br />
Data Transport Services (DTS)<br />
The Data Transport Service (DTS) infrastructure provides end-to-end management of content delivery<br />
securely, reliably and efficiently across multiple platforms, protocols, networks and data formats,<br />
helping clients to synchronize, distribute, update, replicate and validate data across his/her enterprise.<br />
Data may be gathered from one system and transported to many others (one-to-many), or it may<br />
need to be gathered from multiple systems and then sent to one (many-to-one).<br />
Database Access Interface (DAI)<br />
A standardized programming interface used by a component or process to access the <strong>DSM</strong> database.<br />
Detailed Design Specification (DDS)<br />
A representation of a software system or component of a system created to facilitate analysis,<br />
planning, implementation and decision-making. The DDS is used as the primary medium for<br />
communicating software design information.<br />
DMAPI<br />
The DMAPI is used by deployment consumers, such as damsel and the Deployment Wizard, to<br />
communicate with the manager. All user-visible deployment functionality is driven through the API.<br />
DM Primer<br />
DM_Primer handles payload transfer and payload installation execution.<br />
Domain Server (DS)<br />
Desktop and Server Manager architectural component that provides all management services to lower<br />
tiers an agents.<br />
Glossary–2 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
<strong>DSM</strong> Explorer<br />
The <strong>DSM</strong> Explorer is a single EGC framework-based Admin GUI. It consists of the framework itself, a<br />
common plug-in and a number of product specific plug-ins. The <strong>DSM</strong> Explorer provides a homogenized<br />
view and operation of all <strong>DSM</strong> products in which no product separation is apparent. As <strong>DSM</strong> products<br />
are purchased and installed the GUI simply becomes richer and more powerful.<br />
Engine<br />
The Engine is a multi-instance, multi-function, distributable component. Its primary focus is the<br />
maintenance of computers and related information. Logic is encapsulated into a number of Engine<br />
Tasks which can be scheduled to run at regular intervals.<br />
Enterprise Server (ES)<br />
Optional tier in Desktop and Server Management architecture which provides a single point of<br />
administration for multiple domains.<br />
Graphical User Interface (GUI)<br />
A graphical user interface allows a user to communicate with a product. Because of its graphical<br />
elements it is easy to use.<br />
Image Prepare System (IPS)<br />
Image Prepare System (IPS) reads the OS files from the vendor’s media and combines this with the<br />
OSIM files to create OSIM OS images and Boot Images.<br />
Infrastructure Deployment<br />
The Infrastructure Deployment subsystem facilitates the initial deployment of <strong>DSM</strong> software<br />
components within a heterogeneous enterprise. Infrastructure Deployment is also sometimes known<br />
as DMDeploy v2. <strong>DSM</strong> infrastructure components, such as Agents and Scalability Servers, can be<br />
transferred and installed without the use of Unicenter Software Delivery. This functionality is typically<br />
used for an initial roll out of the <strong>DSM</strong> infrastructure. Infrastructure Deployment uses a <strong>DSM</strong> Explorer<br />
wizard to scan for deployment targets and to configure and initiate the deployment job.<br />
Infrastructure Deployment Manager<br />
The Infrastructure Deployment Manager (dmdeploy) controls the overall deployment mechanism and<br />
maintains status among other tasks. It is a <strong>CA</strong>F plug-in<br />
Inter Process Communication (IPC)<br />
IPC is a communication system that allows two process to interchange information. The <strong>DSM</strong> Manager<br />
utilizes <strong>CA</strong>M for IPC and uses the <strong>DSM</strong> Message Interface to run <strong>CA</strong>M.<br />
IT Resource Management (<strong>DSM</strong>)<br />
A suite of products that enable the management of IT resources within an enterprise including:<br />
Unicenter Asset Management, Unicenter Software Delivery and Unicenter Remote Control.<br />
Management Database (MDB)<br />
The MDB schema provides a unified and extensible model for enterprise IT management (EITM). It<br />
contains both common tables and product-specific tables that were previously implemented in<br />
separate product databases. The MDB serves as the enterprise database for all <strong>CA</strong> products and acts<br />
as a primary reference point.<br />
September 2007 Glossary–3
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
Network Address Translation (NAT)<br />
Internet standard that enables a local-area network (LAN) to use one set of IP addresses for internal<br />
traffic and a second set of addresses for external traffic. A NAT box located where the LAN meets the<br />
Internet makes all necessary IP address translations.<br />
Networker<br />
The Networker is a generic, protocol-independent interface to stream based networking. This is a<br />
loadable component, which makes use of other loadable components to provide support for specific<br />
protocols, such as TCP/IP.<br />
Network Object Server<br />
When a transfer job is activated the TOS contacts the Network Object Server (NOS) for the best route.<br />
Communication is managed via SM.<br />
Operating System (OS)<br />
Every general-purpose computer must have an operating system to run other programs. Operating<br />
systems perform basic tasks, such as recognizing input from the keyboard, sending output to the<br />
display screen, keeping track of files and directories on the disk, and controlling peripheral devices<br />
such as disk drives and printers.<br />
OS Installation Management (OSIM)<br />
OS Installation Management is a feature of USD that manages the preparation, installation,<br />
configuration, and upgrade of operating systems in an enterprise network.<br />
Plug-in<br />
Computer program that interacts with a host application (a web browser or an email client, for<br />
example) to provide a certain, usually very specific, function "on demand.<br />
Port Multiplexer (PMUX)<br />
The Port Multiplexer is a plug-in that listens for stream connections and forwards them to the process<br />
that requires them. It handles connection establishment and enables multiple applications to listen on<br />
a single port (by default that port is 4728). The Port Multiplexer only supports TCP.<br />
Port Address Translation (PAT)<br />
Also known as "Network Address Port Translation" or "NAPT" PAT refers to network address translation<br />
where port number are mapped, allowing multiple machines to share a single IP address.<br />
Report Extractor<br />
The Report Extractor is a separate EGC plug-in that is used to extract data from the MDB into result<br />
tables that are presented in the GUI and can be printed or exported in a number of standard formats.<br />
The Report Extractor plug-in is also used by the <strong>DSM</strong> Engine to generate result sets on a scheduled<br />
basis.<br />
Sector Server<br />
The sector server is a component of UAM V4 that collects information from the attached agents and<br />
reports them to the UAM manager.<br />
Glossary–4 Desktop and Server Management <strong>Advanced</strong> <strong>Topics</strong> <strong>Guide</strong> September 2007
OSIM and <strong>CA</strong><strong>DSM</strong>CMD<br />
Scalability Server<br />
The Scalability Server is a component of the <strong>DSM</strong> R11 architecture that acts as a distribution point for<br />
software delivery activities and a collection point for asset inventory.<br />
Session Messaging (SM)<br />
Session Messaging (SM) is a client-server layer that sits atop the <strong>DSM</strong> Messenger component. SM is<br />
provided in the form of a C-based interface DLL and a management daemon (<strong>CA</strong>F plug-in). SM is<br />
modular and utilizes many common components. It provides session management, encryption,<br />
compression, low-level authentication (X.509), high-level authentication (O/S or External),<br />
transactional calls and message forwarding.<br />
Software Catalog<br />
The Software Catalog is an agent plug-in, which allows you "self-service". With this wizard based<br />
interface, you can install or remove software on your computer from a library provided by the<br />
administrator.<br />
TOS<br />
DTS is implemented around an object model. These are the objects controlled by the Transfer Object<br />
Service (TOS).<br />
Unicenter Asset Management (UAM)<br />
Unicenter Asset Management (UAM) is one of the worlds leading Enterprise Asset Management<br />
products. It is a scalable enterprise class product and its management capabilities allow clients to<br />
build an inventory of IT assets in a database and deploy management policy on remote desktops.<br />
It has a very broad platform and protocol coverage, utilizes <strong>CA</strong> Common Services and integrates with<br />
Unicenter NSM and other <strong>CA</strong> desktop products.<br />
Unicenter Remote Control (URC)<br />
Unicenter Remote Control (URC) is a product that allows accessing and controlling a distant PC and its<br />
resources from any location – as if you were locally logged on.<br />
Unicenter Software Delivery (USD)<br />
Unicenter Software Delivery (USD) is currently the world’s leading Enterprise Software Distribution<br />
product generating more revenue than any of its competition.<br />
It is a flexible tool that can build, distribute, install and manage software packages. Its management<br />
capabilities allow clients to install, configure, verify and remove software throughout their business<br />
environment in a controlled and standardized way. It has a very broad platform and protocol<br />
coverage, utilizes <strong>CA</strong> Common Services and integrates with Unicenter NSM and other <strong>CA</strong> desktop<br />
products.<br />
Web Admin Console (WAC)<br />
The Web Console is a browser-based user interface to Unicenter <strong>DSM</strong>, which can be installed on<br />
Windows and Linux operating environments.<br />
September 2007 Glossary–5