Herunterladen von PDF - Support

Transcription

CA IT Client Manager
Software Delivery Administrationshandbuch
12.8
Diese Dokumentation, die eingebettete Hilfesysteme und elektronisch verteilte Materialien beinhaltet (im Folgenden als
"Dokumentation" bezeichnet), dient ausschließlich zu Informationszwecken des Nutzers und kann von CA jederzeit geändert
oder zurückgenommen werden. Diese Dokumentation ist Eigentum von CA und darf ohne vorherige schriftliche Genehmigung
von CA weder vollständig noch auszugsweise kopiert, übertragen, vervielfältigt, veröffentlicht, geändert oder dupliziert werden.
Der Benutzer, der über eine Lizenz für das bzw. die in dieser Dokumentation berücksichtigten Software-Produkt(e) verfügt, ist
berechtigt, eine angemessene Anzahl an Kopien dieser Dokumentation zum eigenen innerbetrieblichen Gebrauch im
Zusammenhang mit der betreffenden Software auszudrucken, vorausgesetzt, dass jedes Exemplar diesen
Urheberrechtsvermerk und sonstige Hinweise von CA enthält.
Dieses Recht zum Drucken oder anderweitigen Anfertigen einer Kopie der Dokumentation beschränkt sich auf den Zeitraum der
vollen Wirksamkeit der Produktlizenz. Sollte die Lizenz aus irgendeinem Grund enden, bestätigt der Lizenznehmer gegenüber
CA schriftlich, dass alle Kopien oder Teilkopien der Dokumentation an CA zurückgegeben oder vernichtet worden sind.
SOWEIT NACH ANWENDBAREM RECHT ERLAUBT, STELLT CA DIESE DOKUMENTATION IM VORLIEGENDEN ZUSTAND OHNE
JEGLICHE GEWÄHRLEISTUNG ZUR VERFÜGUNG; DAZU GEHÖREN INSBESONDERE STILLSCHWEIGENDE GEWÄHRLEISTUNGEN
DER MARKTTAUGLICHKEIT, DER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK UND DER NICHTVERLETZUNG VON RECHTEN. IN
KEINEM FALL HAFTET CA GEGENÜBER IHNEN ODER DRITTEN GEGENÜBER FÜR VERLUSTE ODER UNMITTELBARE ODER
MITTELBARE SCHÄDEN, DIE AUS DER NUTZUNG DIESER DOKUMENTATION ENTSTEHEN; DAZU GEHÖREN INSBESONDERE
ENTGANGENE GEWINNE, VERLORENGEGANGENE INVESTITIONEN, BETRIEBSUNTERBRECHUNG, VERLUST VON GOODWILL ODER
DATENVERLUST, SELBST WENN CA ÜBER DIE MÖGLICHKEIT DIESES VERLUSTES ODER SCHADENS INFORMIERT WURDE.
Die Verwendung aller in der Dokumentation aufgeführten Software-Produkte unterliegt den entsprechenden
Lizenzvereinbarungen, und diese werden durch die Bedingungen dieser rechtlichen Hinweise in keiner Weise verändert.
Diese Dokumentation wurde von CA hergestellt.
Zur Verfügung gestellt mit „Restricted Rights“ (eingeschränkten Rechten) geliefert. Die Verwendung, Duplizierung oder
Veröffentlichung durch die US-Regierung unterliegt den in FAR, Absätze 12.212, 52.227-14 und 52.227-19(c)(1) bis (2) und
DFARS, Absatz 252.227-7014(b)(3) festgelegten Einschränkungen, soweit anwendbar, oder deren Nachfolgebestimmungen.
Copyright © 2013 CA. Alle Rechte vorbehalten. Alle Markenzeichen, Markennamen, Dienstleistungsmarken und Logos, auf die
hier verwiesen wird, sind Eigentum der jeweiligen Unternehmen.
CA Technologies-Produktreferenzen
Diese Dokumentation bezieht sich auf die folgenden CA-Produkte:
■
CA Advantage® Data Transport® (CA Data Transport)
■
CA Asset Intelligence
■
CA Asset Portfolio Management (CA APM)
■
CA Common Services™
■
CA Desktop Migration Manager (CA DMM)
■
CA Embedded Entitlements Manager (CA EEM)
■
CA Network and Systems Management (CA NSM)
■
CA Patch Manager
■
CA Process Automation
■
CA Business Intelligence
■
CA Service Desk Manager
■
CA WorldView™
■
CleverPath™ Reporter
Technischer Support – Kontaktinformationen
Wenn Sie technische Unterstützung für dieses Produkt benötigen, wenden Sie sich an
den Technischen Support unter http://www.ca.com/worldwide. Dort finden Sie eine
Liste mit Standorten und Telefonnummern sowie Informationen zu den Bürozeiten.
Inhalt
Kapitel 1: Einführung
11
Software Delivery als Teil von CA ITCM...................................................................................................................... 11
Verwenden des Data Transport Service ..................................................................................................................... 12
Kapitel 2: Software Delivery-Funktionen
13
Auswahl der Software Delivery-Komponenten .......................................................................................................... 13
Softwarepaketbibliothek ............................................................................................................................................ 14
Domänen-Manager .................................................................................................................................................... 14
Enterprise-Manager ................................................................................................................................................... 15
Scalability-Server ........................................................................................................................................................ 15
Software Delivery-Agent ............................................................................................................................................ 16
Software Delivery Agent Bridge ................................................................................................................................. 17
Docking-Geräte .......................................................................................................................................................... 17
Katalog........................................................................................................................................................................ 18
Logon-Shield für Windows-Betriebsumgebungen ..................................................................................................... 18
Software Management Packager ............................................................................................................................... 19
Packager für Windows ........................................................................................................................................ 19
Packager für Linux und UNIX ............................................................................................................................... 19
Desktop Management Script Generator und Editor .................................................................................................. 20
Kapitel 3: Implementierung
21
Konfigurieren der Manager-Hierarchie ...................................................................................................................... 21
Domänenimplementierung ................................................................................................................................. 22
Enterprise mit einer Implementierung von lokalen Administratoren................................................................. 24
Enterprise ohne eine Implementierung von lokalen Administratoren ............................................................... 25
Verwendung von Scalability-Servern ......................................................................................................................... 26
Software-Delivery-Verbesserungen für die interaktive Softwarebereitstellung unter Windows Vista oder
höher .......................................................................................................................................................................... 28
Kapitel 4: Konfigurieren von Software Delivery
31
Software Delivery, Richtliniengruppe......................................................................................................................... 31
Ändern der Konfigurationsrichtlinien ......................................................................................................................... 32
Konfiguration von Softwarejobs................................................................................................................................. 32
Konfiguration von Scalability-Servern ........................................................................................................................ 32
Konfiguration von Logon-Shield ................................................................................................................................. 33
Inhalt 5
Implizites Aktivieren von "Logon-Shield" ............................................................................................................ 34
Kapitel 5: Verwenden von Software Delivery
37
Computer- und Benutzerprofile ................................................................................................................................. 37
Definieren von Computern ................................................................................................................................. 38
Definieren von Benutzerprofilen......................................................................................................................... 38
Statische und dynamische Computergruppen ........................................................................................................... 38
Definieren von Computergruppen ...................................................................................................................... 39
Dynamische Computergruppen .......................................................................................................................... 39
Verknüpfen, Aufheben von Verknüpfungen und Verschieben von Computern und Computergruppen ........... 39
Abfragen ..................................................................................................................................................................... 40
Verwenden der Softwarepaketbibliothek .................................................................................................................. 40
Überblick über den Registrierungsvorgang ......................................................................................................... 41
Vorbereiten von Programmen für die Registrierung .......................................................................................... 44
Verzeichnisbaumstruktur der Bibliothek ............................................................................................................ 47
Programmregistrierung auf Scalability-Servern .................................................................................................. 52
Registrieren virtueller Anwendungen ................................................................................................................. 53
Registrieren von MSI-Paketen in der Softwarepaketbibliothek .......................................................................... 65
Registrieren von Windows CE- und Palm-Paketen in der Softwarebibliothek .................................................... 71
Prüfen von Paketen auf Konsistenz..................................................................................................................... 71
Definieren von Kataloggruppen .......................................................................................................................... 72
Verknüpfen von katalogbasierten Prozeduren ................................................................................................... 73
Anzeigen von Bibliothekselementdaten ............................................................................................................. 74
Versiegelung eines Software-Elements aufheben .............................................................................................. 74
Archivieren und Wiederherstellen von Softwareelementen .............................................................................. 75
Hinweise zum Prüfen auf Viren ........................................................................................................................... 75
Software und Prozeduren .......................................................................................................................................... 76
Definieren eingebetteter Elementprozeduren ................................................................................................... 76
Definieren hinzugefügter Elementprozeduren ................................................................................................... 80
Software- und Prozedurgruppen ........................................................................................................................ 84
Erneuern und Wiederherstellen fehlgeschlagener Installationen ............................................................................. 85
Lieferung und Staging von Software .......................................................................................................................... 86
Anweisungen ....................................................................................................................................................... 86
Vom Domänen-Manager gesendete Aufträge .................................................................................................... 89
Aktivieren von Elementprozeduren .................................................................................................................... 99
Auslösen einer sofortigen Prüfung der Warteschlange nach Jobs .................................................................... 100
Vor-und Nachbereitungsfunktionen für Jobprüfungen .................................................................................... 100
Getrennte Lieferung oder Bereitstellung und Jobaktivierung .......................................................................... 102
Anzeigen aktueller Installationen...................................................................................................................... 103
Download-Optionen .......................................................................................................................................... 104
Konfiguration der Download-Methode............................................................................................................. 105
6 Software Delivery - Administrationshandbuch
Optimieren der Erstellung komprimierter Jobdateien ...................................................................................... 107
Verwenden von symbolischen Verknüpfungen ................................................................................................ 107
Exportieren eines Bibliotheks-Images ............................................................................................................... 108
Offline-Agentenvorgang .................................................................................................................................... 109
Verteilen von Aufträgen vom Enterprise-Manager........................................................................................... 111
Überwachen des Verteilungsstatus .................................................................................................................. 113
Einstellungen für Softwarerichtlinien ............................................................................................................... 113
Liefern von virtuellen Anwendungen ....................................................................................................................... 117
Funktionsweise der Bereitstellung von virtuellen Anwendungen .................................................................... 118
Roaming und Bereitstellung virtueller Anwendungen ...................................................................................... 125
Softwarekatalog ....................................................................................................................................................... 128
Anzeige und Zugriff auf den Softwarekatalog ................................................................................................... 129
Konfigurieren des Softwarekatalogs für die Desktop-Benutzer ........................................................................ 129
Installation des Softwarekatalogs ..................................................................................................................... 130
Hinzufügen neuer Software aus dem Softwarekatalog .................................................................................... 131
Verwalten von Computern ....................................................................................................................................... 131
Verschieben von Computern ............................................................................................................................ 132
Nach einem Absturz erneut installieren ........................................................................................................... 141
Benutzerdefinierte Administratormeldung .............................................................................................................. 148
Verschieben der OSIM-Jobinformationen ................................................................................................................ 148
Optimierung der gleichzeitigen Ausführung von Managern .................................................................................... 149
Verschlüsselung und Drosselung für Übertragungen von Software-Paketen ohne NOS ......................................... 149
Optimierung von Datenbankaktualisierungen ......................................................................................................... 150
Fahren Sie einen Computer nach dem letzten SD-Job herunter .............................................................................. 150
Verwenden der SD Agent Bridge .............................................................................................................................. 151
UUID Generator für Agent Bridge ..................................................................................................................... 151
Einschränkungen bei der Verwendung der SD Agent Bridge ............................................................................ 152
Bekannte Probleme bei der SD Agent Bridge ................................................................................................... 152
Agentenregistrierung ........................................................................................................................................ 153
Besonderheiten bei der Agentenmigration ...................................................................................................... 155
Voraussetzungen bei der Verwendung der SD Agent Bridge ............................................................................ 155
Unterstützte Betriebsumgebungen und SD-Agenten ....................................................................................... 156
SD Agent Bridge-Konfiguration ......................................................................................................................... 156
Wake-on-LAN-Serverkonfiguration ................................................................................................................... 159
Hinzufügen von Legacy-Software zur Softwarepaketbibliothek ....................................................................... 162
Fehlermeldungen zur Download-Methode in Zusammenhang mit der SD Agent Bridge ................................. 163
Installieren von Wrapper-Paketen von externen Repositorys ................................................................................. 163
Beispiel-DSM-Architektur mit externen Debian-Repositorys ........................................................................... 163
Bereitstellen von Paketen aus Debian-Repositorys .......................................................................................... 165
Konfigurieren externer Debian-Repositorys in CA ITCM ................................................................................... 165
Bereitstellen von Debian-Paketen mithilfe von Software Delivery ................................................................... 172
Einrichten von Debian-Spiegel-Repositorys ...................................................................................................... 179
Inhalt 7
Einrichten von FTP- oder HTTP-Freigaben für Softwarepakete und BS-Images................................................ 189
Konfigurationsparameter für das Verwalten von Debian-Paketen ................................................................... 190
Installieren des debmirror-Hilfsprogramms ...................................................................................................... 190
Kapitel 6: Integration in Data Transport Service
195
Verwenden von DTS mit Software Delivery ............................................................................................................. 195
DTS zwischen Managern und Scalability-Servern ............................................................................................. 196
DTS zwischen Domänen-Managern und Agenten............................................................................................. 196
Mit Software Delivery installierte DTS-Komponenten ............................................................................................. 196
DTS-Komponenten unter Windows .................................................................................................................. 197
DTS-Komponenten unter Linux und UNIX ......................................................................................................... 197
Aktivieren und Deaktivieren von DTS ....................................................................................................................... 198
Arbeitsweise von DTS ............................................................................................................................................... 198
Kapitel 7: Diagnose und Fehlerbehebung bei Software Delivery
199
Ermitteln der Build-Nummer von CA ITCM .............................................................................................................. 200
Prüfen der Application Framework-Plugins ............................................................................................................. 200
Absturz des RAL-Extrahierungstasks ........................................................................................................................ 201
Softwarebereitstellungsjobs hängen sich auf gestreamten virtuellen Citrix XenDesktop-Rechnern
gelegentlich auf ........................................................................................................................................................ 202
Erfassungstool für Protokolldateien dsminfo ........................................................................................................... 203
Protokolldateien für CAF-Dienste ............................................................................................................................ 203
Software Delivery-Protokolldateien ......................................................................................................................... 204
Data Transport Service-Protokolldateien ................................................................................................................. 205
Registrierung von großen Softwarepaketen im DSM-Explorer dauert sehr lange ................................................... 206
Migrierte Abfrage ergibt unterschiedliche Ergebnisse............................................................................................. 207
Verschieben des Softwarekatalogs und des Scalability-Servers .............................................................................. 207
Woher weiß ich, ob die SD Agent Bridge läuft? ....................................................................................................... 208
Task-Manager kann nicht im gleichzeitigen Modus ausgeführt werden ................................................................. 208
Installations-Manager kann nicht im gleichzeitigen Modus ausgeführt werden ..................................................... 209
apt-Befehle für die Bereitstellung ............................................................................................................................ 210
Löschen von RAL-Datensätzen aus der MDB............................................................................................................ 211
Registrierung des Legacy-Agenten schlägt fehl ........................................................................................................ 212
Unicenter Software Delivery-Agent kann auf HP-UX System nicht gestartet werden ............................................. 213
RAC-Containerjob fehlgeschlagen ............................................................................................................................ 213
Bereitstellung von Softwarepaketen für virtuelle Anwendungen schlägt fehl ........................................................ 214
Netzwerkinstallation des MSI-Pakets schlägt fehl ................................................................................................... 216
Nicht durchgeführter Start des SD-Agents nach einem CAF-Neustart ..................................................................... 217
Kein vorab ausgeführtes Seeding der Variablen in "debconf"-Parametern ............................................................. 217
Fehler bei der Installation von Debian-Wrapper-Paketen ....................................................................................... 218
Fehler bei der Installation von Debian-Wrapper-Paketen ....................................................................................... 219
Der SD-Job hängt und die Meldung wird nicht angezeigt ........................................................................................ 219
Windows-Erkennung für interaktive Services sperrt Agenten ................................................................................. 220
Fehlender "DebWrap"-Pakettyp in DSM-Reporter .................................................................................................. 220
Fehlerhafter Abbruchsbefehl während der Neuinstallation von VDI-Komponenten .............................................. 220
Anhang A: Unterstützung und Lokalisierung eines Nicht-UTF-8Gebietsschemas
221
UTF-8- und MBCS-Codierung ................................................................................................................................... 221
Lokalisierung und UTF-8-Codierung ......................................................................................................................... 222
Unterstützung des Nicht-UTF-8-Gebietsschemas .................................................................................................... 222
Überlegungen zum Scalability-Server ...................................................................................................................... 222
Anhang B: Importieren von Abfragezeichenfolgen aus Unicenter Software
Delivery 4.0
225
Übersicht .................................................................................................................................................................. 225
Einschränkungen beim Importieren von Abfragen .................................................................................................. 226
Importieren von Ausdrücken, die BS-Sicherheits- oder Verzeichnisabfragen enthalten ......................................... 228
Importieren von Ausdrücken mit Hilfe von IN und NOT IN-Operatoren .................................................................. 229
Importieren von Ausdrücken ohne IN und NOT IN-Operatoren .............................................................................. 229
Importieren von Ausdrücken ohne IN und NOT IN-Operatoren .............................................................................. 230
Terminologieglossar
239
Inhalt 9
Kapitel 1: Einführung
Bei der CA ITCM-Komponente "Software Delivery" (SD) handelt es sich um eine Lösung,
die die Bereitstellung von Software und anderen digitalen Inhalten für Ressourcen im
gesamten Enterprise beschleunigt und automatisiert. Die SD-Komponente stellt flexible
Tools zur Erstellung, Verteilung, Installation und Verwaltung von Softwarepaketen und
Betriebssystemen auf Zielcomputern an beliebigen Orten weltweit zur Verfügung.
Die Software Delivery-Funktionen ermöglichen die Verwaltung von Software auf allen
Computern, die zu miteinander verbundenen oder autonomen Netzwerken gehören,
und geben Ihnen die vollständige Kontrolle über den Betrieb und die Leistung der auf
den Computern Ihres Netzwerks installierten Software. Die SD-Managementfunktionen
ermöglichen die Installation, Konfiguration, Überprüfung und Entfernung von Software
in Ihrer gesamten Geschäftsumgebung auf eine kontrollierte und standardisierte Weise.
Dabei werden für die Softwareverwaltung im gesamten Unternehmen eine Vielzahl von
Plattformen und Protokollen unterstützt.
Mit den SD-Tools und -Funktionen können Sie sicherstellen, dass die Software immer
korrekt und rechtzeitig installiert wird. So erhöhen Sie die Verlässlichkeit der verteilten
Computerdienste und bieten den Benutzern einen besseren Service.
Dieses Handbuch beschreibt die Konzepte und Vorgehensweisen von Software Delivery,
über die Sie die gesteuerte Verteilung und das Management von Software in Ihrem
Unternehmen verwalten können. Dieses Handbuch richtet sich in erster Linie an
Systemadministratoren. Es eignet sich jedoch für alle Benutzer, die einen Einblick in die
Funktionsweise von Software Delivery bei der Verwaltung der Verteilung und
Installation von Softwarepaketen in einem System vernetzter Computer gewinnen
möchten.
Dieses Kapitel enthält folgende Themen:
Software Delivery als Teil von CA ITCM (siehe Seite 11)
Verwenden des Data Transport Service (siehe Seite 12)
Software Delivery als Teil von CA ITCM
Software Delivery nutzt wesentliche Bestandteile der CA ITCM-Infrastruktur, z. B.
Datenbank, Kommunikation, Prozesssteuerung und Ereignismanagement. Dieses
Konzept bietet zahlreiche Vorteile: einfachere Administration, unübertroffenes
Funktionsspektrum, verbesserte Leistung in allen Funktionsbereichen sowie einheitliche
Daten und Terminologie.
Kapitel 1: Einführung 11
Verwenden des Data Transport Service
Verwenden des Data Transport Service
Data Transport Service (DTS) steuert den Datenübertragungsfluss in der Software
Delivery-Umgebung. DTS unterstützt Punkt-zu-Punkt- sowie Punkt-zu-vieleÜbertragungen, einschließlich Broadcast, Multicast und Fanout (ein einziger
Lesevorgang mit vielen Sende- und Schreibvorgängen). Sie können auch die
Netzwerkleistung optimieren, indem Sie den Paketversand drosseln und die Paketgröße
einschränken.
Durch die Integration von Data Transport Service in Software Delivery erhalten Sie die
Möglichkeit, Datenübertragungen in SD-Dialogfeldern anzuhalten, wiederaufzunehmen
und zu beenden. Weitere Informationen finden Sie unter "Integration in Data Transport
Service" (siehe Seite 195).
Kapitel 2: Software Delivery-Funktionen
Die Software Delivery-Funktionalität (SD) von CA ITCM umfasst flexible Dienste für die
Konfiguration der verschiedenen Komponenten Ihres Netzwerks. Vor der Konfiguration
Ihrer Softwareverteilungsumgebung müssen Sie die Funktion der einzelnen SDKomponenten kennen.
Auswahl der Software Delivery-Komponenten (siehe Seite 13)
Softwarepaketbibliothek (siehe Seite 14)
Domänen-Manager (siehe Seite 14)
Enterprise-Manager (siehe Seite 15)
Scalability-Server (siehe Seite 15)
Software Delivery-Agent (siehe Seite 16)
Software Delivery Agent Bridge (siehe Seite 17)
Docking-Geräte (siehe Seite 17)
Katalog (siehe Seite 18)
Logon-Shield für Windows-Betriebsumgebungen (siehe Seite 18)
Software Management Packager (siehe Seite 19)
Desktop Management Script Generator und Editor (siehe Seite 20)
Auswahl der Software Delivery-Komponenten
Die Auswahl und die Strukturierung der Software Delivery-Funktionen hängt davon ab,
wie Ihre Organisation konfiguriert ist und wie Sie die Verteilung der Software innerhalb
der Organisation steuern möchten.
Die Mindestimplementierung erfordert einen eigenständigen Domänen-Manager und
Agenten. Zusätzliche Scalability-Server können bereitgestellt werden, wenn RemoteNetzwerke verwaltet werden müssen oder mehr Software gleichzeitig bereitgestellt
werden muss. Sind größere Skalierbarkeit oder Autonomie der Domäne das Ziel, können
zusätzliche Domänen-Manager eingesetzt werden. Bei Verwendung mehrerer
Domänen-Manager kann ein Enterprise-Manager eingesetzt werden, der das gesamte
Software Delivery-Netzwerk zentral verwaltet.
Kapitel 2: Software Delivery-Funktionen 13
Softwarepaketbibliothek
Softwarepaketbibliothek
In der Softwarepaketbibliothek werden alle Softwareprogramme registriert und
gespeichert. Software, die nicht registriert ist, kann nicht verwaltet werden.
Softwarepaketbibliotheken können auf Enterprise-Managern, Domänen-Managern, und
Scalability-Servern gespeichert sein. Die Softwarepaketbibliothek speichert (unabhängig
vom beabsichtigten Betriebssystem des Programms) alle Programme, die an
Zielcomputer verteilt werden sollen, vorausgesetzt, der Datenträger für die Installation
des Programms kann vom Manager gelesen werden.
Um beispielsweise ein Linux-Programm bei einem Windows-basierten Manager zu
registrieren, muss sich das Linux-Programm auf einem Datenträger befinden, der von
dem Windows-Computer gelesen werden kann, auf dem sich der Manager befindet.
Domänen-Manager
Der Domänen-Manager ist die einzige obligatorische Managementebene. Er unterstützt
die Verwaltung von einzelnen Agenten und Scalability-Servern sowie der
entsprechenden Gruppen. Der Domänen-Manager ist für folgende Tasks verantwortlich:
■
Pflegen der Konfigurationsinformationen für die CA ITCM-Domäne
■
Konfigurieren der Sicherheit für die Administratoren, die eine Verbindung zum
Domänen-Manager herstellen können, und des Umfangs ihrer Berechtigungen für
jede Objektklasse.
■
Auslösen der Engine, um die im Scalability-Server gespeicherten Daten zu erfassen
■
Evaluieren und Erstellen von Jobcontainern, die anschließend an den ScalabilityServer gesendet werden
■
Empfangen der Ergebnisse für die Jobcontainer von den Scalability-Servern und
Agenten
■
Evaluieren der dynamischen Computergruppen
■
Evaluieren der Softwarerichtlinien
■
Evaluieren und Erstellen der Betriebssystem-Implementierungen
■
Replizieren der Elemente zwischen sich selbst und dem entsprechenden EnterpriseManager
Die derzeit vom Domänen-Manager unterstützten Betriebssystemumgebungen werden
in der auf CA Support verfügbaren Zertifizierungsmatrix aufgelistet.
Enterprise-Manager
Enterprise-Manager
Der Enterprise-Manager ist eine optionale Managementebene, die eine zentrale
Verwaltung von mehreren Domänen-Managern und Gruppen von Agenten und
Scalability-Servern ermöglicht. Der Enterprise-Manager ist für folgende Tasks
verantwortlich:
■
Sicherstellen der Sichtbarkeit und Steuerung des gesamten Enterprises, in dem
mehrere CA ITCM-Domänen implementiert wurden
■
Verwalten von Konfigurationsinformationen für das Unternehmen
■
Konfigurieren der Sicherheit für die Administratoren, die eine Verbindung zum
Enterprise-Manager herstellen können, und des Umfangs ihrer Berechtigungen für
jede Objektklasse
■
Kommunizieren mit einem Domänen-Manager, um Jobs zu übertragen und die
Ergebnisse dieser Jobs zu erfassen
Die derzeit im Enterprise-Manager unterstützten Betriebssystemumgebungen werden in
der auf CA Support verfügbaren Zertifizierungsmatrix aufgelistet.
Scalability-Server
Ein Scalability-Server ist eine optionale verwaltungsfreie Ebene, die bei einer großen
Anzahl von Agenten verwendet wird. Dies gilt z. B. für Remote-Netzwerke, die
durch ein WAN getrennt sind. Er lässt sich als ein Fanout-Verfahren zur Optimierung der
Netzwerknutzung erklären.
Ein Software Delivery-Scalability-Server hat eine Softwarepaketbibliothek (StagingBibliothek), in der Softwarepakete dauerhaft gespeichert werden können. So kann das
wiederholte Versenden eines Pakets über das Netzwerk bei jeder Anforderung durch
einen Agenten vermieden werden. Anstelle einer direkten Kommunikation zwischen
den einzeln verwalteten Endsystemen (Agenten) und einem einzelnen Manager kann
die Belastung auf mehrere Scalability-Server verteilt werden.
Software Delivery-Agent
Scalability-Server verwenden eine Dateispeicherdatenbank als lokales Repository, um
die Informationen zu speichern, die für die Kommunikation der Agenten benötigt
werden. In einer Scalability-Server-Minimalinstallation besteht die Dateidatenbank aus
einem Wörterbuch registrierter Agenten und dem Basisinventar, zu denen diese
Agenten Berichte erstellen.
Zu einem Scalability-Server gehört auch der Boot-Server, der für die Bereitstellung des
Betriebssystems benötigt wird.
Hinweis: Mit virtuellen Anwendungen funktioniert der Scalability-Server auch als
Streaming-Server für Pakete mit virtuellen Anwendungen, die per Datenstrom an die
Zielrechner, auf denen das Windows-Betriebssystem ausgeführt wird, übertragen
werden. Weitere Informationen finden Sie unter Registrieren virtueller Anwendungen
(siehe Seite 53) und Liefern virtueller Anwendungen (siehe Seite 117).
Die derzeit vom Scalability-Server unterstützten Betriebssystemumgebungen werden in
der auf CA Support verfügbaren Zertifizierungsmatrix aufgelistet.
Software Delivery-Agent
Der Software Delivery-Agent ist auf einem Zielcomputer erforderlich, wenn der
Computer von Software Delivery-Funktionen verwaltet werden soll. Der SD-Agent stellt
Softwareinstallationsdienste und das Basis-Hardwareinventar bereit. Der WindowsAgent unterstützt auch die Benutzerprofilverwaltung.
Der SD-Agent unterstützt Folgendes:
■
Agenten für Linux und UNIX
■
Proxy-Agenten für Docking-Geräte
■
PC-Agenten
SD-Agenten können mit Hilfe der von CA ITCM zur Verfügung gestellten
Bereitstellungsverfahren, mit der CA ITCM-Installations-DVD oder mit früheren
Versionen von Software Delivery (Migration) eingerichtet werden.
Die derzeit vom SD-Agenten unterstützten Betriebssystemumgebungen werden in der
auf CA Support verfügbaren Zertifizierungsmatrix aufgelistet.
Die Software Delivery-Komponente unterstützt Windows Vista als
Betriebssystemumgebung für den Agenten. Aufgrund von Einschränkungen in Windows
Vistaim Hinblick auf die Ausführung von Benutzeroberflächen über einen WindowsDienst wurde der SD-Agent umgestaltet. Der SD-Agent kann erkennen, ob er auf einer
Windows Vista- oder Microsoft Server 2008-Umgebung ausgeführt wird und
entsprechend handeln. In Betriebsumgebungen ohne Windows Vista wird der SD-Agent
wie in früheren Versionen ausgeführt.
Software Delivery Agent Bridge
Software Delivery Agent Bridge
Die Software Delivery Agent Bridge (SD Agent Bridge) bietet Abwärtskompatibilität für
erweiterte und ältere Unicenter Software Delivery-Agenten (SD-Agenten) und enthält
eine allgemeine Legacy-Serverkomponente sowie die dazugehörigen
Prozesskomponenten und bestimmte Software Delivery-Komponenten
Die SD Agent Bridge-Unterstützung für erweiterte und ältere Unicenter SD-Agenten ist
vollständig in den Scalability-Server integriert. Es ist durch eine Richtlinie konfigurierbar,
und es kann als Scalability-Server-Thread von Software Delivery gestartet und gestoppt
werden.
Detaillierte Informationen, insbesondere zur Installation und Konfiguration, finden Sie
unter Verwenden der SD Agent Bridge (siehe Seite 151).
Docking-Geräte
Der Begriff "Docking-Gerät" bezeichnet einen Computertyp, der in Software Delivery
(SD) zur Beschreibung eines mobilen Geräts verwendet wird, das über einen "DesktopBegleitcomputer" mit der SD-Infrastruktur verbunden wird. Das Docking-Gerät steht für
das mobile Gerät, obwohl die Adresse des Begleitcomputers verwendet wird.
Ein mobiles Gerät ist mit dem Begleitcomputer (beispielsweise über die serielle
Schnittstelle) verbunden. Der Begleitcomputer ist mit einem SD-Agenten ausgestattet.
Die Jobprüfung wird auf dem Begleitcomputer initiiert, wenn das Gerät mit dem SDAgenten verbunden wird. Dadurch wird das mobile Gerät (dargestellt durch ein DockingGerätesymbol) auf dem mit dem SD-Agenten verbundenen Domänen-Manager ein
Mitglied der Gruppe "Alle Computer und Benutzer"
Software, die auf einem Docking-Gerät installiert werden soll, muss zuerst in der
Softwarepaketbibliothek registriert werden. Dabei handelt es sich in der Regel um
Software von Drittanbietern.
Jobs werden auf einem mobilen Zielgerät ausgeführt, so lange es mit dem SD-Agenten
verbunden ist. Wenn das Gerät an einen anderen Standort gebracht wird und dort an
einen SD-Agent-Computer angeschlossen wird, der zu demselben Domänen-Computer
gehört wie der vorherige SD-Agent, werden alle ausstehenden Jobs zum Zeitpunkt der
Verbindung ausgeführt, wenn der Benutzer auch für diesen anderen Desktop-Computer
konfiguriert ist.
Katalog
Die derzeit unterstützten Proxy-Agent-Plattformen werden in der auf CA Support
verfügbaren Zertifizierungsmatrix aufgelistet.
Informationen über das Aktivieren eines Docking-Geräts unter Windows finden Sie im
Abschnitt Aktivieren eines Docking-Geräts unter Windows in der Installation von CA
ITCM im Implementierungshandbuch.
Katalog
Der Katalog ist eine optionale Schnittstelle für den Benutzer, in der
Softwareanforderungen für den Domänen-Manager erteilt werden. Über den Katalog
können Benutzer Software, die vom Administrator als optional eingestuft wurde, mit
Hilfe des Software Delivery-Netzwerks und seiner Konfigurationsfunktionen auf ihren
eigenen Rechnern installieren.
Logon-Shield für Windows-Betriebsumgebungen
Das Logon-Shield stellt sicher, dass das System ungestört von Benutzeranmeldungen
Anwendungen installieren oder aktualisieren kann. Mit anderen Worten, ein aktiviertes
Logon-Shield verhindert, dass Benutzer sich bei einem Windows-Betriebssystem
anmelden können. Die Logon-Shield-Funktion steht für alle Windows NTBetriebsumgebungen und für Windows Vista zur Verfügung.
Da Microsoft die dem Betriebssystem Windows Vista zugrundeliegende Technologie
geändert hat, wurde die Logon-Shield-Funktion angepasst, um die Anforderungen von
Windows Vista zu erfüllen. In Umgebungen aus der Zeit vor Windows Vista basiert die
Funktionsweise von Logon-Shield auf dem Konzept der grafischen Identifikation und
Authentifizierung (GINA) von Microsoft, während sie in Windows VistaBetriebsumgebungen das Credential Provider Filtering nutzt. Auf den Zielsystemen
unterscheidet sich die Benutzeroberfläche des Logon-Shields in Windows VistaUmgebungen leicht von der in Nicht-Windows Vista-Betriebsumgebungen.
Das Logon-Shield kann im DSM-Explorer über die Konfigurationsansicht für das LogonShield aktiviert und konfiguriert (siehe Seite 33) werden. Darüber hinaus kann das
Logon-Shield beim Einrichten eines Softwareverteilungsjobs implizit aktiviert (siehe
Seite 34) werden.
Hinweis: Wenn das Logon-Shield zum ersten Mal auf-Systemen aktiviert wird, die älter
als Windows Vista sind, wird vor der Ausführung des ersten Jobs Logon-Shield-Schutz
ein Systemneustart initiiert.
Software Management Packager
Software Management Packager
Mit Hilfe des Software Management Packager (Packager) können Sie aus Software und
Daten Produktpakete in einem CA Technologies-spezifischen Paketformat erstellen, die
dann auf den Zielcomputern installiert werden können.
Der Packager steht für Windows-, Linux- und UNIX-Betriebsumgebung zur Verfügung.
Die aktuellen Betriebssystem-Umgebungstypen und durch den Packager unterstützten
Versionen finden Sie auf CA Support unter in der Zertifizierungsmatrix.
Packager für Windows
Die Packager-Komponente für Windows befindet sich auf einem separaten dedizierten
Paketcomputer. Auf dem Paketcomputer müssen lediglich das Betriebssystem und der
Packager installiert sein. Als Betriebssysteme kommen auf dem Paketcomputer
Windows NT oder Windows Vista in Frage.
Während des Paketprozesses wird das zu packende Produkt auf dem Betriebssystem
dieses Paketcomputers installiert. Sie können Produktdateien, Installationsparameter
und andere notwendige Änderungen angeben. Der Packager zeichnet diese und alle
anderen Informationen auf, die für eine erfolgreiche Installation des Softwarepakets
erforderlich sind, und generiert ein installierbares Softwareimage.
Das installierbare Produkt (Image) wird im SXP-Paketformat gepackt.
Wichtig! Das Softwareimage kann nur auf Zielcomputern installiert werden, auf denen
derselbe Betriebssystemtyp ausgeführt wie auf dem Paketcomputer während des
Paketprozesses.
Packager für Linux und UNIX
Für die Packager-Komponente für Linux und UNIX ist kein separater Paketcomputer
erforderlich. Sie kann auf einem beliebigen Linux- oder UNIX-Computer ausgeführt
werden.
Während des Paketprozesses wird das zu packende Produkt, einschließlich aller Dateien
und Parameter, in einer Prototypdatei definiert. Dies ist über die PackagerBenutzeroberfläche oder die Befehlszeile möglich. Mit Hilfe dieser Prototypdatei wird
das installierbare Produkt (Image) konstruiert.
Bei dem Paketformat des Produktes handelt es sich um das PIF-Paketformat (Product
Interchange Format).
Desktop Management Script Generator und Editor
Desktop Management Script Generator und Editor
Der Desktop Management Script Generator ist ein Tool, mit dem Sie
Konfigurationsänderungen für ein installiertes Produkt aufzeichnen können, z. B.
Registrierungsänderungen. Der Script Generator erstellt ein Snapshot des Computers
und erzeugt ein Image- und Installationsskript. Dieses Skript kann dann in der
Softwarepaketbibliothek registriert und auf Zielcomputern installiert werden, auf denen
der Skript-Interpreter installiert ist. Desktop Management Script Generator ist nicht für
komplexe Produktinstallationen geeignet.
Mit dem Desktop Management Script Editor können Sie Skripte schreiben, die Syntax
prüfen, Fehler beheben und Skripte ausführen.
Kapitel 3: Implementierung
Zum besseren Verständnis der Software Delivery-Funktionen und -Komponenten enthält
dieses Kapitel ein Implementierungsmodell sowie ein Szenario für das Installieren und
Entfernen von Software.
Konfigurieren der Manager-Hierarchie (siehe Seite 21)
Verwendung von Scalability-Servern (siehe Seite 26)
Software-Delivery-Verbesserungen für die interaktive Softwarebereitstellung unter
Windows Vista oder höher (siehe Seite 28)
Konfigurieren der Manager-Hierarchie
Wenn Sie eine zentralisierte Verwaltung benötigen und die Anzahl der verwalteten
Systeme nicht die empfohlenen Grenzwerte überschreitet, die sich nach der Größe
eines Domänen-Managers richten, dann wählen Sie eine einzelne Domäne.
Wenn Sie eine zentralisierte Verwaltung benötigen und die Anzahl der verwalteten
Systeme die empfohlenen Grenzwerte überschreitet, die sich nach der Größe eines
Domänen-Managers richten, dann wählen Sie ein Enterprise mit mehreren Domänen.
Es sind auch andere Gründe denkbar, die für den Enterprise-Ansatz sprechen, selbst
wenn sich eine einzelne Domäne für die Verwaltung aller verwalteten Systeme eignen
würde. So könnte die Anforderung bestehen, dass die Administratoren einzelner
Standorte einen Vollzugriff auf die verwalteten Systeme an diesem Standort haben
müssen. In diesem Fall würde sich eine Domäne pro Standort empfehlen. Ein gewisser
Grad an lokaler Autonomie lässt sich erzielen, indem die CA ITCM-Sicherheitsverfahren
dazu genutzt werden, das Eigentum von Agenten und anderen Elementen in der
Management-Datenbank eines Domänen-Managers auf mehrere Administratoren
aufzuteilen.
Kapitel 3: Implementierung 21
In den meisten Szenarien lohnt es sich, einen Enterprise-Manager zu installieren, wenn
mehrere Domänen verwendet werden. Einer der Vorteile ist die EnterpriseBerichterstellung. Selbst wenn die Verwaltung von Agenten ausschließlich von den
Domänenadministratoren ausgeführt wird, kann die Erstellung von
unternehmensweiten Berichten zu allen Agenten und der Software im Unternehmen
wünschenswert sein. Ein weiterer Vorteil der Enterprise-Installation ist die Integration
von CA ITCM und anderer CA Technologies-Software, wie CA Service Desk Manager und
Unicenter Asset Portfolio Management. Viele Unternehmen bevorzugen ein zentrales
Help Desk oder eine zentrale Beschaffungsfunktion, selbst wenn die Administration der
verwalteten Systeme mit Hilfe von mehreren Domänen auf Standortadministratoren
aufgeteilt ist. Wir empfehlen in solchen Umgebungen den Einsatz einer EnterpriseLösung, um maximalen Nutzen aus der Integration der Produkte ziehen zu können.
Beachten Sie Folgendes: Wenn ein einzelne Domäne genügt, ist eine Produktintegration
auch auf Domänenebene möglich.
Bei der Erstellung einer Verteilungsstruktur stehen die folgenden
Konfigurationsoptionen zur Verfügung:
■
Ein Domänen-Manager mit einem lokalen Administrator
■
Ein Enterprise-Manager mit lokalen Administratoren
■
Ein Enterprise-Manager ohne lokale Administratoren
Domänenimplementierung
Bei einer Domänenimplementierung steuert der Domänen-Manager die Verteilung der
Software an einen oder mehrere Agenten. Eine Domäne besteht aus dem DomänenManager und den über ein Netzwerk mit diesem Manager verbundenen Computern. In
der Regel befinden sich bei einer Domänenimplementierung alle Agenten am selben
Standort und sind über ein lokales Netzwerk (LAN) mit dem Manager verbunden, wiw in
der folgenden Abbildung gezeigt:
Wenn der Domänen-Manager ohne einen Enterprise-Server eingesetzt wird, wird er als
autonomer (eigenständiger) Domänen-Manager bezeichnet.
Vorteile eines autonomen Domänen-Managers
Der autonome Domänen-Manager eignet sich hervorragend, wenn sich alle
verwalteten Computer im selben logischen Netzwerk befinden und die
Gesamtanzahl der Computer innerhalb des von der Managergröße bestimmten
Bereichs liegt. In einer solchen Situation vermeidet diese Konfiguration die
Inanspruchnahme unnötiger Infrastruktur und Hardware, ohne dass der Vorteil der
Verwaltbarkeit und der Einheitlichkeit verloren geht, den die Software DeliveryFunktionalität bietet.
Nachteile eines autonomen Domänen-Managers
Wenn Ihre Organisation aus mehreren Domänen besteht, führt die Verwendung
von autonomen Strukturen an jedem Standort zu einer Umgehung der zentralen
Steuerung, die bei einer Verwaltung mehrerer Domänen über einen EnterpriseManager gegeben wäre. Domänen-Manager können nicht mit Hilfe der Software
Delivery-Funktionalität Software untereinander verteilen.
Enterprise mit einer Implementierung von lokalen Administratoren
Diese Systemkonfiguration besteht aus einem Enterprise-Manager und mehreren
Domänen-Managern (Domänen), wobei jeder Domänen-Manager von seinem eigenen
lokalen Administrator verwaltet werden kann.
Die folgende Abbildung zeigt ein Beispielszenario einer Enterprise-Implementierung mit
lokalen Administratoren:
In diesem Implementierungsszenario bietet der an mehrere Domänen-Manager
angeschlossene Enterprise-Manager zentrale Steuerungsmöglichkeiten für ein großes
System mehrerer über ein WAN verbundener LAN-Netzwerke.
Der Enterprise-Administrator verteilt Software an die Domänen-Manager. Die lokalen
Administratoren installieren und verwalten die Elemente auf den Computern ihrer
Domäne. Auf diese Weise bilden lokale Administratoren eine zusätzliche Ebene der
Steuerung von Software-Installation und -Pflege für die einzelnen Domänen.
Vorteile eines Enterprise-Managers mit lokalen Administratoren
Auch wenn diese Systemkonfiguration zentral gesteuert wird, können DomänenManager den Verteilungsprozess für einzelne Computer anpassen und somit
unabhängig vom Enterprise-Manager operieren.
Nachteile eines Enterprise-Managers mit lokalen Administratoren
Da der lokale Administrator Software ohne Eingriff seitens des EnterpriseAdministrators verteilen kann, schränkt diese Struktur die zentrale Steuerung ein.
Der Enterprise-Administrator behält jedoch alle Überwachungsfunktionen und kann
Anweisungen zum Entfernen nicht autorisierter Software versenden.
Enterprise ohne eine Implementierung von lokalen Administratoren
Diese Systemkonfiguration besteht aus einem Enterprise-Manager und mehreren
Domänen-Managern (Domänen), wobei die Domänen-Manager ausschließlich vom
Enterprise-Administrator über den Entrpise-Manager verwaltet werden.
Die folgende Abbildung zeigt ein Beispielszenario einer Enterprise-Implementierung
ohne lokale Administratoren:
In diesem Implementierungsszenario bietet der an mehrere Domänen-Manager
angeschlossene Enterprise-Manager zentrale Steuerungsmöglichkeiten für ein großes
System mehrerer über ein WAN verbundener LAN-Netzwerke.
Verwendung von Scalability-Servern
Der Enterprise-Administrator verteilt Software an die Domänen-Manager, verwaltet
Software in den Domänenbibliotheken und kann Software auf den Zielcomputern
installieren und warten. Auf diese Weise ermöglicht die Implementierung eines
Enterprise-Managers mit mehreren Domänen ohne lokale Administratoren eine
vollständig zentralisierte Kontrolle der Software, die auf den Computern in den
Domänen installiert ist.
Vorteile eines Enterprise-Managers ohne lokale Administratoren
Mit dieser Systemkonfiguration können alle Domänen-Manager und Zielcomputer
von einem einzigen Standort aus gesteuert werden. Eingriffe lokaler
Administratoren in den einzelnen Domänen erübrigen sich.
Nachteile eines Enterprise-Managers ohne lokale Administratoren
Bei dieser Systemkonfiguration ist eine an individuelle Anforderungen angepasste
Konfiguration der einzelnen Domänen-Manager nicht möglich.
Scalability-Server verbessern die Skalierbarkeit und die Leistung. Zum Lieferumfang des
Domänen-Managers gehört ein Scalability-Server. Zusätzliche Scalability-Server sind
optional erhältlich.
Die folgende Abbildung zeigt ein typisches Szenario für den Einsatz von ScalabilityServern in einem Netzwerk:
Scalability-Server werden an jedem Remote-Standort oder an jedem Netzwerkstandort
eingesetzt, um überflüssigen Netzwerkverkehr im WAN zu vermeiden. Da außerdem die
Softwarepakete dauerhaft in den Softwarebibliotheken der Scalability-Server
gespeichert sind, müssen nur Steuerungsdaten im WAN übertragen werden. Am Anfang
kann man die Bereitstellung der Softwarepakete für die Remote-Bibliotheken über das
WAN vornehmen, aber die lokal Registrierung wird auch unterstützt, wenn die WANVerbindungen sehr langsam sind.
Einer der wichtigsten Gründe für den Einsatz von Scalability-Servern ist die Verbreitung
über einen großen geografischen Raum. Aber es gibt auch andere Faktoren, z. B.
Bereitstellungsfenster und Bibliothekszugriffsmethoden, die bei der Planung eines
Software Delivery-Netzwerks zu berücksichtigen sind.
■
Bereitstellungsfenster:
Das Bereitstellungsfenster beschreibt den maximal zulässigen Zeitraum für die
Bereitstellung und Ausführung eines bestimmten Softwarepaketes auf allen
verwalteten Systemen. Das Bereitstellungsfenster wird vom Software DeliveryBenutzer und nicht von CA Technologies festgelegt.
■
Methoden für den Zugriff auf Softwarebibliotheken:
Zu berücksichtigen ist auch, welche Bibliothekszugriffsmethode von den Agenten
verwendet werden soll. Die Wahl der Zugriffsmethode beeinflusst die Belastung
von Scalability-Server und Netzwerk. Bei der Konfiguration des Scalability-Servers
kann die zulässige Anzahl der gleichzeitig ausgeführten Softwarejobs festgelegt
werden.
Software-Delivery-Verbesserungen für die interaktive Softwarebereitstellung unter Windows Vista oder höher
Software-Delivery-Verbesserungen für die interaktive
Softwarebereitstellung unter Windows Vista oder höher
Wenn Sie ein Softwarepaket für einen Windows-Agenten bereitstellen, wird der
SYSTEM-Zusammenhang durch das Installationsprogramm gestartet.
In Windows-Versionen vor Vista wurden alle Dienste in Sitzung 0 ausgeführt, und die
Anwendungen wurden im SYSTEM-Zusammenhang gestartet. Dies stellte ein
Sicherheitsrisiko dar. Ab Windows Vista und höher isoliert das Betriebssystem Dienste in
Sitzung 0 und führt Anwendungen in anderen Benutzersitzungen aus. Dienste sind vor
Angriffen geschützt, die aus dem Anwendungscode hervorgehen. Ab Windows Vista und
höher ist die Erkennung interaktiver Dienste vorhanden. Hiermit wird bei der
Ausführung erkannt, ob eine Anwendung eine Benutzeroberfläche anzeigen muss,
woraufhin das Dialogfeld "Erkennung interaktiver Dienste" angezeigt wird, um zur
Sitzung 0 zu wechseln bzw. fortzufahren. Weitere Informationen zur Erkennung
interaktiver Dienste finden Sie in der Microsoft-Dokumentation.
Ab Windows Vista und höher führte die Änderung des Designs der Erkennung
interaktiver Dienste zu einem Problem bei interaktiven Softwareinstallationen, die eine
Benutzereingabe erfordern.
Wenn die bereitgestellte Software über folgende Merkmale verfügt, verbleibt die
Installation in Sitzung 0 und erwartet Benutzereingaben:
■
Die Software ist interaktiv.
■
Die Software ist nicht für Sitzungen konzipiert.
■
Die Erkennung interaktiver Dienste ist deaktiviert.
Da keine Eingabebenutzeroberfläche angezeigt wird, erfolgt eine Zeitüberschreitung des
Software Delivery-Jobs.
Der Software Delivery-Agent hat dieses Szenario seit CA ITCM r12 SP1 unterstützt,
indem die Erkennung interaktiver Dienste aktiviert wurde, die Benutzereingaben
ermöglichten, bevor der Dienst vor dem Beenden wieder deaktiviert wurde.
Um sicherzustellen, dass die interaktive Software installiert werden kann, selbst wenn
die Software nicht für Sitzungen konzipiert ist, und um die Abhängigkeit der Erkennung
interaktiver Dienste zu entfernen, bietet <asdm> nun eine Option zum Angeben, dass
ein registriertes oder bereitgestelltes Softwarepaket interaktiv ist und eine
Benutzerinteraktion auf dem Agentencomputer erfordert.
Der Administrator wählt zum Verwenden dieser Funktion die Option
"Benutzerinteraktion aktivieren (nur WinLH)" in den Prozeduroptionen aus, wenn ein
Softwarepaket registriert wird oder wenn in den Jobeinstellungen ein Paket
bereitgestellt wird. Der Agent startet das Softwareinstallationsprogramm in
Benutzersitzungen, die derzeit angemeldet und aktiv sind, und wird auch im SYSTEMZusammenhang gestartet.
Hinweis: Diese Funktion hilft Ihnen dabei, interaktive Anwendungen zu installieren,
gefährdet jedoch die Isolationsfunktion, die Microsoft bereitstellt, um die Sicherheit zu
erhöhen. Verwenden Sie diese Funktion mit Vorsicht.
Für vor dem DM-Upgrade versiegelte Softwarepakete können Sie über eine Option die
Benutzerinteraktion (selbst im versiegelten Status) aktivieren, solange Sie nicht die
Option "Benutzeranmeldung während Jobausführung nicht zulassen" auswählen.
Sind keine Benutzer angemeldet, wartet der SD-Agent darauf, dass sich ein Benutzer
anmeldet und führt dann den Job aus.
Diese Funktion verwendet die folgenden Konfigurationsparameter in bestimmten
Situationen, die sich auf Logon-Shield und Neustart- bzw. Abmeldevorgänge beziehen.
Diese Parameter befinden sich unter "DSM" > "Software Delivery" > "Agent":
Dialogaufträge: In Benutzersitzung starten unter Windows Server-BS-Familie
Gibt die Sitzung an, in der die Jobs auf Agenten ausgeführt werden, die Windows
Vista oder höher ausführen.
Werte:
■
WAHR: Auf Grundlage der Jobeigenschaft "Benutzerinteraktion aktivieren
(nur WinLH)", wird der Job in der angemeldeten Benutzersitzung
ausgeführt. Dieser Parameter gilt nur für Jobs, die auf Computeragenten
bereitgestellt sind. Dieser Parameter wirkt sich nicht auf Jobs aus, die auf
Benutzerprofilen und für nicht interaktive Jobs bereitgestellt wurden.
■
FALSCH: Der Job wird in Sitzung 0 ausgeführt.
Standard: WAHR.
Beschränkungen:
■
Dieser Parameter gilt nur für Jobs, die auf Computeragenten bereitgestellt
werden.
■
Dieser Parameter wirkt sich nicht auf nicht interaktive Jobs oder Jobs aus,
die auf Benutzerprofilen bereitgestellt wurden.
Dialogaufträge: Logon-Shield-Modus im Konfliktfall unter Windows Server-BS-Familie
ignorieren
Gibt das SD-Agentenverhalten an, wenn der Logon-Shield-Status Warten, bis der
Benutzer sich abmeldet, bevor der Job ausgeführt wird oder Abmeldung des
Benutzers erzwingen, bevor der Job ausgeführt wird aufweist und die
Jobeigenschaft Benutzerinteraktion aktivieren (nur WinLH) auf WAHR festgelegt ist.
Werte:
■
WAHR: Die Jobeigenschaft unterdrückt das Logon-Shield-Verhalten.
■
FALSCH: Ein Konflikt wird entdeckt, und Jobs schlagen mit einer
entsprechenden Fehlermeldung fehl.
Standard: FALSCH
Dialogaufträge: Verbleibende Jobs unter Windows Server-BS-Familie in einem
Container des Typs 'Keine Verknüpfung' verschieben
Gibt die folgenden Aktionen an:
Werte:
■
WAHR: Nehmen Sie eine zeitliche Verschiebung sämtlicher Jobs nach dem
ersten Job bei festgelegter Option "Benutzerinteraktion aktivieren (nur
WinLH)" vor.
■
FALSCH: Nehmen Sie eine zeitliche Verschiebung der interaktiven Jobs in
den Container vor, und führen Sie alle nicht interaktiven Jobs aus.
Standard: WAHR.
Beschränkungen: Dieser Parameter gilt, wenn keine Benutzer am Computer
angemeldet sind und Dialogaufträge: In Benutzersitzung unter Windows Server-BSFamilie ausführen auf WAHR festgelegt ist.
Kapitel 4: Konfigurieren von Software
Delivery
Sie können die Software Delivery-Funktionalität nach der Installation konfigurieren.
Im Allgemeinen werden Komponenten wie Manager, Scalability-Server und Agenten von
Konfigurationsrichtlinien verwaltet. Eine Konfigurationsrichtlinie ist eine Reihe von
Parametern, die das Verhalten einer bestimmten Komponente bestimmen.
Software Delivery, Richtliniengruppe (siehe Seite 31)
Ändern der Konfigurationsrichtlinien (siehe Seite 32)
Konfiguration von Softwarejobs (siehe Seite 32)
Konfiguration von Scalability-Servern (siehe Seite 32)
Konfiguration von Logon-Shield (siehe Seite 33)
Software Delivery, Richtliniengruppe
Mit der Richtliniengruppe "software delivery" können Sie die bestehenden
Richtlinieneigenschaften für die Software Delivery-Verwaltung anzeigen oder
bearbeiten.
Die Richtliniengruppe "software delivery" enthält die folgenden Ordner.
■
Agent
■
Dateikomprimierung
■
Dateiübertragung
■
Manager
■
Scalability-Server
■
Freigegeben
■
Software Management
Kapitel 4: Konfigurieren von Software Delivery 31
Ändern der Konfigurationsrichtlinien
Ändern der Konfigurationsrichtlinien
Konfigurationsrichtlinien können im DSM-Explorer über die Knoten "Systemsteuerung",
"Konfiguration", "Konfigurationsrichtlinien", "Standardcomputerrichtlinie" und "DSM"
angezeigt und geändert werden.
Wenn Sie eine Konfigurationsrichtlinieneinstellung ändern möchten, doppelklicken Sie
auf die betreffende Richtlinie. Das Dialogfeld "Eigenschaften von Einstellung" wird
angezeigt, in dem Sie die Konfigurationsrichtlinie ändern können.
Weitere Informationen zur Konfiguration oder Bearbeitung von
Konfigurationsrichtlinien für Software Delivery finden Sie im Abschnitt
"Konfigurationsrichtlinie" in der DSM-Explorer-Hilfe.
Konfiguration von Softwarejobs
Der Ordner "Konfiguration" in der Systemsteuerung enthält den Unterordner
"Softwarejobmanagement", in dem Sie die Tasks "Jobbereinigung", "Jobverarbeitung"
und "Neuinstallation nach Absturz (RAC)" konfigurieren können.
Wenn Sie mit der rechten Maustaste auf einen Zielcomputer oder eine Gruppe klicken,
können Sie weitere Jobeigenschaften wie z.#160;B. "Jobausführungskalender",
"Download-Methode" und "RAC-Richtlinie" auswählen und konfigurieren. Wenn Sie im
Kontextmenü die Option "Eigenschaften" auswählen, können Sie die
Konfigurationseinstellungen festlegen.
Konfiguration von Scalability-Servern
Ein Scalability-Server besteht aus einer Reihe von Systemprozessen, die im Hintergrund
ausgeführt werden. Administratoren können den Scalability-Server starten und beenden
sowie seine Konfiguration ändern.
Sie können den Scalability-Server mit der Konfigurationsfunktion im DSM-Explorer des
Managers oder über die Application Framework (CAF)-Befehlszeile konfigurieren. Zum
Beispiel:
cserver config -h neuer_manager
Hinweis:Wenn CA Common Services (CCS) installiert sind, wird CCS beim Verschieben
des Domänen-Managers eines Scalability-Servers erneut so konfiguriert, dass auf den
neuen Manager-Computer verwiesen wird. Um sicherzustellen, dass CCS-Werte nicht
verändert werden, wenn man den Server erneut registriert, verwenden Sie den Befehl
"cserver" mit der Option "-i" statt der Option "-h".
Konfiguration von Logon-Shield
Die Logon-Shield-Konfiguration wird von der Komponente "Allgemeine Konfiguration"
gesteuert. Über die angepasste Benutzeroberfläche, die Konfigurationsansicht für
Logon-Shield, können Sie die Daten der Konfigurationsrichtlinie einstellen und
modifizieren.
Wenn Sie die Konfigurationsansicht für Logon-Shield vom DSM-Explorer aus starten,
wird das Dialogfeld für die Logon-Shield-Konfiguration angezeigt.
Sie können den Betriebsmodus für Logon-Shield auswählen, der die
Anmeldebedingungen, unter der Software Delivery-Jobs (SD-Jobs) ausgeführt werden,
sowie den Installationsstatus des Logon-Shields festlegt.
Mögliche Betriebsmodi für Logon-Shield sind:
Logon-Shield nicht installiert
Besagt in einer Windows Vista-Betriebsumgebung, dass die "Credential Provider
and Filter"-COM-Module für das Logon-Shield nicht registriert sind. In einer nichtWindows Vista-Umgebung ist sxpgina.dll nicht installiert.
Keine Einschränkung bei Jobausführung
Legt fest, dass das Logon-Shield nicht aktiviert wird, wenn ein SD-Job ausgeführt
wird.
Abmeldung des Benutzers erzwingen, bevor der Job ausgeführt wird
Legt fest, dass der Benutzer gezwungen wird, sich abzumelden, wenn die
Ausführung eines SD-Jobs vorgesehen ist. Das Logon-Shield ist während der
Ausführung eines Jobs aktiviert.
Jobdefinierte Bedingung anwenden
Legt fest, dass die Option "Benutzeranmeldung während Jobausführung nicht
zulassen", die der Administrator während der Einrichtung des SD-Jobs aktiviert hat,
angewendet wird. Ist der Betriebsmodus "Jobdefinierte Bedingung anwenden"
ausgewählt, wird der Benutzer gezwungen, sich abzumelden, wenn ein Job auf
seine Ausführung wartet und das Logon-Shield während der Ausführung eines Jobs
aktiviert ist.
Warten, bis der Benutzer sich abmeldet, bevor der Job ausgeführt wird
Legt fest, dass der Benutzer nicht gebeten wird, sich abzumelden, wenn die
Ausführung eines SD-Jobs aussteht. Allerdings wird der Job erst ausgeführt,
nachdem sich der Benutzer abgemeldet hat. Das Logon-Shield ist während der
Ausführung eines Jobs aktiv.
Warten, bis der Benutzer sich anmeldet, bevor der Job ausgeführt wird
Gibt an, dass ausstehende SD-Jobs nur dann ausgeführt werden, wenn ein Benutzer
angemeldet ist.
Um im Fall einer Störung eine ständige Blockade des Systems zu vermeiden, können Sie
den Zeitraum angeben, nach dessen Ablauf die Sperrung des Systems aufgehoben
werden soll. Die "Maximale Blockierungsdauer" definiert den maximalen Zeitraum in
Minuten, in dem Anmeldungen verhindert werden. Dieser Parameter wurde in früheren
Versionen bereits per Remote-Zugriff verwaltet.
In Windows Vista- und neueren Betriebsumgebungen sollten Sie das Logon-Shield
unbedingt mit den spezifischen Windows-Sicherheitsoptionen ausführen. Das LogonShield wendet die Windows-Sicherheitsoptionen immer dann an, wenn es aktiviert wird,
vorausgesetzt, im Dialogfeld für die Logon-Shield Konfiguration ist die Option
"Windows-Sicherheitsoptionen anwenden" aktiviert. The Logon-Shield-Funktion für die
Anwendung der Windows-Sicherheitsoptionen wirkt sich nicht auf Betriebsumgebungen
vor Windows Vista aus.
Um die spezifischen Windows-Sicherheitsoptionen auszuwählen, klicken Sie im
Dialogfeld für die Logon-Shield-Konfiguration auf die Schaltfläche "Einstellungen". Das
Dialogfeld für die Windows-Sicherheitsoptionen wird geöffnet. Hier können Sie folgende
Windows-Richtlinien aktivieren (bzw. deaktivieren):
STRG+ALT+ENTF deaktivieren
Diese Windows-Richtlinie legt fest, ob Strg+Alt+Entf gedrückt werden muss, bevor
sich ein Benutzer anmelden kann. Ist diese Richtlinie deaktiviert, muss ein Benutzer
Strg+Alt+Entf drücken, bevor er sich bei Windows anmeldet.
Sie sollten diese Richtlinie unbedingt deaktivieren, wenn Sie das Logon-Shield
verwenden.
Herunterfahren ohne Anmeldung
Diese Windows-Richtlinie legt fest, ob ein man einen Computer herunterfahren
kann, ohne sich bei Windows angemeldet zu haben. Ist diese Richtlinie deaktiviert,
muss sich ein Benutzer bei Windows anmelden, bevor er den Computer
herunterfährt.
Sie sollten diese Richtlinie unbedingt deaktivieren, wenn Sie das Logon-Shield
verwenden.
Implizites Aktivieren von "Logon-Shield"
Neben dem expliziten Aktivieren und Konfigurieren von "Logon-Shield" mit der
Konfigurationsansicht für "Logon-Shield" im DSM-Explorer kann das "Logon-Shield" auch
implizit aktiviert werden, wenn ein Softwareverteilungsjob eingerichtet wird. Wählen
Sie auf der Registerkarte "Prozeduroptionen" des Dialogfelds "Jobs einrichten" die
Option Benutzeranmeldung während Jobausführung nicht zulassen (nur WinNT).
Wichtig! Das implizite Aktivieren von "Logon-Shield" funktioniert nur, solange die
Betriebsart des "Logon-Shields" den Wert "Jobdefinierte Bedingung anwenden"
aufweist oder der Betriebsmodusparameter lokal verwaltet wird. Hinweis: Der
Betriebsmodusparameter wird standardmäßig lokal verwaltet.
Kapitel 5: Verwenden von Software Delivery
In diesem Kapitel werden die Funktionen von Software Delivery und deren optimale
Verwendung ausführlich beschrieben.
Computer- und Benutzerprofile (siehe Seite 37)
Statische und dynamische Computergruppen (siehe Seite 38)
Abfragen (siehe Seite 40)
Verwenden der Softwarepaketbibliothek (siehe Seite 40)
Software und Prozeduren (siehe Seite 76)
Erneuern und Wiederherstellen fehlgeschlagener Installationen (siehe Seite 85)
Lieferung und Staging von Software (siehe Seite 86)
Liefern von virtuellen Anwendungen (siehe Seite 117)
Softwarekatalog (siehe Seite 128)
Verwalten von Computern (siehe Seite 131)
Benutzerdefinierte Administratormeldung (siehe Seite 148)
Verschieben der OSIM-Jobinformationen (siehe Seite 148)
Optimierung der gleichzeitigen Ausführung von Managern (siehe Seite 149)
Verschlüsselung und Drosselung für Übertragungen von Software-Paketen ohne NOS
(siehe Seite 149)
Optimierung von Datenbankaktualisierungen (siehe Seite 150)
Fahren Sie einen Computer nach dem letzten SD-Job herunter (siehe Seite 150)
Verwenden der SD Agent Bridge (siehe Seite 151)
Installieren von Wrapper-Paketen von externen Repositorys (siehe Seite 163)
Computer- und Benutzerprofile
Für Computer- und Benutzerprofile werden DSM-Agenten installiert, die über ein
Netzwerk mit dem Domänen-Manager verbunden sind. Ein Benutzerprofil ist eine
Instanz eines lokalen Kontos oder Domänenkontos auf einem bestimmten Computer.
Kapitel 5: Verwenden von Software Delivery 37
Statische und dynamische Computergruppen
Definieren von Computern
Ein Computer, auf dem der Software Delivery-Agent (SD-Agent) installiert ist, wird
automatisch beim Domänen-Manager registriert und in die Liste der Computer im DSMExplorer aufgenommen. Verwenden Sie die Funktion "Agent bereitstellen" von CA ITCM,
um die Agenten automatisch auf die Computer im Netzwerk zu übertragen.
Sie können Computer manuell definieren, d. h., dass neue Computer im Voraus
registriert und zugeordnet werden können. Wenn der SD-Agent auf dem Computer
installiert ist, kann er sofort Software empfangen. So kann die Einrichtungszeit für neue
Computer verkürzt werden. Bei der manuellen Definition eines neuen Computers geben
Sie die allgemeinen Angaben zu diesem Computer (wie Hostname, Netzwerkadresse,
Betriebssystem, Name des Scalability-Servers) mit Hilfe des Assistenten zum
Vorregistrieren neuer Computer ein. Sie können außerdem einen Jobkalender
definieren, in dem Wochentag, Datum und Uhrzeit für die Ausführung bestimmter Jobs
auf diesem Computer festgelegt werden können (Computereigenschaften).
Definieren von Benutzerprofilen
Benutzerprofile sind Anmeldekonten auf Computern mit einem WindowsBetriebssystem. Sie bestehen aus einer Kombination des Computernamens und des
Benutzerkontonamens. Benutzerprofile können Ziele für die Bereitstellung von
Softwarepaketen sein und ermöglichen die Installation von Software bei einem
bestimmten Benutzer anstatt bei allen Benutzern, wie es bei der Lieferung an einen
Computer der Fall ist.
Benutzerprofile werden definiert, wenn sich ein Computer beim Domänen-Manager
registriert. Die Registrierung ist standardmäßig nicht aktiviert. Wenn Sie die
Registrierung aktivieren möchten, erstellen Sie eine Konfigurationsrichtlinie, bei der
unter dem Parameter "DSM/Agent/Common Agent/Software Delivery/Unterstützte
Einheitstypen" die Option "Computer+Benutzerprofil" eingestellt ist.
Statische und dynamische Gruppen sind Erfassungen von Assets. Statische Gruppen
werden manuell erstellt, während dynamische Gruppen aus den Ergebnissen von
Abfragen aktualisiert werden. Alle diese Asset-Gruppen werden von allen Produkten in
CA ITCM gemeinsam verwendet.
Definieren von Computergruppen
Zur leichteren Verteilung von Softwarepaketen an eine größere Anzahl von Computern
können einzelne Computer zu Computergruppen zusammengefasst werden. Diese
Gruppen können auf der Grundlage bestimmter Kriterien, z. B. gleicher Attribute,
Verwendungszwecke oder Domänen eingeteilt werden.
Computergruppen werden üblicherweise auf dem Enterprise-Manager definiert, wenn
die Enterprise-Ebene verwendet wird, und dann im Domänen-Manager repliziert.
Selbstverständlich können Gruppen auch in Domänen definiert werden.
Eine neue Computergruppe können Sie im Dialogfeld "Neue Gruppe" erstellen. Mit den
im Dialogfeld "Neue Gruppe" verfügbaren Optionen können Sie festlegen, ob die
Gruppe abfragefähig d. h. dynamisch ist.
Dynamische Computergruppen
Sie können entweder eine vordefinierte Abfrage verwenden oder eine neue erstellen,
um eine dynamische Gruppe zu definieren. Die Software Delivery-Funktionen
verwenden Abfragen für Computer und Benutzerprofile.
Weitere Informationen zur Verwendung des Abfrage-Designers finden Sie in der OnlineHilfe von Software Delivery.
Verknüpfen, Aufheben von Verknüpfungen und Verschieben von Computern und
Computergruppen
Computer und Computergruppen können mit einer anderen statischen
Computergruppe verknüpft sein. Per Drag-and-Drop oder Kopieren und Einfügen
können Sie einen Computer einer definierten statischen Computergruppe mit einer
anderen statischen Computergruppe verknüpfen.
Sie können einen kopierten Computer nicht in eine Computergruppe auf der Ebene
einfügen, auf der er bereits Mitglied ist. Sie können jedoch den kopierten Computer auf
einer anderen Ebene in einer verschachtelten Computergruppe einfügen.
Sie können den Prozess "Aus Gruppe entfernen" verwenden, um eine vorher erstellte
Verknüpfung aufzuheben. Wenn Sie beispielsweise einen Computer aus einer statischen
Computergruppe entfernen, wird der ausgewählte Computer nicht mehr in der
Computergruppe angezeigt.
Das Entfernen aus einer Gruppe hat nicht dieselbe Bedeutung wie Löschen. Wenn Sie
einen Computer aus einer Computergruppe löschen, wird der betreffende Computer
nicht nur aus der Gruppe, sondern dauerhaft aus der CA ITCM-Datenbank gelöscht.
Abfragen
Computer und Computergruppen können auch in andere Computergruppen verschoben
werden. Wenn Sie einen Computer oder eine Computergruppe in eine andere Gruppe
verschieben, wird der Computer bzw. die Computergruppe Mitglied dieser Gruppe,
d. h., sie gehören der vorherigen Gruppe nicht mehr an. Systemordner können
nicht verändert werden. Sie können z. B. keinen Computer aus dem Ordner "Alle
Computer" verschieben.
Abfragen
Software Delivery verwendet die allgemeinen Abfragefunktionen von CA ITCM für
Datenbankabfragen und für das Definieren der Prozedurvoraussetzungen. Sie können
diese Richtlinien mit Hilfe des Dialogfelds "Abfrage-Designer" definieren. Weitere
Informationen über allgemeine Abfrageentwürfe finden Sie im "Administratorhandbuch
zu Asset Management".
Software Delivery verwendet manchmal die in Unicenter Software Delivery 4.0 erstellte
Abfragen, und erstellt in anderen Fällen Abfragen, die dem Unicenter Software
Delivery 4.0-Abfrageformat entsprechen. Diese Abfragen unterscheiden sich von den
Abfragen, die vom CA ITCM-Abfrage-Designer erstellt wurden. Weitere Informationen
zu Unicenter Software Delivery 4.0-Abfragen finden Sie im Anhang Importieren von
Unicenter Software Delivery 4.0-Abfragezeichenfolgen (siehe Seite 225).
Verwenden der Softwarepaketbibliothek
Bevor ein Softwareprogramm (Softwarepaket) mit Hilfe von Software Delivery (SD)
verteilt werden kann, muss es in der Softwarepaketbibliothek auf dem Enterprise- oder
Domänen-Manager über einen als Registrierung bezeichneten Vorgang definiert
werden.
Während des Registrierungsvorgangs werden Informationen zu den Softwareelementen
wie Name, Version, Quelle und Installationsprozeduren in der Datenbank definiert.
In diesem Abschnitt erhalten Sie Informationen zu folgenden Themen:
■
Vorbereiten von Programmen für die Registrierung in der Softwarepaketbibliothek
■
Registrieren von Softwareprogrammen
■
Registrieren von Paketen mit virtuellen Anwendungen
■
Definieren von Startprozeduren und benutzerspezifischen Skripten, den so
genannten Elementprozeduren, zur Installation, Aktivierung, Konfiguration und
Deinstallation von Programmen
■
Hinzufügen neuer Elementprozeduren zu Programmen, die bereits in der
Softwarepaketbibliothek registriert sind
■
Automatisches Registrieren von SD-Produkten in zusätzlichen SD-Netzwerken
■
Erstellen von Softwaregruppen zum Bündeln einzelner Softwarepakete
■
Erstellen von Kataloggruppen, um über den Softwarekatalog Software einer
bestimmten Gruppe von Benutzern zugänglich zu machen
Überblick über den Registrierungsvorgang
Beim Registrierungsvorgang wird ein Programm als Element in einer Domänen- oder
Enterprise-Bibliothek identifiziert und gespeichert. Bibliothekselemente können
zunächst in einer der Bibliotheken registriert werden, bevor sie auf die Zielcomputer
verteilt werden. Die folgende Abbildung zeigt die Registrierung eines Elements in einer
lokalen Bibliothek.
Die Prozedur für das Registrieren eines Programms ist für Enterprise- und DomänenManager identisch. Sie müssen jedoch Folgendes dabei beachten:
■
Software, die nur in der Bibliothek eines Domänen-Managers registriert ist, kann
nicht an Bibliotheken anderer Domänen-Manager oder an das Enterprise verteilt
werden.
■
Software, die nur in der Bibliothek des Enterprise-Managers registriert ist, kann erst
dann in einer Domäne installiert werden, wenn das Element unter Verwendung
eines Verteilungscontainers an den Domänen-Manager geliefert wurde.
■
■
Je nach Typ des Elements, das Sie definieren, ist der Registrierungsvorgang in
mehrere Schritte unterteilt.
■
Festlegen des Programms (Name, Version, Anbieter, Kommentare)
■
Festlegen der Quelle und Kopieren des Elements in die
Softwarepaketbibliothek.
■
Festlegen der Elementprozeduren, die zur Installation und zum Verwalten des
Programms verwendet werden
■
Speichern der Registrierung, d. h. Versiegeln des Softwareelements.
Nach der Registrierung eines Programms kann es verteilt werden.
Pakettypen für die Registrierung
Sie können folgende Softwarepakettypen in der Softwarepaketbibliothek registrieren:
■
Software-Pakete, die mit CA ITCM geliefert werden.
■
Aus Microsoft App-V- oder VMware ThinApp-Images erstellte Pakete mit virtuellen
Anwendungen
■
Software Management-Produkte in den Standardpaketformaten PKG und RPM (Red
Hat Package Manager) sowie in den CA Technologies-spezifischen Paketformaten
SXP (für Windows) und PIF (für Linux und UNIX), die mit Hilfe der Software
Management Packager von CA Technologies erstellt werden.
■
MSI-Pakete, die im Microsoft Installer-Paketformat generiert werden. (Weitere
Informationen finden Sie unter Registrieren von MSI-Paketen in der
Softwarepaketbibliothek (siehe Seite 65).)
■
Windows CE- und Palm-Pakete für Windows CE- und Palm-Geräte. (Weitere
Informationen finden Sie unter "Registrieren von Windows CE- und Palm-Paketen in
der Softwarepaketbibliothek (siehe Seite 71)".)
Beispiel für einen Registrierungsvorgang
Beispiel: Sie haben die folgenden neuen Softwareprodukte erhalten:
■
MemoPlus, ein Windows#160;NT-basiertes Textverarbeitungsprogrammpaket, das
von Mitgliedern des administrativen Supportteams zum Erstellen von Memos,
Briefen usw. verwendet wird
■
MasterCalc, ein Linux-basiertes Buchhaltungsprogramm, das für die
Buchhaltungsgruppe in der Domäne JUPITER bestimmt ist
Bevor Sie diese Programme an die Domänen und Abteilungen verteilen können, müssen
sie zusammen mit den jeweiligen Installationsprozeduren in der Software-PaketBibliothek des Enterprise-Managers (oder in der Bibliothek des Domänen-Managers,
wenn Sie keinen Enterprise-Manager verwenden) registriert werden.
Da die Dateien für MasterCalc auf einem Bandgerät gespeichert sind, müssen die
erforderlichen Dateien zunächst ohne Verwendung von Software Delivery extrahiert
und in ein installierbares Format konvertiert werden (z. B. ein Festplattenverzeichnis).
Anschließend müssen Sie die entsprechenden Elementprozedurdateien erstellen und
das Programm vom Verzeichnis aus in der Softwarepaketbibliothek registrieren.
Elementprozeduren werden als eingebettete, hinzugefügte oder externe
Elementprozeduren registriert.
Hinweise zum Registrieren von Softwarepaketen
Die folgende Liste enthält wichtige Hinweise zur Registrierung von Software-Paketen:
■
Wenn Sie ein Softwarepaket in der Softwarepaketbibliothek registrieren, müssen
Sie über folgende Informationen verfügen:
Quelle
Speichermedium des Pakets (CD/DVD, Festplatte oder Verzeichnis)
Name und Version
Paketname, beispielsweise MemoPlus 3.0
Elementprozeduren
Prozeduren (ausführbare Dateien, Batch-Dateien, Befehlsdateien oder Skripte)
für die Installation, Konfiguration, Aktivierung und Deinstallation des
Programms. Sämtliche genannten Prozeduren müssen als Elementprozeduren
registriert sein.
■
Wenn Sie ein Software-Paket als eine neue Version registrieren, können Sie die
Funktion zum Senden der Delta-Verteilung von einem Enterprise-Manager auf
Domänen-Manager verwenden. Diese Funktion bewirkt, dass nicht das gesamte
Paket an einen Domänen-Manager gesendet wird, auf dem bereits die
Vorgängerversion des Pakets registriert ist. Sie lässt sich vor allem dann
nutzbringend einsetzen, wenn das Software-Paket aus der Packumgebung
exportiert und in die Produktionsumgebung importiert wird.
■
Das Benutzerkonto muss Schreibzugriff auf den Bibliothekspfad der Domäne haben
(..\SD\ASM\LIBRARY), um die Pakete in der Softwarepaketbibliothek zu registrieren.
■
Beim Speichern von Softwarepaketen in der Softwarepaketbibliothek verwendet CA
ITCM Pfadnamen, die anstelle einer vor Version r11 verwendeten Objekt-ID (12
Zeichen) eine UUID (40 Zeichen) enthalten. Die Folge davon ist, dass die
Registrierung eines Pakets einer früheren Version als r11, bei der die Länge des
Pfadnamens in der Softwarepaketbibliothek betriebssystembedingt fast die
maximal zulässige Länge hatte, fehlschlagen könnte.
Hinweis zu den Registrierungsinformationen
Die Registrierungsinformationen "reginfo" für ein in einer Softwarepaketbibliothek
registriertes Softwareelement ändern sich nie. Folgendes sollten Sie jedoch beachten:
Wenn Sie nach dem Registrieren eines Softwarepakets auf dem Enterprise-Manager
eine der im Folgenden aufgelisteten Informationen ändern, wird die Information beim
Verteilen des Softwarepakets zur Registrierung bei den Domänen-Managern zusammen
mit der ursprünglichen reginfo verteilt:
■
Kommentar für das Softwareelement
■
Kommentar für eine Prozedur im Softwareelement
■
Standardmäßig ausgewählte Prozedur für Jobs (Kontrollkästchen
aktiviert/deaktiviert)
■
Status des Katalogs (Kontrollkästchen aktiviert/deaktiviert)
■
Ausschluss von der RAC (Reinstall After Crash; Neuinstallation nach Absturz)
(Kontrollkästchen aktiviert/deaktiviert)
Wenn Sie auf dem Enterprise-Manager Änderungen an den aufgeführten Informationen
vornehmen und das Softwarepaket in diesem Zustand verteilen, weichen die
Softwarepakete auf dem Domänen-Manager unter Umständen von der ursprünglichen
Verteilung des Softwarepakets ab.
Kopieren von registrierten Elementen für die automatische Registrierung
Nachdem ein Element in der Softwarebibliothek registriert wurde, können sowohl das
Element als auch die Registrierungsinformationen kopiert werden, um eine
automatische Registrierung in anderen Bibliotheken zu ermöglichen. Dies kann sehr
hilfreich sein, wenn Sie über mehrere Manager verfügen oder wenn die Software
Delivery-Funktionalität an mehreren Orten installiert ist, die nicht über ein Netzwerk
miteinander verbunden sind.
Vorbereiten von Programmen für die Registrierung
Bevor Sie ein Softwareprodukt in der Softwarepaketbibliothek registrieren, sollten Sie
die Prozeduren überprüfen, die mit dem Produkt geliefert werden. In den folgenden
Abschnitten finden Sie dazu weitere Hinweise.
Identifizieren eines Programms und seiner Quelle
Damit der Registrierungsvorgang für Programme beginnen kann, müssen zunächst die
Softwareprogramme festgelegt werden. Nach dem Identifizieren der Programme
müssen sie in die Softwarepaketbibliothek des Enterprise- oder Domänen-Managers
kopiert werden. Dazu müssen Sie die Quelle für die Programme festlegen (Disketten,
Verzeichnisse oder CD-ROM).
Da Installationsdateien nur in die Softwarepaketbibliothek kopiert und dort nicht im
eigentlichen Sinne installiert werden, können Sie Windows-, Linux-, WinCE- oder PalmSoftwareprogramme unabhängig vom Betriebssystem auf jedem Manager registrieren.
Die einzige Einschränkung besteht darin, dass der Datenträger des Programms vom
Manager gelesen können werden muss.
Suchen von Quelldateien
Die Dateien werden über die Softwarepaketbibliothek (siehe Seite 14) und nicht über
den Produktdatenträger (z. B. DVD oder CD-ROM) bereitgestellt. Möglicherweise
müssen Sie den Speicherort der Quelldatei ändern, damit auf das Unterverzeichnis der
Bibliothek verwiesen wird. Der Speicherort wird in der aktuellen Installationsprozedur
verwaltet. Weitere Informationen finden Sie unter Verzeichnisbaumstruktur der
Bibliothek (siehe Seite 47).
Sonstige Prozeduren
Neben den Installationen können Sie Prozeduren zum Aktivieren, Deinstallieren oder
Konfigurieren einer Produktinstallation schreiben. Sie können komplett neue und
vollständig angepasste Installationsprozeduren hinzufügen.
Wenn eine Installation fehlschlägt, können Sie sie auf den Zielcomputern auch
wiederherstellen.
Anpassen vorhandener Prozeduren
Zusätzlich zu den erforderlichen Änderungen können Sie optional die
Installationsdateien anpassen, um automatische bzw. halbautomatische Installationen
zu erzeugen.
Ausführen von Windows Installer-Tasks
Zu Software Delivery gehört ein Tool mit dem Namen "sd_msiexe.exe", mit dem
Windows Installer-Tasks ausgeführt werden können. Es ähnelt dem Microsoft Windows
Installer-Tool "msiexec.exe" insofern, dass Windows Installer ebenfalls ein
Befehlszeilen-Tool verwendet. Das Befehlszeilen-Tool "sd_msiexe.exe" verwendet
dieselben Befehlszeilenoptionen wie "msiexec.exe" und wurde für die Verwendung mit
Software Delivery optimiert.
Hinweis: Wenn Sie kleine Änderungen an existierenden Prozeduren vornehmen oder
neue Prozeduren erstellen möchten, sollten Sie unbedingt mit der
Verzeichnisbaumstruktur vertraut sein, die von Software Delivery verwendet wird.
Hinweis: Eine Erläuterung der für Microsoft Installer "msiexec.exe" verfügbaren
Befehlszeilenoptionen finden Sie auf der Webseite Microsoft Hilfe und Support.
Verzeichnisbaumstruktur der Bibliothek
Wenn der Softwarepaketbibliothek ein Element hinzugefügt wird, werden die Dateien
auf der Basis des Datenträgertyps, von dem das Element kopiert wurde, in einer
Verzeichnisstruktur gespeichert. Eine typische Verzeichnisstruktur, die entsteht, wenn
das Programm von mehreren Datenträgern (z. B. CD-ROMs) kopiert wurde, wird in der
folgenden Abbildung dargestellt:
Jeder Datenträger wird unter dem Programmverzeichnis als Volume gespeichert. Der
erste Datenträger wird als 1.VOL bezeichnet, das zweite als 2.VOL usw.
Hinweis: Volumes haben in den vergangenen Jahren an Bedeutung verloren, da die
meisten Pakete inzwischen auf einen einzigen Installationsdatenträger passen.
Wenn das Programm von einem Datenträger oder aus einem Verzeichnis kopiert wird,
gilt es als einzelne Volume-Quelle und wird, wie in der folgenden Abbildung dargestellt,
verteilt:
In beiden Fällen (einzelne oder mehrere Datenträger) befinden sich die
Elementprozeduren, die bei der ursprünglichen Registrierung des Produkts identifiziert
werden (auch als eingebettete Elementprozeduren bezeichnet), typischerweise in
Unterverzeichnissen der Hauptverzeichnisse. Sie können jedoch auch im
Stammverzeichnis der ursprünglichen Installations-Datenträger bzw. im
Installationsverzeichnis gespeichert sein.
Hinweis: Unterschiedliche Datenträgertypen können nicht in einer Quelle
zusammengefasst werden.
Erforderliche Änderungen an Installationsdateien
Bei der Installation von Diskette oder CD-ROM rufen die Installationsprogramme
manchmal Daten aus Informationsdateien ab, die sich auf der ersten
Installationsdiskette befinden. Diese Datei enthält die Erkennungsinformationen für den
Datenträger. Während des Installationsvorgangs prüfen diese Programme in der Regel
das aktuelle Verzeichnis auf die erforderlichen Installationsdateien. Wenn das
Programm aus einer oder mehreren Disketten oder CD-ROMs besteht, die Sie vor der
Registrierung in ein Verzeichnis kopiert haben, müssen Sie keine Änderungen
vornehmen. Wenn mehrere Datenträger vorliegen, und Sie jeden Datenträger einzeln
registriert haben, müssen Sie die Bezeichnungen der Volumes der
Installationsinformationsdatei (*.INS oder *.INF) so verändern, dass sie auf die Dateien
in der Struktur der Softwarebibliothek verweisen. Wenn zum Beispiel die VolumeBezeichnungen in numerischer Reihenfolge angegeben sind ("VOL_BEZ1", "VOL_BEZ2"
usw.), müssen diese in "\1.VOL", also "VOL_BEZ1", \2.VOL "VOL_BEZ2" usw. geändert
werden. Nachdem das ursprüngliche Bibliothekselement registriert wurde, muss die
geänderte *.INS- oder *.INF-Datei mit dem Installationsprogramm (als Prozedur für
hinzugefügte Elemente) registriert werden. Weitere Informationen zum Registrieren
hinzugefügter Elementprozeduren finden Sie unter Definieren hinzugefügter
Elementprozeduren (siehe Seite 80).
Änderungen an Linux- und UNIX-Installationen
Welche Änderungen an Linux- oder UNIX-Programmen vorgenommen werden müssen,
hängt davon ab, welche Linux- oder UNIX-Umgebung und Versionsebene Sie
verwenden. Im Allgemeinen sollten Sie Folgendes beachten:
1.
Entscheiden, welches Installationsprogramm Sie zur Installation des Produkts
verwenden werden. Damit legen Sie fest, welcher Befehl zur Ausführung der
Installation verwendet wird.
Hinweis: Denken Sie daran, dass die zu installierenden Dateien in der zuvor
beschriebenen temporären Verzeichnisstruktur gespeichert sind, und nicht auf dem
Installationsdatenträger. Sie müssen ein Installationsskript erstellen, das diesen
Befehl ausgibt.
2.
Überzeugen Sie sich davon, dass der Installationsvorgang keine Eingaben des
Benutzers auf dem Zielcomputer erfordert. Sollte dies der Fall sein, muss Ihr Skript
die Antworten auf die betreffenden Fragen enthalten. Die Art und Weise, in der Sie
die Antworten bereitstellen, hängt vom verwendeten Betriebssystem ab.
3.
Registrieren Sie das Skript als Elementprozedur für das Programm.
Optionale Anpassungs-Tools
Benutzerspezifisch angepasste Prozeduren bestehen aus zusätzlichen,
benutzerdefinierten Dateien, die folgende Funktionen erfüllen:
■
Ändern des Linux- oder UNIX-Installationsskripts mit Hilfe des entsprechenden
Installationsprogramms
■
Speichern der Antworten für einige oder sämtliche Installationsfragen zum
Erzeugen automatischer oder halbautomatischer Installationsprozeduren
■
Initiierung einer Remote-Aktivierung des Produkts
■
Ändern der Konfigurationsdateien des Zielcomputers
■
Deinstallation von Produkten zu einem späteren Zeitpunkt
Wichtig! Testen Sie jede Prozedur vor der Registrierung und Verteilung.
Ändern von bestehenden Prozeduren
Sie können folgende Schritte ausführen:
■
Ändern des Linux/UNIX-Installationsskripts gemäß der Beschreibung unter
"Erforderliche Änderungen an Installationsdateien"
■
Ändern der Installer-Antwortdatei
■
Ändern der Antwortdatei für CID-fähige IBM-Produkte
Erstellen von neuen Prozeduren
Verwenden Sie die Skriptsprache für folgende Aufgaben:
■
Erstellen einer Skriptdatei mit DMS-Erweiterung mit Hilfe eines Texteditors (weitere
Informationen zur Skriptsprache finden Sie in der Online-Hilfe des CA ITCM-SkriptEditors).
■
Erstellen von eigenen ausführbaren Dateien (z. B. mit Hilfe von C/C++)
■
Kopieren von anderen Installationsprogrammen oder -skripten
Bibliothekselemente
Die Softwareelemente in der Softwarepaketbibliothek sind folgenden Gruppen
zugeordnet:
Öffnen
Ein Objekt ist während der Registrierung so lange offen, bis der
Registrierungsprozess durch die Versiegelung des Softwareelements beendet wird.
Geschlossen/Versiegelt
Ein Softwareelement ist geschlossen, wenn es versiegelt wurde. Wenn ein
Softwareelement als ein Software Delivery-Paket registriert wird, wird es
automatisch versiegelt.
Programme
Programme können mit Elementprozeduren registriert werden, um Anwendungen
zu installieren, zu aktivieren, zu konfigurieren und/oder zu deinstallieren.
Elementprozeduren können entweder zusammen mit Programmen oder nach
deren Registrierung registriert werden.
Gefunden
Gefundene Software ist bereits auf einem Computer installiert, wurde jedoch noch
nicht in der Bibliothek des Enterprise-Managers oder Domänen-Managers
registriert. Diese Elemente dienen mehr oder weniger als Platzhalter in der
Softwarepaketbibliothek und enthalten keine tatsächlichen Programme.
Programmregistrierung auf Scalability-Servern
Scalability-Server enthalten auch eine permanente Softwarepaketbibliothek (die so
genannte Staging-Bibliothek). Um Bibliothekselemente von einem Domänen-Manager
auf einen untergeordneten Scalability-Server zu kopieren, wählen Sie ein
Bibliothekselement oder eine Softwaregruppe aus und legen sie per Kopieren und
Einfügen oder per Drag-and-Drop auf dem Scalability-Server ab. Wenn Sie mit einem
Enterprise-Manager verbunden sind, können Sie eine Verteilung für die Lieferung von
Bibliothekselementen an die Bibliothek eines Scalability-Servers planen, der dem
Domänen-Manager, an den die Verteilung gesendet werden soll, untergeordnet ist.
Auch diesen Vorgang können Sie per Kopieren und Einfügen bzw. Drag-and-Drop
vornehmen.
Der Staging-Assistent ist eine verbesserte, benutzerfreundliche Methode zum
Übertragen von Software auf den Scalability-Server. So können Sie damit z. B.
Software aus mehreren Softwaregruppen auswählen. Der Assistent kann von
Bibliothekselementen, Scalability-Servern und Softwarejobs aus gestartet werden.
Klicken Sie beispielsweise mit der rechten Maustaste auf einen Scalability-Server, und
wählen Sie "Softwarejob", "Softwarepakete bereitstellen (Staging)", um den Assistenten
zu starten. Im Enterprise-Manager können Sie auch die Domänen auswählen, an die die
Bibliothekselemente als Erstes verteilt werden sollen, bevor sie auf die ausgewählten
Scalability-Servergruppen weitergeleitet werden.
Programme können ferner über die Befehlszeile in der Staging-Bibliothek registriert
werden. So lässt sich die Registrierung auch wieder aufheben. Mit Hilfe des Befehls
"sd_sscmd aregsw" können Sie einer Staging-Bibliothek, die sich nicht im Ordner der
Softwarepaketbibliothek auf dem Domänen-Manager befindet, Software hinzufügen.
Die Software wird in der Staging-Bibliothek des DSM-Explorers auf dem DomänenManager nicht angezeigt, auch wenn die Prozedur "Software-Staging-Bibliothek
synchronisieren" gestartet wird.
Bevor Sie die permanenten Staging-Bibliotheken verwenden können, müssen Sie
folgende Schritte ausführen:
■
Speichern aller Produkte der Softwarepaketbibliothek des Domänen-Managers in
der Staging-Bibliothek.
■
Zuweisen von Produkten und Zielcomputern mit Hilfe der Funktion Installieren
Um den Inhalt der Staging-Bibliothek zu verfolgen, wird im Ordner "LIBRARY" eine Datei
mit dem Namen "library.dct" erstellt, in der alle registrierten Elemente eingetragen
werden.
Registrieren virtueller Anwendungen
Sie können virtuelle Anwendungen in die Software-Paket-Bibliothek importieren und sie
auf Enterprise- oder Domänenmanagement-Ebene registrieren. Die folgenden
Abschnitte bieten eine Übersicht über die Anwendungsvirtualisierung und enthalten
weitere Details zu den allgemeinen Prozessen und Prozeduren der Paketerstellung:
■
Anwendungsvirtualisierung
■
Inhalt und Format von Images der virtuellen Anwendung
■
Funktionsweise der Paketerstellung von virtuellen Anwendungen
■
Pakete mit virtueller Anwendung
■
Erstellen eines Softwarepakets für virtuelle Anwendungen
■
Erstellen einer Aktualisierung des Softwarepakets für virtuelle Anwendungen
■
Infrastrukturpaketvorlagen für virtuelle Anwendungen
■
Erstellen von Infrastruktursoftwarepaketen für Microsoft App-V
■
Erstellen von Infrastruktursoftwarepaketen für VMware ThinApp
Anwendungsvirtualisierung ist eine Softwaretechnologie, die die Bereitstellung und die
Verwaltung von Anwendungen erleichtert, indem man sie vom zu Grunde liegenden
Betriebssystem trennt, auf dem sie normalerweise ausgeführt würden. Virtuelle
Anwendungen werden nicht auf die traditionelle Weise installiert, sie können sie jedoch
so benutzen, als ob es sich um eine traditionelle Installation handeln würde. Wenn eine
virtuelle Anwendung ausgeführt wird, scheint sie direkt mit dem ursprünglichen
Betriebssystem und allen vom Betriebssystem verwalteten Ressourcen zu interagieren.
Die Anwendung wird jedoch in einer Umgebung ("Blase") ausgeführt, die isoliert vom
Betriebssystem ist.
Virtuelle Anwendungen können direkt von der lokalen Festplatte eines Zielcomputers
ausgeführt oder von einem Remote-Server gestreamt werden. Mit der Option
"Streaming" wird die virtuelle Anwendung auf dem Server gespeichert. Ein
"Sandkasten" wird auf dem Server oder dem Zielcomputer für jeden Benutzer einer
gestreamten virtuellen Anwendung erstellt. Der Sandkasten enthält alle Unterordner,
Konfigurationsdateien und anwendungsspezifische Registrierungseinträge, die zur
Ausführung der Anwendung benötigt werden. Nachdem der Benutzer die virtuelle
Anwendung geschlossen hat, wird die Anwendung vom Speicher des Computers
entfernt. Nur kleine Konfigurationsdateien und eine Verknüpfung, um die Anwendung
zu starten, bleiben übrig. Der Sandkasten, der alle benutzerspezifischen Einstellungen
enthält, ist allerdings noch auf dem Server oder dem Zielcomputer für das nächste Mal
verfügbar, wenn der Benutzer die Anwendung ausführen möchte.
Virtuelle Anwendungen sind normale Anwendungen, die als Images der virtuellen
Anwendung erfasst wurden. Dieses Image enthält alle Dateien und Konfigurationsdaten,
die zur Ausführung der Anwendung notwendig sind, sowie alle
Installationsinformationen, die normalerweise bei der Installation einer Anwendung
verwendet werden würden. Für die Erstellung eines Images der virtuellen Anwendung
werden Tools verwendet, die vom Anbieter der Virtualisierungstechnologie geliefert
werden. Diese Anbietertools können ein Image der virtuellen Anwendung von einer
normalen Anwendung generieren.
Sie können CA ITCM verwenden, um den Lebenszyklus der virtuellen Anwendung zu
verwalten, nachdem das Image der virtuellen Anwendung mit einem der Tools des
Anbieters erstellt wurde. Das Image kann als ein Standardsoftware-Paket in die
Software Delivery-Bibliothek aufgenommen werden und auf Zielcomputern durch die
standardmäßigen CA ITCM-Bereitstellungsmethoden bereitgestellt werden. Für das
Paket kann eine Aktualisierung oder ein Upgrade durchgeführt werden bzw. kann es
über die standardmäßigen CA ITCM-Methoden zurückgezogen werden.
Inhalt und Format von Images der virtuellen Anwendung
Sie erstellen ein Image der virtuellen Anwendung von einer normalen Anwendung,
indem Sie die von Ihrem Anbieter von Anwendungsvirtualisierungen zur Verfügung
gestellten Tools verwenden. CA ITCM unterstützt die MicrosoftAnwendungsvirtualisierung (Microsoft App-V) und VMware ThinApp-Produkte. Sie
müssen die Images der virtuellen Anwendung mit einem dieser Tools erstellen, bevor
Sie CA ITCM verwenden können, um virtuelle Anwendungen zu verpacken,
bereitzustellen und zu verwalten.
Hinweis: Weitere Informationen zur Erstellung von virtuellen Anwendungen finden Sie
in der Dokumentation Ihres Anbieters für Ihr Produkt zur Anwendungsvirtualisierung.
Microsoft App-V
In der Vorbereitung von Images der virtuellen Anwendung (Sequenzierung)
entstehen eine Reihe von Dateien, unter anderem die folgenden Dateien:
■
XML-basierte Open Software Description-Dateien (.osd)
■
Symboldateien (.ico)
■
Eine Datei, die den vollständigen Anwendungscode der virtualisierten
Anwendung speichert (.sft)
■
Eine XML-basierte Manifestdatei (.xml)
■
Eine Projektdatei (.sprj)
Hinweis: Der Endbenutzer am Zielcomputer sollte eine virtuelle Anwendung von
Microsoft App-V nicht durch doppelten Mausklick auf die .osd-Datei starten. Wenn der
Benutzer die Anwendung auf diese Weise öffnet, besteht die Möglichkeit, dass die
Kommunikation mit dem Streaming-Server nicht fehlerfrei funktioniert. Der Benutzer
sollte die Anwendung über den Shortcut auf dem Desktop oder über das Startmenü
starten.
VMware ThinApp
In der Vorbereitung von Images der virtuellen Anwendung (Erfassung) entstehen
eine Reihe von Dateien und Ordner, unter anderem die folgenden Dateien und
Ordner:
■
Ein Ordner "Bin", der eine einzelne ausführbare Datei enthält. Für
Programmsuiten werden mehrere ausführbare Dateien für die
Benutzeroberfläche benötigt. In diesem Fall enthält der Ordner "Bin" eine Datei
".dat", die das ganze virtuelle Paket enthält, und kleine ausführbare Datei, die
für Zugriff zum virtuellen Paket sorgen.
■
Eine Konfigurationsdatei (.ini)
Funktionsweise der Paketerstellung von virtuellen Anwendungen
Sie können ein Standard-Software Delivery-Paket von einem Image der virtuellen
Anwendung über den Registrierungsassistenten für Pakete mit virtuellen Anwendungen
erstellen. Das Image der virtuellen Anwendung muss schon verfügbar sein, bevor Sie
den Assistenten zur Erstellung des Software Delivery-Pakets verwenden. Das Image
muss vom Computer zugreifbar sein, auf dem CA ITCM ausgeführt wird. Der Assistent
ermöglicht Ihnen auch, Aktualisierungspakete für virtuelle Anwendungen zu erstellen,
die zuvor in Software Delivery-Pakete verwandelt wurden.
Der Prozess, um Pakete mit virtueller Anwendung zu erstellen und zu importieren,
verwendet die folgenden allgemeinen Schritte:
1.
Der Administrator öffnet den Registrierungsassistenten für Pakete mit virtuellen
Anwendungen und lokalisiert ein Image der virtuellen Anwendung. Images müssen
auf dem Computer, der CA ITCM ausführt verfügbar sein bzw. von diesem
Computer aus zugreifbar sein.
2.
Der Administrator durchsucht das Image der virtuellen Anwendung. Mit diesem
Schritt kann der Administrator überprüfen, ob das ausgewählte Image ein zulässiges
Image der virtuellen Anwendung ist. Der Assistent analysiert das virtuelle Image
und extrahiert die Informationen, die zur Erstellung der Software Delivery-Pakete
notwendig sind.
Hinweis: Der Paketname basiert auf dem Namen der virtuellen Anwendung und ist
auf 20 Charaktere beschränkt (zum Beispiel, my_productname_is_20-TA-SG). Wenn
ein Produktnamen doppelt vorhanden ist, muss der Administrator den aktuellen
Paketnamen ändern, um das Paket erstellen zu können.
3.
(Optional) Wenn das Image der virtuellen Anwendung eine Aktualisierung für eine
virtuelle Anwendung darstellt, identifiziert der Administrator das Staging-Paket, das
ursprünglich für die virtuelle Anwendung erstellt wurde.
4.
Der Administrator überprüft die Zusammenfassung des erstellten Pakets mit
virtueller Anwendung und beendet den Assistenten.
5.
Der Registrierungsassistent für Pakete mit virtuellen Anwendungen erstellt drei
Softwarepakete für jedes Image der virtuellen Anwendung:
Eigenständig
Dieses Paket wird verwendet, um die virtuelle Anwendung lokal auf dem
Zielcomputer zu installieren.
Streaming
Dieses Paket wird verwendet, um die virtuelle Anwendung downstream von
einem Streaming-Server zu erhalten und sie auf dem lokalen Computer
auszuführen.
Staging
Dieses Paket bietet Zugriff auf die virtuelle Anwendung für eigenständige und
Streaming-Modi der Paketlieferung. Dieses Paket enthält das Image der
virtuellen Anwendung.
Hinweis: Weitere Informationen zu den Typen von Paketen mit virtueller
Anwendung finden Sie im Abschnitt "Pakete mit virtuellen Anwendungen" (siehe
Seite 57).
6.
7.
Der Assistent startet den Vorgang, Pakete mit virtueller Anwendung in die Software
Delivery-Bibliothek zu importieren, indem überprüft wird, ob die Paketnamen
bereits in der Bibliothek aufgelistet werden.
a.
Wenn die Paketnamen schon in der Bibliothek vorhanden sind, wird eine
Fehlermeldung angezeigt, dass die Paketnamen nicht eindeutig sind. Die Pakete
werden nicht importiert.
b.
Wenn die Paketnamen nicht in der Bibliothek vorhanden sind, importiert der
Assistent die drei Pakete: Staging, Eigenständig und Streaming.
c.
Wenn die Pakete Aktualisierungspakete sind, werden sie importiert und mit
einer höheren Versionsnummer registriert. Es werden nur zwei Pakete für
Aktualisierungen erstellt: Staging und Eigenständig.
Der Administrator erstellt die Definitionen für die neuen Pakete mit virtueller
Anwendung. Die Beschreibungen des Erkennens und des Inventars für virtuelle
Anwendungen stellen mehr Informationen zur Erstellung von Definitionen für
Pakete mit virtueller Anwendung zur Verfügung.
Nachdem die Software Delivery-Bibliothek ein Paket mit virtueller Anwendung
aufgenommen hat, kann es der Administrator bereitstellen und die Verwendung von
standardmäßigen Software Delivery-Methoden verwalten.
Pakete mit virtueller Anwendung
Der Prozess zur Software-Paketerstellung mit Software Delivery für virtuelle
Anwendungen (durch den Registrierungsassistenten für Pakete mit virtuellen
Anwendungen) erstellt drei Softwarepakete bei der ersten Paketerstellung einer
virtuellen Anwendung:
Eigenständig
Dieses Paket installiert und führt die virtuelle Anwendung örtlich auf dem
Zielcomputer aus. Das eigenständige Paket enthält Prozeduren und, für Microsoft
App-V, Konfigurationsdateien. Es enthält außerdem eine Abhängigkeit zum StagingPaket, das das Image der virtuellen Anwendung enthält. Daher wird das StagingPaket auf dem Zielcomputer installiert, bevor das eigenständige Paket installiert
wird.
Dieses Paket erstellt alle Verknüpfungen und Dateizuordnungen (wie bei der
ursprünglichen Installation erstellt). Das eigenständige Paket enthält keine
Anwendungsmassendaten. Die große Datenmenge wird im Staging-Paket
gespeichert und auf dem Zielcomputer als eine Abhängigkeit zum eigenständigen
Paket installiert.
Dieses Paket wird im folgenden Format benannt:
Anwendungsname-Anbieter-Tool-Abkürzung-SA
Beispiel: DeveloperStudio–AV–SA (Microsoft App-V) oder DeveloperStudio–TA–SA
(VMware ThinApp)
Streaming
Dieses Paket besteht aus Prozeduren, Tools und Konfigurationsdateien. Es erstellt
Verknüpfungen und Dateizuordnungen auf dem Zielcomputer. Die Verknüpfungen
auf dem Zielcomputer erlauben den Start der Anwendung vom Scalability-Server,
der als Streaming-Server agiert. Das Image der virtuellen Anwendung ist nicht Teil
des Streaming-Pakets, d. h., dass für das Anwendungs-Image kein Staging auf dem
Zielcomputer durchgeführt wird. Für das Anwendungs-Image muss stattdessen ein
Staging auf dem Scalability-Server durchgeführt werden. Der Administrator muss
sicher gehen, dass das Staging-Paket zuerst auf dem Scalability-Server installiert
wird, damit das Streaming-Paket ordnungsgemäß ausgeführt werden kann.
Hinweis: Das Streaming-Paket wird nicht erstellt, wenn eine virtuelle Anwendung
als Aktualisierung eines vorhandenen Pakets mit einer virtuellen Anwendung
importiert wird. Das Streaming-Paket muss nicht aktualisiert werden, weil die
enthaltenen Shortcuts bereits auf das (aktualisierte) Staging-Paket verweisen.
Anwendungsname-Anbieter-Tool-Abkürzung-SM
Beispiel: DeveloperStudio–AV–SM (Microsoft App-V) oder DeveloperStudio–TA–SM
(VMware ThinApp)
Staging
Dieses Paket bietet Zugriff auf die virtuelle Anwendung für eigenständige und
Streaming-Modi der Paketlieferung. Das Staging-Paket enthält große Datenmengen,
d. h., das Image der virtuellen Anwendung. Bei eigenständigen Lieferungen wird für
das Image ein Staging auf dem Zielcomputer durchgeführt. Bei StreamingLieferungen wird der Inhalt des Images auf den Zielcomputer gestreamt. Da
bestimmte Teile der Anwendung vom Benutzer angefordert werden, werden jene
Teile vom Scalability-Server (der als Streaming-Server agiert) auf den Zielcomputer
gestreamt.
Hinweis: Das Staging-Paket wird automatisch installiert (als ein abhängiges Paket),
wenn Sie ein eigenständiges Paket auf einem Zielcomputer installieren. Wenn Sie
jedoch ein eigenständiges Paket deinstallieren, wird das entsprechende StagingPaket nicht automatisch deinstalliert. Sie müssen einen Deinstallationsjob planen,
um das Staging-Paket zu entfernen.
Anwendungsname-Anbieter-Tool-Abkürzung-SG
Beispiel: DeveloperStudio–AV–SG (Microsoft App-V) oder DeveloperStudio–TA–SG
(VMware ThinApp)
Aktualisierungen für virtuelle Anwendungen
Wenn Pakete der Aktualisierungen für virtuelle Anwendungen erstellt werden, erstellt
der Software Delivery-Verpackungsprozess nur zwei Softwarepakete: Eigenständig und
Staging. Das Streaming-Paket wird nicht erstellt, da dieses Paket nur ClientVerknüpfungen zu den Staging-Paketen und den virtuellen Anwendungen enthält. Diese
Verknüpfungen sind nicht von den Anwendungsaktualisierungen betroffen. Die
Aktualisierungspakete "Eigenständig" und "Staging" werden mit einer Versionsnummer
registriert, die über der Nummer der ursprünglichen Pakete liegt.
Aktualisierungspakete haben denselben Namen wie die früheren Pakete, jedoch mit
einer höheren Versionsnummer. Obwohl die Versionsnummer nicht Teil des
Paketnamens ist (wird intern gespeichert), wird sie in der Software Delivery-Bibliothek,
im DSM-Explorer, als Suffix des Paketnamens angezeigt.
Downgrades für virtuelle Anwendungen
Sie können an einem Paket mit einer virtuellen Anwendung auch ein Downgrade
vornehmen. Ein Downgrade ähnelt einer Aktualisierung. Sie müssen das Image der
virtuellen Anwendung, das die Anwendung enthält, mit der Zielversion für das
Downgrade erstellen. Das Verpacken eines Downgrades ähnelt dem Verpacken einer
Aktualisierung. Es werden nur die Pakete 'Eigenständig' und 'Staging' erstellt. Die
Pakete, an denen ein Downgrade durchgeführt wurde, haben denselben Namen wie
frühere Pakete, jedoch mit einer höherenVersionsnummer (ähnlich zu
Aktualisierungspaketen).
Erstellen eines Softwarepakets für virtuelle Anwendungen
Der Registrierungsassistent für Pakete mit virtuellen Anwendungen ermöglicht es Ihnen,
ein Paket mit virtueller Anwendung zu erstellen und es in die Software-Paket-Bibliothek
zu importieren.
So erstellen Sie ein Softwarepaket für virtuelle Anwendungen
1.
Überprüfen Sie, ob ein Image der virtuellen Anwendung für die Anwendung erstellt
worden ist, die Sie verpacken möchten. Das Image sollte sich auf demselben
Computer befinden bzw. von diesem Computer zugreifbar sein, auf dem CA ITCM
ausführt wird.
2.
Navigieren Sie zum Ordner der Software-Paket-Bibliothek im DSM-Explorer, in dem
Sie das Paket erstellen möchten.
3.
Klicken Sie mit der rechten Maustaste auf den Ordner und wählen Sie "Import",
"Paket mit virtueller Anwendung", aus.
Der Registrierungsassistent für Pakete mit virtuellen Anwendungen wird geöffnet.
4.
Wählen Sie auf den folgenden Seiten des Assistenten das Image der virtuellen
Anwendung aus.
Der Assistent erstellt drei Pakete mit virtueller Anwendung: Eigenständig,
Streaming und Staging. Die Pakete werden im Ordner der Software-Paket-Bibliothek
gespeichert, von dem aus Sie den Assistenten gestartet haben.
Erstellen einer Aktualisierung des Softwarepakets für virtuelle Anwendungen
Der Registrierungsassistent für Pakete mit virtuellen Anwendungen ermöglicht es Ihnen,
eine Aktualisierung des Pakets für virtuelle Anwendungen zu erstellen und es in die
Software-Paket-Bibliothek zu importieren.
So erstellen Sie eine Aktualisierung des Softwarepakets für virtuelle Anwendungen
1.
Überprüfen Sie, ob ein aktualisiertes Image der virtuellen Anwendung für die
Aktualisierungsanwendung erstellt worden ist, die Sie verpacken möchten. Das
Image sollte sich auf demselben Computer befinden bzw. von diesem Computer
zugreifbar sein, auf dem CA ITCM ausführt wird.
Hinweis: Für Microsoft App-V müssen Sie das aktualisierte Image der virtuellen
Anwendung über die Methode des aktiven Upgrades von App-V-Sequencer
erstellen. Weitere Informationen zur Methode des aktiven Upgrades finden Sie in
der Microsoft App-V-Produktdokumentation. Sie können auch auf die MicrosoftWebseite zugreifen (http://www.microsoft.com) und Details im Artikel "Upgradeund Aktualisierungsmethoden für virtualisierte Anwendungen (Methods for
Upgrading or Updating Virtualized Applications)" von Microsoft-TechNet finden.
2.
Navigieren Sie zum Ordner der Software-Paket-Bibliothek im DSM-Explorer, in dem
Sie die Aktualisierung des Pakets erstellen möchten.
3.
Klicken Sie mit der rechten Maustaste auf den Ordner und wählen Sie "Import",
"Paket mit virtueller Anwendung", aus.
Der Registrierungsassistent für Pakete mit virtuellen Anwendungen wird geöffnet.
4.
Wählen Sie auf den folgenden Seiten des Assistenten die aktualisierte virtuelle
Anwendung aus.
Der Assistent fordert Sie auf, das Staging-Paket für Ihre aktualisierte virtuelle
Anwendung auszuwählen.
5.
Wählen Sie das vorherige Staging-Paket (letzte Version) aus, das für die
ursprüngliche virtuelle Anwendung erstellt wurde.
Der Assistent erstellt zwei Pakete mit virtueller Anwendung: Eigenständig und
Staging. Die Pakete werden im Ordner der Software-Paket-Bibliothek gespeichert,
von dem aus Sie den Assistenten gestartet haben.
Hinweis: Sie können an einem Paket mit einer virtuellen Anwendung auch ein
Downgrade vornehmen. Ein Downgrade ähnelt einer Aktualisierung. Sie müssen das
Image der virtuellen Anwendung, das die Anwendung enthält, mit der Zielversion für
das Downgrade erstellen. Das Verpacken eines Downgrades ähnelt dem Verpacken
einer Aktualisierung. Es werden nur die Pakete 'Eigenständig' und 'Staging' erstellt. Die
Pakete, an denen ein Downgrade durchgeführt wurde, haben denselben Namen wie
frühere Pakete, jedoch mit einer höherenVersionsnummer (ähnlich zu
Aktualisierungspaketen).
Infrastrukturpaketvorlagen für virtuelle Anwendungen
CA ITCM ermöglicht Ihnen, Softwarepakete für virtuelle Anwendungen von Images der
Microsoft Application Virtualization (Microsoft App-V) oder VMware ThinApp erstellen.
Bevor Sie diese Pakete mit virtueller Anwendung jedoch bereitstellen und ausführen
können, müssen Sie bestimmte Anwenderinfrastruktursoftware auf den Servern und
Zielcomputern installieren, für die Sie die virtuellen Anwendungen bereitstellen wollen.
Die Infrastruktursoftware enthält Anbietertools und Module, die zur Installation und
Ausführung der virtuellen Anwendung nötig sind.
Hinweis: Weitere Informationen zu den Voraussetzungen von
Anwenderinfrastruktursoftware finden Sie in den Beschreibungen Vorbereiten eines
Zielcomputers für Bereitstellung einer virtuellen Anwendung von Microsoft App-V (siehe
Seite 119) und Vorbereiten eines Zielcomputers für Bereitstellung einer virtuellen
Anwendung von VMware ThinApp (siehe Seite 121).
Sie können von CA zur Verfügung gestellte Vorlagen verwenden, um
Anwenderinfrastruktursoftwarepakete zu erstellen. Die folgenden Vorlagen stehen
Ihnen zur Verfügung:
■
Microsoft App-V Virtualization Desktop Client (App-V-Client für standardmäßige
Desktops)
■
Microsoft-App-V-Virtual Client für Remote Desktop Services (App-V-Client für
Terminalserver)
■
Microsoft App-V Server
■
VMware ThinApp
Sie müssen dazu die entsprechenden Anbietersoftwaremodule in diese Vorlagen
einfügen. Die Pakete, die Sie mit den Vorlagen erstellen, sind standardmäßige Software
Delivery-Softwarepakete. Sie können die Infrastruktur-Softwarepakete in der SoftwarePaket-Bibliothek registrieren.
Die Dateistruktur in der Infrastrukturpaketvorlage stimmt mit der Struktur eines
standardmäßigen Software Delivery-Softwarepakets überein: ein Stammordner, der
Ordner "reginfo" und zusätzliche Ordner und/oder Dateien.
Unterordner "Reginfo"
Die Vorlagen enthalten alle notwendigen Informationen, um das Paket in der
Software-Paket-Bibliothek zu registrieren und es mit anderen abhängigen
Infrastrukturpaketen zu verknüpfen.
Zusätzliche Ordner und Dateien
Die Vorlagen beinhalten Installationsmodule für die Softwarepakete. Für
Infrastrukturpakete müssen Sie diese Module von den Installationsdatenträgern des
Anbieters kopieren.
Die Vorlage hilft Ihnen dabei, die Installationsmodule zu identifizieren, die Sie in die
entsprechenden-Unterordner kopieren müssen. In jeder Vorlage befindet sich eine
Image-Datei, in der die erforderlichen Anbieterdateien aufgelistet werden. Zum Beispiel
enthält die Vorlage für Microsoft App-V Desktop Client die Datei "client_files.JPG". Diese
Datei zeigt, dass drei Dateien benötigt werden:
■
AppVirtReadme.htm
■
Setup.exe
■
Setup.msi
Hinweis: Die Infrastrukturpaketvorlagen werden als Benutzerfreundlichkeit zur
Verfügung gestellt. Sie können jedoch auch die Anwenderinfrastruktursoftware selbst
installieren. Gehen Sie in diesem Fall sicher, dass die Software auf allen Servern und
Zielcomputern installiert wurde, auf denen Sie virtuelle Anwendungen bereitstellen
möchten. Überprüfen Sie außerdem, dass die erforderlichen Berechtigungsschlüssel in
der Registrierung festgelegt wurden.
Zusätzlich zu den Infrastrukturpaket-Vorlagen beinhaltet der CA ITCM-DVD-Kit das
folgende Paket: Microsoft-Anwendungsfehlerberichterstattung 11.0.6558.0. Sie können
dieses Fehlerberichterstattungs-Paket mit den Client- und Serverpaketen bereitstellen.
Weitere Informationen zu diesem Paket finden Sie in der MicrosoftProduktdokumentation.
Erstellen von Infrastruktursoftwarepaketen für Microsoft App-V
Sie können Microsoft App-V-Infrastruktursoftwarepakete mittels der von CA zur
Verfügung gestellten Vorlagen erstellen. Die Pakete, die Sie mit den Vorlagen erstellen,
sind standardmäßige Software Delivery-Pakete.
Hinweis: Für diese Prozedur wird angenommen, dass die folgenden Produkte verfügbar
sind: Microsoft System Center Application Virtualization Streaming Server, Microsoft
Application Virtualization Desktop Client und Microsoft Application Virtualization Client
für Remote Desktop Services. Das folgende Verfahren beschreibt, wie Pakete für den
Server und beide Arten von Clients erstellt werden können.
So erstellen Sie Infrastruktursoftwarepakete für Microsoft App-V
1.
Greifen Sie auf den folgenden Ordner auf dem CA ITCM-Installationsdatenträger zu:
examples\AV_Templates\Microsoft AppV-Pakete
2.
Kopieren Sie den Ordner "Microsoft AppV-Pakete" (und die ganze Baumstruktur
darunter) auf Ihren lokalen Rechner (z. B. nach D:\AppV-Packages).
3.
Öffnen Sie die Image-Datei "server_files.JPG" im Unterordner "1.vol" und die
notwendigen Microsoft-Produktdateien werden angezeigt:
Microsoft AppV-Pakete\Infrastrukturpaket für AppV-Server\1.vol
4.
Kopieren Sie die erforderlichen Dateien (wie in "server_files.JPG" angezeigt) vom
Installationsdatenträger "Microsoft System Center Application Virtualization
Streaming Server" in den folgenden Unterordner:
5.
Entfernen Sie die Datei "server_files.JPG" aus dem folgenden Unterordner:
6.
Öffnen Sie die Image-Datei "client_files.JPG" in der Desktop Client-Vorlage. Die
erforderlichen Microsoft-Produktdateien werden angezeigt:
Microsoft AppV-Pakete\Microsoft Application Virtualization Desktop Client
7.
Kopieren Sie die erforderlichen Dateien (wie in "client_files.JPG" angezeigt) vom
Installationsdatenträger "Microsoft Application Virtualization Desktop Client" in die
Vorlage:
8.
Entfernen Sie die Datei "client_files.JPG" aus der Desktop Client-Vorlage:
9.
Öffnen Sie die Image-Datei "client_files.JPG" in der Desktop Client-Vorlage für
Remote Desktop Services. Die erforderlichen Microsoft-Produktdateien werden
angezeigt:
Microsoft-AppV-Pakete\Microsoft Application Virtualization Desktop Client für
Remote Desktop Services
10. Kopieren Sie die erforderlichen Dateien (wie in "client_files.JPG" angezeigt) vom
Installationsdatenträger "Microsoft Application Virtualization Desktop Client für
Remote Desktop Services" in die Vorlage:
11. Entfernen Sie die Datei "client_files.JPG" aus der Desktop Client-Vorlage für Remote
Desktop Services:
12. Kopieren Sie die erforderlichen Dateien (wie in "files.JPG" angezeigt) vom
Installationsdatenträger "Microsoft-Anwendungsfehlerberichterstattung" in die
Vorlage:
Microsoft-AppV-Pakete\Microsoft-Anwendungsfehlerberichterstattung
13. Entfernen Sie die Datei "cfiles.JPG" aus der Fehlerberichterstattungs-Vorlage:
Microsoft-AppV-Pakete\Microsoft-Anwendungsfehlerberichterstattung\1.vol
14. Öffnen Sie die Image-Datei "files.JPG" in der Fehlerberichterstattungs-Vorlage. Die
erforderlichen Microsoft-Produktdateien werden angezeigt:
Microsoft-AppV-Pakete\Microsoft-Anwendungsfehlerberichterstattung\1.vol
15. Wählen Sie im Windows Explorer alle Ordner unter dem Ordner "AppV-Pakete" aus
(z. B. D:\AppV-Pakete), und verschieben Sie sie über Drag/Drop in die SoftwarePaket-Bibliothek in der EGC-GUI.
Fünf Microsoft App-V-Infrastruktursoftwarepakete werden erstellt und in der
Software-Paket-Bibliothek registriert. Sie müssen die folgenden Pakete auf den
Zielrechnern bereitstellen.
■
Das Infrastrukturpaket für den Server wird in folgendem Format benannt:
Infrastrukturpaket für AppV-Server
■
Das Infrastrukturpaket für den Standard-Desktop-Computer wird in folgendem
Format benannt:
Infrastrukturpaket für AppV-Client
■
Das Infrastrukturpaket für den Terminalserver wird in folgendem Format
benannt:
Infrastrukturpaket für AppV-Client für Remote Desktop Services
Erstellen von Infrastruktursoftwarepaketen für VMware ThinApp
Sie können VMware ThinApp-Infrastruktursoftwarepakete mittels der von CA zur
Verfügung gestellten Vorlagen erstellen. Die Pakete, die Sie mit den Vorlagen erstellen,
sind standardmäßige Software Delivery-Softwarepakete.
Hinweis: Für diese Prozedur wird angenommen, dass Sie das folgende Produkt bereits
installiert haben: VMware ThinApp.
So erstellen Sie Infrastruktursoftwarepakete für VMware ThinApp
1.
Greifen Sie auf den folgenden Ordner auf dem CA ITCM-Installationsdatenträger zu:
examples\AV_Templates\VMWare ThinApp-Pakete\Infrastrukturpaket for ThinAppClient
2.
Kopieren Sie den Ordner Infrastrukturpaket für ThinApp-Client auf Ihren lokalen
Rechner.
Hinweis: Der Speicherort auf Ihrem lokalen Rechner muss für den
Registrierungsassistenten für Pakete mit virtuellen Anwendungen zugreifbar sein.
3.
Öffnen Sie die Image-Datei "vmware_files.JPG" im folgenden Unterordner und die
notwendigen VMware-Produktdateien werden angezeigt:
Infrastrukturpaket für ThinApp-Client\1.vol
4.
Kopieren Sie die ausführbare Datei "Thinreg.exe" vom VMware ThinAppInstallationsdatenträger in den folgenden Unterordner:
5.
Entfernen Sie die Datei "vmware_file.JPG" aus dem folgenden Unterordner:
6.
Wählen Sie den Ordner "Infrastrukturpaket für ThinApp-Client" im Windows
Explorer aus und verschieben Sie ihn über Drag/Drop in die Software-PaketBibliothek in der EGC-GUI.
7.
Die Infrastrukturpakete werden im folgenden Format benannt:
Infrastrukturpaket für ThinApp-Client
Das VMware ThinApp-Infrastruktursoftwarepaket ist nun als ein standardmäßiges
Software Delivery-Paket in der Software-Paket-Bibliothek registriert.
Registrieren von MSI-Paketen in der Softwarepaketbibliothek
Der Microsoft Windows Installer (MSI) ist ein Installationsdienst auf der Agentenseite,
der die Installation von Anwendungen auf Windows-Plattformen verwaltet. Diese
Anwendungen müssen in einem Paket, dem so genannten MSI-Paket, eingeschlossen
sein. Das MSI-Paket besteht aus einer MSI-Datei und externen Quelldateien, die auf
diese Datei zeigen. Das Paket enthält alle Informationen, die der Microsoft Windows
Installer zur Ausführung der Benutzeroberfläche und zur Installation bzw. Deinstallation
der Anwendung benötigt.
Die MSI-Datei enthält eine Installationsdatenbank, einen Datenstrom mit
Zusammenfassungsinformationen und Datenströme für verschiedene Teile der
Installation. Die Logik und die Daten, die für eine Installation erforderlich sind, werden
in einer relationalen Datenbank in der MSI-Datei verwaltet. Zusätzlich kann die MSIDatei auch eine oder mehrere Transformationen, interne und externe Quelldateien oder
Cabinet-Dateien enthalten, die für die Installation erforderlich sind.
Eine Transformation ist eine Erfassung von Änderungen, die auf eine Installation
angewendet werden. Der Installer kann Daten in der Installationsdatenbank hinzufügen
oder ersetzen, indem er eine Transformation auf ein Basisinstallationspaket anwendet.
Eine Transformation wechselt z. B. die Sprache des Textes einer
Anwendungsoberfläche. Transformationen werden durch eine oder mehrere
Transformationsdateien (.mst) angegeben. Der Installer kann Transformationen nur
während einer Installation anwenden.
Eine Cabinet-Datei ist eine einzelne Datei, in der Regel mit der Erweiterung CAB, die
komprimierte Dateien in einer Dateibibliothek speichert.
Der Microsoft Windows Installer organisiert Installationen auf der Grundlage des
Konzepts der Komponenten und Funktionen. Komponenten sind Teile der Anwendung
oder des Produkts, die installiert werden. In der Regel bleiben sie dem Benutzer
verborgen. Funktionen stehen den Benutzern zur Verfügung und werden in der Regel
durch die Funktionalität der Anwendung aus Benutzersicht bestimmt.
MSI-Pakete können in der Softwarepaketbibliothek mit Hilfe des
Registrierungsassistenten für MSI-Pakete registriert werden. Mit diesem Assistenten
können Sie das MSI-Paket registrieren, eine Verwaltungsinstallation nutzen bzw.
ausführen und dann verwenden. Der Assistent führt Sie durch den
Registrierungsvorgang, bei dem Sie beispielsweise Prozeduren und Eigenschaften
hinzufügen können. Ferner können Sie separate Pfade für das MSI-Paket und die MSIDatei festlegen.
Möglicherweise erhalten Sie irgendwann ein MSI-Patch-Paket von einem Ihrer
Softwareanbieter. Weitere Informationen zum Hinzufügen dieser Patch-Pakete zu
Verwaltungs- oder lokalen Installationen finden Sie unter Registrieren und Installieren
eines MSI-Patch-Pakets (siehe Seite 67).
Mittels eines Datenträgers, z. B. einer CD, können Sie registrierte MSI-Pakete offline an
Zielcomputer verteilen. Der kombinierte Einsatz einer registrierten Prozedur und eines
Datenträgers ist dann sinnvoll, wenn Sie eine Verwaltungsinstallation nicht nur auf dem
Domänen-Manager, sondern auch auf den untergeordneten Scalability-Servern
ausführen möchten, um die Bandbreitenanforderungen zu reduzieren. Eine Anleitung
zum Erstellen einer Offline-Prozedur für eine Verwaltungsinstallation unter Verwendung
einer CD finden Sie unter Verwenden einer Offline-Prozedur für eine
Verwaltungsinstallation mit einer CD (siehe Seite 70).
Hinweis: Da einige Produkte Systemdateien aktualisieren oder Änderungen an der
Windows-Registrierung vornehmen, kann eine Installation fehlschlagen, wenn ein
Installationsjob an ein Benutzerprofil gesendet wird, das nicht über die erforderlichen
Zugriffsrechte verfügt.
Verwenden des Windows Installer mit erhöhten Rechten
Verwenden Sie zum Ausführen von Windows Installer mit erhöhten Berechtigungen den
Systemrichtlinien-Editor ("poledit.exe" für Windows NT ) oder den GruppenrichtlinienEditor ("gpedit.msc" und Active Directory für Windows ;2000/2003/XP), um "Immer mit
erhöhten Berechtigungen installieren" für Windows Installer zu aktivieren. Es muss
sowohl die Computerkonfiguration als auch die Benutzerkonfiguration geändert
werden.
Wenn Sie auf diese Weise "Immer mit erhöhten Rechten installieren" für Windows
Installer aktivieren, überschreiben Sie alle CA ITCM-Einstellungen (da CA ITCM niemals
Windows Installer-Berechtigungen herab-, sondern lediglich heraufsetzt).
Wenn für den Windows Installer nicht "Immer mit erhöhten Rechten installieren"
aktiviert werden soll, können Sie mit zwei weiteren CA ITCM-Tools arbeiten:
■
Wenn Sie das Kontrollkästchen "Nicht mit erhöhten Berechtigungen installieren"
nicht aktivieren, wird die Eigenschaft "sdprop_installelevated" für alle Installations-,
Deinstallations- und Konfigurationsprozeduren ausgewählt, die für das aktuelle
Softwareelement registriert sind. Das heißt, die Eigenschaft wird für alle Prozeduren
eingestellt, die für das Element registriert sind. Eine Ausnahme bilden die
Prozeduren Verwaltungsinstallation, Verwaltungsinstallation entfernen, Erkennen
und Prüfen.
■
Wenn Sie das Kontrollkästchen "Nicht mit erhöhten Berechtigungen installieren"
aktivieren, können Sie trotzdem Installationen mit erweiterten Berechtigungen
vornehmen. Dazu richten Sie die Eigenschaft "sdprop_installelevated" für die
entsprechenden Installations-, Deinstallations- und Konfigurationsprozeduren ein,
die für das aktuelle Softwareelement registriert sind. Dazu lassen Sie das Element
unversiegelt und verwenden Eigenschaften für die Prozedur(en), die für Sie nach
der Registrierung von Interesse sind. Öffnen Sie zunächst die Registerkarte
"Eingebettete Datei" und dann die Registerkarte "MSI-Eigenschaften", auf der Sie
MSI-Eigenschaften hinzufügen oder entfernen können.
Unbeaufsichtigte Verteilung von Microsoft Windows Installer
Die Microsoft Windows Installer Engine (MSI) ist Teil der Windows-Betriebsumgebung.
Installationen können nur durchgeführt werden, wenn auf dem Zielcomputer Windows
Installer vorhanden ist. Auf Computern, auf denen ein Windows-Betriebssysteme läuft,
muss der Windows Installer-Dienst installiert werden.
Registrieren und Installieren eines MSI-Patch-Pakets
Microsoft Windows Installer verwendet ein Patch-Paket mit der Dateierweiterung MSP
zum Korrigieren von Verwaltungsinstallationen oder lokalen Installationen.
Ausführen von Patch-Vorgängen für Verwaltungsinstallationen
Wenn Sie die Software, die Sie korrigieren möchten, mit Hilfe von "MSI-Pakete
registrieren" registriert haben, gehen Sie wie folgt vor, um Verwaltungsinstallationen
mit Netzwerk-Installationsprozeduren zu korrigieren.
1.
Wählen Sie das MSI-Element, für das der Patch-Vorgang durchgeführt werden soll,
in der Softwarepaketbibliothek aus.
2.
Klicken Sie mit der rechten Maustaste auf den Prozedurenordner, und wählen Sie
im Kontextmenü "Neu", "Hinzugefügte Prozedur mit neuen Dateien" aus.
3.
Geben Sie auf der Registerkarte "Allgemein" einen Namen für die Prozedur ein. Der
Task muss "Configure" lauten, und als Betriebssystem muss Windows 32-Bit
eingestellt sein.
4.
Suchen Sie auf der Registerkarte "Hinzugefügte Dateien" die MSP-Datei. Als Typ
sollte "MSI-Datei" eingestellt sein.
5.
Für die MSI-Dateien werden drei Registerkarten geöffnet. Wählen Sie auf der
Registerkarte "Allgemein" als MSI-Methode die Option "PatchVerwaltungsinstallation".
Das Paketfeld "$msi\... $msi" wird auf den Pfad des Verzeichnisses erweitert, in
dem die Verwaltungsinstallation des aktuellen Elements erfolgt ist.
6.
Geben Sie den Namen der MSI-Datei an, der ursprünglich bei der Registrierung des
Pakets verwendet wurde.
7.
Klicken Sie auf "OK", um die Registrierung der Patch-Prozedur abzuschließen.
Hinweis: Wenn Sie bei der Registrierung des zu korrigierenden MSI-Pakets entweder
"Verwaltungsinstallation verwenden" oder "Verwaltungsinstallation ausführen und
verwenden" ausgewählt haben, sollten Sie die Schaltfläche zum Durchsuchen rechts
neben dem Paketfeld verwenden, um die tatsächliche MSI-Datei der
Verwaltungsinstallation anzugeben.
Führen Sie schließlich die neue Konfigurationsprozedur auf dem Software DeliveryManager aus, um den Patch auf die Verwaltungsinstallation anzuwenden.
Patch-Vorgang bei vorhandenen Installationen
Da für Ihr MSI-Paket nun ein Patch auf die Verwaltungsinstallation angewendet wurde,
verwenden alle neuen Installationsanforderungen, die mittels einer der
Netzwerkinstallationsprozeduren (die immer eine Verwaltungsinstallation verwenden)
an die Ziele gesendet werden, das aktuelle Installationspaket.
Bei vorhandenen Installationen müssen Sie eine Prozedur zum Anwenden von Patches
ausführen, um die aktuellsten Patch-Dateien zu installieren. Gehen Sie folgendermaßen
vor, um den Patch auszuführen:
1.
Wählen Sie das MSI-Element aus, für das die Prozedur in der
Softwarepaketbibliothek erstellt werden soll (die MSI-Datei, die bei der
ursprünglichen Registrierung des Pakets verwendet wurde).
2.
3.
eingestellt sein. Suchen Sie auf der Registerkarte "Hinzugefügte Dateien" die MSPDatei. Als Typ sollte "MSI-Datei" eingestellt sein. Wählen Sie auf der Registerkarte
"Allgemein" für MSI-Dateien als MSI-Methode "Patch-Installation" aus.
Es wird kein Paketfeld angezeigt.
4.
Diese Prozedur können Sie nun zur Aktualisierung der Ziele verwenden, auf denen alte
MSI-Pakete installiert sind.
Patch-Vorgang für lokale Installationen
Wenn Sie bei der Registrierung des zu korrigierenden MSI-Pakets "MSI-Paket
registrieren" ausgewählt haben und die lokalen Installationsprozeduren verwenden
möchten, die in diesem Fall registriert sind, sollten Sie die Patch-Prozedur wie im
Folgenden beschrieben erstellen.
Hinweis: In diesem Fall gibt es keine Möglichkeit, das Produkt in der
Softwarepaketbibliothek zu korrigieren. Daher muss bei Paketen, die lokale
Installationsprozeduren verwenden, nachträglich ein Patch angewendet werden, um sie
auf die neueste Version zu aktualisieren.
1.
Wählen Sie das MSI-Element aus, für das die Prozedur in der
Softwarepaketbibliothek erstellt werden soll.
2.
3.
eingestellt sein.
4.
Suchen Sie auf der Registerkarte "Hinzugefügte Dateien" die MSP-Datei. Als Typ
sollte "MSI-Datei" eingestellt sein.
5.
Für MSI-Dateien werden drei Registerkarten angezeigt. Wählen Sie auf der
Registerkarte "Allgemein" als MSI-Methode die Option "Patch-Installation".
Es wird kein Paketfeld angezeigt.
6.
Sie können nun diese Prozedur zur Aktualisierung der Ziele verwenden. Bei Zielen, auf
denen das alte MSI-Paket installiert ist, genügt die Ausführung der neuen
Konfigurationsprozedur. Bei neuen Installationen muss sowohl die lokale
Installationsprozedur als auch die neue Konfigurationsprozedur ausgeführt werden.
Verwenden einer vorhandenen Verwaltungsinstallation als Quelle für ein Softwareelement
Bei der Registrierung eines MSI-Pakets können Sie zwischen den Optionen
"Verwaltungsinstallation verwenden" oder "Verwaltungsinstallation ausführen und
verwenden" wählen.
Das ist beispielsweise dann nützlich, wenn in Ihrer Umgebung bereits eine Reihe von
Verwaltungsinstallationen vorhanden sind und Sie diese nun mit Hilfe von Software
Delivery verwalten möchten, ohne sie erneut installieren oder sogar ihre Quelle in der
Softwarebibliothek registrieren zu müssen. Sie werden jedoch nicht die mit diesen
Elementen verknüpften Dateien an die untergeordneten Domänen-Manager oder
Scalability-Server verteilen können, da die Quelle als extern definiert wurde. Alle
Prozeduren werden auf den ursprünglichen Speicherort der Verwaltungsinstallation
verweisen. Sie werden die mit dem Element verknüpften Dateien auch dann nicht an die
untergeordneten Scalability-Server verteilen können, wenn Sie die MSI-Bibliothek als
Speicherort für die externe Verwaltungsinstallation angeben. Die einzige Möglichkeit,
wie Sie die Quelle als Teil des Elementes an untergeordnete Server verteilen können,
besteht darin, sie wirklich in der Softwarepaketbibliothek zu registrieren oder
einzubetten.
Verwenden einer Offline-Prozedur für eine Verwaltungsinstallation mit einer CD
So erstellen Sie Offline-Verwaltungsinstallationsprozeduren für die Verteilung von
registrierten MSI-Paketen:
1.
Suchen Sie das MSI-Element in der Softwarepaketbibliothek.
2.
Suchen Sie nach der registrierten Paketprozedur für die CD-Installation.
3.
Klicken Sie mit der rechten Maustaste auf die Prozedur, und wählen Sie "Neu
basierend auf" aus.
4.
Wählen Sie auf der Registerkarte "Externe Datei/Allgemein" als MSI-Methode
"Verwaltungsinstallation".
5.
Speichern Sie die Prozedur.
Die erstellte Prozedur kann jetzt mit Drag-and-Drop an die Ziele verteilt werden. Die
Zielcomputer fordern Sie auf, die CD einzulegen und die Verwaltungsinstallation
auszuführen.
Der kombinierte Einsatz einer registrierten Prozedur und einer CD ist dann sinnvoll,
wenn Sie eine Verwaltungsinstallation auf dem Domänen-Manager und auf den
untergeordneten Scalability-Servern ausführen müssen, um die
Bandbreitenanforderungen zu reduzieren.
Hinweis: Um Verwaltungsinstallationen auf Scalability-Servern auszuführen, verwenden
Sie bei der Registrierung des MSI-Elements in der Softwarepaketbibliothek die erste
Methode, die vom Registrierungs-Assistent für das MSI-Paket vorgeschlagen wird: "MSIPaket in Softwarepaketbibliothek registrieren". Aktivieren Sie im Dialogfeld "CDOptionen" das Kontrollkästchen "Installation von CD-ROM".
Wenn das Element in der Softwarepaketbibliothek registriert wurde, wählen Sie die
Verwaltungsinstallationsprozedur, und verteilen diese mit Drag-and-Drop an die
Scalability-Server.
Registrieren von Windows CE- und Palm-Paketen in der Softwarebibliothek
Die Windows CE- und Palm-Pakete werden mit spezifischen Dialogfeldern in der
Softwarepaketbibliothek registriert, d. h. mit dem Dialogfeld "WinCE-Paket
registrieren" und mit dem Dialogfeld "Palm-Paket registrieren". Mit Hilfe dieser
Dialogfelder können Sie neue Softwareelemente registrieren und ablegen, wenn sich die
Registrierungsinformationen auf dem Quellmedium befinden.
Die Anweisungen und Daten, die für die Installation von Windows CE-Anwendungen
benötigt werden, befinden sich entweder in einer Windows CE Cabinet-Datei (*.cab)
oder in einer Windows CE Application Manager-Datei (*.ini).
Die Anweisungen und Daten, die für die Installation von Palm-Paketen benötigt werden,
befinden sich in einer PRC-Datei.
Prüfen von Paketen auf Konsistenz
Die Paketkonsistenzprüfung bietet die Möglichkeit, Pakete vor Beschädigungen zu
schützen. Das heißt konkret, dass wenn Dateien hinzugefügt, entfernt oder durch
Dateien mit einem anderen Umfang im Paket ausgetauscht werden und die
Konsistenzprüfung für das Paket aktiviert ist, Software Delivery die Verteilung des
Pakets verweigert und eine Fehlermeldung zurückgegeben wird.
Die Paketkonsistenzprüfung können Sie über den DSM-Explorer aktivieren bzw.
deaktivieren. Dazu öffnen Sie die Seite mit den Eigenschaften des betreffenden
Softwarepakets. Die Funktion zum Prüfen von Paketen auf Konsistenz ist beim
Importieren und Erstellen neuer Pakete standardmäßig aktiviert.
Eine Prüfsumme bezieht sich auf die Anzahl der Dateien sowie ihre Namen und ihren
Umfang, aber sagt nichts über den tatsächlichen Inhalt der Dateien aus.
Die Prüfsumme wird bei folgenden Gegebenheiten aktualisiert:
■
Eine Aktualisierung des Pakets (z. B. durch Hinzufügen von Dateien)
■
Registrieren neuer Softwarepakete
■
Wiederherstellen von Softwarepaketen
■
Automatisches Registrieren von Software
■
Versiegeln von Softwarepaketen
Bei folgenden Ereignissen wird die Prüfsumme gegen die vorher berechnete Prüfsumme
verifiziert:
■
Aktivierung der Konsistenzprüfung
■
Einrichtung neuer Lieferumgebungen
■
Vor der Ausführung einer nicht-externen Prozedur auf dem Agenten
Hinweise zur Berechnung der Prüfsumme
■
Die Prüfsummenkontrolle wird auch beim Registrieren von Produkten über die
Befehlszeile standardmäßig aktiviert.
■
Wenn ein Job für mehrere Ziele eingerichtet wurde und während seiner Verteilung
ein Prüfsummenfehler auftritt, enden alle Jobs, die bis zu diesem Punkt nicht
abgeschlossen sind, mit einem Fehler. Beispiel: Der Job für den ersten Zielcomputer
wird ordnungsgemäß ausgeführt. Bei der Lieferung an den nächsten Computer
entdeckt der Software Delivery-Manager einen Prüfsummenfehler. Daraufhin
schlagen die Jobs für den nächsten und alle darauffolgenden Zielcomputer fehl,
sofern der Prüfsummenfehler nicht behoben wird.
■
Für einen Software Delivery-Agenten erfolgt keine Prüfsummenberechnung,
solange er keinen Job ausführt.
Definieren von Kataloggruppen
Kataloggruppen verbinden Softwareelemente, um sie über die Benutzeroberfläche des
Katalogs bestimmten Gruppen von Benutzern zur Verfügung zu stellen. Sie können
Kataloggruppen im Ordner "Katalog", einem vordefinierten Verzeichnis in der
Softwarepaketbibliothek, durch Kopieren oder Drag-and-Drop einer Computer- oder
Benutzergruppe in den Knoten "Katalog" erstellen. Nachdem eine Software in eine
Kataloggruppe verschoben oder mit ihr verknüpft wurde, besteht eine Verknüpfung
zwischen einer bestimmten Computergruppe und der Kataloggruppe. Die
Kataloggruppe, die automatisch erstellt wird, hat denselben Namen wie die
Computergruppe.
Der Assistent zum Veröffentlichen im Katalog ist eine verbesserte, benutzerfreundliche
Methode zur Weitergabe von Software an Benutzer. So können Sie damit z. B. Software
aus mehreren Softwaregruppen auswählen. Der Assistent kann von
Bibliothekselementen und Computergruppen aus gestartet werden. Klicken Sie
z. B. mit der rechten Maustaste auf eine Computergruppe, und wählen Sie
"Softwarejob", "Software in Katalog veröffentlichen...", um den Assistenten zu starten.
Wenn sich ein Benutzer anmeldet, der einer oder mehreren Computergruppen angehört
und damit auch einer oder mehreren Kataloggruppen, ermittelt eine Software DeliveryFunktion, welche Software diesen Kataloggruppen zur Verfügung steht. Die Software
wird dann über die Benutzeroberfläche des Katalogs angezeigt.
Wenn z. B. Benutzer 1 der Kataloggruppe A angehört, sieht Benutzer 1 sämtliche
Software, die für Kataloggruppe A zur Verfügung steht, sowie die Software, die mit dem
Ordner "Katalog" verknüpft wurde. Wenn Benutzer 2 den Kataloggruppen A und B
angehört, sieht er alle Software, die für die Kataloggruppen A und B zur Verfügung steht,
sowie die Software, die mit dem Ordner "Katalog" verknüpft wurde. Wenn Benutzer 3
keiner Kataloggruppe angehört, sieht er lediglich die Software, die mit dem Ordner
"Katalog" verknüpft wurde, sofern dies überhaupt geschehen ist.
Wenn Sie Software in den Ordner "Katalog" ziehen (oder kopieren) und eine
Verknüpfung erstellen, steht diese Software allen Katalogbenutzern zur Verfügung. Den
Benutzern wird auch angezeigt, welche Software auf ihren Computern installiert ist.
Hinweis: Lediglich die Softwarepakete, bei denen mindestens eine Prozedur
katalogbasiert ist, sind auf der grafischen Benutzeroberfläche des Katalogs sichtbar.
Verknüpfen von katalogbasierten Prozeduren
Sie konnen festlegen, dass für automatisch registrierte Software, die katalogbasierte
Prozeduren enthält, eine Verknüpfung im Katalogordner erstellt wird, wenn sie in der
Software-Paket-Bibliothek registriert wird. Setzen Sie dazu die Richtlinie "SoftwareBibliothek: Software-Pakete automatisch zu Katalogordner hinzufügen" auf "True"
(Wahr). (Konfigurationsrichtlinie, Standardcomputerrichtlinie, DSM, Software Delivery,
Gruppe "Manager-Richtlinie")
Das gilt für folgende Fälle:
■
Die Software wird vom Enterprise-Manager auf einen Domänen-Manager
übertragen.
■
Mit einer der folgenden Methoden wird die Software über den DSM-Explorer
registriert:
SD-Paket registrieren, Ordner zum Registrieren von SD-Paketen einfügen, SD-Paket
als neue Version registrieren und gefundene Software in "Registriert" konvertieren.
■
Die Software wird über die Befehlszeile registriert.
Anzeigen von Bibliothekselementdaten
Sie können zusätzliche Informationen zu Programmen anzeigen, die bereits in der
Enterprise-Bibliothek oder Domänen-Bibliothek registriert wurden. Die angezeigten
Informationen entsprechen den Informationen, die zum Zeitpunkt der ursprünglichen
Registrierung zur Verfügung gestellt wurden. Zu diesen Angaben gehören der Name und
die Version des Programms und wahlweise der Name der Person, die das Programm bei
der Registrierung archiviert hat, der Zeitpunkt der Registrierung, der Name des
Herstellers/Anbieters sowie zusätzliche Kommentare, die vom Administrator während
der Registrierung eingegeben wurden.
Versiegelung eines Software-Elements aufheben
Normalerweise haben Softwareelemente (Programme) in der Software-Paket-Bibliothek
den Status "Versiegelt", der auch mit "Geschlossen" benzeichnet wird. In versiegeltem
Zustand kann ein Programm verteilt, installiert und exportiert werden.
Unter bestimmten Umständen können Sie die Versiegelung eines Softwareelements zur
Bearbeitung des Elements aufheben. Das Aufheben der Versiegelung eines
Softwareelements ist nicht möglich, wenn das Softwarepaket bereits installiert, geliefert
oder verteilt wurde. Weitere Informationen finden Sie in der Online-Hilfe zu DSM
Explorer.
Wenn Sie die Versiegelung eines Softwareelements aufheben möchten, klicken Sie mit
der rechten Maustaste in der Softwarepaketbibliothek auf das Element, und wählen im
Kontextmenü die Option "Versiegelung aufheben".
Hinweis: Die Anzeige von Softwareelementen wird von der Sicherheitskomponente von
CA ITCM gesteuert. Sie benötigen für das Anzeigen oder das Bearbeiten von
Softwareelementen folgende Zugriffsrechte:
■
Anzeigeberechtigung, um ein Softwareelement in der Bibliothek anzeigen zu
können
■
Leseberechtigung, um ein Softwareelement auswählen zu können
■
Schreibberechtigung, um ein Softwareelement versiegeln bzw. dessen Versiegelung
aufheben zu können.
Archivieren und Wiederherstellen von Softwareelementen
Sie können Softwareelemente mit Hilfe der Archivierungsoption von Software Delivery
archivieren. Mit Hilfe dieser Option können Sie ein geschlossenes Softwareelement aus
der Softwarepaketbibliothek archivieren. Wurde ein Element archiviert, ändert sich das
Symbol entsprechend. Archivierte Elemente haben die gleiche Struktur wie die
Elemente auf dem Quelldatenträger (z. B. DVD). Bei der Archivierung eines
Softwareelements wird das Quellverzeichnis entfernt, da sämtliche Dateien, die zuvor
dort gespeichert waren, in das angegebene Archivverzeichnis kopiert werden.
Nach der Archivierung eines Softwareelements kann es zu einem späteren Zeitpunkt mit
Hilfe der Wiederherstellungsfunktion von Software Delivery wiederhergestellt werden.
Wenn sich das Softwareelement immer noch an dem Speicherort befindet, an dem es
archiviert wurde, wird der Wiederherstellungsvorgang sofort in Gang gesetzt. Ist dies
nicht der Fall, wird eine Fehlermeldung zurückgegeben, die angibt, dass im
ursprünglichen Archivverzeichnis keine Registrierungsinformationen (reginfo) gefunden
wurden.
Hinweis: Wenn die Dateien z. B. auf ein Band verschoben wurden, müssen Sie sie
zunächst wiederherstellen und an einem bekannten Ort speichern, bevor Sie den
Wiederherstellungsvorgang starten können.
Nach der Wiederherstellung eines Softwareelements wird wieder das Symbol angezeigt,
das vor der Archivierung verwendet wurde. Der Quellverzeichnis des Softwareelements
wird ebenfalls wiederhergestellt.
Hinweise zum Prüfen auf Viren
Administratoren, die den DSM-Explorer unter einem Windows NT-basierten
Betriebssystem ausführen, wobei er entweder lokal auf demselben Rechner wie der
Manager oder als eigenständige Anwendung auf einem Remote-Computer installiert ist,
können eTrust Antivirus verwenden, sofern dieses Programm auf dem Manager
installiert ist.
Mit ihm können Sie entweder alle Bibliothekselemente, ein einzelnes
Bibliothekselement, ein Bibliothekselement-Volume oder eine BibliothekselementVolume-Datei nach Viren scannen.
Administratoren, die den DSM-Explorer auf einem Windows NT-basierten
Betriebssystem ausführen und eTrust Antivirus installiert haben, können den Scan auch
auf einem Enterprise- und Domänen-Manager mit einem Windows-NT-basierten
Betriebssystem durchführen.
Hinweis: Ein im Fernzugriff angebundener DSM-Explorer kann nur NOS-Verbindungen
zum Manager verwenden. Die Bibliothek muss im Netzwerk freigegeben sein.
Software und Prozeduren
Der Manager prüft, ob eTrust Antivirus, InocuLAN oder cavscan verwendet wird. Das
gefundene Virenprüfprogramm wird verwendet. Wird kein Virenprüfprogramm
gefunden, erfolgt eine Suche nach inocmd32. inocmd32 wird verwendet, wenn es
gefunden wird. Die Integration mit inocmd32 ermöglicht automatische Viren-Scans beim
Erstellen von Jobs.
Über die Benutzeroberfläche des DSM-Explorers können Sie einen manuellen Viren-Scan
der Software Delivery-Bibliothekspakete und der abgerufenen Elementdateien
durchführen. Dazu klicken Sie mit der rechten Maustaste auf einen Ordner oder ein
Objekt und wählen dann im angezeigten Kontextmenü die Option "Auf Viren scannen".
Bei Verwendung von InocuLAN oder eTrust Antivirus müssen Sie unter Umständen das
Kontrollkästchen Include Subdirectory (Unterverzeichnis einbeziehen) im Shell ScannerDialogfeld von InocuLAN oder eTrust Antivirus aktivieren, bevor Sie den Viren-Scan
starten.
Bei Verwendung von inocmd32 wird nach Beginn des Scans ein zunächst leeres DOSFenster angezeigt. Nach dem Scan wird dort das Ergebnis angezeigt. Schließen Sie das
Feld, wenn Sie sich das Ergebnis angeschaut haben.
In diesem Abschnitt wird beschrieben, wie Sie Elementprozeduren definieren.
Außerdem enthält er eine Einführung in Software- und Prozedurgruppen.
■
Definieren eingebetteter Elementprozeduren (siehe Seite 76)
■
Definieren hinzugefügter Elementprozeduren (siehe Seite 80)
■
Software- und Prozedurgruppen (siehe Seite 84)
Definieren eingebetteter Elementprozeduren
Mit Hilfe von Elementprozeduren werden Programme installiert, aktiviert, konfiguriert
und deinstalliert. Es gibt eingebettete oder hinzugefügte Elementprozeduren.
Eingebettete Elementprozeduren werden automatisch zur gleichen Zeit wie das
Programm selbst registriert. Hinzugefügte Elementprozeduren werden separat
registriert, nachdem das Element registriert wurde. Weitere Informationen zu
hinzugefügten Elementprozeduren finden Sie unter Definieren hinzugefügter
Elementprozeduren (siehe Seite 80).
Eingebettete Elementprozeduren sind in der Spalte Erstellt der Prozedurdetailanzeige
als Originallieferung gekennzeichnet.
Elementprozeduren geben Folgendes an:
■
Betriebssystem, unter dem die Elementprozedur ausgeführt wird
■
Prozedurtyp, wie Befehlsdatei, ausführbare Datei, SWD-Datei, MSI-Datei, SXP-Datei,
PKG-Datei, PIF-Datei, RPM-Datei, IPS-Datei, Palm-Datei oder WinCE-Datei
■
Name der Startprozedur, z. B. "SETUP.EXE"
■
Ob es sich bei der Prozedur um eine externe Prozedur handelt (d. h., wenn die
Prozedur bereits auf einem Zielcomputer existiert oder auf sie vom Zielcomputer
aus zugegriffen werden kann). Externe Prozeduren bieten die Möglichkeit, auf
Programme zu verweisen, die nicht in der Softwarepaketbibliothek registriert sind,
d. h. auf jedem Agenten mit absoluten Pfad angegeben sind, können aber immer
noch deren Ausführung mit dem Produkt verwalten.
■
Typ des von der Prozedur auszuführenden Tasks, wie INSTALL (INSTALLATION),
ACTIVATE (AKTIVIERUNG), UNINSTALL (DEINSTALLATION) oder CONFIGURE
(KONFIGURATION)
■
Parameter, die beim Start der Prozedur verwendet werden
■
Zusätzliche Dateien, die zur Ausführung der Prozedur erforderlich sind
■
Ob das Element für den Softwarekatalog aktiviert werden soll
Sie können die Elementprozeduren verwenden, die mit dem Programm geliefert werden
(wie SETUP.EXE), oder Sie können eigene benutzerspezifische Prozeduren mit Hilfe von
Stapel- oder Befehlsdateien erstellen. So können Sie beispielsweise eine
benutzerspezifische Installation für sämtliche Windows-Computer mit deaktivierter
Maus erstellen.
Ausschließen von Elementprozeduren von der RAC-Option (Reinstall After Crash)
Wenn eine Elementprozedur nicht als Teil des RAC-Prozesses ausgeführt werden soll,
können Sie die Option "Aus RAC ausschließen" im Dialogfeld "Eigenschaften" der
Prozedur auswählen. Diese Option kann sogar für versiegelte Softwareelemente
geändert werden und ermöglicht es so dem Administrator, veraltete Pakete vom RACProzess auszuschließen. Weitere Informationen dazu finden Sie unter RAC-Konfiguration
(siehe Seite 142).
Für die folgenden Elementprozeduren ist die Option "Aus RAC ausschließen" aktiviert:
■
Alle Aktivierungsprozeduren auf dem Software Delivery-Agenten:
Die drei Scan-Prozeduren (zum Scannen von MSI, SWD und SM InstallerInstallationen) und die Aktivierungsprozeduren von SM Installer.
■
Die folgende Konfigurationsprozedur auf dem Software Delivery-Agenten:
Netzwerkreparatur
■
■
Die folgenden Aktivierungsprozeduren auf dem Scalability-Server:
■
Software-Staging-Bibliothek synchronisieren
■
Softwarejob-Datensätze synchronisieren
■
CCS-Kalender synchronisieren
■
SDLIB-Freigabe aktivieren
■
SDLIB-Freigabe deaktivieren
■
MSILIB-Freigabe aktivieren
■
MSILIB-Freigabe deaktivieren
■
Boot-Server-Freigabe aktivieren
■
Boot-Server-Freigabe deaktivieren
Alle Neuinstallationsprozeduren für alle Paketformate.
Elementprozeduren in Stapelprogrammen
Durch eine bedingte Verarbeitung in Stapelprogrammen können Sie sicherstellen, dass
der Status für den Job, für den die Prozedur verwendet wird, nicht OK lautet, wenn das
Stapelskript fehlgeschlagen ist.
Bei Windows NT-basierten Systemen können Sie das integrierte IF mit ERRORLEVEL,
EXIST oder Zeichenfolgenvergleich, gefolgt von einem speziellen Befehl verwenden und
so sicherstellen, dass das Stapelskript mit einem Fehlercode und Abbruch beendet wird
und Software Delivery den Fehler erkennt.
So kopiert z. B. die folgende Befehlsdatei der Elementprozedur die Datei
"myfile.txt" in das Stammverzeichnis der Festplatte, sofern die Datei im Quellverzeichnis
existiert. Ist dies nicht der Fall, endet die Prozedurdatei mit einem Fehlercode.
@echo off
copy myfile.txt C:\*.*
IF ERRORLEVEL 1 EXIT
Wenn die Datei "myfile.txt" nicht gefunden wird, endet der Job mit Fehlercode
"SDM228001".
Weitere Informationen zur Ausführung bedingter Verarbeitungsprozesse in
Stapelprogrammen finden Sie in der Dokumentation zur jeweiligen Plattform. Bei
Windows NT-basierten Systemen können Sie eine Eingabeaufforderung öffnen
und "help if" oder "help exit" eingeben, wenn Sie weitere Informationen benötigen.
Task-Typen für Elementprozeduren
Die von einer Elementprozedur ausgeführten Tasks lassen sich einer von vier Kategorien
zuordnen, von denen der Task-Typ INSTALL der gebräuchlichste ist.
Die anderen Tasks sind ACTIVATE, CONFIGURE und UNINSTALL. Sie werden auch als
Nicht-Installationstask-Typen bezeichnet.
ACTIVATE
Leitet die Ausführung des Produkts ein. Der ACTIVATE-Task kann zum Beispiel
eingesetzt werden, um aus der Ferne ein Sicherungs- oder Archivierungsprogramm
zu starten. Wenn eine Elementprozedur nicht unter eine der drei anderen
Kategorien fällt oder eine Kombination aus den anderen Tasks bildet, sollte sie als
ACTIVATE-Task definiert werden.
CONFIGURE
Nimmt an einer bestehenden Installation eine Neukonfiguration vor.
INSTALL
Installiert das Produkt.
UNINSTALL
Entfernt die Installation.
Hinweis: Die Prozeduren ACTIVATE, CONFIGURE und UNINSTALL können nur auf
Computern ausgeführt werden, auf denen das Element bereits installiert wurde, d. h.
mit einer Prozedur des Typs INSTALL installiert wurde. Die meisten Softwarepakete
enthalten nur die Prozeduren INSTALL und UNINSTALL. CONFIGURE sowie angepasste
INSTALL- und ACTIVATE-Tasks können durch die Registrierung von vor Ort
geschriebenen Skripten, Befehlen oder Batch-Dateien erstellt werden. Weitere
Informationen zu angepassten Elementprozeduren finden Sie unter Optionale
Anpassungs-Tools (siehe Seite 50).
Im Gegensatz zu anderen Software Delivery-Agenten haben Agenten ohne NOS keinen
Zugriff auf die lokale Bibliothek des Managers. Aus diesem Grund kann Software
Delivery nicht festlegen, welche Elementprozeduren für Nicht-Installationstask-Typen
erforderlich sind. Es wird deshalb das vollständige Bibliothekselement an den Agenten
übermittelt. Im Falle eines umfangreichen Bibliothekselements kann dieser Vorgang
sowohl zeitaufwändig als auch ressourcenintensiv sein. Um die Lieferung des Pakets zu
vermeiden, sollten Sie externe Prozeduren verwenden.
Definieren hinzugefügter Elementprozeduren
Wenn Sie eine Elementprozedur vor der Registrierung eines Programms geschrieben
haben, können Sie diese während der Registrierung als eingebettete Elementprozedur
hinzufügen; die meisten angepassten Prozeduren sind jedoch als hinzugefügte
Elementprozeduren definiert.
Hinzugefügte Elementprozeduren werden nach der Registrierung des Programms, zu
dem sie gehören, in der Softwarepaketbibliothek erstellt oder registriert. Sie können
neu erstellt oder aus vorhandenen Prozeduren kopiert werden.
Hinzugefügte Elementprozeduren werden vom Enterprise-Manager nicht automatisch
mit dem Softwarepaket an die Domänen geliefert. Wenn Sie jedoch einem
Verteilungscontainer eine Registrierungsanweisung für ein Softwareelement
hinzufügen, das hinzugefügte Elementprozeduren enthält, können Sie Software Delivery
anweisen, dem Verteilungscontainer auch automatisch Registrierungsanweisungen für
zugeordnete Elementprozeduren hinzuzufügen. Ferner können Sie festlegen, dass nur
für ausgewählte Prozeduren Registrierungsanweisungen erstellt werden. Bei einem
Fehler während der automatischen Erstellung einer Registrierungsanweisung für eine
der hinzugefügten Elementprozeduren können Sie wahlweise mit der automatischen
Erstellung von Registrierungsanweisungen für die verbleibenden Prozeduren fortfahren.
Hinzugefügte Prozeduren können nur bei den Bibliotheken des Enterprise-Managers
und Domänen-Managers registriert werden. Eine Registrierung bei den Bibliotheken des
Scalability-Servers ist nicht möglich. Dies ist unbedingt zu beachten. Wenn hinzugefügte
Prozeduren mit neuen Dateien über Remote-Scalability-Server auf Agenten installiert
werden sollen, wird das gesamte ursprüngliche Softwareelement und die hinzugefügten
Dateien von der Bibliothek des Domänen-Managers geliefert anstatt erneut die Dateien
zu verwenden, die beim Scalability-Server registriert wurden. Dies sollte vor dem
Verwenden von hinzugefügten Prozeduren berücksichtigt werden.
Die Alternative zu hinzugefügten Prozeduren ist das Erstellen neuer unabhängiger
Softwareelemente, die in den Bibliotheken des Scalability-Servers gespeichert werden
können.
Kopieren vorhandener Elementprozeduren
Sie können vorhandene Elementprozeduren kopieren, um eine neue Elementprozedur
zu erstellen, wenn es sich bei der neuen Elementprozedur um den gleichen Typ handelt
(z. B. CMD- oder EXE-Dateien) wie die vorhandene Elementprozedur. In diesem
Fall wird die vorhandene Elementprozedur als Modell verwendet, und Sie können
beliebige Veränderungen vornehmen. Lediglich der Typ der Prozedur und das Programm
lassen sich nicht verändern.
Verknüpfen von Elementprozeduren, Aufheben der Verknüpfung und Hinzufügen neuer
Elementprozeduren
Elementprozeduren können verknüpft werden, Verknüpfungen lassen sich aufheben,
und neue Elementprozeduren können zu Prozedurgruppen hinzugefügt werden. Wenn
Prozeduren in eine Prozedurgruppe gezogen werden, können Sie im angezeigten
Kontextmenü die Prozedur mit der Zielprozedurgruppe verknüpfen.
Die Verknüpfung einer Prozedur mit einer Prozedurgruppe, deren Teil sie ist, kann auch
aufgehoben werden. Nach Ausführung dieses Vorgangs wird sie nicht mehr in dieser
Gruppe angezeigt.
Die Reihenfolge in der Prozedurgruppe ist wichtig (siehe Spalte "Auftragsnummer" in
der GUI) und kann anschließend über ein Kontextmenü geändert werden.
Definieren von Prozedurabhängigkeiten
Mit Hilfe von Prozedurabhängigkeiten können Sie Voraussetzungsprozeduren für
Bibliothekselemente definieren. Dies ist hilfreich, wenn eine Prozedur eine oder
mehrere andere bereits erfolgreich ausgeführte Prozeduren erfordert, bevor die
aktuellen Prozeduren ausgeführt werden können.
Wenn Sie eine Prozedur mit Abhängigkeiten aus der Softwarepaketbibliothek wählen,
werden diese Abhängigkeiten in dem im rechten Fensterbereich angezeigten Ordner
"Prozedurabhängigkeiten" aufgelistet. Nur Installationsprozeduren können abhängige
Prozeduren sein. Wenn ein Job unter Verwendung der übergeordneten Prozedur im
Ordner ausgeführt wird, prüft Software Delivery, ob die als Voraussetzung zu
erfüllenden Prozeduren ausgeführt wurden. Wenn nicht, werden zunächst diese
Prozeduren ausgeführt. Dabei gilt die Reihenfolge; in der sie im Ordner
"Prozedurabhängigkeit" aufgeführt sind.
Hinweis: Die Deinstallation von abhängigen Voraussetzungsprozeduren führt nicht
automatisch zu einer Deinstallation der abhängigen Prozeduren.
Prozeduren können mehrere Abhängigkeitsebenen haben. Eine Prozedur im
Prozedurabhängigkeitsordner kann beispielsweise ihrerseits wieder eine
Prozedurabhängigkeit aufweisen. Bei der Auswertung des Jobcontainers werden alle
diese Abhängigkeiten berücksichtigt. Daraufhin werden Jobs erzeugt, die wiederum
andere Jobs erzeugen können.
Spezielle Agentenprozeduren
Zusätzlich zu den Installationsprozeduren, die zur Installation unterschiedlicher Arten
von Software verwendet werden, verfügen die Software Delivery-Agenten über einige
spezialisierte Prozeduren. Dazu gehört:
■
Prozedur für Microsoft Installer (MSI) (siehe Seite 82)
■
Prozedur für Softwareerkennung (SWD) (siehe Seite 82)
■
Software Management Installer-Optionen (siehe Seite 82)
Prozedur für Microsoft Installer
"MSI scannen", die Prozedur für Microsoft Installer (MSI), scannt die Software, die von
Microsoft Installer installiert wurde, für Agenten auf Windows NT-basierten Systemen.
Prozedur für Softwareerkennung (SWD)
Die Prozedur "SWD scannen" sucht mit Hilfe von Softwareerkennungsscripts für
Software Delivery-Agenten auf Windows NT-basierten Systemen, Linux und UNIX nach
Software.
Software Management Installer-Optionen
Die folgenden Prozeduren für Software Management stehen für Agenten auf Windows
und Linux/UNIX zur Verfügung, sofern keine anderen Angaben gemacht wurden.
SM Installer: Tracing aktivieren
Aktiviert die Tracing-Funktion des Software Management Installer.
SM Installer: Tracing deaktivieren
Deaktiviert die Tracing-Funktion des Software Management Installer.
SM Installer: Alle Traces abrufen
Ruft alle Software Management Installer-Traces ab.
SM Installer: Letztes Trace abrufen
Ruft das letzte Software Management Installer-Trace ab.
SM Installer: Verlauf abrufen
(Nicht für Linux- und UNIX-Agenten verfügbar)
Ruft den Verlauf von Installations- und Deinstallationsvorgängen des Software
Management Installer ab.
SM Installer: Benutzer-Trace abrufen
Ruft das letzte Software Management Installer-Benutzer-Trace ab.
SM Installer: Benutzerverlauf abrufen
Ruft den Verlauf von benutzerspezifischen Installations- und
Deinstallationsvorgängen des Software Management Installer ab.
SM Installer-Installationen scannen
Sucht nach Software, die vom Installationsprogramm des Software ManagementAgenten installiert wurde, und meldet die Ergebnisse an den Domänen-Manager.
Prozeduren für den Softwarekatalog
Der Softwarekatalog ist über das Installationspaket "CA DSM Agent + Software Delivery
Plugin" erhältlich.
Das Installationspaket enthält folgende Installationsprozeduren:
Katalog: Hinzufügen
Installiert den Katalog auf einem Agentensystem.
Katalog: Entfernen
Entfernt die Kataloginstallation aus einem Agentensystem.
Scalability-Server-Prozeduren
Zu den Prozeduren auf dem Scalability-Server gehören Konfigurations- und
Aktivierungsprozeduren.
Dies sind die Konfigurationsprozeduren auf dem Scalability-Server:
Boot-Server-Freigabe deaktivieren
Deaktiviert den Zugriff auf die Boot-Server-Freigabe
MSILIB-Freigabe deaktivieren
Verhindert den Zugriff auf die MSI-Bibliothek über die Agenten.
SDLIB-Freigabe deaktivieren
Verhindert den direkten Zugriff auf die Software-Staging-Bibliothek über die MS
NOS-Agenten.
Boot-Server-Freigabe aktivieren
Aktiviert den Zugriff auf die Boot-Server-Freigabe
MSILIB-Freigabe aktivieren
Aktiviert den Zugriff von Agenten auf die MSI-Bibliothek.
SDLIB-Freigabe aktivieren
Aktiviert den direkten Zugriff von MS NOS-Agenten auf die Software-StagingBibliothek.
Dies sind die Aktivierungsprozeduren auf dem Scalability-Server:
CCS-Kalender synchronisieren
Synchronisiert die CCS-Kalender auf dem Scalability-Server und dem Manager,
nachdem der Kalender auf dem Manager aktualisiert wurde.
Softwarejob-Datensätze synchronisieren
Nur nach schwerem Manager-Fehler auszuführen, um verlorene Jobergebnisse
wiederherzustellen und den Inhalt der gelieferten Elemente mit der SoftwareStaging-Bibliothek zu synchronisieren.
Software-Staging-Bibliothek synchronisieren
Synchronisiert den Inhalt gelieferter Elemente mit der Software-Staging-Bibliothek.
Software- und Prozedurgruppen
Softwaregruppen werden zum Bündeln von Softwarepaketen in der
Softwarepaketbibliothek verwendet. Jede Softwaregruppe kann individuelle
Softwarepakete, Installationsprozedurgruppen oder andere Softwaregruppen enthalten,
die wiederum Teil einer weiteren Softwaregruppe sein können. So kann z. B. das
Softwarepaket mit der Bezeichnung "Textverarbeitung" Teil der Softwaregruppe "OfficeSoftware" und der Softwaregruppe "Häufig verwendete Programme" sein.
Die Softwarepaketbibliothek enthält zunächst drei vordefinierte Softwaregruppen, und
zwar "Gesamte Software", "DSM-Softwarepakete" und "Katalog". Die Gruppe "Gesamte
Software" enthält sämtliche registrierten Softwarepakete. Die Gruppe "DSMSoftwarepakete" enthält alle automatisch registrierten DSM-Pakete. Der Ordner Katalog
ist anfänglich leer. Kataloggruppen können jedoch im Nachhinein hinzugefügt werden.
Weitere Informationen zu Kataloggruppen finden Sie unter Definieren von
Kataloggruppen (siehe Seite 72).
Erneuern und Wiederherstellen fehlgeschlagener Installationen
Die Verwendung von Softwaregruppen bietet eine schnelle und einfache Möglichkeit zur
Installation mehrerer einzelner Softwarepakete. So kann z. B. die Gruppe "OfficeSoftware" ein Textverarbeitungspaket, ein Grafikpaket und ein
Tabellenkalkulationspaket enthalten. Die Pakete können zusammen als Teil der OfficeSoftwareinstallation installiert werden.
Prozedurgruppen enthalten Verknüpfungen zu einzelnen Softwarepaketen und werden
bei der Definition von Installationsjobs verwendet.
Die Prozedurengruppe enthält die Prozeduren, die zur Installation der Softwarepakete
verwendet werden. Die Prozeduren in einer Prozedurengruppe können geordnet
werden.
Erneuern und Wiederherstellen fehlgeschlagener
Installationen
Wenn ein Installationsauftrag für einen oder mehrere Zielcomputer fehlschlägt, können
Sie den fehlgeschlagenen Job mit Hilfe einer Deinstallationsprozedur bereinigen, die für
das entsprechende Bibliothekselement registriert ist.
In den folgenden Situationen ist es ratsam, eine fehlgeschlagene Installation zu
erneuern, anstatt sie wiederherzustellen:
■
Die Jobausführung ist für einen oder mehrere Zielcomputer fehlgeschlagen, und
■
es warten keine weiteren zu aktivierenden Computer.
Hinweis: Wenn Sie einen Jobcontainer erneuern, ist die Eigenschaft "Überlappende
Installation von abhängigen Paketen ignorieren" automatisch aktiviert und kann nicht
bearbeitet werden. Dadurch wird sichergestellt, dass der erneuerte Jobcontainer genau
dieselben Jobs enthält wie der fehlgeschlagene Jobcontainer. Wenn der ursprüngliche
Jobcontainer aufgrund einer fehlenden Prozedurabhängigkeit fehlgeschlagen ist, wird
bei der Erneuerung dieses Jobcontainers die Prozedurabhängigkeit ignoriert, und es
wird versucht, das abhängige Softwarepaket zu installieren. Dies geschieht nur, wenn
die Prozedur physisch fehlt. Wenn die überlappende Prozedur vorhanden ist und ihre
Installation einfach fehlschlägt, wird sie bei einer Erneuerung eingefügt.
Lieferung und Staging von Software
Nachdem ein Softwarepaket in der Enterprise-Bibliothek oder der Domänen-ManagerBibliothek registriert ist, kann es durch Erstellen und Senden von Aufträgen an andere
Computer im Netzwerk verteilt werden. Aufträge, die vom Enterprise gesendet werden,
sind in Containern zusammengefasst, die weitere Aufträge enthalten können. Aufträge
eines Domänen-Managers werden in Jobcontainern an die Zielcomputer oder
Zielcomputergruppen gesendet.
Hinweis: Falls die Viren-Scan-Software von CA Technologies auf dem EnterpriseManager oder Domänen-Manager installiert ist, scannt CA ITCM automatisch den Inhalt
eines Verteilungscontainers auf dem Enterprise-Manager, wenn eine Verteilung
gesendet wird. Auch der Inhalt eines Jobcontainers auf einem Domänen-Manager wird
automatisch gescannt, wenn eine Verteilung empfangen wird. Bei der Einrichtung eines
Jobcontainers wird der Inhalt des Jobcontainers automatisch gescannt.
Anweisungen
Es stehen folgende Auftragsstypen für Zwecke der Softwarelieferung zur Verfügung:
Registrierungsaufträge für Bibliothekselemente
Verteilen registrierte Elemente und Elementprozeduren aus der
Softwarepaketbibliothek auf dem Enterprise-Manager an die Domänen-ManagerBibliotheken. Die Aufträge zum Registrieren von Elementen umfassen das
Bibliothekselement und die dazugehörigen Registrierungsinformationsdateien.
Softwareprogramme müssen in der Softwarepaketbibliothek auf dem DomänenManager registriert sein, damit sie vom Domänen-Manager verteilt werden können.
Sie können auch neue Versionen von Softwarepaketen erstellen und das DeltaLieferverfahren verwenden, d. h. es werden nur solche Dateien verteilt, die sich von
der zuvor verteilten Version unterscheiden.
Installations- und Deinstallationsaufträge
Installieren oder Deinstallieren ein Programm auf einem Computer oder einer
Computergruppe.
Elementabrufaufträge
Rufen bestimmte Dateien von den Domänen-Managern ab und laden sie an einem
festgelegten Ort auf dem Enterprise-Manager.
Aufträge zum Aufheben der Registrierung eines Bibliothekselements
Heben die Registrierung des Programms auf und löschen Elemente aus der
Softwarepaketbibliothek oder den Computergruppen eines Domänen-Managers.
Wenn die Registrierung eines Programm aufgehoben und das Programm gelöscht
wurde, wird auch die Registrierung aller damit zusammenhängenden
Elementprozeduren (eingebettete und hinzugefügte) aufgehoben.
Die Registrierung von Elementen aus einer Softwarepaketbibliothek auf einem
Domänen-Manager kann nur dann aufgehoben und die Elemente können nur dann
gelöscht werden, wenn sie ursprünglich vom Enterprise-Manager verteilt und nicht
auf einem Computer in der Domäne installiert wurden.
Aktivierungsaufträge
Aktivierungsanweisungen starten das entsprechende Programm. So können Sie mit
einer Aktivierungsanweisung z. B. das Starten eines Archivierungsprogramms
auf einem Remote-Computer auslösen.
Konfigurationsanweisungen
Konfigurationsanweisungen führen Änderungen in den Konfigurationsdateien auf
einem Remote-Computer durch. Konfigurationstasks werden als
Elementprozeduren definiert.
Softwarerichtlinienaufträge
Registrieren Softwarerichtlinien bzw. heben die Registrierung der
Softwarerichtlinien auf den Domänen-Managern auf.
Bibliothekswartungsaufträge
Bereinigen Software und markieren sie in den Bibliotheken der Domänen-Manager
als archiviert, z. B. nicht häufig verwendete Software. So kann Speicherplatz gespart
werden. Bei Bedarf kann die Software wiederhergestellt werden.
Die folgende Abbildung zeigt den Auftragsfluss von einem Enterprise-Manager zum
Domänen-Manager (in Verteilungscontainern) und von dort zu den Zielcomputern (in
Jobcontainern).
Sobald die Jobs an die Zielcomputer geliefert wurden, kann der Software DeliveryManager (SD-Manager) oder der Software Delivery-Agent (SD-Agent) den Job auf dem
Zielcomputer ausführen.
Aufträge können auch einen Auslöser enthalten, so dass der SD-Manager den Job
startet. Wenn kein Auslöser vorhanden ist, nimmt der Agent mit Hilfe der Jobprüfung
den Kontakt zum Manager auf und startet den Job. Die Anweisungen gelangen in die
Warteschlange, bis die Jobprüfung nach vorhandenen Anweisungen sucht. Die
Häufigkeit dieser Prüfung hängt von den Optionen der Jobprüfung ab, die im
Betriebssystem verfügbar sind, das auf dem Zielcomputer ausgeführt wird.
Elementprozeduren enthalten Aufträge zum Installieren, Deinstallieren, Aktivieren und
Konfigurieren von Elementen auf Zielcomputern. Wenn eine Anweisung empfangen und
aktiviert wird, wird die Elementprozedur gestartet, als würde sie sich direkt auf diesem
Computer befinden.
Vom Domänen-Manager gesendete Aufträge
Aufträge werden vom Domänen-Manager mit Hilfe eines Jobcontainers an den
Zielcomputer gesendet. Domänen-Manager können sowohl individuelle Computer als
auch Computergruppen als Ziel haben.
Alle von einem Domänen-Manager gesendeten Aufträge können mit Hilfe einer der
beiden folgenden Methoden verteilt werden:
■
Vereinfachte Methode, die Standardeinstellungen verwendet
■
Benutzerspezifische Methode, in der Sie Joboptionen und Flags definieren können.
Neuinstallationsprozeduren können sich bei der Verwaltung der Software als nützlich
erweisen. Weitere Informationen finden Sie unter Neuinstallationsprozeduren (siehe
Seite 95).
Sie können einen Jobausführungskalender an einen bestimmten Computer, eine
bestimmte Computergruppe oder an die Gruppe "Alle Computer"/"Alle Benutzerprofile"
anhängen. Dazu müssen Sie mit der rechten Maustaste auf das Symbol für den
Computer oder die Gruppe klicken und die Optionen "Softwarejobs",
"Jobausführungskalender", "Anhängen" auswählen. Der Kalender kann zu einem
späteren Zeitpunkt auf ähnliche Weise wieder abgetrennt werden. Die
Kalenderdefinitionen zu Tagen, Daten und Zeitpunkten hinsichtlich der Durchführung
von Prozessen werden verwendet, um die Ausführung von Software-Jobs zu
überwachen.
Sie können auch einen Jobverteilungskalender verwenden. Auf der Registerkarte
"Joboptionen" können Sie für jeden Job festlegen, ob Sie einen Jobverteilungskalender
verwenden möchten. Dieser Kalender dient der Steuerung von Lieferungen mit Hilfe von
Data Transport Service.
Konfigurationsanweisungen sind Aktivierungsanweisungen ähnlich. Für beide ist es
erforderlich, dass das zugehörige Bibliothekselement bereits installiert wurde. Das ist
auch eine Voraussetzung für Deinstallationsaufträge.
Einrichten von Jobcontainern auf dem Domänen-Manager
Jobs können einem Jobcontainer hinzugefügt werden, so dass mehrere Jobs in einer
Gruppe zusammengefasst sind. Jobcontainer werden bei der Einrichtung von Jobs für
Computer oder Computergruppen automatisch erstellt. Sie haben verschiedene
Möglichkeiten, um einen Jobcontainer zu erstellen:
■
Ziehen Sie mit der Maus Bibliothekselemente (Software, Softwaregruppe, Prozedur
oder Prozedurgruppe) auf einen Computer oder eine Computergruppe.
Wenn Sie den Drag-and-Drop-Vorgang mit der linken Maustaste durchführen, wird
der Job sofort mit den Standardeinstellungen eingerichtet. Wenn Sie die rechten
Maustaste verwenden, wird nach dem Ablegen ein kleines Popup-Fenster geöffnet,
in dem Sie die benutzerdefinierten Optionen festlegen können.
■
Kopieren Sie Bibliothekselemente in die Zwischenablage, und fügen Sie sie
anschließend für den Computer oder die Computergruppe ein.
■
Verwenden Sie den Assistenten zum Bereitstellen von Software.
Der Assistent kann von einem Bibliothekselement, einem Computer, einer
Computergruppe und vom Ordner "Softwarejobs" aus gestartet werden.
■
Klonen Sie die Installationen auf einem Zielcomputer, indem Sie "Softwarejobs",
"Neu", "Softwarebereitstellungsjob basierend auf Zielinstallationen" auswählen.
■
Wenn Sie einen neuen Jobcontainer erstellen möchten, verwenden Sie einen
vorhandenen Jobcontainer oder eine Softwarerichtlinie als Vorlage, klicken mit der
rechten Maustaste und wählen "Neu", "Softwarebereitstellungsjob basierend auf".
Bei Verwendung einer benutzerspezifischen Methode können Sie dem Jobcontainer
einen Namen zuweisen und Optionen für die Jobverknüpfung für den Jobcontainer
einrichten. Außerdem können Sie mit diesen Jobverknüpfungsoptionen festlegen, ob die
Jobs im Container unabhängig voneinander ausgeführt werden (keine Verknüpfung),
oder ob, falls ein Job fehlschlägt, die verbleibenden Jobs für dieses Ziel abgebrochen
werden sollen (Batch).
Hinweis: Das Verhalten bei der Stapelverarbeitung kann mit der Eigenschaft
'Transaktion aktivieren' des Jobcontainers angepasst werden. Wenn diese Eigenschaft
aktiviert ist, werden alle Jobs im Jobcontainer für ein Ziel mit mindestens einem
fehlgeschlagenen Job, während der Evaluierung im Domänen-Manager auf "Fehler"
gesetzt. Dies gilt unabhängig vom Softwareprozedurtyp. Wenn die Eigenschaft
'Transaktion aktivieren' nicht aktiviert ist, werden alle Jobs nach dem fehlgeschlagenen
Job während der Evaluierung im Domänen-Manager auf Fehler gesetzt, jedoch werden
alle erfolgreich eingerichteten Jobs vor dem fehlgeschlagenen Job ausgeführt.
Wenn möglich wird unabhängig von einer Jobcontainer-Verknüpfung für Prozeduren
vom Typ SXP, PKG, PIF, RPM oder MSI bei einem Ausführungsfehler ein Rollback
durchgeführt. Falls die Jobcontainer-Verknüpfung den Wert "Batch" hat und die
Jobcontainer-Eigenschaft "Transaktion aktivieren" gesetzt ist, behandelt der Agent
komplette Ketten aufeinanderfolgender Jobs von Prozeduren der Typen SXP, PKG und
RPM als einzelne Vorgänge. Treten Fehler auf, wird, wenn möglich, automatisch für die
gesamte Kette ein Rollback durchgeführt. Beachten Sie, dass, falls der Jobcontainer nur
Prozeduren der Typen SXP, PKG, PIF und RPM enthält, der gesamte Container eine
einzelne Kette bildet. SXP-, PKG-, PIF- und RPM-Prozeduren können jedoch mit anderen
Prozedurtypen, wie "MSI" oder "Generisch", gemischt werden. In diesem Fall können in
einem Jobcontainer mehrere Ketten gebildet werden, allerdings wird nur für die aktive
Kette im Fehlerfall ein vollständiges Rollback vorgesehen. Außerdem wird
möglicherweise vom Agenten die vom Manager festgelegte Ausführungsreihgenfolge
für Jobs innerhalb des Jobcontainers für Prozeduren der Typen SXP, PKG, PIF und RPM
nicht eingehalten. Die Software Management-Komponente des Software DeliveryAgenten (SD-Agent) sortiert die Jobs in der für sie am besten geeigneten Reihenfolge.
Wenn die Jobreihenfolge auf dem Software Delivery-Manager für drei Jobs A, B, C
lautet, kann es also gut sein, dass die Jobs auf dem SD-Agenten in der Reihenfolge B, C,
A ausgeführt werden. Weiterhin kann es passieren, dass, falls die JobcontainerEigenschaft "Transaktion aktivieren" nicht festgelegt ist und beispielsweise Job B
fehlschlägt, die Software Management-Komponent nicht anhält, sondern versucht, die
Jobs C und A auszuführen.
Jedoch kann auch die Job-Ausführung synchronisiert werden. Das bedeutet, dass ein Job
nur dann aktiviert wird, wenn der vorherige Job erfolgreich abgeschlossen wurde, wenn
also alle Zielcomputer den Job erfolgreich ausgeführt haben.
Für Jobcontainer mit Jobverknüpfung "Batch" oder "Synchronisiert" kann das
automatische Kaskadieren abhängiger Pakete deaktiviert werden. Für Jobcontainer
ohne Jobverknüpfung ist das automatische Kaskadieren abhängiger Pakete immer
deaktiviert.
Wenn Sie auf die Schaltfläche Als Standard festlegen klicken, können Sie die
Einstellungen in der Registrierung des aktuell verwendeten Computers speichern. Wenn
mehrere Personen eine Verbindung mit demselben SD-Manager herstellen und alle die
Option "Als Standard festlegen" verwenden, besitzt jeder Benutzer eindeutige
Einstellungen in einer persönlichen Benutzerregistrierung.
Festlegen von Joboptionen
In der Registerkarte "Jobs" des Dialogfelds "Jobs einrichten" können Sie Optionen für die
einzelnen Jobs angeben. Die Optionen können auf einen oder mehrere Jobs
angewendet werden. Sie gelten für die in der Liste ausgewählten Jobs. Mit den
Schaltflächen auf der rechten Seite der Jobliste können Sie die Reihenfolge, in der die
Jobs ausgeführt werden, ändern und unerwünschte Jobs entfernen.
Berechtigung zur Jobausführung
Mit der Berechtigung zur Jobausführung können Administratoren die Ausführung
beliebiger Software Delivery- oder Asset Management-Jobs auf einem Zielcomputer
aktivieren oder deaktivieren. Die Berechtigung zur Jobausführung kann entweder auf
dem Zielcomputer oder per Remote-Zugriff über den DSM-Explorer aktiviert oder
deaktiviert werden.
Die Berechtigung zur Jobausführung auf einem Zielcomputer wird über die
Konfigurationsrichtlinie "Jobausführung beschränken" gesteuert, die anzeigt, ob ein
Software- oder Ressourcenjob auf dem Zielcomputer deaktiviert ist.
Wenn die Management-Richtlinie es zulässt (d. h. wenn die Konfigurationsrichtlinie
"Jobausführung beschränken" lokal auf dem Zielcomputer verwaltet wird), kann ein
Administrator die Ausführung von Asset-Jobs und Software-Jobs auf einem
Zielcomputer lokal aktivieren oder deaktivieren. Dies kann im Dialogfeld "DSMEigenschaften - Common Agent" auf der Registerkarte "Allgemein" mit dem
Kontrollkästchen "Agentenjobs beschränken" festgelegt werden.
Als Alternative zu dieser Methode kann der folgende Befehl in der Befehlszeile
verwendet werden:
caf restrictjobs [1 | 0]
Ist im Befehl "caf restrictjobs" 1 angegeben, werden keine Jobs auf dem Zielcomputer
ausgeführt, bei 0 werden Jobs ausgeführt. Wenn Sie weder 1 noch 0 angeben, wird die
aktuelle Einstellung angezeigt.
Priorisierung von Softwarejobs
Software Delivery ermöglicht dem Benutzer die Priorisierung von Softwarejobs, um eine
dynamische und schnellere Bereitstellung von Softwarepaketen, z. B. von Patches, auf
Endsystemen zu erzielen.
Mit dieser Jobpriorisierungsfunktion werden Softwarepakete nach ihrer aktuellen
Priorität verarbeitet, anstatt sie in der Reihenfolge, in der sie geplant wurden, an
Systeme zu übertragen. Die Priorität steuert im Wesentlichen, in welcher Reihenfolge
Jobs erstellt und ausgeführt werden. Je höher die Priorität ist, desto dringender ist die
Lieferung.
Die Priorität garantiert nicht die Reihenfolge der Ausführung. Auch wenn Jobs mit
höherer Priorität öfter verarbeitet werden, wird die ursprüngliche Aktivierungszeit
berücksichtigt, und ein Job mit niedrigerer Priorität kann vor Jobs mit höherer Priorität
ausgeführt werden, wenn der Lieferungsvorgang für die Jobs mit niedrigerer Priorität
vor dem Job mit hoher Priorität abgeschlossen ist.
Prioritäten werden festgelegt, wenn Softwarerichtlinien oder Jobcontainer (auf dem
Domänen- oder Enterprise-Manager) oder Verteilungscontainer (auf dem EnterpriseManager) eingerichtet werden. 1 ist die höchste Priorität, 5 ist die Standardpriorität und
10 ist die niedrigste Priorität.
Jobausführung beim Herunterfahren des Systems
Wenn beispielsweise auf einem Linux-Scalability-Server Kerneltreiber aktualisiert
werden sollen, ist ein Neustart erforderlich. Da diese Arten von Managern nur
gelegentlich neu gestartet werden, müssen Sie die Ausführung von Jobs planen,
während der Computer heruntergefahren wird.
Wenn Sie das Kontrollkästchen Beim Herunterfahren ausführen (nur UNIX) auf der
Registerkarte "Jobeigenschaften", "Prozeduroptionen" aktivieren, wird ein Jobtyp
erstellt, der auf dem Zielcomputer zurückgestellt wird, bis das System heruntergefahren
wurde.
Ist das Kontrollkästchen aktiviert, wird das Feld "Jobs werden vom Scalability-Server
ausgelöst" automatisch abgeblendet, da sich diese beiden Optionen gegenseitig
ausschließen.
Das Kontrollkästchen wird standardmäßig aktiviert, wenn das Kontrollkästchen Beim
Herunterfahren ausführen (nur UNIX) auf der Registerkarte "Optionen" der für den Job
verwendeten Prozedur aktiviert ist.
Hinweis: Aktivieren Sie die Option nicht für die Jobs, die auf Nicht-UNIX-Computer
abzielen. Ansonsten wird der Job nie ausgeführt, und das Zeitlimit wird überschritten.
Jobs für die Ausführung beim Herunterfahren dürfen nicht mit Standardjobs in
demselben Container verbunden werden, da dadurch alle Jobs im Container verschoben
werden.
Aktivieren der Prüfung von softwarebasierten Richtlinien
Mit der Konfigurationsrichtlinie "DSM/Software Delivery/Manager/Check template
policies" können Sie Softwarerichtlinien während der Evaluierung eines Jobcontainers
überprüfen.
Angenommen, einer Software-Richtlinie ist ein Job zugewiesen, der sicherstellt, dass der
Softwarekatalog für die Mitglieder der der Software-Richtlinie zugewiesenen Gruppe
nicht installiert wird. In diesem Fall wird ein Job, der den Softwarekatalog installiert, bei
allen Zielen, die auch zu dieser Software-Richtlinie gehören, im Evaluierungsschritt
fehlschlagen.
Wenn der Parameter "Check template policies" auf "True" gesetzt ist, wird jeder
eingerichtete Job in der Evaluierungsphase des Jobcontainers fehlschlagen, wenn der
Zielcomputer auch ein Mitglied einer Vorlagengruppe ist, der widersprüchliche Jobs
zugewiesen wurden.
Der Softwarerichtlinie X wurde z. B. ein Job zugewiesen, der eine Anwendung
deinstalliert. Wenn ein Job zum Installieren derselben Anwendung eingerichtet wird,
schlägt er für alle Mitglieder der mit der Softwarerichtlinie X verknüpften Gruppe fehl.
Dieser Task kann vom DSM-Explorer über "Tasks" "Richtlinie" "Jobrichtlinie" gesteuert
werden.
Deaktivieren von impliziten Lieferungen an Scalability-Server
Jobs über Scalability-Server liefern implizit Software vom Domänen-Manager, wenn
diese sich noch nicht in der Bibliothek des Scalability-Servers befindet. Zur besseren
Kontrolle der Lieferungen im Netzwerk können implizite Lieferungen deaktiviert
werden. Sind sie deaktiviert, schlagen Jobs fehl, wenn sich die erforderliche Software
nicht in der Bibliothek des Scalability-Servers befindet.
Dieser Task kann in der Baumansicht durch Navigieren zu "Systemsteuerung",
"Konfiguration", "Softwarejobmanagement", "Jobverarbeitung" gesteuert werden.
Verwenden von Scalability-Server-Bibliotheken für Lieferungen an Agenten
Data Transport Service-Übertragungen werden vom Data Transport Service-Agenten auf
dem Scalability-Server initiiert. Die Software wird aus der Scalability-Server-Bibliothek
extrahiert. Wenn der Job eine hinzugefügte Prozedur mit neuen Dateien verwendet
oder das Softwarepaket nicht bei der Scalability-Server-Bibliothek registriert ist, bleibt
die Domänen-Manager-Bibliothek die Quelle für die Übertragungen, weil eine
Scalability-Server-Bibliothek diese hinzugefügten Prozeduren nicht verwaltet.
Eine fehlgeschlagene Übertragung führt dazu, dass alle Agenten in dem Job
fehlschlagen, der von dieser Übertragung abhängt. Wenn die Übertragung fehlerhaft
abgeschlossen oder der Job gelöscht wird, bereinigt Data Transport Service alle StagingBereiche.
Die Funktion betrifft nur Data Transport Service-Lieferungen an Agenten. Alle anderen
Methoden zum Herunterladen, wie z. B. das interne Herunterladen mit oder ohne
NOS, werden von dieser Funktion nicht abgedeckt.
Neuinstallationsprozeduren
Die Neuinstallation von SXP-Software auf einem Zielcomputer war in der Vergangenheit
eher mühsam, da Sie vor der Installation zunächst die Software deinstallieren mussten.
Außerdem stand die Software auf dem Computer für eine gewisse Zeit nicht zur
Verfügung. Ursache dafür war, dass sich ein Deinstallations- und ein Installationsjob
nicht in demselben Jobcontainer befinden durften.
Software Management-Pakete, die mit dem Befehl "sd_registerproduct" registriert
wurden, sind mit einer zusätzlichen Neuinstallationskonfigurations-Prozedur
ausgestattet, mit der eine bestehende Produktinstallation repariert werden kann.
Bei Palm-, Windows CE- und Nokia-Paketen, die in der Softwarepaketbibliothek mit Hilfe
einzelner Registrierungsbefehle aus dem DSM-Explorer registriert wurden, wird eine
Neuinstallationsprozedur immer zusammen mit einer Installationsprozedur erstellt.
Sie können eine Neuinstallationsprozedur problemlos aus dem DSM-Explorer
auswählen.
Leere Jobs und Jobcontainer
In bestimmten Situationen wird ein Job eingerichtet, für dessen Empfang keine
Zielcomputer vorhanden sind. Oder es wurde ein Job für eine Gruppe ohne
Berechtigungen zum Ausführen eingerichtet. Dies hat im ersten Fall einen leeren, mit
"OK" gekennzeichneten Job oder im zweiten Fall einen Jobcontainer ohne Jobs zur
Folge.
Das Software Delivery-System verhält sich wie folgt:
■
Wenn bei der Joberstellung bestimmt werden kann, dass keine Zielcomputer
vorhanden sind, wird sofort ein Fehler zurückgegeben.
■
Wenn keine Jobs eingerichtet werden konnten, wird der Jobcontainer gelöscht.
■
Wenn die Hintergrundauswertung eines Jobcontainers ergibt, dass für den Job
keine Zielcomputer vorhanden sind, wird der Job mit einem Warnsymbol
gekennzeichnet. Dies geschieht in folgenden Fällen:
■
Ein Jobcontainer mit den Prozeduren ACTIVATE, CONFIGURE oder UNINSTALL
wurde mit Zielcomputergruppen oder mit Computern als Zielcomputer
eingerichtet. Bei der Evaluierung des Containers wird festgestellt, dass das zu
der Elementprozedur gehörige Element auf keinem der Zielcomputer installiert
ist.
■
Ein Jobcontainer wurde mit Hilfe einer beliebigen Prozedur mit
Zielcomputergruppen oder mit Computern als Zielcomputer eingerichtet. Bei
der Evaluierung des Containers wird festgestellt, dass der Software DeliveryAgent überhaupt nicht auf dem Rechner installiert ist (der Asset ManagementAgent wurde z. ;B. nur auf den Zielcomputern installiert.
In diesen Fällen gibt eine neue Jobmeldung an, warum keine Zielcomputer gefunden
wurden, z B. "Keine Zielcomputer während der Evaluierung gefunden" oder "Keine
Zielinstallationen während der Evaluierung gefunden".
Prozedur "Softwarejob-Datensätze synchronisieren"
Die Jobprozedur "Softwarejob-Datensätze synchronisieren" des Scalability-Servers ist für
Windows- und Linux-Betriebsumgebungen verfügbar. Die Prozedur hat den Typ
"activate".
Führen Sie diese Prozedur nur nach einem Totalausfall des Managers aus, um verloren
gegangene Jobergebnisse wiederherzustellen und den Inhalt der gelieferten Elemente
mit der Staging-Bibliothek zu synchronisieren.
Die Prozedur sollte nur auf allen untergeordneten Scalability-Servern und auf dem
Domänen-Manager-Rechner selbst ausgeführt werden, nachdem ein DomänenManager-Rechner nach einem Absturz wiederhergestellt wurde. Die Prozedur stellt
sicher, dass möglicherweise verloren gegangene Jobergebnisse auf dem Manager
wiederhergestellt werden und dass der Inhalt der Staging-Bibliothek für die ScalabilityServer synchronisiert wird.
Optimierte Evaluierung der Prozedurvoraussetzungen für SXP-Softwarepakete
Diese Leistungsverbesserung betrifft die Evaluierung der Prozedurvoraussetzungen in
SXP-Softwarepaketen ab Unicenter Desktop and Server Management (Unicenter
DSM) r11.2.
Es sind nur SXP-Pakete von der Optimierung betroffen, die mit dem Software
Management Packager für Windows oder der CLI erstellt oder die von einem Manager
vor Version 11 (also Unicenter Software Delivery 4.0 SP1) migriert wurden.
Die optimierte Evaluierung ist mit Versionen vor Unicenter DSM r11 nicht kompatibel.
Sie ist daher standardmäßig deaktiviert und muss aktiviert werden, ehe SXP-Pakete mit
Prozedurvoraussetzungen in der Softwarepaketbibliothek registriert werden.
Der verbesserte Evaluierungsmechanismus kann nur dann aktiviert werden, wenn alle
CA ITCM-Manager im Enterprise mindestens die Version r11.2 haben. Das Aktivieren des
Mechanismus auf einem Manager einer früheren Version von Unicenter DSM als r11 hat
keine Wirkung.
SXP-Pakete, die Prozedurvoraussetzungen eines Managers der Version r11.2 mit
aktiviertem optimiertem Evaluierungsmechanismus enthalten, können auch auf
Manager der Version r11.2 exportiert werden, bei denen der optimierte
Evaluierungsmechanismus deaktiviert ist. Die Optimierung ist auch in diesem Fall
wirksam. Ein Export in umgekehrter Richtung ist ebenfalls möglich, allerdings ist die
Optimierung in diesem Fall nicht wirksam.
Das Exportieren von SXP-Paketen, die Prozedurvoraussetzungen eines Managers der
Version r11.2 mit aktiviertem optimiertem Evaluierungsmechanismus enthalten,
auf Manager einer Version vor Version r11.2 führt zu internen Prozessfehlern in
CA ITCM. Dies betrifft auch Szenarien, in denen der Enterprise-Manager in der
Version r11.2 vorliegt, einige oder alle verknüpften Domänen-Manager jedoch in
einer früheren Version.
Pakete, die Prozedurvoraussetzungen eines Managers einer Version vor r11.2 enthalten
(also der Unicenter DSM-Versionen r11.0 oder r11.1) können in r11.2 importiert
werden, allerdings ist die Optimierung in diesem Fall nicht wirksam.
SXP-Pakete, die Prozedurvoraussetzungen eines Managers vor Version r11 (also
Unicenter Software Delivery 4.0 SP1) enthalten, können in r11.2 migriert oder
importiert werden. Die Optimierung ist allerdings nur wirksam, wenn der Mechanismus
aktiviert wird, bevor die Migration gestartet wird.
Das Optimieren registrierter Pakete, die nicht optimierte Prozedurvoraussetzungen
enthalten, ist nur möglich, indem diese aus der Softwarepaketbibliothek gelöscht und
nach dem Aktivieren des optimierten Evaluierungsmechanismus erneut erstellt oder
migriert werden.
Verwenden Sie folgenden Befehl, um die optimierte Evaluierung der
Prozedurvoraussetzungen zu aktivieren:
ccnfcmda -cmd SetParameterValue -psitrm/usd/shared
-pnBuildQuerySQLWithParameters -v1
Verwenden Sie folgenden Befehl, um die optimierte Evaluierung der
Prozedurvoraussetzungen zu deaktivieren:
ccnfcmda -cmd SetParameterValue -psitrm/usd/shared
-pnBuildQuerySQLWithParameters -v0
Steuerung der durch die Jobprüfung initiierte Wake-on-LAN-Funktion
Derzeit sendet jeder SD-Job Wake-on-LAN-Pakete, um den Zielcomputer zu wecken.
Der Konfigurationsparameter "Jobprüfung: Wake-On-Lan deaktivieren" des SD
Scalability-Servers steuert das Verhalten der Wake-on-LAN-Funktion, wenn sie durch die
SD-Jobprüfung initiiert wird. Ist dieser Konfigurationsparameter auf 'Wahr' gesetzt, wird
keine WOL-Signatur (Wake-On-Lan) in der Trigger-Meldung der Jobprüfung gesendet.
Der Standardwert dieses Konfigurationsparameters ist "False" (Falsch).
Hinweis für das Senden eines Jobs an einen Computer mit Apple Mac OS X
Wird ein Software Delivery-Job (SD-Job) an einen Computer im Energiesparmodus
gesendet, auf dem Apple Mac OS X läuft, wird der Computer zwar aktiviert, der SD-Job
selbst wird jedoch nicht gestartet. Das liegt daran, dass die Aktivierung des Mac OS XComputers noch nicht abgeschlossen ist, wenn er den Auslöser für die Ausführung des
SD-Jobs empfängt.
Der SD-Scalability-Server oder -Manager wird den Auslösebefehl jedoch nach 10
Minuten erneut an den Mac OS X-Computer senden, da der SD-Job dann noch aktiv ist.
Aktivieren von Elementprozeduren
Nachdem ein Auftrag gefunden wurde, wird das von der Elementprozedur identifizierte
Programm initiiert. Das Dialogfeld "Jobprüfung" wird für Windows-Zielcomputer
angezeigt, sofern der Administrator die Option "Benutzer-Eingabeaufforderung" im
Installationsauftrag ausgewählt hat. Wenn der Benutzer auf "Ausführen" klickt, wird die
Installation umgehend gestartet. Durch Klicken auf Verschieben kann er festlegen, auf
wann die Ausführung verschoben werden soll. Wenn der Benutzer auf Abbrechen klickt,
wird die Anweisung abgebrochen, und es werden keine weiteren
Eingabeaufforderungen mehr ausgegeben.
Benutzer des Agenten
Zusätzlich wird dem Benutzer des Agenten ein Dialogfeld mit einer
Eingabeaufforderung zum Neustart angezeigt, wenn der Administrator das
Kontrollkästchen zum Neustart vor Jobbeginn und zur BenutzerEingabeaufforderung während der Definition eines Jobauftrags für einen
Zielcomputer unter Windows aktiviert hat.
Bevor der Job ausgeführt wird, muss der Benutzer des Agenten angeben, ob ein
Neustart jetzt durchgeführt oder verschoben werden soll.
Wenn der Administrator das Kontrollkästchen zum Neustart nach Jobabschluss
(sowie zur Benutzer-Eingabeaufforderung) bei der Definition eines Jobauftrags für
einen Zielcomputer unter Windows aktiviert, wird dem Benutzer des Agenten nach
der Ausführung des Jobs das vorige Dialogfeld angezeigt.
Administratoren
Bei Jobaufträgen mit der Boot-Option, die auf dem Domänen-Manager ausgeführt
werden, wird dem Administrator zunächst die Meldung angezeigt, dass andere Jobs
fehlschlagen können.
Wenn diese Warnung ignoriert wird und der Administrator auf "Ja" klickt, muss er
in der vorherigen Eingabeaufforderung zur Jobprüfung angeben, wann der Neustart
durchgeführt werden soll.
Nachdem der Auftrag eingegangen ist und akzeptiert wurde, wird der Umfang der
notwendigen Benutzerinteraktion durch die Elementprozedur bestimmt. Wenn bei der
Elementprozedur Zielverzeichnisse eingegeben werden sollen, werden diese
Eingabeaufforderungen an den Benutzer übertragen.
Hinweis: Der Domänen-Manager darf nicht in der Kombination der Optionen "Neu
Starten" und "Job wird vom Server ausgelöst" eingerichtet werden, weil das Starten des
Scalability-Servers zu einer festgelegten Jobstartzeit zu unerwarteten Ergebnissen
führen kann.
Auslösen einer sofortigen Prüfung der Warteschlange nach Jobs
Die Verknüpfung "Jobprüfung starten" in der Taskleiste löst eine sofortige
Durchsuchung der Software Delivery-Jobs (SD-Job) in der Warteschlange aus. Unter
Windows wird das Dialogfeld "Jobprüfung" angezeigt.
Wenn der SD-Agent einen Job in der Warteschlange findet, wird die Installation
ausgelöst.
Hinweis: Die Joboption "Jobs werden vom Scalability-Server ausgelöst" ist für SD-Jobs
standardmäßig aktiviert. Das bedeutet, dass der Scalability-Server den Job zu einer
vorher festgelegten Zeit aktiviert. Ist diese Option deaktiviert, muss der Benutzer die
Jobprüfung auf dem Zielcomputer manuell ausführen.
Vor-und Nachbereitungsfunktionen für Jobprüfungen
Die Vor-und Nachbereitungsfunktionen für Jobprüfungen ermöglichen es, vor und nach
der Ausführung eines Software Delivery-Jobs (SD-Job) externe Programme auszuführen.
Sie können eine ausführbare Datei angeben, die vor der Verarbeitung des eigentlichen
SD-Jobs, und eine, die nach Abschluss des SD-Jobs bzw. des letzten Jobs in einer Kette
ausgeführt werden soll.
Diese ausführbaren Dateien werden über die Agentenrichtlinieen "Jobprüfung: PräBefehl" und "Jobprüfung: Post-Befehl" wie folgt angegeben:
Jobprüfung: Prä-Befehl
Gibt die ausführbare Datei an, die vor der Verarbeitung eines SD-Jobs bzw. des
ersten SD-Jobs in einem Batch ausgeführt wird. Ein Beispiel ist das Deaktivieren
eines Virenüberwachungsprogramms für die Dauer der Ausführung eines
Jobcontainers.
Standard: leer
Jobprüfung: Post-Befehl
Gibt die ausführbare Datei an, die nach der Verarbeitung eines SD-Jobs bzw. des
letzten SD-Jobs in einem Batch ausgeführt wird.
Standard: leer
Der Post-Befehl wird nur ausgeführt, wenn auch ein Prä-Befehl angegeben ist!
Vor-und Nachbereitungsfunktionen für Jobprüfungen finden ungeachtet der
Jobverknüpfungseinstellung (Batch-Job, synchronisiert oder keine Verknüpfung) für die
Registerkarte "Jobcontainer" statt.
Hinweise:
■
Falls für einen bestimmten Zielcomputer oder -benutzer mehrere Jobs ausgeführt
werden sollen, wird zuerst der Prä-Befehl der Jobprüfung, dann alle Jobs und
schließlich der Post-Befehl der Jobprüfung ausgeführt. Falls während einer
Jobausführung ein Neustart oder eine Abmeldung eingeleitet wird, führt der SDAgent die im Parameter "Jobprüfung: Post-Befehl" angegebene ausführbare Datei
aus, führt den Neustart oder die Abmeldung durch, führt die im Parameter
"Jobprüfung: Prä-Befehl" angegebene ausführbare Datei aus und setzt anschließend
die Jobausführung fort.
■
Falls mit den SD-Prozeduroptionen "Computer neu starten" bzw. "Benutzer
abmelden" Aktionen angegeben wurden, die vor der Jobausführung stattzufinden
haben, wird keine Vor- und Nachbereitung der Jobprüfung durchgeführt, bis der
erste Job der Jobkette gestartet wird.
Falls mit den SD-Prozeduroptionen "Computer neu starten" bzw. "Benutzer
abmelden" Aktionen angegeben wurden, die nach der Jobausführung bzw. nach der
Ausführung des letzten Jobs in der Kette stattzufinden haben, wird keine Vor- und
Nachbereitung der Jobprüfung durchgeführt.
■
Die Vor- bzw. Nachbereitung wird nur durchgeführt, falls die Jobprüfung einen SDJob entdeckt, der auf seine Ausführung wartet. Die Jobprüfung startet Vor-und
Nachbereitungsfunktionen für Jobprüfungen nicht automatisch.
Getrennte Lieferung oder Bereitstellung und Jobaktivierung
Wenn Sie bei der Einrichtung von Jobs einen Jobcontainer erstellen, wird ein anderes
Dialogfeld angezeigt. Wenn Sie einen Job z. B. mit dem Drag-and-Drop-Verfahren einem
Computer oder einer Computergruppe hinzufügen und die Option "Jobs planen"
auswählen, wird ein Dialogfeld angezeigt, das folgendermaßen aussieht:
Es ist möglich, die Lieferungs- und Aktivierungszeiten getrennt zu definieren, wenn Sie
die Lieferung der Software und das Bereitstellen von Jobs auf dem Scalability-Server
oder den Zielcomputern (bei Computern ohne DTS/NOS) von der eigentlichen
Aktivierungszeit des Jobs trennen möchten.
Die Aktivierungszeit steht für die frühestmögliche Aktivierungszeit. Wenn die Lieferung
oder Bereitstellung die Aktivierungszeit überschreitet, wird die Aktivierung für die
betreffenden Zielcomputer entsprechend zurückgestellt.
Der Lieferungszeitpunkt ist für jeden Job festgelegt. Standardmäßig hat die
Lieferungszeit für alle Jobs die gleiche Länge wie die Aktivierungszeit.
Synchronisierte Jobcontainer führen die Lieferung und Aktivierung für jeden
verarbeiteten Job durch. Die Lieferung eines Jobs beginnt also nicht, bevor der Job
davor erfolgreich abgeschlossen wurde.
Hinweis: Von einem Domänen-Manager können Sie auch die Option "Lieferung an
Staging-Bibliothek planen" auswählen, wenn Sie einem Scalability-Server oder einer
Scalability-Servergruppe einen Job per Drag-and-Drop hinzufügen. Diese Option zeigt
ein anderes Dialogfeld an, in dem Sie der Bibliothek eines untergeordneten ScalabilityServers Elemente hinzufügen können.
Anzeigen aktueller Installationen
CA ITCM verwaltet Aufzeichnungen zu allen aktuellen Produktinstallationen. Diese
Aufzeichnungen können entweder aus der Perspektive der Anzahl der auf einem
bestimmten Computer installierten Produkte oder aus der Perspektive der Anzahl an
Computern, auf denen ein bestimmtes Programm installiert wurde, angezeigt werden.
Im Folgenden finden Sie Beispiele für jede Sichtweise:
In der folgenden Abbildung sind installierte Pakete auf einem angegebenen Computer
dargestellt:
In der folgenden Abbildung sind Installationen eines angegebenen Elements dargestellt:
Download-Optionen
Die Download-Optionen gelten für alle derzeit für die Agenten von CA ITCM
unterstützten Betriebsumgebungen, sofern keine anderen Angaben gemacht werden.
Die aktuellen Agentenbetriebssystem-Versionen werden in der verfügbaren
Zertifizierungsmatrix auf CA Support aufgelistet.
DTS - ohne NOS
Diese Download-Methode, die nicht für Windows CE-Agenten gilt, nutzt Data
Transport Service für Downloads auf Agenten ohne NOS von dem mit ihnen
verknüpften Domänen-Manager.
Unter Windows muss das CA DSM Agent + Data Transport-Plugin auf dem Ziel
installiert sein, bevor Sie diese Download-Methode verwenden können.
Unter Linux und UNIX muss das CA DSM Agent + Data Transport-Plugin zusammen
mit dem CA DSM Agent + Software Delivery-Plugin installiert sein.
Wenn Sie die DTS-Konfiguration ohne NOS nicht mehr benötigen, können Sie das
DTS-Agenten-Plugin mit Hilfe eines Deinstallationsjobs vom Zielcomputer
entfernen, sofern Sie das DTS-Agenten-Plugin nicht benötigen.
Intern - ohne NOS
Diese Prozedur verwendet interne Software Delivery-Protokolle zum Herunterladen
auf Agenten ohne NOS vom dazugehörigen Domänen-Manager oder ScalabilityServer.
Intern - NOS
Diese Prozedur verwendet das Microsoft-Netzwerk oder NFS für den Zugriff von
Agenten auf Dateien auf dem Domänen-Manager oder Scalability-Server,
d. h. Netzwerkfreigaben.
Konfiguration der Download-Methode
Die Standard-Download-Methode für einen Computer wird in der MDB auf dem
Manager definiert. Über das Dialogfeld "Computereigenschaften" kann die DownloadMethoden für einzelne Computer festgelegt werden. Außerdem ermöglicht das KontextPopup-Menü für Computer und Computergruppen die Einstellung der DownloadMethode für mehrere Computer in einem Schritt.
Die in der MDB gespeicherte Download-Methode wird für die Software-Bereitstellung
verwendet. Alle Software-Jobs verwenden die Download-Methode, deren Verwendung
für den Zielcomputer zu dem Zeitpunkt eingestellt war, als der Jobcontainer versiegelt
und evaluiert wurde. Eine Änderung der Download-Methode für einen Computer
nachdem ein Jobcontainer versiegelt und evaluiert wurde, wird von Software-Jobs nicht
beachtet. Dagegen verwenden nach der Änderung versiegelte Jobcontainer die neue
Download-Methode.
Die Standard-Download-Methode für einen Computer kann auch vom Agenten
konfiguriert werden. Über die Befehlszeilenschnittstelle des Agenten (sd_acmd
SetDownloadMethod) lässt sich die Download-Methode in der MDB einstellen. Nach
erfolgreicher Jobprüfung und dem Informationsaustausch zwischen Scalability-Server
und Domänen-Manager erscheint der neue Wert in der MDB.
Hinweis: Der Manager wird nur dann zulassen, dass für die Download-Methode DTS
ausgewählt wird, wenn die Software Delivery- und die Data Transport ServiceAgentenkomponenten für diesen Agenten in der MDB registriert sind.
Neben der Befehlszeilenmethode bietet die Registerkarte "Erweitert" im DSMDialogfeld "Software Delivery-Eigenschaften" der CAF-Taskleiste die (grafische)
Möglichkeit, die Standard-Download-Methode für einen Computer zu ändern. Durch
Änderung der Zeile "Software Delivery: Ein bestimmtes Netzwerkbetriebssystem (NOS)
anfordern" wird die Aktualisierung der Standard Download-Methode in der MDB
angestoßen.
Verwechseln Sie die Zeile "Software Delivery: Ein bestimmtes Netzwerkbetriebssystem
(NOS) anfordern" nicht mit der Zeile "Software Delivery: Netzwerkbetriebssystem".
Letztere ändert lediglich den lokalen Konfigurationsspeicher des Agenten, um den
Agenten zu zwingen, Download-Methoden ohne NOS zu verwenden, insbesondere,
wenn der Scalability-Server Netzwerkfreigaben zur Verfügung stellt. Wird der Wert
eingestellt, beispielsweise auf MS, garantiert dies noch nicht die Verwendung von
Freigaben. Der Wert kann durch die Standard-Download-Methode oder die
Leistungsmerkmale und die Konfiguration des Scalability-Servers außer Kraft gesetzt
werden. Die Standard-Download-Methode für DTS kann vom Agenten nicht
überschrieben werden.
Optimieren der Erstellung komprimierter Jobdateien
Die folgenden Konfigurationsrichtlinien-Parameter steuern die Erstellung komprimierter
Dateien:
■
DSM/Software Delivery/freigegeben/Agenten ohne NOS verbunden
■
DSM/Software Delivery/freigegeben/On-the-Fly ohne NOS
Agenten ohne NOS verbunden
Der Parameter "Agenten ohne NOS verbunden" wird vom Domänen-Manager und
vom Scalability-Server verwendet und bietet Unterstützung für Agenten ohne NOS,
die mit dem Scalability-Server oder Manager verbunden sind.
Wenn er auf "Ja" gesetzt ist (die Standardeinstellung), erzwingt er die Erstellung
eines komprimierten Pakets, welches Ziele ohne NOS erfordern.
Wenn er auf "Nein" gesetzt ist, versucht der Scalability-Server oder Manager
herauszufinden, was diese Datei erfordert (wird in Verbindung mit dem Parameter
"On-the-Fly ohne NOS" verwendet).
On-the-Fly ohne NOS
Der Parameter "On-the-Fly ohne NOS" bietet Unterstützung für Agenten ohne NOS,
die mit dem Manager verbunden sind.
Wenn dieser Wert auf "False" (Falsch) gesetzt wird, werden keine komprimierten
Dateien erstellt, falls der Parameter "Agenten ohne NOS verbunden" auf "Nein"
gesetzt ist.
Wenn er auf "True" (Wahr) gesetzt ist und der Parameter "Agenten ohne NOS
verbunden" gleichzeitig auf "Nein" gesetzt ist, können Sie die CPU- und
Datenträgerverwendung optimieren, da in diesem Fall die komprimierte Datei nur
erstellt wird, wenn es erforderlich ist.
Verwenden von symbolischen Verknüpfungen
In Software Delivery stehen Ihnen auch symbolische Verknüpfungen (in Windows NT
auch Verbindungspunkte genannt) zur Verfügung, die Sie auf Domänen-Managern oder
Scalability-Servern mit Windows NT-Technologie oder Linux verwenden können. Das
SD-System überprüft selbst, ob die Verwendung von Symbolverknüpfungen möglich ist.
Der Vorteil von symbolischen Verknüpfungen liegt darin, dass sie sehr schnell sind. Der
SD-Manager muss keine unnötigen Daten kopieren, wodurch sowohl E/A-Bandbreite als
auch CPU-Zeit verbraucht würden. Es wird kein Speicherplatz verschwendet.
Folgende Einschränkungen gelten für die Verwendung symbolischer Verknüpfungen:
■
Symbolische Verknüpfungen können nur in Linux-Versionen verwendet werden, die
diese Funktion unterstützen.
■
Bei Windows NT-basierten Betriebssystemen können symbolische Verknüpfungen
nur mit dem Dateisystemtyp NTFS5 verwendet werden. Es gibt keine Versionen von
FAT, die diese Option unterstützen.
■
Die Pakete dürfen nicht in die Ordner des Bereichs ACTIVATE schreiben. Wenn dies
erlaubt wäre, hätte dies Auswirkungen auf die ursprüngliche Quelle der Pakete.
Wenn ein beliebiges Paket in den Bereich ACTIVATE schreibt, muss diese Funktion
deaktiviert werden. Dazu setzen Sie die Konfigurationsrichtlinie "DSM/Software
Delivery/freigegeben/Symbolische Verknüpfungen verwenden" auf "False" (Falsch).
Hinweis: Sie müssen über ausreichende Berechtigungen (Benutzerrechte) für den
Computer verfügen, wenn Sie versuchen, Symbolverknüpfungen zu verwenden, z. B.,
Administrator oder Sicherungsoperator.
Exportieren eines Bibliotheks-Images
Mit der Funktion "Bibliotheks-Image exportieren" können Sie Softwarepakete für die so
genannte Offline Software Delivery exportieren. Hierbei verwenden Sie die Befehlszeile
des Agenten (sd_acmd), um Container-Anweisungsdateien (COF) auszuführen. Es lassen
sich mehrere Dateien gleichzeitig exportieren. Dazu werden sie einfach im rechten
Fenster des DSM-Explorers ausgewählt.
Wenn mehrere Dateien ausgewählt sind, sieht die Struktur des Zielverzeichnisses wie
folgt aus:
Element 1
:
Element n
library.dct
Die Datei "library.dct" enthält Informationen zu den Namen, Versionen und Typen der
Elemente.
Jedes exportierte Softwareelement behält dieselbe Struktur wie in der
Softwarepaketbibliothek bei.
Hinweis: Eine Installationsquelle, die mit externen Prozeduren verknüpft ist, wird nicht
an den angegebenen Speicherort exportiert. Es wird nur eine eingebettete Quelle
exportiert. Bei der Ausführung von externen Prozeduren werden die in diesen
Prozeduren definierten absoluten Pfade vom Software Delivery-Agenten verwendet.
Offline-Agentenvorgang
Die Software Delivery-Funktionalität bietet Möglichkeiten der Offline-Verteilung für
Windows- und Linux-Agenten. Damit können Sie Softwarepakete für Zielcomputer
installieren und deinstallieren, die vom Domänen-Manager oder Scalability-Server
getrennt (offline) sind, und das Softwareinventar bei der nächsten Verbindung mit dem
Zielcomputer (online) aktualisieren.
Die Funktionen für die Offline-Verteilung können besonders im Falle einer
Kommunikationsunterbrechung (keine Verbindung zwischen Agenten und Manager)
oder bei Laptops nützlich sein, die selten angedockt werden.
Software-Pakete, die aus der Softwarepaketbibliothek exportiert wurden, können mit
Hilfe der Schnittstelle für die Agenten-Verwaltungsbefehle (sd_acmd), die Bestandteil
von Windows- und Linux-Agenten ist, installiert und deinstalliert werden. Eine COFDatei (Datei mit Jobcontaineranweisungen) mit Pfaden zu Paketen, die installiert oder
deinstalliert werden sollen, wird an die Befehlszeilenschnittstelle weitergegeben.
Der SD-Agenten-Dienst führt den Jobcontainer aus und verwaltet die erforderlichen
Abmeldungen und Neustarts. Die Ausführung erfolgt entweder ohne Verknüpfung oder
im Batch-Modus mit der Option, dass SXP-, PIF- und PKG-Pakete bei Fehlschlag
rückgängig gemacht werden können.
Die Synchronisierungsoption "Jobverknüpfung" wird in diesem Zusammenhang nicht
unterstützt.
Mit einer Batch-Datei (.bat) können Sie die Ausführung mehrerer COF-Dateien mit
mehreren Aufrufen des sd_acmd-Befehls "ExecuteContainer" einrichten. Die
Containerdateien sollten in derselben Reihenfolge wie in der Batch-Datei angegeben
ausgeführt werden.
Wahlweise können Sie (in Batch-Dateien) nach Aufrufen von "sd_acmd
ExecuteContainer" den Befehl "sd_acmd WaitContainers" verwenden, damit erst alle
ausstehenden oder gerade aktiven Jobs fertig gestellt werden können.
Während der Ausführung erhalten Sie über eine Ergebnisdatei und wahlweise auch über
Dialogfelder mit Meldungen Feedback. Informationen zu Jobs, die von sd_acmd
ausgeführt wurden, werden in einer lokalen Protokolldatei auf dem Zielcomputer für
Verfolgungszwecke gespeichert.
Das Offline-Softwareinventar für den SD-Agenten wird aktualisiert und hochgeladen,
wenn der Agent das nächste Mal den Scalability-Server kontaktiert.
Die Vorlagendatei "template.cof" befindet sich im Verzeichnis "CONF".
Hinweis: Mit einer speziellen Offline-Funktion können Sie im Verzeichnis
"%sdroot%\ASM\CONF" den Offline-Container "Runonce.cof" platzieren und einmal
ausführen, bevor der Agent eine Verbindung zum Scalability-Server aufbaut.
Weitere Informationen zu den drei sd_acmd-Befehlen, "ExecuteContainer",
"SecureContainer" und "WaitContainers", die bei der Bearbeitung von COF-Dateien
verwendet werden, finden Sie im Referenzhandbuch, das zur CA ITCM-OnlineDokumentation gehört.
Hinweis: Ungesicherte COF-Dateien können nicht ausgeführt werden. Mit dem
sd_acmd-Befehl "SecureContainer" können Sie die COF-Datei sichern. Wenn der
Container mit dem optionalen Parameter "p" (password, englisch für Kennwort)
gesichert wird, muss dasselbe Kennwort bei der Ausführung des Containers in die
Befehlszeile eingegeben werden.
Eine gesicherte COF-Datei, die verändert wurde, kann nicht ausgeführt werden. Um eine
COF-Datei erneut zu sichern, setzen Sie den Eintrag "secured=1" auf "secured=0" und
geben das Benutzerkonto (Abschnitt "Library") und die Kennwörter (Abschnitte
"Library" und "Container") erneut in die COF-Datei ein.
In einer Windows NT-Technologie-Umgebung kann jeder Benutzer Container
sichern. Für eine erfolgreiche Ausführung eines Offline-Jobs in Software Delivery mit
Hilfe des Befehls "sd_acmd ExecuteContainer" sind allerdings ausreichende
Sicherheitsrechte erforderlich. Standardmäßig sind dazu nur Benutzer mit lokalen bzw.
globalen Administratorrechten berechtigt.
Optional haben Mitglieder der lokalen Gruppe SDOFFLIN oder der globalen
Domänengruppe SDOFFLIN unter Windows NT die Berechtigung zum Ausführen von SDOffline-Jobs.
Die lokale Gruppe SDOFFLIN wird während der Installation von Software Delivery auf
allen Windows NT-Computern erstellt.
Administratoren können die globale Domänengruppe SDOFFLIN erstellen und diesen
Gruppen Benutzer hinzufügen, die dann SD-Offline-Jobs ausführen können.
UNIX verfügt über NIS, das sich wie die Domänenbenutzerprüfung unter
Windows NT-Technologie verhält. Die Benutzergruppe NIS für Offline-Jobs wird
auch als SDOFFLIN bezeichnet.
Einschränkungen
Es gibt keine Unterstützung für die Makroerweiterung $msi. Daher können Sie keine
COF-Dateien für die Erstellung von administrativen MSI-Installationen oder
Netzwerkinstallationen auf der Grundlage von administrativen Installationen (die mit
dem Makro "$msi" arbeiten) verwenden. Es gibt keine Unterstützung für hinzugefügte
Prozeduren. Nur Prozeduren, die vor der Versiegelung des Softwarepaketes erstellt
wurden, können mit COF-Dateien ausgeführt werden.
Es gibt keine Unterstützung für die Planung oder Erneuerung von Containern. Es kann
nur eine COF-Datei zu einem festgelegten Zeitpunkt ausgeführt werden. Wenn ein
Auftrag während der Ausführung eines anderen Auftrags ausgelöst wird, wird der zweite
sd_acmd-Befehl in eine Warteschlange gestellt.
Wenn derzeit die Jobprüfung ausgeführt wird, schlägt die Ausführung von sd_acmd mit
einem Beendigungscode unter Angabe des Fehlers fehl. Andererseits kann die
Jobprüfung nicht gleichzeitig mit sd_acmd durchgeführt werden. Software Delivery (SD)
führt diese Synchronisierungssperre intern durch.
Es gibt weder eine Unterstützung für die Benutzer-Eingabeaufforderungsfunktion noch
für das Erweitern von $cl-Makros auf Scalability-Server-Zeit. Diese Makros werden auf
die lokale Agentenzeit erweitert. Die Konfiguration ohne NOS bzw. die Konfiguration für
die NFS-Verbindung zum SD-Manager wird ebenfalls nicht unterstützt.
In einer Windows NT-Umgebung unterstützt der COF-Executor nur die Ausführung im
Systemkontext. Dadurch ist es erforderlich, ein Benutzerkonto sowie ein Kennwort
einzurichten, wenn auf ein freigegebenes Netzwerk zugegriffen wird, wobei es sich nicht
um eine NULL-Sitzungsfreigabe handelt (das Konto sollte über ausreichend
Zugriffsrechte auf die Freigabe verfügen).
Spezielle UNIX-Einschränkungen
In UNIX-Umgebungen werden weder LogonShield noch die Neustartabmeldung
unterstützt.
Verteilen von Aufträgen vom Enterprise-Manager
Aufträge werden vom Enterprise-Manager an die Domänen mit Hilfe eines
Verteilungscontainers verteilt. Dies ist eine Art Aufgabenliste, die vom Enterprise an die
Domänen gesendet wird. Ein Verteilungscontainer enthält einen oder mehrere Aufträge.
Die Anzahl der Anweisungen in einem Container ist nicht begrenzt. Verteilungscontainer
können Aufträge enthalten, mit denen folgende Aktionen ausgeführt werden:
■
Registrieren eines Elements oder einer Elementprozedur in der
Softwarepaketbibliothek einer Domäne
■
Installieren oder Deinstallieren eines Programmes
■
Aktivieren oder Abbrechen einer Aktivierungsanweisung
■
Aufheben von Registrierungen und Entfernen von Programmen
■
Abrufen von Elementen (Dateien) aus der Domäne
■
Registrieren einer Softwarerichtlinie oder Aufheben der Registrierung einer
Softwarerichtlinie in der Domäne
■
Archivieren (Bereinigen) und Wiederherstellen von Bibliothekselementen
Die Aktionen treten in der Reihenfolge auf, in der sie im Verteilungscontainer aufgeführt
werden. Wenn Aufträge vom Enterprise an den Domänen-Manager gesendet werden,
werden sie in dieser Domäne automatisch ohne den Eingriff des lokalen Administrators
verarbeitet, sofern dieser existiert.
Voraussetzung für das Einrichten eines Verteilungsauftrags
Sobald eine Domäne mit einem Enterprise-Manager verknüpft ist, werden alle
zugehörigen Computer und Scalability-Server auf dem Enterprise-Manager repliziert.
Vor dem Verteilen eines Lieferungs- oder Staging-Auftrags auf einem DomänenManager müssen Sie eine statische oder dynamische Computergruppe oder ScalabilityServergruppe erstellen, die automatisch auf den Domänen repliziert wird.
Einzelne Computer und Computergruppen können nicht vom Enterprise-Manager
adressiert werden. Die Zielgruppenadressierung muss mit Hilfe von Computer- und
Benutzergruppen durchgeführt werden.
Definieren von Lieferungsverteilungsaufträgen
Um einen Software Delivery-Verteilungsauftrag zu definieren, öffnen Sie den
Assistenten zum Bereitstellen von Softwarepaketen, indem Sie mit der rechten
Maustaste entweder auf die Computergruppe oder auf ein Softwarepaket klicken, und
befolgen die Anweisungen des Assistenten.
Definieren von Bereitstellungsverteilungsaufträgen
Öffnen Sie den Assistenten zum Bereitstellen von Softwarepaketen, indem Sie entweder
mit der rechten Maustaste auf die Computergruppe oder auf ein Softwarepaket klicken
und die Schritte im Agenten befolgen.
Sie können auch Bibliothekselemente per Drag-and-Drop den Computergruppen
hinzufügen (bzw. sie kopieren und einfügen). Der Vorteil eines Assistenten besteht
darin, dass Sie festlegen können, an welche Domänen der Container verteilt werden
soll. Außerdem können Sie automatisch Registrierungsaufträge für die Software
einschließen. Mit der Drag-and-Drop-Methode wird nur ein Verteilungscontainer
erstellt, der in einem zusätzlichen Schritt an die Domänen gesendet werden muss.
Definieren von Staging-Verteilungsaufträgen
Öffnen Sie den Assistenten zum Bereitstellen von Softwarepaketen (Staging), indem Sie
entweder mit der rechten Maustaste auf die Scalability-Servergruppe oder auf ein
Softwarepaket klicken und die Schritte im Agenten befolgen.
Sie können auch Bibliothekselemente per Drag-and-Drop den Scalability-Servergruppen
hinzufügen (bzw. sie kopieren und einfügen). Der Vorteil eines Assistenten besteht
darin, dass Sie festlegen können, an welche Domänen der Container verteilt werden
soll. Außerdem können Sie automatisch Registrierungsaufträge für die Software
einschließen.
Definieren von Softwarerichtlinien auf einem Enterprise
Wenn Sie den Assistenten zum Erstellen von Softwarerichtlinien auf einem EnterpriseManager ausführen, können Sie die Domänen festlegen, an die die Richtlinie verteilt
werden soll. Sie haben auch die Option, Registrierungsaufträge für die angegebenen
Softwarepakete einzubeziehen.
Softwarerichtlinien, die auf dem Enterprise-Manger erstellt und dann an die Domäne
verteilt werden, können mit lokal erstellten und verwalteten Domänen-Assetgruppen
verknüpft werden.
Überwachen des Verteilungsstatus
Nachdem ein Installationsauftrag verteilt wurde, können Sie seinen Fortschritt
überwachen, indem Sie einen der beiden Stati kontrollieren:
■
Auftragsstatus - wenn der Auftrag von einem Domänen-Manager geliefert wurde
■
Verteilungsstatus - wenn der Auftrag vom Enterprise-Manager verteilt wurde
Im Enterprise-Manager finden Sie im Ordner "Jobs/Softwareverteilungen" des DSMExplorers Informationen zu Verteilungen. Dieser Ordner zeigt den aktuellen Status und
den Verteilungszeitpunkt für alle verteilten Container an. Der Verteilungsstatus für
bestimmte Bibliothekselemente kann auch dem Zweig "Softwarepaketbibliothek" im
DSM-Explorer angezeigt werden.
Einstellungen für Softwarerichtlinien
Mit Hilfe des Assistenten zum Erstellen von Softwarerichtlinien können Sie definieren,
welche Software automatisch bei den Mitgliedern einer Computergruppe installiert
werden sollte.
Im Dialogfeld mit erweiterten Einstellungen für die Softwarerichtlinie können Sie
bestimmen, ob für eine Gruppe die automatische Evaluierung der Gruppenkonformität
aktiviert wird. Dadurch können Sie festlegen, wie Jobs auf Computern ausgeführt
werden, die die Bedingungen einer Gruppenmitgliedschaft nicht erfüllen. Jobs können
entweder automatisch eingerichtet oder für Mitglieder, die nicht konform sind,
eingerichtet und aktiviert werden.
Sie können die Jobverknüpfungsoptionen so festlegen, dass die Jobs unabhängig
voneinander ausgeführt werden, oder, wenn ein Job fehlschlägt, die verbleibenden Jobs
für dieses Ziel abgebrochen werden. Die Jobausführung kann auch synchronisiert
werden, d. h., dass ein Job nur aktiviert wird, wenn der vorherige Job
abgeschlossen ist.
Informationen zu einem alternativen Mechanismus für die Vorlagengruppenevaluierung
finden Sie unter "Ad-hoc-Evaluierung (siehe Seite 114)".
Die Registerkarte "Evaluierung" des Dialogfelds "Neue Softwarerichtlinie" ermöglicht
Einstellungen für geplante Evaluierungen sowie für Ad-hoc-Evaluierungen.
Geplante Evaluierung
Mit den Optionen auf der Registerkarte "Evaluierung" des Dialogfelds "Neue
Softwarerichtlinie" können Sie Evaluierungszeitpläne erstellen. Eine
Computergruppenmitgliedschaft kann entweder nach einem bestimmten Zeitplan
evaluiert werden oder dynamisch, was bedeutet, dass die Gruppen bei jeder
Verwendung evaluiert werden.
Sie können auch bestimmte Tage sowie Daten und Uhrzeiten in einem CCS-Kalender
festlegen, an denen eine Evaluierung der Gruppenzugehörigkeit zulässig ist.
Weitere Informationen zu einem alternativen Mechanismus für die
Vorlagengruppenevaluierung finden Sie unter "Ad-hoc-Evaluierung (siehe Seite 114)".
Ad-hoc-Evaluierung
Wenn neue Computer hinzugefügt oder bestehende Computer wiederhergestellt
werden, ist es wichtig, dass sie so schnell wie möglich wieder in den gewünschten Status
versetzt werden, damit für diese Zielcomputer den Anforderungen ihrer
Softwarerichtlinie entsprechende Jobs eingerichtet werden können.
Der Evaluierungsmechanismus wird nicht nur auf Basis einer vorherigen Planung,
sondern auch zum Zeitpunkt der Registrierung ausgeführt ("Ad-hoc" genannt). Neu
registrierte Ziele werden bei der Registrierung evaluiert, ohne dass dabei die anderen
registrierten Ziele in der Datenbank beachtet werden müssen. Aufgrund dieser
Anforderung kann die geplante Evaluationshäufigkeit reduziert werden, um während
der Geschäftszeiten eine zu hohe Belastung durch Evaluierungsvorgänge zu vermeiden.
Zwei allgemeine Verfahren stehen für die Einführung von neuen verwalteten
Computern in CA ITCM zur Verfügung: Vorregistrierung und reguläre Registrierung.
Vorregistrierung
Eine Vorregistrierung wird mit Hilfe einer der CA ITCM-Benutzeroberflächen
durchgeführt, beispielsweise dem DSM-Explorer. Die Vorregistrierung wird auch
durch die BS-Installationsverwaltung (OSIM) als Teil der Wiederherstellung des
Computers durchgeführt.
Reguläre Registrierung
Die reguläre Registrierung wird von der DSM-Engine während der Erfassung der
Scalability-Server durchgeführt.
Der hauptsächliche Unterschied zwischen den zwei Verfahren besteht im erfassten
Inventar oder dem bei einer Vorregistrierung nicht erfassten Inventar. Diese Tatsache
wirkt sich auf die Ergebnisse der Abfrageevaluierung und die Mitgliedschaft von
Computern in dynamischen Computergruppen aus. Softwarerichtlinien sind
Computergruppen zugeordnet und können als Teil der Evaluierung die Evaluierung der
zugeordneten Computergruppe auslösen. Das Fehlen von erfasstem Inventar für
vorregistrierte Computer kann sich auf ihre Mitgliedschaft in dynamischen Gruppen
auswirken, und die Evaluierung der Softwarerichtlinien wird deshalb möglicherweise auf
den vorregistrierten Computern nicht durchgeführt. Hierfür kann die
Konfigurationsrichtlinie "DSM/software delivery/Manager/Delay agent preregistration
actions" zum Verschieben der Evaluierung der Softwarerichtlinien für vorregistrierte
Computer verwendet werden, bis die erste reguläre Registrierung durch die Engine
durchgeführt wird.
Konfigurationshinweise
■
Über den Konfigurationsrichtlinienparameter "DSM/software
delivery/Manager/Computer evaluation policy" wird gesteuert, ob die Ad-hocFunktion in ihrem gesamten Umfang und für alle Gruppen ein- oder ausgeschaltet
ist, wobei die Konfigurationen für einzelne Gruppen außer Kraft gesetzt werden.
Standardmäßig ist der gesamte Ad-hoc-Funktionsumfang aktiviert.
■
Wenn Agenten durch einen Verschiebe- bzw. Roam-Vorgang gesperrt sind oder
nach einem Absturz neu installiert werden und für eine Ad-hoc-Evaluierung
eingeplant sind, wird der Evaluierungsversuch abgebrochen, jedoch zu einem
späteren Zeitpunkt wiederholt. Sie können die Verzögerung über den
Konfigurationsparameter "Software-Richtlinienevaluierung: Verzögerung für Adhoc-Taskevaluierung von gesperrten Zielen" mit einer standardmäßigen
Verzögerung von 30 Minuten für den nächsten Evaluierungsversuch steuern. Dank
dieses Parameters haben Sie eine bessere Kontrolle über das Evaluierungsverhalten
als mit dem Konfigurationsparameter "Software-Richtlinienevaluierung:
Verzögerung für Ad-hoc-Taskevaluierung", der eine standardmäßige Verzögerung
von 10Minutenhat.
Zielevaluierung
Während der Registrierung werden die Ziele für die Planung der Evaluierung markiert.
Die Konfigurationsrichtlinie "DSM/software delivery/Manager/ Computer evaluation
task computer count limit" steuert die Anzahl der Ziele, die in einem Durchgang
evaluiert werden können.
Bei Evaluierungen von Softwarerichtlinien ist Folgendes zu beachten:
■
Aktivierungs- und Konfigurationsjobs können so konfiguriert werden, dass sie bei
jeder geplanten Evaluierung erneut ausgeführt werden. Bei einer Ad-hocEvaluierung findet diese Zuweisung nicht statt.
■
Wenn das Kontrollkästchen "Keine Jobs für Mitglieder regenerieren, die für diese
Richtlinie bereits fehlgeschlagen sind" aktiviert ist, werden keine neuen
Jobcontainer für Ausnahmemitglieder eingerichtet, falls aufgrund einer vorherigen,
durch die Evaluierung angeforderten Aktivierung noch ein fehlgeschlagener
Jobcontainer vorhanden ist. Wenn der frühere Jobcontainer manuell gelöscht
wurde, werden die Jobs durch eine erneute Evaluierung der Vorlage
ordnungsgemäß eingerichtet.
Verschobene Ziele und Neuinstallation nach Absturz (RAC)
Ziele, die aktuell von Verschiebungen oder RAC-Vorgängen betroffen sind, werden von
der Evaluierung (Ad-hoc, geplant oder nicht geplant) ausgeschlossen, bis die anderen
Vorgänge abgeschlossen sind. Der Grund dafür ist, dass die verschobenen Datensätze
oder RAC-Datensätze die durch die Softwarerichtlinie festgelegten Bedingungen
möglicherweise erfüllen.
Wenn Ziele während Verschiebungen oder RAC-Vorgängen nicht evaluiert werden,
bleibt der Task für die Evaluierung bestehen, bis die anderen Vorgänge abgeschlossen
sind und die Ziele evaluiert wurden.
Liefern von virtuellen Anwendungen
Erneute Ausführung von Installationsprozeduren mit Hilfe von Softwarerichtlinien
Mit Jobvorlagen, die in Softwarerichtlinien definiert sind, können Sie die Option
"Installationsdaten entfernen und ausgewählte Prozedur erneut ausführen" angeben,
die bei der Richtlinienevaluierung vorhandene Installationsdatensätze entfernt und die
Installationsprozedur unabhängig davon, ob die Software bereits als installiert
aufgezeichnet ist, erneut ausführt.
Wenn Software beispielsweise manuell ohne Verwendung des Softwarekatalogs
deinstalliert wurde, wird diese Änderung im Software Delivery-Jobverlauf in der MDB
nicht angezeigt. Mit dieser Funktion können Sie die Installationsprozedur auch dann
erneut ausführen, wenn der Software Delivery-Jobverlauf anzeigt, dass die Software
bereits installiert ist.
Wichtig! Verwenden Sie diese Funktion mit Vorsicht. Bei falscher Verwendung können
Jobs so geplant werden, dass sie bei jeder Evaluierung der Softwarerichtline ausgeführt
werden und somit zu einer unerwünschten Auslastung der Infrastruktur führen.
Außerdem führt die Softwarerichtlinie die angegebene Prozedur erneut aus, ohne zu
berücksichtigen, ob sie erneut ausgeführt werden muss. Ob die Funktion zum erneuten
Ausführen bei einer bestimmten Installationsprozedur angewendet werden soll, bleibt
dem Benutzer überlassen.
Nachdem ein Softwarepaket für virtuelle Anwendungen in der Software-PaketBibliothek auf dem Enterprise- oder Domänen-Manager registriert worden ist, können
Sie es über die standardmäßigen Software Delivery-Methoden an andere Computer im
Netzwerk verteilen. Es bestehen allerdings einige Anforderungen und Prozesse, die
alleine für die Lieferung von Paketen mit virtueller Anwendung gelten. Die folgenden
Abschnitte enthalten Details zu diesen Anforderungen und Prozessen:
■
Funktionsweise der Bereitstellung von virtuellen Anwendungen
■
Vorbereiten eines Zielcomputers für Bereitstellung eines Pakets mit virtueller
Anwendung von Microsoft App-V
■
Vorbereiten eines Zielcomputers für Bereitstellung eines Pakets mit virtueller
Anwendung von VMware ThinApp
■
Bereitstellen eines Softwarepakets für virtuelle Anwendungen
■
Bereitstellen von Aktualisierungen des Softwarepakets für virtuelle Anwendungen
■
Roaming und Bereitstellung virtueller Anwendungen
■
Funktionsweise von Roaming mit virtuellen Anwendungen
Funktionsweise der Bereitstellung von virtuellen Anwendungen
Nachdem das Paket mit virtueller Anwendung, das Sie mit dem
Registrierungsassistenten für Pakete mit virtuellen Anwendungen erstellt haben, in die
Software-Paket-Bibliothek aufgenommen worden ist, können Sie es bereitstellen und
über die standardmäßigen Software Delivery-Methoden verwalten. Sie können virtuelle
Anwendungen für Systeme bereitstellen (oder Gruppen von Systemen), Anwendungen
im Software Delivery-Katalog verfügbar machen, Anwendungen in Richtlinien
aufnehmen und standardmäßige Software Delivery-Aktivitäten ausführen.
Sie können das Paket mit virtueller Anwendung auf Enterprise- (EP) oder auf
Domänenmanagement-Ebene registrieren. Ein Paket mit virtueller Anwendung sollte
nicht auf EP-Ebene und auf Domänenmanagement-Ebene registriert werden. Wenn Sie
ein Paket mit virtueller Anwendung auf der EP-Management-Ebene registrieren, kann es
dann an die Domänenmanagement-Ebene und darunterliegende Ebenen verteilt
werden. Vom Domänen-Manager können die Pakete an Agenten und Scalability-Server
verteilt werden. Bei gestreamten virtuellen Anwendungen agieren die Scalability-Server
auch als Streaming-Server.
Die Bereitstellung von Paketen mit virtueller Anwendung durchläuft die folgenden
allgemeinen Phasen:
1.
Der Administrator stellt sicher, dass die Infrastruktursoftware des Anbieters für die
virtuellen Anwendungen auf den Zielrechnern installiert ist.
Hinweis: Nach der Installation des "Microsoft System Center Application
Virtualization Streaming Server" kann ein Neustart des Zielservers erforderlich sein.
Der Einrichtungsprozess des Streaming-Servers initiiert diesen Neustart.
2.
Der Administrator erstellt Software-Jobs, um die Pakete mit virtueller Anwendung
für Zielcomputer bereitzustellen (nach der Paketerstellung und Registrierung
virtueller Anwendungen). Der Administrator kann Software-Jobs für Pakete mit
virtueller Anwendung mit den gleichen Methoden erstellen, die er auch für die
Erstellung von Software-Jobs für normale Anwendungspakete verwendet.
3.
Der Administrator stellt das Paket zur Bereitstellung der virtuellen Anwendung
durch Staging auf dem Scalability-Server bereit. Der Scalability-Server fungiert auch
als Streaming-Server. Darum werden Staging-Pakete für das Streaming virtueller
Anwendungen auf die Zielcomputer auf dem Scalability-Server bereitgestellt.
Hinweis: Wenn der Zielcomputer zu einem neuen Scalability-Server wechselt, muss
das Staging-Paket auf dem neuen Server ebenso installiert werden. Weitere
Informationen zu Roaming finden Sie in der Beschreibung von Roaming und
Bereitstellung virtueller Anwendungen (siehe Seite 125).
4.
Der Administrator stellt die eigenständigen und Streaming-Pakete vom DomänenManager auf den Zielcomputern bereit. Der Administrator kann auch Pakete vor der
Bereitstellung auf Zielcomputern auf dem Scalability-Server durch Staging
bereitstellen. Der Administrator kann Standardbereitstellungsmethoden für
Software Delivery verwenden, um Pakete mit virtuellen Anwendungen auf
Zielcomputern bereitzustellen.
Vorbereiten eines Zielcomputers für Bereitstellung einer virtuellen Anwendung von Microsoft
App-V
Bevor Sie ein Paket mit virtuellen Anwendungen von Microsoft App-V auf einem
Zielcomputer bereitstellen können, müssen Sie überprüfen, ob der Zielcomputer für die
virtuelle Anwendung vorbereitet ist. Die folgende Beschreibung erklärt die Vorbereitung
der Zielcomputer.
Abhängigkeiten – Über Microsoft App-V-Image erstellte Pakete mit virtuellen
Anwendungen benötigen gewisse Abhängigkeiten. Die folgende Tabelle identifiziert
diese Abhängigkeiten, je nach Typ des Pakets mit virtueller Anwendung, den Sie
bereitstellen möchten.
Pakettyp
Abhängigkeiten
Server-Staging
Streaming-Server der Anwendungsinitialisierung des Microsoft System
Center
Eigenständiger Client oder StreamingClient
Microsoft Application Virtualization Desktop Client
Microsoft SML Parser 6.0
Microsoft Visual C++ 2005 SP1
Eigenständiger Client oder StreamingClient für Remote Desktop Services
Microsoft Application Virtualization Desktop Client
Microsoft SML Parser 6.0
Microsoft Visual C++ 2005 SP1
Die Infrastrukturkomponenten müssen auf den Zielservern und Clients verfügbar sein,
damit die virtuelle Anwendung funktioniert. Sie können Ihre eigenen lokalen Prozeduren
verwenden, um diese Komponenten auf den Zielcomputern verfügbar zu machen, oder
Sie können CA ITCM verwenden, um Software Delivery-Pakete für die
Infrastrukturkomponenten von Microsoft App-V zu erstellen. (Microsoft stellt diese
Komponenten als MSI-basierte Installations-Images zur Verfügung.) Diese
Infrastrukturpakete können dann mit den vorhandenen Software Delivery-Methoden in
die Software-Paket-Bibliothek importiert werden.
Hinweis: Sie können die Infrastrukturpakete selbst erstellen, oder Sie können die
Software Delivery-Infrastrukturpaketvorlagen verwenden (in Ihrem DVD-Kit enthalten).
Weitere Informationen zu den Infrastrukturpaketvorlagen finden Sie in der
Beschreibung Infrastrukturpaketvorlagen für virtuelle Anwendungen (siehe Seite 60).
Serverkonfiguration für Streaming-Kommunikationen — Für virtuelle Anwendungen,
die auf Zielcomputer gestreamt werden, muss der Zielcomputer den Namen des
Streaming-Servers erkennen. Der DSM-Scalability-Server handelt als App-V-StreamingServer. Deswegen muss der App-V-Streaming-Server auf dem DSM-Scalability-Server
installiert werden.
Der Microsoft App-V-Streaming-Server verwendet zwei Protokolle für die StreamingKommunikation: RTSP (nicht gesichert) und RTSPS (gesichert). Standardprotokoll und port für den Microsoft App-V-Streaming-Server sind RTSP und Port 554. Wenn Sie das
gesicherte RTSPS-Protokoll mit Port 322 verwenden wollen, müssen Sie den StreamingServer entsprechend konfigurieren. Wenn Sie die von CA zur Verfügung gestellten
Vorlagen für Infrastrukturpakete verwenden, müssen Sie den Streaming-Server
konfigurieren, bevor Sie ihn in die Vorlage einschließen. Informationen zur Konfiguration
des Microsoft App-V-Streaming-Servers finden Sie in der Dokumentation von Microsoft.
Client-Konfiguration für Streaming-Kommunikationen—Standardprotokoll und -port
für den Microsoft App-V-Client sind RTSP und Port 554. Wenn Sie das gesicherte RTSPSProtokoll mit Port 322 verwenden wollen (damit zum Beispiel die Konfiguration der des
Streaming-Servers entspricht), können Sie die Richtliniengruppe "Virtuelle
Anwendungen bereitstellen" entsprechend einstellen und sie auf die Agenten
anwenden. (Weitere Informationen zur Richtliniengruppe "Virtuelle Anwendungen
bereitstellen" finden Sie in der Online-Hilfe zu DSM Explorer.) Wenn dann ein neues
Paket mit virtuellen Anwendungen von Microsoft-App-V registriert und mit dem
Standardprotokoll und -port bereitgestellt wird, ersetzt der Agent die
Standardeinstellungen mit dem in der Richtlinie festgelegten Protokoll und Port. Für die
Installation einer bestehenden Anwendung auf dem Zielcomputer müssen Sie das
Streaming-Paket unter Verwendung der Neuinstallationsprozedur erneut bereitstellen,
die Teil des Streaming-Pakets ist. Diese Prozedur verwendet das neue Protokoll und den
neuen Port, wenn der Benutzer die Anwendung startet. Auch werden die Shortcuts auf
dem Zielcomputer aktualisiert, sobald sich der Benutzer das nächste Mal auf dem
Computer anmeldet.
Hinweise:
Sie können Pakete mit virtueller Anwendung auf Ziel-Scalability-Servern und
Zielcomputern bereitstellen, auf denen ein Windows-Betriebssystem und keine
UNIX- oder Linux-Betriebssysteme ausgeführt werden.
Microsoft App-V-Sequencer unterstützt Windows 2000 nicht. Daher wird Windows
2000 nicht als Client für ausgeführte virtuelle Anwendungen von App-V unterstützt.
Microsoft Application Virtualization Desktop Client Version 4.5 unterstützt 64-BitWindows-Betriebssysteme nicht. Daher werden Computer mit 64-Bit-WindowsSystemen nicht für ausgeführte virtuelle Anwendungen von App-V unterstützt
(Eigenständige und Streaming-Pakete).
Autorisierung – Der Endbenutzer auf dem Zielcomputer benötigt eine Autorisierung, um
auf die virtuelle Anwendung zugreifen zu können, die sich auf einem Netzlaufwerk auf
dem Scalability-Server befindet. Eine Autorisierung kann über eine vertrauenswürdige
Verbindung zwischen dem Zielcomputer und dem Server erreicht werden. Wenn keine
vertrauenswürdige Verbindung vorhanden ist, wird der Endbenutzer aufgefordert, einen
Benutzernamen und ein Kennwort anzugeben.
Vorbereiten eines Zielcomputers für Bereitstellung einer virtuellen Anwendung von VMware
ThinApp
Bevor Sie ein Paket mit virtuellen Anwendungen von VMware ThinApp auf einem
Zielcomputer bereitstellen können, müssen Sie überprüfen, ob der Zielcomputer für die
virtuelle Anwendung vorbereitet ist. Die folgenden Abschnitte erklären die Vorbereitung
der Zielcomputer.
Abhängigkeiten – Über VMware ThinApp-Image erstellte Pakete mit virtuellen
Anwendungen benötigen gewisse Abhängigkeiten. Die folgende Tabelle identifiziert
diese Abhängigkeiten, je nach Typ des Pakets mit virtueller Anwendung, den Sie
Pakettyp
Abhängigkeiten
Server-Staging
Keine Abhängigkeiten
Eigenständiger Client oder Streaming-Client
Hilfsprogramm "ThinReg.exe"
Für ThinApp-Pakete zur Bereitstellung der virtuellen Anwendung durch Staging für den
Server gelten keine Voraussetzungen. Die eigenständigen und Streaming-Pakete, die
ThinApp-Pakete für Zielcomputer bereitstellen, rufen das Hilfsprogramm "ThinReg.exe"
auf. Dieses Programm verschafft dem Endbenutzer leichten Zugriff auf virtuelle
Anwendungen.
Wichtig! Das Hilfsprogramm "ThinReg.exe" muss in der PATH-Umgebung auf dem
Zielcomputer vorhanden sein. Ist dies nicht der Fall, kann die Bereitstellung des Pakets
mit virtueller Anwendung auf dem Zielcomputer nicht erfolgreich abgeschlossen
werden.
Sie können Ihre eigenen lokalen Prozeduren verwenden, um das Hilfsprogramm
"ThinReg.exe" auf den Zielcomputern verfügbar zu machen, oder Sie können CA ITCM
verwenden, um ein Software-Delivery-Paket für das Hilfsprogramm "ThinReg.exe" zu
erstellen. Dieses Infrastrukturpaket kann dann in die Software-Paket-Bibliothek
importiert werden, indem die vorhandenen Methoden für den Import von Paketen
verwendet wird. Weitere Informationen zur Erstellung von Infrastrukturpaketen finden
Sie in der Beschreibung Infrastrukturpaketvorlagen für virtuelle Anwendungen (siehe
Seite 60).
Hinweis: Sie können Pakete mit virtueller Anwendung auf Ziel-Scalability-Servern und
Zielcomputern bereitstellen, auf denen ein Windows-Betriebssystem und keine UNIXoder Linux-Betriebssysteme ausgeführt werden.
Autorisierung – Der Endbenutzer auf dem Zielcomputer benötigt eine Autorisierung, um
auf die virtuelle Anwendung zugreifen zu können, die sich auf einem Netzlaufwerk auf
dem Scalability-Server befindet. Eine Autorisierung kann über eine vertrauenswürdige
Verbindung zwischen dem Zielcomputer und dem Server erreicht werden. Wenn keine
vertrauenswürdige Verbindung vorhanden ist, wird der Endbenutzer aufgefordert, einen
Benutzernamen und ein Kennwort anzugeben.
Erkennung von ThinApp-Paketen in Nicht-Domänen-Umgebungen
Die Erkennung von ThinApp-Streaming-Paketen ist in einer Nicht-Domänen-Umgebung
nicht kontinuierlich. Wenn der Scan nach Benutzern nicht zu einem Zeitpunkt
ausgeführt wird, zu dem ein Benutzer für diese Server-Freigabe authentisiert ist, kann
der Scan keine Inhalte dieser Freigabe erkennen.
Typisch wird der Scan sofort nach der Anmeldung (in diesem Fall ist es
unwahrscheinlich, dass der Benutzer noch nicht bei dem Scalability-Server authentisiert
worden ist) ausgeführt, und immer, wenn der vollständige Signatur-Scan ausgeführt
wird, was nur selten vorkommt und nur, wenn der Benutzer nicht angemeldet ist.
Deswegen empfiehlt CA, Domänen-/Active Directory-Umgebungen für das Streaming
von ThinApp-Anwendungen zu verwenden und ThinApp-Pakete mit virtuellen
Anwendungen bereitzustellen.
Bereitstellen eines Softwarepakets für virtuelle Anwendungen
Sie können die folgende allgemeine Prozedur zusammen mit den
Standardbereitstellungsmethoden der Software Delivery verwenden, um ein Paket mit
virtueller Anwendung bereitzustellen.
So stellen Sie ein Softwarepaket für virtuelle Anwendungen bereit
1.
Überprüfen Sie, dass die Zielserver und Clients für die Bereitstellung von virtuellen
Anwendungen vorbereitet sind.
Hinweise:
Anbieterinfrastruktursoftware muss auf den Zielservern und Clients installiert
werden. Sie können diesen Schritt unter Verwendung Ihrer eigenen lokalen
Prozeduren vervollständigen oder die bei CA ITCM zur Verfügung gestellten
Vorlagen für Infrastrukturpakete verwenden. Weitere Informationen finden Sie
in den folgenden Beschreibungen: "Vorbereiten eines Zielcomputers für
Bereitstellung einer virtuellen Anwendung von Microsoft App-V" und
"Vorbereiten eines Zielcomputers für Bereitstellung einer virtuellen
Anwendung von VMware ThinApp".
Nach der Installation des "Microsoft System Center Application Virtualization
Streaming Server" kann ein Neustart des Zielservers erforderlich sein. Der
Einrichtungsprozess des Streaming-Servers initiiert diesen Neustart.
2.
Überprüfen Sie, dass drei Softwarepakete – Staging (SG), Eigenständig (SA) und
Streaming (SM) – in der Software-Paket-Bibliothek für die virtuelle Anwendung, die
Sie bereitstellen möchten, vorhanden sind.
3.
Stellen Sie das Staging-Paket für alle erforderlichen Scalability-Server bereit (Server,
die mit Zielcomputern verbunden sind, auf denen eine gestreamte virtuelle
Anwendung bereitgestellt wird).
Sie sollten jegliche Infrastrukturpakete zuerst bereitstellen.
Hinweis: Nach der Installation eines Microsoft App-V-Staging-Pakets auf einem
Scalability-Server kann es zu einer Verzögerung kommen (möglicherweise von bis zu
30 Minuten), bevor das Paket zur Verwendung verfügbar wird. Wenn der
Endbenutzer eine virtuelle Anwendung von App-V-Streaming startet, bevor das
Staging-Paket verfügbar ist, wird eine Fehlermeldung angezeigt.
4.
Stellen Sie eigenständige oder Streaming-Pakete auf allen Zielcomputern bereit
Sie sollten jegliche Infrastrukturpakete zuerst bereitstellen.
Die Softwarepakete für virtuelle Anwendungen wurden installiert.
Hinweise:
Beim Deinstallieren einer eigenständigen virtuellen Anwendung deinstallieren Sie
zuerst das SA-Paket vom Zielcomputer und dann das SG-Paket. Bei einer virtuellen
Streaming-Anwendung deinstallieren Sie zuerst das SM-Paket auf dem Clienten und
dann das SG-Paket auf dem Server.
Der Endbenutzer am Zielcomputer sollte eine virtuelle Anwendung von Microsoft
App-V nicht durch doppelten Mausklick auf die .osd-Datei starten. Wenn der
Benutzer die Anwendung auf diese Weise öffnet, besteht die Möglichkeit, dass die
Kommunikation mit dem Streaming-Server nicht fehlerfrei funktioniert. Der
Benutzer sollte die Anwendung über den Shortcut auf dem Desktop oder über das
Startmenü starten.
Bereitstellen von Aktualisierungen des Softwarepakets für virtuelle Anwendungen
Sie können die folgende allgemeine Prozedur zusammen mit den
Standardbereitstellungsmethoden der Software Delivery verwenden, um eine
Aktualisierung für Pakete mit virtueller Anwendung bereitzustellen.
So stellen Sie Aktualisierungen der Softwarepakete für virtuelle Anwendungen bereit
1.
Überprüfen Sie, dass die Zielserver und Clients für die Bereitstellung von virtuellen
Anwendungen vorbereitet sind.
Hinweise:
Anbieterinfrastruktursoftware muss auf den Zielservern und Clients installiert
werden. Sie können diesen Schritt unter Verwendung Ihrer eigenen lokalen
Prozeduren vervollständigen oder die bei CA ITCM zur Verfügung gestellten
Vorlagen für Infrastrukturpakete verwenden. Weitere Informationen finden Sie
in den folgenden Beschreibungen: "Vorbereiten eines Zielcomputers für
Bereitstellung einer virtuellen Anwendung von Microsoft App-V" und
"Vorbereiten eines Zielcomputers für Bereitstellung einer virtuellen
Anwendung von VMware ThinApp".
Nach der Installation des "Microsoft System Center Application Virtualization
Streaming Server" kann ein Neustart des Zielservers erforderlich sein. Der
Einrichtungsprozess des Streaming-Servers initiiert diesen Neustart.
2.
Überprüfen Sie, dass zwei Softwarepakete – Staging (SG) und Eigenständig (SA) – in
der Software-Paket-Bibliothek für die virtuelle Anwendung, die Sie bereitstellen
möchten, vorhanden sind.
Hinweis: Staging- und eigenständige Pakete werden für Aktualisierungen von
virtuellen Anwendungen benötigt. Das Streaming-Paket enthält nur Verknüpfungen
zum Staging-Paket und der virtuellen Anwendung. Diese Verknüpfungen müssen
nicht aktualisiert werden.
3.
Stellen Sie das Staging-Paket für alle erforderlichen Scalability-Server bereit (Server,
die mit Zielcomputern verbunden sind, auf denen eine gestreamte virtuelle
Anwendung bereitgestellt wird).
4.
Stellen Sie das eigenständige Paket je nach Bedarf für alle Zielcomputer bereit.
Die Aktualisierungen der Softwarepakete für virtuelle Anwendungen wurden
installiert.
Roaming und Bereitstellung virtueller Anwendungen
Unter Roaming versteht man, dass ein Zielcomputer innerhalb des
Unternehmensnetzwerks von einem Standort an einen anderen wechselt. Nach dem
Verschieben muss der Zielcomputer möglicherweise mit einem neuen Scalability-Server
verbunden werden. Diese Verschiebung kann stattfinden, wenn der Benutzer in ein
neues Büro umzieht und der Computer des Benutzers eine Verbindung zum lokalen
Scalability-Server und nicht zum ursprünglichen Scalability-Server herstellen muss. Auch
im Falle von organisatorischen Änderungen im Unternehmen bei denen die Struktur der
Netzwerke beeinflusst wird, müssen einige Zielcomputer möglicherweise anderen
Scalability-Servern zugewiesen werden.
Für Zielcomputer, die virtuelle Anwendungen in Streaming-Modus ausführen, agiert der
Scalability-Server auch als Streaming-Server. Bei gestreamten virtuellen Anwendungen
müssen die Anwendungen durch Staging auf dem Scalability-Server, mit dem der
Zielcomputer verbunden ist, bereitgestellt werden, damit die Anwendungen auf dem
Zielcomputer ausgeführt werden können. Wenn ein Zielcomputer an einen neuen
Standort und einen neuen Scalability-Server wechselt, kann der neue Scalability-Server
möglicherweise auch der neuen Streaming-Server werden. Die Staging-Pakete für alle
virtuellen Anwendungen, die für den Zielcomputer gestreamt werden, müssen auf dem
neuen Scalability-Server installiert werden, bevor der neue Server als Streaming-Server
agieren kann. Weitere Informationen zu den Pakettypen mit virtueller Anwendung
finden Sie in der Beschreibung von Pakete mit virtueller Anwendung (siehe Seite 57).
Um Probleme mit ausgeführten gestreamten virtuellen Anwendungen auf einem
Roaming-Zielcomputer zu vermeiden, führt der CA ITCM-Agent auf dem Zielcomputer
einige Überprüfungen durch, bevor der Streaming-Server des Computers geändert wird.
Diese Überprüfungen wirken sich nicht auf den Wechsel zum neuen Scalability-Server
aus. Der Zielcomputer wechselt nicht zum neuen Scalability-Server. Die Überprüfungen
entscheiden, ob der neue Scalability-Server auch als Streaming-Server fungiert. Wenn
das Ergebnis der Überprüfungen positiv ist, wird der neue Scalability-Server zum
Streaming-Server. Wenn das Ergebnis der Überprüfungen negativ ist, wird der
ursprüngliche Scalability-Server weiterhin als Streaming-Server verwendet. Weitere
Informationen finden Sie in "Funktionsweise von Roaming mit virtuellen
Anwendungen".
Hinweise:
■
Roaming wirkt sich nicht auf die Bereitstellung von eigenständigen Paketen mit
virtueller Anwendung oder die Vorbereitung von Scalability-Servern für den
Streaming-Modus aus.
■
Sie können die Roaming-Funktion deaktivieren, indem Sie die Richtlinienparameter
der allgemeinen Konfiguration festlegen. In dem Fall agiert der ursprüngliche
Scalability-Server immer als Streaming-Server. In der DSM Explorer-Hilfe finden Sie
weitere Information zu Konfigurationsrichtlinien, insbesondere zur
Richtliniengruppe "Virtuelle Anwendungen bereitstellen".
Funktionsweise von Roaming mit virtuellen Anwendungen
Für virtuelle Anwendungen, die auf einen Zielcomputer gestreamt werden, müssen die
entsprechenden Staging-Pakete auf dem Scalability-Server (Streaming), der mit dem
Zielcomputer verbunden ist, installiert werden. Wenn ein Zielcomputer zu einem
anderen Standort und einem neuen Scalability-Server wechselt (Roaming), müssen die
Staging-Pakete für alle gestreamten virtuellen Anwendungen auf dem neuen ScalabilityServer installiert werden, bevor die Anwendungen auf dem Zielcomputer ausgeführt
werden können.
Um Probleme mit ausgeführten gestreamten virtuellen Anwendungen auf einem
Roaming-Computer zu vermeiden, führt der CA ITCM-Agent auf dem Zielcomputer
einige Überprüfungen durch, bevor der Streaming-Server des Computers geändert wird.
Diese Überprüfungen wirken sich nicht auf den Wechsel zum neuen Scalability-Server
aus. Der Zielcomputer wechselt nicht zum neuen Scalability-Server. Die Überprüfungen
entscheiden, ob der neue Scalability-Server auch als Streaming-Server fungiert. Wenn
das Ergebnis der Überprüfungen positiv ist, wird der neue Scalability-Server zum
Streaming-Server. Wenn das Ergebnis der Überprüfungen negativ ist, wird der
ursprüngliche Scalability-Server weiterhin als Streaming-Server verwendet.
Je nach Technologie, die bei der Erstellung der virtuellen Anwendungen verwendet
wurde, werden verschiedene Überprüfungen und Prozeduren werden ausgeführt. Im
Fall von VMware ThinApp wird die Roaming-Überprüfung beispielsweise während der
Benutzeranmeldung durchgeführt. Diese Überprüfungen werden jedes Mal ausgeführt,
wenn sich ein Benutzer am Zielcomputer anmeldet.
Hinweis: Für zu Roaming-Computern gestreamte Microsoft App-V-Anwendungen
müssen die Pakete mit den getreamten virtuellen Anwendungen auf dem Zielcomputer
neu installiert werden, damit der Wechsel zum neuen Streaming-Server durchgeführt
wird.
Die folgenden Abschnitte beschreiben die Überprüfung eines neuen Scalability-Servers
für virtuelle Anwendungen von VMware ThinApp und Microsoft App-V.
VMware ThinApp
1.
CA ITCM überprüft bei der Benutzeranmeldung am Zielcomputer, ob sich der
Scalability-Server geändert hat.
2.
CA ITCM stellt eine Verbindung zum neuen Scalability-Server her, wenn es
Änderungen gegeben hat.
3.
CA ITCM durchsucht den neuen Scalability-Server nach Staging-Paketen, die den
einzelnen auf dem Zielcomputer bereitgestellten virtuellen Anwendungen
entsprechen.
a.
CA ITCM verwendet den neuen Scalability-Server als Streaming-Server für alle
Anwendungen, die entsprechende Staging-Pakete auf dem neuen Server
haben.
b.
CA ITCM verwendet den ursprünglichen Scalability-Server als Streaming-Server
für alle Anwendungen, die keine entsprechenden Staging-Pakete auf dem
neuen Server haben.
Softwarekatalog
Microsoft App-V
Im Fall von Roaming müssen die Pakete mit den getreamten virtuellen Anwendungen
auf dem Zielcomputer neu installiert werden, damit der Wechsel zum neuen StreamingServer durchgeführt wird.
Es werden aufgrund des derzeitigen Stands der Technologie keine weiteren
Überprüfungen für Microsoft App-V ausgeführt.
Hinweis: Optimalerweise stellen Sie das Paket zur Bereitstellung durch Staging für jede
virtuelle Anwendung auf allen Scalability-Servern in Ihrem Netzwerk bereit, auf denen
das Windows-Betriebssystem ausgeführt wird.
1.
CA ITCM erlaubt die Anpassung an einen einem neuen Scalability-Server, wenn sich
dieser geändert hat.
2.
CA ITCM stellt eine Verbindung zum neuen Scalability-Server her, wenn es
Änderungen gegeben hat.
3.
CA ITCM verwendet den neuen Scalability-Server als Streaming-Server für alle
virtuellen Anwendungen, die auf dem Zielcomputer bereitgestellt werden.
Softwarekatalog
Der Softwarekatalog ist ein benutzerfreundliches Software Delivery-Tool, mit dem Sie
die Software auf Ihrem Computer mit Hilfe einer vom Administrator zur Verfügung
gestellten Bibliothek verwalten können.
Der Administrator erstellt Softwarepakete, die innerhalb des Unternehmens lizenziert
sind, und stellt diese in die Bibliothek des Softwarekatalogs. Mit Hilfe des
Softwarekatalogs können Sie ein Paket bestellen. Die Software wird an Ihren Computer
geliefert, installiert und ohne oder mit wenigen Eingaben bereitgestellt.
Mit dem Softwarekatalog können Sie die folgenden Tasks ausführen:
■
Software hinzufügen
■
Software anpassen
■
Software entfernen
■
Status des Softwareauftrags prüfen
Wichtig! Der Softwarekatalog ist nur für Windows-Betriebssysteme erhältlich und
erfordert das Software Delivery-Agenten-Plugin.
Softwarekatalog
Anzeige und Zugriff auf den Softwarekatalog
Der Administrator kann den Ordner "Katalog" in der Softwarepaketbibliothek mit
registrierter Software aus den anderen Ordnern füllen. Normalerweise steht diese
Software allen Desktop-Benutzern zur Verfügung.
Der Administrator kann die Software mit Hilfe der Option im Kontextmenü für Computer
oder Benutzergruppen "Softwarejobs - Software in Katalog veröffentlichen" auf
bestimmte Computer oder Benutzergruppen beschränken und spezifische Software im
Dialogfeld des Assistenten auswählen.
Der Administrator kann auch Computer, Benutzer oder Softwaregruppen in den Ordner
"Katalog" kopieren und einfügen sowie konfigurieren oder Software darin direkt
registrieren.
Hinweis: Die Software ist nur dann im Softwarekatalog sichtbar (auf dem Client), wenn
er mindestens eine katalogbasierte Installationsprozedur enthält.
Konfigurieren des Softwarekatalogs für die Desktop-Benutzer
Der Administrator ist für die Verteilung des Softwarekatalogs an mehrere Agenten
verantwortlich und muss die Softwarebibliothek einrichten und diese im
Softwarekatalog verfügbar machen.
Wenn der Agent für die Registrierung von Benutzerprofilen konfiguriert ist, bietet der
Softwarekatalog die Möglichkeit, Software für den eigenen Gebrauch zu installieren. Ein
typisches Szenario für diese Funktion ist dann gegeben, wenn ein Computer von
mehreren Benutzern genutzt wird.
Jobprüfung deaktivieren
Mit dem Symbol für die Jobprüfung im Bildschirm zur Anzeige des Auftragsstatus
können die Desktop-Benutzer den Softwarelieferungsvorgang einleiten, wenn das
Softwarepaket für die Lieferung durch Staging bereitgestellt ist. Dies geschieht immer
automatisch, aber nicht notwendigerweise sofort.
Der Administrator kann das Symbol für die Jobprüfung deaktivieren, indem er den
Parameter "DSM/Software delivery/Agent/HideJobCheckIcons" im
Konfigurationsspeicher (Comstore) setzt. Wenn dieser Parameter vorhanden ist, wird
das Symbol für die Jobprüfung im Bildschirm zum Softwareauftragsstatus nicht
angezeigt. Damit die Änderung übernommen wird, müssen Sie den Softwarekatalog neu
starten.
Softwarekatalog
Angabe des Installationstyps
Die meisten Softwarepakete können normalerweise nur auf eine Art installiert werden.
Allerdings kann der Administrator je nach Unternehmen dieselben Programme auf
verschiedene Arten zu Paketen zusammenfassen. So könnte z. B. die MarketingAbteilung eine Textverarbeitung mit vielen zusätzlichen Clipart-Bibliotheken und
Schriftarten benötigen, während die Buchhaltung eher eine einfachere Installation
bevorzugt. Diese unterschiedlichen Installationstypen liegen in der Hand des
Administrators.
Möglicherweise gibt es einen Standardinstallationstyp, der angegeben werden kann,
wenn das Softwarepaket bei Software Delivery registriert wird. Wenn es eine
Standardinstallation gibt, kann der Benutzer im Schritt "Auswahl des Installationstyps"
die Standardinstallation wählen, oder ausdrücklich einen anderen Installationstyp
angeben.
Benutzerparameter und der Softwarekatalog
Prozeduren, die das Makro "$up" verwenden, können nicht im Softwarekatalog aktiviert
werden. Dies funktioniert nicht, da der Desktop-Benutzer keinen Benutzerparameter im
Dialogfeld "Softwarekatalog" eingeben kann.
Installation des Softwarekatalogs
Im Moment gibt es nur eine Art der Installation, die Standardinstallation. Wenn Sie eine
Express-Agent-Installation durchführen, wird der Katalog standardmäßig ausgewählt.
Sie können im Bildschirm "Agent konfigurieren" die Schaltfläche "Software Delivery"
verwenden, wenn Sie bei der benutzerdefinierten DSM-Installation als Funktionalität
"Software Delivery" und als Funktion "Agent" auswählen. Die Standardauswahl ist
"Softwarekatalog installieren".
Der Softwarekatalog kann zusätzlich zu einem Software Delivery-Agenten über die
Softwarepaketbibliothek installiert werden. Öffnen Sie im DSM-Explorer in der
Software-Paket-Bibliothek das Paket "CA DSM Agent + Software Delivery Plug-in" und
ziehen Sie mit der Maus die Prozedur "Katalog: Hinzufügen" auf den Zielcomputer.
Hinweis: Um den Softwarekatalog nutzen zu können, muss Microsoft Internet Explorer
6.0 oder höher installiert sein.
Verwalten von Computern
Hinzufügen neuer Software aus dem Softwarekatalog
Mit Hilfe des Assistenten zum Hinzufügen von Software können Sie Software bestellen,
die für Ihren Computer oder, wenn das Benutzerprofil auf Ihrem Computer aktiviert ist,
Ihr persönliches Konto (Benutzerprofil) geliefert werden soll.
Das Hinzufügen von Software besteht aus folgenden Schritten:
■
Wahl der Software, die angefordert wird
Wählen Sie das Softwarepaket aus, das auf Ihrem Computer oder unter Ihrem
Konto installiert werden soll. Es wird nur die Software angezeigt, die Sie von der
Bibliothek des Softwarekatalogs aus installieren dürfen.
■
Auswahl des Installationstyps
Normalerweise können die meisten Softwarepakete können nur auf eine Art
installiert werden. Allerdings kann der Administrator für die Softwarepakete, die Sie
anfordern, verschiedene Installationsmöglichkeiten zur Verfügung gestellt haben.
■
Bestätigung des Auftrags
Das Softwarepaket und der Installationstyp, die Sie ausgewählt haben, werden
aufgeführt und Sie können den Auftrag mit "Jetzt bestellen" bestätigen. Sie können
festlegen, ob Sie benachrichtigt werden möchten, bevor die Lieferung gestartet
wird.
Hinweis: Wenn das gewünschte Softwarepaket bereits mit dem ausgewählten
Installationstyp (Elementprozedur) auf dem lokalen Computer installiert wurde,
werden Sie darüber informiert. Wenn Sie den Auftrag trotzdem ausführen, wird
eine Neuinstallation der Software ausgeführt (im Gegensatz zu einer normalen
Installation). Das ist vor allem dann sinnvoll, wenn auf Ihrem Computer das
Betriebssystem reinstalliert wurde, Software Delivery aber immer noch mit den
alten Installationsdatensätzen arbeitet.
Abschließend werden Sie in einem Bestätigungs-Dialogfenster darüber informiert, dass
Ihr Auftrag ausgeführt wird. Sie können auswählen, ob Sie den Auftragsstatus
überwachen möchten.
Weitere Informationen zu jedem dieser Schritte finden Sie in der Online-Hilfe zum
Softwarekatalog.
Dieser Abschnitt enthält Informationen zu folgenden Funktionen:
■
Verschieben von Computern zwischen Domänen-Managern in verschiedenen
Domänen oder innerhalb einer Domäne (Roaming). (siehe Seite 132)
■
Neuinstallation nach Absturz (RAC) (siehe Seite 141)
Verschieben von Computern
CA ITCM unterstützt das Verschieben von Agenten oder den Zielen von Agenten, z. B.
von Benutzerprofilen, Benutzerkonten oder Docking-Geräten und den dazugehörigen
Jobverläufen zwischen Domänen-Managern. Diese Funktion ist im Rahmen der
zunehmend mobilen Umgebungen immer wichtiger geworden. Computer werden
zwischen verschiedenen Büros bewegt, die zu unterschiedlichen Domänen gehören und
von verschiedenen Domänen-Managern verwaltet werden. Oft werden die Computer
nach den Umzügen nicht neu installiert und so ist der Verlauf der Computer (z. B. die
Datensätze zu Jobs wie Installation, Aktivierung und Konfiguration) noch gültig, der auf
dem vorherigen Domänen-Manager vorhanden ist.
Die Funktion zum Verschieben ist vor allem auf dauerhafte Wechsel von DomänenManagern ausgelegt, eher als auf häufigere Wechsel mobiler Systeme, die sich innerhalb
des Verwaltungsbereichs eines Domänen-Managers bewegen.
Verschieben von Computern zwischen Domänen
Dieser Abschnitt enthält Informationen zu folgenden Funktionen bezüglich des
Ortswechsels von Computern über Domänengrenzen hinweg:
■
Dauerhafte Verschiebungen und die Voraussetzungen dafür
■
Wirkungsbereich des Verschiebevorgangs
■
Vorgang zur dauerhaften Verschiebung
■
Rolle der Scalability-Server
■
Verbindungsaufbau für die Verschiebung und Verschieben von Datensätzen
■
Verschieben der Scalability-Server-Datensätze
■
Verschieben und Neuinstallieren nach einem Absturz
■
Status von Verschiebevorgängen im DSM-Explorer
■
Abbrechen eines Verschiebevorgangs
■
Einschränkungen der Funktion zum Verschieben
■
MSI-Unterstützung für das Verschieben oder Roaming von Zielen
Dauerhafte Verschiebungen und die Voraussetzungen dafür
Eine dauerhafte Verschiebung hat folgende Konsequenzen:
■
Der neue Domänen-Manager verwaltet den Agenten und alle Ziele (d. h.
Benutzerprofile und Benutzerkonten), die von dem Agenten abhängen.
■
Alle Datensätze erfolgreicher Jobs für die Installation von Software, die auf dem
vorherigen Domänen-Manager gespeichert sind, werden in den neuen DomänenManager importiert.
■
Der Agent und die Ziele werden vom vorherigen Domänen-Manager gelöscht, da sie
nicht mehr von ihm verwaltet werden.
Voraussetzungen für einen erfolgreichen Verschiebungsvorgang:
■
Alle Domänen-Manager, zwischen denen eine Verschiebung stattfinden soll,
müssen über eine Kommunikationsverbindung verfügen, da eine
Kommunikationsunterbrechung zur Folge hat, dass der Bericht über die
Registrierung der neuen Agenten nicht mehr den vorherigen Domänen-Manager
erreicht. (Diese Agenten bleiben dann durch den Verschiebevorgang gesperrt, bis
sie veraltet sind.)
■
Die UTC-Zeiten (Coordinated Universal Time) aller Manager sollten synchronisiert
werden, damit der Altersvergleich von Datensätzen korrekt funktioniert.
Verschiedene Zeitzonen wurden dabei berücksichtigt. Wenn die UTC-Zeiten nicht
synchronisiert werden, kann das Alter der Datensätze nicht richtig bestimmt
werden. Dies würde zu unvorhergesehenen Verschiebungen führen.
■
Bei allen Software Delivery-Komponenten sollte dieselbe Version vorliegen.
Wenden Sie sich an den Technischen Support von CA Technologies, wenn Sie
Unterstützung und Anweisungen in Bezug auf ältere Versionen von Software
Delivery-Agenten benötigen.
Wirkungsbereich des Verschiebevorgangs
Ein Verschiebevorgang umfasst die Verschiebung aller Datensätze zu (erfolgreichen)
Installationen und der entsprechenden Datensätze zu erfolgreichen Aktivierungen und
Konfigurationen. Der Installationsverlauf erfolgreich entfernter Software wird nicht
verschoben, das Gleiche gilt für Datensätze zu fehlgeschlagenen Aktivierungen und
Konfigurationen, da sie für die Beschreibung des aktuellen Status eines Agenten keine
Bedeutung haben. Beim Verschiebevorgang wird nur das Profil des aktuell
angemeldeten Benutzers verschoben. So wird sichergestellt, dass inaktive Benutzer
nicht dauerhaft in der MDB gespeichert werden. Wenn der Computer über mehrere
Benutzerprofile verfügt, können Sie die erforderlichen Profile verschieben, indem Sie
sich bei jedem Benutzerkonto anmelden, das Sie verschieben möchten.
Hinweis: Eine Verschiebung ist ein ziemlich ressourcenintensiver Vorgang. Sie umfasst
den Verbindungsaufbau zum vorherigen Domänen-Manager, die Auflistung aller
Jobdatensätze und die Aktualisierung des Jobverlaufs für das zu verschiebende Ziel. Im
Falle eines sehr umfangreichen Verschiebevorgangs von mehreren Hundert Computern
empfehlen wir, mehrere Ziele vom selben vorherigen Domänen-Manager aus zum
selben Zeitpunkt zu verschieben, da für alle Verschiebungen dieselbe Verbindung
verwendet werden kann.
Wenn der Agent neu konfiguriert wird, ist es zwingend erforderlich, dass die
Installationsdatensätze für den Agenten vom vorherigen zum neuen Domänen-Manager
verschoben werden, damit die Verwaltung dieses Agenten erfolgreich fortgeführt
werden kann.
Ein Scalability-Server ist bei dauerhaften Verschiebungen zwischen Domänen-Managern
nicht direkt beteiligt. Allerdings kann der Agent, der verschoben wird, über einen
Scalability-Server eine Verbindung zum Domänen-Manager aufbauen. So ist ein
Verschieben des Scalability-Servers selbst zu einem neuen Domänen-Manager möglich.
Beim Verschieben eines Scalability-Servers wird auch jeder Bereitstellungsdatensatz
verschoben. Obwohl die Scalability-Server-Objekte gemeinsam mit den entsprechenden
Installationen, Aktivierungen, Konfigurationen und Bereitstellungsdatensätzen
verschoben werden, werden die Ziele, die über diesen Scalability-Server Verbindungen
aufbauen, erst bei der nächsten erfolgreichen Verbindung verschoben. Das bedeutet,
dass es eine zu berücksichtigende Zeitverzögerung geben kann zwischen der
Verschiebung des Scalability-Servers und den Zielen, die über diesen Scalability-Server
Verbindungen herstellen.
Ein Verschiebevorgang ist eine Transaktion. Das bedeutet, dass alle Fehlfunktionen
während einer Verschiebung dazu führen, dass der Verschiebevorgang rückgängig
gemacht wird. Dazu gehören u. a. Softwareausnahmen oder
Kommunikationsfehler. Ein neuer Versuch wird erst dann unternommen, wenn der
Vorgang zum Verschieben von Computern erneut ausgeführt wird.
Weitere Informationen zu den Verschiebevorgängen von Agenten und Scalability-Server
finden Sie im ITCM-Implementierungshandbuch.
Vorgang zur dauerhaften Verschiebung
Es ist wichtig, dass die UTC-Zeiten aller Manager und Scalability-Server, die an einem
Verschiebevorgang beteiligt sind, synchronisiert werden, damit der Altersabgleich der
Datensätze funktionieren kann. Verschiedene Zeitzonen wurden dabei berücksichtigt.
Es wird angenommen, dass die Software auf dem zu verschiebenden Computer
während des Verschiebungsvorgangs intakt bleibt. Wenn Software während der
Verschiebung manuell entfernt oder hinzugefügt wird, ist es wichtig, dass alle
Änderungen auch auf dem Domänen-Manager aufgezeichnet werden, der jetzt den
Computer verwaltet, z. B. durch das manuelle Löschen der
Installationsdatensätze für die Software, die manuell entfernt wurde.
Bei jedem Verbindungsaufbau zwischen einem Software Delivery-Agenten (SD-Agent)
und einem Manager oder Scalability-Server wird eine Meldung an den Agenten
übermittelt. Die Meldung enthält Informationen über die Adresse des DomänenManagers, der den Agenten verwaltet, und über die aktuelle UTC-Zeit des ScalabilityServers. Der Agent speichert die Adresse des Domänen-Managers lokal. Wenn der Agent
bei zwei aufeinanderfolgenden Verbindungen eine Änderung der Adresse des DomänenManagers feststellt, wird für alle vom SD-Agenten verarbeiteten Ziele (z.#160;B. die
Benutzerprofile) die Adresse des vorherigen Domänen-Managers aufgerufen.
Die Adresse des vorherigen Domänen-Managers wird über die SD-Infrastruktur zum
neuen Domänen-Manager übertragen, der versucht, den Verschiebevorgang
durchzuführen.
Dieser Vorgang wird für alle Ziele wiederholt, die von dem Agenten verwaltet werden,
und findet immer statt, sobald der Agent auf einen neuen Domänen-Manager
verschoben wird.
Der Agent verwendet die übermittelte UTC-Zeit des Scalability-Servers bei der
Berechnung seines Referenzzählers, der eine Art Zeitstempel für jede Verbindung
darstellt. Der Referenzzähler wird über die Infrastruktur an den übergeordneten
Domänen-Manager übermittelt. Er wird verwendet, um festzustellen, welcher von zwei
miteinander verglichenen Zieldatensätzen bei einem Verschiebevorgang der neueste ist.
Da sich der SD-Agent nicht immer voll auf die SD-Manager-Zeit verlassen kann, führt er
eine Verträglichkeitsprüfung durch, indem er sie mit seinem vorherigen Referenzzähler
vergleicht. Wenn die aktuelle UTC-Zeit des Scalability-Servers zeigt, dass der vorige
Referenzzähler erhöht werden sollte, wird die UTC-Zeit dazu verwendet, den neuen
Referenzzähler zu berechnen.
Wenn die aktuelle UTC-Zeit des Managers allerdings anzeigt, dass der Referenzzähler
reduziert werden sollte, verwirft der SD-Agent diese UTC-Zeit und erhöht einfach den
vorherigen Referenzzähler, um sicherzustellen, dass ein höherer Wert für jede
Verbindung zum Scalability-Server verwendet wird.
Bei neu installierten SD-Agenten wird der Referenzzähler immer mit Hilfe der aktuellen
UTC-Zeit des Scalability-Servers initialisiert.
Rolle der Scalability-Server
Ein Scalability-Server ist verantwortlich für das Übermitteln der Adresse des vorherigen
Domänen-Managers an den neuen Domänen-Manager im Auftrag des Ziels. Wenn ein
Ziel aufgrund eines Verschiebe- oder Löschvorgangs vom Domänen-Manager entfernt
wurde, wird es während der nächsten Phasenprüfung auch vom Scalability-Server
entfernt.
Wenn ein Scalability-Server zwischen Domänen-Managern verschoben wird, stellen Sie
sicher, dass die Agenten dieses Scalability-Servers bei dem neuen Manager registriert
werden, bevor die Agenten verschoben werden, da der Verschiebevorgang sonst
fehlschlägt. Sie können die Agenten manuell mit dem Befehl "caf register" registrieren
oder warten, bis sich die Agenten automatisch entsprechend dem Zeitplan beim neuen
Domänen-Manager registrieren.
Verbindungsaufbau für die Verschiebung und Verschieben von Datensätzen
Bei einer erfolgreichen Verbindung zwischen den beiden Domänen-Managern wird der
vorherige Domänen-Manager auf folgende Weise nach Informationen über das aktuell
zu verarbeitende Ziel (z. B. Benutzerkonto und Benutzerprofil) abgefragt:
■
Wenn der vorherige Domänen-Manager nicht über einen Datensatz für dieses Ziel
verfügt, wird die Verschiebung übergangen.
■
Wenn der vorherige Domänen-Manager über einen Datensatz für dieses Ziel
verfügt, wird ein Vergleich der Referenzzähler der beiden Zieldatensätze
durchgeführt. Wenn der vorherige Domänen-Manager einen aktuelleren
Referenzzähler aufweist, wird die Verschiebung abgebrochen. Anderenfalls wird der
Verschiebevorgang fortgesetzt.
■
Die Attribute des Ziels auf dem vorherigen Domänen-Manager werden nicht
verschoben, solange angenommen wird, dass die momentan erstellten aktueller
sind.
■
Wenn der Zieldatensatz auf dem vorherigen Domänen-Manager durch einen
Verschiebevorgang gesperrt ist, wird eine Prüfung vorgenommen, um festzustellen,
ob die beiden Domänen-Manager darauf warten, Datensätze untereinander
auszutauschen. Ist das der Fall, dann wird das Ziel mit dem höchsten (also jüngsten)
Referenzzähler als gültig betrachtet und der Verschiebevorgang fortgesetzt, wenn
der aktuelle Domänen-Manager über den Datensatz verfügt. Wenn der
Verschiebevorgang auf dem vorherigen Domänen-Manager auf das Verschieben
von Datensätzen eines dritten Domänen-Managers wartet, wird der
Verschiebevorgang zurückgestellt, bis die andere Verschiebung abgeschlossen ist.
Als Nächstes wird die aktuelle Zeit des vorherigen Domänen-Managers abgefragt. Die
zurückgegebene Zeit wird mit der Zeit des aktuellen Domänen-Managers verglichen,
und die Zeitabweichung (Zeitzone) wird bestimmt. Für jeden Installationsdatensatz, der
mit dem Ziel auf dem vorherigen Domänen-Manager verknüpft ist, wird auf dem
aktuellen Domänen-Manager ein neuer Datensatz erstellt, wobei sein Enddatum und die
Zeit durch Anrechnung der Zeitabweichung ermittelt wird. Alle Datensätze erfolgreicher
Aktivierungen und Konfigurationen, die einem verschobenen Installationsdatensatz
zugeordnet sind, werden ebenfalls verschoben. Softwareelemente, die nicht in der
Softwarepaketbibliothek des aktuellen Domänen-Managers registriert sind, werden als
"Gefunden" gekennzeichnet. Die Ausgabedatei wird aus Leistungsgründen nicht
verschoben.
Nach einer erfolgreichen Verschiebung aller Datensätze wird der Zieldatensatz auf dem
vorherigen Domänen-Manager zusammen mit allen zugeordneten Datensätzen
bezüglich Installation, Aktivierung, Konfiguration und Deinstallation gelöscht.
Nach einer erfolgreich abgeschlossenen Verschiebung wird die Sperrung des Ziels
wieder aufgehoben.
Hinweis: Der Verschiebevorgang ist eine Transaktion. Tritt während der Verschiebung
ein Fehler auf, wird der gesamte Vorgang rückgängig gemacht, damit ein zweiter
Versuch stattfinden kann, wenn der Vorgang zum Verschieben von Computern das
nächste Mal ausgeführt wird.
Verschieben der Scalability-Server-Datensätze
Wenn das zu verschiebende Ziel ein Scalability-Server ist, wird dieselbe Logik verfolgt
wie bei regulären Zielen, mit einem Zusatz: Alle Datensätze erfolgreicher
Bereitstellungen eines Scalability-Servers werden ebenfalls verschoben.
Sind Bereitstellungsdatensätze mit Software verknüpft, die nicht in der Bibliothek des
neuen Domänen-Managers registriert ist, werden sie übergangen. Durch die
Registrierung der Software in der Softwarepaketbibliothek des neuen DomänenManagers und der anschließenden Ausführung einer Synchronisierungsprozedur mit
dem Scalability-Server können diese Datensätze aber erneut erstellt werden.
Das Verschieben von Zielen, die über einen Scalability-Server Verbindungen herstellen,
ist nicht Teil des Verschiebevorgangs für einen Scalability-Server. Alle Ziele, die über den
verschobenen Scalability-Server Verbindungen aufbauen, werden irgendwann über den
Scalability-Server auf dem neuen Domänen-Manager registriert und mit Hilfe der
konventionellen Autoregistrierungs- und Verschiebungsmechanismen vom vorherigen
Domänen-Manager aus verschoben.
Verschiebevorgang für Scalability-Server und Agenten
werden, bevor die Agenten verschoben werden, da der Verschiebevorgang sonst
fehlschlägt.
werden, bevor der Softwarekatalog auf den einzelnen, mit diesem Scalability-Server
verbundenen Agenten verwendet wird. Andernfalls schlägt die Verwendung des
Katalogs fehl.
Sie können die Agenten manuell mit dem Befehl "caf register" registrieren oder warten,
bis sich die Agenten automatisch entsprechend dem Zeitplan beim neuen DomänenManager registrieren.
Verschieben und Neuinstallieren nach einem Absturz
Wenn beim Verschieben eines Ziels der neue Domänen-Manager einen Vorgang zur
Neuinstallation nach einem Absturz erkennt (RAC), hat die Verschiebeoperation Vorrang
vor der Funktion zur Neuinstallation. Nach dem erfolgreichen Abschluss der
Verschiebung wird der RAC-Vorgang aufgerufen, um alle verschobenen Jobdatensätze
neu zu installieren.
Die Neuinstallation nach einem Absturz wird eingeleitet, wenn die UUID (Universal
Unique Identifier, universeller eindeutiger Bezeichner) sich nach der Registrierung auf
dem neuen Domänen-Manager ändert, bevor der Vorgang abgeschlossen ist.
Hinweis: Wenn das Ziel während der physischen Verschiebung (also vor Einleitung des
Verschiebevorgangs) neu installiert wird, findet keine Verschiebung der Jobdatensätze
statt, da der Software Delivery-Agent (SD-Agent)über die Adresse des vorherigen
Domänen-Managers verfügt und diese Daten bei der Neuinstallation des Agenten oder
des Betriebssystems verloren gehen.
Wenn ein Ziel auf einen neuen Domänen-Manager verschoben und auf dem vorherigen
Domänen-Manager ein RAC-Vorgang erkannt wird, dann wird die Verschiebeoperation
so lange verzögert, bis der Remote-RAC-Vorgang abgeschlossen ist.
Beispiel: Der SD-Agent war mit einem Scalability-Server verbunden, der dem vorherigen
Domänen-Manager untergeordnet war, bevor er zum aktuellen Domänen-Manager
verschoben wurde. Das Ziel hat alle RAC-Jobs ausgeführt, aber der Scalability-Server hat
noch immer keine Berichte über die RAC-Ergebnisse an seinen Domänen-Manager
geliefert. Wenn der Scalability-Server die RAC-Ergebnisse an den Domänen-Manager
geliefert hat, findet die Verschiebung der Datensätze zwischen den beiden DomänenManagern statt.
Status von Verschiebevorgängen im DSM-Explorer
Die Benutzeroberfläche des DSM-Explorers zeigt den Fortschritt der
Verschiebevorgänge an. Die Spalte "Status" zeigt den Status des Verschiebevorgangs an.
Wählen Sie dazu die Option "Alle Computer", und sehen sich das Ergebnis im rechten
Fenster an.
Abbrechen eines Verschiebevorgangs
Eine Verschiebung ist z. B. nicht möglich, wenn der vorherige Domänen-Manager
aufgrund eines Hardwareschadens ausgefallen ist. Nachdem die Software DeliveryAgenten neu konfiguriert wurden, um eine Verbindung zu einem neuen DomänenManager aufzubauen, wird der Name des vorherigen Domänen-Managers noch immer
an den neuen Domänen-Manager gemeldet und eine Verschiebung geplant. Um mit
diesen Szenarien umgehen zu können, können Sie ein oder mehrere Ziele markieren,
mit der rechten Maustaste darauf klicken und anschließend im Kontextmenü die Option
"Verschiebevorgang abbrechen" wählen, um den Jobverlauf für die betreffenden Ziele
zu löschen.
Einschränkungen der Funktion zum Verschieben
Verschiebungen zwischen verschiedenen Versionen von Domänen-Managern werden
möglicherweise nicht unterstützt, wenn die beiden Versionen von Software Delivery
große Unterschiede im API-Protokoll aufweisen. Außerdem werden Verschiebungen von
lokalen Unicenter Software Delivery 4.0-Servern aus nicht unterstützt.
Aus Leistungsgründen werden Ausgabedateien von Jobs nicht verschoben.
Das Verschieben von Computern wird für automatisch registrierte Zielcomputer
unterstützt.
Bei manuell mit Hilfe von DSM-Explorer registrierten Zielcomputern wird eine
Verschiebung zum Registrierungszeitpunkt vom vorherigen zum aktuellen DomänenManager nicht unterstützt.
Verschiebevorgänge unterstützen zwar Aktualisierungen, aber wenn zwischen den
einzelnen Verschiebevorgängen ein neues Image eines Agentensystems angelegt wird,
kann kein automatischer Verschiebevorgang mehr durchgeführt werden, weil alle
Informationen über den vorherigen Domänen-Manager im neuen Betriebssystem-Image
fehlen. Dasselbe gilt für den Fall, dass ein Agent deinstalliert und später wieder neu
installiert wird.
Die Funktion zum Verschieben von Computern ist für häufig wechselnde Agenten
("Roaming") nicht ausgelegt, löst aber das Problem einzelner, dauerhafter Umzüge von
Agenten zwischen verschiedenen Domänen-Managern. Sie ist daher für ein Szenario von
Hunderten oder Tausenden von wandernden Agenten pro Tag nicht angemessen.
Die Funktion zum Verschieben umfasst nicht das automatische Verschieben von
Zielcomputern zwischen Boot-Servern.
MSI-Unterstützung für das Verschieben oder Roaming von Zielen
Wenn ein Computer versetzt oder verschoben wird, kann es vorkommen, dass MSIbasierte Anwendungen den Netzwerkpfad zum Installations-Image verlieren. Der Zugriff
auf diese Installations-Images ist für angekündigte Produkte und den Einsatz von
"Selbstreparaturen" und "bedarfsorientierten Installationen" jedoch enorm wichtig.
Ein MSI-basiertes Produkt enthält eine Liste mit Quellenangaben (SOURCELIST) in der
Registrierung, in der mehrere Quellpfade angegeben werden können. Diese Liste mit
Quellenangaben wird bei Erkennung eines Roam- oder Verschiebevorgangs aktualisiert,
und ein installiertes Produkt befindet sich dann in MSILIB auf dem neuen ScalabilityServer. Die Aktualisierung wird von der Software Delivery-Agentenrichtlinie "MSI source
update" gesteuert.
Verschieben von Computern in derselben Domäne (Roaming)
CA ITCM unterstützt die Verschiebung von Software-Delivery-Agenten zwischen
Scalability-Servern, die mit dem gleichen Domänen-Manager Verbindung aufnehmen.
Alle Datensätze des Software-Delivery-Agenten werden auf dem früheren ScalabilityServer gelöscht, nachdem ausstehende Jobergebnisse erfasst worden sind. Während
des Roamings aktive Jobs können ihre Ausführung durch den neuen Scalability-Server
fortführen.
Da die Ziele den Domänen-Manager in diesen Szenarien nicht ändern, ist es nicht
notwendig, den Jobverlauf zu verschieben.
Roaming-Jobs
Ein Job wird als verschoben betrachtet, sobald dessen Anforderung von ScalabilityServer A stammt und der Software Delivery-Agent (SD-Agent) sich über ScalabilityServer B registriert.
Der SD-Agent wechselt von Scalability-Server A zu Scalability-Server B. Der SD-Agent
wird automatisch auf Scalability-Server A registriert. Auf dem Agenten wurden mehrere
Jobs eingerichtet, die jetzt in der Dateidatenbank auf Scalability-Server A bereitgestellt
werden. Anschließend wird der Agent über Scalability-Server B registriert.
Wenn Scalability-Server B seinen neuen Agenten beim Domänen-Manager anmeldet,
löst der Domänen-Manager den Scalability-Server A aus. Scalability-Server A übergibt
die Jobergebnisse für diesen Agenten, und der Domänen-Manager erkennt, dass dieser
Agent auf Scalability-Server B verschoben wurde. Alle Jobs, die noch nicht ausgeführt
sind, werden zurückgesetzt, und Scalability-Server B wird ausgelöst. Scalability-Server B
übernimmt die zurückgesetzten Jobs.
Zusätzlich wird der Name des Managers, der die Jobs empfangen hat, von Software
Delivery intern verwaltet, um sicherzustellen, dass kein Batch unterbrochen wird. In
dem zuvor gezeigten Szenario übernimmt der neue SD-Manager keinen Job, bis die
Ergebnisse vom bisherigen Manager vorliegen, die Jobs vom Administrator gelöscht
wurden oder ihr Zeitlimit überschritten ist. In dieser Zeit können keine neuen Jobs für
den Roaming-Agenten eingerichtet werden.
Nach einem Absturz erneut installieren
Software Delivery kann den Zustand von Computern automatisch wiederherstellen,
indem die RAC-Funktion (Neuinstallation nach Absturz) automatisch aufgerufen wird.
Dies geschieht, wenn der SD-Agent die Neuinstallation des Betriebssystems meldet. Alle
zuvor vorhandenen Software-Programme werden gemäß dem Jobverlauf des
Computers, der in der Datenbank gespeichert ist, neu installiert und konfiguriert.
Während der Funktion zur Neuinstallation nach Abstürzen ist der Computer gesperrt,
daher können keine weiteren Jobs initiiert werden.
Im Rahmen eines generischen RAC-Vorgangs wird auf der Grundlage der aktuellen
Jobverlaufsdaten für einen Zielcomputer ein Jobcontainer erstellt. Dieser Vorgang ist
der Erstellung eines Jobcontainers für eine Vorlage sehr ähnlich.
Die generische RAC ist eine Funktion, die für alle Pakettypen verwendet werden kann
(z. B. SD-, SXP- und MSI-Elemente). Sie ist für alle Betriebssystemumgebungen
verfügbar, die den UUID-Mechanismus unterstützen, also alle Linux/UNIX-und
Windows-32-Bit-Plattformen. Das generische RAC kann verwendet werden, um
Prozeduren zu konfigurieren und zu aktivieren.
Hinweis: Software-Versionen, die nicht mehr verwendet werden, aber noch registriert
sind, können von der RAC-Funktion ausgeschlossen werden, indem die Option 'Aus RAC
ausschließen' der Installationsprozedur aktiviert wird.
RAC-Konfiguration
Es hängt von der Einstellung der Parameter "RAC-Richtlinie" und "RAC-Automatisierung"
im Konfigurationsspeicher (Comstore) ab, wie der Domänen-Manager die RAC
verwaltet.
Sie können den Parameter "RAC-Automatisierung" über die Systemsteuerung im DSMExplorer einstellen, indem Sie im Unterordner "Softwarejobmanagement" von
"Konfiguration" das Dialogfeld "Neuinstallation nach Absturz" aufrufen.
Wenn beim Installieren eines neuen Betriebssystems die RAC-Richtlinie ausgewählt ist,
wird der Domänen-Manager vom Software Delivery-Agenten (SD-Agent) benachrichtigt.
Der Domänen-Manager setzt den Status des Computers auf "Neuinstallation nach
Absturz" und sperrt den Computer. Alle Installationsdatensätze im Ordner "Jobs" für
den SD-Agenten werden als "Deinstalliert" gekennzeichnet.
Der Domänen-Manager führt eine der folgenden Optionen aus:
■
Keine weitere Aktion außer der Entsperrung des Computers (deaktivierte RACAutomatisierung)
■
Erstellen eines RAC-Jobcontainers für den SD-Agenten, Füllen des Containers mit
Anweisungen zum Ausführen aller zuvor erfolgreich ausgeführten Jobs, Container
bleibt unversiegelt (zurückgestellte RAC-Automatisierung). Der Container kann
überprüft und geändert werden, da er manuell aktiviert werden muss.
■
Erstellen eines RAC-Jobcontainers für den SD-Agenten, Füllen des Containers mit
Anweisungen zum Ausführen aller zuvor erfolgreich ausgeführten Jobs, Versiegeln
und Aktivieren des Containers (automatische RAC-Automatisierung).
Wenn der Computer mit Windows 2000, Windows XP oder
Windows 2003 über Benutzerprofil-Agenten verfügt, werden das Computerprofil
und jeder Benutzerprofil-Agent getrennt verwaltet. Die Installationsdatensätze der SDAgent werden separat gelöscht, und den einzelnen Agenten wird ein eigener
Jobcontainer zugewiesen (sofern ein solcher Container erzeugt wird).
Prozeduroption "Aus RAC ausschließen"
Wenn eine Elementprozedur nicht als Teil des RAC-Prozesses ausgeführt werden soll,
können Sie die Option "Aus RAC ausschließen" für diese Prozedur festlegen. Der Zweck
dieser Option ist der automatische Ausschluss bestimmter Prozeduren aus einem RACContainer. Weitere Informationen zur Option "Aus RAC ausschließen" finden Sie im
Abschnitt "Ausschließen von Elementprozeduren von der RAC-Option (Reinstall After
Crash) (siehe Seite 77)".
Konfigurieren individueller RAC-Richtlinien für Computer
Sie können für jeden Computer eine individuelle RAC-Einstellung (Reinstall after Crash,
Neuinstallation nach Absturz) festlegen. Diese Einstellung setzt die RAC-Richtlinie außer
Kraft, die auf dem mit diesem Computer verbundenen Domänen-Manager definiert ist.
So definieren Sie eine individuelle RAC-Einstellung für einen Computer:
1.
Klicken Sie im Manager mit der rechten Maustaste auf die Baumansicht des DSMExplorers.
Das entsprechende Kontextmenü wird angezeigt.
2.
Wählen Sie im Kontextmenü die Option "Eigenschaften".
Das Dialogfeld "Eigenschaften" wird angezeigt.
3.
Klicken Sie auf die Registerkarte "Software Delivery" und ändern den Wert für den
Eintrag im Feld "RAC-Richtlinie".
Der Standardwert ist "Allgemein", d. h., es wird die allgemeine Richtlinie für
den Domänen-Manager verwendet.
Hinweis: Wenn die allgemeine RAC-Richtlinie auf "Deaktiviert" eingestellt ist, haben
individuelle RAC-Einstellungen keine Wirkung.
RAC-Jobcontainer
Wenn ein Zielcomputer meldet, dass ein neues Betriebssystem (BS) installiert wurde
(erkennbar an der Änderung der Host-UUID), werden alle bisherigen erfolgreichen
Installations- und Verteilungsdatensätze im Jobverlauf des Zielcomputers mit dem
Ausdruck "*von RAC entfernt" versehen.
Hinweis: Wenn die Konfigurationsrichtlinie "DSM/Software Delivery/Manager/RACRichtlinie" auf "False" (Falsch) gesetzt ist, bleiben vorhandene Datensätze unberührt,
und es wird kein RAC-Jobcontainer erstellt.
Dann wird je nach aktueller Konfigurationseinstellung der RAC-Richtlinie von einem
Domänen-Manager automatisch ein Jobcontainer erstellt bzw. nicht erstellt. Alle
bisherigen erfolgreichen Jobs, die den zuvor genannten Installations- und
Verteilungsdatensätzen zugeordnet sind, werden in den Container aufgenommen.
Dieser wird dann in der Liste der Jobcontainer angezeigt, wobei der Name das Präfix
RAC trägt. Der Name des Jobcontainers wird nach folgendem Schema erstellt:
RAC: Computername [ Aktuelles_DatumAktuelle_Uhrzeit]
Alle RAC-Container werden mit der UUID des entsprechenden Computers und der
Uhrzeit versehen, zu der die neue BS-Installation stattgefunden hat. Dadurch wird
sichergestellt, dass nur RAC-Container mit einer aktuellen UUID ausgeführt werden. Jobs
in einem RAC-Container mit einer alten UUID schlagen fehl und werden in den
Fehlerstatus versetzt: RAC-Container ist veraltet. Dieser Fall tritt ein, wenn der Software
Delivery-Agent mit einem neuen Betriebssystem installiert wird, bevor ein zuvor
erstellter RAC-Container vollständig ausgeführt wurde.
Neue Installationen und Jobs, die offline erzeugt und zusammen mit der neuen BSInstallation gemeldet wurden (durch Verwendung der neuen UUID), werden nicht in den
RAC-Container aufgenommen. Alte und neue Installationen für Ziele werden getrennt,
indem die UUID für jeden Job aufgezeichnet wird. Alle Jobdatensätze, die offline erzeugt
wurden, werden mit der UUID versehen.
Die Einschränkung früherer Software Delivery-Versionen, die Ausführung von
Aktivierungs- und Konfigurationsprozessen zu verbieten, solange diese nicht an eine
bestehende Installation des aktuellen Ziels gebunden sind, wurde gelockert, um einen
RAC-Container alle Jobs auf der Basis des Jobverlaufs des Ziels in einem Durchlauf
ausführen zu lassen.
Damit eine größtmögliche Regenerierung des Ziels möglich ist, werden folgende
Standardwerte für einen RAC-Container verwendet:
■
Batch-Verknüpfung
■
Die Option "Transaktion aktivieren" ist nicht eingestellt
■
Die Option "Überlappende Installation von abhängigen Paketen ignorieren" ist nicht
eingestellt
Hinweis: Die Batch-Verknüpfung für einen nicht versiegelten Jobcontainer kann
synchronisiert werden.
Bei der Erstellung des RAC-Containers wird die Abschlusszeit der Computerjobs
(Jobverlauf) verwendet, um die Ausgangsreihenfolge der Jobs festzulegen. Lieferungen
werden grundsätzlich an die erste Stelle gesetzt. Solange der Jobcontainer nicht
versiegelt ist, können die Jobs gelöscht oder umpositioniert werden. Es können auch
weitere Jobs zum Container hinzugefügt werden.
Wenn ein Job nicht eingerichtet werden kann, weil die zu verwendende Software
bereits archiviert wurde, wird der Job in den Warnstatus versetzt und der Jobcontainer
bleibt unversiegelt.
Jobs, deren Ausführung vor der Initialisierung von RAC nicht abgeschlossen werden
konnten, werden in einen Fehlerstatus versetzt. Sie werden nicht im RAC-Container
aufgenommen und können nicht erneuert werden, da sie mit der alten UUID versehen
sind. Nach Abschluss des RAC-Vorgangs sollten Sie überprüfen, ob diese Jobs erneut
eingerichtet werden sollen.
Wenn ein RAC-Jobcontainer für ein Ziel erstellt wurde, wird das Ziel so lange gesperrt,
bis der Container vollständig abgearbeitet ist oder gelöscht wird. Während der Sperrung
des Ziels wird der Computername in der Baumansicht von DSM-Explorer rot angezeigt.
In dieser Zeit können keine anderen Jobs für diesen Zielcomputer geliefert, ausgeführt
oder gelöscht werden. Alle Jobs, die eingerichtet werden, schlagen fehl und geben einen
Fehler zurück: Job ist nicht zulässig: Computer wurde von der RAC gesperrt.
In der Zeit, in der der Zielcomputer gesperrt ist, werden Vorlagen für das Ziel
eingerichtet und dem Ordner Ausnahmen hinzugefügt. Wenn diese Jobvorlagen noch
während der Sperrung aktiviert werden, werden sie jedoch ebenfalls fehlschlagen. Jobs,
die vom Enterprise-Manager aus angefordert werden, werden als fehlgeschlagen
gekennzeichnet, wenn sie während der Sperrung des Zielcomputers aktiviert werden.
Installations- und Jobdatensätze können während der Sperrung des Zielcomputers nicht
gelöscht werden.
Wenn ein RAC-Container fehlschlägt, steht die Standardfunktion zur Erneuerung zur
Verfügung. Wenn ein Job fehlschlägt, weil er nicht auf der neuen BS-Installation
ausgeführt werden kann, kann dieser Job aus dem RAC-Container entfernt werden,
bevor dieser erneuert wird.
Im Falle einer vollständigen Erneuerung, bei der ein neues Betriebssystem erforderlich
ist, sollte der RAC-Container gelöscht und eine neue BS-Installation eingeleitet werden.
Wenn die ausgewählte RAC-Richtlinie angibt, dass keine RAC-Automatisierung
stattfinden soll, und keine Jobs eingerichtet wurden, dann wird der Zielcomputer
freigegeben, sobald sein Installationsregister bereinigt wurde.
Jobverlauf mit beibehaltenen Jobauftragsdaten
Die Jobauftragsoption Benutzerparameter verbleibt in den Computerjobs. Bei den
anderen Optionen werden die Standardwerte verwendet.
Prozeduroptionen werden von der verwendeten Prozedur übernommen. Die
Joboptionen werden vom Administrator konfiguriert. Folgende Joboptionswerte sind die
Standardwerte:
■
Job wird vom Server ausgelöst=Ja
■
Lieferungskalender verwenden=Nein
Die Parameter "JobTimeout" und "StoreInSSLibrary" im RAC-Abschnitt des
Konfigurationsspeichers können ebenfalls verwendet werden, um das Zeitlimit für Jobs
zu steuern und zu bestimmen, ob Pakete in der Bibliothek gespeichert werden sollen.
Einbezogene und ausgeschlossene Jobs in einem RAC-Jobcontainer
Jobs werden immer in einen RAC-Jobcontainer aufgenommen, wenn sie folgende
Elemente umfassen:
■
Erkannte Software, wenn die Software zu einem echten Softwareelement
umgewandelt (registriert) wurde und eine Standardinstallationsprozedur aufweist.
■
Bereitstellungsdatensätze für einen Scalability-Server.
Folgende Jobs werden aus einem RAC-Jobcontainer ausgeschlossen:
■
Jobs, die auf deinstallierte Software und auf Prozeduren verweisen, die mit der
Option Aus RAC ausschließen gekennzeichnet sind.
■
Jobs, die von einer Aktivierungs- oder Konfigurationsprozedur eingerichtet wurden,
wenn die dazugehörige Installationsprozedur mit der Option Aus RAC ausschließen
gekennzeichnet ist.
Verhältnis zu Verschiebevorgängen
Informationen zum Verhältnis zwischen RAC und Verschiebevorgängen finden Sie unter
"Verschieben und Neuinstallieren nach einem Absturz" (siehe Seite 95).
RAC-Einschränkungen
Nur Zielcomputer mit dem UUID-Mechanismus kommen für die Funktion
"Neuinstallation nach Absturz (RAC)" in Frage. Dazu gehören alle 32- und 64-BitVersionen von Windows sowie alle Linux/UNIX-Plattformen. Allerdings sind DockingGeräte von der RAC ausgenommen, weil sie die UUID des Host-Computers melden.
RAC auf Zielcomputern, die über DTS-Download konfiguriert wurden, nutzen alternativ
den internen Download ohne NOS. Ein Grund dafür ist die Zwischenspeicherung
gesendeter Pakete auf der Festplatte des Zielcomputers, die bei der Neuinstallation des
Betriebssystems überschrieben wird. Ein weiterer Grund ist, dass DTS nicht mit dem
Software Delivery-Agenten zusammengefasst ist, sondern als Job gesendet wird.
RAC ist auf Scalability-Servern (einschließlich Bibliothek) nur dann möglich, wenn der
Scalability-Server von Anfang an installiert ist. Es ist also nicht möglich, den ScalabilityServer von einer Agenteninstallation aus wiederherzustellen, da ansonsten alle
Bereitstellungsdatensätze als gelöscht gekennzeichnet werden. Es werden nur die Teile
der Bibliothek wiederhergestellt, die dem Domänen-Manager bekannt sind.
Es gibt keine Synchronisierung zwischen der RAC für Computerziele und der für
Benutzerprofilziele. Wenn z. B. ein Benutzerprofiljob von einem Computerjob
abhängt, gibt es keinen Mechanismus außer der Verwendung von Voraussetzungen für
Prozeduren.
Die Reihenfolge innerhalb des Jobverlaufs wird mit einer Ausnahme beibehalten. Bei
Scalability-Servern werden zuerst Lieferungen eingerichtet, erst dann alle anderen Jobs.
Die Reihenfolge innerhalb der Lieferungen und innerhalb der anderen Jobs bleibt aber
erhalten.
Benutzerdefinierte Administratormeldung
Benutzerdefinierte Administratormeldung
Sie können Software Delivery dazu verwenden, zum Zeitpunkt der Erstellung eines
Jobcontainers eine Textmeldung zu erstellen, zu definieren oder einem Jobcontainer,
individuellen Jobs (Aktivitäten innerhalb eines Jobcontainers) oder beiden zuzuweisen.
Sie können die Textmeldung auch für die Prozedur eines Softwarepakets hinzufügen. Die
Meldung wird den Endbenutzern bei Ausführung des zugeordneten Jobcontainers und
dessen Jobs angezeigt. Sie können mit diesen Meldungen den Endbenutzern
entsprechende Informationen übermitteln, zum Beispiel können Sie die folgenden
Informationen in der Meldung angeben:
■
Informieren Sie Endbenutzer über den Zweck der Aufgabe, die auf dem
Zielcomputer ausgeführt wird.
■
Informieren Sie Endbenutzer über bestimmte Aktionen, die Sie (als Administrator)
vor oder nach einer Aufgabe auf dem Zielcomputer ausführen möchten.
■
Informieren Sie Endbenutzer über bestimmte Aktionen, die sie (Endbenutzer) vor
oder nach der Aufgabe ausführen müssen.
■
Nehmen Sie Hyperlinks in die Meldungen für mehr Informationen auf, um
Endbenutzer an die entsprechenden Ressourcen zu verweisen.
Hinweis: Weitere Informationen zur Definition und Zuordnung einer
benutzerdefinierten Administratormeldung finden Sie im Abschnitt "Software Delivery"
der DSM-Explorer-Hilfe.
Verschieben der OSIM-Jobinformationen
Die Software Delivery-Funktionalität ermöglicht Ihnen, OSIM-Jobinformationen zu
übertragen, wenn Sie einen Zielcomputer von einem Domänen-Manager zu einem
anderen verschieben. Die gesamten Informationen zu abgeschlossen, geplanten und
aktivierten OSIM-Jobs werden aufbewahrt und als Teil aller standardmäßigen SDVerschiebevorgänge von Computern verschoben. Sie müssen keine manuellen Schritte
ausführen, um die Informationen über verschiedene Domänen-Managern zu
importieren oder exportieren. Sie können automatisch die vollständigen OSIMJobinformationen mit den SD-Installationsdatensätzen übertragen, während Sie einen
normalen Computer-Verschiebevorgang ausführen.
Hinweis: Weitere Informationen zur Funktionsweise des Verschiebens von OSIMJobinformationen während eines SD-Verschiebevorgangs von Computern, finden Sie im
Abschnitt "Software Delivery" der DSM-Explorer-Hilfe.
Optimierung der gleichzeitigen Ausführung von Managern
Optimierung der gleichzeitigen Ausführung von Managern
Software Delivery optimiert den Prozess, vielfache Aufgaben durch die Verbesserung
des Task-Managers und Gleichzeitiger Ausführung der Installations-Manager zu
bewältigen. Software Delivery bietet Konfigurationsrichtlinien, die es ermöglichen, den
Task-Manager und Installations-Manager im gleichzeitigen Modus auszuführen, damit
vielfache Aufgaben gleichzeitig bewältigt werden können. Dieser Ansatz mehrerer
gleichzeitiger Prozesse, den der gleichzeitige Modus bietet, hilft Ihnen dabei, die
gleichzeitige Ausführung der Manager, und somit die Leistung der Software DeliveryEngine, zu optimieren.
Hinweis: Weitere Informationen zur Optimierung der gleichzeitigen Ausführung der
Manager finden Sie im Abschnitt "Software Delivery" der DSM-Explorer-Hilfe.
Verschlüsselung und Drosselung für Übertragungen von
Software-Paketen ohne NOS
Software Delivery ermöglicht Ihnen, die Verschlüsselung und Drosselung für
Übertragungen von Software-Paketen ohne NOS zu konfigurieren. Die entsprechende
Konfiguration und Anwendung der Verschlüsselungs- und Drosselungsparameter helfen
Ihnen dabei, die Netzwerkressourcen optimal auszunutzen. Mit diesen Konfigurationen
können Sie die Übertragung von Softwarepaketen ohne NOS von einem ScalabilityServer auf einen Software-Delivery-Agenten für ausführende Software-Jobs
kontrollieren.
Hinweis: Weitere Informationen zur Konfiguration der Verschlüsselung und Drosselung
von Übertragungen des Software-Pakets ohne NOS finden Sie im Abschnitt "Software
Delivery" der DSM-Explorer-Hilfe.
Optimierung von Datenbankaktualisierungen
Optimierung von Datenbankaktualisierungen
Mit Software Delivery können Sie den Scalability-Server und den Installations-Manager
konfigurieren, um ein besseres Leistungsniveau bei Datenbankaktualisierungen zu
erreichen. Durch die entsprechende Konfiguration des Scalability-Servers und des
Installations-Managers können Sie mehrere individuelle Meldungen zusammen in einer
einzigen Datenbanktransaktion erfassen, übertragen und übernehmen. Diese Fähigkeit,
eine große Transaktion anstatt mehrerer individuellen Transaktionen nacheinander
auszuführen, hilft Ihnen dabei, die Datenbankaktualisierungen zu optimieren.
Die Meldungen, die für die Optimierung berücksichtigt werden, sind die
Jobstatusmeldungen und die Softwaredatensätze. Die Jobstatusmeldungen enthalten
Meldungen zum Jobfortschritt und zur Jobbeendigung. Die Softwaredatensätze
enthalten die Software-Erkennungsdatensätze und die Software-Jobdatensätze.
Hinweis: Weitere Informationen zur Optimierung von Datenbankaktualisierungen
finden Sie im Abschnitt "Software Delivery" der DSM-Explorer-Hilfe.
Fahren Sie einen Computer nach dem letzten SD-Job herunter
Software Delivery ermöglicht Ihnen, einen Zielcomputer nach Abschluss des letzten
Software Delivery-Jobs herunterzufahren. Software Delivery bietet die entsprechenden
Optionen zum Herunterfahren und für den Kalender. Eine Kombination aus Job- und
Kalenderoptionen kontrolliert das Verhalten beim Herunterfahren des Zielcomputers.
Sie können diese Optionen verwenden, um zu bestimmen, ob und wann der Computer
heruntergefahren werden soll. Sie können außerdem nicht widersprüchliche
Zeitbereiche definieren, in denen heruntergefahren werden kann. Die Möglichkeit,
einen Computer nach Abschluss des letzten SD-Jobs herunterzufahren, hilft dabei,
sicherzustellen, dass der Energieverbrauch der Zielcomputer optimal ist und die Green
IT-Richtlinien der Organisation unterstützt werden.
Hinweis: Weitere Informationen zur Funktionsweise des Herunterfahrens eines
Computers, nachdem der letzte SD-Job abgeschlossen wurde, finden Sie im Abschnitt
"Software Delivery" der DSM-Explorer-Hilfe.
Verwenden der SD Agent Bridge
Die SD Agent Bridge-Funktion bietet Abwärtskompatibilität für erweiterte und LegacySD-Agenten auf Grundlage von Unicenter DSM r11.2 C1. Sie können Informationen
sammeln, die von mobilen Agenten abgerufen wurden, und anschließend Jobs, Module,
Vorlagen und Konfigurationen an diese Agenten verteilen.
SD Agent Bridge ist seit r11.2 C3 vollständig in CA ITCM integriert.
Hinweis: Die Agent Bridge wird nur unter Microsoft Windows unterstützt.
Hinweis: Die vom Agent Bridge in dieser Veröffentlichung unterstützten AgentPlattformen sind Windows Mobil 6.1 (ARM-basiert, einschließlich StrongARM, XScale),
Windows Mobile 6 (Classic, Standard, Professional) (ARM-basiert, einschließlich
StrongARM, XScale, TI OMAP), und Windows Mobile 5 (ARM-basiert, einschließlich
StrongARM, XScale).
Hauptkomponenten
SD Agent Bridge besteht aus folgenden Komponenten:
■
Allgemeine Legacy-Server-Komponente und deren Prozesskomponenten
Führt die Kommunikation für Agent Bridge, die Konfiguration und die
Agentenregistrierung aus.
■
Software Delivery-Komponenten
Bieten Serverunterstützung für erweiterte und Legacy-Agenten von Software
Delivery.
UUID Generator für Agent Bridge
Ein UUID-Generator ermöglicht es der Agent Bridge, eine Agenten-UUID für einen
Legacy-Agenten zu generieren, wenn keine UUID gemeldet wurde. Außerdem wurde
eine neue Konfigurationsrichtlinie zum Steuern des UUID-Generierungsverhaltens
hinzugefügt.
Hinweis: Sie sollten immer die neuesten Agenten für Ihre Betriebsumgebung
verwenden. Angaben zum Zertifizierungsstatus von Legacy-Agenten finden Sie in der
entsprechenden Kompatibilitätsmatrix auf der CA Support Online-Website unter
http://support.ca.com.
Einschränkungen bei der Verwendung der SD Agent Bridge
Da CA ITCM eine neue Generation von Asset Management, Software Delivery und
Remote Control-Funktionen darstellt, gibt es bestimmte neue Eigenschaften und
Funktionen, die in den vorherigen Versionen dieser Komponenten noch nicht vorhanden
waren und daher nicht mit Legacy-Agenten verwendet werden können. Die SD Agent
Bridge-Unterstützung umfasst nicht die folgenden CA ITCM-Funktionen:
■
Leistungsmodulextrahierung
■
Konfigurationsrichtlinien
Hinweis: Bei Legacy-Agenten wird der Strukturknoten "Konfigurationsrichtlinie"
unterdrückt und die Option "Jobprüfung aktivieren" ist deaktiviert.
■
Sofortdiagnose
■
DMDeploy-Funktionalität
Aufgrund der technologischen Änderungen in CA ITCM gibt es auch einige vorhandene
Unicenter Software Delivery 4.0-Funktionen, die auf Legacy-Agenten in CA ITCM bei
Verwendung von Agent Bridge nicht unterstützt werden. Dabei handelt es sich um die
folgenden Funktionen:
■
Docking-Geräte auf Basis der Unicenter Software Delivery 4.0-Legacy-Agenten
■
Softwarekatalog für Software Delivery-Legacy-Agenten
■
Automatische Installationen von Software Delivery-Legacy-Agenten
Bekannte Probleme bei der SD Agent Bridge
Zurzeit sind hinsichtlich der SD Agent Bridge folgende Probleme bekannt.
Aktive Jobprüfung
Die aktive Jobprüfung auf dem Unicenter Software Delivery-Legacy-Agenten schlägt in
der folgenden Situation möglicherweise fehl:
1.
Während der Paketbereitstellung ist die Option "Jobs werden vom Scalability-Server
ausgelöst" nicht ausgewählt.
2.
Sobald der Jobcontainer erstellt wurde und den Status "Aktiv" besitzt, wählen Sie
entweder im DSM-Explorer die Option für die aktive Jobprüfung aus oder Sie führen
auf dem Agentencomputer "sdacmd jobcheck" aus.
Dies führt dazu, dass der Job weiterhin den Status "Aktiv" besitzt.
Sie können dieses Problem umgehen, indem Sie "sdjexec.exe" auf einem Unicenter
Software Delivery 4.0-Agentencomputer oder "asminst" auf einem Unicenter Software
Delivery 3.x- oder 2.0-Agentencomputer ausführen. Als Status des Jobs wird dann im
DSM-Explorer "Erfolgreich" angezeigt.
Windows Mobile 5.0-Geräte
Wenn auf einem Windows Mobile 5.0-Gerät, das auf Agent Bridge verweist, zuerst ein
Unicenter Asset Management 4.0 SP1 C2-Agent installiert wird und danach ein
Unicenter Software Delivery 4.0 SP1 C3-Agent, ist die im DSM-Explorer angezeigte
Versionsnummer des Unicenter Asset Management-Agenten möglicherweise nicht
korrekt.
Wenn außerdem auf einem Windows Mobile 5.0-Gerät, das auf Agent Bridge verweist,
zuerst ein Unicenter Software Delivery 4.0 SP1 C3-Agent installiert wird und danach ein
Unicenter Asset Management 4.0 SP1 C2-Agent, wird möglicherweise der Unicenter
Asset Management 4.0 SP1 C2-Agent nicht gemeldet.
Agentenregistrierung
Die Registrierung des CA ITCM-Agenten bei der MDB erfolgt durch die Angabe der
folgenden Informationen:
■
Hostname
■
Universelle eindeutige ID (UUID) des Hosts
■
ID der Betriebssystemklasse
■
IP-Adresse
■
MAC-Adresse
Mit Agent Bridge wird die Host-UUID durch den Legacy-Agenten angegeben und der
Legacy-Agent wird mit Hilfe von Agent Bridge beim CA ITCM-System registriert. Die von
CA ITCM und Agent Bridge verwendete Agentenregistrierungsmethode ordnet die
Legacy-Informationen den Informationen in CA ITCM zu. Zum Beispiel wird eine
Unicenter Software Delivery-Datei-ID mit 8 Byte einer CA ITCM-formatierten,
alphanumerischen Host-UUID mit 32 Byte zugeordnet. Die Host-UUID, die für einen
Legacy-Agenten generiert wird, wird in der Datei für die gemeinsame Verwendung
gespeichert.
Wenn ein Legacy-Agent keine eindeutige Host-UUID angibt und der UUID-Generator
nicht aktiviert ist, wird der Agent nicht von Agent Bridge registriert, und er wird als
ungültiger Agent behandelt.
Wenn der UUID-Generator aktiviert ist, sind dies die korrekten Verfahren zum
Registrieren der Unicenter Software Delivery-Legacy-Agenten:
So registrieren Sie Legacy-Agenten, von denen einige möglicherweise ihre UUIDs nicht
melden:
■
Wenn der Unicenter Asset Management- und der Unicenter Software DeliveryAgent keine Host-UUIDs melden, können Sie diese Agenten in beliebiger
Reihenfolge registrieren. Sie müssen jedoch zwischen der Registrierung der beiden
Agenten einen gewissen Zeitraum, in der Regel mindestens fünf (5) Minuten,
verstreichen lassen.
■
Wenn der Unicenter Asset Management-Agent keine Host-UUID meldet, der
Unicenter Software Delivery-Agent dies jedoch tut, sollten Sie immer den Unicenter
Software Delivery-Agenten zuerst registrieren. Registrieren Sie anschließend nach
fünf (5) Minuten Wartezeit den Unicenter Asset Management-Agenten.
■
Wenn der Unicenter Software Delivery-Agent keine Host-UUID meldet, der
Unicenter Asset Management-Agent dies jedoch tut, sollten Sie immer den
Unicenter Asset Management-Agenten zuerst registrieren. Registrieren Sie
anschließend nach fünf (5) Minuten Wartezeit den Unicenter Software DeliveryAgenten.
Im Allgemeinen melden die meisten Unicenter Asset Management 4.0-Agenten und
Unicenter Software Delivery 4.0-Agenten bei ihrer Registrierung auf dem Server HostUUIDs.
Die Registrierung aller Unicenter Software Delivery 2.0-, 3.x- und 4.0-Legacy-Agenten
wird durch die von CA ITCM und Agent Bridge verwendete
Agentenregistrierungsmethode unterstützt.
Besonderheiten bei der Agentenmigration
Beim Migrieren von Legacy-Agenten nach CA ITCM unter Verwendung der Agent Bridge
gibt es folgende Einschränkungen:
■
Nachdem ein migrierter Agent eine "Neuinstallation nach Absturz" (RAC) ausgeführt
hat, erstellt eine neue Migration desselben Agenten eine neue Einheit, statt den
vorhandenen Agenten zu aktualisieren.
■
Wenn es bereits einen migrierten Unicenter Software Delivery (SD) Legacy-Agenten
in Ihrer CA ITCM-Umgebung gibt, führt das Installieren eines Unicenter Asset
Management 4.0 Legacy-Agenten oder eines CA ITCM Asset Management-Agenten
dazu, dass der Status des migrierten Legacy-SD-Agenten überschrieben wird. Der
SD-Status wird von "Von Migration gesperrt" in "Nicht installiert" geändert.
Verwenden Sie diese Methode daher nicht zum Migrieren und Registrieren von
Daten von Legacy-Agenten. Verwenden Sie stattdessen das DSM-Migrations-Tool.
Voraussetzungen bei der Verwendung der SD Agent Bridge
Die SD Agent Bridge muss nicht notwendigerweise auf demselben Computer installiert
sein wie der Domänen-Manager. Allerdings muss sie auf demselben Computer wie der
Scalability-Server von Software Delivery installiert sein, was von der
Installationsprozedur automatisch vorgenommen wird.
Bei Unicenter Software Delivery 4.0 SP1-Agenten muss möglicherweise abhängig von
der Betriebsumgebung und der Sprache einer der folgenden Testkorrekturen oder
kumulativen Korrekturen aufgespielt werden,:
■
Englisch (ENU)
QO77129
Windows NT - USD 4.0 SP1C3 CD1
T18C930
4.0 SP1 Fix für Novell Netware (NW)
QO77130
Windows NT-4.0 SP1 C3 FIX für NT & NW
QO77876
4.0 SP1 C3 FIX für LINUX
QO77874
4.0 SP1 C3 FIX für HP-UX
QO77877
4.0 SP1 C3 FIX für SOLARIS
QO77869
4.0 SP1 C3 FIX für AIX
QO77878
4.0 SP1 C3 FIX für SOLARIS Intel
■
■
■
Deutsch (DEU)
QO81439
T1B1339
Windows CD1
QO81451
T1B1359 Windows CD2
QO81456
T1B1340 AIX
QO81457
T1B1341 HP-UX
QO81458
T1B1342 Sun Solaris
Französisch (FRA)
T1B1344
Windows CD1
T1B1360
Windows CD2
T1B1345
AIX
T1B1346
HP-UX
T1B1347
Sun Solaris
Japanisch (JPN)
QO83580
T1B1373
Diese Korrekturen erhalten Sie vom Technischen Support unter http://ca.com/support.
Unterstützte Betriebsumgebungen und SD-Agenten
Der CA ITCM-Datenträger schließt einen Agenten für Windows Mobile 5.0, 6.0, und 6.1
ein. Dieser Agent erfordert die Verwendung des Legacy-Agent-Bridge. Kein anderer
Agent wird von dem Legacy-Agent-Bridge unterstützt.
Hinweis: Sie sollten immer den neuesten Software Delivery-Agenten für Ihre
Betriebsumgebung verwenden. Die neueste Version finden Sie in der Software DeliveryKompatibilitätsmatrix auf der CA Support Online-Website http://support.ca.com.
SD Agent Bridge-Konfiguration
Wie alle anderen CA ITCM-Plugins ist SD Agent Bridge konfigurierbar.
Sie können daher die Richtliniengruppenordner im Unterknoten "Systemsteuerung,
Konfiguration, Konfigurationsrichtlinie, Standardcomputerrichtlinie, DSM, Software
Delivery, Scalability-Server" der DSM-Explorer-Baumstruktur zum Konfigurieren der SD
Agent Bridge verwenden.
Richtliniengruppe "Backwards Compatibility Support"
Mit der Richtliniengruppe "Backwards Compatibility Support" können Sie Agent BridgeUnterstützungsrichtlinien für erweiterte und Legacy-Unicenter-Software-DeliveryAgenten anzeigen und bearbeiten. Sie können Richtlinienparameterwerte ändern,
indem Sie auf eine Richtlinie doppelklicken, um das Dialogfeld "Eigenschaften von
Einstellung" anzuzeigen.
Diese Richtliniengruppe enthält den folgenden Richtliniengruppenordner:
Kommunikation
Die Richtliniengruppe "Backwards Compatibility Support" enthält außerdem folgende
Richtlinien:
Unterstützung für Abwärtskompatibilität: Aktivieren
Aktiviert bei "True" (Wahr) die Agent Bridge-Scalability-Server-Unterstützung für
Legacy-Unicenter-Software-Delivery-Agenten und Windows CE-Agenten. Bei "False"
(Falsch) deaktiviert diese Richtlinie die Server-Unterstützung für erweiterte und
Legacy-Unicenter-Software-Delivery-Agenten.
Hinweis: Die Aktivierung der AM Agent Bridge-Unterstützung bedeutet nicht, dass
die SD Agent Bridge-Unterstützung automatisch aktiviert wird. Weitere
Informationen finden Sie unter der Konfigurationsrichtlinie "Agent Bridge
aktivieren" der Richtliniengruppe "Asset Management".
Standard: False
Unterstützung für Abwärtskompatibilität: Verwenden der SDOUTPUT-Freigabe
Aktiviert die Unterstützung für eine neue beschreibbare Freigabe SDOUTPUT unter
SDLIBRARY$ auf dem Server, wenn der Wert "True" (Wahr) lautet. Bei "False"
(Falsch) deaktiviert diese Richtlinie die Unterstützung für die neue beschreibbare
Freigabe SDOUTPUT. Diese Serverrichtlinie muss auf "True" (Wahr) gesetzt werden,
wenn Legacy-Agenten vor Unicenter Software Delivery 4.0 mit dem Server
verbunden sind und die NOS-Verbindungsmethode für den Zugriff auf die Software
Delivery-Bibliothek verwenden. Diese Richtlinie ermöglicht es, dass
Jobausgabedateien direkt in die SDOUTPUT-Bibliotheksfreigabe geschrieben
werden.
Standard: False
Richtliniengruppe "Communication"
Die Richtliniengruppe "Communication" steuert die CA-SD-Kommunikationsprotokolle
für erweiterte und Legacy-Unicenter-Software-Delivery-Agenten.
Die Richtliniengruppe "Communication" enthält die folgenden Richtlinien:
Unterstützung für Abwärtskompatibilität: Agenten-Verbindungsport
Gibt den Port an, den der Server auf Verbindungsanforderungen von LegacyUnicenter-Software-Delivery-Agenten abhören soll.
Standard: 4721
Unterstützung für Abwärtskompatibilität: FileTransferBlockSize
Gibt die Größe der Blöcke für die Dateiübertragung in Kilobyte (KB) an. Wenn Sie
schnelle Netzwerke einsetzen, wird die Leistung durch die Erhöhung der Größe in
der Regel verbessert.
Beschränkungen: 4–32
Standard: 4
Unterstützung für Abwärtskompatibilität: Max. Verbindungen
Gibt die maximal zulässige Anzahl an Netzwerkverbindungen zu und von diesem
Computer an.
Standard: 550
Unterstützung für Abwärtskompatibilität: Max. Peers
Gibt die maximal zulässige Anzahl an Netzwerkanwendungs-Peers für diesen
Computer an.
Standard: 200
Unterstützung für Abwärtskompatibilität: SysRcvTimeout
Gibt das allgemeine Zeitlimitintervall für den Systemempfang in Sekunden an.
Hinweis: Wenn "-1" angegeben ist, ist das Zeitlimit unbegrenzt.
Standard: -1
Unterstützung für Abwärtskompatibilität: Trigger-Port
Gibt die Port-Nummer des Trigger-Prozesses (TRIGGER) an.
Standard: 4725
Unterstützung für Abwärtskompatibilität: WaitCCTimeout
Gibt das Warte-Zeitlimitintervall in Sekunden für Verbindungsbestätigungen an.
Standard: 120
Unterstützung für Abwärtskompatibilität: WaitCRTimeout
Gibt das Warte-Zeitlimitintervall in Sekunden für Verbindungsanforderungen an.
Standard: 120
Wake-on-LAN-Serverkonfiguration
Sie können die erweiterte Wake-on-LAN-Serverkonfiguration für die Legacy-Agenten
einrichten. Diese Konfigurationsrichtlinien werden lokal verwaltet und müssen auf den
Servern eingerichtet werden, indem "comstore" lokal geändert wird
Beispiel: Angeben der Remote-Subnetzmaske und Senden von Wake-on-LANBroadcasts
[itrm/usd/SUBNETMASKS]
;
Dieser Abschnitt ist mit dem nachfolgenden Abschnitt verwandt.
[itrm/usd/CUSTOMBROADCAST]
;
In diesem Abschnitt wird die TCP/IP-Subnetzmaske definiert, die beim Senden
;
der Wake-on-LAN-Broadcasts verwendet wird. Standardmäßig werden Broadcasts
auf dem
;
Netzwerk gesendet, auf dem sich der Computer befindet. Für das lokale
Netzwerk wird das Subnetz
;
automatisch von der Konfiguration des Computers abgerufen.
;
Wenn ein Remote-Netzwerk Subnetze verwendet, müssen Sie
;
hier deren Subnetzmaske angeben.
;
;
Beispiel:
;
100.0.0.0
= 255.255.255.0
Dies geschieht beispielsweise dadurch, dass auf dem Server der folgende Befehl
ausgeführt wird:
ccnfcmda -cmd SetParameterValue -ps itrm/usd/SUBNETMASKS -pn 100.0.0.0 -v
255.255.255.0
Führen Sie Folgendes aus, um diese Einstellung zu entfernen:
ccnfcmda -cmd DeleteParameter -ps itrm/usd/SUBNETMASKS -pn 100.0.0.0
[itrm/usd/CUSTOMBROADCAST]
;
Dieser Abschnitt ist mit dem obigen Abschnitt ([itrm/usd/SUBNETMASKS])
verwandt und
;
enthält drei Parameter: DisableBroadcast, NoBroadcast und
;
CustomBroadcast.
DisableBroadcast=
;
Wenn DisableBroadcast=1, sind Wake-on-LAN-Broadcasts deaktiviert.
;
Wenn DisableBroadcast=0, sind Wake-on-LAN-Broadcasts aktiviert.
Beispiel:
ccnfcmda -cmd SetParameterValue -ps itrm/usd/CUSTOMBROADCAST
DisableBroadcast -v 1
-pn
NoBroadcast=
;
Wenn NoBroadcast=1, wird ein direktes Broadcast an eine bestimmte IP-Adresse
gesendet
;
(vor der Auslösermeldung). In diesem Fall ist Broadcast nicht zulässig.
;
Wenn NoBroadcast=0, wird ein direktes Wake-on-LAN-Broadcast an eine bestimmte
;
IP-Adresse deaktiviert.
CustomBroadcast=
;
Wenn CustomBroadcast =0, werden Wake-on-LAN-Broadcasts an nicht
;
standardmäßige Subnetze deaktiviert. Anschließend wird ein Standard-Broadcast
mit Hilfe des
;
[SUBNETMASKS]-Eintrags vorgenommen.
;
Wenn CustomBroadcast =1, wird ein Wake-on-LAN-Broadcast an
;
Nicht-Standard-Subnetze (benutzerdefinierte Subnetze) gesendet.
;
Beispiel:
;
Wenn Sie über ein Subnetz mit Subnetzmaske 255.255.255.224 (32 Adressen
;
in diesem Subnetz) verfügen, sind 31,63,95... Werte, die den BroadcastAdressen
;
xxx.xxx.xxx.31, xxx.xxx.xxx.63, xxx.xxx.xxx.95, ... entsprechen.
;
Hängen Sie diese Liste an das Ende an.
;
“ccnfcmda -cmd SetParameterValue -ps itrm/usd/CUSTOMBROADCAST
v 0”
“ccnfcmda -cmd SetParameterValue -ps itrm/usd/CUSTOMBROADCAST
CustomBroadcast –v 1”
-pn
NoBroadcast –
-pn
“ccnfcmda -cmd SetParameterValue -ps itrm/usd/CUSTOMBROADCAST -pn xxx.xxx.xxx.0
–v 31,63,95,127,159,191,223,255”
;
;
Wenn Software Delivery einen Job an die IP-Adresse xxx.xxx.xxx.69 sendet,
sollte ein
;
Wake-on-LAN-Broadcast xxx.xxx.xxx.95 gesendet werden.
Hinzufügen von Legacy-Software zur Softwarepaketbibliothek
Die folgenden Möglichkeiten stehen zum Hinzufügen von Unicenter Software Delivery
Legacy-Software zur Softwarepaketbibliothek zur Verfügung :
■
Exportieren von einem lokalen Legacy-Server
■
Importieren von einer Original-Legacy-CD-ROM
Die folgenden Szenarios zeigen die Möglichkeiten zum Hinzufügen von Unicenter
Software Delivery Legacy-Software zur Softwarepaketbibliothek auf.
Szenario 1 – Exportieren von Legacy-Agent-Software von einem lokalen Unicenter
Software Delivery 4.0-Server:
1.
Navigieren Sie auf einem lokalen Unicenter Software Delivery 4.0-Server zur
Software Delivery (Softwarebibliotheksknoten), und suchen Sie die Legacy-AgentSoftware, die Sie hinzufügen möchten.
2.
Klicken Sie mit der rechten Maustaste auf das Software-Paket, und klicken Sie
anschließend auf "Exportieren, Software-Paket".
Das Dialogfeld "Software-Paket exportieren" wird angezeigt.
3.
Geben Sie den Verzeichnispfad und -namen ein, unter dem Sie das Software-Paket
speichern möchten.
Geben Sie den Pfad ein, in den das Softwarepaket kopiert werden soll, oder klicken
Sie auf "Durchsuchen", um den Pfad im Explorer auszuwählen.
4.
Klicken Sie auf "OK".
5.
Klicken Sie im DSM-Explorer mit der rechten Maustaste auf den Knoten "DSMSoftware-Pakete", und klicken Sie anschließend auf "Importieren", "SoftwarePaket".
Das Dialogfeld zum Importieren von Software-Paketen wird angezeigt.
6.
Wählen Sie das Software-Paket für den Legacy-Agenten aus dem in Schritt 3
angegebenen Verzeichnis aus, und klicken Sie auf "OK".
Die Legacy-Agent-Software wird zur Softwarepaketbibliothek hinzugefügt.
Szenario 2 – Importieren von Legacy-Software von einer Original-CD-ROM von
Unicenter Software Delivery:
1.
Legen Sie die Unicenter Software Delivery-CD ein.
2.
Klicken Sie im DSM-Explorer mit der rechten Maustaste auf den Knoten "DSMSoftware-Pakete", und klicken Sie anschließend auf "Importieren", "SoftwarePaket".
Das Dialogfeld zum Importieren von Software-Paketen wird angezeigt.
Installieren von Wrapper-Paketen von externen Repositorys
3.
Wählen Sie das Software-Paket für den Legacy-Agenten aus.
4.
Klicken Sie auf "OK".
Die Legacy-Agent-Software wird zur Softwarepaketbibliothek hinzugefügt.
Hinweis: Beim Importieren der Software erhalten Sie möglicherweise eine
Meldung, die der Folgenden ähnelt: "Die Software, die Sie registrieren, ist bereits in
einem gefundenen Paket vorhanden. Möchten Sie sie durch die echte Software
ersetzen?” Klicken Sie auf "Ja". (Dies ist der Fall, wenn ein Agent, der diese AgentSoftware verwendet, bereits eine Verbindung zum DSM-System hergestellt und sich
dort registriert hat.)
Fehlermeldungen zur Download-Methode in Zusammenhang mit der SD Agent
Bridge
In Zusammenhang mit der SD Agent Bridge-Funktion können bei Verwendung der
Download-Methode von Software Delivery folgende Fehlermeldungen auftreten:
■
SDM001043
Download-Methode kann auf einem Computer mit einem Legacy-Agenten nicht
festgelegt werden.
■
SDM001044
Ein oder mehrere Computer mit Legacy-Agenten gefunden. Download-Methode
kann auf diesen Computern nicht festgelegt werden.
Dieses Kapitel beschreibt die Installation von Wrapper-Paketen von externen
Repositorys mithilfe der Software Delivery-Funktionalität ausführlich.
Beispiel-DSM-Architektur mit externen Debian-Repositorys
Forward Inc ist eine Bankorganisation mittlerer Größe, die CA ITCM für die Verwaltung
der physischen und virtuellen Infrastruktur bereitgestellt hat. Der Hauptsitz von Forward
Inc befindet sich in New York und die Filialen befinden sich an anderen Standorten in
den USA und in Indien. In jedem Land gibt es ein Datencenter und mehrere Filialen.
Die aktuelle CA ITCM-Implementierung sieht wie folgt aus:
■
Der DSM-Enterprise-Manager befindet sich im Hauptsitz.
■
EIN DSM-Domain Manager befindet sich im Datencenter eines jeden Landes.
■
Ein Scalability-Server befindet sich in Großstädten für verschiedene Filialen im
Umkreis.
Forward Inc verfügt über ein paar Tausend Computer mit dem Betriebssystem Debian.
Das Unternehmen muss in der Lage sein, Debian-Softwarepakete über CA ITCM
bereitzustellen. Das Master-Debian-Repository befindet sich im Hauptsitz. Das
Unternehmen möchte Wrapper-Pakete erstellen und auf jedem Domain Manager
bereitstellen, um eine schnellere Bereitstellung zu ermöglichen. Vorgehensweise:
■
Das externe Debian-Repository wird als Master-Repository zum Enterprise-Manager
hinzugefügt.
■
In jedem Datencenter wird ein Spiegel des Master-Debian-Repositorys erstellt.
■
Die Spiegel in jedem Datencenter werden den jeweiligen Domain Managers als
Master-Repository zugeordnet, damit Wrapper-Pakete aus dem DatencenterSpiegel erstellt werden können. Wrapper-Pakete, die für die gesamte Organisation
gelten, werden im Enterprise-Manager erstellt und auf die Domain Manager
verteilt.
■
Spiegel für die Scalability-Server werden von dem Datencenter-Spiegel durch die
Konfiguration der jeweiligen Domain Manager erstellt.
Das folgende Architekturdiagramm veranschaulicht die DSM-Architektur mit den
Debian-Repositorys und -Spiegeln:
Bereitstellen von Paketen aus Debian-Repositorys
Der folgende Prozess beschreibt, wie CA ITCM zu konfigurieren ist, damit Pakete aus
Debian-Repositorys bereitgestellt werden:
1.
Hinzufügen der Details des externen Debian-Repositorys in CA ITCM (siehe
Seite 165)
2.
Einrichten von Spiegel-Repositorys (siehe Seite 179)
3.
Einrichten von HTTP- und FTP-Freigaben auf Repository-Servern
4.
Bereitstellen von Debian-Paketen mithilfe von Software Delivery (siehe Seite 172)
Konfigurieren externer Debian-Repositorys in CA ITCM
Als Desktop-Support-Analyst wurden Sie angewiesen, die Details des externen DebianRepositorys in CA ITCM zu konfigurieren. Mit dieser Konfiguration können Sie das
Repository von CA ITCM aus durchsuchen, Spiegelkopien des Repositorys erstellen und
Debian-Pakete mithilfe von Software Delivery bereitstellen. Im folgenden Diagramm
sind die Schritte veranschaulicht, die Sie durchführen müssen, um die Details des
externen Debian-Repositorys in CA ITCM zu konfigurieren:
Führen Sie die folgenden Tasks aus, um externe Debian-Repositorys in CA ITCM zu
konfigurieren:
1.
Definieren der Details des externen Debian-Repositorys in CA ITCM (siehe
Seite 167)
2.
Extrahieren von Paketmetadaten aus dem Repository (siehe Seite 169)
3.
Durchsuchen des Debian-Repositorys in der Webkonsole (siehe Seite 171)
Definieren der Details des externen Debian-Repositorys in CA ITCM
Definieren Sie die Details des externen Debian-Repositorys, mit dem CA ITCM eine
Verbindung herstellen muss. CA ITCM verwendet diese Informationen, um das
Repository zu durchsuchen, Spiegelkopien zu erstellen und Softwarepakete
bereitzustellen.
Gehen Sie wie folgt vor:
1.
Navigieren Sie zu "Systemsteuerung", "Konfiguration", "Konfigurationsrichtlinie".
2.
Klicken Sie mit der rechten Maustaste auf die standardmäßige
Konfigurationsrichtlinie, und wählen Sie "Versiegelung aufheben" aus.
Hinweis: Die geänderte Konfigurationsrichtlinie muss auf alle Zielcomputer
angewandt werden. Wählen Sie daher die standardmäßige Konfigurationsrichtlinie
aus.
Die Richtlinie kann bearbeitet werden.
3.
Navigieren Sie zu "DSM", "Software Delivery", "Freigegeben", "Externes
Repository", "Debian", und wählen Sie im rechten Bereich "Repositorys" aus.
4.
Geben Sie in der Tabelle "Repositorys" die folgenden Details für jedes Repository
an, das mit CA ITCM verbunden werden soll:
Repository-Name
Gibt einen eindeutigen Repository-Namen an. Sie können einen beliebigen
Namen angeben. Sie müssen jedoch sicherstellen, dass der Name in der
gesamten Tabelle "Repositorys" eindeutig ist.
Repository-Beziehung
Gibt an, ob es sich beim Repository um eine Master- oder Spiegelvorlage
handelt.
Master
Gibt an, dass das Repository ein Master ist. Ein Master-Repository wird bei
der Erstellung von Wrapper-Paketen verwendet. CA ITCM kann
systemeigene Debian-Pakete nicht direkt bereitstellen. Erstellen Sie
Wrapper-Pakete, die Verweise zu den systemeigenen Debian-Paketen
enthalten, und stellen Sie dann die Wrapper-Pakete bereit.
Folgende Richtlinien gelten für Master-Repositorys:
–
Fügen Sie mindestens ein Master-Repository hinzu, um Debian-WrapperPakete zu erstellen und bereitzustellen.
–
Sie können mehrere Master-Repositorys hinzufügen. Sie können WrapperPakete jedoch nur von dem ersten (alphabetisch) verfügbaren Master
erstellen.
–
Sie können unterschiedliche Master-Repositorys auf Enterprise-Managerund Domänen-Manager-Ebene konfigurieren. Ein Master-Repository kann
ein externes Debian-Repository oder ein anderes Spiegelkopie-Repository
sein, das als Master für das Erstellen von Wrapper-Paketen fungiert.
Beispielsweise können Sie über ein externes Debian-Repository verfügen,
das sich am selben Ort wie der Enterprise-Manager befindet. Sie haben
Spiegelkopien dieses Repositorys auf einem Linux-Computer erstellt, der
sich am selben Ort wie Ihre einzelnen Domänen-Manager befindet. Sie
können diese Spiegelkopien als Master für die entsprechenden DomänenManager konfigurieren, sodass Sie Wrapper-Pakete von den Spiegelkopien
erstellen können, die sich am selben Ort wie Ihre Domänen-Manager
befinden.
Spiegelung
Gibt an, dass das Repository eine Spiegelkopie ist, die von einem Master
oder einer anderen Spiegelkopie erstellt wird.
Spiegelvorlage
Gibt an, dass die Spiegelkopie nur eine Vorlage und kein physisches
Repository ist. Die Spiegelvorlage ist nur ein Platzhalter für mehrere
Spiegelkopie-Repositorys, die die gleiche Konfiguration aufweisen. Wenn
Sie über zahlreiche Spiegelkopien verfügen, können Sie eine
Spiegelkopievorlage für jedes übergeordnete Element erstellen, anstatt
dass Sie eine Reihe für alle Spiegelkopien erstellen. Spiegelvorlagen
werden für die Softwarebereitstellung und die Extraktion der RepositoryDaten, jedoch nicht für die Spiegelsynchronisierung verwendet. Der
Hostname der die Spiegelkopien hostenden Computer wird dynamisch zur
Laufzeit ersetzt.
Repository-Typ
Gibt den Repository-Typ an.
Repository-Methode
Gibt das Übertragungsprotokoll an, das verwendet wird, um die Pakete vom
Repository auf die Zielcomputer zu übertragen. Wählen Sie HTTP oder FTP in
Abhängigkeit der von Ihnen vorgenommenen Konfiguration aus. Weitere
Informationen über diese Konfiguration finden Sie unter "Einrichten von FTPund HTTP-Freigaben für Softwarepakete und BS-Images".
Hinweis: Wenn das Repository ein Master ist und Sie das Repository
durchsuchen und Wrapper-Pakete davon erstellen möchten, konfigurieren Sie
das Repository als eine FTP-Freigabe.
Hostname
Gibt den Hostnamen des Computers an, der das Repository hostet. Geben Sie
für Spiegelvorlagen-Repositorys den Hostnamen nicht an, da der Hostname
dynamisch zur Laufzeit angegeben wird. Auch wenn Sie ihn angeben, wird der
Hostname für Spiegelvorlagen ignoriert.
Stamm
Gibt den Stammknoten des Repositorys an.
5.
Wiederholen Sie Schritt 4, um weitere Repositorys hinzuzufügen.
6.
Speichern und versiegeln Sie die Richtlinie. Überprüfen Sie, ob die Richtlinie auf
allen Zielcomputern angewandt wird.
Die Repository-Informationen werden auf allen Zielcomputern aktualisiert.
Extrahieren von Paketmetadaten aus dem Repository
Beim Extrahieren der Paketmetadaten aus dem Repository können Sie die Details des
Debian-Pakets auf der DSM-Webkonsole anzeigen.
Hinweis: Folgende Schritte gelten für das Extrahieren von Paketmetadaten von Masterund Spiegel-Repositorys.
1.
Navigieren Sie zur Systemsteuerung, "Engines", "Alle Engines", "SystemEngine" im
DSM-Explorer.
Das Engine-Protokoll wird angezeigt.
2.
Klicken Sie mit der rechten Maustaste auf "SystemEngine", und wählen Sie "Neuen
Task hinzufügen" aus.
Der Assistent für neuen Task wird geöffnet.
3.
Folgen Sie den Anweisungen, und führen Sie die folgenden Schritte im Assistenten
aus:
a.
Wählen Sie den Tasktyp als "Extraktion der CA-Repository-Daten" aus, und
geben Sie einen Task-Namen bzw. eine -Beschreibung ein. Klicken Sie auf
"Weiter".
Hinweis: Stellen Sie sicher, dass Sie die System-Firewall deaktivieren, um den
Task erfolgreich auszuführen.
b.
Geben Sie die folgenden Informationen an:
Hinweis: Da sich der Repository-Server unter Linux befindet, muss bei den in
den folgenden Feldern "Verteilung" und "Komponentenname" bereitgestellten
Werten die Groß-/Kleinschreibung beachtet werden. Sie müssten mit der Groß/Kleinschreibung im Repository-Server übereinstimmen. Wenn beispielsweise
der Repository-Server-Speicherort
"ftp://172.16.0.12/ubuntu/dists/lucid/main/binary-i386/" lautet, muss der
Verteilungsname als "lucid" angegeben werden und nicht als "Lucid" oder
"LUCID".
Repository-Name
Gibt den Repository-Namen an, von dem aus Sie die Paketmetadaten
extrahieren möchten. Die Liste zeigt die von Ihnen in der RepositorysKonfigurationstabelle definierten Repositorys an.
Hinweis: Sie können nicht zwei Engine-Tasks mit der gleichen Repositoryund Verteilungskombination erstellen.
Hostname
Gibt den Hostnamen des Repositorys an. Dieses Feld ist nur für Repositorys
vom Typ "Spiegelvorlage" aktiviert. Bei Master- und Spiegel-Repositorys
wird der Hostname automatisch aus der Repositorys-Konfigurationstabelle
übernommen.
Distribution
Gibt die Verteilung an, von der aus Sie die Paketdetails extrahieren
möchten.
Hinweis: Ein Engine-Task kann Daten nur von einer einzelnen Verteilung
extrahieren. Wenn Sie Daten aus mehreren Verteilungen extrahieren
möchten, müssen Sie zusätzliche Engine-Tasks erstellen.
Komponentenname
Gibt die Komponenten an, die Sie extrahieren möchten. Klicken Sie auf
"Hinzufügen", um mehr Komponenten hinzuzufügen.
c.
4.
Gibt Planungsoptionen an.
Klicken Sie auf der letzten Seite auf "Fertig stellen".
Die SystemEngine erstellt den Task und führt ihn zu einer geplanten Zeit aus. Sie
können den Task überwachen, indem Sie auf "SystemEngine" klicken und den
Status im Bereich "Task-Liste" auf der rechten Seite überprüfen.
Hinweis: Sie können das Repository auch in der Webkonsole durchsuchen, während
der Engine-Task noch in Bearbeitung ist. Die Webkonsole zeigt die Verteilungen und
Pakete während und nach der Extrahierung aus dem Repository an.
Durchsuchen des Debian-Repositorys in der Webkonsole
Sie können die Inhalte eines Debian-Repositorys in der Webkonsole durchsuchen, um zu
erfahren, welche Pakete im Repository vorhanden sind.
1.
Melden Sie sich an der DSM-Webkonsole an.
2.
Navigieren Sie zu "Konsole", "Software", "Externe Repositorys", Repository.
Es wird eine Liste der Verteilungen im ausgewählten Repository angezeigt. Die
Spalte "Synchronisierungsstatus" zeigt den Status des Repository-Extraktions-Tasks
an. Sie können auch auf "Anzeigen" unter der Spalte "Synchronisierungsprotokoll"
klicken, um den Fortschritt der Metadatenextrahierung und die ggf. auftretenden
Fehler anzuzeigen.
Hinweis: Wenn Sie das Repository öffnen, bevor der Extraktions-Task
abgeschlossen ist, ist es möglich, dass nicht alle Verteilungen in der Liste angezeigt
werden.
3.
Klicken Sie auf eine Verteilung.
Eine Liste von Debian-Paketen wird in der Verteilung angezeigt.
Bereitstellen von Debian-Paketen mithilfe von Software Delivery
Als Desktop-Support-Analyst können Sie Debian-Softwarepakete auf KubuntuZielcomputern mithilfe von Software Delivery bereitstellen. Mithilfe der
Softwarebereitstellung durch Software Delivery können Sie Softwarepakete an beliebige
verwaltete Debian-Computer senden und sie bereitstellen. Die systemeigenen DebianPakete werden in CA ITCM nicht physisch gespeichert. Sie werden in den DebianMaster- und Spiegel-Repositorys gespeichert. Daher unterscheidet sich die
Bereitstellung von Debian-Paketen von normalen SD-Paketen. Im folgenden Diagramm
sind die Schritte veranschaulicht, die Sie durchführen, um Debian-Pakete mithilfe von
Software Delivery bereitzustellen:
Führen Sie die folgenden Tasks aus, um Debian-Pakete mithilfe von Software Delivery
bereitzustellen:
1.
Verwalten von "Sources.List" über CA ITCM (siehe Seite 173)
2.
Erstellen eines Debian-Wrapper-Pakets (siehe Seite 175)
3.
Bereitstellen eines Debian-Wrapper-Pakets (siehe Seite 176)
4.
Überprüfen der Bereitstellung (siehe Seite 178)
Verwalten von "Sources.List" über CA ITCM
Die Debian-Computer verwalten eine Datei mit dem Namen "sources.list". Diese enthält
die Details der Repositorys, Bereitstellungen und Komponenten, von wo aus die Pakete
abgerufen werden können. Um Debian-Pakete durch Software Delivery bereitzustellen,
müssen Sie "sources.list" über CA ITCM verwalten.
1.
Navigieren Sie zu "Systemsteuerung", "Konfiguration", "Konfigurationsrichtlinie"
Richtlinienname, "DSM", "Software Delivery", "Freigegeben", "Externe Repositorys",
"Debian", und doppelklicken Sie im rechten Bereich auf "Quellen".
Hinweis: Diese Änderung der Konfigurationsrichtlinie muss auf Computer oder
Computergruppen angewandt werden, die ein bestimmtes Quell-Repository
verwenden. Zum Beispiel haben Sie ein Master-Repository und fünf SpiegelkopieRepositorys. Die Spiegelkopie-Repositorys befinden sich für schnellere Downloads
in verschiedenen Büros. Sie möchten die Computer in diesen Büros mit diesen
Spiegelkopien an den entsprechenden Standorten verbinden. In diesem Fall
erstellen Sie fünf Konfigurationsrichtlinien. Anschließend öffnen Sie jede einzelne
und konfigurieren die Quellentabelle mit den Spiegelkopie-Repository-Details für
diesen Standort und wenden die Richtlinie auf alle Computer an diesem Standort
an.
2.
Geben Sie die folgenden Details in der Quellentabelle an:
Hinweis: Wenn die Richtlinie auf Zielcomputer angewendet wird, die mindestens
über eine Zeile in der Tabelle "sources.list" verfügen, wird die ursprüngliche
"sources.list" durch CA ITCM in "sources.list.original.CADSM" umbenannt. Es wird
anschließend eine "sources.list"-Datei erstellt, und die Informationen aus der
Tabelle "Quellen" werden hinzugefügt.
Repository-Name
Gibt den Repository-Namen an. Der Wert in diesem Feld muss mit dem
Repository-Namen in der Tabelle "Repositorys" übereinstimmen, andernfalls
kann die Softwarebereitstellung fehlschlagen. Geben Sie nur die Details der
Repositorys an, zu denen die Zielcomputer eine Verbindung herstellen müssen.
Repository-Zuweisung
Gibt an, wie der Hostname für das Repository zugewiesen wird.
Statisch
Gibt an, dass der in der Repository-Tabelle angegebene Hostname
verwendet werden muss. Diese Option ist nur auf Master- und
Spiegelkopie-Repositorys und nicht auf Spiegelvorlagen anwendbar.
Dynamisch
Gibt an, dass der Hostname des Repositorys in der Konfigurationsrichtlinie
"Dynamischer Repository-Host" in der Systemsteuerung unter
"Konfiguration", "Konfigurationsrichtlinie", "Richtlinienname", "DSM",
"Software Delivery", "Freigegeben", "Externe Repositorys", "Debian"
bereitgestellt wird. Diese Option ist nur auf Spiegelvorlagen anwendbar.
Hinweis: Die dynamische Zuweisung ist hilfreich, wenn der Zielcomputer
wechselt oder bewegt wird. In diesem Fall ändern sich Hostname und URI,
aber die Bereitstellung ändert sich nicht. Die Verwaltung der zugewiesenen
Bereitstellungen ist von den physischen Standorten der Spiegelkopien
getrennt.
Scalability-Server
Gibt an, dass der Hostname des Repositorys der Scalability-Server ist. Der
Hostnamenswert in der Datei "sources.list" wird dynamisch auf Grundlage
des Scalability-Servers des Zielcomputers aktualisiert. Diese Option ist nur
auf Spiegelvorlagen anwendbar.
Distribution
Gibt die Bereitstellung an, die die Pakete enthält, die Sie bereitstellen möchten.
Komponenten
Gibt die Komponenten an, die die Pakete enthalten, die Sie bereitstellen
möchten.
Hinweis: Sie können mehrere Komponenten angeben; trennen Sie die
Komponenten mit einem Leerzeichen ab.
Repository-Format
Gibt das Format des Debian-Pakets im Repository an.
Binärdatei
Gibt an, dass die Pakete ein binäres Format aufweisen. Dieses Format ist
das Äquivalent zu "deb" in "sources.list", also ".deb <URI>
<DISTRIBUTIONS> <COMPONENTS>".
3.
(Optional) Fügen Sie zusätzliche Repositorys hinzu, wenn die Zielcomputer über
mehr als ein Quell-Repository verfügen, mit dem sie sich verbinden.
4.
(Nur für die dynamisch Repository-Zuweisung) Wechseln Sie zurück zu "External
Debian Repository", "Debian", und doppelklicken Sie auf "Dynamischer RepositoryHost". Geben Sie den Repository-Hostnamen an.
Hinweis: Sie können diesen Parameter auch in der standardmäßigen
Konfigurationsrichtlinie der Domänen-Manager definieren. Diese Aktion ist
hilfreich, wenn der Zielcomputer von einem Manager zu einem anderen verschoben
wird. Das Ziel kann automatisch eine Verbindung zum für den neuen Manager
konfigurierten standardmäßigen Repository-Hostnamen herstellen, und zwar ohne
zusätzliche Konfiguration.
5.
Speichern und versiegeln Sie die Richtlinie. Wenden Sie die Richtlinie auf die
Zielcomputer an, auf die sich die Konfiguration bezieht.
Die Konfigurationsrichtlinie wird über einen Push-Vorgang auf die Zielcomputer
angewendet.
6.
Navigieren Sie zu "Alle Computer", Computername, "Konfiguration",
"Konfigurationsrichtlinie", und stellen Sie sicher, dass die Richtlinie angewendet und
aktiviert wurde.
7.
(Optional) Melden Sie sich an einem Zielcomputer an, und stellen Sie sicher, dass
die Datei "sources.list" die von Ihnen konfigurierten Quellen enthält.
Die Repository-Details werden der Datei "sources.list" hinzugefügt.
Erstellen eines Debian-Wrapper-Pakets
Ein Debian-Wrapper-Paket enthält Verweise zu systemeigenen DebianSoftwarepaketen, die in einem externen Debian-Repository gespeichert sind. Sie können
ein systemeigenes Debian-Softwarepaket nicht direkt mithilfe von CA ITCM
bereitstellen, Sie benötigen dafür Wrapper-Pakete.
Hinweis: Obwohl Sie der Tabelle "Repositorys" mehrere Master- und SpiegelkopieRepositorys hinzufügen können, können Sie Wrapper-Pakete nur vom ersten
(alphabetisch) verfügbaren Master-Repository erstellen, dessen Paket-Metadaten
extrahiert worden sind. Weitere Informationen finden Sie unter "Extrahieren von
Paketmetadaten aus dem Repository".
Sie können ein Debian-Wrapper-Paket mithilfe einer der folgenden Möglichkeiten
erstellen:
■
Erstellen Sie ein Debian-Wrapper-Paket.
■
Erstellen Sie ein Debian-Wrapper-Paket anhand eines vorhandenen WrapperPakets. Das neue Wrapper-Paket enthält Verweise zu Debian-Paketen und
"debconf"-Parametern aus dem Quell-Wrapper-Paket.
1.
2.
Navigieren Sie zu "Software", "Pakete", und klicken auf die Softwarepaketgruppe,
unter der Sie das Wrapper-Paket erstellen möchten.
Eine Liste von Paketen in der Gruppe wird angezeigt.
3.
Klicken Sie im Bereich "Aktionen" auf "Neues 'Debian Wrapper'-Paket".
Hinweis: Wenn Sie ein Wrapper-Paket anhand eines vorhandenen Wrapper-Pakets
erstellen möchten, klicken Sie im Bereich "Aktionen" auf "Neu basierend auf".
Der Assistent "Neues 'Debian Wrapper'-Paket" wird geöffnet.
4.
Folgen Sie den Anweisungen des Assistenten, um die Vorinstallationsaktionen
anzugeben, beziehen Sie Debian-Pakete mit ein, konfigurieren Sie "Debconfig"Parameter, und geben Sie Nachinstallationsaufgaben an.
5.
Das neue Debian-Wrapper-Paket wird der Liste der registrierten Softwarepakete
hinzugefügt.
Hinweis: Wenn Sie das Wrapper-Paket bearbeiten möchten, heben Sie zunächst dessen
Versiegelung auf, und klicken Sie dann im Bereich "Aktionen" auf "Bearbeiten".
Bereitstellen eines Debian-Wrapper-Pakets
Bei der Bereitstellung eines Debian-Wrapper-Pakets auf Zielcomputern wird ein
Softwarejob an den Agent gesendet. Der Job installiert dann zur geplanten Zeit die
Software auf den Zielcomputern.
Stellen Sie sicher, dass die folgenden Voraussetzungen gegeben sind, bevor Sie mit der
Bereitstellung beginnen:
■
Stellen Sie sicher, dass HTTP- oder FTP-Zugriff auf den das Repository hostenden
Computern konfiguriert ist. Weitere Informationen über das Konfigurieren des
Zugriffs finden Sie unter "Einrichten von FTP- und HTTP-Freigaben für
Softwarepakete und BS-Images".
■
Stellen Sie sicher, dass Sie diesen Patch auf dem Zielcomputer angewandt haben
Befolgen Sie diese Schritte, um ein Paket über die Webkonsole bereitzustellen:
1.
Öffnen Sie die Webkonsole, und navigieren Sie zu "Express-Aktion".
2.
Klicken Sie auf "Software installieren".
3.
Folgen Sie den Anweisungen des Assistenten, und klicken Sie auf der letzten Seite
auf "Fertig stellen".
Befolgen Sie diese Schritte, um ein Paket über den DSM-Explorer bereitzustellen:
1.
Öffnen Sie "DSM-Explorer", und navigieren Sie zu "Computer und Benutzer", "Alle
Computer", und suchen Sie nach dem Zielcomputer, auf dem Sie das Paket
2.
Klicken Sie mit der rechten Maustaste auf den Zielcomputer, und wählen Sie
"Software-Jobs", "Softwarepakete bereitstellen" aus.
Der Assistent zum Bereitstellen von Softwarepaketen wird angezeigt.
3.
Folgen Sie den Anweisungen des Assistenten, und klicken Sie auf der letzten Seite
auf "Fertig stellen".
Der Softwarejob wird an die ausgewählten Computer gesendet. Die Jobs laden zu einer
geplanten Uhrzeit die Debian-Pakete aus dem in "source.list" auf dem Zielcomputer
definierten Debian-Repository herunter und führen das Installationsprogramm aus.
Hinweise zur Debian-Softwarebereitstellung
Wenn Sie eine Version eines Wrapper-Pakets erstmals auf einem Zielcomputer
installieren und Sie zu einem späteren Zeitpunkt eine andere Version des gleichen
Wrapper-Pakets auf demselben Computer installieren, wird die erste Version
deinstalliert, und alle Pakete in der zweiten Version werden installiert.
Wenn ein systemeigenes Debian-Paket Bestandteil von mehr als einem DebianWrapper-Paket ist und Sie solche Debian-Wrapper-Pakete auf demselben Zielcomputer
bereitstellen, wird das Debian-Paket in beiden Bereitstellungsjob installiert oder
aktualisiert. Während des Deinstallationsvorgangs von einem der Debian-WrapperPakete werden die zu deinstallierenden Debian-Pakete überprüft. Wenn auf sie in einem
anderen Debian-Wrapper-Paket verwiesen wird, wird der Deinstallationsvorgang
abgeschlossen, ohne dass das freigegebene Debian-Paket deinstalliert wird.
Anzeigen der Konfiguration der Paket-Ressourcenliste
Sie können die Konfiguration von "sources.list" im folgenden Inventarspeicherort
anzeigen:
1.
Navigieren Sie zu "Computers and Users" (Computer und Benutzer), "Alle
Computer", Debian-Computer, "Inventar", "Systemstatus", "Paket-Ressourcenliste".
Die Konfiguration der Paket-Ressourcenliste wird angezeigt.
Überprüfen der Bereitstellung
Überprüfen Sie die Bereitstellung, um sicherzustellen, dass das Wrapper-Paket
erfolgreich auf dem Zielcomputer bereitgestellt wird.
Hinweis: Das Debian-Softwareinstallationsprogramm gibt CA ITCM keine Meldung über
einen erfolgreichen Vorgang bzw. Fehler zurück. Der Status des SD-Jobs spiegelt nur den
Status der Wrapper-Paketbereitstellung wider und nicht das tatsächliche DebianSoftwarepaket.
1.
Öffnen Sie "DSM-Explorer", und navigieren Sie zu "Computer und Benutzer", "Alle
Computer", und suchen Sie nach dem Zielcomputer, auf dem Sie das Paket
bereitgestellt haben.
2.
Klicken Sie mit der rechten Maustaste auf den Computer, und wählen Sie "Jobs",
"Software-Jobs" aus.
Der Status des Jobs wird angezeigt.
3.
Doppelklicken Sie auf den entsprechenden Job, wenn der Status in "SW installiert"
geändert wird, und klicken Sie auf die Registerkarte "Jobausgabe".
Sowohl die Jobausgabe als auch die Erfolgsmeldung oder Fehlermeldung werden
angezeigt.
Einrichten von Debian-Spiegel-Repositorys
Als Desktop-Support-Analyst können Sie Debian-Spiegel-Repositorys einrichten, um den
einfachen Zugriff und das schnellere Herunterladen von Paketen auf dem Zielcomputer
sicherzustellen. Im folgenden Diagramm sind die Schritte veranschaulicht, die Sie
durchführen müssen, um Debian-Spiegel-Repositorys einzurichten:
Führen Sie die folgenden Tasks aus, um Debian-Spiegel-Repositorys einzurichten:
1.
Überprüfen der Voraussetzungen (siehe Seite 180)
2.
Installieren des Add-ons des CA-DSM-Agents für Debian-Spiegel (siehe Seite 180)
3.
Definieren der Details des übergeordneten Repositorys (siehe Seite 181)
4.
Definieren der Spiegelsynchronisierung-Details (siehe Seite 184)
5.
Planen der Spiegelsynchronisierung (siehe Seite 185)
6.
Überprüfen der Spiegelsynchronisierung (siehe Seite 186)
Überprüfen der Voraussetzungen
Überprüfen Sie die folgenden Voraussetzungen, um sicherzustellen, dass die
Spiegelkopie und die Synchronisierung richtig funktionieren:
■
Geben Sie die Computer an, auf denen Sie das Spiegelkopie-Repository erstellen
möchten.
Hinweis: Nur Linux-Varianten werden für Spiegelkopien unterstützt. Sie können das
Spiegelkopie-Repository beispielsweise auf einem Linux-Scalability-Server hosten.
■
Installieren Sie DSM-Agents auf den angegebenen Computern.
■
Installieren Sie das "debmirror"-Hilfsprogramm auf den angegebenen Computern.
Weitere Informationen über das Installieren von "debmirror" finden Sie im Thema
zur Installation des "debmirror"-Hilfsprogramms.
■
Erweitern Sie den Speicherort und das Verzeichnis, auf dem Sie das SpiegelkopieRepository als HTTP- und FTP-Freigaben erstellen möchten. Weitere Informationen
über das Einrichten von HTTP- und FTP-Freigaben auf der Spiegelkopie finden Sie
unter "Einrichten von FTP- und HTTP-Freigaben für Softwarepakete und BS-Images".
Installieren des Add-ons des CA-DSM-Agents für Debian-Spiegel
Installieren Sie das Add-on-Paket auf Computern, die das Spiegelkopie-Repository
hosten. Das Add-on aktiviert den Computer für die Spiegelsynchronisierung.
Wichtig! Bei der Spiegelsynchronisierung treten Fehler auf, wenn Sie das Add-on-Paket
nicht installieren.
1.
Navigieren Sie im DSM-Explorer zu "Software", "Softwarepaketbibliothek", "DSMSoftwarepakete".
2.
Klicken Sie mit der rechten Maustaste auf das Add-on des CA-DSM-Agents für
Debian Mirror 1.0, und wählen Sie "Bereitstellen" aus.
3.
Befolgen Sie die Anleitungen des Assistenten. Geben Sie die folgenden
Informationen im Assistenten an:
■
4.
Wählen Sie die Computer aus, auf denen Sie planen, das SpiegelkopieRepository zu hosten.
Für jeden von Ihnen ausgewählten Computer wird ein Softwarejob erstellt.
5.
Überwachen Sie den Jobstatus in "Alle Computer", Computername, "Jobs",
"Software-Jobs".
Wenn der Job abgeschlossen ist, wird der Jobstatus in "SW installiert" geändert.
Definieren der Details des übergeordneten Repositorys
Definieren Sie die Details des übergeordneten Repository für die Spiegelkopie. Ein
übergeordnetes Repository kann ein Master-Repository oder ein SpiegelkopieRepository sein, da Sie eine Spiegelkopie von einem Master-Repository oder von einem
anderen Spiegelkopie-Repository erstellen können. Sie können mehrere Spiegelkopien
eines übergeordneten Repositorys in Abhängigkeit des Netzwerkverkehrs, der
Auslastung und der zu unterstützenden Standorte definieren. Wenn Sie beispielsweise
beschließen, über zwei Spiegelkopien an jedem Standort zu verfügen und Sie fünf
unterschiedliche Bürostandorte besitzen, benötigen Sie zehn Spiegelkopien des
übergeordneten Repositorys.
Hinweis: Die Schritte gleichen dem Definieren des externen Repositorys, jedoch mit der
Ausnahme, dass Sie bestimmen müssen, ob das übergeordnete Repository Master oder
Spiegelkopie ist.
1.
Navigieren Sie zu "Systemsteuerung", "Konfiguration", "Konfigurationsrichtlinie".
2.
Klicken Sie mit der rechten Maustaste auf die standardmäßige
Konfigurationsrichtlinie, und wählen Sie "Versiegelung aufheben" aus.
Hinweis: Die geänderte Konfigurationsrichtlinie muss auf alle Zielcomputer
angewandt werden. Wählen Sie daher die standardmäßige Konfigurationsrichtlinie
aus.
Die Richtlinie kann bearbeitet werden.
3.
Repository", "Debian", und wählen Sie im rechten Bereich "Repositorys" aus.
4.
Geben Sie in der Tabelle "Repositorys" die folgenden Details für jedes Repository
an, das mit CA ITCM verbunden werden soll:
Repository-Name
Gibt einen eindeutigen Repository-Namen an. Sie können einen beliebigen
Namen angeben. Sie müssen jedoch sicherstellen, dass der Name in der
gesamten Tabelle "Repositorys" eindeutig ist.
Repository-Beziehung
Gibt an, ob es sich beim Repository um eine Master- oder Spiegelvorlage
handelt.
Master
Gibt an, dass das Repository ein Master ist. Ein Master-Repository wird bei
der Erstellung von Wrapper-Paketen verwendet. CA ITCM kann
systemeigene Debian-Pakete nicht direkt bereitstellen. Erstellen Sie
Wrapper-Pakete, die Verweise zu den systemeigenen Debian-Paketen
enthalten, und stellen Sie dann die Wrapper-Pakete bereit.
Folgende Richtlinien gelten für Master-Repositorys:
–
Fügen Sie mindestens ein Master-Repository hinzu, um Debian-WrapperPakete zu erstellen und bereitzustellen.
–
Sie können mehrere Master-Repositorys hinzufügen. Sie können WrapperPakete jedoch nur von dem ersten (alphabetisch) verfügbaren Master
erstellen.
–
Sie können unterschiedliche Master-Repositorys auf Enterprise-Managerund Domänen-Manager-Ebene konfigurieren. Ein Master-Repository kann
ein externes Debian-Repository oder ein anderes Spiegelkopie-Repository
sein, das als Master für das Erstellen von Wrapper-Paketen fungiert.
Beispielsweise können Sie über ein externes Debian-Repository verfügen,
das sich am selben Ort wie der Enterprise-Manager befindet. Sie haben
Spiegelkopien dieses Repositorys auf einem Linux-Computer erstellt, der
sich am selben Ort wie Ihre einzelnen Domänen-Manager befindet. Sie
können diese Spiegelkopien als Master für die entsprechenden DomänenManager konfigurieren, sodass Sie Wrapper-Pakete von den Spiegelkopien
erstellen können, die sich am selben Ort wie Ihre Domänen-Manager
befinden.
Spiegelung
Gibt an, dass das Repository eine Spiegelkopie ist, die von einem Master
oder einer anderen Spiegelkopie erstellt wird.
Spiegelvorlage
Gibt an, dass die Spiegelkopie nur eine Vorlage und kein physisches
Repository ist. Die Spiegelvorlage ist nur ein Platzhalter für mehrere
Spiegelkopie-Repositorys, die die gleiche Konfiguration aufweisen. Wenn
Sie über zahlreiche Spiegelkopien verfügen, können Sie eine
Spiegelkopievorlage für jedes übergeordnete Element erstellen, anstatt
dass Sie eine Reihe für alle Spiegelkopien erstellen. Spiegelvorlagen
werden für die Softwarebereitstellung und die Extraktion der RepositoryDaten, jedoch nicht für die Spiegelsynchronisierung verwendet. Der
Hostname der die Spiegelkopien hostenden Computer wird dynamisch zur
Laufzeit ersetzt.
Repository-Typ
Gibt den Repository-Typ an.
Repository-Methode
Gibt das Übertragungsprotokoll an, das verwendet wird, um die Pakete vom
Repository auf die Zielcomputer zu übertragen. Wählen Sie HTTP oder FTP in
Abhängigkeit der von Ihnen vorgenommenen Konfiguration aus. Weitere
Informationen über diese Konfiguration finden Sie unter "Einrichten von FTPund HTTP-Freigaben für Softwarepakete und BS-Images".
Hinweis: Wenn das Repository ein Master ist und Sie das Repository
durchsuchen und Wrapper-Pakete davon erstellen möchten, konfigurieren Sie
das Repository als eine FTP-Freigabe.
Hostname
Gibt den Hostnamen des Computers an, der das Repository hostet. Geben Sie
für Spiegelvorlagen-Repositorys den Hostnamen nicht an, da der Hostname
dynamisch zur Laufzeit angegeben wird. Auch wenn Sie ihn angeben, wird der
Hostname für Spiegelvorlagen ignoriert.
Stamm
Gibt den Stammknoten des Repositorys an.
5.
Wiederholen Sie Schritt 4, um weitere Repositorys hinzuzufügen.
6.
Speichern und versiegeln Sie die Richtlinie. Überprüfen Sie, ob die Richtlinie auf
allen Zielcomputern angewandt wird.
Die Informationen des übergeordneten Repositorys werden auf allen Zielcomputern
aktualisiert.
Definieren der Spiegelsynchronisierung-Details
Der Synchronisierungsjob erfordert, dass Sie die Spiegelsynchronisierung-Details für
jedes Spiegelkopie-Repository definieren. Der Job verwendet diese Details, um die
Spiegelkopien zu synchronisieren.
1.
Navigieren Sie zu "Systemsteuerung", "Konfiguration". Klicken Sie mit der rechten
Maustaste auf "Konfigurationsrichtlinie", und wählen Sie "Neue Richtlinie" aus.
Sie benötigen eine neue Richtlinie für die Spiegelsynchronisierung, sodass Sie die
Synchronisierungsdetails nur auf die Computer anwenden können, die die
Spiegelkopien hosten.
2.
Repository", "Debian", und doppelklicken Sie auf "Spiegelsynchronisierung".
3.
Geben Sie die folgenden Informationen für das Spiegeln eines Repositorys in der
Spiegelsynchronisierungstabelle an:
Übergeordneter Repository-Name
Gibt das übergeordnete Repository an, das Sie spiegeln möchten.
Hinweis: Stellen Sie sicher, dass der von Ihnen in diesem Feld angegebene
übergeordnete Repository-Name mit dem Namen in der RepositorysKonfigurationstabelle unter der standardmäßigen Konfigurationsrichtlinie,
"DSM", "Software Delivery", "Freigegeben", "Externes Repository", "Debian"
übereinstimmt. Wenn die Namen nicht übereinstimmen, schlägt der
Synchronisierungsjob zur Laufzeit fehl.
Verteilungen
Gibt die Liste der Bereitstellungen des ausgewählten Repositorys an, die
gespiegelt werden müssen. Sie können mehr als einen Wert angeben, indem
Sie jeden Wert durch ein Leerzeichen abtrennen.
Komponenten
Gibt die Liste der Komponenten des ausgewählten Repositorys an, die
Architekturen
Gibt die Liste der Architekturen des ausgewählten Repositorys an, die
Standort
Gibt den Speicherort an, unter dem Sie das Spiegelkopie-Repository erstellen
möchten.
Hinweis: Stellen Sie sicher, dass dieser Speicherort als HTTP- und FTP-Freigabe
erweitert wird. Weitere Informationen über das Einrichten von HTTP- und FTPFreigaben finden Sie unter "Einrichten von FTP- und HTTP-Freigaben für
Softwarepakete und BS-Images".
Zusätzliche Argumente
Gibt die zusätzlichen Argumente an, die verwendet werden, während das
"debmirror"-Hilfsprogramm gestartet wird.
Status
Gibt an, ob Sie die Spiegelkopie synchronisieren möchten. Wenn Sie ein
Spiegelkopie-Repository nicht aktiv verwenden, können Sie die
Synchronisierung deaktivieren, ohne die Spiegelkopie zu löschen.
4.
Speichern und versiegeln Sie die Richtlinie. Wenden Sie die Richtlinie auf Computer
an, die das Spiegelkopie-Repository hosten.
Die Spiegelsynchronisierung-Details werden definiert, und die Konfiguration wird
auf die Spiegelkopie-Computer angewandt.
Planen der Spiegelsynchronisierung
Planen Sie die Spiegelsynchronisierung, um die Spiegelkopie mit ihrem übergeordneten
Repository zu einer geplanten Zeit automatisch zu synchronisieren. Das SpiegelkopieRepository wird erstellt, wenn der Synchronisierungsjob erstmals erfolgreich ausgeführt
wird, nachdem Sie die Spiegelsynchronisierung-Details definiert haben.
1.
Navigieren Sie zu "Systemsteuerung", "Konfigurationsrichtlinie".
2.
Klicken Sie mit der rechten Maustaste auf die Konfigurationsrichtlinie, die Sie auf
Spiegelkopien hostende Computer angewendete haben, und wählen Sie
"Versiegelung aufheben" aus.
3.
Navigieren Sie im DSM-Explorer zu "DSM", "Allgemeine Komponenten", "CAF",
"Planer", "MirrorSync ausführen".
4.
Wählen sie "CAF-Scheduler: Aktiviert" aus, und legen Sie den Wert auf "Wahr" fest.
5.
Konfigurieren Sie die anderen Parameter unter dem Knoten "MirrorSync
ausführen", um den Plan der Spiegelsynchronisierung anzugeben. Drücken Sie auf
F1, um weitere Informationen über die Planungsparameter zu erhalten.
6.
Versiegeln Sie die Richtlinie, und wenden Sie sie auf Computer an, die die
Spiegelkopie-Repositorys hosten.
Die Spiegelsynchronisierung wird geplant. Zu einer geplanten Zeit synchronisiert
der CAF-Scheduler die Spiegelkopie mit dem übergeordneten Repository.
Überprüfen der Spiegelsynchronisierung
Folgen Sie nach der Ausführung des Spiegelsynchronisierungsjobs diesen Schritten, um
sicherzustellen, dass die Spiegelsynchronisierung erfolgreich war und CA ITCM eine
Verbindung zu den Spiegeln herstellen kann.
1.
Anzeigen des Status der letzten Spiegelsynchronisierung (siehe Seite 186)
2.
Extrahieren von Paketmetadaten aus dem Repository (siehe Seite 169)
3.
Anzeigen von Debian-Paketen in der Webkonsole (siehe Seite 171)
Anzeigen des Status der letzten Spiegelsynchronisierung
Sie können den Status der letzten Synchronisierung anzeigen, um zu überprüfen, ob die
Spiegelsynchronisierung erfolgreich war.
1.
Überprüfen Sie die Engine-Protokolle, um sicherzustellen, dass der InventarErfassungs-Task mindestens einmal nach der letzten Spiegelsynchronisierung
ausgeführt wurde.
2.
Navigieren Sie zu "Computer und Benutzer", "Alle Computer", Spiegelcomputer,
"Inventar", "Systemstatus", "Externe Repositorys".
Die Seite "Externe Repositorys" wird angezeigt.
3.
Zeigen Sie den Wert des folgenden Parameters an, um den Status anzuzeigen:
Last Sync Result (Letztes Synchronisationsergebnis)
Gibt das Ergebnis der letzten Spiegelsynchronisierung an. Eine erfolgreiche
Synchronisierung gibt 0 zurück, und ein Fehler gibt einen Wert zurück, der nicht
null entspricht.
Folgen Sie bei einer fehlerhaften Synchronisierung den folgenden Schritten:
a.
Stellen Sie die Prozedur "FetchMirrorLog" im Add-on des CA-DSM-Agents
für das Debian Mirror 1.0-Paket auf dem Computer bereit, auf dem die
Synchronisierung fehlschlug.
b.
Überprüfen Sie den Jobstatus unter "Alle Computer", Computername,
"Jobs", "Softwarejobs".
c.
Klicken Sie mit der rechten Maustaste auf den Vorgangsjob
"FetchMirrorLog", wählen Sie "Eigenschaften" aus, und klicken Sie auf die
Registerkarte "Jobausgabe".
Das Spiegelsynchronisierungsprotokoll wird angezeigt.
Extrahieren von Paketmetadaten aus dem Repository
Beim Extrahieren der Paketmetadaten aus dem Repository können Sie die Details des
Debian-Pakets auf der DSM-Webkonsole anzeigen.
Hinweis: Folgende Schritte gelten für das Extrahieren von Paketmetadaten von Masterund Spiegel-Repositorys.
1.
Navigieren Sie zur Systemsteuerung, "Engines", "Alle Engines", "SystemEngine" im
DSM-Explorer.
Das Engine-Protokoll wird angezeigt.
2.
Klicken Sie mit der rechten Maustaste auf "SystemEngine", und wählen Sie "Neuen
Task hinzufügen" aus.
Der Assistent für neuen Task wird geöffnet.
3.
Folgen Sie den Anweisungen, und führen Sie die folgenden Schritte im Assistenten
aus:
a.
Wählen Sie den Tasktyp als "Extraktion der CA-Repository-Daten" aus, und
geben Sie einen Task-Namen bzw. eine -Beschreibung ein. Klicken Sie auf
"Weiter".
Hinweis: Stellen Sie sicher, dass Sie die System-Firewall deaktivieren, um den
Task erfolgreich auszuführen.
b.
Geben Sie die folgenden Informationen an:
Hinweis: Da sich der Repository-Server unter Linux befindet, muss bei den in
den folgenden Feldern "Verteilung" und "Komponentenname" bereitgestellten
Werten die Groß-/Kleinschreibung beachtet werden. Sie müssten mit der Groß/Kleinschreibung im Repository-Server übereinstimmen. Wenn beispielsweise
der Repository-Server-Speicherort
"ftp://172.16.0.12/ubuntu/dists/lucid/main/binary-i386/" lautet, muss der
Verteilungsname als "lucid" angegeben werden und nicht als "Lucid" oder
"LUCID".
Repository-Name
Gibt den Repository-Namen an, von dem aus Sie die Paketmetadaten
extrahieren möchten. Die Liste zeigt die von Ihnen in der RepositorysKonfigurationstabelle definierten Repositorys an.
Hinweis: Sie können nicht zwei Engine-Tasks mit der gleichen Repositoryund Verteilungskombination erstellen.
Hostname
Gibt den Hostnamen des Repositorys an. Dieses Feld ist nur für Repositorys
vom Typ "Spiegelvorlage" aktiviert. Bei Master- und Spiegel-Repositorys
wird der Hostname automatisch aus der Repositorys-Konfigurationstabelle
übernommen.
Distribution
Gibt die Verteilung an, von der aus Sie die Paketdetails extrahieren
möchten.
Hinweis: Ein Engine-Task kann Daten nur von einer einzelnen Verteilung
extrahieren. Wenn Sie Daten aus mehreren Verteilungen extrahieren
möchten, müssen Sie zusätzliche Engine-Tasks erstellen.
Komponentenname
Gibt die Komponenten an, die Sie extrahieren möchten. Klicken Sie auf
"Hinzufügen", um mehr Komponenten hinzuzufügen.
c.
4.
Gibt Planungsoptionen an.
Die SystemEngine erstellt den Task und führt ihn zu einer geplanten Zeit aus. Sie
können den Task überwachen, indem Sie auf "SystemEngine" klicken und den
Status im Bereich "Task-Liste" auf der rechten Seite überprüfen.
Hinweis: Sie können das Repository auch in der Webkonsole durchsuchen, während
der Engine-Task noch in Bearbeitung ist. Die Webkonsole zeigt die Verteilungen und
Pakete während und nach der Extrahierung aus dem Repository an.
Durchsuchen des Debian-Repositorys in der Webkonsole
Sie können die Inhalte eines Debian-Repositorys in der Webkonsole durchsuchen, um zu
erfahren, welche Pakete im Repository vorhanden sind.
1.
2.
Navigieren Sie zu "Konsole", "Software", "Externe Repositorys", Repository.
Es wird eine Liste der Verteilungen im ausgewählten Repository angezeigt. Die
Spalte "Synchronisierungsstatus" zeigt den Status des Repository-Extraktions-Tasks
an. Sie können auch auf "Anzeigen" unter der Spalte "Synchronisierungsprotokoll"
klicken, um den Fortschritt der Metadatenextrahierung und die ggf. auftretenden
Fehler anzuzeigen.
Hinweis: Wenn Sie das Repository öffnen, bevor der Extraktions-Task
abgeschlossen ist, ist es möglich, dass nicht alle Verteilungen in der Liste angezeigt
werden.
3.
Klicken Sie auf eine Verteilung.
Eine Liste von Debian-Paketen wird in der Verteilung angezeigt.
Einrichten von FTP- oder HTTP-Freigaben für Softwarepakete und BS-Images
Für Kubuntu-Bereitstellungen müssen Sie eine FTP- oder HTTP-Freigabe einrichten, um
Softwarepakete und BS-Images zu speichern.
Weitere Informationen finden Sie im BS-InstallationsverwaltungsAdministrationshandbuch unter Einrichten von FTP- oder HTTP-Freigaben für
Softwarepakete und BS-Images.
Konfigurationsparameter für das Verwalten von Debian-Paketen
CA ITCM stellt neue Konfigurationsparameter bereit, um Debian-Pakete zu verwalten.
Navigieren Sie zu DSM, Software Delivery, Agent, um diese Parameter zu verwenden.
■
Debian-Jobprüfung: Zeitlimit für Jobausführung
■
Debian-Repository: Protokollierungsebene der APT-Befehle
■
Debian-Repository: Pakete automatisch entfernen
■
Debian-Repository: Ausführung von Post-Aktionen
■
Debian-Repository: Ausführung von Prä-Aktionen
■
Debian-Deinstallationsverhalten: Pakete neu installieren
Weitere Informationen zu einer Parameterbeschreibung finden Sie in der
Konfigurationsrichtlinienbeschreibung in DSM-Explorer.
Installieren des debmirror-Hilfsprogramms
Das debmirror-Hilfsprogramm synchronisiert ein Debian-Spiegel-Repository vom
übergeordneten Repository. Installieren Sie das debmirror-Hilfsprogramm auf
Computern, die das Spiegel-Repository hosten, um die Spiegel synchronisieren zu
können.
Installieren von debmirror unter dem Betriebssystem Ubuntu
Führen Sie den folgenden Befehl aus, um das debmirror-Hilfsprogramm unter dem
Betriebssystem Ubuntu zu installieren:
sudo apt-get install debmirror
Wenn der Befehl erfolgreich ausgeführt wird, wird das debmirror-Hilfsprogramm
installiert.
Installieren von debmirror unter RedHat oder SUSE
In diesem Abschnitt wird beschrieben, wie Sie einen Debian-Spiegel auf RedHat- oder
SUSE-Computern einrichten können. Da DSM-Scalability-Server unter Debian nicht
unterstützt werden, können Sie Spiegel des Debian-Systems auf RedHat- oder SUSEComputer einrichten.
Überprüfen der Voraussetzungen
Überprüfen Sie, ob die folgenden Voraussetzungen gegeben sind, bevor Sie einen
Debian-Spiegel einrichten:
■
Perl 5.14 oder höher ist auf dem Zielcomputer installiert.
■
Der Masterserver, von dem das Repository gespiegelt wird, ist bereits konfiguriert.
Wenn debmirror z. B. die HTTP-Download-Methode verwendet, konfigurieren Sie
den Masterserver so, dass ein virtuelles Verzeichnis des Repositorys angezeigt wird.
Falls FTP verwendet wird, sind ähnliche Konfigurationen erforderlich.
Herunterladen von Perl-Skripten für die Verwendung von Debmirror
Debmirror ist ein Perl-Skript, das Debian-Repositorys auf RedHat- oder SUSE-Computern
spiegelt. Debmirror erfordert, dass bestimmte Perl-Module vorhanden sind.
Gehen Sie folgendermaßen vor:
1.
Überprüfen Sie, ob die folgenden Perl-Module vorhanden sind:
■
LockFile::Simple;
■
Compress::Zlib;
■
Digest::MD5;
■
Digest::SHA;
■
Net::INET6Glue;
■
LWP::UserAgent
Eine Standardinstallation umfasst nur wenige Perl-Module. Wenn die Module nicht
verfügbar sind, installieren Sie die Module mithilfe einer der folgenden
Vorgehensweisen:
Vorgehensweise 1: unter Verwendung des cpanminus-Tools
a.
Installieren Sie das cpanminus-Tool, das Perl-Module herunterlädt. Führen Sie
eine der folgenden Aktionen aus, um das cpanminus-Tool zu installieren:
–
Führen Sie den Befehl "App::cpanminus" aus.
–
Führen Sie das RPM-Paket für cpanminus aus, das von dem folgenden Ort
heruntergeladen werden kann:
http://rpmfind.net/linux/rpm2html/search.php?query=cpanminus
b.
Führen Sie den folgenden Befehl aus, um die erforderlichen Perl-Module zu
installieren:
cpan m <modul-name>
Beispiele:
Um das LockFile::Simple-Modul zu installieren, führen Sie den Befehl "cpanm
LockFile::Simple" aus.
Um das Net::INET6Glue-Modul zu installieren, führen Sie den Befehl "cpanm
Net::INET6Glue" aus.
Mit dem Befehl werden die Perl-Module aus dem Internet heruntergeladen
und installiert. Dieser Befehl löst Abhängigkeiten automatisch.
c.
Stellen Sie sicher, dass die Perl-Module installiert sind.
Vorgehensweise 2: unter Verwendung der src-Pakete
a.
Laden Sie das Perl-Modulpaket-tar von
http://www.cpan.org/modules/index.html herunter.
b.
Extrahieren Sie das tar-Programm.
c.
Führen Sie den Perl-Befehl "MakeFile.PL" aus. Dieser Befehl generiert ein
Makefile.
d.
Führen Sie den Befehl "make" aus.
e.
Führen Sie den Befehl "make install" aus.
Hinweis: Stellen Sie sicher, dass Sie die Abhängigkeiten manuell lösen. Zum
Beispiel hängt Net::INET6Glue vom Socket6-Modul ab. Stellen Sie sicher, dass
Socket6 installiert ist, bevor Sie Net::INET6Glue installieren. Sie finden die
Abhängigkeiten am folgenden Ort:
http://deps.cpantesters.org/
f.
Hinweis: Überprüfen Sie für die Vorgehensweisen 1 und 2, dass GCC auf dem RedHatoder SUSE-Computer installiert ist.
Vorgehensweise 3: unter Verwendung der RPM-Quellen
a.
Suchen Sie im Internet nach den folgenden Perl-Modulen, und installieren Sie
die Module mithilfe von YUM:
–
perl-Compress-Zlib-1.42-1.fc6
–
perl-Digest-SHA1-2.11-1.2.1.i386.rpm
–
perl-LockFile-Simple-0.206-1.el5.rf.noarch.rpm
–
perl-Digest-MD5-M4p-0.01-1.2.el5.rf.i386.rpm
Hinweis: Wenn Sie das libnet-inet6glue-perl-Modul im Internet nicht finden,
laden Sie die Quelldateien herunter, und erstellen Sie die Binärdateien manuell
mit Vorgehensweise 2.
b.
Installieren von debmirror
Installieren Sie das debmirror-Hilfsprogramm auf Computern, die das Spiegel-Repository
hosten, damit Sie Spiegel des Master-Debian-Repositorys erstellen können.
1.
Laden Sie das neueste debmirror src-Paket (zurzeit debmirror_2.14ubuntu1.tar.gz)
von http://archive.ubuntu.com/ubuntu/pool/universe/d/debmirror/ herunter.
2.
Extrahieren Sie die tar-Datei, und kopieren Sie das debmirror-Perl-Skript auf dem
RHEL/SUSE-Computer in das Verzeichnis "/usr/bin".
3.
Führen Sie den debmirror-Befehl aus.
Kapitel 6: Integration in Data Transport
Service
Mit Hilfe von Data Transport Service (DTS), einem Verwaltungsprogramm zur
Datenübertragung, können Sie den Datenfluss in der Software Delivery-Umgebung
steuern. Sie können mit DTS eine Netzwerktopologie zur Datenübertragung erstellen,
die aus Computerobjekten besteht, und bevorzugte Routen für die Datenübertragung
definieren.
Weitere Informationen zu den DTS-Funktionen und -Einstellungen finden Sie im
Administratorhandbuch zu Data Transport Service, das zur Online-Dokumentation von
CA ITCM gehört.
Verwenden von DTS mit Software Delivery (siehe Seite 195)
Mit Software Delivery installierte DTS-Komponenten (siehe Seite 196)
Aktivieren und Deaktivieren von DTS (siehe Seite 198)
Arbeitsweise von DTS (siehe Seite 198)
Verwenden von DTS mit Software Delivery
Mit Data Transport Service (DTS) kann die Übertragung von Software Delivery-Objekten
zwischen Enterprise- und Domänen-Manager, Domänen-Manager und ScalabilityServer, Domänen-Manager und Agenten sowie Scalability-Server und Agenten
vereinfacht werden.
Die Leistung der verwalteten DTS-Dateiübertragungen wurde verbessert, indem interne
Mechanismen umgestaltet wurden und die Anzahl der gestarteten Prozesse minimiert
wurde.
Diese Umgestaltung hat Vorteile für alle verwalteten Dateiübertragungen zwischen dem
Enterprise-Manager und dem Domänen-Manager, dem Domänen-Manager und dem
Scalability-Server, dem Domänen-Manager und dem Agenten und dem ScalabilityServer und dem Agenten sowie für die Aufhebung der Registrierung von
Softwarepaketen in der Softwarebibliothek der Scalability-Server.
Wenn Sie eine Aktualisierung von CA IT Client Manager durchführen, müssen alle
Dateiübertragungen abgeschlossen sein. Wenn Dateiübertragungen während einer
Aktualisierung eines Managers aktiv sind, gehen sie verloren.
Kapitel 6: Integration in Data Transport Service 195
Mit Software Delivery installierte DTS-Komponenten
DTS zwischen Managern und Scalability-Servern
Data Transport Service (DTS) ist in Software Delivery (SD) integriert, so dass Sie die
Verwendung von Software Delivery im Netzwerk optimal an Ihre Anforderungen
anpassen können. Dies kann durch die Definition einer Netzwerktopologie, bestehend
aus Ihren Managern und den vermittelnden Scalability-Servern, erreicht werden. Die
Fanout-Funktion der Scalability-Server, d. h. ein einziger Lesevorgang mit vielen
Sende- und Schreibvorgängen, kann von DTS ausgeführt werden. Es kann ebenfalls die
Punkt-zu-Viele-Funktion verwenden, d. h. ein einzelner Lesevorgang, ein
einzelner Sendevorgang und viele Schreibvorgänge. Fanout oder Punkt-zu-Viele kann
jedoch nur ausgeführt werden, wenn die Übertragungsobjekte bestimmte gemeinsame
Eigenschaftswerte aufweisen. Zwischen diesen Managern können hierarchische
Beziehungen eingerichtet werden, die festlegen, wie die Daten verteilt werden.
DTS stellt eine unbeschränkte Fanout-Hierarchie bereit, die Feinabstimmungen
ermöglicht. Mit Hilfe der erweiterten Fanout- und Routing-Funktionen von DTS können
Sie effiziente Netzwerke einrichten.
DTS zwischen Domänen-Managern und Agenten
Data Transport Service (DTS) kann auf Software Delivery-Agenten (SD-Agenten)
installiert werden, um die Verbindungsmöglichkeiten zwischen diesen Agenten und dem
Domänen-Manager zu verbessern.
Sobald DTS auf einem SD-Agenten installiert wurde, kann ein DTS-Download ohne NOS
verwendet werden. Der SD-Manager unterstützt Mix-and-Match. Dies bedeutet, dass er
Dateien gleichzeitig über die in Software Delivery integrierte Dateiübertragung an
Software Delivery-Agenten ohne DTS sowie mit Hilfe der DTS-Dateiübertragung an
Agenten mit installiertem DTS senden kann.
Die Integration von Software Delivery in DTS bietet die folgenden Vorteile:
■
Modernste Multicast- und Broadcast-Technologie reduziert Netzwerküberlastung.
■
Mobile Benutzer, die zeitweise Verbindungen zu einem Firmennetzwerk
verwenden, können sich dank der automatischen Checkpoint-Neustart-Funktionen
von DTS auf die Integrität der an sie gesendeten Daten verlassen.
■
Sichere Datenübertragungsfunktionen führen zu verbesserter Datenintegrität.
In den folgenden Abschnitten werden die Data Transport Service-Komponenten
genannt, die bei der Installation von Software Delivery installiert werden.
DTS-Komponenten unter Windows
Data Transport Service-Komponenten (DTS-Komponenten) werden auf EnterpriseManagern, Domänen-Managern und Scalability-Servern unter Windows automatisch
installiert. Bei Agenten gilt jedoch Folgendes:
■
Enterprise-Manager:
DTS Network Object Server (NOS), Transfer Object Server (TOS), Schedule Object
Server (SOS) und DTS-Agent werden installiert.
■
Domänen-Manager:
■
Scalability-Server:
DTS-Agent wird installiert.
■
Agent:
Unter Windows befindet sich die DTS-Funktionalität nicht im Software DeliveryAgenten-Plugin, sondern in einem separaten Installationspaket. D. h., dass Sie das
gesonderte DTS-Installationspaket auf diesem Agenten bereitstellen müssen, wenn
Sie die DTS-Funktionalität benötigen, z. B. um die Download-Methode für diesen
bestimmten Agenten anzugeben.
Hinweis: Wenn der DTS-Agent über ein separates Installationspaket installiert wird,
müssen Sie ihn separat entfernen, wenn Sie den Software Delivery-Agenten
deinstallieren.
DTS-Komponenten unter Linux und UNIX
Data Transport Service (DTS) wird bei Enterprise-Managern, Domänen-Managern,
Scalability-Servern und Agenten unter Linux oder UNIX automatisch installiert:
Enterprise-Manager:
Domänen-Manager:
Kapitel 6: Integration in Data Transport Service 197
Aktivieren und Deaktivieren von DTS
Scalability-Server:
Agent:
Hinweis: Das Verhalten von Data Transport Service wird durch Einstellungen aus einer
Konfigurationsrichtlinie gesteuert.
Aktivieren und Deaktivieren von DTS
Wenn Sie die DTS-Download-Methode ohne NOS für Agenten aktivieren oder
deaktivieren möchten, klicken Sie im DSM-Explorer einfach mit der rechten Maustaste
auf einen oder mehrere Agenten oder eine Gruppe von Agenten und aktivieren oder
deaktivieren Sie die Option "Softwarejobs", "Download-Methode", "DTS - ohne NOS".
Nach dieser Einstellung wird Software Delivery diese Download-Methode nicht mehr
verwenden, wenn Software, die vom SD-Agenten installiert werden soll, übertragen
wird.
Eine andere Methode, den Download-Typ zu ändern, ist folgende: Verwenden Sie den
Befehl "sd_acmd SetDownloadMethod <DTS | NONE | NOS>" oder stellen Sie sie in den
erweiterten Software Delivery-Eigenschaften auf dem Agent-Computer ein (Software
Delivery: Ein bestimmtes Netzwerkbetriebssystem anfordern (NOS)).
Zwischen Managern und Scalability-Servern kann DTS nicht deaktiviert werden, da es
sich um die einzige Übertragungsmethode handelt, die zwischen diesen Teilen des SDNetzwerks unterstützt wird.
Arbeitsweise von DTS
Wenn Jobs für Agenten eingerichtet werden, die eine Verbindung zu Scalability-Servern
herstellen, prüft der Domänen-Manager als Erstes, ob das betreffende Paket bereits in
der Softwarepaketbibliothek auf dem Scalability-Server gespeichert ist. Sollte das der
Fall sein, wird eine Kopie mit Data Transport Service (DTS) an den Agenten gesendet.
Wenn das Paket nicht in der Softwarepaketbibliothek auf dem Scalability-Server
vorhanden ist, wird das Paket aus der Softwarepaketbibliothek auf dem DomänenManager übertragen. Wenn die DTS-Dateiübertragung der Softwarepakete
abgeschlossen ist, werden die Jobaufträge an den Scalability-Server gesendet, damit die
Agenten ausgeführt werden. Sobald der Job beendet ist, werden die für den Job
heruntergeladenen Dateien gelöscht.
Kapitel 7: Diagnose und Fehlerbehebung
bei Software Delivery
In diesem Kapitel werden einige der häufigsten Fragen zu den Funktionen und
Komponenten von Software Delivery behandelt sowie Informationen zum Beheben
möglicher Probleme geliefert. Lesen Sie diese Informationen, bevor Sie sich an den
Technischen Support von CA Technologies wenden.
Ermitteln der Build-Nummer von CA ITCM (siehe Seite 200)
Prüfen der Application Framework-Plugins (siehe Seite 200)
Absturz des RAL-Extrahierungstasks (siehe Seite 201)
Softwarebereitstellungsjobs hängen sich auf gestreamten virtuellen Citrix XenDesktopRechnern gelegentlich auf (siehe Seite 202)
Erfassungstool für Protokolldateien dsminfo (siehe Seite 203)
Protokolldateien für CAF-Dienste (siehe Seite 203)
Software Delivery-Protokolldateien (siehe Seite 204)
Data Transport Service-Protokolldateien (siehe Seite 205)
Registrierung von großen Softwarepaketen im DSM-Explorer dauert sehr lange (siehe
Seite 206)
Migrierte Abfrage ergibt unterschiedliche Ergebnisse (siehe Seite 207)
Verschieben des Softwarekatalogs und des Scalability-Servers (siehe Seite 207)
Woher weiß ich, ob die SD Agent Bridge läuft? (siehe Seite 208)
Task-Manager kann nicht im gleichzeitigen Modus ausgeführt werden (siehe Seite 208)
Installations-Manager kann nicht im gleichzeitigen Modus ausgeführt werden (siehe
Seite 209)
apt-Befehle für die Bereitstellung (siehe Seite 210)
Löschen von RAL-Datensätzen aus der MDB (siehe Seite 211)
Registrierung des Legacy-Agenten schlägt fehl (siehe Seite 212)
Unicenter Software Delivery-Agent kann auf HP-UX System nicht gestartet werden
(siehe Seite 213)
RAC-Containerjob fehlgeschlagen (siehe Seite 213)
Bereitstellung von Softwarepaketen für virtuelle Anwendungen schlägt fehl (siehe Seite
214)
Netzwerkinstallation des MSI-Pakets schlägt fehl (siehe Seite 216)
Nicht durchgeführter Start des SD-Agents nach einem CAF-Neustart (siehe Seite 217)
Kein vorab ausgeführtes Seeding der Variablen in "debconf"-Parametern (siehe Seite
217)
Fehler bei der Installation von Debian-Wrapper-Paketen (siehe Seite 218)
Fehler bei der Installation von Debian-Wrapper-Paketen (siehe Seite 219)
Der SD-Job hängt und die Meldung wird nicht angezeigt (siehe Seite 219)
Kapitel 7: Diagnose und Fehlerbehebung bei Software Delivery 199
Ermitteln der Build-Nummer von CA ITCM
Windows-Erkennung für interaktive Services sperrt Agenten (siehe Seite 220)
Fehlender "DebWrap"-Pakettyp in DSM-Reporter (siehe Seite 220)
Fehlerhafter Abbruchsbefehl während der Neuinstallation von VDI-Komponenten (siehe
Seite 220)
Ermitteln der Build-Nummer von CA ITCM
Um die Build-Nummer der installierten CA ITCM-Komponenten zu ermitteln, führen Sie
folgenden Befehl über die DOS-Eingabeaufforderung aus:
dsmver
Prüfen der Application Framework-Plugins
Wenn Probleme mit Software Delivery auftreten, sollten Sie als Erstes prüfen, ob alle
Dienste aktiviert sind und ausgeführt werden. Führen Sie dazu den Befehl "caf status"
aus.
Das folgende Beispiel zeigt die Ausgabe auf einem Manager-System:
caf status
Statusinformationen werden von caf abgerufen...
CA DSM r12 Common Application Framework 12.xx.xx.xx
Aktive DSM-Dienste anzeigen...
[1] Asset Management-Manager (ammanager)
[2] Asset Management-Leistungs-Agent (ampmagent)
[3] Asset Management-Server (amrss)
[4] Asset Management-Verwendungsserver (amms)
[5] Zertifikatsaustausch-Plugin (cfcertex)
[6] Allgemeiner Server (cserver)
[7] Manager für allgemeine Objekte (cmobjectmanager)
[8] Konfigurationsagent (ccnfagent)
[9] CSM Agent (ccsmagt)
[10] CSM Agent Controller (ccsmact)
[11] CSM-Datenbank-API-Server (ccsmapi)
[12] CSM Server (ccsmsvr)
[13] DSM-Dienst-Locator-Plugin (cfsvclocator)
Absturz des RAL-Extrahierungstasks
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
Data Transport network object server (dtsnos)
Data Transport schedule object server (dtssos)
Data Transport transfer agent (dtsagent)
Data Transport transfer object server (dtstos)
Bereitstellungs-Manager (dmdeploy)
Engine (SystemEngine)
Ereignisbenachrichtigungs-Plugin (cfnotify)
File transfer server (cfftplugin) (transfers job output)
Benachrichtigungsserver (cfnotsrvd)
Port-Multiplexer (pmux)
Registrierungs-Plugin (cfregister)
Remote Control-Host-Agent (rchost)
Remote Control-Manager (rcmanager)
Remote Control-Server (rcserver)
Session Messaging-Server (smserver)
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
Software Delivery boot server (sdmpcserver)
Software Delivery manager: api server (sdmgr_api_0)
Software Delivery manager: dialog manager (sdmgr_dm)
Software Delivery manager: file transfer (sdmgr_ft)
Software Delivery manager: installation manager (sdmgr_im)
Software Delivery manager: task manager (sdmgr_tm)
Software Delivery server (sdserver)
Tomcat-Server (tomcat)
Die fett markierten CAF-Dienste gelten nur für Software Delivery.
Sollte ein Dienst deaktiviert sein, können Sie ihn z. B. folgendermaßen starten:
caf start sdserver
Sie sollten in diesem Fall die Protokolldatei überprüfen, um herauszufinden, warum der
Dienst beendet wurde.
Absturz des RAL-Extrahierungstasks
Wenn die Firewall auf dem Computer aktiviert wird, der den RAL-Extrahierungstask
ausführt, fügen Sie der Firewallausnahmeliste die Datei "java.exe" hinzu.
Wenn CA ITCM beispielsweise an einem standardmäßigen Speicherort installiert ist,
müssen Sie der Firewallausnahmeliste den folgenden Pfad hinzufügen:
C:\Program Files (x86)\CA\SC\JRE\1.7.0_17\bin\java.exe
Softwarebereitstellungsjobs hängen sich auf gestreamten virtuellen Citrix XenDesktop-Rechnern gelegentlich auf
Softwarebereitstellungsjobs hängen sich auf gestreamten
virtuellen Citrix XenDesktop-Rechnern gelegentlich auf
Symptom:
Wenn ich einen Softwarebereitstellungsjob-Container mit 15 oder mehreren Jobs
erstelle und den Container für 15 oder mehrere Rechner bereitstelle, hängt sich der
Softwarebereitstellungsjob auf einigen Rechnern auf. Der Job wird nicht abgeschlossen.
Für den "caf status"-SD-Agent wird cfPluginWorkerProcess is waiting for Messages
(cfPluginWorkerProcess wartet auf Meldungen) angezeigt.
Lösung:
Überschreiben Sie den Standardwert, und weisen Sie für die Software DeliveryKonfigurationseinstellung, Scalability-Server, einen entsprechenden Wert zu:
"Gleichzeitige Ausführung: Maximale Anzahl von gleichzeitig ausführenden Agenten auf
dem Scalability-Server". Diese Aktion stellt sicher, dass die Anzahl der Agenten, die mit
dem Scalability-Server verbunden sind und Jobs ausführen, optimal verwaltet wird.
Verwenden Sie den Wert 10 für den obigen Konfigurationsparameter für einen
Bereitstellungsjobcontainer mit 15 Jobs auf jedem der 15 Computer.
Hinweis: Der Standardwert ist 25 und der optimale Wert für diese Einstellung ist von
externen Faktoren wie Netzwerklatenz, Speicher und verfügbare CPU-Ressourcen
abhängig. Wenn die Jobs weiterhin aufgehängt bleiben, reduzieren Sie den Wert noch
einmal.
Erfassungstool für Protokolldateien dsminfo
Erfassungstool für Protokolldateien dsminfo
CA Technologies stellt das Tool "dsmInfo" zur Verfügung, das Diagnoseinformationen
von Systemen erfasst, in denen CA ITCM installiert ist. Die gesammelten Daten werden
in eine einzelne Datei komprimiert, die Protokolldateien, Systeminformationen,
Verzeichnisstrukturen sowie Registrierungs- und Umgebungsinformationen enthält.
Dieses Diagnose-Tool ist befindet sich auf dem CA ITCM Produktinstallationsdatenträger
im Ordner "DiagnosticTools".
Wenn Sie ein Problem mit CA ITCM reproduzieren können, führen Sie den folgenden
Befehl aus, um die Trace-Ebene in DETAIL zu ändern:
cftrace -c set -l DETAIL
Reproduzieren Sie das Problem und sammeln Sie die Diagnoseinformationen mit dem
Tool "dsmInfo".
Hinweise:
Weitere Information zu diesem Tool finden Sie in der Datei DSMInfoReadMe.txt im
Ordner "DiagnosticTools" auf dem Datenträger für die Produktinstallation.
Das Tool "dsmInfo" erzeugt standardmäßig ".7z"-Dateien . Diese Dateien bieten bessere
Verdichtung als ZIP-Dateien, so ist es leichter, sie nach CA Technologies hochzuladen.
Protokolldateien für CAF-Dienste
Die Common Application Framework-Dienste (CAF) protokollieren ihre Aktivitäten in
Protokolldateien. Der Grad der Detaildarstellungen hängt von der Trace-Ebene ab, die
benutzerdefinierbar ist. Die Protokolldateien unterstützen Sie bei der Analyse von
Problemen.
Standardmäßig wird die Trace-Ebene auf ERROR (Fehler) gesetzt. Wenn Sie weitere
Trace-Informationen benötigen, können Sie die Trace-Ebene festlegen, z. B. können Sie
sie für Software Delivery-Funktionen oder Data Transport Service auf DETAIL festlegen,
indem Sie den Befehl "cftrace" folgendermaßen ausführen:
cftrace -c set -f USD -l DETAIL -s 30000
oder
cftrace -c set -f DTS -l DETAIL -s 30000
Software Delivery-Protokolldateien
Mit der Option "-s" wird die Größe der Protokolldatei auf 30.000 KB festgelegt.
Die standardmäßige Größe beträgt 2.000 KB, die für die Trace-Ebene DETAIL
u. U. zu klein ist. (Diese Trace-Datei wird überschrieben, wenn die
Größenbeschränkung und die Anzahl der konfigurierten Trace-Dateien erreicht wurde.)
Hinweis: Wenn Sie eine Liste der Trace-Einstellungen anzeigen möchten, führen Sie den
cftrace-Befehl folgendermaßen aus:
cftrace list
Unter Windows befinden sich die Protokolldateien aller CAF-Dienste unter
"Installationsverzeichnis\logs" (Standard: C:\Programme\CA\DSM\logs).
Die während der Installation von CA ITCM erstellten Protokolldateien befinden sich im
temporären Ordner des jeweiligen Benutzers. Normalerweise verweist die
Umgebungsvariable "%temp%" auf dieses Verzeichnis.
Unter Linux befinden sich die Protokolldateien der CAF-Dienste unter
$CA_ITRM_BASEDIR/logs (Default: /opt/CA/DSM/logs).
Die während der Installation von CA ITCM erstellten Protokolldateien befinden sich
unter "/opt/CA/installer/log".
Software Delivery-Protokolldateien
Die spezifischen Aktivitäten von Software Delivery werden in den folgenden TraceDateien protokolliert (n gibt die Dateinummer an):
Manager:
Dateiname
Description/Comment
TRC_USD_APISERVER_i_n.log
i ist die SD-API-Serverinstanznummer
TRC_USD_DIALOGM_n.log
Nicht zutreffend
TRC_USD_INSTMAN_n.log
Nicht zutreffend
TRC_USD_MPCWORKER_n.log
Nicht zutreffend
TRC_USD_SDAGENT_n.log
Nicht zutreffend
TRC_USD_SDMGRFT_n.log
Nicht zutreffend
TRC_USD_SDMSIEXE_n.log
Nur Windows
TRC_USD_SDSERVER_n.log
Nur auf dem Domänen-Manager
TRC_USD_SSCMD_n.log
Nur auf dem Domänen-Manager
TRC_USD_SXP_n.log
Nicht zutreffend
Data Transport Service-Protokolldateien
Dateiname
Description/Comment
TRC_USD_TASKMAN_n.log
Nicht zutreffend
TRC_MIGRATION_USD_n.log
Protokolldatei für Migration
Scalability-Server:
Dateiname
Description/Comment
TRC_USD_SDSERVER_n.log
Nicht zutreffend
TRC_USD_SXP_n.log
Nicht zutreffend
TRC_USD_SSCMD_n.log
Nicht zutreffend
Nicht zutreffend
Nur Windows
TRC_USD_MPCWORKER_n.log
OSIM Boot Server
Agent:
Dateiname
Description/Comment
Nicht zutreffend
Nur Windows
TRC_USD_SXP_n.log
Nicht zutreffend
Data Transport Service-Protokolldateien
Wenn beim Ausführen von Data Transport Service-Übertragungen Probleme oder Fehler
auftreten, haben Sie die Möglichkeit, einige Protokolldateien zu überprüfen. Sie können
auch die Tracing-Funktionen verwenden.
n gibt die Dateinummer an):
Manager:
Dateiname
Beschreibung/Kommentar
TRC_DtsTos_n.log
DTS Transfer Object Server-Protokolldatei
TRC_DtsNos_n.log
DTS Network Object Server-Protokolldatei
TRC_DtsSos_n.log
DTS Schedule Object Server-Protokolldatei
TRC_DTS_n.log
SDDTSFT-Protokolldatei
Registrierung von großen Softwarepaketen im DSM-Explorer dauert sehr lange
Dateiname
TRC_DtsAgent_n.log
DTS Master-Agent-Protokolldatei
TRC_DtsAgentm_n.log
DTS Slave-Agent-Protokolldateien, wobei m die
Nummer des DTS Slave-Agenten angibt
TRC_DtsBrowser.log
DTS-Browser-Protokolldatei
Scalability-Server und Agent:
Dateiname
TRC_DtsAgent_n.log
DTS Master-Agent-Protokolldatei
TRC_DtsAgentm_n.log
DTS Slave-Agent-Protokolldateien, wobei m die Nummer
des DTS Slave-Agenten angibt
Einrichten der DTS-Übertragung:
Die folgenden Protokolldateien werden von den Software Delivery-Funktionen erstellt,
die die DTS-Übertragungen einrichten.
Dateiname
TRC_USD_DTSFT_n.log
Für Lieferungen an Staging-Bibliotheken
Registrierung von großen Softwarepaketen im DSM-Explorer
dauert sehr lange
Symptom:
Wenn ich ein großes Softwarepaket im DSM-Explorer registriere, dauert die
Paketregistrierung sehr lange, und in der DSM-Explorer-Sitzung ist es nicht möglich, zur
gleichen Zeit andere Aufgaben auszuführen.
Lösung:
Bei der Registrierung eines großen Softwarepakets im DSM-Explorer kann die
Paketregistrierung je nach der Paketgröße, Server-Hardware-Konfiguration, Remoteoder lokalem DSM-Explorer und Auslastung des Servers einige Zeit dauern. Wenn Sie
andere Aufgabe im DSM-Explorer ausführen möchten, während der DSM-Explorer einen
ressourcenintensiven Vorgang durchführt (wie Registrierung eines großen
Softwarepakets, Auflistung zahlreicher Jobcontainer usw.), können Sie eine neue DSMExplorer-Sitzung öffnen und die gewünschte Aufgabe ausführen.
Migrierte Abfrage ergibt unterschiedliche Ergebnisse
Migrierte Abfrage ergibt unterschiedliche Ergebnisse
Abfragen mit dem Attribut "Type" (in der Attributgruppe "Target") und seinen Werten
"Machine" und "Staging Server" verhalten sich in Unicenter Software Delivery 4.0 und
CA ITCM unterschiedlich. Dies liegt daran, dass in Version 4.0 der Agent auf dem lokalen
Server für "Type" den Wert "Machine" hatte, während der Agent auf dem DomänenManager in CA ITCM den Wert "Staging-Server" hat.
In Unicenter Software Delivery 4.0 würde eine Abfrage des Typs
"Target.Type='Machine'" alle Agenten (keine Staging-Server) einschließlich des eigenen
Agenten des lokalen Servers zurückgeben. Wenn diese Abfrage auf CA ITCM migriert
wird, gibt sie nur eigenständige Agenten zurück, also Agenten, die über keinen
Scalability-Server oder Domänen-Manager auf demselben Rechner verfügen.
In Unicenter Software Delivery 4.0 würde eine Abfrage des Typs "Target.Type='Staging
Server'" alle Staging-Server zurückgeben. Wenn diese Abfrage auf CA ITCM migriert
wird, gibt sie auch den Domänen-Manager zurück, da sein Agent als Staging-Server
betrachtet wird.
Verschieben des Softwarekatalogs und des Scalability-Servers
Der Softwarekatalog ruft die Netzwerkadresse des Domänen-Managers, zu dem er eine
Verbindung herstellen soll, mit folgendem Konfigurationsparameter vom
Konfigurationsspeicher (Comstore) ab:
itrm/agent/units/./currentmanageraddress
Dieser Parameter wird jedes Mal ausgefüllt, wenn der Agent sich bei seinem ScalabilityServer registriert.
Wenn der Scalability-Server auf einen neuen Domänen-Manager verschoben wird, also
bei einem neuen Domänen-Manager registriert wird und die Registrierung beim
ursprünglichen Domänen-Manager aufgehoben wird, ist bei allen Agenten, die eine
Verbindung über diesen Scalability-Server herstellen, dieser Parameter solange auf die
Adresse des ursprünglichen Managers eingestellt, bis sich die Agenten wieder beim
Scalability-Server registrieren.
Daher funktioniert der Softwarekatalog erst dann wieder ordnungsgemäß, wenn der
Agent erneut registriert und dem oben genannten Konfigurationsparameter ein
entsprechender Wert zugewiesen wurde.
Woher weiß ich, ob die SD Agent Bridge läuft?
Woher weiß ich, ob die SD Agent Bridge läuft?
Symptom:
Ich muss überprüfen, ob die SD Agent Bridge tatsächlich läuft. Wie geht das?
Lösung:
Die SD Agent Bridge ist vollständig in den Scalability-Server von Software Delivery (SD)
integriert. Wenn der SD-Scalability-Server läuft und die Unterstützung der
Rückwärtskompatibilität aktiviert ist, wird die SD Agent Bridge ausgeführt.
Task-Manager kann nicht im gleichzeitigen Modus ausgeführt
werden
Symptom:
Ich habe den Task-Manager so konfiguriert, dass er im gleichzeitigen Modus ausgeführt
werden soll, dennoch wird der Task-Manager weiterhin im nicht gleichzeitigen Modus
ausgeführt.
Lösung:
Wenn der Task-Manager im nicht gleichzeitigen Modus ausgeführt wird, obwohl Sie Ihn
für den gleichzeitigen Modus konfiguriert haben, kann der Task-Manager den
Richtlinien-Manager und Replikations-Manager nicht starten. Sie müssen das TaskManager-Plug-In (sdmgr_tm) erneut starten, um den Task-Manager im gleichzeitigen
Modus auszuführen.
Sie können den Task-Manager über den DSM-Explorer neu starten. Klicken Sie dazu im
Portlet "Tasks" auf die Verknüpfung "Engine beenden" (Systemsteuerung, Engine, Alle
Engines, Systemlieferungs-Engine) und klicken Sie anschließend auf "Engine starten",
um den Task-Manager erneut zu starten. Sie können auch den CAF-Befehl verwenden,
um den Task-Manager erneut zu starten. Detaillierte Informationen zu diesem Fehler
finden Sie in der Datei "TRC_USD_TASKMAN.log".
Wenn diese Probleme wiederholt auftreten, wenden Sie sich an den Technischen
Support von CA.
Installations-Manager kann nicht im gleichzeitigen Modus ausgeführt werden
Installations-Manager kann nicht im gleichzeitigen Modus
ausgeführt werden
Symptom:
Ich habe den Installations-Manager so konfiguriert, dass er im gleichzeitigen Modus
ausgeführt werden soll, dennoch wird der Task-Manager weiterhin im nicht
gleichzeitigen Modus ausgeführt.
Lösung:
Wenn der Installations-Manager im nicht gleichzeitigen Modus ausgeführt wird, obwohl
Sie Ihn für den gleichzeitigen Modus konfiguriert haben, kann der Installations-Manager
den Benachrichtigungs-Manager nicht starten. Sie müssen das Installations-ManagerPlug-In (sdmgr_im) erneut starten, um den Installations-Manager im gleichzeitigen
Modus auszuführen. Sie müssen den CAF-Befehl verwenden, um den InstallationsManager neu zu starten. Detaillierte Informationen zu diesem Fehler finden Sie in der
Datei "TRC_USD_INSTMAN.log".
Wenn diese Probleme wiederholt auftreten, wenden Sie sich an den Technischen
Support von CA.
apt-Befehle für die Bereitstellung
apt-Befehle für die Bereitstellung
Um die Wrapper-Pakete bereitzustellen, verwendet CA ITCM die folgenden apt-Befehle:
■
Installieren des Wrapper-Pakets:
apt-get -y install <Pk1> <PK2> <PK3>
■
Neuinstallieren des Wrapper-Pakets:
apt-get --reinstall -y install <Pk1> <PK2> <PK3>
■
Deinstallieren des Wrapper-Pakets:
apt-get -y purge <Pk1> <PK2> <PK3>
Um die Add-On-Prozeduren im CA DSM-Agent-Add-On für das Debian-Spiegelpaket auf
den Repository-Clients bereitzustellen, verwendet CA ITCM die folgenden Befehle:
■
AutoRemove-Abhängigkeiten:
apt-get -y autoremove
■
Bereinigen des lokalen Cache:
apt-get clean
■
Aktualisieren des Cache:
apt-get update
■
Durchführen von Upgrades für Debian-Pakete:
apt-get -y upgrade
Löschen von RAL-Datensätzen aus der MDB
Löschen von RAL-Datensätzen aus der MDB
Um veraltete RAL-Datensätze aus der MDB zu löschen, rufen Sie den Befehl zum
Löschen von RALs auf. Dieser Befehl funktioniert komponentenweise und löscht die im
Befehl aufgelisteten Komponenten. Er kann unter den folgenden Bedingungen auch
Verteilungs- und Repository-Serverdetails löschen:
■
Wenn eine Verteilung nach dem Löschen von Komponenten leer ist
■
Wenn ein Repository-Server nach dem Löschen von Verteilungen keine
Verteilungen aufweist
Beispiel: Die Lenny-Verteilung weist zwei Komponenten (testing und main) auf, die von
der RAL-Engine-Task extrahiert werden. Um die Datensätze in der Testkomponente zu
entfernen, entfernen oder deaktivieren Sie die Synchronisierungs-Engine-Tasks mithilfe
von DSM-Explorer, und rufen Sie den Löschbefehl manuell für den %RALHOME%-Ordner
auf:
java -jar ral.jar -purge ftp://testing-i25361/debian/ lenny testing MASTER DEBIAN
"Enterprise Debian Repository"
Dieser Befehl hat das folgende Format:
java -jar ral.jar -purge -uri uri -distribution distribution -component component
-type type -format format -name repository name -desc description -log log path
URI
Gibt den URI des Debian-Repository-Servers an.
Beispiel:
RAL.jar -purge –uri ftp://testing-i25361/debian/ -distribution lenny –component
testing –type MASTER –format DEBIAN –desc "Enterprise Debian Repository"
Distribution
Gibt die Verteilung an, die die Komponente enthält, die Sie löschen möchten. Sie
können diesen Parameter nur verwenden, wenn das Format DEBIAN ist.
Komponente
Gibt die Komponente an, die Sie löschen möchten. Verwenden Sie Kommas, um
mehrere Komponenten zu trennen.
Typ
Gibt den Typ des Repository als Master-Repository oder Spiegel an.
Format
Gibt das Repository-Format an.
Gültiger Wert: DEBIAN
Registrierung des Legacy-Agenten schlägt fehl
Name
Gibt den Repository-Servernamen der Komponente an, die Sie löschen möchten.
Der Name muss mit dem Repository-Namen in der Repository-Konfigurationstabelle
übereinstimmen.
Beschreibung
(Optional) Gibt die Repository-Beschreibung in der Repository-Konfigurationstabelle
an.
Protokoll
(Optional) Legt den Pfad der Protokolldatei fest. Wenn Sie keinen Pfad angeben,
wird im Ordner <DSM-Installationspfad>\logs eine Protokolldatei erstellt. Die
Protokolldatei für den Löschvorgang wäre RAL_purge_log.log.
Wichtig! Stellen Sie sicher, dass während des Löschvorgangs keine SynchronisierungsEngine-Tasks ausgeführt werden. Stellen Sie auch sicher, dass während des
Löschvorgangs Benutzer keine Wrapper-Pakete durchsuchen oder erstellen.
Registrierung des Legacy-Agenten schlägt fehl
Symptom:
Ich kann meinen Legacy-Agenten nach der Aktivierung von Agent Bridge nicht bei CA
ITCM registrieren.
Lösung:
Nach der Aktivierung Ihrer Agent Bridge-Konfigurationsrichtlinien müssen Sie einige
Minuten warten, bevor Sie Ihren Legacy-Agenten registrieren können.
Unicenter Software Delivery-Agent kann auf HP-UX System nicht gestartet werden
Unicenter Software Delivery-Agent kann auf HP-UX System
nicht gestartet werden
Symptom:
Ich habe in einer HP-UX 11.11-Betriebsumgebung, auf der CA ITCM mit aktivierter Agent
Bridge läuft, erfolgreich einen Unicenter Software Delivery 4.0 SP1-Agenten installiert.
Der Befehl "sdpgm start" schlägt jedoch fehl.
Lösung:
Die Ursache hierfür liegt darin, dass die Datei libcawinext.sl nicht im Pfad für die
Bibliothek der gemeinsam genutzten Komponenten gefunden wird. Um dieses Problem
zu lösen, erstellen Sie eine Verknüpfung für libcawinext.sl, so dass SHLIB_PATH (und
LD_LIBRARY_PATH) auf die Datei verweisen:
cd /opt/CA/SharedComponents/lib
ln -s /opt/CA/SharedComponents/cawin/lib/libcawinext.sl.0 libcawinext.sl
SHLIB_PATH=/opt/CA/UnicenterSoftwareDelivery/usd/lib:
/opt/CA/SharedComponents/lib:
/opt/CA/SharedComponents/lib
Jetzt können Sie den Unicenter Software Delivery-Agenten starten.
RAC-Containerjob fehlgeschlagen
Symptom:
Ich habe meinen Legacy-Agenten nach einem Absturz neu installiert und beim
Ausführen des RAC-Containerjobs die Meldung "Bereits installiert" erhalten.
Lösung:
Wenn ein Legacy-Agent nach einem Absturz neu installiert wird (RAC), kann die
Ausführung von Jobs in dem automatisch erstellten RAC-Container mit der Meldung
"Bereits installiert" fehlschlagen. In diesem Fall löschen Sie den RAC-Jobcontainer.
Anschließend ist der Agent wieder funktionsfähig.
Bereitstellung von Softwarepaketen für virtuelle Anwendungen schlägt fehl
Bereitstellung von Softwarepaketen für virtuelle Anwendungen
schlägt fehl
Symptom:
Wenn ich versuche, ein Softwarepaket für virtuelle Anwendungen bereitzustellen,
schlägt die Bereitstellung fehl und ich erhalten die folgende Fehlermeldung: "FEHLER
(Nummer) Installieren von Paket_Name ist fehlgeschlagen." Wie kann ich diesen Fehler
lösen?
Lösung:
Um einen Fehler zu beheben, der bei der Bereitstellung eines Softwarepakets für
virtuelle Anwendungen auftritt, führen Sie die folgenden Schritte aus:
1.
Navigieren Sie zu "Computer und Benutzer", "Alle Computer", "Computer_Name",
"Jobs", Ordner "Software-Jobs".
Der rechte Fensterbereich zeigt die verfügbaren Software-Delivery-Jobs an.
2.
Klicken Sie mit der rechten Maustaste auf den fehlgeschlagenen Job und wählen Sie
"Eigenschaften" aus.
Das Dialogfeld "Jobeigenschaften" wird angezeigt.
3.
Die Statusmeldung wird auf der Registerkarte "Computerjob" angezeigt.
4.
Öffnen Sie die Registerkarte "Jobausgabe". Die Trace-Informationen werden
angezeigt.
Hinweis: Es werden keine Trace-Informationen angezeigt, wenn die Bereitstellung
erfolgreich war.
5.
Scrollen Sie zum Abschnitt "Post-Programme werden gestartet".
Dieser Abschnitt zeigt Informationen an, die sich auf die Installation von Paketen
mit virtueller Anwendung beziehen.
Bereitstellung von Softwarepaketen für virtuelle Anwendungen schlägt fehl
6.
Der Rückgabecode für Post-Programme wird angezeigt. Die folgende Liste enthält
alle Rückgabecodes und deren Bedeutung:
-1
Interner Fehler mit ungültigen oder unvollständigen Parametern (Installationsskript
nicht ausgeführt)
0
Erfolgreicher Abschluss (kein Fehler)
1
Der Prozess konnte die DSM-Installation nicht finden (Dateien, Verzeichnisse,
Registrierungsschlüssel oder Umgebung wurden nicht gefunden)
2
Der Prozess konnte Dateien oder Ordner nicht erstellen oder entfernen.
3
Der Prozess konnte die für das Paket erforderlichen Dateien nicht finden (zum
Beispiel Datei "sft" für Microsoft App-V-Pakete).
4
Erstellen oder Entfernen von Netzwerkfreigaben ist fehlgeschlagen
5
Der Prozess konnte App-V-Dienste nicht starten.
6
Die Ausführung von "sftmime.exe" (App-V) oder "ThinReg.exe" (VMware ThinApp)
ist fehlgeschlagen. Diese erforderlichen Tools erstellen oder entfernen
Verknüpfungen (Symbole) auf dem Desktop und Einträge unter "Start" >
"Programme".
7
Die Verbindung zum ThinApp-Streaming-Server ist fehlgeschlagen.
7.
Die Befehlszeile, die den Bereitstellungsfehler ausgelöst hat, wird im Abschnitt
"Aktionsausgabe" der Trace-Informationen angezeigt. Scrollen Sie nach rechts, um
die Befehlszeilenparameter und den Rückgabecode anzuzeigen.
8.
Stellen Sie die Ursache für den Fehler fest und lösen Sie das Problem.
9.
Stellen Sie das Softwarepaket für virtuelle Anwendungen erneut bereit.
Netzwerkinstallation des MSI-Pakets schlägt fehl
Netzwerkinstallation des MSI-Pakets schlägt fehl
Symptom:
Wenn ich eine Netzwerkinstallation eines MSI-Pakets unter Windows Server 2008
ausführe, schlägt die Installation mir einem Fehler "1619: Dieses Installationspaket
konnte nicht geöffnet werden" fehl. Wie kann ich das beheben?
Lösung:
Die Netzwerkinstallation eines MSI-Paketes schlägt mit dem Fehlercode "1619: Dieses
Installationspaket konnte nicht geöffnet werden" fehl, wenn sowohl der ScalabilityServer als auch der Agent unter Windows Server 2008-, Windows Vista SP2-, oder
Windows 7-Betriebsumgebungen installiert und Teil einer WORKGROUP und nicht einer
Domäne sind.
Um eine Netzwerkinstallation eines MSI-Paketes erfolgreich auszuführen, deaktivieren
Sie SMB2.0 und starten Sie den Scalability-Server neu.
Um SMB2.0 auf dem Scalability-Server zu deaktivieren, gehen Sie wie folgt vor:
1.
Öffnen Sie den Registrierungseditor und navigieren Sie nach HKLM, System,
CurrentControlSet, Services, LanmanServer, Parameters.
2.
Erstellen Sie einen DWORD-Wert und nennen Sie ihn "smb2"
3.
Um SMB2.0 zu deaktivieren, setzen Sie den Wert von smb2 auf 0.
Hinweis: Um SMB2.0 zu aktivieren, setzen Sie den Wert auf 1.
4.
Starten Sie den Scalability-Server neu.
SMB2.0 ist auf dem Scalability-Server deaktiviert.
Nicht durchgeführter Start des SD-Agents nach einem CAF-Neustart
Nicht durchgeführter Start des SD-Agents nach einem CAFNeustart
Gültig unter Windows und UNIX
Symptom:
Wenn Sie CAF starten, wird der SD-Agent nicht automatisch initiiert. Daher wird die SDJobprüfung beim CAF-Neustart nicht ausgeführt.
Lösung:
Tun Sie Folgendes:
■
Ändern Sie im CAF-Scheduler den Standardwert des Felds "Zufällige Jetztzeit" auf
0 Sekunden.
■
Stellen Sie sicher, dass der Standardwert der Konfigurationsrichtlinie "CAF:
Registrierung bei Start aktivieren" auf "Wahr" festgelegt ist.
Hinweis: Unter UNIX führt "CAF register" nicht alle Plug-ins aus. Verwenden Sie den
Befehl "CAF register all", um alle Plug-ins auszuführen.
Kein vorab ausgeführtes Seeding der Variablen in "debconf"Parametern
Während der Bereitstellung führt der Software Delivery-Agent vorab ein Seeding der
"debconf"-Parameter mit den von Ihnen während der Erstellung von Wrapper-Paketen
angegebenen Werten durch. Der Agent führt kein Seeding für die "debconf"-Parameter
vorab durch, wenn Sie ihnen Variablen wie ${choices} zuweisen.
Führen Sie die folgenden Schritte aus, um für eine Variable mit bekannten Werten vorab
ein Seeding durchzuführen:
1.
Navigieren Sie zu "DSM-Explorer", "Computer", "Software",
"Softwarepaketbibliothek", "Alle Software-Programme", Debian-Wrapper-Paket,
"Quelle", Neues Volume, "debWrpMetadata.wdp".
2.
Doppelklicken Sie auf die WDP-Datei, und bearbeiten Sie sie.
Fehler bei der Installation von Debian-Wrapper-Paketen
Symptom:
Bei der Installation eines Debian-Wrapper-Pakets wird bei einer fehlerhaften Installation
der folgende Fehler angezeigt:
WARNING: The following packages cannot be authenticated! (WARNUNG: Die
folgenden Pakete können nicht authentifiziert werden!)
Lösung:
Führen Sie einen der folgenden Schritte aus:
■
Erstellen Sie eine Konfigurationsdatei für APT-Befehle, damit nicht authentifizierte
Pakete installiert werden können. Fügen Sie auf dem Agentencomputer den
folgenden Text einer der APT-Konfigurationsdateien hinzu, oder erstellen Sie eine
neue Datei unter /etc/apt/apt.conf.d:
APT {
Get {
AllowUnauthenticated "true";
};
}
■
Importieren Sie den öffentlichen Schlüssel auf dem Agentcomputer mithilfe des
Befehls "apt-key add". Erstellen Sie für einen umfangreichen Import ein Software
Delivery-Paket.
Symptom:
Bei der Installation eines Debian-Wrapper-Pakets traten Fehler auf.
Lösung:
Tun Sie Folgendes:
■
Stellen Sie sicher, dass weder die Paketgröße noch der Hash durch die Indexdatei
geändert werden.
■
Stellen Sie sicher, dass das Paket in den Repositorys vorhanden ist, die in
"sources.list" erwähnt werden.
■
Stellen Sie sicher, dass die gesamte Paketabhängigkeit erfüllt ist.
■
Stellen Sie sicher, dass während der Installation keine Laufzeitfehler auftreten.
Der SD-Job hängt und die Meldung wird nicht angezeigt
Symptom:
Wenn ich das Paket "Interactive DM Script SD" bereitstelle, dann hängt die SD-JobÜberprüfung, und das Meldungsfeld wird nicht angezeigt.
Lösung:
Sie können dies auf eine der folgenden Weisen beheben:
Bearbeiten von itemproc.dat des SD-Pakets:
Wenn ein DM-Skript an einen Agenten als Teil des SD-Jobs, der ein interaktives Fenster
hat, übergeben wird, dann fügen Sie das Flag "w_dms" zu den Vorgangsoptionen des
Pakets hinzu.
1.
Öffnen Sie die Datei "itemproc.dat" im Paket, und identifizieren Sie die
Vorgänge, die interaktiv sind.
2.
Gehen Sie zum Abschnitt [ItemprocX] (X ist die Zahl des interaktiven Vorgangs).
3.
Ändern Sie den Parameterschlüssel, und hängen Sie den Wert "-w_dms" an das
Ende an.
Verwenden der Vorgangseigenschaften von DSM-Explorer:
1.
Klicken Sie im Installierungsvorgang des interaktiven Pakets mit der rechten
Maustaste auf den Vorgangsnamen, und navigieren Sie zur Registerkarte
"Eigenschaften", "Eingebettete Datei", "Parameter".
2.
Fügen Sie "-w_dms" hinzu.
SD-Job ist erfolgreich, und das Meldungsfeld wird angezeigt.
Windows-Erkennung für interaktive Services sperrt Agenten
Windows-Erkennung für interaktive Services sperrt Agenten
Nur Windows
Symptom:
Wenn ich ein interaktives Softwarepaket mithilfe der Windows-Erkennung für
interaktive Services bereitstelle, wird der Agent gesperrt, wenn sich die Sitzung länger
als eine Minute im Leerlauf befindet.
Lösung:
Die Ursache für dieses Verhalten sind die Einschränkungen von Betriebssystemen wie
Windows Vista und höher. Um mit der Bereitstellung fortzufahren, melden Sie sich
erneut an, und wählen Sie die Sitzung 0.
Fehlender "DebWrap"-Pakettyp in DSM-Reporter
Der Softwarepakettyp für Debian-Wrapper-Pakete wird durch eine numerische 10
bestimmt und nicht in Form von "DebWrap" als Pakettyp.
Fehlerhafter Abbruchsbefehl während der Neuinstallation von
VDI-Komponenten
Symptom:
Bei der Verwendung der Befehlszeile zum Abbrechen einer Neuinstallation der VDIKomponenten wird der Abbruchsprozess nicht initiiert.
Lösung:
Sie können nicht gleichzeitig mehrere Instanzen des SD-Agents initiieren. Brechen Sie
die Neuinstallation ab, indem Sie auf die Schaltfläche "Abbrechen" im Dialogfeld
"Agent" klicken.
Anhang A: Unterstützung und Lokalisierung
eines Nicht-UTF-8-Gebietsschemas
UTF-8- und MBCS-Codierung (siehe Seite 221)
Lokalisierung und UTF-8-Codierung (siehe Seite 222)
Unterstützung des Nicht-UTF-8-Gebietsschemas (siehe Seite 222)
Überlegungen zum Scalability-Server (siehe Seite 222)
UTF-8- und MBCS-Codierung
UTF-8 (8-Bit Unicode Transformation Format) ist eine Methode zur Codierung von
Zeichen, so dass jedes beliebige Zeichen mit einer variablen Anzahl von Byte dargestellt
werden kann. Unter Unix wird das Format wie jeder andere Multibyte-Zeichensatz
behandelt und ist abwärtskompatibel mit dem ASCII-Zeichensatz.
CA ITCM-Code wird unter Linux und UNIX in der Regel in einem UTF-8-Gebietsschema
ausgeführt. Dies führt zu Problemen mit dem Betriebssystem, wenn das Betriebssystem
ein Nicht-UTF-8-Gebietsschema verwendet. Sämtlicher Code, der mit dem
Betriebssystem verknüpft ist, wie beispielsweise Dateinamen, Befehlszeilenparameter
usw. wird zwischen dem MBCS-Gebietsschema des Systems und UTF-8 konvertiert.
Ein Multibyte-Zeichensatz (MBCS) verwendet 1 oder 2 Byte pro Zeichen und wird für
Zeichensätze mit sehr vielen verschiedenen Zeichen eingesetzt (zum Beispiel asiatische
Zeichensätze).
Anhang A: Unterstützung und Lokalisierung eines Nicht-UTF-8-Gebietsschemas 221
Lokalisierung und UTF-8-Codierung
Lokalisierung und UTF-8-Codierung
Die einzige Möglichkeit einer erfolgreichen Lokalisierung besteht darin, dass alle
beteiligten Computer UTF-8-Codierung oder exakt dasselbe Gebietsschema verwenden.
Dies gilt für die gesamte Kette, vom Manager über den Scalability-Server bis hin zum
Agenten. Daher sollte UTF-8 überall verwendet werden. Anderenfalls könnte das
Senden von Jobs mit Dateien und Verzeichnissen, die National Language Characters
(NLCs) enthalten, fehlschlagen.
Bei Linux-Versionen, die das CIFS-Dateisystem nicht unterstützten, funktioniert das
Samba-Protokoll möglicherweise nicht ordnungsgemäß, wenn auf Dateien und
Verzeichnisse zugegriffen werden soll, die NLCs enthalten. Jobs, die die Dateifreigaben
erfolgreich mounten konnten, schlagen daher möglicherweise fehl, weil sie nicht auf
Dateien und Verzeichnisse zugreifen können, die NLCs enthalten. Software Delivery
erkennt automatisch, ob CIFS verfügbar ist und verwendet es wenn immer möglich.
SuSE 9 ES und RedHat 4 unterstützen CIFS, SuSE 9 Pro und RedHat 3.x jedoch nicht.
Unterstützung des Nicht-UTF-8-Gebietsschemas
Die Unterstützungsfunktion für Nicht-UTF-8-Gebietsschemas bietet interne
Hilfsprogramme, mit denen Probleme mit National Language Characters (NLCs) bei der
Lokalisierung unter Linux und UNIX gelöst werden können.
National Language Characters sind spezielle Zeichen eines bestimmten Gebietsschemas.
Überlegungen zum Scalability-Server
Die folgende Liste bietet Hinweise für die Verwendung von Scalability-Servern unter
besonderen Bedingungen:
■
Wenn auf einem Scalability-Server mit einem Nicht-UTF-8-System Samba
verwendet wird, muss er unbedingt ordnungsgemäß konfiguriert sein. (YaST2 in
SuSE ist hierfür ungeeignet). Äußerst wichtig ist, dass die Einstellung "unix charset"
korrekt festgelegt ist (im Abschnitt "global" der Datei "smb.conf"). Ein guter Wert
ist möglicherweise "iso8859–15", der für alle westlichen Gebietsschemas geeignet
ist. Wenn Sie diese Einstellung vergessen, werden alle Dateien angezeigt. Wenn
jedoch ein Verzeichnisname selbst National Language Characters (NLCs) enthält,
können Sie das Verzeichnis zwar anzeigen und aufrufen, jedoch keine darin
enthaltenen Dateien anzeigen. Aus der Sicht des Benutzers schlagen die Jobs fehl.
Sobald Sie eine derartige Einstellung geändert haben, müssen Sie unbedingt Samba
neu laden.
■
Wenn ein Linux-Scalability-Server für die Verwendung von NFS und Samba
konfiguriert wurde, verwenden die Agenten immer Samba. Verwenden Sie auf dem
Scalability-Server die Befehle "sd_sscmd addshare" bzw. "sd_sscmd removeshare",
um dies entsprechend einzurichten.
■
Samba und NFS werfen hinsichtlich der Datei- und Verzeichnisnamen
unterschiedliche Probleme auf. Samba verfügt über einen internen Mechanismus,
der Datei- und Verzeichnisnamen automatisch zuordnet, wenn wir (als Agent)
Samba mitteilen, dass UTF-8 (oder nicht UTF-8) verwendet wird. Die
Namenszuordnung wird automatisch durchgeführt. NFS bietet dies nicht, was zu
Problemen führen kann, wenn zum Beispiel ein Nicht-UTF-8-Agent mit einem UTF8-Scalability-Server verbunden wird (oder umgekehrt) und dann der Zugriff auf
Datei- und Verzeichnisnamen mit NLCs versucht wird. Leider gibt es keine
Möglichkeit, dieses Problem zu umgehen (außer der, Samba statt NFS zu
verwenden).
■
Auf einem Scalability-Server, auf dem die Samba-Dateifreigabe verwendet wird,
sollte der Bibliothekszugriff (sd_sscmd libraryaccess …) ordnungsgemäß
eingerichtet werden, damit Linux-Agenten mit CIFS auf die Samba-Dateifreigabe
zugreifen können.
Dieses Problem ist mit der Einstellung für die Samba-Sicherheitskonfiguration
verknüpft. Wenn die Agenten versuchen, die Freigabe auf den Scalability-Server mit
CIFS zu mounten, funktioniert dies nur als Gast-Benutzer (der Standardeinstellung,
wenn kein Bibliothekszugriff bereitgestellt wurde), wenn der Samba-ScalabilityServer für die Verwendung von Sicherheit auf freigegebener Ebene konfiguriert
wurde.
Wenn der Samba-Scalability-Server jedoch für die Verwendung eines anderen
Sicherheitstyps, wie beispielsweise der Sicherheit auf Benutzerebene, konfiguriert
wurde, funktioniert das Mounten mit CIFS als anonymer Benutzer nicht, da ein
expliziter Benutzer sowie das entsprechende Kennwort erforderlich sind. Darüber
hinaus muss der Benutzer mit dem Befehl "smbpasswd -a" der SambaBenutzerdatei hinzugefügt worden sein.
Der Grund, weshalb die Verwendung von CIFS wenn möglich erzwungen werden
soll ("mount -t cifs"), ist, dass NLCs besser verarbeitet werden können als mit SMB
("smbmount").
Wir empfehlen den Administratoren, ihre Scalability-Server folgendermaßen zu
konfigurieren:
■
sd_sscmd libraryaccess …
Hiermit werden die Anmeldeinformationen für Software Delivery eingerichtet,
die beim Senden von Jobs an Agenten verwendet werden.
■
smbpasswd -a …
Hiermit werden die Anmeldeinformationen in Samba selbst eingerichtet.
Anhang A: Unterstützung und Lokalisierung eines Nicht-UTF-8-Gebietsschemas 223
■
Öffnen Sie die Datei "smb.conf" mit Hilfe eines Editors, und entfernen Sie die
Zeile "guest ok = Yes" auf den Freigaben "sdlibrary" und "sdmsilib" (bzw.
kommentieren Sie sie aus). Darüber hinaus sollten Sie die
Sicherheitseinstellung (im Abschnitt "global") aus Sicherheitsgründen nicht auf
"share" (die Standardeinstellung) sondern auf "user" (oder höher) setzen. Die
genaue Bedeutung aller Samba-Scalability-Servereinstellungen finden Sie auf
der Seite "manl" der Datei "smb.conf".
■
Laden Sie Samba folgendermaßen neu:
/etc/init.d/smb reload
Die neuen Einstellungen werden aktiviert.
Hinweis: Wenn dieser Konfigurationsschritt nicht durchgeführt wird, funktionieren
die Jobs wahrscheinlich trotzdem, da sich die Fallback-Lösung, der
Transportmechanismus "Intern - ohne NOS" einschaltet "Intern - ohne NOS" ist
möglicherweise nicht so effizient wie "Intern - NOS", funktioniert aber dennoch.
Zu den Linux-Systemen, die anscheinend ohne weitere Konfigurationsmaßnahmen
funktionieren, gehört SuSE 9 ES. Zu den Linux-Systemen, die konfiguriert werden
müssen, gehören RedHat 3 ES und RedHat 4 ES.
Anhang B: Importieren von
Abfragezeichenfolgen aus Unicenter
Software Delivery 4.0
Übersicht (siehe Seite 225)
Einschränkungen beim Importieren von Abfragen (siehe Seite 226)
Importieren von Ausdrücken, die BS-Sicherheits- oder Verzeichnisabfragen enthalten
(siehe Seite 228)
Importieren von Ausdrücken mit Hilfe von IN und NOT IN-Operatoren (siehe Seite 229)
Importieren von Ausdrücken ohne IN und NOT IN-Operatoren (siehe Seite 229)
Importieren von Ausdrücken ohne IN und NOT IN-Operatoren (siehe Seite 230)
Übersicht
CA ITCM verwendet Unicenter Software Delivery 4.0-formatierte Abfragezeichenfolgen
in folgenden Bereichen, um die Rückwärtskompatibilität zu unterstützen:
Befehlszeilenschnittstelle
Der Befehl zum Erstellen von Computergruppen akzeptiert Unicenter Software
Delivery 4.0-formatierte Abfragezeichenfolgen, um dynamische Gruppen zu
erzeugen.
Softwarepakete
Beim Importieren von Software-Paketen mit in Unicenter Software Delivery 4.0
erstellten Prozedurvoraussetzungen werden formatierte Abfragezeichenfolgen
akzeptiert.
Software-Packager
Der Software-Packager von CA ITCM verwendet Unicenter Software Delivery 4.0formatierte Abfragezeichenfolgen, um Prozedurvoraussetzungen für die von ihm
generierten Software-Pakete zu erstellen.
Hinweis: In allen oben genannten Bereichen werden aufgrund bestimmter
Einschränkungen beim Abfrageimport benutzerdefinierte Abfragen im
Abfrageuntersystem von CA ITCM erstellt. Zusätzlich werden Abfragen, die mit Hilfe der
Migrationstools von Version 4.0 zu Unicenter DSM r11.x migriert wurden, als
benutzerdefinierte Abfragen importiert.
Anhang B: Importieren von Abfragezeichenfolgen aus Unicenter Software Delivery 4.0 225
Einschränkungen beim Importieren von Abfragen
Software Delivery verwendet in gewissen Fällen Abfragen, um das Management von
Assets zu automatisieren. Ab Unicenter DSM-Version 11 ersetzt ein neuer
Abfragemechanismus, der für alle DSM-Komponenten gleich ist, das Abfrage-Subsystem
der Version 4.0. Das neue SQL-basierte Abfrageverfahren bietet im Vergleich zum
vorherigen codebasierten Evaluierungsverfahren Leistungsvorteile. Außerdem ersetzt
ab Unicenter DSM r11 ein neuer Basis-Hardware-Inventar-Mechanismus, der für alle
DSM-Komponenten gleich ist, das Inventarmodul von Unicenter Software Delivery 4.0.
Dieses neue Basis-Hardware-Inventarmodul bietet genauere Inventardaten. Jedoch
werden einige Attribute aus Unicenter Software Delivery 4.0 nicht vom CA ITCMInventarmodul erfasst.
Diese Änderungen haben folgende bedeutende Auswirkungen auf Abfrageimporte:
Abfrageattribute
Wenn Sie eine 4.0-formatierte Abfragezeichenfolge in CA ITCM importieren, ist es
nicht möglich, alle Abfrageattribute den entsprechenden CA ITCM-Attributen
zuzuordnen. CA ITCM importiert ungültige Abfragen, bei denen leere Ausdrücke zur
Information für den Benutzer als ungültig markiert sind. Sie müssen diese Abfragen
bearbeiten, bevor Sie einen Importvorgang durchführen.
Computerbenutzer
Das Abfrageuntersystem von CA ITCM erkennt Computer und Benutzerprofile als
einzelne Zieltypen für Abfragen. Dies bedeutet, dass eine Abfrage entweder eine
Gruppe von Computern oder Benutzerprofilen, aber nicht beides, zurückgeben
kann. In Version 4.0 wurden Computer und Benutzerprofile durch einen Zieltyp
dargestellt, so dass eine Abfrage sowohl Computer als auch Benutzerprofile
zurückgeben konnte. Wenn Sie eine 4.0-formatierte Abfragezeichenfolge in CA
ITCM importieren, bleibt die Möglichkeit, Computer und Benutzerprofile
zurückzugeben, durch Erstellen einer benutzerdefinierten Abfrage erhalten. Bei
benutzerdefinierten Abfragen handelt es sich um reine SQL-Anweisungen, die mit
der Abfrageerstellungsfunktion des Abfrage-Designers nicht direkt kompatibel sind.
Daher müssen, anstatt der Verwendung der Funktion "Argument einfügen",
benutzerdefinierte Abfragen über die Funktion "SQL bearbeiten" des AbfrageDesigners geändert werden.
Platzhalterzeichen
In CA ITCM werden SQL-Platzhalter verwendet; der Operator LIKE ersetzt den
Operator MATCH aus Unicenter Software Delivery 4.0, und alle anderen
Platzhalterzeichen werden, sofern möglich, ihren SQL-Entsprechungen zugeordnet.
Jedoch besitzen einige Platzhalterzeichen wie etwa "?", "+" und "|" keine SQLEntsprechung; das Einstellen der Negation *^ ….+ wird nicht unterstützt und führt zu
einer ungültigen Abfrage.
Attributwerte
Einige Attributwerte wurden in CA ITCM geändert. In zahlreichen Fällen ist eine
einfache Zuordnung möglich, um die alten Version 4.0-Werte in neue Werte zu
konvertieren, die in den Abfragen für die neuen Werte eingebettet sind. In anderen
Fällen ist dies nicht möglich, da die Anzahl der in CA ITCM und in Version 4.0
verwendeten Werte nicht übereinstimmt; in einigen Fällen kann ein "=" oder "<>"
verwendet werden, wobei LIKE und andere Platzhalter dem alphanumerischen
Zeichen hinzugefügt werden. Hier erzeugen andere Operatoren als "=" oder "<>'"
eine ungültige Abfrage.
Diese Einschränkung gilt insbesondere für die Zielattributgruppe mit Attributwerten
wie "Machine" (Rechner), "Staging Server" (Staging-Server), "Domain" (Domäne)
und "UserId" (Benutzer-ID), aber auch für die Namensattribute der Attributgruppen
"SDAttr_OS2", "SDAttr_WinNT", "SDAttr_WinCE", "SDAttr_unix", "SDAttr_Win9X",
"SDAttr_Netware" und "SDAttr_VMS".
Beim Attribut "Type" (in der Zielattributgruppe) mit den Werten "Machine" und
"Staging Server" ist das Abfrageverhalten in Unicenter Software Delivery 4.0 und CA
ITCM unterschiedlich. Dies liegt daran, dass in Version 4.0 der Agent auf dem
lokalen Server den Typ "Machine" hatte, während der Agent auf dem DomänenManager in CA ITCM den Wert "Staging Server" hat.
Abfrageergebnisse
In Unicenter Software Delivery 4.0 gibt eine Abfrage des Typs
"Target.Type='Machine'" alle Agenten (keine Staging-Server) einschließlich des
Agenten des lokalen Servers zurück. Wenn diese Abfrage in CA ITCM importiert
wird, gibt sie nur eigenständige Agenten zurück (Agenten, die über keinen
Scalability-Server oder Domänen-Manager auf demselben Rechner verfügen).
In Unicenter Software Delivery 4.0 gibt eine Abfrage des Typs "Target.Type='Staging
Server'" alle Staging-Server zurück. Wenn diese Abfrage in CA ITCM importiert wird,
gibt sie auch den Domänen-Manager zurück, da sein Agent als Staging-Server
betrachtet wird.
Importieren von Ausdrücken, die BS-Sicherheits- oder Verzeichnisabfragen enthalten
Importieren von Ausdrücken, die BS-Sicherheits- oder
Verzeichnisabfragen enthalten
Wenn Sie eine im Format der Unicenter Software Delivery-Version 4.0 formatierte
Abfragezeichenfolge importieren, die die NT-Gruppenquelle oder die Verzeichnisquelle
enthält, werden den URI-Zeichenfolgen Autoritäten hinzugefügt. Sie sind
Computernamen für die lokalen Berechtigungen, die mit der NT-Gruppe und den mit
dem Verzeichnis verwendeten Verzeichnisautoritäten verknüpft sind. Diese Autoritäten
können in der neuen Umgebung inkorrekt sein, in der Sie den Manager verwenden. In
diesem Fall können Sie die Abfrage nach dem Importieren bearbeiten und den Namen
der Autorität ändern.
Öffnen Sie zum Ändern des Autoritätsnamens das Eigenschaften-Dialogfeld der Abfrage,
klicken Sie mit der rechten Maustaste auf das SQL-Fragment und wählen Sie die Option
"SQL bearbeiten". Ersetzen Sie den Namen der Autorität durch den richtigen Namen.
Importieren von Ausdrücken mit Hilfe von IN und NOT IN-Operatoren
Importieren von Ausdrücken mit Hilfe von IN und NOT INOperatoren
Die IN/NOT IN-Operationen der Unicenter Software Delivery-Version 4.0 beinhalten die
Verwendung eines "Plugins" zur Bereitstellung eines Satzes von Werten anstatt des
einzelnen Literals, das für die anderen Operationen verwendet wird. Die Unicenter
Software Delivery-Version 4.0 Plugin-Quellen und ihre entsprechenden Funktionen in CA
ITCM sind wie folgt:
■
SDGroup (SD-Gruppe)
■
NTGroup
■
AMOQuery
■
DirectoryService
Die SDGroup Funktionalität "Plugin" wird von CA ITCM-Standard-Abfragen
bereitgestellt, die Computergruppendefinitionen verwenden.
NTGroup wird mit Hilfe der Directory Services-Funktion von CA ITCM-Abfragen
implementiert. Die zulässige Attributgruppe ist "Target", und die zulässigen Attribute in
der Gruppe sind "User" und "UserId".
Die zulässige Attributgruppe für IN/NOT IN-Prüfungen auf Sätze, die von Directory
Services-Abfragen generiert wurden, ist "Ziel", und die zulässigen Attribute in dieser
Gruppe sind "Benutzer", "Benutzer-ID", "Name", "Server" und "Computer".
Die zulässige Attributgruppe für IN/NOT IN-Prüfungen auf Sätze, die mit der
Abfrageintegration in Asset Management der Unicenter Software Delivery-Version 4.0
generiert wurden, ist "Ziel", und die zulässigen Attribute in dieser Gruppe sind
"Benutzer", "Benutzer-ID", "Name", "Server" und "Computer".
Importieren von Ausdrücken ohne IN und NOT IN-Operatoren
Die folgende Tabelle listet die unterstützten und nicht unterstützten Attribute in jeder
Attributgruppe auf, die keine Ausdrücke enthalten, die IN/NOT IN-Operatoren
verwenden. Die nicht unterstützten Attribute werden nicht erfolgreich importiert:
Die folgende Tabelle listet die unterstützten und nicht unterstützten Attribute in jeder
Attributgruppe auf, die keine Ausdrücke enthalten, die IN/NOT IN-Operatoren
verwenden. Die nicht unterstützten Attribute werden nicht erfolgreich importiert:
Attributgruppe
Unterstützte
Attribute
Nicht unterstützte Attribute
SDAttr_AgentConfig
Nicht zutreffend
Status
SDAttr_AgentConfig
LibraryAccess
Nicht zutreffend
SDAttr_AgentConfig
Nicht zutreffend
PalmSupport
SDAttr_AgentConfig
Nicht zutreffend
WinCESupport
SDAttr_AgentConfig
Nicht zutreffend
NokiaSupport
SDAttr_AgentConfig
Nicht zutreffend
UserAgent
SDAttr_AgentConfig
Nicht zutreffend
LogonShield
SDAttr_AgentConfig
Nicht zutreffend
LogoffPolicy
SDAttr_AgentConfig
Nicht zutreffend
operationalMode
SDAttr_LogonShield
Nicht zutreffend
Status
SDAttr_LastUpdated
Datum
Nicht zutreffend
SDAttr_LastUpdated
Nicht zutreffend
Uhrzeit
SDAttr_Win3x
Nicht zutreffend
Name
SDAttr_Win3x
Nicht zutreffend
Version
SDAttr_Win3x
Nicht zutreffend
StartupFreeMem
SDAttr_Win3x
Nicht zutreffend
Modus
SDAttr_Win3x
Nicht zutreffend
Locale
SDAttr_Win3x
Nicht zutreffend
ANSI_CP
SDAttr_Win3x
Nicht zutreffend
OEM_CP
SDAttr_OS2
Name
Nicht zutreffend
SDAttr_OS2
Version
Nicht zutreffend
SDAttr_OS2
Nicht zutreffend
StartingFreeMemory
SDAttr_WinNT
Name
Nicht zutreffend
SDAttr_WinNT
Version
Nicht zutreffend
SDAttr_WinNT
Nicht zutreffend
StartupFreeMem
Attributgruppe
Unterstützte
Attribute
SDAttr_WinNT
Nicht zutreffend
Locale
SDAttr_WinNT
Nicht zutreffend
ANSI_CP
SDAttr_WinNT
Nicht zutreffend
OEM_CP
SDAttr_WinNT
Nicht zutreffend
Build
SDAttr_WinNT
ServicePack
Nicht zutreffend
SDAttr_WinNT
Nicht zutreffend
Typ
SDAttr_WinCE
Name
Nicht zutreffend
SDAttr_WinCE
Version
Nicht zutreffend
SDAttr_WinCE
Nicht zutreffend
StartupFreeMem
SDAttr_WinCE
Nicht zutreffend
Locale
SDAttr_WinCE
Nicht zutreffend
ANSI_CP
SDAttr_WinCE
Nicht zutreffend
OEM_CP
SDAttr_WinCE
Nicht zutreffend
Build
SDAttr_WinCE
Nicht zutreffend
ServicePack
SDAttr_WinCE
Nicht zutreffend
Typ
SDAttr_WinCE
Nicht zutreffend
DeviceName
SDAttr_WinCE
Nicht zutreffend
OriginalDeviceName
SDAttr_WinCE
Nicht zutreffend
ProxyName
SDAttr_Unix
Name
Nicht zutreffend
SDAttr_Unix
Nicht zutreffend
Version
SDAttr_Unix
Nicht zutreffend
Locale
SDAttr_Unix
Nicht zutreffend
ANSI_CP
SDAttr_Unix
Nicht zutreffend
OEM_CP
SDAttr_Unix
PhysicalMem
Nicht zutreffend
SDAttr_Win9x
Name
Nicht zutreffend
SDAttr_Win9x
Version
Nicht zutreffend
SDAttr_Win9x
Nicht zutreffend
LoggedOnUser
SDAttr_Win9x
Nicht zutreffend
StartupFreeMem
SDAttr_Win9x
Nicht zutreffend
Locale
Attributgruppe
Unterstützte
Attribute
SDAttr_Win9x
Nicht zutreffend
ANSI_CP
SDAttr_Win9x
Nicht zutreffend
OEM_CP
SDAttr_Win9x
Nicht zutreffend
Build
SDAttr_Win9x
ServicePack
Nicht zutreffend
SDAttr_Netware
Name
Nicht zutreffend
SDAttr_Netware
Version
Nicht zutreffend
SDAttr_Netware
Nicht zutreffend
MachineName
SDAttr_Netware
Nicht zutreffend
NetworkNumber
SDAttr_Netware
Nicht zutreffend
NodeAddress
SDAttr_Netware
Nicht zutreffend
Locale
SDAttr_Netware
Nicht zutreffend
ANSI_CP
SDAttr_Netware
Nicht zutreffend
OEM_CP
SDAttr_VMS
Name
Nicht zutreffend
SDAttr_VMS
Version
Nicht zutreffend
SDAttr_VMS
Arbeitsspeicher
Nicht zutreffend
SDAttr_NokiaAdminSuite
Nicht zutreffend
Name
Nicht zutreffend
Version
Nicht zutreffend
DeviceType
Nicht zutreffend
EPOCCommandVersion
Nicht zutreffend
LogFile
SDAttr_PCSystem
Nicht zutreffend
Modell
SDAttr_PCSystem
Nicht zutreffend
SerialNumber
SDAttr_PCSystem
Nicht zutreffend
BaseMemory
SDAttr_PCSystem
ExtendedMemory
Nicht zutreffend
SDAttr_PCSystem
Nicht zutreffend
BiosOEMName
SDAttr_PCSystem
Nicht zutreffend
BiosRevision
SDAttr_PCSystem
Nicht zutreffend
BiosDate
SDAttr_PCSystem
Prozessor:
Nicht zutreffend
SDAttr_PCSystem
Nicht zutreffend
ProcessorDesc
Attributgruppe
Unterstützte
Attribute
SDAttr_PCSystem
Nicht zutreffend
BusType
SDAttr_PCSystem
Nicht zutreffend
DMAController
SDAttr_PCSystem
ProcessorCount
Nicht zutreffend
SDAttr_PCSystem
ProcessorSpeed
Nicht zutreffend
SDAttr_PCSystem
Nicht zutreffend
MainBatteryStatus
SDAttr_PCSystem
Nicht zutreffend
BackupBatteryStatus
SDAttr_PCSystem
Nicht zutreffend
PowerSource
SDAttr_Unix_Processor
Nicht zutreffend
Typ
Nicht zutreffend
SubType
Nicht zutreffend
Beschreibung
ProcessorCount
Nicht zutreffend
SDAttr_PhoneUnit
Nicht zutreffend
Nicht zutreffend
SDAttr_PCFloppy
Laufwerk
Nicht zutreffend
SDAttr_PCFloppy
Nicht zutreffend
Kapazität
SDAttr_PCFloppy
Nicht zutreffend
Format
SDAttr_PCDisk
Laufwerk
Nicht zutreffend
SDAttr_PCDisk
Größe
Nicht zutreffend
SDAttr_PCDisk
Verfügbar
Nicht zutreffend
SDAttr_PCDisk
Nicht zutreffend
Name
SDAttr_PCDisk
Nicht zutreffend
Typ
SDAttr_PCMappedDrive
Nicht zutreffend
Laufwerk
SDAttr_PCCDROM
Laufwerk
Nicht zutreffend
SDAttr_PCDisplay
Nicht zutreffend
DisplayAttached
SDAttr_PCDisplay
Nicht zutreffend
SerialNumber
SDAttr_PCDisplay
Nicht zutreffend
AdapterString
SDAttr_PCDisplay
Nicht zutreffend
AdapterRam
SDAttr_PCDisplay
Nicht zutreffend
AdapterBiosType
SDAttr_PCDisplay
Nicht zutreffend
AdapterBiosDate
SDAttr_PCDisplay
Nicht zutreffend
Lösung
Attributgruppe
Unterstützte
Attribute
SDAttr_PCDisplay
Nicht zutreffend
Breite
SDAttr_PCDisplay
Nicht zutreffend
Höhe
SDAttr_PCDisplay
AdapterType
Nicht zutreffend
SDAttr_PCKeyboard
Nicht zutreffend
Typ
SDAttr_PCKeyboard
Nicht zutreffend
SerialNumber
SDAttr_PCSerialPorts
Nicht zutreffend
NumberOf
SDAttr_PCParallelPorts
Nicht zutreffend
NumberOf
SDAttr_PCMouse
Nicht zutreffend
PointingDevice
SDAttr_PCMouse
Nicht zutreffend
SerialNumber
SDAttr_MSNOS
Nicht zutreffend
Name
SDAttr_MSNOS
Nicht zutreffend
Version
SDAttr_MSNOS
Computername
Nicht zutreffend
SDAttr_MSNOS
IPAddress
Nicht zutreffend
SDAttr_MSNOS
Nicht zutreffend
LoggedOnUser
SDAttr_MSNOS
Nicht zutreffend
LoggedOnDomain
SDAttr_NovellNOS
Nicht zutreffend
Name
SDAttr_NovellNOS
Nicht zutreffend
VersionShell
SDAttr_NovellNOS
Nicht zutreffend
NetworkNumber
SDAttr_NovellNOS
Nicht zutreffend
NodeAddress
SDAttr_NovellNOS
Nicht zutreffend
LoggedOnUser
SDAttr_IBMNOS
Nicht zutreffend
Name
SDAttr_IBMNOS
Nicht zutreffend
Version
SDAttr_IBMNOS
Nicht zutreffend
Computername
SDAttr_IBMNOS
Nicht zutreffend
LoggedOnUser
SDAttr_IBMNOS
Nicht zutreffend
LoggedOnDomain
SDAttr_Win9xNOS
Nicht zutreffend
Name
SDAttr_Win9xNOS
Nicht zutreffend
LoggedOnDomain
SDAttr_PCNetworkAdapter
Nicht zutreffend
Nummer
Nicht zutreffend
Typ
Attributgruppe
Unterstützte
Attribute
Nicht zutreffend
Hersteller
Nicht zutreffend
IDBytes
Name
Nicht zutreffend
SDAttr_Win9xNetworkAdapter
Nicht zutreffend
Nummer
SDAttr_UnixNetworkAdapter
Name
Nicht zutreffend
SDAttr_UnixNetworkAdapter
Nicht zutreffend
Beschreibung
SDAttr_PCOtherAdapter
Nicht zutreffend
Name
SDAttr_UnixVolume
Nummer
Nicht zutreffend
SDAttr_UnixVolume
Kapazität
Nicht zutreffend
SDAttr_UnixVolume
Verfügbar
Nicht zutreffend
SDAttr_UnixVolume
Beschriftung
Nicht zutreffend
SDAttr_UnixVolume
Nicht zutreffend
FileSystem
SDAttr_VMSVolume
Nummer
Nicht zutreffend
SDAttr_VMSVolume
Kapazität
Nicht zutreffend
SDAttr_VMSVolume
Verfügbar
Nicht zutreffend
SDAttr_VMSVolume
Beschriftung
Nicht zutreffend
SDAttr_VMSVolume
Nicht zutreffend
FileSystem
SDAttr_NFSLink
Nicht zutreffend
RemoteName
SDAttr_NFSLink
Nicht zutreffend
Kapazität
SDAttr_NFSLink
Nicht zutreffend
Verfügbar
SDAttr_NFSLink
Nicht zutreffend
LinkName
SDAttr_VMSNFSLink
Nicht zutreffend
RemoteName
SDAttr_VMSNFSLink
Nicht zutreffend
Kapazität
SDAttr_VMSNFSLink
Nicht zutreffend
Verfügbar
SDAttr_VMSNFSLink
Nicht zutreffend
LinkName
SDAttr_Win9xProtocol
Nicht zutreffend
Name
SDAttr_Win9xProtocol
Adresse
Nicht zutreffend
SDAttr_MacAddress
MACAddress
Nicht zutreffend
Installation
ItemName
Nicht zutreffend
Attributgruppe
Unterstützte
Attribute
Installation
ItemVersion
Nicht zutreffend
Installation
ItemProcedure
Nicht zutreffend
Installation
Status
Nicht zutreffend
Installation
Datum
Nicht zutreffend
Installation
Nicht zutreffend
Uhrzeit
Installation
Nicht zutreffend
OrderedBy
StagingLibrary
ItemName
Nicht zutreffend
StagingLibrary
ItemVersion
Nicht zutreffend
StagingLibrary
Status
Nicht zutreffend
StagingLibrary
Datum
Nicht zutreffend
StagingLibrary
Nicht zutreffend
Uhrzeit
StagingLibrary
Nicht zutreffend
OrderedBy
Ziel
Name
Nicht zutreffend
Ziel
Typ
Nicht zutreffend
Ziel
Adresse
Nicht zutreffend
Ziel
Betriebssystem
Nicht zutreffend
Ziel
Registration date
Nicht zutreffend
Ziel
Nicht zutreffend
RegistrationTime
Ziel
ChangedDate
Nicht zutreffend
Ziel
Nicht zutreffend
ChangedTime
Ziel
Benutzer
Nicht zutreffend
Ziel
Telefon
Nicht zutreffend
Ziel
Standort
Nicht zutreffend
Ziel
ViaStagingServer
Nicht zutreffend
Ziel
Staging-Server
Nicht zutreffend
Ziel
Kommentar
Nicht zutreffend
Ziel
Kalender
Nicht zutreffend
Ziel
DownloadMethod
Nicht zutreffend
Ziel
SoftwareManagement Nicht zutreffend
System
Attributgruppe
Unterstützte
Attribute
Ziel
Nicht zutreffend
CoreName
Ziel
Server
Nicht zutreffend
Ziel
Computer
Nicht zutreffend
Ziel
Domäne
Nicht zutreffend
Ziel
UserId
Nicht zutreffend
Ziel
UUID
Nicht zutreffend
Ziel
PreviousLocalServer
Nicht zutreffend
Ziel
RACPolicy
Nicht zutreffend
Ziel
Nicht zutreffend
Veraltet
SDAttr_DownloadMethod
Methode
Nicht zutreffend
SDAttr_AgentConfig
LibraryAccess
Nicht zutreffend
Terminologieglossar
Anwendung
Eine Anwendung ist eine Software, zum Beispiel Microsoft Word.
Anwendungsvirtualisierung ist die Verkapselung einer Anwendung, indem sie vom zu
Grunde liegenden Betriebssystem abgetrennt wird, unter dem es ausgeführt wird. In der
Laufzeit wird die Anwendung dazu gebracht, so zu handeln, als ob sie direkt mit dem
ursprünglichen Betriebssystem und allen davon verwalteten Ressourcen verbunden ist,
aber in Wirklichkeit ist es nicht so.
Common Configuration Enumeration (CCE)
Common Configuration Enumeration (CCE) ist einer der SCAP-Standards. Er enthält
Standard-IDs und ein Wörterbuch zu sicherheitsbezogenen
Systemkonfigurationsproblemen. Eine Rollendefinition in einem SCAP-Datenstrom kann
Referenzen zu einer oder mehreren CCE-IDs, enthalten, was angibt, dass die Regel eine
spezifische CCE-Konfigurationsanweisung oder eine Konfigurationskontrolle darstellt.
Weitere Informationen erhalten Sie unter http://cce.mitre.org/.
Common Platform Enumeration (CPE)
Common Platform Enumeration (CPE) ist einer der SCAP-Standards. Er enthält StandardIDs und ein Wörterbuch zu Plattform- und Produktnamen. Einige Elemente in XCCDFDateien, zum Beispiel, können auf die Anwendung ausschließlich auf bestimmten
Plattformen beschränkt werden, und die erfolgt mittels CPE-IDs. Weitere Informationen
erhalten Sie unter http://cpe.mitre.org/.
Common Vulnerabilities and Exposures (CVE)
Common Vulnerabilities and Exposures (CVE) ist ein Wörterbuch gebräuchlicher Begriffe
(CVE-Identifikatoren) für öffentlich bekannte Sicherheitslücken. Diese Identifikatoren
erleichtern das Austauchen von Daten über mehrere Netzwerk-Sicherheitsdatenbanken
und Hilfsprogramme hinweg. CVE ist nur eine der in SCAP verwendeten Komponenten.
Weitere Informationen finden Sie unter http://cve.mitre.org/.
Common Vulnerability Scoring System (CVSS)
Common Vulnerability Scoring System (CVSS) ist einer der SCAP-Standards. Es enthält
Standards für die Übermittlung und die Bewertung der Auswirklungen von
Sicherheitslücken. Weitere Informationen erhalten Sie unter
http://www.first.org/cvss/index.html.
Terminologieglossar 239
Connectors
Connectors sind die Verknüpfungen von Produkten, die Connector-Daten für externe
Produkte oder Domänen-Manager verarbeiten. Jeder Connector ruft Informationen
seines Domänen-Managers ab und übermittelt die Informationen über das ConnectorFramework an das Consumer-Produkt zur Anzeige und Analyse. Connectors können
auch eingehende Vorgänge für Daten im Quell-Domänen-Manager veranlassen,
beispielsweise Objekterstellung. Connectors verwenden ein vereinheitlichtes
Connector-Framework, um die Integration mit mehreren Produkten zu ermöglichen, die
Sie verwenden.
Desktop-Aktualisierung
Bei der Desktop-Aktualisierung wird der virtuelle Desktop in den Originalstatus
zurückversetzt. Verknüpfte Klone verfolgen Änderungen für den virtuellen Rechner mit
dem Klon nach. Um die Speicherzuweisungen mit dem Klon zu steuern, stellt VMware
View den Aktualisierungsvorgang bereit, der den Klon auf die Baseline zurücksetzt und
alle für Änderungsnachverfolgungen bereitgestellten Deltas freigibt. Demnach gehen
alle auf dem Systemdatenträger seit der Erstellung des Klons oder seiner letzten
Aktualisierung oder Neuzusammenstellung gespeicherten Informationen verloren. Im
Gegensatz zur Desktop-Neuzusammenstellung wird dasselbe Golden Template wie vor
dem Aktualisierungsvorgang verwendet.
Desktop-Neuzusammenstellung
Die Desktop-Neuzusammenstellung ist ein Prozess, bei dem dem virtuellen Desktop eine
neues Golden Template zugewiesen wird. Betriebssysteme und Anwendungen müssen
während ihrer Lebenszeit verwaltet werden, um Probleme mittels Hotfixes oder
Services Packs zu beheben oder neue Funktionen durch neue Versionen bereitzustellen.
Für verknüpfte Klone bedeutet dies, dass das Master-Image oder das Golden Template
aktualisiert werden muss. Sobald die Aktualisierungen abgeschlossen sind, wird der
verknüpfte Klon neu zusammengestellt und wird aktiv. Während der Operation der
Neuzusammenstellung werden die entsprechenden verknüpften Klone mit dem neuen
Golden Template verknüpft und aktualisiert.
Durch Staging bereitgestelltes Image der virtuellen Anwendung
Ein zwischengespeichertes Image einer virtuellen Anwendung ist das Image einer
virtuellen Anwendung, das im File System eines Computers entdeckt wurde.
Eigenständige Umgebung
Als eigenständige Umgebung wird eine Umgebung bezeichnet, in der die Benutzer des
Host- und des Viewer-Computers sämtliche Einstellungen, Eigenschaften und die
Lizenzierung der CA ITCM-Remote Control-Komponente lokal verwalten. Eingerichtet
wird sie mit Hilfe einer eigenständigen Agenten-Installation. Wenn Sie die Installation
manuell ausführen möchten, muss das Setup für den RC-Agenten direkt aufgerufen
werden.
Eigenständige virtuelle Anwendung
Eine eigenständige virtuelle Anwendung ist eine virtuelle Anwendung, die so zur
Verfügung gestellt worden ist, dass das als Quelle verwendete Image der virtuellen
Anwendung auf dem System beherbergt wird, auf dem es zur Verfügung gestellt worden
ist.
eXtensible Configuration Checklist Description Format (XCCDF)
eXtensible Configuration Checklist Description Format (XCCDF) ist eine
Spezifikationssprache, die zum Schreiben von Sicherheits-Checklisten, Benchmarks und
ähnlichen Arten von Dokumenten verwendet wird. Ein XCCDF-Dokument stellt eine
strukturierte Sammlung von Sicherheitskonfigurationsregeln für eine Gruppe von
Zielcomputern dar. Die Spezifikation unterstützt den Austausch von Informationen, die
Generierung von Dokumenten, die Anpassung an Organisationen und Situationen, die
automatisierte Compliance-Kontrolle sowie die Bewertung der Compliance. Weitere
Infos finden Sie unter http://nvd.nist.gov/xccdf.cfm.
Federal Information Processing Standard (FIPS)
Federal Information Processing Standard (FIPS) ist ein Sicherheitsstandard, der vom NIST
herausgegeben und genehmigt wird. Es gibt an, welche Sicherheitsanforderungen von
einem kryptographischen Modul erfüllt werden müssen, die innerhalb eines
Sicherheitssystems verwendet werden, das vertrauliche, aber nicht geheime,
Information schützt.
FIPS-bevorzugt
FIPS-bevorzugt ist eine Betriebsart für CA ITCM, in der Großteil der kryptographischen
Operationen FIPS-kompatibel sind, wenige Verschlüsselungen werden im früheren
Format belassen. In diesem Modus ist CA ITCM rückwärts-kompatibel mit den früheren
Versionen von CA ITCM.
FIPS-kompatible Kryptographie
FIPS-kompatible Kryptographie bezieht sich auf die Verwendung von FIPS 140-2zertifizierten Modulen, FIPS-anerkannt, und von FIPS zugelassene Verfahren und
Algorithmen für Kryptographie.
FIPS-zertifiziertes Kryptographiemodul
FIPS-zertifiziertes Kryptographiemodul bezieht sich auf das Modul "RSA CryptoC BSAFE",
das für FIPS 140-2zertifiziert ist.
Flüchtige Klone
Flüchtige Klone sind virtuelle Desktops aus dem flüchtigen Pool von VMware ViewBenutzerdaten, die vorübergehend integriert sind. Sobald ein Benutzer sich abmeldet,
wird der Klon aktualisiert, und alle Benutzerdaten auf dem Systemdatenträger gehen
verloren.
Gast
Ein Gast in der Terminologie der generischen Plattformvirtualisierung ist der virtuelle
Rechner und das Gastbetriebssystem.
Gastbetriebssystem
Das Gastbetriebssystem führt das Betriebssystem, das in einem virtuellen Rechner
ausgeführt wird.
Gehostete virtuelle Umgebung
Eine gehostete virtuelle Umgebung ist die Virtualisierungs-Software, die zusätzlich zu
einem Hostbetriebssystem, das heißt, dem physischen Rechner, dem Host-BS, und dem
Hypervisor ausgeführt wird.
Gestreamte virtuelle Anwendung
Eine gestreamte virtuelle Anwendung ist eine virtuelle Anwendung, die derart zur
Verfügung gestellt worden ist, dass das als Quelle verwendete Image der virtuellen
Anwendung auf einem anderen Remote- System beherbergt wird, als dem System ist, in
dem es zur Verfügung gestellt wird.
Gestreamtes Image der virtuellen Anwendung
Ein gestreamtes Image der virtuellen Anwendung ist das Image einer virtuellen
Anwendung, das als über das Netzwerk für einen Computer verfügbar entdeckt wurde.
Die Entdeckung des gestreamten Image einer virtuellen Anwendung wird üblicherweise
nur möglich sein, wenn die virtuellen Anwendungen sich innerhalb des zur Verfügung
gestellten Images befinden.
Golden Template
In der CA ITCM-Terminologie ist das Golden Template der virtuelle Rechner, von dem
aus die virtuellen Desktops geklont werden.
Host
Ein Host in der Terminologie der generischen Plattformvirtualisierung ist der physische
Rechner, das Host-Betriebssystem und der Hypervisor.
Host-Betriebssystem
Das Hostbetriebssystem ist das Betriebssystem, das auf einem physischen Rechner
ausgeführt wird.
Host-Cluster
Der Hostcluster ist die Gesamtmenge der Datenverarbeitungs- und Speicherressourcen
einer Gruppe von Hosts, die zum Teil oder insgesamt das gleiche Netzwerk und den
gleichen Speicher gemeinsam nutzen.
Hypervisor
Der Hypervisor ist die Virtualisierungs-Softwareschicht, die physische Hardware im
Namen des Gastbetriebssystems simuliert. Dieser Begriff ist synonym zu Virtual Machine
Monitor (VMM).
Image der virtuellen Anwendung
Ein Image der virtuellen Anwendung enthält eine oder mehrere virtuelle Anwendungen,
die in einer Datei gespeichert wurden, möglicherweise mit einem Set unterstützender
Metadatendateien.
Image-Definition der virtuellen Anwendung
Eine Image-Definition der virtuellen Anwendung bezeichnet die "Spur" für die
Entdeckung des Image einer virtuellen Anwendung. Um ein Bild zu entdecken, dass eine
oder mehrere eingeschlossene virtuelle Anwendungen enthält (in ihm gespeichert),
müssen normale Softwaresignaturen mit der Image-Definition der virtuellen
Anwendung verknüpft werden.
Instanz-Softwarestatusdatenbank
Die Instanz-Softwarestatusdatenbank ist ein Bestandteil der Softwarestatusdatenbank,
die den Verlauf sämtlicher durch den Agent ausgeführten Softwarejobs enthält, die auf
einem Nicht-Golden-Template-System ausgeführt wurden, d. h. alle Klone des Golden
Template.
Konfigurationsansicht
Eine Konfigurationsansicht ist eine angepasste Windows-Benutzeroberfläche, auf der Sie
Konfigurationsrichtlinien für bestimmte Komponenten oder Funktionen bearbeiten
können. In den Konfigurationsansichten werden die relevanten Richtlinien für eine
Komponente oder für eine Funktion unabhängig davon aufgeführt, an welcher Stelle sie
sich tatsächlich in der Hierarchie und in der DSM-Explorer-Baumstruktur befinden.
Master-vDisk
In Citrix XenDesktop ist eine Master-vDisk die initiale vDisk, die vom Golden TemplateComputer generiert wird.
Masterzielgerät
In Citrix XenDesktop ist ein Masterzielgerät der Basis-Desktop mit dem BS und dem
erforderlichen Satz an Anwendungen, von dem eine vDisk generiert wird.
MITRE
Die MITRE Corporation ist eine gemeinnützige Organisation, die für Tätigkeiten in
öffentlichem Interesse gegründet wurde. MITRE bietet Übersetzungsprogramme,
Quellcode, Schemata, und Dateien kostenlos an, damit Einzelpersonen und
Organisationen auf sie bauen und sie erweitern können. Ovaldi ist ein solches frei
erhältliches Übersetzungsprogramm
National Institute of Standards and Technology (NIST)
Das National Institute of Standards and Technology (NIST) ist ein nichtregulierendes
Bundesamt des US-Handelsministeriums. Aufgabe des NIST ist es, die US-amerikanische
Innovation und industrielle Wettbewerbsfähigkeit zu fördern, indem es die
Wissenschaft, Standards und Technologie des Messens so fördert, dass die
wirtschaftliche Sicherheit und unsere Lebensqualität verbessert werden. Die USamerikanische nationale Datenbank für Sicherheitslücken, National Vulnerability
Database (NVD), die vom NIST betrieben wird, bietet ein Repository und Daten-Feeds
mit Inhalten, die SCAP-Standards verwenden. Es ist außerdem das Repository für einige
offizielle Daten zu SCAP-Standards. So definiert NIST offene Standards innerhalb des
SCAP-Kontextes und definiert die Zuordnungen zwischen den SCAPAufzählungsstandards.
Nicht verknüpfte Klone
In VMware View sind nicht verknüpfte Klone oder vollständige Klone vollständige Kopien
des Master- oder Golden Images. Der Klon enthält eine Kopie des Images, und alle
Änderungen am System bei Benutzersitzungen werden in dieser Kopie gespeichert.
Normale Anwendung
Eine normale Anwendung ist Anwendungssoftware, die nicht virtualisiert worden ist und
die in traditioneller Weise installiert und ausgeführt werden kann. Wenn Versionen,
Patches, und Suiten erwähnt werden, handelt es sich um normale Anwendungen.
Nur-FIPS
Nur-FIPS ist eine Betriebsart für CA ITCM, in der nur FIPS-kompatible Kryptographie
erlaubt ist. In diesem Modus ist CA ITCM nicht rückwärtskompatibel mit den früheren
Versionen von CA ITCM.
Offline-Patching
Mit dem Offline-Patching können Sie Patch-Inhalte und -Dateien remote exportieren
und sie mit dem CA Patch Manager ohne Internetzugriff in der CA ITCM-Umgebung
importieren.
Offline-RAC
Bei einem Offline-RAC handelt es sich um einen RAC-Task (Neuinstallation nach Absturz,
Reinstall After Crash), der nicht durch den Manager, sondern durch den Agent gesteuert
wird. Virtuelle Desktops werden häufig erneut erstellt, das heißt, wenn das Golden
Template aktualisiert und die Festplatte zurückgesetzt wird, werden alle Änderungen
am virtuellen Desktop seit der vorherigen Zurücksetzung effektiv ungültig gemacht. Bei
virtuellen Desktops ist nicht der Manager, sondern der Agent für die Erstellung des RACJobcontainers verantwortlich. Bei einer Datenträgerzurücksetzung initiiert der Agent
einen Offline-RAC, um sämtliche Software wiederherzustellen, die für den Agent
bereitgestellt wurde.
Open Vulnerability and Assessment Language (OVAL)
Open Vulnerability and Assessment Language (OVAL) ist einer der SCAP-Standards. Es
enthält Standard-XML für Testverfahren im Zusammenhang mit sicherheitsrelevanten
Softwarefehlern, Konfigurationsproblemen und Patches sowie mit der Weitergabe der
Testergebnisse. Alle Regelüberprüfungen in der Checkliste haben die Form von
Referenzen zu OVAL-Definitionen, die in OVAL-Dateien aus dem SCAP-Datenstrom
enthalten sind. Weitere Informationen erhalten Sie unter http://oval.mitre.org/.
Ovaldi
Ovaldi ist ein OVAL-Übersetzungsprogramm, das von der MITRE Corporation entwickelt
wurde. Es ist eine frei verfügbare Referenzimplementierung, die erstellt wurde, um zu
zeigen, wie Informationen von einem Computer zu Testzwecken erhalten werden
können, um die OVAL-Definitionen für diese Plattform zu bewerten und auszuführen
und um die Testergebnisse weiterzugeben. Das Übersetzungsprogramm zeigt die
Nutzbarkeit der OVAL-Definitionen auf und sorgt für eine korrekte Syntax und die
Einhaltung des OVAL-Schemas.
Paket mit eigenständiger virtueller Anwendung
Ein Paket mit einer eigenständigen virtuellen Anwendung ist ein Paket mit einer
virtueller Anwendung, das verwendet wird, um eine virtuelle Anwendung in
eigenständigem Modus zur Verfügung zu stellen.
Paket mit virtueller Anwendung (VAP)
Ein Image einer virtuellen Anwendung, das in ein oder mehr Software Delivery verpackt
ist, wird als virtuelles Anwenderpaket bezeichnet. Diese Pakete werden verwendet, um
virtuelle Anwendungen auf Computern zur Verfügung zu stellen.
Paket zum Streaming der virtuellen Anwendung
Ein Paket zum Streaming der virtuellen Anwendung ist ein Paket mit einer virtueller
Anwendung, das verwendet wird, um eine virtuelle Anwendung im Streaming- Modus
zur Verfügung zu stellen.
Paket zur Bereitstellung der virtuellen Anwendung durch Staging
Ein Paket zur Bereitstellung der virtuellen Anwendung durch Staging ist ein Paket mit
einer virtuellen Anwendung, das verwendet wird, um das Image der virtuellen
Anwendung durch Staging bereitzustellen.
Paketformat
Das Paketformat ist eine Eigenschaft eines Softwarepakets. Formate sind "normal" und
"virtuell".
Pakettyp
Der Pakettyp ist eine Eigenschaft eines Softwarepakets. Derzeitige Typen sind
Allgemein, MSI, SXP, PIF und PKG. Paket-Typ wird nicht verwendet oder geändert, um
virtuelle Anwendungspakete zu unterstützen.
Partition
Eine Partition ist eine isolierte Instanz eines Hostbetriebssystems. Partitionen
verwenden normalerweise keine Gastbetriebssysteme, weil sie alle das Betriebssystem
des Hosts gemeinsam nutzen.
Partitionierte virtuelle Umgebung
Eine partitionierte virtuelle Umgebung ist eine Umgebung, in der mehrere Instanzen des
Host-Betriebssystems isoliert auf dem gleichen physischen Rechner ausgeführt werden
können. Streng genommen handelt es sich nicht um eine Virtualisierungs-Technologie,
aber sie wird verwendet, um die gleichen Probleme zu lösen.
Permanente Klone
Permanente Klone sind virtuelle Desktops des permanenten Pools, die in ihrer Form
bestehen bleiben, nachdem sich der Benutzer abgemeldet hat, bis sie aktualisiert oder
erneut erstellt werden. VMware View bietet integrierte getrennte Geräte für Systemund Benutzerdaten mit den permanenten Klonen. Auf dem Benutzerdatengerät
gespeicherte Informationen bleiben von jeder Aktualisierung oder
Neuzusammenstellung unberührt, während Änderungen am Systemdatenträger
verloren gehen.
Plattformvirtualisierung
Plattformvirtualisierung ist die Verkapselung von Computern oder Betriebssystemen,
indem ihre physischen Merkmale vor den Benutzern verborgen werden und die
Datenverarbeitungsplattform in der Laufzeit nachgeahmt wird.
Replikation
Bei der Replikation handelt es sich um einen Engine-Task zum Ausführen der
Datenreplikation vom Domänen-Manager zum Enterprise-Manager und umgekehrt.
Sandkasten
Ein Sandkasten ist die Laufzeitumgebung einer Anwendung, die die Anwendung vom
Betriebssystem und den Ressourcen des Computers sowie von anderen Anwendungen
auf dem Computer isoliert. Der Grad der Isolation wird üblicherweise festgelegt, um der
Anwendung einen beschränkten Zugriff auf Ressourcen des Betriebssystems zu
erlauben, z. B. auf den Ordner "Eigene Dateien" .
Scalability-Server
Ein Scalability-Server ist der zentrale Server, um eine geographische Skalierbarkeit für
Management-Tasks zu ermöglichen. Es handelt sich um einen verteilten Prozess, der die
primäre Schnittstelle des Agenten ist.
SCAP-Datenstrom
Ein SCAP-Datenstrom besteht aus Sicherheits-Checklisten in automatischen XMLFormaten, Aufzählungen zu Sicherheitslücken und Produktnamen sowie Zuordnungen
zwischen den Aufzählungen. Ein SCAP-Datenstrom besteht aus den folgenden XMLDateien:
■
Eine XCCDF-Datei
■
Eine oder mehrere OVAL-Dateien
■
(Optional) Eine CPE-Wörterbuchdatei
Schemazuordnung
Eine Schemazuordnung ist eine Zuordnung der mit Datenobjekten wie Benutzern,
Computern und Gruppen verknüpften Attributnamen, die in einem externen Verzeichnis
verwendet werden, zu den Attributnamen, die von den entsprechenden CA ITCMObjekten verwendet werden. Der feste Satz und der Standardsatz der DSMAttributnamen werden zur Abfrage von Verzeichnissen und zur Formulierung komplexer
Abfragen und Berichte verwendet.
Security Content Automation Protocol (SCAP)
Das Security Content Automation Protocol (SCAP), "S Cap" ausgesprochen, ist eine
Methodik für die Verwendung von Standards wie XCCDF, CCE, CVE, CVSS, CPE und OVAL
für automatisches Sicherheitslückenmanagement und die Bewertung der Einhaltung von
Richtlinien (z. B. FISMA-Compliance). Genauer betrachtet SCAP ist eine Suite
ausgewählter offener Standards, die Softwarefehler, sicherheitsrelevante
Konfigurationsprobleme und Produktnamen aufzählen, und die Maßsysteme, um das
Vorkommen von Sicherheitslücken festzustellen sowie Mechanismen, die die Ergebnisse
dieser Messungen einordnen, um die Auswirkungen der entdeckten
Sicherheitsprobleme zu beurteilen, enthalten. SCAP definiert, wie diese Standards
kombiniert werden. Die nationale Datenbank für Sicherheitslücken stellt ein Repository
und Daten-Feeds mit Inhalten, die die SCAP-Standards verwenden, zur Verfügung.
Weitere Infos finden Sie unter http://nvd.nist.gov/.
Softwaresignatur
Eine Softwaresignatur definiert die Attribute einer Softwareanwendung, z. B. den
Dateinamen der Hauptprogrammdatei, andere dazugehörende Dateien, den
Größenbereich, Versionsbereich sowie das Erstellungs- und Änderungsdatum der
Software. Alle diese Attribute einer Softwaresignatur dienen zur eindeutigen
Identifikation einer Anwendung. Softwaresignaturen in Asset Management werden als
Softwaredefinitionen erstellt. Sie können Softwaredefinitionen für ein Produkt, eine
Version, einen Patch, eine Suite, eine Suite-Komponente oder ein Image der virtuellen
Anwendung erstellen. Standardmäßig enthält Asset Management vordefinierte
Softwaresignaturen für die branchenweit am häufigsten verwendeten
Softwareprogramme.
Softwaretyp
Der Software-Typ ist eine Eigenschaft einer Softwaredefinition. Derzeitige Typen
schließen Suite, Produkt, Version, Patch, und Image der virtuellen Anwendung ein.
Standorterkennung
Mit der Standorterkennung kann der DSM-Agent auf einem Computer den Standort des
Computers feststellen.
Systemeigene virtuelle Umgebung
Eine systemeigene virtuelle Umgebung ist die Virtualisierungs-Software, die direkt auf
dem physischen Rechner ausgeführt wird oder die als Host-Betriebssystem handelt oder
auftritt (oft minimal), das heißt, der Rechner und der Hypervisor. Ein synonymer Begriff
ist "Bare Metal-Umgebung".
vDisk
In Citrix XenDesktop ist eine vDisk oder ein virtueller Datenträger prinzipiell eine ImageDatei mit dem BS und dem erforderlichen Satz an Anwendungen.
Verknüpfte Klone
In VMware View verweisen verknüpfte Klone eines Master- oder Golden Images nur auf
das Master- oder Golden Image, aber sie enthalten es nicht. Änderungen, die bei
Benutzersitzungen am System vorgenommen werden, werden nicht im Master-Image
gespeichert, sie werden nur in Delta-Dateien mit dem Klon beibehalten.
virtuelle Anwendung (VA)
Eine virtuelle Anwendung ist Software, die virtualisiert worden ist.
Virtuelle Festplatte
Eine virtuelle Festplatte ist ein Set von Dateien, die ein Dateisystem bildet, das als
physischer Datenträger im Gastbetriebssystem erscheint.
Virtuelle Version
Eine virtuelle Version ist das virtuelle Äquivalent zur normalen Version und hat die
gleiche grundlegende Bedeutung. Der Begriff wird verwendet, wenn man über
Software-Inventar für virtuelle Anwendungen berichtet (nicht Images der virtuellen
Anwendung). Beachten Sie, dass eine zur Verfügung gestellte virtuelle Anwendung
entweder ein durch Staging bereitgestelltes oder ein per Datenstrom übertragenes
Image einer virtuellen Anwendung als Quelle verwenden kann. Die virtuellen
Anwendungen, die im Images der virtuellen Anwendung enthalten sind können als
durch Staging bereitgestellt, aber nicht zur Verfügung gestellt angesehen werden.
Virtueller Desktop flüchtig verknüpfter Klone
Ein virtueller Desktop flüchtig verknüpfter Klone ist ein virtueller Rechner, der bei jeder
Benutzeranmeldung aktualisiert oder erneut erstellt wird, und zwar ohne Persistenz für
benutzerdefinierte installierte Anwendungen, Personalisierung usw.
Virtueller Desktop permanent verknüpfter Klone
Ein virtueller Desktop permanent verknüpfter Klone ist ein virtueller Rechner, der für
einen bestimmten Benutzer dediziert ist, und der Benutzer kann das Hinzufügen
bestimmter Software anfordern, Einstellungen anpassen usw. Die benutzerdefinierte
Umgebung des Benutzers wird bei jeder Anmeldung wiederhergestellt. Dies wird so
beibehalten, bis der virtuelle Desktop aktualisiert oder erneut erstellt wird. Zu diesem
Punkt gehen alle auf dem Systemdatenträger installierten Softwareprodukte verloren.
Virtueller Desktop permanenter, nicht verknüpfter Klone
Ein virtueller Desktop permanenter, nicht verknüpfter Klone ist ein virtueller Rechner,
der für einen bestimmten Benutzer dediziert ist, und er wird dem Benutzer bei jeder
Anmeldung mit den entsprechenden benutzerdefinierten installierten Anwendungen,
Benutzereinstellungen, Daten usw. angezeigt.
Virtueller Patch
Ein virtueller Patch ist das virtuelle Äquivalent zu einem normalen Patch und hat die
gleiche grundlegende Bedeutung. Der Begriff wird verwendet, wenn man über
Software-Inventar für virtuelle Anwendungen berichtet (nicht Images der virtuellen
Anwendung).
Virtueller Rechner (VM)
Ein virtueller Rechner ist eine isolierte virtualisierte Umgebung, die einen Computer
simuliert. Der virtuelle Rechner schließt definitionsgemäß das Gastbetriebssystem nicht
ein.
Virtuelles Image
A virtuelles Image ist eine Datei oder Set von Dateien, die die vollständige Definition
eines virtuellen Rechners, einschließlich seiner Hardware-Spezifikationen und virtuellen
Festplatten enthalten. Es ist die Darstellung des Host-Dateisystems eines Gastes. Ein
virtuelles Image kann online oder offline sein, je nach dem Laufstatus des virtuellen
Rechners, den es abbildet.
XCCDF-Profil
Ein XCCDF-Profil ist eine Richtlinie, die auf den Zielcomputer angewendet oder mit der
Konfiguration des Zielcomputers verglichen wird. Die XCCDF-Datei für jeden SCAPDatenstrom definiert eine Liste der unterstützten Profile. Die XCCDF-Datei muss
mindestens ein XCCDF-Profil enthalten, das angibt, welche spezifischen Regeln für die
Überprüfung eines bestimmten Systemtyps verwendet werden. Sie können
unterschiedliche XCCDF-Profile für jede anwendbare Betriebsumgebung, in der das
System implementiert werden kann, erstellen.
Zentral verwaltete Hostumgebung
Bei einer zentral verwalteten Hostumgebung ist entweder ein Enterprise-Manager oder
ein Domänen-Manager von Remote Control für die Konfiguration der Hosts sowie für
die Authentifizierung von Viewer-Verbindungen verantwortlich. Außerdem verwaltet
dieser Server die Adressbücher, die die Benutzer zur Hostsuche verwenden.
Zentral verwaltete Umgebung
In einer zentral verwalteten Umgebung steuert der Remote Control-Domänen-Manager
die Hosteinstellungen durch Computerrichtlinien, Elemente im globalen Adressbuch
(GAB), Lizenzierung des Agenten auf der Domäne und Benutzerberechtigungen. Dies ist
die Standardeinstellung für CA IT Client Manager.
Zur Verfügung gestellte Anwendung
Eine zur Verfügung gestellte Anwendung ist eine Anwendung (normal oder virtuell), die
für die Ausführung auf einem Zielcomputer verfügbar gemacht worden ist. Die
Anwendung muss nicht lokal "installiert werden", um sie als zur Verfügung gestellt zu
behandeln.
Zustandsüberwachung
Mithilfe der Zustandsüberwachung (Health Monitoring, HM) können Sie Alarme
konfigurieren, Grenzwerte festlegen und den Gesamtzustand der CA ITCM-Infrastruktur
überwachen.

Herunterladen von PDF - Support

Transcription

Similar documents

CA IT Client Manager - CLI-Referenzhandbuch

Datenblatt