1 Einführung in die Suite

Transcription

baramundi
Management Suite 8
benutzerhandbuch
www.baramundi.de
Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können
Fehler nicht völlig ausgeschlossen werden. Die baramundi software AG übernimmt daher
keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und
deren Folgen.
Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind
möglicherweise eingetragene Warenzeichen. baramundi richtet sich im wesentlichen nach den
Schreibweisen der Hersteller. Das Handbuch einschließlich aller seiner Teile ist urheberrechlich
geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung,
Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.
Kommentare und Fragen können Sie gerne an uns richten:
baramundi software AG
Beim Glaspalast 1
86153 Augsburg
Tel.: (0821) 56708–0
Fax: (0821) 56708–19
E-Mail: [email protected]
Copyright:
©2010 baramundi software AG
3.Auflage 2010
Sitz und Registergericht:
Amtsgericht Augsburg hrb Nr.2064
Sitz der AG ist Augsburg
Vorstand und Aufsichtsrat:
Dipl.-Inf.(FH) Bernd Holz (Vorstand Entwicklung & Services)
Dipl.-Ing.(FH) Uwe Beikirch (Vorstand Vertrieb & Finanzen)
Prof.Rainer Liebich (Vorsitzender des Aufsichtsrats)
Text, Satz und Gestaltung
Dipl.-Kfm.Tobias Berndt, m ba (Technischer Redakteur)
Vorbemerkungen
A nwender u nd Sof t ware. Eine erfolgreiche und erprobte Beziehung, aber auch
belastete Zweckgemeinschaft, die sich täglich wieder auf die Probe stellt! Gerade
die Verteilung, Installation, Aktualisierung und Wartung von Software im betrieblichen Umfeld wird nicht selten als notwendiges Übel empfunden, weil diese
unproduktiven «Vorleistungen» der Bereitschaftsaufnahme Ressourcen wie Arbeitszeit, Produktionsmittel, mitunter externen Sachverstand – also schließlich Geld
kosten. Genau diese Kosten der Softwarebereitstellung zu minimieren, war Motivation und Anlass zur Entwicklung der baramundi Management Suite, die nunmehr in
der Version 8.2 vorliegt, der Client-Lifecycle-Management-Lösung Ihres Vertrauens,
für das wir uns herzlich bedanken.
Intention dieses Textes ist es nun, Ihnen einen fundierten Einblick in die Module
der baramundi Management Suite (bms) und deren Funktionen zu geben. Dabei
werden best practices und Techniken vorgestellt, um Ihnen den Ein- oder Umstieg in
oder auf die Version 8.2 zu erleichtern. Zahlreiche Abbildungen und exemplarische
Aufgabenstellungen unterstützen Sie dabei, die baramundi Management Suite
strukturiert und effizient in der Infrastruktur Ihres Unternehmens einzusetzen.
Dieses Handbuch leitet Sie Kapitel für Kapitel durch die Funktionen und Module
der Suite.
Nun ist Zeit stets ein kritischer Faktor, der überdies keinerlei Rücksichten auf
den Redaktionsschluss zu nehmen pflegt. Zudem ist die baramundi Entwicklung
bestrebt, die Management Suite stetig zu verbessern und auf dem neuesten Stand
der Technik zu halten. Sollten also Informationen nicht mehr auf dem aktuellsten
Stand sein, wenden Sie sich bitte an unseren Service, der sicherlich bereits aktuellere
Unterlagen für Sie bereithält.
Sofern Sie Inhalte vermissen, Fragen, Meinungen oder Vorschläge an uns senden
möchten, freuen wir uns auf Ihre Einsendungen. Die Kontaktdaten dazu finden Sie
am Ende des Buches.
Wir hoffen, dass Ihnen dieses Handbuch dabei nützlich ist, sich möglichst schnell
zu orientieren und wünschen viel Erfolg bei der Arbeit mit der baramundi Management Suite,
Ihre
baramundi software AG
Über uns
Die baramundi software AG entwickelt und vertreibt umfassende Lösungen für
Client- und Server-Management zur zentralen und automatisierten Installation von
Betriebssystem und Applikationen in Windows-Umgebungen. Im Mittelpunkt des
Portfolios steht die baramundi Management Suite, die den vollständigen Lebenszyklus von Client und Server abdeckt – unternehmensweit, auch über mehrere
Standorte. Somit werden Betriebssysteminstallationen, Softwareverteilungen, Patch
Management, die umfassende Inventarisierung von Hard- und Software oder Datensicherungen zum Kinderspiel.
Die baramundi software AG verfolgt seit ihrer Gründung im Jahr 2000 einen klar
definierten Weg: Qualitativ hochwertige Software für IT Lifecycle Management
zur Verfügung zu stellen. Produktion, Vertrieb und Support sind und bleiben in
Deutschland angesiedelt. Die solide innenfinanzierte AG verzichtet auf Notierung
an der Börse und kann so ihre klaren Businesspläne langfristig verfolgen. Externe
Investoren haben damit keinen Einfluss auf das Unternehmen, weder hinsichtlich
Philosophie, noch Produkte oder Standort.
Die baramundi software AG nutzt für ihre Produkte, vor allem die baramundi
Management Suite, das Können ausgesuchter Experten, sowohl bei Konzeption
und Programmierung, als auch bei Consulting und Support. Nur ausführlich getestete Versionen werden für den allgemeinen Einsatz freigegeben. Dabei werden
kommende Entwicklungen bei Betriebssystemen und Anwendungssoftware frühzeitig berücksichtigt. IT-Management mit der baramundi Management Suite gibt
Anwendern die Freiheit, jederzeit die jeweils aktuellsten Programme zu nutzen und
mit der baramundi Management Suite zu verteilen und zu verwalten.
ii |
Über 50 engagierte Mitarbeiter, ein erfahrener Aufsichtsrat und ein Netz kompetenter Partner haben die Augsburger baramundi software AG europaweit zu einem
der führenden Softwareanbieter im Client- und Server-Management gemacht.
baramundi legt besonderen Wert auf professionelle Dienstleistungen mit ausführlicher, individueller Beratung vor der Kaufentscheidung. Aber auch auf maßgeschneiderte Schulungen und zertifizierte Partner, auf beste Unterstützung bei Installation
und Implementierung sowie First- und Second-Level-Support.
Über dieses Buch
Das vorliegende Handbuch gliedert sich in vier Kapitel:
Einführung in die Suite Das Kapitel beginnt mit Informationen zur Systemarchitektur
der bms (bms). Zudem werden Hinweise zur Installation der Suite gegeben
und ein Getting Started stellt die grundsätzliche Arbeitsweise im Umgang mit
der Management Suite vor. Dabei widmet sich der Abschnitt beispielhaft mit
den wichtigsten Verwaltungsarbeiten in einer Rechnerstruktur: Zielsystenerfassung, Hardwareinventarisierung, Softwareverteilung.
Arbeiten mit der Suite Noch vor der Vorstellung der einzelnen Module, widmet sich
dieses Kapitel der Vorstellung und Vorführung jener Werkzeuge und Funktionen, die im Umgang mit der baramundi Management Suite notwendig
sind: dem dem baramundi Management Center – der Arbeitsoberfläche der
Suite; der Jobverwaltung – in der sämtliche «Jobs», über die die Aktionen
innerhalb der Management Suite laufen, erstellt werden; die Umgebung – zur
Strukturierung und Verwaltung der Zielsysteme; dem baramundi Management Agent – der Schnittstelle zwischen Server und Client; das Reporting –
das baramundi Berichtssystem zu Ihren Netzwerk sowie Import/Export – ein
Werkzeug zum Austausch von bms-Daten.
Module der Suite In diesem Kapitel werden die Module der baramundi Management
Suite vorgestellt: OS-Install – zur Installation von Betriebssystemen; Deploy –
zur Softwareverteilung; Inventory – zum Inventarisieren von Hard- und Software; Assets – zur Verwaltung von Geräten; Application Usage Tracking – zu
Überwachung des Softwareeinsatzes; Patch Management – zur automatischen
Verteilung von Sicherheitsupdates und Recovery – zur Wiederherstellungen
von Systemen in Notfällen.
|
iii
Verwaltung der Suite Das vierte Kapitel dokumentiert die zahlreichen Möglichkeiten
zu Verwaltung der baramundi Management Suite, gegliedert in Serververwaltung – den Einstellungen für den Serverbetrieb sowie der Allgemeinen
Verwaltung – in der die restlichen Verwaltungstools beschrieben sind
Typographische Konventionen
Im Buch wurden folgende Textauszeichnungen verwendet:
•
•
•
•
i
!
Serifenlose: für Überschriften in den verschiedenen Gliederungsebenen.
Kursive: für Bezeichnungen, Fremdsprachliches und Hervorhebungen.
Kapitälchen: für Schalter in Dialogen und Kontextmenüs.
Nichtproportionale: für gelegentliche Quelltextzitate und Benutzereingaben.
Mit dem «i» für Information, werden weiterführende Tipps im Umgang mit der
Managemant Suite gekennzeichnet.
Die Stoppzeichen sympolisieren Stellen im Text, die auf mögliche Probleme im
Umgang mit der Management Suite hinweisen.
iv |
Inhalt
1
2
Einführung in die Suite
Systeminstallation . . . . . . . . . . . . . .
Grundsätzliches zur Systemarchitektur
Installation der Suite . . . . . . . . . .
Getting Started . . . . . . . . . . . . . . .
Zielrechner erfassen . . . . . . . . . .
Hardware inventarisieren . . . . . . .
Software verteilen . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
3
6
6
7
8
Arbeiten mit der Suite
baramundi Management Center . . . . . . . . . . . .
Grundsätzliches zum Management Center . . . .
Bereiche des Management Centers . . . . . . . .
Jobverwaltung . . . . . . . . . . . . . . . . . . . . . .
Grundsätzliche Arbeitsweise . . . . . . . . . . .
Ausführen von Jobs . . . . . . . . . . . . . . . .
Benutzerbezogene Jobausführung . . . . . . . . .
Automatische Jobzuweisung/Jobvoraussetzungen
baramundi Kiosk . . . . . . . . . . . . . . . . .
Umgebung . . . . . . . . . . . . . . . . . . . . . . . .
Logische Gruppierung . . . . . . . . . . . . . . .
Dynamische Gruppen . . . . . . . . . . . . . . .
Weitere Umgebungen . . . . . . . . . . . . . . .
Arbeitshilfen im Knoten Umgebung . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
13
13
15
16
17
25
36
37
38
38
40
41
42
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
v
baramundi Management Agent . . . . . . . . . . . . . . . . . . . . . . 45
Systemerfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Installation und Konfiguration des baramundi Management Agents 48
Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Import/Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Persönliche Einstellungen . . . . . . . . . . . . . . . . . . . . . . 54
3
Module der Suite
OS-Install . . . . . . . . . . . . . . . . . . .
Grundsätzliche Vorgehensweise . . . . .
Vorbereitungen zum OS-Install . . . . .
Verteilung von Betriebssystemen . . . .
Treiberintegration . . . . . . . . . . . .
Komponenten . . . . . . . . . . . . . .
Hardwareprofile . . . . . . . . . . . . .
Ein Beispiel . . . . . . . . . . . . . . .
Deploy . . . . . . . . . . . . . . . . . . . . .
Grundsätzliche Arbeitsweise . . . . . .
Software verteilen . . . . . . . . . . . .
Ein Beispiel . . . . . . . . . . . . . . .
Citrix Presentation Server Verwaltung .
Automate . . . . . . . . . . . . . . . . . . .
Grundsätzliches zum Automation Studio
GUI-Aktion/Analyzer . . . . . . . . . .
Debugger . . . . . . . . . . . . . . . .
Noch ein Beispiel . . . . . . . . . . . .
Arbeiten mit Variablen . . . . . . . . .
Inventory . . . . . . . . . . . . . . . . . . .
Inventarisieren von Hardware . . . . . .
Inventarisieren von Software . . . . . .
Assets . . . . . . . . . . . . . . . . . .
Application Usage Tracking . . . . . . .
Patch Management . . . . . . . . . . . . . .
Voraussetzungen . . . . . . . . . . . . .
Grundsätzliche Arbeitsweise . . . . . .
Patchkonfiguration . . . . . . . . . . .
vi | Inhalt
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
56
56
57
60
62
64
65
69
74
74
75
79
83
91
92
98
106
107
111
115
115
120
125
130
137
138
138
140
Patches verteilen .
Ein Beispiel . . .
Recovery . . . . . . . .
Disaster Recovery
Personal Backup .
Ein Beispiel . . .
4
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Verwaltung der Suite
Serververwaltung . . . . . . . . . . . .
Grundeinstellungen . . . . . . . .
Konfiguration . . . . . . . . . . .
Modulzustände . . . . . . . . . .
Lock Manager . . . . . . . . . . .
Ereignisanzeige . . . . . . . . . .
Versionsinformation . . . . . . . .
Allgemeine Verwaltung . . . . . . . . .
Sicherheitsverwaltung . . . . . . .
Domänenkonfiguration . . . . . .
IP-Netzwerke . . . . . . . . . . .
Bootumgebungen . . . . . . . . .
Variablen . . . . . . . . . . . . . .
Patch Management . . . . . . . .
Recovery . . . . . . . . . . . . . .
Inventory . . . . . . . . . . . . .
Asset-Typen . . . . . . . . . . . .
DIP-Server Synchronisierung . . .
Active Directory Synchronisierung
Datenbankwartungsaufgaben . . .
Downloadjobs . . . . . . . . . . .
Bandbreitenmanagement . . . . .
Reservierte Lizenzen . . . . . . . .
Revisionslog . . . . . . . . . . . .
Tools . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
145
147
150
150
154
159
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
163
164
164
166
172
173
173
173
174
174
179
181
182
183
184
187
187
188
189
191
193
194
195
196
196
197
Hilfen zur Suite
199
Fehlermeldungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Inhalt |
vii
Konfiguration . . .
Sonstiges . . . . . .
Fehleranalyse . . .
baramundi Support
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Anhang
Kommunikationsschema und Portbelegung . . . . .
Ablaufschema zur Skriptierung im Automation Studio
Die MSI-Fehlerwerte und deren Bedeutung . . . . . .
baramundi Variablen . . . . . . . . . . . . . . . . .
Globale Variablen . . . . . . . . . . . . . . . .
Benutzerdefinierte Variablen . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
. II
. III
. IV
. IX
. IX
. XIII
viii | Inhalt
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
200
201
203
210
IT einfach clever managen
In diesem Kapitel:
• Systemarchitektur—1
• Installation der Suite—3
• Getting Started—6
1
Einführung in die Suite
Systeminstallation
Bevor im weiteren Verlauf des Kapitels der Installationsverlauf erläutert und Ihnen
in Form eines kurzen Getting Starteds ein schneller Einstieg geboten wird, möchten
wir Sie zunächst mit der grundlegenden Architektur des Systems vertraut machen.
Grundsätzliches zur Systemarchitektur
Bedingung für den Einsatz der bms ist eine Datenbank (Microsoft sql oder Oracle).
Hierin werden für die Arbeit mit der Suite relevanten Daten geschrieben. Die Schnittstelle zur Datenbank wird von uns moc genannt (Management Object Connector).
Dieser Dienst nimmt Daten entgegen und leitet sie weiter, von der Datenbank ans
System und umgekehrt. Während die Datenbank ab einer entsprechenden Clientanzahl einen separaten Server erfordert, laufen die Dienste moc, xm l-Webdienste
(Frontend) und der baramundi Management Server (Backend) in aller Regel auf
dem gleichen Rechner.
Backend. Als Backend fungiert der baramundi Management Server (auf Basis von
Microsoft Windows Server 2003/2008). Der Management Server kommuniziert
(nach oben) mit dem moc, um Befehle und Daten entgegenzunehmen, und (nach
unten) mit den zu verwaltenden Clients (baramundi Management Agent, bma)
respektive einem Datei-Depot, mit zur Verteilung bereit stehender Software, dip
(Distributed Installation Point) genannt.
Abbildung 1–1: baramundi Topologie
2 | Kapitel1: Einführung in die Suite
Frontend. Der Benutzerschnittstelle vorgeschaltet ist ein xm l-Webdienst. Dieser
wandelt maschinenlesbare Daten in für einen Benutzer interpretierbare Ausgaben
um. Der Benutzer selbst veranlasst Eingaben und erhält Systemausgaben sehr
komfortabel über eine entsprechende Oberfläche (gui). Ein- und Ausgaben können
dabei entweder in Tabellenform über die Microsoft Management Console (m m c)
oder noch bequemer über eine htm l-Ansicht eingesehen und bearbeitet werden.
Die Benutzerschnittstelle kommuniziert (neben dem xm l-Webdienst) mit dem moc
und kann dabei von beliebigen Rechnern aus bedient werden.
Client/Software. Der einzelne Client erhält seine Anweisungen und regelt seine Abfragen über eine dafür entwickelte und auf jedem Zielrechner installierte Software
– den baramundi Management Agent (bma). Über das Netzwerk verbindet sich
dieser mit dem baramundi Management Server und erhält so seine Informationen.
Zudem hält der bma Verbindung zum dip, einem externen oder auf dem baramundi
Management Server befindlichen Installationsshare, der entsprechende Software
bereitstellt.
Der bma ist über den Infobereich der WindowsAufgabenleiste erreichbar. Über das Kontextmenü der Maus
sind darüber Informationen zum Agent abrufbar (Über baramundi Management Agent), die Logdaten einzusehen (Logdatei einsehen) und der baramundi Kiosk zu öffnen (baramundi Kiosk).
Installation der Suite
Die Installation der baramundi Management Suite vollzieht sich schnell, indem die
angebotenen Optionen einfach akzeptiert und durchgeklickt werden. Gleichwohl
sei im weiteren Verlauf kurz auf die relevanten Schritte eingegangen. Grundsätzlich
verläuft die Installation in drei Phasen, nämlich:
1. Installationsvorbereitung (Windows Tools),
2. Installation der Management Suite,
3. Datenbankbezogene Installationsschritte,
da für die Arbeit mit der Management Suite bestimmte Windowskomponenten
(wie z.B..net, msx m l) sowie eine Datenbank nebst baramundi Datenbankmanager
benötigt werden.
Systeminstallation |
3
Abbildung 1–2: Dialog bei fehlender Komponente
Installationsvorbereitung
Nach dem Doppelklick auf die Datei BMS_Setup.exe der Installations-d vd, erfolgt
zunächst eine Rückfrage nach der Sprachauswahl (Deutsch oder Englisch) für die
Folgedialoge, also nicht der Suite selbst. Danach wird geprüft, ob dem System
sämtliche, für die Installation benötigten, Windowskomponenten zur Verfügung
stehen. Es handelt sich dabei um Software, die Teil Ihres System sein sollten. Falls
nicht, kommt es zu einer Rückmeldung (Abb.1–2).
Mögliche fehlende Komponenten – wie beispielsweise .net – stehen jedoch auf der
Installations-dvd bereit. Sind alle erforderlichen Windowskomponenten vorhanden beziehungsweise installiert, meldet sich der bms-Setup-Assistent mit einigen
Informationnen und einem Dialog zur Auswahl der Komponenten:
• baramundi Management Suite (voreingestellt)
• baramundi dipSync (für den Betrieb mehrerer dips)
• baramundi Management Agent (für aktuell benutzten Rechner)
Nach der Bestätigung dieses Dialogs werden Sie schließlich noch gebeten, Zusätzliche Aufgaben auszuwählen:
• Windows PowerShell (zum Betrieb des s q l-Servers)
• s q lServer 2008 Express Edition (falls kein s q lServer/Oracle vorhanden)
• Crystal Reports Runtime (falls baramundi Reports verwendet werden sollen)
Nach Auswahl und Bestätigung dieses Dialogs sind sämtliche Voreinstellungen
getroffen, und der InstallShield Wizard für die baramundi Management Suite
begrüßt Sie zur bms-Installation.
Installation
Zunächst gilt es die Lizenzvereinbarung zu akzeptieren sowie den Setuptyp (Vollständig/Angepasst) zu wählen. Schließlich wird Ihnen optional angeboten den
Datenbank Manager zu starten. In diesem Fall geht die Installation nahtlos in die
Datenbankeinrichtung über.
Sie können also die Einrichtung des Database Managers an dieser Stelle gleich mit
erledigen oder zu einem späteren Zeitpunkt über das Startmenü veranlassen. In
diesem Falle endet hier die Installation. Beachten Sie, dass die baramundi Management Suite sich nun zwar auf Ihrem Rechner befindet, jedoch erst nach der Einrichtung der Datenbank mittels des Database Managers ihre Arbeit aufnehmen kann.
Um den Einrichtungsprozess des Database Managers außerhalb der bmsInstallationsroutine zu starten, wählen
Sie bitte Start—Programme—baramundi
Management Suite—Tools—Database Manager. Wir wollen davon ausgehen, dass
bereits ein Datenbankserver vorhanden
ist und es nurmehr darum geht, eine
neue Datenbank zu erzeugen. Wählen
Sie den entsprechenden Dialogpunkt Eine neue Datenbank erstellen.
Abbildung 1–3: Datenbank erzeugen
Darin ist zunächst das Datenbanksystem zu wählen (Abb.1–3). Zur Auswahl stehen Microsoft s q l-Server oder Oracle.
Im zweiten Scrollmenü selektieren Sie bitte den Datenbankserver, auf dem die
Systeminstallation |
5
Datenbank eingerichtet werden soll. Die Login-ID für den sich im Lieferumfang
befindlichen sql Express Server ist konventionsgemäß sa, das Kennwort lautet
baramundi-2008. Unter Datenbank benennen Sie die eben erstellte Datenbank. Der
darauf folgende Dialog fordert unter Datenbankmedium und Logmedium zu Eingaben auf. Grundsätzlich sind auch diese Pfade frei wählbar – die entsprechenden
Verzeichnisse müssen jedoch bereits existieren. Die folgenden Dialoge sind selbsterklärend und können insofern durchgeklickt werden; die voreingestellten Optionen
sind dabei im Normalfall einfach zu übernehmen.
Getting Started
Um Ihnen bereits an dieser Stelle ein erstes Gefühl zu vermitteln, wie die baramundi
Management Suite arbeitet, sollen im Folgenden einige kleinere Jobs – denn fast
nur über Jobs kommunizieren Sie mit der Management Suite – ausgeführt werden.
Starten Sie dazu das baramundi Management Center und darin den Server im
Kontextmenü des oberen Knotens baramundi Management Center—Server starten.
i
Beachten Sie bitte, dass der erste Serverstart einen umfangreichen Download von Patchdateien iniziiert. Bestimmte Jobs, wie die Hardwareinventarisierung neuer Clients, greifen dabei auf den gleichen Fileimport zu,
wie das Einlesen der Patchdaten. Dadurch kann es geschehen, dass zwar der
Job anläuft, jedoch die Resultate erst nach dem Patchdownload ersichtlich
sind.
Zielrechner erfassen
Zunächst gilt es die Rechner, die künftig verwaltet werden sollen, im System zu
erfassen. Dazu ist im Kontextmenü der rechten Maustaste unter Umgebung/Logische
Gruppe—Neu—System erfassen zu wählen. Diesmal wollen wir uns für ohne Hardwareprofil entscheiden. Geben Sie unter Anzeigename den zu erfassenden Rechner
an (wird gleichzeitig als Hostname übernommen) und bestätigen Sie Ihre Einträge.
Der Rechner wird daraufhin unter Logische Gruppe aufgeführt.
Um mit diesem Rechner zu kommunizieren ist es notwendig, dass auf dem Zielsystem der baramundi Management Agent (bma) installiert ist. Markieren Sie dazu
den eben erfassten Client (Umgebung/Logische Gruppierung) und klicken Sie in der
Tools-Menüleiste der htm l-Ansicht einfach auf bMA installieren. Der bma auf dem
Clientsystem ist nun installiert und stellt erste Angaben Allgemein zur Verfügung.
Abbildung 1–4: Job anlegen
Abbildung 1–5: Jobschritt wählen
Abbildung 1–6: Jobschritt bearbeiten
Abbildung 1–7: Job fertigstallen
Hardware inventarisieren
Diese grundsätzlichen Angaben zur Hardware sollen nunmehr ergänzt werden.
Dazu ist ein so genannter Job anzulegen. Wie bereits erwähnt: Die meisten Aktionen
innerhalb der baramundi Management Suite laufen über Jobs ab, also eine konkrete
Aufgabe, die an das System übergeben wird. Und so funktionierts, Wählen Sie:
1. im Kontextmenü der Jobverwaltung/Neu—Job und benennen Sie Ihren neuen
Job (hier: «Hardwareinventarisierung», Abb.1–4),
2. dann wählen Sie den Jobschritt Inventarisierung durchführen (Abb.1–5) und
3. im nächsten Dialog Standard Hardwareinventarisierungsvorlage (Abb.1–6).
4. Klicken Sie sich bis zum letzten Dialog (Abb.1–7), um den Job mit Fertig
stellen zu beenden.
Getting Started |
7
Damit ist der neue Job erstellt und befindet sich unter dem Knoten Jobverwaltung. Der Job muss nun noch dem entsprechenden Client zugeordnet werden.
Das geschieht am einfachsten, indem Sie entweder den Job (Jobverwaltung) via
Drag&Drop auf den Client (Umgebung/Logische Gruppe) oder den Client auf den
Job schieben. Nach Bestätigung der kurzen Zwischenfrage, ob Sie diese Zuordnung
wünschen, läuft der Job.
Sie können der bms bei der Arbeit zusehen, das heißt die Ausführung des Jobs
beobachten. Klicken Sie dazu in der linken Baumansicht auf Ihren Client und
dann rechts in der htm l-Ansicht in das Register Jobs. Unter Status befindet sich ein
kleiner Klappschalter (Doppelfpeil nach unten). Mit einem Klick darauf klappt das
System eine kleine Übersicht auf, die Sie über die aktuellen Jobzustände informiert.
Nachdem der Job erfolgreich gelaufen ist – Fortschrittsbalken: wechselt von blau
(läuft) auf grün (100%) – stehen Ihnen die so ermittelten Hardwaredaten im Register
Inventur zur Verfügung.
Software verteilen
Natürlich wollen wir Ihnen im Getting Started auch eine kleine Softwareinstallation nicht vorenthalten. Daher wurden der Installations-d vd einige Anwendungen
hinzugefügt, aus denen wir nun beispielhaft eine, zum Zwecke der Demonstration,
verteilen wollen.
Es soll im Folgenden der Internetbrowser Firefox an ein bereits erfasstes Zielsystem
(ClientA) verteilt werden.
Installationsdateien auf DIP kopieren
Bevor Software über baramundi verteilt werden kann, muss diese auf dem Verteilverzeichnis dem System zunächst zur Verfügung stehen.
1. Wählen Sie eine zu verteilende Software (z.B.Firefox* ).
2. Kopieren Sie die Installationsdatei in das dip-Verzeichnis \\{Server}\DIP$.
*
www.mozilla-europe.org/de/firefox
Applikation in Deploy anlegen
Die Installationsdatei muss nun noch im baramundi Management Center verfügbar
sein.
3.
4.
5.
6.
Wählen Sie Deploy/Applikationen—Neu—Applikation.
Verwenden Sie den Application Automation Wizard.
Geben Sie den dip-Pfad zum Firefox ein.
Folgen Sie den Wizardanweisungen.
Damit steht die Firefox Setup.exe für eine Verteilung zur Verfügung.
Softwareverteiljob anlegen und zuweisen
Schließlich ist noch ein entsprechender Job anzulegen und einem Zielsystem zuzuweisen.
7.
8.
9.
10.
11.
Wählen Sie Jobverwaltung—Neu—Job.
Geben Sie dem Job einen aussagekräftigen Namen.
Wählen Sie den ersten Jobschritt Software verteilen
und die entsprechende Software aus.
Stellen Sie die Job fertig.
Der Job zur Verteilung des Firefox steht nun unter dem Knoten Jobverwaltung
zur Verfügung. Von hier aus kann der Verteiljob nun via Drag&Drop auf einen
Client oder einer Clientgruppe – in diesem Falle eben ClientA – unter Umgebung
zugewiesen werden und kommt zur Ausführung.
Soviel in aller Kürze zu einigen populären Funktionen der Suite. Detaillierte Beschreibungen der Bereiche der Suite folgen in den Kapiteln dieses Handbuchs.
Die nächsten Abschnitte jedoch, sind der allgemeinen Bedienung der baramundi
Management Suite gewidmet.
Getting Started |
9
In diesem Kapitel:
• baramundi Management Center—12
• Jobverwaltung — 15
• Benutzerbezogene Jobausführung—25
• baramundi Kiosk—37
• Umgebung—38
• baramundi Management Agent—45
• Reporting—50
• Import/Export—52
2
Arbeiten mit der Suite
Noch vor detaillierten Erläuterungen der einzelnen Module, soll die Arbeit mit
der baramundi Management Suite grundsätzlich betrachtet werden. Zunächst wird
das baramundi Management Center (bmc) vorgestellt, die zentrale Steuerungsoberfläche der Suite. Darin stehen Ihnen, in einer Baumstruktur, die einzelnen Bereiche,
Module und Werkzeuge der Suite übersichtlich zur Verfügung. Dazu im Anschluss
gleich mehr.
Fast jede Aktion in der baramundi Management Suite, also jede Kommunikation
zwischen Server und Zielsystemen verläuft über «Jobs». Ob Installationen von
Betriebssystemen, Verteilung von Software oder Inventarisierung von Hard- und
Software: All diese Aufgaben werden über Jobs abgewickelt. Insofern ist der Konten Jobverwaltung von zentraler Bedeutung. Im zweiten Abschnitt dieses Kapitels
wird der Umgang mit Jobs erläutert und veranschaulicht. Erläuterungen zu den
Funktionen der benutzerbezogene Jobausführung sind in diesem Kapitel ebenfalls
Gegenstand der Betrachtung. Schließlich wird auch der baramundi Kiosk vorgestellt,
eine Weboberfläche, über die – anstatt vom Server initiiert – die Clients selbst Jobs
abholen.
Die Zusammenfassung von Clients sorgt nicht nur für eine entsprechende Übersichtlichkeit, sie ist auch für eine effiziente Jobausführung unerlässlich. Der dritte
Abschnitt – Umgebung – erklärt die weitgehenden Möglichkeiten der Strukturierung
von Zielsystemen und deren Bedienung.
Zur Ausführung, der vom Server veranlassten administrativen Aufgaben auf den
Client-Rechnern, gibt es den baramundi Management Agent (bma), der Ihnen im
vierten Abschnitt vorgestellt wird.
Im Abschnitt Reports wird das Berichtesystem der Management Suite vorgestellt
und im Abschnitt Import/Export lernen Sie die Möglichkeiten kennen, Inhalte der
bms auszutauschen.
baramundi Management Center
Das baramundi Management Center stellt die Administrationsoberfläche der Management Suite dar – die Schaltzentrale, wenn Sie so wollen. Sämtliche Jobs und
Prozesse lassen sich darin überwachen und steuern. Im Folgenden möchten wir Sie
mit der Struktur des baramundi Management Center vertraut machen, damit Sie
sich darin schnell und sicher orientieren.
Abbildung 2–1: baramundi Management Center
Starten Sie das baramundi Management Center Start—Programme—baramundi
Management Suite—baramundi Management Center und darin den Server im Kontextmenü des oberen Knotens baramundi Management Center—Server starten.
!
Bitte beachten Sie, dass der erste Serverstart einen umfangreichen Patchdownload iniziiert. Bestimmte Jobs, wie die Inventarisierung neuer Clients,
greifen dabei auf den gleichen Fileimport zu, wie das Patchupdate. Dadurch kann es geschehen, dass zwar der Job anläuft, jedoch die Resultate
12 | Kapitel2: Arbeiten mit der Suite
erst nach dem Patchdownload ersichtlich sind. Das initiale Patchupdate
nimmt einige Zeit in Anspruch, circa 15 Minuten. Damit die ersten Tests
von diesen Aktivitäten nicht beeinträchtigt werden, ist es ratsam abzuwarten,
bis der Patchdownload beendet ist. Diese Information ist über den Knoten
Verwaltung/Server/Modulzustände/FileConnector ersichtlich.
Grundsätzliches zum Management Center
Wie Sie es von anderen Programmen gewohnt sind, präsentieren sich auch im
baramundi Management Center oben-links eine Menü- und eine Symbolleiste.
Die Symbolleiste – wie auch andere Bereiche der bmc – passt sich den gewählten
Modulen an. Das heißt, dass je nachdem, welches Modul im Navigationsbaum
gewählt ist, auch unterschiedliche Symbole angezeigt werden.
In den meisten Modulen stehen Ihnen zwei Ansichten zur Verfügung: die Tabellenform (m mc) und eine htm l-Ansicht. Auch ein Wechsel der Ansichten ist über die
Symbolleiste möglich, und zwar durch einen Klick auf Zur Tabellenansicht wechseln
oder Zur HTML-Ansicht wechseln.
Bereiche des Management Centers
Da im weiteren Verlauf des Handbuchs immer wieder auf bestimmte Bereiche des Management Centers Bezug genommen werden muss, sollen diese hier
kurz benannt und vorgestellt werden.
Im linken Bereich des bmc befindet sich der Navigationsbaum (Abb.2–2). Darin können Sie – ganz ähnlich dem Windows Explorer – die Knoten aufzuklappen, um in darunter liegende Bereichen zu gelangen,
zwischen den Modulen und Funktionen der Suite
wechseln oder über deren Kontextmenüs arbeiten.
Den größten Funktionsumfang sowie den meisten
Bedienkomfort bieten dabei die h tm l-Ansichten.
Im oberen Bereich (Abb.2–3) stehen Ihnen (in der
h tm l-Ansicht) noch einige Informationen zur VerfüAbbildung 2–2: Navigationsbaum
gung. In den Statusinformationen, der Region direkt
über dem Arbeitsbereich, wird der Pfad angezeigt, indem Sie sich gegenwärtig
befinden.
baramundi Management Center |
13
Abbildung 2–3: bMC-Statusinformationen
Im Arbeitsbereich (Abb.2–4) werden die Systemausgaben (hier im Knoten OSInstall) dargestellt. Um eine höchstmögliche Übersichtlichkeit zu gewährleisten,
sind thematisch verbundene Ausgaben in Registerkarten (hier eben Betriebssystemliste und Lizenzübersicht) geordnet.
Abbildung 2–4: bMC-Arbeitsbereich
Die Anzahl der Registerkarten variieren, abhängig vom gewählten Modul. Zuweilen
kommt es so zur Anzeige vieler Registerkarten, was die Übersichtlichkeit beeinträchtigt. Deshalb ist einstellbar, ob die Beschriftung vollständig angezeigt wird,
oder ob lediglich ein Symbol das Register kennzeichnet. Ein Wechsel der Anzeigen ist im Knoten baramundi Management Center unter Einstellungen durch die
Aktivierung/Deaktivierung der Option Job-Reiter verkürzen möglich.
Rechts neben der Pfadangabe befindet sich eine Leiste, die eine schnelle Navigation
im Management Center ermöglicht und zudem noch eine kurze Erklärung zum
aktuell gewählten Inhalt ausgibt. Im unteren Bereich wird, je nach gewähltem
Modul, eine Statistik bezüglich des aktuellen Inhalts angezeigt, in der Abbildung
Informationen über Jobs und Clients.
Zwischen dem Arbeitsbereich und dem Navigationsbaum befindet sich der Aufgabenbereich. Ähnlich der
Symbolleiste wechseln auch die im Aufgabenbereich befindlichen Auswahlmöglichkeiten mit den entsprechend
gewählten Modulen oder sind – je nach den im Navigationsbaum gewählten Funktionen – aktiv oder inaktiv.
Die Funktionen im Aufgabenbereich (hier aus dem Knoten Inventory) sind auf- und zuklappbar. Ein Klick in
die funktional geordneten (hier Neue Vorlagen, Aufgaben und Quicklinks) Aufgabenbereiche, ermöglicht eine
schnelle, effiziente Arbeitsweise.
Bitte beachten Sie in diesem Zusammenhang, dass die
einzelnen Aufgabenbereiche, je nach aktuell gewähltem
Modul, auch verschiedene Bezeichnungen aufweisen. So
heißen beispielsweise die Aufgabenbereiche des oberen
Knotens baramundi Management Center zum Beispiel
Abbildung 2–5: AufgabenAdministration, Modul und Verwaltung und nicht, wie
bereich
im Inventory-Knoten, Neue Vorlagen, Aufgaben etc.
Ganz unten in im Management Center, befindet sich die Statusleiste. Sie zeigt
(in der m mc) an, wieviele Unterknoten sich unter dem aktuell gewählten Hauptknoten befinden. Das mag bei Knoten innerhalb des Navigantionsbaums noch
recht unspektakulär wirken; werden aber Patches, pci-Kennungen oder dergleichen,
zahlreicheren Angaben verarbeitet, kann die Statusleiste sehr nützlich sein.
Jobverwaltung
Wie bereits erwähnt: Die meisten Aktionen innerhalb der baramundi Management
Suite werden über Jobs ausgeführt. Insofern ist die Jobverwaltung Ihre exekutive
Schaltzentrale, denn über diesen Knoten verwalten Sie Jobs. Ein Job besteht aus
mindestens einem Jobschritt – zum Beispiel einer Betriebssysteminstallation oder
Jobverwaltung |
15
Abbildung 2–6: Die Jobverwaltung
Inventarisierung –, es ist auch möglich, dass ein Job mehrere Schritte umfasst.
Die Zusammenstellung dieser Jobschritte kann ganz unterschiedlich sein und für
Aufgaben individuell angepasst werden. Wie Sie Jobs erstellen, diese ausführen,
verwalten oder automatisieren, erfahren Sie in den folgenden Abschnitten.
Grundsätzliche Arbeitsweise
Die Jobausführung vollzieht sich in vier einfachen Phasen:
•
•
•
•
!
Der Server übermittelt dem Client, dass Jobs vorhanden sind.
Der Client signalisiert daraufhin dem Server seine Ausführungsbereitschaft.
Der Server übergibt den Job/die Jobs an den Client.
Der Client teilt nach Ausführung/Ablehnung dem Server den Jobverlauf mit.
Bitte beachten Sie: Bevor Jobs vom Server an die Zielsysteme übergeben
werden können, sind in aller Regel einige Vorbereitungen zu treffen. Zu
verteilende Software muss beispielsweise auf dem dip zur Verfügung stehen, für eine Betriebssysteminstallation müssen die Systeme unter OSInstall/Betriebssysteme eingerichtet sein und dergleichen mehr.
Abbildung 2–7: Arbeitsweise der Jobverwaltung
Server (bMS)
- MOC
DB
-
-
6
(3)
(4)
(1)
(2)
(1) Server meldet: Job(s) vorhanden
(2) Client meldet: Bereit zur Jobausführung
(3) Jobübergabe: Server—Client
(4) Ergebnisübermittlung: Client—Server
?
Client (bMA)
-
Ausführen von Jobs
Über die Jobverwaltung lassen sich folgende Aufgaben auf den Clients ausführen:
•
•
•
•
•
•
•
•
•
•
•
•
Software verteilen
Applikation deinstallieren
Inventarisierung durchführen
Systeme mit Patches aktualisieren
Datensicherung
Image eines Laufwerks erstellen
Citrix Jobschritte
Betriebssystem installieren
Festplatte vollständig löschen
Daten aus Sicherung wiederherstellen
Laufwerk aus Image wiederherstellen
p xe Image booten
Eine Linie trennt den oberen Bereich der Jobschritte, die beliebig oft ausgeführt
werden können, vom unteren Bereich mit Jobschritten, deren Ausführung eher
dauerhaften Charakters sind. Diese Jobs sind mit entsprechender Sorgfalt zu verwenden.
Jobverwaltung |
17
Software verteilen. Dieser Jobschritt installiert Software auf Zielsysteme.
Applikation deinstallieren. Um eine Applikation zu deinstallieren, kann für alle Applikationen, für die ein Deinstallationsmechanismus definiert wurde, auch direkt ein
Deinstallationsjob angelegt werden. Über die Auswahl-Schaltfläche öffnet sich ein
neues Fenster zur Auswahl, der zur Deinstallation in Frage kommenden Applikationen. Darin werden die zur Deinstallation gewählten Applikationen gelistet.
Inventarisierung durchführen. Hierüber werden Jobs zur Bestandsaufnahme der Hardund Softwareausstattung von Zielrechnern erstellt.
Systeme mit Patches aktualisieren. Mittels dieses Jobschritts wird der Patch-Status von
Zielsystemen ermittelt und gegebenenfalls aktualisiert.
Datensicherung. Basierend auf den Sicherungsvorlagen steht auch die Datensicherung als eigener Jobschritt bereit. Wie auch bei der Imageerstellung ist es erforderlich, dass der Pfad für die Sicherung aus Clientsicht angegeben wird und erreichbar
ist. Sie können die durchzuführenden Sicherungen aus einer Liste definierter Sicherungsvorlagen auswählen.
Image eines Laufwerks erstellen. Um ein Image zu erstellen, achten Sie bitte darauf,
dass das Ziel aus Sicht des zu sichernden Systems auch erreichbar ist. Aus Kompatibilitätsgründen muss ein großes Image in maximal 2040MByte große Dateien
aufgeteilt werden, da beim Rückspielen eines Images eine dos-Umgebung verwendet
wird.
Citrix Jobschritte. Jobschritte zur Verwaltung eines Citrix Presentation Servers.
Betriebssystem installieren. Imzuge der Änderungen für Windows Vista und der damit
verbundenen Anforderung an die Boot-Umgebung, steht für die Installation von
Vista und Windows7 auch die Möglichkeit zur Verfügung, über Windows PE
zu booten. Das erforderte eine Erweiterung der Konfigurationsoptionen, unter
anderem bei der Jobdefinition Betriebssystem installieren. In einem ersten Schritt
wählen Sie das zu installierende Betriebssystem sowie in den Optionen, wie die
Partitionierung erfolgen soll. Danach kann das zu bootende Image ausgewählt
werden.
Festplatte vollständig löschen. Mit baramundi Wipe Disk wurde ein Werkzeug entwickelt, um Daten von Rechnern, beispielsweise weil sie ausrangiert oder verkauft
werden sollen, vollständig zu löschen. Der Löschvorgang erfolgt dabei durch Überschreiben der Sektoren mit den Werten 00 beziehungsweise FF. Geben Sie an, welche
Festplatte gelöscht werden soll, und wählen Sie den zu verwendenden Modus:
•
•
•
•
•
•
•
•
Gleiches Muster schreiben,
Alternierendes 00/FF Muster schreiben,
Zufällige Daten schreiben,
US DoD 5220-22.M/US DoD 5220-22.M (short),
Peter Gutmann,
rc m p ts s i t op s - i i,
Deutscher vs i tr-Standard,
Bruce-Schneier
Daten aus Sicherung wiederherstellen. Bei der Datenwiederherstellung besteht die Möglichkeit, das Verzeichnis zur Datensicherung frei zu wählen. Außerdem kann durch
Wahl der Option Wiederherzustellende Daten manuell wählen über einen Folgedialog
festgelegt werden, welche der gesicherten Daten wiederhergestellt werden sollen.
Laufwerk aus Image wiederherstellen. Auch beim Zurückspielen eines Images muss der
Pfad, auf dem es liegt, aus Sicht des Clients angegeben werden und erreichbar
sein. Setzen Sie die gewünschten Optionen und wählen Sie zum Abschluss die zu
verwendende Boot-Umgebung aus, sofern der Start über das Netzwerk erfolgen
soll. Wie auch beim Starten eines Bootimages, handelt es sich beim über den
Server initiierten Systemneustart um einen erzwungenen Bootvorgang, der eventuell
Datenverluste nach sich ziehen kann.
PXE Image booten. Über diesen Jobschritt besteht die Möglichkeit, ein Image zu
booten. Dies kann dann nützlich sein, wenn zum Beispiel ein bios-Update erstellt
werden soll. Dann kann über diesen Jobstep ein beliebiges, selbst erstelltes Image
gebootet werden. Ist auf dem Zielsystem Windows installiert und zum Zeitpunkt
der Jobausführung gestartet, so kann der Systemneustart über die zugehörige
Option durch den Server veranlasst werden. In diesem Fall wird ein erzwungener
Shutdown durchgeführt; ein installierter baramundi Management Agent ist dafür
nicht erforderlich.
Jobverwaltung |
19
i
Definition: Job. Ein Job (im bms-Kontext) ist ein Arbeitspaket für eine oder
mehrere Aufgaben, welche auf den Zielsystemen ausgeführt werden sollen.
Jobvoraussetzungen. Bitte beachten Sie, dass für einige Jobs Vorbereitungen
zu treffen sind. So muss beispielsweise bei einer Betriebssysteminstallationen
das Betriebssystem zunächst unter OS-Install/Betriebssysteme zur Verfügung
stehen. Ähnliches gilt für Softwareverteilungen und Deploy/Applikationen.
Struktur des Jobknotens
Um bei einer Vielzahl verschiedener Aufgaben nicht den Überblick zu verlieren
ist es sinnvoll, die Jobs innerhalb einer Struktur zu verwalten. Empfehlenswert
ist eine Struktur, die zum Beispiel eine Trennung nach den Hauptaufgaben Inventarisierung, Patchverteilung und Softwareverteilung (vgl.Abb.2–6 linksoben:
Unterknoten der Jobverwaltung) vorsieht.
Sie können eine Struktur einrichten, verändern oder erweitern, indem Sie Ordner
umbenennen, löschen oder neue Ordner hinzufügen. Es ist auch möglich, untergeordnete Ordner zu erstellen. Diese Möglichkeit steht sowohl über die htm l-Ansicht
im Aufgabenbereich zur Verfügung als auch im Kontextmenü der Listenansicht, bei
Wahl des Knotens Jobverwaltung oder einen der untergeordneten Knoten.
Neue Jobs lassen sich ebenso über den Aufgabenbereich oder das Kontextmenü
direkt im ausgewählten Ordner erzeugen. Bereits bestehende Jobs können in der
Listenansicht via Drag&Drop in andere Ordner verschoben werden, auch wenn
diese bereits Clients zugeordnet sind.
Jobeinstellungen und -ergebnisse
Jobs können über verschiedene Vorgehensweisen ausgeführt werden:
• Jobs werden im bmc manuell Clients oder Clientgruppen zugewiesen,
• Jobs werden vom Client aus, über den baramundi Kiosk, angefordert,
• Jobs werden automatisch zugewiesen: Jobausführung bei Clientaufnahme,
• Jobs laufen benutzerbezogen: Jobausführung bei Benutzeranmeldung.
Zeitsteuerung. In der täglichen Praxis gibt es häufig Aufgabenstellungen, die eine zyklische Jobausführung auf den Zielsystemen erfordern, wie zum Beispiel
Patchverteilungen oder Inventarisierungen. Für solche Aufgaben lassen sich Jobs
auch zeitgesteuert planen. So ist es beispielsweise möglich, Installationen während
betriebsschwachen Zeiten durchzuführen.
Diese Konfiguration kann entweder während der Joberstellung
durchführt werden, indem Sie den
Expressmodus deaktivieren, oder
über die Eigenschaften bereits angelegter Jobs. Die Eigenschaftsseiten erreichen Sie sowohl über
das Kontextmenü als auch über
den Aufgabenbereich, wenn Sie
einen Job ausgewählt haben.
Im Kontextmenü eines Jobs unter
Eigenschaften befinden sich im ReAbbildung 2–8: Jobgültigkeit
gister Allgemein die Optionen Gültigkeit und Intervall. Unter Gültigkeit können Sie festlegen, in welchen Zeiträumen
der Job ausgeführt werden soll. So ist es möglich ein Start- und Enddatum oder die
Zeiten festzulegen, zu denen Jobs ausgeführt werden.
•
•
•
•
Nicht einschränken: Job gilt zu jeder Zeit.
Alle Tage gleich: Job gilt täglich, zu einer bestimmten, eingestellten Zeit.
Werktage und Wochenende setzen: Job gilt Montag bis Sonntag.
Individuell setzen: Für jeden Wochentag gelten individuelle Zeiten.
Die gelben Regler (Abb.2–8) kennzeichnen den gültigen Zeitraum. Sie lassen sich
verschieben, indem Sie mit der Maus die obere/untere Kante greifen und mit gedrückter Maustaste Start oder Ende nach oben/unten verschieben. Zusätzliche
Regler lassen sich definieren, indem Sie mit gedrückter linker Maustaste einen Regler in einem freien Bereich aufziehen. Die so definierten Tageszeiten gelten natürlich
nur innerhalb des unter Gültigkeit definierten Bereichs. Darüber hinaus besteht die
Möglichkeit, auch Intervalle für einen Job zu definieren. So ließe sich beispielsweise
festlegen, dass ein Job viermal wiederholt werden soll, und zwar jeweils Mittwochs
und Freitags um 20.00 Uhr. Wählbar sind:
•
•
•
•
an bestimmten Wochentagen,
an jedem Ersten des Monats,
an jedem 15.des Monats,
jede x-te Minute/Stunde/Tag.
Jobverwaltung |
21
Abbildung 2–9: Benennung
Abbildung 2–10: Wahl der Vorlage
Wenn Sie die Option unbegrenzt setzen, wird der Job entsprechend der hier vorgenommenen Konfiguration wiederholt.
Client-/Serverinteraktionen. Für sämtliche Jobs kann über die Registerkarte Allgemein
festgelegt werden, wie die Ausführung erfolgen soll. Dazu können Sie den Jobtyp
festlegen, Abmeldungen einrichten und anweisen, was nach erfolgter Jobausführung
weiter geschieht (Abb.2–9).
Aktiv (Server kontaktiert Clients). Es wird, sofern das Zielsystem erreichbar und in
Betrieb ist, der Job vom Server an den Client adressiert und ausgeführt.
Aktiv mit Wake-On-Lan. Ist das Zielsystem erreichbar, aber nicht in Betrieb, wird
vom Server ein Wake-Up-Signal ans Zielsystem gesendet, um einen Betriebssystemstart zu initiieren.
Passiv (Server wartet auf Kontakt durch Client). Der Server versucht nicht den Client zu erreichen, sondern wartet auf Kontakt.
Aktiv auf online Clients. (empfohlen) Kam das letzte Announce-Signal binnen der
doppelten Announce-Zeit (via Voreinstellung 30 Minuten) beim Server ein,
betrachtet dieser den Client als online.
Sollte auf einem Zielsystem ein Anwender angemeldet sein, können Sie im Register
Erweitert festlegen, wie in dieser Situation (Abb.2–10) verfahren werden soll:
• Anwender nicht abmelden. (Standard)
• Anwender normal abmelden. Sämtliche Applikationen werden geschlossen,
nicht gespeicherte Dokumente können gesichert werden.
• Anwender erzwungen abmelden. Alle Prozesse werden beendet, der Benutzer
hat nicht mehr die Möglichkeit, geöffnete Dokumente noch zu sichern.
Darüber hinaus können Sie mit folgenden Optionen festlegen, was nach erfolgter
Ausführung des Jobs auf dem Zielsystem geschehen soll: Keine zusätzliche Aktion
(Standard), Screensaver aktivieren (ab Windows 2000), System herunterfahren, System
herunterfahren, wenn per WOL geweckt: Wenn Sie möchten, dass der angewiesene
Job nach der Ausführung aus der Jobdefinition entfernt wird, können Sie dies
festlegen, indem Sie die Option Nach erfolgter Ausführung Target aus Job entfernen
aktivieren oder das System neu starten.
Jobergebnisse. Das baramundi Management Center informiert laufend über die
Zustände der initiierten Jobs. Dabei werden vier Zustände unterscheiden:
Warte auf Client: Die Verbindung zum Zielsystem ist nicht hergestellt.
Job lief fehlerfrei: Der Job wurde erfolgreich durchgeführt.
Warnung: Das System warnt vor unerwarteten Zuständen.
Job lief auf Fehler: Der Job wurde nicht erfolgreich abgeschlossen.
Die Jobzustände werden sowohl in der Jobansicht im Register Zielsysteme, als auch
in der Clientansicht unter Jobs angezeigt.
Je nach den Ergebnissen einer Jobdurchführung, kann
über den Aufgabenbereich entschieden werden, wie weiter verfahren werden soll. Die entsprechende Auswahl
ist soweit selbsterklärend. Einzig die Auswahl Jobziele
OK setzen verdient nähere Betrachtung. Unter Nutzung
dieser Funktion ist es möglich, Jobs, die nicht ordnungsgemäß durchliefen, dennoch als korrekt zu markieren.
Das ist beispielsweise dann sinnvoll, wenn fehlerhafte
Jobs vom Administrator korrigiert wurden.
Abbildung 2–11: Auswahl
Jobverwaltung |
23
Abbildung 2–12: Wahl des Wizards
Abbildung 2–13: Pfadauswahl
Ein Beispiel
Im Folgenden soll anhand eines Beispiels die Funktionsweise der Jobverwaltung
kurz demonstriert werden. Dazu wird eine Applikation – der Editor Notepad+ – an
ein Zielsystem verteilt.
Installationsdateien auf DIP kopieren. Um Software über baramundi zu verteilen, muss
diese dem dip zunächst zur Verfügung gestellt werden. Laden Sie sich dazu den
Editor aus dem Internet herunter* und kopieren Sie die Anwendung in das entsprechende dip-Verzeichnis.
Applikation in Deploy anlegen. Nun muss Notepad im Modul Deploy angelegt werden.
Wählen Sie dazu unter Deploy/Applikationen—Neu—Applikation und im sich daraufhin öffnenenden Dialog (Abb.2–12) die Option Application Automation Wizard
verwenden. Anschließend ist der Pfad (Abb.2–13) zum Editor im dip-Verzeichnis
anzugeben.
Klicken Sie sich durch die nachfolgenden Dialoge und schließlich auf Fertigstellen.
Der Notepad befindet sich daraufhin unter Deploy/Applikationen, zur Verteilung
bereit.
Softwareverteiljob erstellen. Nachdem die Software dem System zur Verfügung steht,
kann nunmehr ein entsprechender Job zur Verteilung des Editors erstellt werden.
*
http://notepad-plus.sourceforge.net/de/site.htm
Abbildung 2–14: Wahl des Jobschritts
1.
2.
3.
4.
5.
Abbildung 2–15: Wahl der Applikation
Wählen Sie Jobverwaltung—Neu—Job
Benennen Sie den Job und übernehmen Sie die restlichen Einstellungen.
Wählen Sie nun die erste Option (Abb.2–14) Software verteilen.
Im Auswahlmenü markieren Sie (Abb.2–15) die gewünschte Applikation.
Schließen Sie die Joberstellung über Fertig stellen ab.
Der Job steht damit zur Verteilung im Knoten Jobwaltung zur Verfügung. Hier kann
der Job nun jederzeit weiterbearbeitet, gelöscht oder eben Zielsystemen zugewiesen
werden.
Job einem oder mehreren Clients zuweisen. Der Job ist nun bereit, an Zielsysteme übergeben zu werden. Das kann entweder über das Kontextmenü durch Anwahl der
Einträge Clients zuordnen oder via Drag&Drop auf den Client oder die Clientgruppe geschehen. Es ist ebenso möglich die entsprechenden Clients auf den Job zu
schieben. Nach der Bestätigung wird der Job ausgeführt.
Benutzerbezogene Jobausführung
Die Vorteile einer benutzerbezogenen Jobausführung liegen auf der Hand: Aktionen
sind nicht nur für einen bestimmten Rechner ausführbar, sondern können darüber
hinaus auch für einen bestimmten, am Rechner angemeldeten, Anwender veranlasst
werden. Das heißt, die Ausführung erfolgt bei der Anmeldung eines bestimmtem
Benutzers (oder einer Benutzergruppe) oder aber im laufenden Betrieb, wenn der
entsprechende Benutzer am Client angemeldet ist.
Jobverwaltung |
25
Die Theorie
Bei einer Softwareverteilung sähen mögliche Szenarios so aus: Einem Graphiker in
der Technischen Redaktion fällt der Rechner aus. In einem solchen Falle muss der
Systemadministrator gar nicht mehr vor Ort erscheinen: Der Mitarbeiter bekommt
einen neuen Rechner, meldet sich an und wird danach automatisch mit seiner
Software ausgestattet. Oder: Zur Ergänzung des Skripts einer Produktdokumentation recherchiert der Graphiker – nennen wir ihn Thadeus Punkt – (wir werden
auf den Herrn noch zurückkommen) in der Entwicklungsabteilung seiner Firma.
Meldet sich nun Herr Punkt auf einem der Rechner in der Entwicklung an, werden,
sofern eingestellt, für ihn auch «seine» Programme mitsamt seinen Einstellungen
installiert!
Um Software benutzerbezogen verteilen
zu können, ist es zunächst notwendig,
sämtliche, für Verteilungsjobs in Frage
kommende, Mitarbeiter im System zu
erfassen. Neben anderen Informationen
sind auch Benutzer in Windowsdomänen
über den Verzeichnisdienst Active Directory (AD) erreichbar. Insofern sollen nunmehr die Benutzerdaten aus dem AD übernommen werden. Zu diesem Zweck wird
ein entsprechender Synchronisierungsjob
eingerichtet. Im Dialog des Kontextmenüs
von Verwaltung/Active Directory Synchronisierung unter dem Pfad Neu—Active DiAbbildung 2–16: Synchronisierungsjob
rectory Synchronisierungsjob (Abb.2–16)
sind die dafür notwendigen Informationen anzugeben.
•
•
•
•
Name: Geben Sie dem Job (wie üblich) einen aussagekräftigen Namen.
Typ: Hier ist zur Zeit nur die Benutzersynchronisierung* möglich.
Quelle: Die Datenquelle ist über die Schaltfläche wählbar (Abb.2–16).
Intervall: Hier ist ein Zeitraum zur Aktualisierung der Benutzerdaten ein-
* In einer der kommenden Veröffentlichungen wird es an dieser Stelle auch
eine Maschinensynchronisierung geben. Dazu stehen dann auch die beiden im
Moment noch inaktiven Felder «Ziel» und «Modus» zur Verfügung.
stellbar: entweder als Uhrzeit, wie 18:30 oder als Tagesangabe Mo bis So.
Verknüpfungen sind über / und ; möglich. Bsp.: 15:00/Mo;18:00/Di für Montags 15.00 Uhr und Dienstags 18.00 Uhr.
• Leere Organisationseinheiten nicht synchronisieren: Mit Aktivierung dieser Option werden leere Organisationseinheiten bei der Synchronisierung ignoriert.
• Filter: Bietet die Möglichkeit einer Selektion über l d ap-Syntax.
Nach Abschluss und Bestätigung Ihrer Eingaben mit Ok, liegt der eben erstellte Job
unter Verwaltung/Active Directory Synchronisierung. Hier ist nun im Kontextmenü
des Jobs Jetzt ausführen zu wählen oder eben das eingestellte Intervall abzuwarten,
um die Synchronisierung zu starten. Im Ergebnis werden die Benutzer und Gruppen
unter Umgebung/Active Directory Benutzer&Gruppen eingetragen. Mit der Übernahme dieser AD-Benutzerdaten ist es nunmehr möglich, Jobs auch benutzerbezogen
durchzuführen.
i
Nicht der Name des Jobs als vielmehr die in der Quelle benannte Domäne
werden unter Active Directory Benutzer & Gruppen geführt.
Jobzuordnung. Grundsätzlich lassen sich Jobs benutzerbezogen entweder am Job
selbst oder aber am entsprechenden Benutzer oder der Benutzergruppe zuweisen.
Dabei ordnen sich selbige nach der AD-Logik, nämlich in:
1. Benutzer
2. Rechtegruppen
3. Organisationseinheiten
Ein Benutzer kann Mitglied in einer oder mehrerer Rechtegruppen sein. Diese können ihrerseits Mitglieder in anderen Rechtegruppen sein – insofern sind bezüglich
der Struktur komplexe Konstrukte denkbar. Jobs sind auf zwei Arten zuordenbar.
Unter Umgebung in den Active Directory Benutzer & Gruppen oder der Logischen
Gruppierung im Kontextmenü: Alle Aufgaben—Job(s) zuordnen den Job anweisen
oder in der h tm l-Ansicht dem entsprechenden Benutzer/der entsprechenden Rechtegruppe im Bearbeiten-Menü am Eintrag Job(s) zuordnen. Im Register Zugeordnete
Jobs der h tm l-Ansicht werden alle auf diesem Wege zugeordneten Jobs angezeigt.
Genausogut ist es möglich, am Job selbst eine benutzerbezogene Ausführung zu
veranlassen. Dazu markieren Sie einfach den Job mit der Maus und wählen in
Jobverwaltung |
27
dessen Kontextmenü den Eintrag Benutzer zuordnen. Im daraufhin erscheinenden
Dialog ist dann lediglich noch der Benutzer oder aber die Rechtegruppe anzugeben
und das Ganze mit Weiter zu bestätigen.
i
Beachten Sie in diesem Zusammenhang auch die bequeme Suche über das
Suchfeld rechts. Hier genügt es, ein paar Zeichen des gesuchten Benutzers
oder der gesuchten Gruppe einzugeben und das System findet dazu inkrementell jeden passenden Eintrag. Um diesen dann zu wählen, ist ein
Häkchen an die Checkbox des entsprechenden Benutzers oder der Benutzergruppe zu setzen – die einfache Markierung des Treffers genügt bei der
Einfachauswahl nicht. Es sind auch mehrere Benutzer/Gruppen wählbar.
Natürlich ist auch hier eine Auswahl über das Aktionen-Menü mittels Benutzer
zuordnen möglich. Im Ergebnis erscheint der selbe Dialog, wie bei der Zuordnung
über Benutzer oder Rechtegruppen. Insofern gilt es zwischen direkt oder indirekt
zugewiesenen Jobs zu unterscheiden: Direkt, wenn der Job einem Benutzer zugewiesen ist; indirekt, wenn dieser Benutzer einen Job über eine Gruppenmitgliedschaft
zugewiesen wird.
In diesem Zusammenhang sei auch auf den Knoten Dynamisch nachgeladene Benutzer hingewiesen. Da sich am Client nur Benutzer anmelden, müssen diese auch
vorliegen. Sofern durch eine AD-Synchronisierung nur Rechtegruppen abgerufen
wurden, lädt das System diese automatisch nach und speichert sie in diesem Knoten.
Jobausführung. Adressaten benutzerbezogener Jobs (Benutzer und Rechtegruppen)
sind aus dem Actice Directory übernommen, zudem wurden ihnen Jobs zugewiesen, nur zur Ausführung kamen diese noch nicht. Dies geschieht im Falle einer
Softwareverteilung automatisch, eben nach Anmeldung der jeweiligen Benutzer,
oder – für den Fall der entsprechende Nutzer ist bereits angemeldet – relativ zeitnah
zur Jobzuordnung. Doch ist das ja mitunter gar nicht erwünscht. Oder es sollen,
neben den eigentlichen Anwendungen, auch gleich bestimmte Einstellungen für
die oder den Benutzer übernommen werden. Auch solcherlei «Nebenbedingungen»
können in die benutzerbezogene Jobausführung einbezogen werden.
Benutzereinstellungen. Usersettings sind Einstellungen, die für den oder die Benutzer
bei Verteilungsjobs mit angegeben werden: Textmeldungen, Desktop-Icons, das
Laden bestimmter Vorlagen in den zu verteilenden Programmen und vieles mehr.
Verfasst werden die Skripte im baramundi Development Studio* , einer Entwick*
Eine Einführung in bDS folgt auf Seite 91.
Abbildung 2–17: Benutzereinstellungen
Abbildung 2–18: Jobausführung
lungsumgebung, die im Lieferumfang der bms mit enthalten ist. Sofern ein solches
Skript zur Verfügung steht und zur Anwendung käme, ist dem System (a) anzugeben für welche Applikation die Usersettings mitgeliefert werden sollen, (b) wo diese
Usersettings zu finden wären und schließlich (c) für wen genau die Benutzereinstellungen überhaupt anzuwenden seien.
Da benutzerbezogene Jobausführungen in erster Linie hinsichtlich Softwareverteilungen Anwendung finden, werden Usersettings auch mit der zu installierenden
Software verteilt, also unter Deploy/Applikationen in den Anwendungsigenschaften
im Register Installation in der entsprechenden Applikation eingestellt. In diesem
Register ist im unteren Scrollfeld unter Benutzereinstellungen/baramundi Deploy
Skript der Pfad zum Skript anzugeben (Abb.2–17) und zu übernehmen.
Damit nun die Usersettings bei einer benutzerbezogenen Jobausführung für einen
bestimmten Benutzer Berücksichtigung finden, ist es notwendig, die Option Usersettings bei Softwareverteilung benutzerspezifisch ausführen im Kontextmenü der Jobs
unter Eigenschaften/Allgemein zu aktivieren. Andernfalls gelten die Usersettings für
jeden Benutzer, das heißt: Jeder auf diesem Client angemeldete Benutzer bekommt
diese Benutzereinstellungen.
Jobverwaltung |
29
Einschränkung der Jobausführung. Um die Ausführung benutzerbezogener Jobs auch allgemein kontrollieren zu können, sind clientseitig einige globale Einstellungen bei
der Ausführung möglich. Im Kontextmenü Eigenschaften der Clientrechner unter
Umgebung/Logische Gruppierung im Register Jobausführung, befindet sich ein Scrollmenü Benutzerdefinierte Jobs mit drei Einstellungen:
• immer ausführen: Unabhängig davon, wer sich an diesem Client anmeldet,
der Job wird (sofern noch nicht geschehen) stets ausgeführt – denken Sie beispielsweise an Rechnerarbeitsplätze in machen Callcentern, Versicherungen
und dergleichen, an denen sich jeden Tag andere Nutzer anmelden.
• nie ausführen: Das Gegenteil, also ein Rechner, der praktisch allen zur Verfügung steht – wie zum Beispiel der Präsentations-PC im Besprechungsraum.
• nur für registrierten Benutzer ausführen: Mit dieser Einstellung wird geregelt,
dass nur und ausschließlich für den im System als Hauptbenutzer eingetragenen Benutzer ein Job ausgeführt wird.
Doch wer ist der Hauptbenutzer und wie
und wo ist ein solcher einzutragen? Bleiben
Sie dazu im gleichen Dialog, nämlich Umgebung/Logische Gruppierung in den Clienteigenschaften, wechseln Sie lediglich zum
Register Allgemein und darin zu Registrierter
Benutzer (Abb.2–19). Via Voreinstellung ist
Hauptbenutzer, wer sich erstmalig am entsprechenden Clientrechner anmeldet; Einstellung: nächsten angemeldeten Benutzer
als Registrierten eintragen. Für den weiteren
Rechnerbetrieb springt die Einstellung auf
Registrierten Benutzer manuell eingeben.
Ebenfalls möglich: Die Wahl der beiden Extrema Registrierten Benutzer nicht verwenden
Abbildung 2–19: Registrierter Benutzer
oder immer aktuell angemeldeten Benutzer
als registrierten eintragen. Im ersten Fall gibt es keinen registrierten Benutzer; im
zweiten Fall ist jeder, der sich am Client anmeldet der Hauptbenutzer.
Für die Funktionen zur benutzerbezogenen Jobausführung, steht ein Register – speziell für die damit verbundenen Benutzereinstellungen – in der htm l-Ansicht der
Abbildung 2–20: Historieregister
baramundi Management Suite zur Verfügung: die Historie. Dieses Register soll den
Systemadministrator bei der Steuerung und Auswertung von Usersettings unterstützen. Die Historie finden Sie in den h tm l-Ansichten sowohl auf den Clientebenen
als auch für Benutzer unter Umgebung/Active Directory Benutzer&Gruppen. In allen
Ansichten lassen sich die Status der verteilten Benutzereinstellungen einsehen.
Register Ubds auf Jobebene. Hier werden vom System sämtliche fehlerhaft gelaufenen
Benutzereinstellungen eingetragen. Der zusätzlich angegebene Job dient in diesem
Register lediglich der Übersichtlichkeit, damit jederzeit nachvollzogen werden kann,
mit welchem Job die fehlerhaften Benutzereinstellungen verknüpft sind. Es ist
also vorstellbar, dass die Jobs fehlerfrei ausgeführt wurden und später – nämlich
genau dann, wenn sich der betreffende Benutzer erstmalig nach Jobausführung an
seinem System anmeldet – dessen Benutzereinstellungen auf einen Fehler laufen.
Dann notiert das System Job, Benutzer, Applikation und den Fehlerstatus mit
Datum und Uhrzeit seines Auftretens. In der htm l-Ansicht sind die notierten
Jobverwaltung |
31
Fehlerläufe der Usersettings darüber hinaus editierbar: Sie können solcherlei Fehler
im htm l-Menü über den Eintrag Jobziele OK setzen entweder (beispielsweise wegen
Geringfügigkeit) akzeptieren oder aber über den Punkt Jobziele fortsetzen noch
einmal starten.
!
Die Usersettings müssen für eine Anwendung vor Jobausführung konfiguriert werden. Ist die Anwendung erst einmal ohne Usersettings verteilt
worden, so muss für den Fall einer nachträglichen Ergänzung auch die
Software noch einmal verteilt werden.
Register Historie auf Client- und Benutzerebene. In den Benutzer- und Clientansichten unter
Umgebung wird, neben den fehlerhaften Skriptverarbeitungen, auch eine Chronik,
der für Benutzer respektive Clientrechner gelaufenen Jobs, angelegt – und zwar je
nach Perspektive der entsprechenden Ansicht.
User: Welcher Job wurde für diesen User auf welchem Client ausgeführt?
Client: Welcher Job wurde auf diesem Client für welchen User ausgeführt?
Das heißt, ein Administrator kann sich zu jeder Zeit ein genaues Bild darüber
verschaffen, welcher Benutzer auf welchem Rechner welche Jobs auslöste. Sofern
zum Beispiel die Meldung aus einer Abteilung bezüglich einer noch nicht installierten Software nebst der dazugehörigen Benutzereinstellungen eintrifft, ist es
mit wenigen Mausklicks möglich, in Frage kommende Ursachen einzusehen und
gegebenenfalls zu korrigieren.
Die Praxis
Das waren eine ganze Menge Informationen zu den Funktionen der benutzerbezogenen Jobausführung. Im Folgenden soll zum Zwecke der Veranschaulichung
des Ganzen ein Beispiel dienen: Der eingangs erwähnte Thadeus Punkt, Graphiker
in der eben geschaffenen Technischen Redaktion Ihres Unternehmens. Ziel soll
es sein, am Tage des Dienstantritts von Herrn Punkt, diesem, gleich nach seiner
Rechneranmeldung, den Acrobat Reader zu installieren und ihm das Vorhandensein
des selben durch ein entsprechendes Icon auf seinem Desktop kundzutun; also
Software und Benutzereinstellungen zu verteilen.
Vorbereitung. Besagter neuer Graphiker, nebst seiner Abteilung, sollte über das AD,
je nach den Intervalleinstellungen (die es natürlich geben muss, es wäre ja auch vorstellbar das Listenfeld Intervall ohne Eintrag zu belassen), unter Umgebung/Active
Directory Benutzer&Gruppen bereits erfasst sein. Wir wollen jedoch davon ausgehen, als seien die Kreativen dergestalt von den Produktiven getrennt, dass sie eine
eigene Domäne – im Beispiel testlan.net – benutzen.
1. Öffnen Sie den Synchronisierungsjobdialog (Verwaltung/Actice Directory Benutzer & Gruppen—Neu—Active Directory Synchronisierungsjob.
Der Name sei schlicht testlan.net, der Typ ist vorgegeben, nämlich die Benutzersynchronisierung. Unter der Quelle ist über eine Schaltfläche der Pfad zur gewünschten
Domäne anzugeben. Diese Domäne soll sich jeden Tag um 18.00 Uhr aktualisieren:
Die Einstellung lautet also 18:00. Die Option Leere Organisationseinheiten nicht
synchronisieren wird in der aktiven Voreinstellung belassen, um leere Verzeichnisse
von der Synchronisierung auszuschließen. Auf Filtereinstellungen wird verzichtet.
2. Treffen Sie Ihre Einstellungen und bestätigen Sie diese mit Ok.
Der Synchronisierungsjob testlan.net liegt nunmehr unter Verwaltung/Active Directory Synchronisierung zur Ausführung bereit.
3. Markieren Sie den eben erstellten Job und wählen Sie in dessen Kontextmenü
Jetzt ausführen.
Nach erfolgreicher Beendigung des Jobs, steht die neue Domäne testlan.net unter
Umgebung/Active Directory Benutzer&Gruppen zur weiteren Bearbeitung zur Verfügung. Darin enthalten: der Bereich Dokumentation/Redaktion/Thadeus Punkt, eben
unser Graphiker.
Ausführung. Nun, da der Benutzer im System erfasst ist, kann beispielsweise Software benutzerbezogen direkt an ihn verteilt werden. Dazu ist ein entsprechender
Job zu erstellen. Die Anwendung, Acrobat Reader, stehe bereits im Modul Deploy
zur Verfügung, muss nur noch um die Benutzereinstellung – das Icon auf dem
Desktop – ergänzt werden. Der Job selbst (Acrobat Reader installieren) wurde
bereits angelegt. Die benutzerbezogene Jobausführung muss aktiviert werden.
4. Öffnen Sie im Kontextmenü der Anwendung (hier der Acrobat Reader) unter
Deploy/Applikationen die Eigenschaften und wählen Sie im Register Installation
Jobverwaltung |
33
Abbildung 2–21: bDS-Skript ausführen
Abbildung 2–22: Usersettings ausführen
die Benutzereinstellungen im unteren Scrollfeld. Unter baramundi Deploy
Skript geben Sie den Pfad zu den gewünschten Benutzereinstellungen an und
bestätigen Ihre Auswahl mit Ok (Abb.2–21).
Damit werden diese Benutzereinstellungen zusammen mit der Anwendung verteilt,
im Moment noch an jeden Benutzer, der sich auf dem Rechner von Herrn Punkt
anmeldet. Um nun das Icon wirklich nur unserem Graphiker auf den Desktop zu
legen, muss dies im Job selbst angegeben werden.
5. Erstellen Sie einen Softwareverteiljob (Acrobat Reader), der den Acrobat
Reader mit Usersettings installiert.
6. Wechseln Sie in das Kontextmenü Eigenschaften dieses Jobs und aktivieren
Sie im Register Allgemein die Option Usersettings bei Softwareverteilung benutzerspezifisch ausführen (Abb.2–22).
Dieser Job ist nun noch dem Thadeus Punkt zuzuordnen. Das soll hier im Beispiel
direkt am Benutzer erfolgen.
Abbildung 2–23: Historie-Register auf Benutzerebene
7. Markieren Sie den gewünschten Benutzer unter Umgebung/Active Directory
Benutzer&Gruppen/Dokumentation/Thadeus Punkt.
8. Wählen Sie im Bearbeiten-Menü den Eintrag Job(s) zuordnen.
9. Aktivieren Sie den gewünschten Job (hier Acrobat Reader) mit einem Häkchen
und bestätigen Sie Ihre Einstellungen mit Ok.
Damit wird der Acrobat Reader bei der nächsten Anmeldung des Graphikers nicht
nur installiert, sondern darüber hinaus liegt auch gleich das entsprechende Icon
zum Start der Anwendung auf seinem Desktop.
Ergebnisse. Sämtliche, diesen Benutzer betreffenden, Aktivitäten, lassen sich übrigens sehr gut in der Benutzer-htm l-Ansicht einsehen. Markieren Sie also beispielsweise Thadeus Punkt, so werden dessen Status in der Active Directory, seine
zugeordneten Jobs sowie die auf Fehler gelaufenen Benutzereinstellungen und ei-
Jobverwaltung |
35
ne Chronik sämtlicher benutzerbezogener Jobs in den Registern Active Directory,
Zugewiesene Jobs sowie Historie angezeigt.
Wir wollen beispielhaft annehmen, das Deploy Skript für das Desktop-Icon sei
fehlerhaft gewesen: Der Job selbst liefe fehlerfrei durch; die Benutzereinstellungen
jedoch nicht.
Wie in der Abbildung 2–23 zu sehen: Im Register Historie der Benutzers Thadeus
Punkt lief das Deploy Skript auf einen Fehler. Es bestünde nunmehr die Möglichkeit
diesen Fehler einfach durch den Vermerk Jobziele OK setzen zu akzeptieren – die
Fehlermeldung verschwände dann; oder aber über die Auswahl Jobziele fortsetzen
die Benutzereinstellungen abermals diesem Benutzer zuzuordnen.
Automatische Jobzuweisung/Jobvoraussetzungen
Es ist zudem möglich, Jobs automatisiert auszuführen. Automatisierungen dieser
Art können Sie analog zur Kriterienbestimmung bei den Voraussetzungen, über
die Registerkarte Automatische Zuweisung veranlassen. Allen Zielsystemen, die den
Bedingungen genügen, wird der Job dann automatisch zugeordnet.
Um Jobs zu automatisieren, sind in den Jobeigenschaften im Register Automatische
Zuweisung entsprechende Bedingungen
zu deklarieren. Über den Auswahlbuttom
können diese Bedingungen hinzugefügt,
verknüpft oder gelöscht werden. Mittels
der Voreinstellung * = * ist über die Auswahl des ersten Sternchens die Kategorie
der Bedingung zu wählen. Ein Klick auf
das Gleichheitszeichen lässt logische Operatoren wählen. Die Auswahl des hinteren
Sternchens öffnet ein frei editierbares Listenfeld, zur Definition einer Bedingung.
Im Ergebnis dessen werden automatisch
Abbildung 2–24: Autom.Jobzuweisung
zugewiesene Jobs ohne explizite Zuweisung zum Zielsystem beim Zutreffen der gewählten Bedingung ausgeführt.
!
Die gemeinsame Verwendung mit der Option Nach erfolgreicher Ausführung
Target aus Job entfernen, kann zu unerwünschten Ausführungen kommen.
Jobvoraussetzungen
Praktisch die Umkehrung der automatischen Jobausführung ist das Eigenschaftsregister Voraussetzungen. Darin nämlich werden – übrigens auf die selbe Art und
Weise wie unter Automatische Zuweisung – Kriterien definiert, die erfüllt sein müssen, damit ein Job überhaupt startet. Das System prüft also nach Initiierung eines
Jobs zunächst, ob hier Bedingungen dagegen sprechen. Ist das der Fall, gibt die
Oberfläche eine entsprechende Fehlermeldung aus.
baramundi Kiosk
Mit dem baramundi Kiosk erhalten Anwender die Möglichkeit, Jobs ganz einfach
selbst anzufordern. Auch hier kann der Administrator vorher festlegen, wer auf
welchen Systemen oder Gruppen von Systemen welche Jobs ausführen darf.
Der baramundi Kiosk wurde als htm l-Anwendung entwickelt. Die Vorteile liegen
auf der Hand: Zum einen benötigt der Client keine weitere Komponente, um
den baramundi Kiosk nutzen zu können, zum anderen ist eine Integration des
baramundi Kiosks in das Corporate Design Ihrer Firma möglich.
Jobs, die Sie in der Jobverwaltung erstellt haben, können für sämtliche Gruppen
und Rechner freigeschaltet werden. Diese Einstellungen sind in den Eigenschaf-
Abbildung 2–25: Kiosk-Aktivierung
Abbildung 2–26: Kiosk-Jobfreigabe
Jobverwaltung |
37
ten der Root-Gruppe (Abb.2–25) unter Verwaltung/Server/Konfiguration/Webserver
vorzunehmen. Via Voreinstellung sind diese Optionen aktiv.
Im Register Anforderbare Jobs der Eigenschaften von Gruppen (Abb.2–26) und
Rechnern können Sie manuell festlegen, welche Jobs im baramundi Kiosk verfügbar
sein sollen. Die Eintragungen in den Gruppen werden auf die untergeordneten
Gruppen und Rechner vererbt und können nicht deaktiviert werden. Über die
Schaltflächen Hinzufügen und Entfernen ist es möglich festzulegen, welche Jobs
verfügbar sein sollen.
Der Kiosk ist in den Standardeinstellungen durch ein Kennwort geschützt (Benutzer:
baramundi; Kennwort: kiosk). Wenn Sie die Webservereigenschaften aufrufen, können Sie die Parameter für den baramundi Kiosk dort einstellen. Auf den Rechnern
kann mittels Doppelklick auf das baramundi Symbol der Kiosk aufgerufen werden.
Über Weiter zur Jobauswahl gelangen Sie zum Jobauswahlfenster.
Aktivieren Sie die Kontrollkästchen der zu installierenden Jobs, um Ihre Auswahl zu
treffen. Klicken Sie auf Ausgewählte Jobs überprüfen und ausführen, um vom System
prüfen zu lassen, ob eine Installation für Ihr System aufgrund der eingestellten
Optionen an der Applikation erlaubt ist. Anschließend erhalten Sie eine Übersicht,
welche Jobs auf Ihrem System ausgeführt werden.
Wenn Sie nun auf Starten klicken, werden die aufgelisteten Jobs auf Ihrem Rechner ausgeführt. Der Benutzer erhält, je nachdem wie der Job definiert ist, ein
Informationsfenster über die Ausführung des angeforderten Jobs.
Umgebung
Ebenso wie Sie über die Jobverwaltung Ihre Jobs strukturieren und konfigurieren
können, verwalten Sie über die Umgebung Ihre Zielsysteme. Gerade die Möglichkeit
der Gruppierungen von Clientsystemen, entlastet die Systemadministration.
Logische Gruppierung
Die Struktur kann frei angelegt und somit den Anforderungen Ihrer Infrastruktur
beziehungsweise den Aufgabenfeldern der Benutzer entsprechend angepasst werden.
Vorstellbar ist eine Aufgliederung nach Standorten oder anderen lokalen Gegebenheiten, wie zum Beispiel Gebäuden oder Stockwerken. Wie bei der Ordnerstruktur
in der Jobverwaltung, ist es möglich Untergruppierungen anzulegen.
Abbildung 2–27: Umgebung/Logische Gruppierung
Die Einstellungen werden dabei auf untergeordnete Gruppierungen und die dort
enthaltenen Zielsysteme weitervererbt (von oben nach unten), falls dem nicht gesonderte Einstellungen entgegen stehen. Sofern also zum Beispiel in den Eigenschaften
des Knotens Logische Gruppierung unter Allgemein ein Pfad zum dip angegeben ist,
so greifen auch die darunter hängenden Clientgruppen und Clients auf diesen dip
zu, es sei denn, es werden in den Untergruppen explizit andere dip-Pfade angegeben.
!
Eine Ausnahme bei der Vererbung bilden die in der Registerkarte Variablen
eingetragenen Werte. Die hier vorhandenen Einträge werden ausschließlich
auf die in dieser Gruppe enthaltenen Zielsysteme vererbt, nicht an in dieser
Gruppierung enthaltenen Untergruppierungen.
Da der zu verwendende dip also bereits in der übergeordneten Gruppe angegeben
wurde, ist eine weitere Angabe in der untergeordneten Gruppe nicht notwendig,
sofern dieser nicht abweicht. Das entsprechende Listenfeld verbleibt leer.
Umgebung |
39
Dynamische Gruppen
Dynamische Gruppen sind temporäre Zusammenfassungen von Zielsystemen nach bestimmten Kriterien, wie Hardwareeigenschaften, installierte Software und dergleichen mehr. Über dynamischen Gruppen können Sie Zielsysteme zusammenfassen, ohne
diese aus den logischen Gruppierungen entfernen
zu müssen. Das kann beispielsweise dann nützlich
sein, wenn Sie auf allen Systemen, auf denen ein Serverbetriebssystem läuft, eine Softwarekomponente
verteilen möchten.
Dynamische Gruppen können Sie anlegen, indem Sie
am Knoten Dynamische Gruppen den entsprechenden Eintrag aus dem Kontextmenü wählen (rechter Mausklick). Ähnlich wie bei der Jobverwaltung
haben Sie auch hier die Möglichkeit, die Struktur
mithilfe von Ordnern übersichtlich* zu gestalten.
Zielsysteme (innerhalb dynamischer Gruppen und
logischer Gruppierungen) können in der mmc wie
folgt dargestellt werden:
• Statisch,
• Management Agent Status,
• Job Status.
Abbildung 2–28: Navigationsbaum
Einstellbar ist die Symbolanzeige für die verschiedenen Status in den Clienteigenschaften im Register Allgemein unter Symboldarstellung.
Die Zuweisung der Kriterien erfolgt analog zur Konfiguration der Kriterien in
den Registereinträgen Automatische Zuweisung† oder Voraussetzungen in den Eigenschaften der Jobverwaltung. Die Zielsysteme, die den definierten Kriterien genügen,
werden bei regelmäßigen Serverscans automatisch in die dynamische Gruppen übernommen. Dynamische Gruppen bilden somit eine Trefferliste für eine Suchanfrage,
ihnen können also Jobs zugewiesen werden.
* Wie in Abbildung 2–28 zu sehen: Sowohl die logischen Gruppierungen als
auch die dynamischen Gruppen wurden funktional benannt und geordnet.
† vgl.dazu Seite III
Weitere Umgebungen
Neben den zuvor behandelten Hauptknoten, sind noch weitere Umgebungen relevant. Diese sollen im Folgenden kurz erläutert werden.
Active Directory Benutzer & Gruppen
Die benutzerbezogenen Jobausführungen erfordern auch eine Umgebungsverwaltung der aus dem Active Directory übernommenen Benutzerdaten. Nach einer
Synchronisierung von Benutzerdaten (Verwaltung/Active Directory Synchronisierung)
stehen diese hier, für benutzerbezogene Jobausführungen, zur Verfügung.
i
In der htm l-Ansicht von Active Directory Benutzer&Gruppen kann entweder nach Organisaionseinheiten oder nach darin enthaltenen Benutzern
gesucht werden. Um an die Benutzerdaten zu gelangen, klicken Sie einfach
auf die entsprechende Organisationseinheit.
Netzwerkumgebung
Die Netzwerkumgebung funktioniert im Wesentlichen wie jene, die Sie von Ihrem Windows-Betriebssystem kennen. Der Vorteil ist einfach der, dass sich aus
dieser Umgebung Clientrechner sehr bequem via Drag&Drop in eine logische
Gruppierung verschieben lassen.
Clientüberwachung
Die Clientüberwachung ist eine Gruppe, in der Clientrechner nach eigenen Kriterien unabhängig von der logischen Gruppierung verwaltet und beobachtet werden
können. Dazu ist jeweils eine neuer Monitor (Neu—Clientmonitor) zu erstellen, in
den dann die entsprechenden Clientrechner verschoben werden können. Einmal
darin, können Clientsysteme – ganz ähnlich wie bei einer Desktopverknüpfung –
wie auch in den anderen Gruppen verwaltet werden. So sehen Sie in der Listenansicht alle zugewiesenen Zielsysteme und die entsprechend verfügbaren Zustände sowie Systeminformationen und Variablen. Analog zu dynamischen Gruppen können
Sie auch einem Clientmonitor Jobs direkt zuweisen. Lediglich ein physikalisches
Löschen ist in der Clientüberwachung nicht möglich.
Umgebung |
41
Arbeitshilfen im Knoten Umgebung
Abschließend sollen noch einige Arbeitsweisen Erläuterung finden, die Ihnen die
Arbeit im Knoten Umgebung erleichtern.
Monitoring – die Übersicht behalten
Je komplexer Ihre Infrastruktur ausgelegt ist, desto wichtiger ist es, einen Überblick
über die Vorgänge in Ihrer Umgebung zu behalten. Aus diesem Grund sind an
allen wichtigen Stellen Ansichten in die Oberfläche integriert worden, die es Ihnen
gestatten, sich schnell und umfassend zu informieren. Im Knoten Jobverwaltung
und den darunter angelegten Ordnern sowie allen logischen Gruppierungen, stehen
Ihnen in der htm l-Ansicht die Register Monitoring, Statistik und Problemfälle zur
Information über den aktuell ausgewählten Knoten zur Verfügung.
Abbildung 2–29: Informationsbereich
Außerdem sehen Sie im Informationsbereich oben eine Kurzzusammenfassung
bezüglich der Status zugewiesener Jobs im ausgewählten Knoten. Die Farbcodierung
sowie Detailinformationen über die Zustände der zugewiesenen Jobs befinden sich
im Register Statistik. Im Register Monitoring erhalten Sie eine Übersicht über den
Status der derzeit geplanten Jobs.
Abbildung 2–30: Register Monitoring
Abbildung 2–31: Register Problemfälle
Im Register Problemfälle befindet sich eine Auflistung aller Zielsysteme unterhalb
des gewählten Knotens, auf denen während der Jobausführung Fehler aufgetreten
sind. Es kann vorkommen, dass Zielsysteme immer wieder Fehler melden, während
der gleiche Job auf anderen Systemen problemlos läuft.
Arbeiten mit Favoriten
Innerhalb des baramundi Management Center besteht zudem die Möglichkeit,
Jobs, logische Gruppierungen oder auch einzelne Zielsysteme als Favoriten zu
verwalten. Diese Funktion ist jedoch nur innerhalb der htm l-Ansicht unterhalb
der Hauptknoten Jobverwaltung und Umgebung verfügbar.
Um einen Job, eine logische Gruppierung oder ein bestimmtes Zielsystem zu den
Favoriten hinzuzufügen, nutzen Sie bitte die Funktion Favorit hinzufügen aus dem
Aufgabenbereich unter Bearbeiten. Angelegte Favoriten befinden sich dann Rootknoten im Register Favoriten (Abb.2–32) Favoriten können sein:
•
•
•
•
Rechner,
Rechnergruppen,
Job,
Jobgruppen.
Diese Ansicht wird alle 10 Sekunden automatisch aktualisiert und listet sämtliche
angelegten Favoriten in der Reihenfolge auf, in der sie angelegt wurden. Dabei ist
jeder einzelne Favorit in der linken Spalte mit einer Verknüpfung versehen, die
Sie direkt zu dem entsprechendem Objekt führt. In der rechten Spalte befinden
sich die Zusammenfassungen der dazugehörigen Informationsbereiche. Natürlich
steht Ihnen auch hier die Möglichkeit offen, mittels eines Linksklicks auf den
Umgebung |
43
Abbildung 2–32: baramundi Management Center/Favoriten
Statusbalken Detailinformationen abzurufen. Die letzten vier Favoriten werden
oben links, im Informationsbereich, angezeigt. Wenn Sie einen Favoriten wieder aus
der Liste entfernen möchten, klicken Sie einfach auf das rote Kreuz rechts neben
dem Favoritennamen.
Drag&Drop – manuelle Ein- und Zuordnung
An vielen Stellen wird innerhalb des baramundi Management Centers Drag&Drop
unterstützt. So ist es beispielsweise möglich, einer Gruppe oder einem einzelnen
Zielsystem einen Job zuzuordnen, indem Sie den Job mit gedrückter linker Maustaste über eine Zielgruppe oder ein Zielsystem ziehen und dort ablegen. In diesem
Fall wird noch eine Sicherheitsabfrage angezeigt, ob Sie diese Zuweisung auch
wirklich vornehmen möchten. Diese Zuweisung funktioniert auch umgekehrt, das
heißt, Sie können Clients auf einen Job ziehen. Zielsysteme, die noch nicht in eine
logische Gruppierung eingeordnet sind oder in einer falschen Gruppierung liegen,
können Sie ebenfalls auf diese Weise verschieben. In einem solchen Fall wird in der
Datenbank lediglich die Verknüpfung aktualisiert.
Wenn Sie hingegen, wie zuvor beschrieben, ein System via Drag&Drop von einer
logischen Gruppierung auf eine dynamische Gruppe oder auf einen Clientmonitor
ziehen, wird hier lediglich eine neue Verknüpfung erzeugt. Das Zielsystem bleibt
weiterhin der logischen Gruppierung zugeordnet.
Drag&Drop stellt eine zusätzliche Möglichkeit dar, Systeme zu erfassen, indem Sie
unter dem Knoten Netzwerkumgebung ein Zielsystem auswählen und über einer
logischen Gruppierung ablegen. Sollte das System bereits in einer anderen Gruppe
enthalten sein, erhalten Sie eine entsprechende Warnung.
baramundi Management Agent
Der baramundi Management Agent ist ein Dienst, der sämtliche Aufgaben verarbeitet, die vom baramundi Management Server zum jeweiligen Client geschickt
werden. Auf den folgenden Seiten erfahren Sie, wie Sie diesen Dienst installieren
und einen Client über baramundi verwalten.
Systemerfassung
Aus Sicht der baramundi Management Suite ist jedes System, das über baramundi
verwaltet werden soll, ein Client; ungeachtet dessen, ob es sich bei einem Zielsystem
um eine Workstation oder ein Serverbetriebssystem handelt. Sie werden daher der
Einfachheit halber als Zielsysteme bezeichnet.
Damit Sie die Zielsysteme in Ihrer Infrastruktur verwalten können, müssen diese
zuerst einmal in baramundi erfasst werden. Dazu stehen Ihnen drei Standardverfahren zur Verfügung:
• Wenn Sie ein System über die baramundi Management Suite respektive das
Modul OS-Install neu aufsetzen, wird der baramundi Management Agent
(bma) mit installiert. Der bma meldet sich beim Starten am baramundi Management Server an, das System wird in der Datenbank erfasst und ist ab
diesem Zeitpunkt über das baramundi Management Center verwaltbar*. Das
Gleiche gilt auch, wenn Sie den baramundi Management Agent manuell auf
einem System installieren.
* Weitere Informationen hierzu erhalten Sie im Abschnitt «OS-Install» des
nachfolgenden Kapitels auf Seite 57.
baramundi Management Agent |
45
• Über die Verwaltung/Domänenkonfiguration besteht die Möglichkeit, Zielsysteme, die über den Computersuchdienst auffindbar sind, automatisch zu
erfassen und einer logischen Gruppierung zuordnen zu lassen.
• Sollen bestehende Systeme erfasst werden, die aus bestimmten Gründen nicht
über den Computersuchdienst ermittelbar sind, oder Sie möchten die automatische Erfassung aus irgendwelchen Gründen nicht nutzen, ist es möglich
diese Systeme manuell, über die Administrationsoberfläche eintragen.
Beachten Sie dabei, dass jedes in baramundi erfasste System als Clientsystem gewertet wird, unabhängig davon, ob auf dem System bereits ein baramundi Management
Agent installiert ist oder nicht. Da die Module der Management Suite auf eine bestimmte Anzahl von Clients lizenziert werden, wirkt sich somit jedes erfasste System
auf die Lizenzzählung innerhalb der Management Suite aus. Wenn Sie ungewollt
erfasste Systeme von der Verwaltung wieder ausnehmen möchten, löschen Sie den
entsprechenden Eintrag. Die zugehörige Lizenz wird dann wieder freigegeben.
Automatische Systemerfassung
Öffnen Sie bitte das Dialogfeld einer zuvor
angelegten Domäne über den Knoten Verwaltung/Domänenkonfiguration. Wechseln
Sie dann in das Register Aktionen. Darin besteht die Möglichkeit, diejenige logische Gruppierung festzulegen, in die Clients
oder Workstations, welche über den Computersuchdienst gefunden werden, automatisch aufgenommen werden sollen. Klicken
Sie nun auf den Auswahlschalter im Bereich
Workstations. Falls sich ein Server anmeldet,
treffen Sie unter Server die Gruppenwahl.
Wählen Sie im Dialogfeld eine zuvor angelegte Gruppe – hier Redaktion – indem Sie
Abbildung 2–33: Domänenkonfiguration
diese markieren und bestätigen; analog verfahren Sie mit den Servern. Sie können nunmehr festlegen, ob auf diesen Zielsystemen der bma direkt nach der Erfassung eines Systems installiert und aktualisiert
werden soll. Im Beispiel aktivieren wir diese Option (Abb.2–33).
Da Sie Änderungen an der Domänenkonfiguration vorgenommen haben, werden
Sie nun aufgefordert, die Systemdienste barasrv und baramoc neu zu starten. Nach
dem Neustart der Dienste wertet der baramundi Management Server den Computersuchdienst aus und sämtliche als Workstation identifizierbaren Systeme werden
in die logische Gruppierung aufgenommen. Je nach Größe Ihrer Infrastruktur kann
es einige Zeit dauern, bis alle als Workstation identifizierbaren Systeme eingetragen
sind. Wählen Sie nun über den Knotenpunkt Umgebung/Logische Gruppierung die
logische Gruppierung Redaktion und wechseln sie dort ins Register Clients.
Systeme manuell erfassen
Unter Umständen ist es aber auch notwendig oder ratsam, Systeme manuell zu erfassen.
Dies kann zum Beispiel dann der Fall sein,
wenn in Ihrer Infrastruktur wan-Strecken eingebunden sind und Sie Systeme verwalten
möchten, die aus Sicht des baramundi Management Servers hinter einem Router liegen
und im Computersuchsdienst nicht auffindbar sind. Um dieses Vorgehen zu demonstrieren, erfassen wir zum Beispiel den baramundi
Management Server.
Wählen Sie dazu in der vorherigen Ansicht
aus dem Aufgabenbereich im Abschnitt Bearbeiten der htm l-Ansicht den Menüpunkt
Neuen Client erfassen. Legen Sie zunächst
Abbildung 2–34: Neues System erfassen
einen Namen fest, unter dem Sie das System
in der baramundi Management Suite verwalten möchten. Tragen Sie anschließend
noch den Hostnamen des Systems ein. Dieser Anzeigename kann frei gewählt
werden und vom Hostnamen abweichen. Es wird aber aus Gründen der Übersichtlichkeit empfohlen, einen gleichen Anzeige- und Hostnamen zu wählen. Schließen
Sie dieses Dialogfeld, wenn Sie die beiden Namen vergeben haben, mit Ok.
Sobald Ihre htm l-Ansicht das nächste Mal aktualisiert wird, ist der Server in der
Übersicht gelistet. Die Kontrollkästchen links neben den Systemen gestatten es, ein
oder mehrere Systeme auszuwählen und Aufgaben für diese Systeme auszuführen.
47
Installation und Konfiguration des baramundi Management Agents
Der baramundi Management Agent wird automatisch installiert:
• Im Zuge einer Betriebssysteminstallation über OS-Install
• und sobald auf einem erfassten System ein Job erstmals ausgeführt wird*.
Auf Systemen mit aktivierter Firewall, die nicht über baramundi installiert wurden
beziehungsweise auf denen der baramundi Management Agent noch nie installiert war, muss der Agent manuell installiert werden – von CD oder über ein
Netzwerklaufwerk.
Der bma wird auf dem baramundi Management Server installiert. Klicken Sie
dazu auf den blauen Anzeigenamen des baramundi Management Servers, um zur
Übersicht dieses Zielsystems zu gelangen. In der sich nun öffnenden Übersicht
befinden sich derzeit lediglich ein paar rudimentäre Angaben. Klicken Sie im
Aufgabenbereich auf Tools, um das Menü zu öffnen. Wählen Sie den Eintrag bMA
installieren. Sie erhalten eine Rückmeldung über die Ausführung der angeforderten
Aufgabe. Diese Meldung verschwindet nach einigen Sekunden von selbst, kann
aber auch geschlossen werden.
In der Clientübersicht des Registers Allgemein wird dieser Status ebenfalls angezeigt.
Sobald die Installation abgeschlossen ist und die Ansicht aktualisiert wurde, stehen
bereits einige Detaildaten über das Zielsystem und die zugrunde liegende Hardware,
die Version des Betriebssystems, die Version des baramundi Management Agents,
die letzte Aktivität und den zuletzt angemeldeten Benutzer auf diesem System zur
Verfügung. Via Voreinstellung ist der baramundi Management Agent in der Taskleiste als Tray Symbol sichtbar. Ein Rechtsklick auf das Symbol öffnet ein Menü
mit folgenden Optionen:
• baramundi Kiosk: Anwender kann freigegebene Software abrufen,
• Logdatei einsehen: Vorgänge werden protokolliert,
• Über baramundi Management Agent: Fenster mit Versionsinformationen.
* Sie können den baramundi Management Agent natürlich auch auf einem neu
erfassten System installieren lassen, ohne einen Job damit zu verbinden.
Die Optionen des baramundi Management Agents lassen sich global definieren. Öffnen Sie dazu den Knoten Verwaltung/Server/Konfiguration und danach mit
einem Doppelklick aus der Listenansicht
den Punkt Grundeinstellungen. Wechseln
Sie dort auf das Register Management Agent.
Sofern es in Ihrem Unternehmen nicht erwünscht ist, dass der Endbenutzer das TraySymbol sehen und damit Software über den
baramundi Kiosk installieren kann: Im Abschnitt Tray-Symbol können Sie festlegen, ob
der Benutzer das Symbol (Symbol ausblenAbbildung 2–35: bMA-Einstellungen
den) oder die Optionen Logdatei einsehen
und baramundi Kiosk sehen darf. Wenn Sie Ihre Anpassungen vorgenommen haben, verlassen Sie diesen Dialog mit Ok. Nachdem Sie Änderungen vorgenommen
haben, müssen Sie das baramundi Management Center sowie den Dienst barasrv
neu starten.
Entsperrung
Mit einer entsprechenden Einrichtung sind die Eingabegeräte (Tastatur und Maus)
bei Aktivitäten des baramundi Management Agents (Jobs) auf den Clientsystemen
gesperrt. Der jeweilige Benutzer kann also während der Jobausführung in einem
solchen Fall keinerlei eigene Eingaben vornehmen. Es gibt jedoch Möglichkeiten,
diese Sperrung des Clients durch den Management Agent aufzuheben, und zwar
auf folgende Art und Weise:
• Durch ein globales Cliententsperrpasswort: Mit diesem, festzulegen unter
Verwaltung/Server/Konfiguration/Jobausführung, Passwort, ist es jedem Benutzer jederzeit möglich Tastatur und Maus auf jobausführenden Clientrechnern
zu entsperren. Insofern sollte dieses Passwort Administratoren vorbehalten
sein.
• Durch Angabe eines Entsperrcodes am Job (Eigenschaften) selbst. Dieser
Code entsperrt den Client dann auch nur speziell bei Ausführung dieses Jobs
– kann also im Zweifel auch Benutzern mitgeteilt werden.
49
Abbildung 2–36: Globaes Entsperren
Abbildung 2–37: Lokales Entsperren
• Durch die Entsperrfunktion am Client, entweder im Kontextmenü des Clients. Alle Aufgaben—Client entsperren oder aber in der htm l-Ansicht unter
Umgebung/Logische Gruppierung am Client im Aktionen-Menü der Eintrag
Client entsperren.
Damit sind die allgemeinen Aspekte im Umgang mit der baramundi Management
Suite abgehandelt – das nächste Kapitel widmet sich den Modulen der Suite.
Reporting
Die baramundi Management Suite bietet über den Knoten Reporting die Möglichkeit umfangreiche Berichte über den Zustand Ihres Netzwerks zu erstellen. Dabei
liefert jeder Unterknoten einen bestimmten Bericht über die Rechner, Lizenzen
sowie die Software Ihrer Systeme.
• Gruppierung – enthaltene Rechner: Übersicht sämtlicher Rechner geordnet in
logischen Gruppierungen mit Domänen, Betriebssystemen, IP-Adressen und
registriertem Benutzer.
• Komponentenübersicht: Übersicht sämtlicher Rechnerkomponenten (Graphikund Netzwerkkarten etc.), geordnet nach Hersteller, Modell und Anzahl.
• Lizenzübersicht im Detail: Überblick der Lizenzen auf Rechnerebene, mit
Gruppenpfad, registrierten benutzer, Installationsdatum und der Information,
ob die entsprechende Software über den baramundi Agent verteilt wurde.
• Lizenzübersicht: Überblick der Lizenzen auf Netzwerkebene, mit Software,
Version, Anzahl, Verwendungsstatus.
• Rechner – Betriebssystemübersicht: Graphischer Überblick der verwendeten
Betriebssyteme.
• Rechner – Datenblatt: Hardware-, Software und Patchdaten zu der Rechner.
• Rechner – Festplattengröße kategorisiert: Graphischer Überblick der Festplatten, geordnet nach deren Größe.
• Rechner – installierte Software: Übersicht der auf den Rechnern vorhandenen
Abbildung 2–38: Reporting/Betriebssystemübersicht
Reporting |
51
Software geordnet nach logischen Gruppierungen.
• Rechner – Prozessor kategorisiert: Graphischer Überblick der Rechnerprozessoren in MHz.
• Rechner – RAM kategorisiert: Graphischer Überblick der Rechnerarbeitsspeicher in MByte.
• Übersicht installierte Software: Installierte Software im Überblick, ohne Rechnerbezug.
Für die Anzeige der Berichte wird der Crystal Reports Viewer auf der Installationsdvd mitgeliefert.Es ist möglich eigene Berichte zu erstellen. Dazu ist dann allerdings
die Vollversion von Crystal Reports notwendig.
Import/Export
Über den Import/Export-Knoten ist es möglich, Daten (zumeist Jobs und Clients)
zwischen baramundi Managementsuiten auszutauschen. Nehmen wir beispielhaft
an, Sie verwalten die edv zweier Filialen eines Unternehmens, die eine in München,
die andere in Hamburg. Es soll nun ein Job, der in München bereits erfolgreich lief,
dem Hamburger Administrator zur Verfügung gestellt werden, um auch dort zur
Ausführung zu kommen.
Export. (München) Zunächst ist der Job (in unserem Falle ein Verteiljob) sowie
die entsprechende Applikation in einen Exportcontainer zu laden. Einen solchen
können Sie über Import/Export—Neu—Exportcontainer neu anlegen, oder aber Sie
benutzen den via Voreinstellung vorhandenen Container.
1. Wählen Sie in der Jobverwaltung den zu exportierenden Job und ziehen Sie
diesen via Drag&Drop auf den Knoten Neuer Import/Export Container.
2. Verfahren Sie analog mit der entsprechenden Applikation unter Deploy/Applikationen (hier Notepad Plus, Abb.2–39)
3. Markieren Sie den Job und die Applikation im Container.
4. Wählen Sie nun im Containerknoten den Kontextmenüeintrag Exportieren.
5. Geben Sie den Speicherort an und speichern Sie Job und Applikation als bdx.
i
Dazu werden die Austauschdaten in das xm l-Dateiformat bdx (baramundi
data exchange,) umgewandelt.
Abbildung 2–39: Export Container
Import. (Hamburg) In Hamburg wird auf den Ablageort zugegriffen und von diesem werden die bdx-Dateien importiert.
1. Wählen Sie Import/Export—Neu—Importdatei öffnen.
2. Markieren Sie die entsprechende bdx-Datei und bestätigen Sie Ihre Wahl. (Die
Datei befindet sich dann unter Import/Export – gelbes Paketsymbol).
3. Markieren Sie den entsprechenden Unterknoten – daraufhin werden die darin
vorhandenen Dateien in der m m c angezeigt.
4. Wählen Sie nun diese Dateien und danach im Kontextmenü den Eintrag
Importieren. (Die Dateien werden dann in den entsprechenden Knoten kopiert
und stehen dieser bms dann zur Verfügung.)
!
Der Austausch von Daten zwischen Management Suiten unterschiedlicher
Version funktioniert in aller Regel von einer neueren auf eine ältere Version
nicht; umgekehrt treten für gewöhnlich keine Probleme auf. Es wird allerdings nicht empfohlen, Daten zwischen verschiedenen bms-Hauptversionen
auszutauschen.
Neben dem Austausch von bms-Daten zwischen verschiedenen Lokalitäten ist der
Import/Export-Knoten auch baramundi Forum von Bedeutung. Dort können
Import/Export |
53
über die bdx-Dateien die Forenmitglieder Dateien tauschen, sei es um nützliche
Einstellungen zu übernehmen oder aber um erfolglose Jobs und dergleichen von
anderen Teilnehmern überprüfen zu lassen.
Persönliche Einstellungen
In den Eigenschaften der Persönlichen Einstellungen können die Grundeinstellungen
des aktuellen Benutzers angepasst werden. Insbesondere kann der Benutzer hier
– im Register Allgemein – einstellen, bereits aktive Jobs weiterhin zu bearbeiten.
Damit wird die Restriktion umgangen, dass bereits auf Clients verteilte Jobs sich
einer weiteren Bearbeitung durch den Benutzer entziehen.
Dieser Zugriff könnte sich jedoch als problematisch erweisen, wenn Jobs auf mehrere Zielsysteme Einfluss nehmen: ein Teil dieser Clients führen dann nämlich einen
anderen Job aus als der andere Teil. Die Systemtransparenz wäre in einem solchen
Falle in Frage gestellt – daher ist an dieser Stelle Vorsicht geboten!
In diesem Kapitel:
• OS-Install—57
• Deploy—74
• Citrix Presentation Server—83
• Automate — 91
• Inventory—115
• Assets—125
• Application Usage Tracking—130
• Patch Management—137
• Recovery—150
3
Module der Suite
Die baramundi Management Suite ist modular aufgebaut; das hat einerseits historische Ursachen – mit OS-Install, Deploy, Inventory fing alles einmal an – ist aber in
erster Linie technisch motiviert und der Benutzerfreundlichkeit geschuldet.
Die Module der Management Suite sind:
• baramundi OS-Install
Automatische Installation von Microsoft Betriebssystemen
• baramundi Deploy
Installation und Verteilung von Software mit flexiblen Installationsverfahren
• baramundi Citrix
Verwaltung von c p s-Farmen/Integration von Citrix-Umgebungen
• baramundi Automate
Arbeitsumgebung zur Oberflächenskriptierung/Deploy-Skript-Erstellung
• baramundi Inventory
Überblick über Hard- und Software, Lizenzen und andere Daten
• baramundi Assets
Geräteverwaltung der Management Suite
• baramundi AUT
Datenschutzsichere Nutzungskontrolle für Software
• baramundi Patch Management
Automatische/manuelle, regelbasierte und sichere Patchverteilung
• baramundi Disaster Recovery
Sicherung und Wiederherstellung von Laufwerken
• baramundi Personal Backup
Effektive Sicherung von Benutzerdaten und -einstellungen
OS-Install
Abbildung 3–1: baramundi OS-Install
Das baramundi OS-Install Modul ermöglicht Ihnen, Installationen von Betriebssystemen vollautomatisch, schnell und zuverlässig vorzunehmen. In nur einem
Durchgang können Sie Clients partitionieren, formatieren, nativ installieren und
konfigurieren. Dabei werden das Betriebssystem und alle benötigten Anwendungen
installiert. OS-Install verwendet dabei, den von Microsoft vorgesehenen, nativen
Installationsmechanismus.
Grundsätzliche Vorgehensweise
Die Betriebssysteminstallation mit baramundi OS-Install vollzieht sich im Wesentlichen nach der Wirkungsweise von Preboot eXecution Environment (pxe), einem
Verfahren, welches Rechnern ein netztwerkbasiertes Booten ermöglicht, das heißt:
pxe- fähige PCs können, anstatt über lokale Laufwerke, auch über das Netzwerk
von einem entfernten Server aus booten.
56 | Kapitel3: Module der Suite
SERVER (bMS)
(5)
?
(1)
PXE
(2)
(3)
?6
(4)
-
(3)
TFTP
-
CLIENT (bMA)
Bootimage PE
6
WAIK
Abbildung 3–2: Arbeitsweise von OS-Install
Die Abläufe bei der Verteilung von Betriebssystemen stellen sich folgendermaßen
dar: Um überhaupt netzbasiert booten zu können, sendet der entsprechende Client einen so genannten broadcast ins Netz, sucht also einen pxe- Boot-Server (1).
Dieser antwortet (2) und stellt dem Client den tf tp -Pfad zum Herunterladen
des PE-Bootimages (3) zur Verfügung. Der Bootloader wird daraufhin in den Arbeitsspeicher des Clients geladen und kann ausgeführt werden (4). Anschließend
ist der Client bereit Jobs vom Server zu empfangen und abzuarbeiten (5), hier:
•
•
•
•
Festplatte partitionieren und formatieren,
Windows Setup kopieren,
Rechner-Reboot mit anschließendem Start des Windows-Setups,
Rechner-Reboot; Start von Windows und des baramundi Management Agents.
Vorbereitungen zum OS-Install
Der Einsatz von baramundi OS-Install knüpft sich an bestimmte Voraussetzungen:
• Das zu verteilende Betriebssystem muss bereits im bmc angelegt sein.
• Ein Boot-Image muss zur Verfügung stehen.
• Das Zielsystem muss p xe unterstützen.
OS-Install |
57
Bootimage erstellen
Ein solches Bootimage ist nur einmal zu erstellen und kann danach für künftige
Betriebssysteminstallationen vom selben Server aus wiederverwendet werden.
WAIK. Zur Erstellung des PE-Bootimages ist zunächst die Installation des Windows
Automated Installation Kits (waik) erforderlich. Dieses liegt der Installations-dvd
bei, und zwar im Verzeichnis . . ./3rdParty/Microsoft/WAIKWin7.de – die Installation
erfolgt durch das Programm StartCD.
Boot Media Wizard. Mit Hilfe des Boot Media Wizards ist nun möglich, schnell und
unkompliziert ein PE-Image zu erstellen. Der Wizard befindet sich im Startmenü
unter Programme/baramundi Management Suite/Tools.
Abbildung 3–3: Typenwahl
Abbildung 3–4: Serverwahl
Abbildung 3–5: Windows PE-Einstellungen
Abbildung 3–6: Treiberwahl
Im ersten Dialog ist der Typ des Bootmediums zu wählen (in unserem Fall Windows PE 3.0) gefolgt von der Wahl des entsprechenden Servers. Im dritten Dialog
Windows PE Einstellungen müssen die Pfade zum Windows aik, zur boot.wim sowie
zur Bootumgebung angegeben werden. Zudem ist die Architektur (32/64-Bit) zu
wählen. Schließlich folgt ein Dialog zur Treiberauswahl. Nach der Fertigstellung
und dem Beenden der Dialoge, wird das Bootimage erstellt und steht für künftige
Betriebssysteminstallation zur Verfügung.
Betriebssystem einrichten
Das zu verteilende Betriebssystem muss (mit allen Rechten) zur Verfügung stehen
und kann bereits auf dem dip abgelegt werden (auch später möglich). Von dort aus
kann es von baramundi übernommen und verteilt werden.
Über OS-Install—Neu—Betriebssystem öffnet sich ein Wizard zur Anlage eines
neuen Betriebssystems. Im ersten Dialog (Abb.3–7) ist die Art der Integration anzugeben – dabei ist nativ die empfohlene Methode. Zur Analyse und Integration des
Betriebssystems ist im nächsten Dialog (Abb.3–8) der Pfad zum dip zu hinterlegen,
auf dem das Betriebssystem vorhanden ist. Hier kann auch eine CD/dvd als Quelle
angegeben werden. In diesem Fall kopiert der Wizard auf Wunsch die Daten auf
den dip. Ab Windows Vista* ist im Folgedialog (Abb.3–9) der Pfad zum unattended
file – eine aus waik generierte Antwortdatei, in der bereits bestimmte Parameter
zum Betriebssystem mitgeliefert werden – anzugeben. Zudem sind hier der Lizenz* Bis Windows XP ist die Antwortdatei für eine bMC-Integration von Betriebssystemen nicht relevant.
Abbildung 3–7: Integrationsmethode
Abbildung 3–8: Verzeichniswahl
OS-Install |
59
Abbildung 3–9: Antwortdatei/Lizenz
Abbildung 3–10: DIP-Kopie
schlüssel sowie die Anzahl der verwendeten Lizenzen einzutragen. Zum Abschluss
der Einstellungen (Abb.3–10) ist es möglich – sofern eine CD/dvd -Quelle gewählt
ist –, auszuwählen, ob das Betriebssystem auf den dip kopiert werden soll oder nicht.
Nach Beendigung der Einstellungen, steht das neue Betriebssystem zur Verteilung
unter OS-Install/Betriebssysteme bereit.
Verteilung von Betriebssystemen
Sind sämtliche Vorbereitungen abgeschlossen, können die, sich nun unter OSInstall/Betriebssysteme integrierten, Betriebssysteme verteilt werden.
Jobvorbereitung
•
•
•
•
Die p xe-Unterstützung (Server) ist zu aktivieren.
Die t f tp-Unterstützung (Server) ist zu aktivien.
Die Betriebssysteminstallation (Client) ist zuzulassen.
Die Bootumgebung (Client) ist zu aktivieren.
Diese Voraussetzungen sind für den Server (Abb.3–11) unter Verwaltung/Server/Konfiguration/PXE Unterstützung durch entsprechende Häkchen bei PXE Server aktiv
sowie TFTP Server aktiv und für den Client (Abb.3–12) in den Clienteigenschaften
im Register Allgemein mit der Aktivierung der Optionen Betriebsysteminstallation
zulassen und Bootumgebung (nebst der Auswahl WinPE) einzustellen.
Abbildung 3–11: Servereinstellungen
Abbildung 3–12: Clienteinstallungen
Joberstellung und -ausführung
Die Jobausführung selbst vollzieht sich wie üblich: Zunächst ist in der Jobverwaltung ein entsprechender Job über Jobverwaltung—Neu—Job einzurichten. Nach
Benennung des Jobs ist als Jobschritt Betriebssystem installieren zu wählen. Danach
ist das zu verteilende Betriebssystem anzugeben. Zusätzlich stehen drei Optionen zur Verfügung, um zum Beispiel die OS-Install-Funktion im Anschluss zu
deaktivieren.
Abbildung 3–13: Jobschrittauswahl
Abbildung 3–14: OS-Wahl/Partitionierung
OS-Install |
61
Abbildung 3–15: Aktivierung Netzboot
Abbildung 3–16: Fertigstellung des Jobs
Anschließend muss der Netzwerkboot nebst der entsprechenden Bootumgebung
aktiviert werden. Der Job ist nun noch fertigzustellen und steht alsdann unter dem
Knoten Jobverwaltung zur Ausführung bereit. Ordnen Sie nun den Job einem Client
oder wahlweise einer Clientgruppe zu, dann folgt – nach einer Sicherheitsabfrage –
die Jobausführung.
Treiberintegration
In aller Regel werden die Komponenten eines Rechners durch den Hardware-Scan
beim Erfassen von Clients der Datenbank automatisch hinzugefügt. Mitunter
werden spezielle Hardwarekomponenten eines Zielsystems vom zu verteilenden
Betriebssystem jedoch nicht unterstützt. In solchen Fällen sind deren Treiber vom
Administrator vor der Betriebsysteminstallation in der bms selbst anzulegen.
Die fehlenden Treiber werden dann den vom Betriebssystem bekannten Treiberdaten hinzugefügt und über das Setup an den jeweiligen Client mit übergeben.
Automatische Treiberintegration
Der einfachste – und daher empfohlene – Weg zur Integration von Treibern ist die
Verwendung des baramundi Treiber Wizards.
i
Sämtliche Treiber müssen zusammen mit einer inf -Datei vorliegen, damit
diese vom baramundi Treiber Wizard erkannt, in die Betriebssysteminstallation integriert und den Komponenten zugeordnet werden können.
Abbildung 3–17: Verzeichnisangabe
Abbildung 3–18: Treiberauswahl
Der Wizard ist unter OS-Install/Treiber—Alle Aufgaben—Automatische Treiberintegration erreichbar. Im ersten Dialogfeld (Abb.3–17) ist zunächst das Verzeichnis
anzugeben, in dem die Treiberdaten zu finden sind. Nach der Pfadangabe kann über
den Auswahlschalter der Treiber speziell für eine bestimmte Komponente gewählt
werden.
Optional kann entschieden werden, ob sämtliche Treiber, oder nur die für die
verwaltete Komponente relevanten Treiber aufgelistet werden sollen. Sofern sich
die Treiberdaten noch nicht auf dem dip befinden, kann dies mit Aktivierung der
letzten Option Treiberdaten in DIP-Struktur kopieren geschehen.
In der Treiberauswahl (Abb.3–18) werden die entsprechenden, für die gewünschte
Komponente notwendigen, Treiber aufgelistet – die relevanten Treiber sind auszuwählen. Die Auswahl ist im nächsten Dialog zu bestätigen, danach wird der Treiber
unter OS-Install/Treiber geführt.
Manuelle Treiberintegration
Neben der automatischen Treiberintegration ist unter OS-Install/Treiber—Neu auch
eine manuelle Treiberintegration möglich. Folgende Einstellungen sind möglich:
Treiber mittels Datei einbinden: Hier ist der Pfad der inf-Datei direkt anzugeben,
die restlichen Einstellungen werden daraufhin automatisch übernommen.
Windows Treiber: Diese Möglichkeit gestattet die manuelle Bearbeitung sämtlicher
Treiberinformationen.
OS-Install |
63
Textmode Treiber (txtsetup.oem): Mitunter werden Treiber bereits während einer
Installation (z.B.für raid-Controller) benötigt. Dazu dienen die hier einstellbaren Textmodetreiber.
DOS Treiber: Sofern noch dos eingesetzt wird, sind hier die entsprechenden Treiberinformationen zu hinterlegen.
Ordner: Um Treiberdaten übersichtlicher zu verwalten, ist es hier möglich Verzeichnisse anzulegen, die dann unterhalb des Treiberknotens aufgeführt werden.
Komponenten
pci -Komponenten werden durch baramundi stets automatisch erkannt und stehen
insofern nach der Clienterfassung über den pci- Scan am Client unter Komponenten
sofort zur Verfügung.
Handelt es sich jedoch nicht um pci- Komponenten, zum Beispiel um Hardware, die
über den us b-Anschluss mit dem Rechner kommunizieren (wie us b-Soundkarten
oder Fingerprintleser bei Laptops), so müssen diese Komponenten manuell angelegt
werden. Das ist über OS-Install/Komponenten—Neu möglich. Hier ist zunächst
auszuwählen, um welchen Komponententyp (Festplatten, Netzwerkkarten, Grafikkarten, Monitore, Sonstige Komponenten) es sich handelt.
i
Sie werden hier i.a.R.mit den sonstigen Komponenten arbeiten, da die
anderen Typen für gewöhnlich über den pci-Scan automatisch erfasst
werden.
Im Dialogfeld unter dem Register Allgemein sind der Hersteller, das Modell sowie
die Device id der entsprechenden Komponente anzugeben. Die ersten Angaben sind
frei editierbar; die Device id kann in aller Regel frei gelassen werden. Im Register
Treiber muss für ein solches Gerät über den Schalter Hinzufügen der entsprechende
– vorher integrierte – Treiber angegeben werden.
!
Beachten Sie beim Anlegen einer Komponente im Register Treiber die unter
Treiberzuordnung in der Spalte OS gelisteten, für den Treiber vorgesehenen
Betriebssysteme! Sollten Sie ein Betriebssystem installieren wollen, welches
diesen Treiber nicht unterstützt – also nicht unter OS gelistet ist – (Sie
installieren gerade Windows 7, unter OS sind jedoch lediglich Windows XP
und Windows 2003 gelistet) – schlägt der OS-Install-Job fehl.
In der Betriebssystemliste darüber können zudem Betriebssysteme ausgewählt
werden, von denen bereits bekannt ist, dass sie eventuell neuere Treiber beinhalten
und somit diesen Treiber nicht benötigen.
Nach Fertigstellung der Komponenten stehen diese unter OS-Install/Komponenten
zur Verfügung. Von dort aus können Komponenten dann einzelnen Clients zugeordnet werden. Für Clientgruppen – und genau darum geht es in den meisten
Fällen – sind die Komponenten zunächst unter Hardwareprofile zu integrieren.
Hardwareprofile
Hardwareprofile sind manuell erfasste Schemata bestimmter Hardwarekomponenten, die – wiederkehrend benötigt – stets abrufbar sind und ermöglichen:
• eine schnelle Partitionierung von Festplatten,
• Betriebssystemeinstellungen via unattended-Parameter vorzunehmen,
• nicht automatisch erkannte Treiber zuzuordnen.
Sinn und Zweck von Hardwareprofilen
Die wesentliche Aufgabe eines Hardwareprofils besteht jedoch darin, die Erfassung
von Rechnern, die aufgrund ihrer Hardwareausstattung durch ein Autodetect nicht
vollständig erfasst werden, dennoch automatisiert verwalten zu können.
Der Normalfall. Beim Erfassen eines PCs wird eine aktuelle Liste der installierten
Komponenten über einen pci-Scan erstellt, die Sie pro Rechner in der Logischen
Gruppierung im Clientknoten Komponenten einsehen können. Über ein Vollständiges Autodetect (das Standard-Hardwareprofil) werden die erkannten Komponenten
mit den entsprechenden (vorhandenen) Treibern verknüpft.
Der Spezialfall. Sofern bereits vor einer Betriebssystemverteilung bekannt ist, dass
die entsprechenden Systeme Komponenten enthalten, die nicht durch den p ci-Scan
erfasst werden, können mit Hilfe eines Hardwareprofils auch solche Komponenten
bei einer Installation Berücksichtigung finden.
Grundsätzlich ergibt sich dabei die folgende Arbeitsweise: Die fehlenden Komponenten sind mit deren Treiberinformationen zunächst unter OS-Install/Komponenten
anzulegen. Bei der Erstellung eines neuen Hardwareprofils werden die benötigten
Komponenten dann daraus angegeben. Das entsprechende Hardwareprofil wird
dem Client bei seiner Erfassung dann zugeordnet.
OS-Install |
65
Gute und schlechte Hardwareprofile
Ein gutes Hardwareprofil berücksichtigt zwei Aspekte, nämlich:
1. einen ausreichenden Automatisierungsgrad sowie
2. die Berücksichtigung nicht automatisch erkannter Komponenten.
Da die p ci-Komponenten beim Erfassen von Clients automatisch erkannt werden,
könnte sich die Meinung ergeben, dass ein Hardwareprofil lediglich noch für diejenigen Komponenten relevant sei, die nicht über den p ci-Scan automatisch angelegt
werden. Diese Annahme täuscht, denn bei der Arbeit mit mehreren Hardwareprofilen sorgt ein Matchingsystem für die korrekte Zuordnung. Darin bearbeitete
Matchpoints werden ausschließlich über die, durch die Gerätekennung erkannten
Komponenten berechnet!
Matchpoints. Bei der Verwendung mehrerer Hardwareprofile wird für jede, von der
Gerätekennung lokalisierte, Komponente ein interner Matchcode erstellt. Bei der
Zuweisung eines Profils wird zunächst geprüft, ob auch wirklich sämtliche im
Profil hinterlegten Komponenten vorhanden sind. Ist das nicht der Fall, wird dieses
Profil bei der Zuweisung ignoriert. Im Anschluss wird die Anzahl der gefundenen
Komponenten – eben über die Matchpunkte – bewertet. Ein höherer Wert resultiert
in einer höheren Präferenz.
Zum besseren Verständnis hier ein kurzes Beispiel: Nehmen wir an, es existierten
zwei Hardwareprofile, mit folgenden Komponenten und deren Matchpoints (5):
Matchpoints HW-Profil A HW-Profil B HW-Profil C
Netzwerkkarte
Graphikkarte
Soundkarte
USB-Erweiterung
ISDN-Karte
Fingerprint
5
5
5
5
5
0
Realtek
Matrox
Digitus
IBM
Realtek
Matrox
Asus
Digitus
AVM
IBM
IBM
Tabelle 3–1: Beispiel einer Hardwareprofilerkennung
Diese beiden Hardwareprofile A und B sind also angelegt. Nun wird ein Rechner
mit folgender Ausstattung erfasst: Netzwerkkarte (Realtek), Graphikkarte (Matrox), Soundkarte (Asus), der usb-Erweiterung (Digitus) sowie dem Fingerprintleser
(i bm). Mit welchem Hardwareprofil wird dieser Rechner nun ausgestattet? Über
die Summe der Matchpoints griffe das Hardwareprofil2: Für jede p ci-Komponente
erhielte es 5 Punkte, also 20 Punkte (denn das Fingerabdrucklesegerät spielt bei
der Matchpoint-Bewertung keine Rolle); Hardwareprofil1 ergäbe hingegen nur
15 Punkte. Doch fehlt dem Rechner eine Komponente des Profils, nämlich die
i sd n-Karte und das schließt eine Zuordnung aus! Es ergeben sich folgende Regeln:
• Für die Matchpoints zählen nur p ci-Komponenten.
• Der Rechner muss sämtliche Komponenten des Profils aufweisen.
• Das Profil kann alle Komponenten des Rechners aufweisen.
Im Beispiel käme es daher zur Zuordnung des Hardwareprofil1, wegen der fehlenden Komponente. Besäße der Rechner auch eine i sd n-Karte, dann erfolgte die
Zuordnung über die höhere Anzahl der Matchpoints.
Das Hardwareprofil C, welches lediglich diejenige Komponente enthält, die nicht
automatisch durch den p ci-Scan erfasst wird, kann aufgrund der fehlenden Matchpointsauswertung keine Entsprechung finden.
Zur Erreichung eines höchstmöglichen Automatisierungsgrades ist es also nicht
nur sinnvoll, sondern notwendig, Hardwareprofilen, neben den nicht durch die
Geräteerkennung erfassten Komponenten, auch die automatisch (über den pciScan) erkannten Komponenten in ein Hardwareprofile zu integrieren. Andernfalls
kann eine automatische Zuordnung nicht erfolgen.
Hardwareprofile anlegen
Beispielhaft sollen 11 neue Clients gleichen Typs erfasst und mit einem entsprechendem Hardwareprofil ausgestattet werden. Sämtliche Rechner beinhalten eine
Komponente – eine usb-Soundkarte –, die nicht durch die Geräteerkennung erfasst
wird. Es seien bereits einige alternative Hardwareprofile angelegt.
Vorbereitung. Zunächst wird einer der neuen Clients erfasst; die über den pci-Scan
gefundenen Komponenten werden dann sowohl am Client selbst, als auch unter
OS-Install/Betriebssystem/Komponenten geführt.
Über die automatische Treiberintegration (OS-Install/Treiber—Alle Aufgaben—
Automatische Treiberintegration können die zu den Komponenten benötigten Treiber ausgewählt und integriert werden. Diese befinden sich im Anschluss unter
OS-Install |
67
OS-Install/Treiber. Komponenten und Treiber, die nicht automatisch über die Gerätekennung zur Verfügung stehen – wie hier die u s b-Audiokarte –, müssen dem
System manuell hinzugefügt werden.
Profilbearbeitung. Um ein neues Hardwareprofil anzulegen, stehen einige Wege
zur Verfügung. Empfohlen, weil einfach, sei die entsprechenden Komponente via
Drag&Drop auf ein vorhandenes Hardwareprofil ziehen.
1.
2.
3.
4.
!
Über OS-Install/Hardwareprofile—Neu den Dialog aufrufen,
im ersten Register Allgemein einen Name vergeben,
den Dialog schließen,
die Komponenten am Client markieren und mit Maus in das Profil ziehen.
Bei der Auswahl der Komponenten ist darauf zu achten, dass die Festplatte
n i c h t Teil der Auswahl* ist. Andernfalls ist die Drag&Drop-Funktion
gesperrt.
Komponenten können auch über den Dialog erfasst/gelöscht werden, und zwar im
Register Komponenten über die Schalter Hinzufügen oder Entfernen.
Im Register Allgemein sind im unteren Bereich noch zwei Optionen zu beachten,
nämlich Domäne erst nach der Betriebssysteminstallation beitreten, für den mittlerweile sehr unwahrscheinlichen Fall, dass bei einer Installation von Betriebssystemen
keine Netzwerkverbindung zum Domänencontroller zur Verfügung steht und ein
Domänenbeitritt erst nach der Installation erfolgen soll. Desweiteren die Option
Dieses Profil bei der automatischen Profilerkennung ignorieren, die dafür sorgt, dass
ein entsprechendes Hardwareprofil trotz höchster Matchpoints ignoriert wird. Sofern Gründe dafür sprechen bestimmte Profile nicht anzuwenden, müssen diese bei
Aktivierung dieser Option nicht gelöscht werden.
Profilzuweisung. Bei der automatischen Erfassung von Clients, werden diesen die
passensten Hardwareprofile zugeordnet – im obigen Fall das zuvor angelegte Profil.
Werden Zielsysteme im Management Center manuell angelegt, dann ist es möglich
diesen, über das Kontextmenü des Knotens der jeweiligen logischen Gruppierung
(Neu—System erfassen), zuvor angelegte Hardwareprofile zuzuordnen.
* Eine solche ist dem Profil bei Bedarf (z.B.einer Festplattenpartitionierung)
manuell hinzuzufügen.
Festplatten partitionieren
Über Hardwareprofile ist es auch möglich
auf Festplatten eine bestimmte Partitionierung einzurichten. Dazu ist ein entsprechendes Profil anzulegen oder es ist einem
via Drag&Drop übernommenen Profil eine Festplatte (über die Profileigenschaften)
hinzuzufügen.
In den Festplatteneigenschaften kann nun
eine Partitionierung der Platte vorgenommen werden. Achten Sie dabei darauf, dass
sich der Rest – also der noch unpartitionierte Teil einer Festplatte – stets wieder an einer
100-Prozent-Basis orientiert. Sofern Sie also beispielsweise 50 Prozent einer Platte für
Abbildung 3–19: Partitionierung
das System- und die anderen 50 Prozent für
eine Daten-Partition einrichten möchten, führten die Einstellungen 50 Primär und
50 Logisch zu einem verbleibenden Gesamtplattenplatz von 25 Prozent. Um also
zwei gleichgroße Partitionen zu erhalten, wählen Sie 50 Primär und 100 Primär
(nämlich 100 Prozent des verbleibenden Platzes).
Nach Abschluss der Einstellungen wird die Partitionierung bei der Betriebssysteminstallation vorgenommen. Dazu ist bei einem OS-Install-Job im Dialog Betriebssystem verteilen unter Partitionierung der Eintrag gemäß Konfiguration Client/Hardwareprofil (vgl.dazu Abb.3–14) zu wählen.
Zwar ist es durchaus möglich Hardwareprofile auch ohne das Anlegen von Hardwarekomponenten zu erstellen – um zum Beispiel Parameter für OS-Install zu
definieren – wir empfehlen jedoch mindestens eine Festplatte mit dem Hardwareprofil zu verknüpfen, da hier eine Partitionierung vorgenommen werden kann.
Ein Beispiel
Zum Zwecke der Veranschaulichung soll im Folgenden ein Betriebssystem (Windows7) auf eine Gruppe von Clients installiert werden. Die Zielsysteme sind zunächst zu erfassen* und mit einem Hardwareprofil auszustatten. Dabei soll auch
*
Näheres zum Thema Clienterfassung finden Sie auf Seite 45.
OS-Install |
69
die Partitionierung der Festplatte Berücksichtigung finden, und zwar dergestalt,
dass im Ergebnis zwei gleichgroße Bereiche zur Verfügung stehen. Es sei dabei von
einem neuen Server ausgegangen, also einen Server, auf dem das Bootimage erst
noch eingerichtet werden muss.
!
Bootimage einrichten. Es ist zunächst Windows Automated Installation Kit (waik) auf
dem Server einzurichten. waik ist Bestandteil der baramundi d vd.
Zur Installation von waik wird der m s xm l Parser benötigt. Sofern noch nicht
geschehen, installieren Sie zunächst msxm l (von der baramundi dvd).
1. Wählen Sie auf der d vd den Pfad 3rdParty/Microsoft/WAIKWin7/de.
2. Installieren Sie das waik mit StartCD.
Nachdem waik auf dem Server installiert ist, kann das PE-Image eingerichtet werden. Dazu bedienen Sie sich des baramundi Boot Media Wizards.
3.
4.
5.
6.
7.
Starten Sie den Boot Media Wizard aus dem Startmenü.
Wählen Sie Windows PE 3.0 Netzwerk Boot Image (vgl.dazu S.58).
Geben Sie hier den p xe - Server (baramundi Server) an.
Übernehmen Sie die im nächsten Dialog genannten Einstellungen.
Sofern Sie Treiber hinzufügen möchten, benutzen Sie den gleichnamigen
Schalter im nächsten Dialog.
Betriebssystem einrichten. Nachdem das PE-Image erstellt ist, kann nunmehr das
Betriebssystem eingerichtet werden. Dazu muss ein (Windows-)Betriebssystem
natürlich vorhanden sein.
1.
2.
3.
4.
5.
6.
7.
Wählen Sie OS-Install/Betriebssysteme—Neu.
Wählen Sie im ersten Dialog die Integrationsmethode Nativ.
Unter Quelle ist der Pfad zum Betriebssystem anzugeben.
Unter Unattended File ist der Pfad zur Antwortdatei anzugeben.
Unter Lizenz ist der Lizenzschlüssel anzugeben.
Unter Anzahl ist die Anzahl der verwendeten Lizenzen anzugeben.
Sie können die Dateien auf den DIP kopieren, sofern nicht bereits geschehen.
Nach der Fertigstellung des Dialogs befindet sich das Betriebssystem im bmc unter
OS-Install/Betriebssysteme und kann von dort aus verteilt werden.
Hardwareprofil erstellen. Um nun die gewünschten Komponenten in einem Hardwareprofil zu hinterlegen, bietet es sich an, zunächst eines der Zielsysteme zu erfassen,
um dessen – durch die Gerätekennung identifizierbaren – Hardwarekomponenten
über den p ci-Scan zu erfassen.
1. Sorgen Sie für die erforderlichen Servervoraussetzungen*.
2. Booten Sie eines der Clientsysteme.
Der Client wird nun über pxe am baramundi Management Server erfasst und meldet sich über seine mac-Adresse im Management Center unter Umgebung/Logische
Gruppierung an.
3.
4.
5.
6.
Erstellen Sie ein neues Hardwareprofil.
Wählen Sie den Clientknoten Komponenten.
Markieren Sie sämtliche Komponenten, außer die Festplatte.
Ziehen Sie die Auswahl via Drag&Drop auf Ihr Profil.
Sämtliche, über den p ci-Scan erfassten Komponenten sind nun Teil des Profils. Es
müssen noch diejenigen Komponenten hinzugefügt werden, die nicht über die
Gerätekennung automatisch erfasst wurden.
7. Legen Sie unter OS-Install/Treiber den/die benötigten Treiber an.
8. Legen Sie die entsprechende Komponente unter OS-Install/Komponenten an.
9. Ordnen Sie im Register Treiber die/den entsprechenden Treiber zu.
Festplatte partitionieren. Schließlich ist dem Hardwareprofil noch eine Festplatte hinzuzufügen und zu partitionieren.
1.
2.
3.
4.
Öffnen Sie den Eigenschaftsdialog Ihres Hardwareprofils.
Im Register Komponenten wählen Sie Hinzufügen.
Wählen und übernehmen Sie eine Festplatte.
Doppelklicken Sie die neue Festplatte, um diese zu partitionieren.
OS-Job anlegen. Die Vorbereitungen sind abgeschlossen – nun soll ein Job zur Verteilung von Betriebssystemen angelegt werden. Stellen Sie zuvor sicher, dass:
*
vgl.dazu Seite 60
OS-Install |
71
• unter Verwaltung/Server/Konfiguration die p xe - Unterstützung aktiviert ist,
• die entsprechenden Zielsysteme eine Betriebssysteminstallation zulassen
(einstellbar in den Clienteigenschaften).
Ist das sichergestellt, wird ein neuer Job angelegt.
1. Wählen Sie Jobverwaltung—Neu—Job.
2. Wählen Sie den Jobschritt Betriebssystem installieren.
3. Treffen Sie Ihre Einstellungen zum Betriebssystem und zur Partitionierung.
Unter Betriebssystem ist (in unserem Fall) Windows 7 (DE) zu wählen, also dasjenige
Betriebssystem, welches verteilt werden soll.
Clients erfassen. Um die neuen Zielsysteme im Management Center zu erfassen, stehen grundsätzlich zwei Wege zur Verfügung: Entweder die Clients werden gebootet
und dadurch automatisch erfasst – und müssen anschließend benannt und in eine
entsprechende logische Gruppierung übernommen werden. Oder aber die Clients
sind manuell zu erfassen.
manuell: Dazu rufen Sie den entsprechenden Dialog über Logische Gruppierung—
Neu—System erfassen auf und wählen dort das passende Hardwareprofil. Für eine
eindeutige Clientzuordnung ist es bei der manuellen Clienterfassung notwendig,
die mac-Adresse (Netzwerk) oder (via Voreinstellung) zumindest den Hostnamen
(Allgemein) zu kennen und im Dialog einzutragen. Die so erfassten Client können
anschließend noch gruppiert werden.
automatisch: Zur automatischen Erfassung ist es lediglich nötig, die entsprechenden
Clients zu booten. Diese werden dann automatisch erfasst und melden sich über
ihre mac-Adresse im Management Center an. Dort sind sie dann zu benennen und
gegebenenfalls zu gruppieren.
Jobs ausführen. Nachdem nun sämtliche neuen Clients erfasst, benannt und gruppiert sind, ist es möglich ihnen Jobs (in unserem Fall zunächst eine Betriebssysteminstallation) zuzuordnen.
1.
2.
3.
4.
5.
Legen Sie einen neuen Job an.
Wählen Sie dabei den Jobschritt Betriebssystem installieren,
und im nächsten Dialog das gewünschte Betriebssystem sowie
die Partitionierung: gemäß Konfiguration Client/Hardwareprofil.
Stellen Sie den Job fertig.
Der Job ist nun noch der Clientgruppe – via Drag&Drop oder über Alle Aufgaben—
Client(s) zuordnen – zuzuordnen, und kann daraufhin ausgeführt werden. Dazu
sind die Clients zu starten.
OS-Install |
73
Deploy
Mit baramundi Deploy ist es möglich, Software einfach und zuverlässig zu installieren/zu deinstallieren sowie administrative Aufgaben zu erledigen. Dabei werden
sämtliche Einstellungen von einem zentralen Punkt aus vorgenommen, was eine
hohe Qualität bei automatischen Installationsprozessen gewährleistet. Der gesamte
Ablauf der Installation ist zu jeder Zeit einsehbar, da sämtliche Informationen
beinahe in Echtzeit an den Server zurückgemeldet werden. Deploy zudem einfach
zu bedienen.
Abbildung 3–20: baramundi Deploy
Die Arbeit im Modul Deploy vollzieht sich nach folgendem Prinzip: Zunächst
sind die Original-Setup-Dateien von den Datenträgern auf den dip zu kopieren (1).
Von dort werden sie entweder automatisch (Application Automation Wizard) oder
manuell als Applikation auf den Management Server gelegt (2), sind also infolge
dessen auch im Management Center unter Deploy/Applikationen geführt. Ist dies
geschehen, kann ein entsprechender Verteiljob angelegt (3) und auf einem Ziel-
CD
(1)
DIP
h
(5)
(2)
?
?
CLIENT (bMA)
Applikation
(3)
(4)
?
-
Job
SERVER (bMS)
(6)
Abbildung 3–21: Arbeitsweise von Deploy
system ausgeführt werden (4). Der Client holt sich daraufhin die auszuführenden
Installationsdateien vom dip (5), installiert die Software und meldet dem Server den
Verlauf des Jobs (6).
Software verteilen
Um Applikationen auf den baramundi Server einzurichten, müssen diese zunächst
auf den dip kopiert werden. Darüber hinaus ist es notwendig, die entsprechenden
Applikationen auf dem baramundi Server anzulegen. Nur die dort befindliche
Software kann verteilt werden.
Installationsdateien kopieren
Der dip (Distribution Installation Point) ist ein Verzeichnis, auf dem die Installationsdateien sämtlicher, zu verteilender Applikationen liegen. Um welches Verzeichnis
es sich dabei handelt ist schnell in den Eigenschaften der logischen Gruppierungen im Register Allgemein und DIP feststellbar. Kopieren Sie die zu Installationen
benötigten Daten in dieses Verzeichnis.
Deploy |
75
Applikationen anlegen
Befinden sich die Installationsdaten der zur Verteilung vorgesehenen Programme im
dip, können die entsprechenden Applikationen in der Management Suite angelegt
werden.
Automatische Applikationintegration. Für eine möglichst einfache Integration neuer Applikationen wurde der Application Automation Wizard entwickelt. Dieser Assistent
unterstützt die gängigsten Installationsmechanismen, wie: msi, Installshield, i ss,
Wise, Innosetup, sfx Installer und erlaubt darüber hinaus auch die Einbindung
von baramundi Deploy Skripten. Bei Installshield und Innosetup können bei der
Integration zudem die dazugehörigen Responsefiles erstellt werden; bei msi und
den anderen Installationsmechanismen wird eine Auswahl der gängigsten Kommandozeilenparameter angeboten.
Der Application Wizard startet über Deploy/Applikationen—Neu—Applikation. Sofern neue Software automatisch integriert werden soll, wählen Sie im ersten Dialog
Application Automation Wizard verwenden. Danach ist der Pfad zur Applikation
(Abb.3–22) anzugeben, die angelegt werden soll. Sind die erforderlichen Installationsdateien vorhanden, wird im nächsten Dialog (Abb.3–23) das Setup erkannt und
das entsprechende Verfahren für die Automatisierung angeboten. Folgen Sie dann
der Programmführung*.
Abbildung 3–22: Wahl der Applikation
Abbildung 3–23: Automatisierungsmethode
* Ein Beispiel zur automatischen Applikationsintegration folgt am Ende des
Abschnitts.
Manuelle Applikationsintegration. Neben
der automatischen Integration von
Software, können Applikationen auch
manuell angelegt werden. Dazu stehen
zwei Optionen zur Verfügung: die manuelle Integration mit Wizardunterstützung und die manuelle Integration ohne
Wizardunterstützung. Während diese
Option lediglich einen entsprechenden
Dialog bietet, in dem sämtliche Angaben einzutragen sind, trägt die manuAbbildung 3–24: manuelle Integration
elle Integration mit Wizardunterstützung, bei Wahl einer bestimmten Applikation, die dafür erforderlichen Angaben
automatisch ein.
Bundles anlegen
Zuweilen ist es vorteilhaft – weil übersichtlich –, wenn auch technisch nicht notwendig, mehrere Applikationen in Paketen, so genannten Bundles zusammenzufassen.
Dazu müssen die Bundle-Applikationen zunächst angelegt werden.
Abbildung 3–25: Name des Bundles
Abbildung 3–26: Applikationswahl
Deploy |
77
Ein neues Bundle kann über Deploy—Neu—Bundle angelegt werden. Dazu ist das
neue Software-Bundle im Register Allgemein zunächst zu benennen (Abb.3–25).
Sofern die über Bundles Software deinstallieren möchten, kann dies über die Option
Deinstallationsbundle geschehen. Normalerweise finden Softwareabhängigkeiten
bei solchen Paketen Berücksichtigung. Soll das nicht der Fall sein, aktivieren Sie die
Option Abhängigkeiten ignorieren.
Welche Applikationen Bestandteil des Bundles sein sollen, wird im Register Software
(Abb.3–26) festgelegt. Hier können mittels des Hinzufügen-Schalters die entsprechenden Applikationen gewählt werden. Über den Schalter Entfernen ist es möglich,
Applikationen aus dem Bundle zu löschen.
Die Softwarepakete können nach ihrer Anlage, wie normale Applikationen auch,
über Jobs installiert oder deinstalliert werden.
Installationsmechanismen anlegen
Über die Installationsmechanismen werden Installationsroutinen festgelegt, wie
zum Beispiel VBScript. Es ist möglich, Installationsmechanismen über Deploy—
Neu—Installationsmechanismus zu integrieren. Hierüber können sämtliche alternativen Installationsverfahren abgebildet werden.
Abbildung 3–27: Installationsmechanismen
Abbildung 3–28: Appliaktionseigenschaften
Dazu sind im Register Allgemein (Abb.3–27) die entsprechenden Angaben auszufüllen. Für den Eintrag Paket ist es notwendig, eine entsprechende bpk-Datei
anzulegen, die für den Server beschreibt, wie das Installationsprogramm auf dem
Client auszuführen ist. Es handelt sich um eine einfache Textdatei* , in der die
Konfigurationsdaten zu erfassen sind.
Nach deren Übernahme steht der Installationsmechanismus im Management Center unter Deploy/Installationsmechanismen zur Verfügung. Einmal angelegt, kann der
Installationsmechanismus in den Eigenschaften der Applikationen in den Registern
Installation und Deinstallation verwendet werden.
!
Alternative Installationsmechanismen können bei der Anlage von Applikationen nur über die manuelle Integration ohne Wizardunterstützung angegeben
werden.
Ein Beispiel
Im Folgenden soll die Anlage von Software über den Application Automation
Wizard näher erläutert werden. Beispielhaft wird dazu der Acrobat Reader in die
Management Suite integriert.
Microsoft Installer (MSI)
1. Öffnen Sie den Wizard über Deploy—Neu—Applikation.
2. Wählen Sie Application Automation Wizard verwenden.
Abbildung 3–29: Methodenwahl
*
Abbildung 3–30: Appliaktionswahl
Nähere Angaben dazu entnehmen Sie bitte der Onlinehilfe.
Deploy |
79
Abbildung 3–32: Appliaktionswahl
Die Installationsdateien für den Acrobat Reader liegen in den dvd-Quellen (/3rdParty) als Setup.exe sowie als AcroRead.msi vor. Für das Beispiel sei letztere gewählt
(führt zu Abb.3–30).
Über die Dateiendung wird die Installationsmethode automatisch erkannt. Insofern
kann das empfohlene Verfahren der Automatisierung übernommen werden.
3. Übernehmen Sie die Einstellung Windows Installer Kommandozeile erstellen.
4. Übernehmen Sie die Einstellungen im Schritt Windows Installer Aktion.
Zu den Einstellungen: Unter Installationsmodus stehen Ihnen vier Optionen zur
Verfügung – Install und Uninstall installieren oder deinstallieren die entsprechende
Applikation vom Client. Mittels Repair ist es möglich eine nicht funktionierende
Installation zu vervollständigen. Unter Verwendung der Option Advertise wird
die Applikation erst im Bedarfsfalle auf dem Zielsystem installiert, das heißt, Die
Startmenüeinträge oder Desktopsymbole sind auf dem Client zwar vorhanden,
das Programm installiert sich jedoch erst bei der ersten Benutzung (ähnlich der
Sprachpakete von Microsoft Word). Soll die Applikation für jedem Benutzer des
Zielsystems zugänglich sein, dann ist zudem die Option Für alle Benutzer installieren
zu aktivieren.
Über Benutzerinterface kann zudem eingestellt werden, ob während der Installation
Dialoge angezeigt werden oder nicht. Mit der Wahl von Kein Benutzerinterface (/qn)
(Voreinstellung) läuft die Installation gänzlich ohne eine Benutzerinteraktion; ein
Vollständiges Benutzerinterface (/qf) hingegen sorgt für eine gänzlich vom Benutzer
geführten Installation.
Abbildung 3–33: Protokollierung
Abbildung 3–34: MSI Properties
Die Auswahl des letzten Feldes Transform erlaubt den Zugriff auf mst-Dateien
(Microsoft Setup Transform), mit deren Hilfe Änderungen von den Standardinstallationen vorgenommen werden können. So wäre es bei Officepaketen zum Beispiel
vorstellbar, bestimmte Komponenten von der Installation auszuschließen.
5. Legen Sie die Parameter für die Protokollierung fest.
6. Legen Sie die msi-Properties fest.
Mit der Option Protokollierung aktivieren können Sie Einstellungen treffen, welche
während des Setups in einer Textdatei festgehalten werden. Die MSI Properties sind
vom Hersteller definierte Werte, die hier vollständig aufgeführt sind. Es ist möglich
diese Werte hier zu ersetzen.
7. Prüfen Sie in der Kommandozeile den Quelltext Ihrer Eingaben.
8. Beschreiben Sie das Applikationsprojekt.
Die getroffenen Eingaben werden in der Kommandozeile als Befehl hinterlegt, der
dann an die Zielsysteme übergeben wird. Hier kann das Kommando überprüft
werden. Der Dialog zur Beschreibung der Applikation ist frei editierbar und wird
dann so übernommen.
9. Bestätigen Sie die Pfadauswahl.
10. Aktivieren Sie die Option, um sich die Applikationseigenschaften zeigen zu
lassen
Deploy |
81
Abbildung 3–35: Kommandozeile
Abbildung 3–36: Beschreibung
Nach einer Rückfrage nach dem Installationspfad – in aller Regel ist der erstgenannte Pfad zu wählen – können Sie schließlich noch entscheiden, ob Sie sich
nach Abschluss des Applikationsprojekts die Eigenschaften der Applikation für eine
eventuell weitere Bearbeitung anzeigen lassen wollen.
InstallShield Setup & andere
Neben msi ist InstallShield (Flexera Software) eine weit verbreitete Installationslösung für MS-Windows. Auch dazu sei anhand der im obigen Beispiel getroffenen
Annahmen der Ablauf über den Application Automation Wizard skizziert.
Die Installationsdateien für den Acrobat Reader liegen auch in den dvd-Quellen
(/3rdParty) vor. Für dieses Beispiel sei nun die Setup.exe gewählt.
Abbildung 3–38: Antwortdatei
1. Wählen Sie das Verfahren der Automatisierung.
2. Erstellen Sie eine Antwortdatei
Wiederum wird das Verfahren (InstallShield) erkannt und vorgeschlagen. Wird
die Installationsmethode hingegen nicht erkannt, erfolgen die entsprechenden
Anweisungen direkt in der Kommandozeile oder über ein baramundi Deploy Skript.
Einmal angelegt, sorgt eine Antwortdatei für die Automatisierung der nächsten,
gleich ablaufenden Installation. Über den Schalter Neu wird dazu eine Textdatei
verfasst, die sämtliche, zur Installation nötigen Schritte – die Installation muss dazu
einmal (lokal) durchlaufen werden – notiert. Nach Fertigstellung und Speicherung
dieser Textdatei, können spätere Installationen gleicher Art wiederum automatisiert
erfolgen.
Die Logdatei ist ein Protokoll, das notiert, wie eine Installation ablief.
3. Überprüfen Sie im nächsten Dialog die Kommandozeile.
4. Geben Sie schließlich die Informationen zur Software.
Mit den Automatisierungen zu Microsoft Installer und InstallShield können sich die
meisten Installationen abbilden lassen. Installationsmechanismen, also alternative
Installationsmethoden, sind nur für Spezialfälle sinnvoll.
Citrix Presentation Server Verwaltung
Citrix ist ein populäres Verfahren der Softwarebereitstellung, bei dem sich so
genannte Thin Clients (kleine Rechner zur Ein- und Ausgabe von Daten) mit einem
Server verbinden, der die vom Thin Client benötigten Anwendungen bereitstellt
und als Speichermedium dient.
Gleichwohl kann die Veröffentlichung von Software über die native Citrixverwaltung eine zähe Angelegenheit sein: Jede Software, jede Einstellung, jede Änderung
muss an jedem einzelnem Server vorgenommen werden. Über die baramundi cp sVerwaltung jedoch, können Citrix-Server wie normale Clients verwaltet werden,
das heißt: Sämtlicher Verteilungskomfort, der sich über dynamische Gruppen in der
Clientverwaltung nutzen lässt, ist ebenfalls über die Citrix-Schnittstelle erreichbar.
Deploy |
83
Abbildung 3–39: Serverauswahl
Abbildung 3–40: Serverauswahl
CPS-Rechtemanagement
Um Ihren Citrix Presentation Server (c p s) über die baramundi Management Suite
zu verwalten, müssen Nutzern respektive Administratoren zunächst bestimmte
Rechte eingeräumt werden: Letzteren, um Jobs auszuführen und normalen Nutzern,
um überhaupt Server und Applikationen über die bms zu bedienen.
In den Farm-Einstellungen Ihres cps befindet sich unter anderem ein Knoten Administratoren. Über dessen Kontextmenü können neue Benutzer und Administratoren
angelegt sowie entfernt werden. Je nachdem, wie ein Benutzer am System arbeitet,
benötigt er mehr oder weniger Rechte. Auch diese Privilegien können bereits bei
der Anlage neuer Benutzer Berücksichtigung finden. Nach dem Fertigstellen der
Prozedur, sind sämtliche autorisierten Benutzer in der Administratoren-Ansicht des
cp s aufgeführt. Der baramundi Installationsbenutzer muss Administrationsrechte
am c p s besitzen.
Live-Inventarisierung
Um mit Citrix in der Management Suite arbeiten zu können, müssen erst einmal die Citrix-Server (und die Software) initialisiert sein. Die Anlage erfolgt über
Deploy/Citrix Presentation Server Verwaltung—Neu—Citrix Farm.
Zunächst gilt es die bms erst einmal mit den Citrix-Servern bekannt zu machen.
Diese werden – selbst wenn es sich lediglich um einen einzelnen Server handelt – als
«Farm» bezeichnet. Nach einer Bestätigung des Eingangdialogs, folgt eine Auswahl
der zur Verfügung stehenden Citrix-Server. Aus dieser logischen Gruppierung
können Sie nun diejenigen Server auswählen, welche über die bms verwaltet werden.
Es kann sich dabei, wie in der Abbildung, natürlich auch um einen einzelnen Server
(h p 0 4) handeln (Abb.3–40).
Sämtliche Citrix-Server lassen sich zu einer Farm zusammen stellen. Der Farmname
wird dabei von Ihrer Citrixsoftware übernommen. Sofern Server gewählt wurden,
die schließlich doch nicht Bestandteil der Farm sein sollen, können diese wieder
entfernt werden.
Danach kann die darin zur Verteilung bestimmte Software ausgewählt werden.
Dazu wird Ihnen vom System sämtliche, auf Ihren Citrix-Servern vorhandene
und Citrix zugängliche, Software angezeigt. Wählen Sie also die Programme und
Inhalte aus, welche verwaltet werden sollen. Nach der Fertigstellung ist die Farm
im Knoten Deploy/Citrix Presentation Server Verwaltung angelegt – heißt jedoch
noch «Unbekannt» – erst nach einer Aktualisierung der Ansicht (F5) wird der von
Citrix angelegte Name auch in der bms angezeigt. Es ist nunmehr möglich, die
Citrix-Server sowie darauf befindliche Software vom Management Center aus zu
verwalten.
Servereinstellungen
Die bms-Schnittstelle zu den citrixspezifischen Einstellungen lässt sich – wie stets –
durch einen Job deklarieren. Es soll beispielhaft ein solcher Job angelegt werden. Im
Kontextmenü des Knotens Jobverwaltung ist das unter Neu—Job schnell geschehen
(Abb.3–41/3–42). Die Auswahl Citrix Jobschritte führt dann geradewegs zu der zur
Verfügung stehenden Auswahl.
Abbildung 3–41: Jobschrittwahl
Abbildung 3–42: Citrix-Jobschritt
Deploy |
85
Abbildung 3–43: Farmauswahl
Abbildung 3–44: Softwarewahl
Anwendungsveröffentlichung. In diesem Menü geht es imgrunde um ganz ähnliche
Einstellungen, wie bei der Anlage von Servern und Software zu Beginn der Prozedur.
Die dabei initialisierten Anwendungen befinden sich erst einmal in der bms, sind
jedoch noch nicht veröffentlicht.
In einem ersten Schritt wählen Sie Citrix Anwendungsveröffentlichung und nach
der Bestätigung die entsprechende Farm (Abb.3–43); nach einer abermaligen Bestätigung bietet Ihnen der Dialog (Abb.3–44) die zur Veröffentlichung verfügbare
Software an. Wählen Sie die Software aus und bestätigen Ihre Wahl mit Weiter.
Daraufhin meldet sich der folgende Dialog und stellt Ihnen drei Optionen zur
Auswahl:
Die erste Option nur Veröffentlichen
zeigt dem Anwender eine Auswahl der
zu veröffentlichenden Software. Das jedoch heißt noch nicht, dass die entsprechende Software in Citrix auch tatsächlich zur Verfügung steht! Sofern nämlich
ein Programm nicht Teil der Farm ist,
kann es auch nicht veröffentlicht werden.
Mit der Option bei Bedarf erstellen sorgen Sie dafür, dass die nachgefragte SoftAbbildung 3–45: Veröffentlichungsoptionen
ware auch erstellt wird. Sofern bezüglich
dieses Punktes für einzelne Programme eines ganzen Bündels von zu veröffentlichenden Anwendungen unterschiedlich verfahren werden soll, dann steht Ihnen über
die Option Einstellung pro Anwendung festlegen auch das frei. Nach der Bestätigung
Ihrer Auswahl können sie diese dem Job Hinzufügen.
Anwendungsbereinigung. Natürlich ist es möglich einmal veröffentlichte Programme
auch wieder zurückgezogen werden. Der so lautende Jobschritt funktioniert im
Wesentlichen wie die eben beschriebene Anwendungsveröffentlichung: Es wird
Ihnen eine Liste von auf der Serverfarm verfügbarer Programme angezeigt, von
denen Sie nun diejenigen wählen können, welche Sie den Clients künftig nicht
mehr zur Verfügung stellen möchten.
Konfiguration
Sowohl Server als auch Anwendungen lassen sich über die bms direkt konfigurieren.
Bitte achten Sie darauf, dass Sie als baramundi Install Benutzer auf der Citrix-Farm
in Ihrer Citrix Software angemeldet sind – andernfalls können keine Jobs ausgeführt
Abbildung 3–46: Citrix-Konfiguration
Deploy |
87
werden. Es werden volle Administrationsrechte benötigt. Dazu ist zunächst eine
entsprechende Auswahl zu treffen, nämlich was genau konfiguriert werden soll.
Server. Es werden daraufhin verschiedene Optionen angezeigt. Zunächst ist jedoch
der gewünschte Server über Einstellungen von Server auslesen zu wählen. Die einzelnen Optionen lassen sich dann durch ihre Anwahl über die Schaltfläche einstellen.
Sofern Sie sich im Anschluss doch wieder für die Voreinstellungen entscheiden
sollten, so ist das über eine entsprechende Schaltfläche [x] jederzeit möglich.
Nehmen wir beispielhaft an, Ihre Clients – und von denen gäbe es nicht so viele –
beschwerten sich ständig darüber, dass die Bearbeitung ihrer Druckaufträge unerträglich lange dauerten. Sie, als Systemadministrator, sind die Sache leid und wollen
den Druckvorhaben der Clients mehr Bandbreite einräumen.
1.
2.
3.
4.
5.
6.
7.
Erstellen Sie einen Job.
Wählen Sie Citrix Jobschritte/Citrix Konfiguration
und daraufhin die Option Server (Abb.3–47).
Setzen Sie ein Häkchen bei Ica Druckereinstellungen (Abb.3–48).
Drücken Sie in der gleichen Zeile den Auswahlschalter
und wählen dort Unbegrenzte Druckerbandbreite.
Bestätigen Sie Ihre Eingaben.
Führen Sie den Job auf allen Rechnern der Farm aus, dann ist die Einstellung der
Druckbandbreite geändert.
Abbildung 3–47: CPS-Objekte
Abbildung 3–48: CPS-Objekteigenschaften
Abbildung 3–49: Citrix-Inventarisierung
Inventarisierung. Um die aktuellen, oder auch frühere, Citrix-Server-Einstellungen
einzusehen, besteht die Möglichkeit einen entsprechenden Inventarisierungsjob
auszuführen. Dazu erstellen Sie einen Job: Inventarisierungs durchführen/Citrix
Farm. Diesen Job weisen Sie nach Fertigstellung einem Citrix-Server zu. Im Ergebnis
werden Ihnen dann – wahlweise in der Dateistruktur oder in der htm l-Ansicht –
die entsprechenden Serverdaten angezeigt (Abb.3–49).
Applikation. Ganz ähnlich der Servereinstellungen, können auch die Applikationen in gewisser Weise konfiguriert werden. Dazu ist zunächst nichts weiter zu
tun, als unter Citrix-Jobschritte/Citrix Konfiguration die Option Applikation zu wählen(Abb.3–47). Nach der entsprechenden Bestätigung, fordert Sie ein Dialog auf
sich zu entscheiden, ob Sie ein Template verwenden möchten oder nicht.
Mit Hilfe eines solchen Templates können Voreinstellungen bestimmter Programme
übernommen werden und zwar durch die Option Anwendung als Template verwenden. Geben Sie in dem Listenfeld die referenzierende Anwendung an, und diese
Einstellungen werden für den nächsten Dialog übernommen (Abb.3–48).
Hier nun können die angebotenen Einstellungen überarbeitet werden. Wählen Sie
Deploy |
89
dazu unter Allgemein diejenige Anwendung aus, deren Sie bestimmte Eigenschaften
der Referenzanwendung zuordnen möchten.
Abbildung 3–50: Veröffentlichungsoptionen
Citrix Presentation Server Installation. Es
ist über die bms natürlich auch
möglich, Citrix-Server zu installieren. Auch dazu ist ein neuer
Job zu öffnen (Jobverwaltung/Neu—
Job) und das entsprechende Menü
auszuwählen (Citrix Jobschritte—
Presentation Server Installation vgl.
dazu Abb.3–50). Wählen Sie im Dialog die gewünschte Farm und das
Bundle. Zudem können Sie entscheiden, ob Sie eine Standardinstallation,
oder aber eine angepasste Installati-
on wünschen.
Die Standardwerte sind in den Farmeigenschaften (Kontextmenü) editierbar. Via
Voreinstellung – zu finden und konfigurieren in den Eigenschaften der Farm –
sind die am ehesten als normal anzunehmenden Werte eingestellt. Um nun die für
Ihren Server zutreffenden Einstellungen zu hinterlegen, schauen Sie bitte in das
Citrix-Handbuch*.
Für eine Standardinstallation sind lediglich Farm und Bundle anzugeben; die Wahl
Installationsparameter anpassen hingegen öffnet einen Dialog, der es ermöglicht die
Standardparameter zu überschreiben. Nach der Bestätigung Ihrer Einstellungen
wählen Sie im Kontextmenü der Farm den Menüpunkt Farm live Inventarisierung
und folgen den Dialogen.
Die Arbeit des Systemadministrators unterstützt baramundi Citrix insbesondere
durch die Bearbeitung von Farm-Servern und -anwendungen in dynamischen Gruppen. Das heißt, es ist möglich Anweisungen an einen, mehrere oder sämtliche Server
zu übergeben, ganz wie Sie es auch im Umgang mit Ihren Clients gewohnt sind.
Verglichen mit den Citrix-Verwaltungstools, mit denen das nur für jeden Server
einzeln möglich ist, lässt sich durch baramundi Citrix viel Zeit sparen.
*
Administrators Guide/Anhang D: «Advanced Installation Matters»
Citrix Systems Inc. (2007)
Automate
Abbildung 3–51: baramundi Automation Studio
Zur Automatisierung von Softwareinstallationen, stellt baramundi die Entwicklungsumgebung Automation Studio bereit. Das Automation Studio ist Teil des Moduls Deploy und stellt für Deploy-Jobs so genannte baramundi Deploy Skripte
(dateiname.bds) zur Verfügung. Diese Skripte dienen zur Unterstützung der Softwareverteilung in Deploy und erfüllen folgende Funktionen:
Installationsmechanismus. Dabei wird ein baramundi Deploy Skript (bds) anstatt eines Setups* ausgeführt. Zweck einer solchen bds-gesteuerten Installation ist:
• die Automatisierung von Benutzerangaben bei einer Installation,
• eine zusätzliche Anpassung vor, während und/oder nach der Installation.
*
Die Ausführung des Setups selbst kann aber Teil eines Deploy Skripts sein.
Automate |
91
Benutzerbezogene Deploy Skripte. (Usersettings) Ein solches Skript wird auf ein Zielsystem kopiert und läuft für einen bestimmten oder mehrere Benutzer, wenn sich diese
erstmals anmelden (z.B.Desktop-Verknüpfungen oder dergleichen).
Das baramundi Automation Studio ist eine einfach zu bedienende, den Bedürfnissen des Nutzers schnell anpassbare und zudem sehr mächtige Entwicklungsumgebung, um Installationen zu automatisieren*.
!
Grundsätzliches zum Automation Studio
Ab der Windowsversion Vista (Server 2008) sind – speziell für gui-Automatisierungen
– lokale Administrationsrechte erforderlich! Andernfalls ist ein Zugriff auf
Programmfenster nicht möglich.
Die Oberfläche des baramundi Automation Studios – die Entwicklungsumgebung
zur Erstellung von Deploy Skripten – ist in fünf Bereiche aufgeteilt: Oben, die Zeile
mit den Ribbons, dient der Steuerung der im Automation Studio angebotenen
Funktionen und ist in drei Bereiche gegliedert:
Abbildung 3–52: Ribbon-Bereich (oben)
Zwischenablage. Einfache Editierfunktionen: Einfügen, Ausschneiden, Kopieren
Aktionen. Stellt sämtliche Funktionen zur Skriptbearbeitung zur Verfügung.
Neue Aktion: Fügt eine Aktion in das Skript;
Bearbeiten: Öffnet den Bearbeiten-Dialog einer Aktion;
Löschen: Entfernt eine Aktion aus dem Skript;
Auskommentieren: Kann Skripteinträge auskommentieren oder wieder
in Funktion setzten;
• Pfeiltasten: Über die Pfeile lassen sich Skriptaktionen nach oben/unten
verschieben oder ein† - und ausrücken.
•
•
•
•
*
†
Was den Funktionsumfang jedoch bei Weitem noch nicht ausschöpft.
beispielsweise für Unterroutinen
Ausführen. Die Debugger-Funktionen –
• Debuggen: Führt die Aktion des Skripts «überwacht» in der Entwicklungsumgebung aus und ermöglicht dadurch:
– ein Reagieren auf Fehler,
– interaktives Anpassen der Aktionen,
– Pausieren des Skripts,
– die Einsicht und Modifikation von Variablen,
– eine Änderung des Programm- bzw. Skriptablaufs
• Beenden: Beendet den laufenden Debugging-Durchlauf;
• Anhalten: Pausiert den laufenden Debugging-Durchlauf;
• Einzelschritt: Durchläuft das Skript Schritt für Schritt;
• Ausführungsposition setzen: Legt fest, welche Aktion als nächstes ausgeführt wird;
• Haltepunkt umschalten: Definiert eine Skriptposition, an der der DebuggingDurchlauf pausiert oder löscht einen solchen.
• Ausführen: (Strg+F5) Das Skript wird nicht überwacht ausgeführt (unter Debuggen-Ribbon).
i
In der rechten, unteren Ecke des Bereichs Aktionen im Ribbon-Menü befindet sich ein kleines Pfeilsymbol: Ein Klick darauf blendet das linke
Aktionenmenü aus und vergrößert somit das Skriptfenster für eine übersichtlichere Skriptbearbeitung!
Am linken Rand – die Liste der Aktionen:
•
•
•
•
•
•
•
•
•
•
•
Favoriten (einfach Aktionen hineinkopieren)
Benutzerinteraktion
Variablen
Dateioperationen
Registry bearbeiten
Benutzermanagement
Netzwerkfunktionen
Dienste steuern
Systemfunktionen
Programmfluss
gui-Automatisierung
Abbildung 3–53: Aktionen
Automate |
93
Im Hauptfenster – dem Skriptfenster – werden die einzelnen gui-Aktionen gelistet
(das spätere Skript), um die Programmschritte zu testen und zu editieren. Sämtliche
Aktionen können darin angelegt, verschoben und/oder gelöscht werden.
Rechts daneben, das Variablenfenster – darin werden Variablenwerte angezeigt. Es
stehen zwei Ansichten zur Verfügung, eine für baramundi Variablen, eine andere
für Laufzeitvariablen.
• Laufzeitvariablen: Bei Ausführung durch das Skript erzeugte Variablen,
• baramundi Variablen: interne Variablen, wie z.B.bms-Pfad.
Unten dann das Ausgabefenster. Auch hier stehen zwei Ansichten zur Verfügung:
die Fehlerliste, zur Anzeige von Syntaxfehlern und die Ausgabe, in der die einzelnen
Aktionsschritte protokolliert werden.
Oberfläche anpassen
Die Anzeigeelemente des Automation Studios lassen sich über das Menü obenrechts bequem auf die individuellen Bedürfnisse des Benutzers anpassen.
Abbildung 3–54: Skript- und Variablenfenster
Im Menüpunkt Fenster ist es möglich sämtliche Arbeitsfenster ein- oder auszublenden. So könnte – um mehr Platz auf der Oberfläche zu schaffen – zum Beispiel
beim Editieren im Skriptfenster die Variablenansicht abgeschaltet, und bei Bedarf
wieder zugeschaltet werden. Auch die Statusleiste im unteren Bereich des Studios
kann ein- und ausgeblendet werden.
Das Variablenfenster kann – je nach Präferenzen des Anwenders – frei platziert
werden. Dazu ist es lediglich mit der Maus zu verschieben. Um das Fenster am
unteren oder rechten Rand «anzudocken» sind die Platzierungsmarken zu beachten:
Ziehen Sie beim Platzieren des Fensters die Maus direkt über die Marken, ein
Schatten zeigt daraufhin die entsprechende Position an.
Dem Automation Studio stehen verschiedene Oberflächen-Stile zur Verfügung:
Office 2007 Blue, Office 2007 Black, Visual Studio und Office XP. Die Änderungen
können über den Menüeintrag Änderungen zurücksetzen wieder in ihren Ausgangszustand zurückgesetzt werden*.
i
Tastenkombinationen können über das Dropdown-Menü der Titelleiste des
Automation Studios unter Weitere Befehle angepasst werden.
Deploy-Skripte anlegen/Neue Aktionen hinzufügen
Nach der Erstellung eines neuen Deploy-Skripts oder dem Öffnen eines bereits
vorhandenen Skripts (über die Funktionsleiste links-oben) sind die entsprechenden
Aktionen (links, aus dem Aktionsmenü) mit der Maus an bestimmten Positionen
in das Skriptfenser zu schieben oder zu doppelklicken. Daraufhin öffnet sich
ein Dialog, indem die Angaben für den jeweiligen Programmschritt eingetragen
werden. Nach Überprüfung und Bestätigung des Dialogs befinden sich die erstellten
Aktionen im Hauptfenster und können dort getestet, verschoben oder auch wieder
gelöscht werden.
Skriptsteuerung (Programmfluss)
Sämtliche Aktionen, die dem Skriptablauf dienen, sind im Bereich Programmfluss
im Aktionsmenü (links) zusammengefasst. In Verbindung mit den Pfeilfunktionen in der Ribbon-Leiste lassen sich auf sehr übersichtliche Art und Weise gut
strukturierte Skripte erstellen.
*
Dabei werden auch geänderte Tastaturkürzel zurückgesetzt!
Automate |
95
Kommentar. Ähnlich wie beim Programmieren, können dem Skript Kommentare
beigefügt werden, um Skriptinhalte kurz zu dokumentieren. Ein Kommentar
hat keinerlei Einfluss auf den Skriptdurchlauf, sondern dient lediglich der
Erläuterung des Skripts.
Abbildung 3–55: Programmfluss/Kommentar
Sprungmarke. Eine Sprungmarke definiert eine bestimmte Stelle im Skript, die in
einem Durchlauf, auch außerhalb der normalen Reihenfolge, angesteuert
werden kann.
Abbildung 3–56: Programmfluss/Sprungmarke
Gehe zu Sprungsmarke. Diese Aktion veranlasst das Skript an eine zuvor definierte
Sprungmarke zu springen, um die Ausführung dort fortzusetzen.
Abbildung 3–57: Programmfluss/Gehe zu Sprungmarke
Bedingung: Definiert einen Sprung, der an eine Bedingung geknüpft ist. Eine
entsprechende Bedingung kann im Aktionsmenü über zwei Operatoren, die
über logische Parameter verknüpft sind, gesetzt werden. Der Sprung erfolgt
dann zu einer vorher definierten Sprungmarke.
Abbildung 3–58: Programmfluss/Gehe zu Sprungmarke—Bedingung
Unterroutine. Unterroutinen sind Programmschritte, die sich – beispielsweise wiederholend – auf andere Aktionen auswirken. Sie werden einmal eingerichtet
und können danach stets wieder aufgerufen werden. Wird eine Unterroutine
in das Skript eingefügt und über die Pfeiltasten im Ribbon-Menü eingerückt,
dann zählen sämtliche, sich darunter befindlichen und ebenfalls eingerückten Aktionen zur Unterroutine. Die Unterroutine endet bei der nächsten
Ausrückung.
Abbildung 3–59: Programmfluss/Unterroutine
Unterroutine ausführen. Ruft eine zuvor definierte Unterroutine auf.
Abbildung 3–60: Programmfluss/Unterroutine ausführen
Bedingung: Startet eine Unterroutine nur dann, wenn eine Bedingung zutrifft
(vgl.«Bedingung»).
Automate |
97
Skript beenden. Beendet die Skriptbearbeitung – zumeist aufgrund einer zuvor
definierten Bedingung. Dabei kann unterschieden werden, ob das Skript mit
einem Fehler oder mit einer Erfolgsmeldung beendet wird.
Abbildung 3–61: Programmfluss/Skript beenden
GUI-Aktion/Analyzer
Um Skripte zur Automatisierung
von Installationen zu erstellen,
wird die Oberflächenaktion aus
dem Aktionsmenü (GUI Automatisierung) aufgerufen. Während die
zur Beschreibung der Aktionen
notwendigen Schritte bei der Wahl
von Leere Aktion jedoch frei eingegeben werden müssen, bietet sich
Abbildung 3–62: Oberflächenaktion
über den Aufzeichnungsmodus für
den Benutzer die komfortable Möglichkeit eine Installation zu starten und dabei die einzelnen, dafür notwendigen
Schritte bequem aufzuzeichnen. Das dabei entstehende Deploy-Skript kann im
Anschluss gespeichert und für nachfolgende Installationen verwendet werden.
i
Sofern Sie häufiger mit den Oberflächenaktionen arbeiten müssen: der
Ausführungsmodus lässt sich auch über die Taste F2 starten! Dazu muss das
Fenster des Automation Studios aktiviert sein.
Lokalisierung und Identifikation von Elementen
Die Sache mit der Lokalisierung/Identifikation von Programmelementen mit dem
Analyzer lässt sich etwas abstrakter mit einer Autofahrt in eine fremde Stadt unter
Zuhilfenahme eines Navigationsgeräts vergleichen. Beispielhaft wollen wir eine
Reise nach Wien mit der gui-Automatisierung auf der Oberfläche von Rechner,
diesem kleinen Taschenrechner in Windows-Betriebssystemen vergleichen.
Bei einer Reise nach Wien verschlägt es einen Touristen ganz sicher ins Zentrum,
denn er möchte unbedingt den Stephansdom, die Ruprechtskirche oder Maria Am
Gestade besichtigen. Sein Navigationsgerät wird sich zunächst die Gesamtheit –
also Wien – suchen und von dort aus seine Suche verfeinern.
Abbildung 3–63: Die Stadt Wien
Abbildung 3–64: Das Anwendungsfenster
Ganz ähnlich verhält es sich mit dem Analyzer des Automation Studios: Nehmen
wir also den Rechner unter Start/Programme/Zubehör. Ähnlich wie ein Navigationsgerät zunächst die Stadt findet, trifft auch der Analyzer zunächst die Gesamtheit,
sei dies nun ein Programm, ein Dialog oder ähnliches. In unserem Falle die Software
selbst, also den Rechner – die äußere Grenze, wenn Sie so wollen – das Anwendungsfenster.
Das Anwendungsfenster (TopWindow) ist die höchste Auswahlhierarchie.
Unser Tourist muss, um seine Besichtigungstour zu starten, ins Wiener Stadtzentrum, den Ersten Bezirk (Innere Stadt).
Im Rechner gelte es die Grundweisheit 1+1=2 zu automatisieren. Auch dazu muss
in eine kleinere Einheit navigiert werden, einem Kindfenster im Hauptfenster:
Hier einem generischem Control – also tatsächlich wie der erste Bezirk in Wien,
denn in diesem Control befinden sich die eigentlichen Ziele, die Taste 1 und das
Gleichheitszeichen.
Automate |
99
Abbildung 3–65: Der erste Bezirk
Abbildung 3–66: Das Kindfenster
Das Kindfenster ist die den Elementen übergeordnete Auswahlhierarchie.
Der Rest ist dann klar: Nachdem das Navigationsgerät den ersten Bezirk identifizierte, wird es unseren Touristen auch leicht zum «Steffl» und den anderen
Sehenswürdigkeiten führen. Ganz ähnlich der Analyzer im Automation Studio:
Ist der Mauszeiger erst einmal im Kindfenster, sind auch die Elemente – eben die
Zifferntasten sowie die =-Taste schnell lokalisiert.
Abbildung 3–67: Der «Steffl»
Abbildung 3–68: Das Element
Das Element ist schließlich das eigentliche Ziel.
So wie wie ein Navigationsgerät eine entsprechende Strecke zum Ziel lediglich
empfiehlt, so ist auch das erkannte Element unter dem Mauszeiger nur ein Vorschlag
des Analysers. Diesen gilt es vor der Übernahme ins Skript zu überprüfen und
gegebenenfalls noch anzupassen.
Ein wenig Theorie
Nachdem das Wien-Beispiel die grundsätzliche Vorgehensweise bereits kurz verdeutlichte, hier noch ein paar «offizelle» Anmerkungen zum Thema.
Bei der Identifikation der Elemente, die für eine Automatisierung von Softwareinstallationen notwendig sind, bedient sich baramundi Automate zweier Konzepte:
dem Windows Application Programming Interface (Winapi) sowie Microsoft Active
Accessibility (m s a a).
Es handelt sich um Programmierschnittstellen, die es Programmierern erlauben
Software für Windows-Betriebssysteme zu entwickeln. Die für Automate benutzten
Klassen ermitteln i.a.R.die Elemente von Dialogen. So werden die TopWindows
(Rahmenfenster, Dialoge, Ansichten) sowie die Controls (Steuerelemente, schwarzer
Rahmen) stets anhand von Winapi-Klassen oder über Winapi-Methoden ermittelt.
Hierbei handelt es sich um eine von Microsoft entwickelte Schnittstelle, über die
ein Zugriff auf Programminformationen (Text, Position, Farbe etc.) eines Elements
genommen werden kann. Über msaa ist eine Kommunikation mit Standardbenutzeroberflächen möglich, um so einen Zugang zu deren Oberflächenelementen
herzustellen, also um solche Elemente zu identifizieren, auszulesen und gegebenenfalls damit zu interagieren.
Analyse von Elementen. Bei der Analyse von Elementen (bottom-to-top-Analyse) wird
zunächst das Steuerelement und danach das m sa a-Objekt ermittelt, welches sich
unter dem Mauszeiger befindet. Der Weg vom msaa-Objekt bis zum gefundenen Steuerelement wird im Analyzer unter MSAA-Objekt dargestellt. Schließlich
analysiert das System, ausgehend vom Steuerelement nach oben durch die Fensterstruktur, den Pfad bis zum Anwendungsfenster. Der dabei ermittelte Pfad wird im
Analyzer unter Steuerelement gelistet.
Unterschieden/Identifiziert wird nach dem Namen der Elemente, nach deren Pfaden
und ihren Merkmalen (Größe, Farbe, Position etc.). Für die ermittelten Kriterien
wird ein Typ festgelegt und im Aktionsdialog vorgeschlagen. Dabei wird vorrangig
auf einen normalen Steuerelement-Typ abgebildet und zwar auf den, der als am
wahrscheinlichsten erscheint. Lediglich wenn das gewünschte Element über seine
Signatur nicht auf einen der Basistypen – der Versuch einer Abbildung zunächst auf
Basistypen ist sinnvoll, da über die Basistypen präzisere und vielfältigere Aktionen
zur Verfügung stehen, als bei einem (generischen) msaa-Objekt – abgebildet werden
kann, wird MSAA-Control als Typ ausgewählt.
Automate |
101
WinAPI
MSAA
Identifikation von Elementen. Um ein Element im Skriptdurchlauf zu identifizieren
und wiederzufinden, verhält es sich umgekehrt (top-to-bottom Analyse): Zunächst
wird unter allen verfügbaren Anwendungsfenstern dasjenige ausgewählt, welches
zuerst auf die angegebenen/ermittelten Suchkriteren passt. Danach wird die komplette Struktur der Steuerelemente des Anwendungsfensters untersucht, bis das
spezifizierte Steuerelement gefunden wird. Sofern diese Suche ergebnislos verläuft,
wird das nächste, passende Anwendungsfenster untersucht. Ist ein (optionales)
msaa-Objekt in den Suchkriterien definiert, wird ausgehend vom lokalisierten
Steuerelement das darin liegende m s aa-Objekt ermittelt. Dabei wird die gesamte
Hierarchie der m s aa -Objekte untersucht, bis das gewünschte Objekt gefunden ist
(oder die Suche erfiolglos blieb).
Benutzereingaben simulieren
Zur Aufzeichnung einer Installation mittels des Analyzers ist der Aufzeichnungsmodus zu starten (Start einer Oberflächenaktion über ein Doppelklick auf GUI
Automatisierung/Oberflächenaktion im Aktionsmenü* ). Anschließend wird das Installationsprogramm ausgeführt. Um nun eine Standardaktion auszuwählen wird
der Mausanzeiger zum gewünschten Element geführt – ein Rahmen erscheint.
Gleichzeitig werden im rechten Analyzer-Fenster (Windows Analyzer) sämtliche
Angaben zum gewählten Element angezeigt.
Befindet sich der Mauszeiger auf dem gewünschten Element, so öffnet sich durch
einen Rechtsklick darauf der GUI AktionsDialog. Darin lässt sich nun überprüfen, inwiefern die Angaben auch mit dem gewünschten Element übereinstimmen. Gegebenenfalls
können hier auch Änderungen vorgenommen werden. Speziell unter Typ und Ziel gibt
es Möglichkeiten Suchangaben zu verändern
Abbildung 3–69: Aktionsdialog
oder aber zu konkretisieren.
Typ: Hier kann eingestellt werden, als was das Element behandelt werden soll.
Darüber ist dann ebenfalls die zur Verfügung stehende Aktion festzulegen.
* Für exzessive Nutzer von Oberflächenaktionen: Bei aktivem Fenster des
Automation Studios führt die Taste F2 vermutlich schneller zum Ziel.
Ziel: Öffnet den Dialog zur Definition der Suchkriterien.
Aktion: Ist diejenige Aktion, welche auf dem Element ausgeführt werden soll.
Aktionseinstellungen: spezifizieren die gewählte Aktion
Timeout: Zeitlimit, nach dessen Verstreichen die Aktion abbricht, wenn das
Ziel nicht gefunden wurde.
Fehler ignorieren: Skript wird trotz Fehler fortgesetzt (Pendant zur Option
hinter der Aktion im Skript).
Der Dialog Suchkriterien ist insofern
von besonderer Bedeutung, da in ihm
Verfeinerungen zu gesuchten Objekten angegeben werden können. In drei
übersichtlichen Kategorien (vier, bei
msaa -Objekten) ist es möglich, die
Objektauswahl zu konkretisieren –
zum Beispiel bei mehreren zur Auswahl stehenden Objekten in einer gemeinsamen Ebene.
Über die grünen Pfeitasten innerhalb
des Dialogs können die gewählten Aktion zunächst getestet werden; dabei
Abbildung 3–70: Suchkriterien
wird die entsprechende Aktion durchgeführt. Durch eine Bestätigung der Auswahl über Ok schließt sich der Dialog und
die Aktion wird als Schritt des Deploy-Skripts eingetragen.
Play:
Play&OK:
OK:
Abbrechen:
die Aktion wird getestet
die Aktion wird getestet und ins Skript übernommen
die Aktion wird ungetestet ins Skript geschrieben
die Aktion wird abgebrochen
Abbildung 3–71: Fehlerliste
Automate |
103
Ausgabe/Fehlerliste. Im unteren Bereich des Automation Studios befindet sich das
Ausgabefenster. Darin wird die Ausgabe der Skriptverarbeitung angezeigt. Mit einem
Doppelklick auf einen Eintrag lässt sich schnell zur Aktion navigieren.
Die Fehlerliste gibt bereits vor der Ausführung des Skripts, aber auch währenddessen
Fehler aus. Sofern also Variablen nicht definiert sind, eine benötigte ini-Datei nicht
gefunden wird et cetera – die Fehlerliste weist darauf hin.
Aufzeichnungsmodus
Im laufenden Aufzeichnungsmodus kann die Maus über einen Fensterdialog geführt
werden, wobei dem Benutzer die darin enthaltenen Fenster und Steuerelemente, also
alles das, was einem Benutzer an Funktionen für eine Installation zur Verfügung
steht, angezeigt werden. Die Darstellung erfolgt in verschiedenfarbigen Rahmen:
• Anwendungsfenster (TopWindow) – das Objekt selbst (über Winapi ermittelt)
• Steuerelement (Controls) – schwarzer Rahmen (über Winapi ermittelt)
• m s a a-Objekt – roter Rahmen (über m s a a ermittelt)
Abbildung 3–72: Analyzer-Window
Sämtliche, im Aufzeichnungsmodus ermittelten
Werte werden im Analyzer-Window rechts angezeigt. Die Informationen sind von oben nach
unten entsprechend der oben erwähnten Reihenfolge sortiert: Unter Allgemein werden grundsätzliche Informationen zum gefundenen Element aufgeführt; Anwendungsfenster sind die
TopWindows-Einstellungen; unter Steuerelement
(WinAPI) (schwarzer Rahmen) folgen die Werte zum Basiselement und unter MSAA-Objekt
(MSAA) (roter Rahmen) die, der m s a a -Elemente.
Unter Optionen kann festgelegt werden, ob sich
das Fenster des Automation Studio während der
Aufzeichnung minimieren soll oder nicht.
Unten, in der Statuszeile des Analyzer-Windows,
werden noch einige Angaben zu den Koordinaten
der aktuellen Mauszeigerposition gegeben. Dabei
wird zwischen Desktop- (absolut zum Objekt) und
Control-Koordinaten (relativ zum Objekt) unterschieden. Darüber hinaus wird der
Farbwert des Pixels, welcher sich unter dem Mauszeiger befindet, ausgegeben.
i
Mit der Tastenkombiniation Strg+L kann im Aufzeichnungsmodus die
Analyze-Funktion unterbrochen werden, um die Maus «normal» benutzen
zu können. Ein abermaliges Strg+L unterbricht die Pause wieder und lässt
eine Elementeauswahl über die rechte Maustaste zu.
Ein Beispiel
Zum Zwecke der Veranschaulichung wollen wir ein kleines Beispiel bemühen. Dazu soll die Installation des Editors Notepad++ automatisiert werden. Wir wollen
annehmen, das Installationsprogramm, anhand dessen die einzelnen Installationsschritte aufgezeichnet werden sollen, befände sich bereits in einem bekannten
Ordner des Rechners.
1. Doppelklicken Sie im Aktionsmenü Prozess starten.
Abbildung 3–73: Prozess starten
Damit die Installation automatisiert werden kann, muss dem Skript zunächst bekannt sein wie und wo das Programm gestartet werden kann.
2. Geben Sie im sich öffnenden Dialog den Pfad zu Notepad++ ein und deaktivieren Sie die Option Auf Beendigung warten.
3. Bestätigen und schließen Sie Ihre Eingaben.
4. Führen Sie das Skript aus, um das Setup zu starten.
5. Starten Sie den Aufzeichnungsmodus.
Da Sie sich momentan im Aufzeichnungsmodus befinden, wird das Skriptfenster
nicht angezeigt. Folgen Sie einfach der Installation:
Automate |
105
6. Rechtsklicken Sie die zur Installation benötigten Schalter der jeweiligen Dialoge und bestätigen Sie die entsprechende Aktionsauswahl mit einem Klick
auf Play&OK und schließen Sie den Windows-Analyzer.
Debugger
Ein Highlight des Automation Studios ist sicherlich der Debugger. Mit seiner Hilfe
ist es möglich Deploy-Skripte auf bequeme und übersichtliche Art und Weise –
über die Ribbons der Ausführen-Gruppe – auf deren Korrektheit hin zu überprüfen.
Um beispielsweise das eben erstellte Notepad-Installationsskript zu testen, drücken
Sie im Ribbon-Menü Ausführen auf das Debuggen-Symbol. Der Debugger beginnt
daraufhin sämtliche Aktionsschritte während der Ausführung zu überwachen.
Um den Debugging-Durchlauf zu beenden dient das nächste Symbol Beenden.
Beenden heißt in diesem Zusammenhang: Der Debugging-Vorgang bricht ab, es
sind keine weiteren Interventionen im Skript mehr möglich. Über das AnhaltenSymbol kann der Durchlauf unterbrochen werden. Eine solche Unterbrechung
stoppt die Skriptbearbeitung lediglich, hierbei ist es möglich noch Änderungen und
Korrekturen vorzunehmen. Mittels des Einzelschrittsymbols erfolgt der Durchlauf
nicht automatisch von oben nach unten, sondern schrittweise – und zwar an der
aktuellen Aktion, also an der jeweiligen Ausführungsposition.
Mit Ausführungsposition setzen wird diejenige Aktion im Skript gewählt, bei der der
Durchlauf starten soll; über Haltepunkt umschalten ist es möglich, das Skript an
einer bestimmten Aktion nicht auszuführen.
Die Aktivierung der Checkboxen rechts neben den Programmschritten verhindert
den Programmstopp beim Durchlaufen fehlerhafter Aktionen. Der Durchlauf wird
an einer auf diese Weise markierten Stelle nicht unterbrochen, sondern läuft stattdessen mit der nächsten Aktion weiter. Die drei Käfer/Bugs in der Ribbon-Leiste,
dienen der Schnellsteuerung von Skriptdurchläufen:
Beenden:
Die Skriptbearbeitung wird abgebrochen.
Anhalten:
Stoppt den Durchlauf des Skripts an der aktuellen Stelle.
Einzelschritt:
Gestattet den schrittweisen Durchlauf eines Skripts.
Zudem lassen sich einzelne Bereiche des Skripts von einem Durchlauf durch Auskommentieren ausschließen respektive überspringen, um beispielsweise nur bestimmte Skriptabschnitte zu testen. Über die Ribbon-Funktion Ausführungsposition
setzen ist es möglich Aktionen zu kennzeichnen, bei denen ein Durchgang starten
oder fortsetzen soll; mittels Haltepunkt umschalten können umgekehrt Aktionen im
Skript definiert werden, bei denen der Durchlauf unterbrochen wird.
7. Debuggen Sie nun Ihr eben erstelltes Skript.
Fehlerbehandlung
Läuft ein Skript auf einen Fehler, bietet ein
Fehlerdialog dies Optionen an:
• Skriptausführung abbrechen. Die Skriptausführung wird beendet, keine weiteren Interventionen sind möglich.
• Skriptausführung unterbrechen. Die
Skriptausführung wird unter-, aber
nicht abgebrochen, d.h. es können
Abbildung 3–74: Fehlerdialog
Fehler korrigiert werden, um das
Skript nochmals zu debuggen.
• Fehler ignorieren und Skriptausführung fortsetzen. Die Skriptausführung wird
ohne Beachtung der fehlerhaften Aktion versucht fortzusetzen.
Noch ein Beispiel
Im Editor Notepad soll die Standardschrift verändert werden, und zwar «ferngesteuert», bereits hier durch Hilfe von Variablen. Doch der eigentliche «Protagonist»
sei der Aufzeichnungsmodus. Um Aktionen aufzeichnen zum können, muss das
Programm erst einmal gestartet werden.
1.
2.
3.
4.
Doppelklicken Sie unter Systemfunktionen den Eintrag Prozess starten.
Geben Sie unter Kommando die Datei notepad.exe ein.
Wählen Sie im Startverhalten den Punkt Normal starten und
Deaktivieren Sie die Option Auf Beendigung warten.
Automate |
107
Abbildung 3–75: Notepad starten
1.Skriptzeile: Externen Prozess [notepad.exe] starten
Der Editor wird gestartet. Nun können die weiteren Schritte über den Aufzeichnungsmodus ermittelt werden.
5.
6.
7.
8.
Starten Sie den Aufzeichnungsmodus.
Wählen Sie mit der linken Maustaste den Menüpunkt Format und
mit der rechten Maustaste Schriftart.
Prüfen und bestätigen Sie den Aktionsdialog mit Play/OK.
Abbildung 3–76: Schriftartmenü
Aus [Menu Control] mit dem Ziel [Unbekannt - Editor] [Menüeintrag "Schriftart..." auswählen] ausführen
Damit ist das Schriftartmenü geöffnet und es kann eine alternative Schrift (Schriftart/Schriftschnitt/Schriftgröße) gewählt werden: hier die Courier New, im Standardschnitt der Größe 10 (Pixel), das heißt, es werden zunächst drei Aktionen
benötigt, nämlich für Art, Schnitt und Größe.
9. Rechtsklicken Sie unter Schriftart auf Courier New und dann auf Play&Ok.
!
Möglicherweise werden Sie bei diesem Schritt aufgefordert Ihre Wahl
zu konkretisieren, da sich auf gleicher Auswahlebene weitere Elemente
befinden.
Abbildung 3–77: Aufforderung zur Konkretisierung der Auswahl
In einem solchen (nicht selten vorkommenden) Fall, bestätigen Sie bitte die
Meldung und drücken den Auswahlschalter unter Ziel. Im sich daraufhin
öffnenden Suchkriterien-Dialog verfeinern Sie Ihre Auswahl (die Resource-ID
ist zumeist eine gute, erste Wahl), so dass die Elementwahl eindeutig ist.
Abbildung 3–78: Schriftart auf «Courier New» wechseln
Automate |
109
9.
10.
11.
12.
Rechtsklicken Sie unter Schriftart auf Courier New und dann auf Play&Ok.
Rechtsklicken Sie unter Schriftschnitt auf Standard und dann auf Play&Ok.
Rechtsklicken Sie unter Schriftgrad auf 10 und dann auf Play&Ok.
Rechtsklicken Sie auf Ok und dann auf Play&Ok.
Und das ergibt die nächsten Skriptzeilen:
Auf [Combo Box] mit dem Ziel [Schriftart] die Aktion [Eintrag "Courier New" auswählen] ausführen
Auf [Combo Box] mit dem Ziel [Schriftart] die Aktion [Eintrag "Standard" auswählen] ausführen
Auf [Combo Box] mit dem Ziel [Schriftart] die Aktion [Eintrag "10" auswählen] ausführen
Auf [Button] mit dem Ziel [Schriftart\OK] die Aktion [Button drücken] ausführen
In aller Regel wird beabsichtigt sein, die entsprechende Anwendung nach den zu
treffenden Einstellungen auch wieder zu schließen.
13. Linksklicken Sie auf Datei, rechtsklicken Sie auf Beenden.
14. Drücken Sie auf Play&Ok und beenden Sie die Aufnahme.
Abbildung 3–79: Notepad beenden
Diese Aktion bringt zugleich die letzte Skriptzeile, nämlich:
Auf [Menu Control] mit dem Ziel [Unbekannt - Editor] die Aktion [Menüeintrag "Beenden" auswählen] ausführen
Damit ergibt sich das folgende Bild:
Abbildung 3–80: Fertiges Skript
Der Schriftartwechsel im Editor Notepad kann damit automatisiert stattfinden.
Prüfen Sie die Funktionsfähigkeit des Skripts mit dem Debugger:
15. Debuggen Sie das Skript durch einen Klick auf das Debuggen-Ribbon.
Arbeiten mit Variablen
Variablen kommen immer dann zum Einsatz, wenn zwar eine bestimmte Information benötigt wird, diese jedoch von Client zu Client andere Werte aufweisen können
– wie zum Beispiel der Rechnername. Andere Anwendungsgebiete sind numerische
Ausdrücke (z.B. Zähler), die Analyse von Übergabe- und Rückgabewerten – also
imgrunde Situationen, in denen Variablen eine Art Platzhalterfunktion einnehmen
können.
Die im Automation Studio erreichbaren Variablen gliedern sich in:
• bms-Variablen – interne baramundi Variablen,
– Projektvariablen: Vom Anwender zu Simulationszwecken, das heißt nur
für die Arbeit im Automation Studio gesetzte Variablen
– Install.ini: beim Start aus der Install.ini gesetzte Variablen
– Systemvariablen: Von der Laufzeitumgebung gesetzte Variablesn, die
stets vorhanden sind.
• Laufzeitvariablen – bei Ausführung durch das Skript erzeugte Variablen
Automate |
111
i
Die in der Management Suite erstellten Variablen für Jobs und Clients können auch
in Deploy-Skripten benutzt werden.
Projektvariablen können von Laufzeitvariablen überschrieben werden.
Projektvariablen, die nicht durch Laufzeitvariablen überschrieben werden
können sind: BMAPath, OSType, Domain, Architecture, Arch!
Die Aktionen für den Umgang mit Variablen befinden sich im Bereich Variablen
des Aktionen-Menüs (links):
• Variable setzen: Definiert eine Variable
• Variable ermitteln: Berechnet einen Variablenwert
Zum Zwecke der Veranschaulichung soll wiederum ein kleines Beispiel dienen, das
möglicherweise nur wenig praktischen Nutzen bietet, dafür jedoch in aller Kürze
einen konkreten Blick in die Variablenwelt ermöglicht.
Beispiel: Software (wenn vorhanden) deinstallieren
Das folgende Skript soll zunächst überprüfen, ob eine bestimmte Software (Notepad++) auf einem Zielsystem vorhanden ist, um diese dann gegebenenfalls zu
deinstallieren. Das soll mit Hilfe einer Variable (Notepad++) geschehen.
In einem ersten Schritt muss eine entsprechende Variable eingerichtet werden, die
gesuchte Software lokalisiert, oder eben nicht.
1.
2.
3.
4.
Doppelklicken im Aktionen-Menü den Eintrag Variable ermitteln.
Unter Variablennamen des Dialogs benennen Sie die Variable Notepad++.
Als Quelle ist Installierte Software Infos anzugeben.
Der Parameter ist die gesuchte Software: Notepad++.
Abbildung 3–81: Variable ermitteln
Nach der Bestätigung Ihrer Angaben enthält das Skript die erste Zeile, nämlich:
Variable [Notepad++] aus [Installierte Software Infos] ermitteln: Notepad++
Sie können das Vorhandensein der Variable übrigens leicht nachprüfen, indem
Sie diese erste Zeile als Einzelschritt laufen lassen und in der rechten Ansicht der
Laufzeitvariablen die Werte von Notepad++ anzeigen lassen: der Variablenwert ist
FOUND.
Trifft das zu, wird also eine entsprechende Software gefunden, dann soll diese
deinstalliert werden; falls nicht, mit einer Meldung des Nichtvorhandenseins der
Software beenden. Eine solche Bedingung kann über eine Bedingung im Skript
eingearbeitet werden. Dazu muss zunächst eine Sprungmarke definiert werden.
Abbildung 3–82: Sprungmarke
Sprungmarke: Definiert die Skriptposition, auf die beim Zutreffen der Bedingung
die Skriptbearbeitung weiter ausgeführt werden soll.
Abbildung 3–83: Gehe zu Sprungmarke
Gehe zu Sprungmarke: Dieser Sprung verweist im Falle des Vorhandenseins der
gesuchten Software, auf die definierte Sprungmarke, die eine entsprechende Aktion
– eben die Deinstallation – veranlasst. Ansonsten, also wenn die zu deinstallierende
Software gar nicht installiert wurde, soll eine entsprechende Meldung auf dem
Server vermerkt werden. Damit ergeben sich noch die folgenden Aktionsschritte:
Automate |
113
Abbildung 3–84: Skript beenden
Skript beenden: Diese Aktion – also für den Fall, dass die Variable nicht gefunden
wird – beendet die Skriptbearbeitung mit einer entsprechenden Meldung.
Abbildung 3–85: Prozess starten
Prozess starten: Nach dem Sprung soll nun ein Prozess gestartet, also die Deinstallation vorgenommen werden. Dazu wird ein entsprechendes Konsolen-Kommando
gesetzt, welches dann die Deinstallation in Gang setzt – die dann wiederum mit
entsprechenden gui-Aktionen zu automatisieren ist. Das gesamte Skript sieht dann
so aus:
Abbildung 3–86: Programmschritte
Abbildung 3–87: baramundi Inventory
Inventory
Die Inventur (lat.invenire: etwas vorfinden) dient der Erfassung von Beständen. Was
jedoch in einem Kaufmannsbetrieb am Ende einer Periode in einem gesamtbelegschaftlichem Zählen, Wiegen und Messen endet, das heißt bei baramundi schlicht
«Inventory» und lässt sich in wenigen Handgriffen bewerkstelligen – dient freilich
dem selben Zweck: nämlich der Erfassung; in unseren Fall jedoch der Hard- und
Softwaredaten Ihrer IT-Landschaft.
Auf den folgenden Seiten erfahren Sie, wie die Hard- und Software Ihrer Zielsysteme
inventarisiert werden kann. Im Anschluss daran werden die baramundi Funktionen
zur Verwaltung von Assets vorgestellt. Abschließlich widmet sich dieser Abschnitt
dem Modul baramundi a u t, zur Beurtleilung der Nutzung von Applikationen.
Inventarisieren von Hardware
Das Inventarisieren von Hardware bildet die Grundlage für die Verwaltung von
PC-Systemem und zugleich den Ausgangspunkt für automatisierte Betriebssysteminstallationen.
Inventory |
115
Inventarisieren mit Vorlagen
Eine Hardwareinventarisierung mit der Standard Hardware Vorlage greift auf das
bios und den pci-Bus zu. Die Daten werden dabei direkt aus den Chipsätzen der
Komponentenhersteller herausgelesen.
1.
2.
3.
4.
Wählen Sie in der Jobverwaltung den Eintrag Job—Neu.
Bennennen Sie den Job und doppelklicken Sie Inventarisierung durchführen.
Wählen Sie hier Standard Hardware Vorlage.
Bestätigen und beenden Sie den Dialog.
Nach Ausführung des Jobs werden die entsprechenden Daten am Client unter
Umgebung/. . ./Client in der h tm l-Ansicht im Register Inventur angezeigt. Dazu ist
Abbildung 3–88: Daten der Hardwareinventarisierung
unter Daten entweder auf Liste (wichtige Daten) oder – für eine detailliertere Ansicht
sämtlicher Daten – auf Tabelle (alle Daten) zu klicken.
Es besteht zudem die Möglichkeit der Erstellung eigener Vorlagen.
Wählen Sie dazu unter dem Knoten Inventory aus dem Aufgabenbereich Neu anlegen
den Eintrag HW Inventurvorlage. Um möglichen Problemen auszuweichen, können im
Register Optionen Parameter für den Hardwarescan angepasst werden.
So erlaubt die Option SpeedStep Support die
Identifikation SpeedStep-fähiger cpus von
Intel. Das gilt für mobile Varianten der
Pentium iii-, PentiumM- sowie für Pentium4- und PentiumD-Prozessoren. Damit
lässt sich feststellen, ob SpeedStep vorhanden ist und in welchem Modus die cpu
läuft (Battery-optimized/Full Power). Bei eiAbbildung 3–89: Vorlage
nigen Desktop-Rechnern kann die Aktivierung dieser Option zu Abstürzen führen – daher ist es ratsam die Option mit
Bedacht einzusetzen.
SMBus ist ein genormtes Protokoll, welches zur Abfrage von Systemdaten dient.
Bei älteren Rechnermodellen kann es vorkommen, dass die Abfrage keine Daten
zurückliefert. Somit kann im Voraus eingeschätzt werden, inwiefern ein Betriebssystemwechsel aufgrund der Hardwareanforderungen erfolgreich verlaufen kann,
ob einer neuen Anwendung genügend Festplattenplatz zur Verfügung steht, der
Hauptspeicher ausreicht oder ein Prozessor womöglich zu langsam ist, et cetera.
Die Hardwareinventarisierung des Inventory-Moduls nimmt pro Client weniger als
30 Sekunden in Anspruch. Da die Ausführung im Hintergrund erfolgt, wird der
Anwender während der Inventarisierung in aller Regel nicht gestört.
WMI-Inventarisierung
Sofern eine Inventarisierung über Vorlagen nicht zum gewünschten Ergebnis führt,
weil diese etwa bei der entsprechenden Hardware zu Abstürzen führt oder eine Hadwareinventarisierung nicht ausreicht, ist eine Inventur anhand der von Microsoft
Windows bereit gestellten Daten, stets durchführbar.
Inventory |
117
Windows Management Instrumentation (wm i) wurde ursprünglich als Teil des Windows NT Service Packs4 durch Microsoft freigegeben. Es ist der zentrale Verwaltungsdienst von Microsoft Windows Betriebssystemen und als fester Bestandteil
der aktuellen Windows-Plattformen dient es seither als Systemschnittstelle, über
die verschiedenste Daten ausgelesen werden können.
Die bms bietet über die wm i-Schnittstelle eine Inventarisierung der Hard- und
Softwaredaten eines Zielsystems. Die darüber abrufbaren Daten können jedoch von
denen der Standard-Hardwareinventarisierung abweichen. Sie unterscheiden sich
zum Teil hinsichtlich der Vielfältigkeit und Detailtiefe.
wm i bietet verschiedenste Datenabfragen an. Diese reichen von bios-Einträgen über
Registrierungsschlüssel bis zu benutzerdefinierten Einstellungen. Es besteht sogar die Möglichkeit selbst festzulegen, welche Daten über die wm i-Schnittstelle
abgefragt werden sollen, indem eine bestehende wm i-Inventarisierungsvorlage angepasst, oder eine neue Vorlage erstellt wird. Um eine Vorlage zu erstellen, wählen
Sie im Management Center den Knoten Inventory und aus dem Aufgabenbereich
den Eintrag WMI Inventurvorlage.
Über die WMI Inventurvorlage im Aufgabenbereich der Inventory-htm l-Ansicht
gelangen Sie in den entsprechenden Abfragedialog. Nachdem Sie die neu zu erstellende Vorlage im Register Allgemein benannt haben, stellt Ihnen das Register
Klassen über den Schalter Neu einen Wizard zum Verfassen einer wm i -Vorlage zur
Verfügung.
Sofern Sie einen Referenz-PC verwenden möchten, muss dieser und ein berechtigter
Benutzer angegeben werden. Da hier nur das grundsätzliche Verfahren vorgestellt
wird, verwenden wir an dieser Stelle keinen Referenz-PC. Klicken Sie auf Weiter
(Abb.3–90). Sie können nun wählen, ob Sie eine vordefinierte Klasse abfragen oder
eine freie mittels wql (WMI Query Language) definieren möchten. Wählen Sie
dazu die WMI-Klasse (Abb.3–91) und dann im Menü Gruppe den gewünschten
Eintrag (Abb.3–92); aktivieren Sie Klassen (Abb.3–93). Sie können einzelne Werte
anpassen und Bedingungen definieren.
Zudem ist es möglich weitere Eigenschaften definieren, wie zum Beispiel ein Zeitlimit, um einen Rückgabewert zu erhalten oder die Ausführung im Fehlerfall
abzubrechen (Abb.3–94). Die erstellte Abfrage kann getestet werden. Die Rückgabe erfolgt im Ergebnisbereich (Abb.3–95) Testen Sie Abfragen zunächst stets auf
Referenzsystemen*.
* Weiterführende Informationen zu WMI finden Sie auch auf der MicrosoftWebsite: http://technet.microsoft.com/de-de/library/cc787057.aspx.
Abbildung 3–90: Benennung
Abbildung 3–91: Wahl der Vorlage
Abbildung 3–92: Klassenauswahl
Abbildung 3–93: Klassenattribute
Abbildung 3–94: Zusätzliche Eigenschaften
Abbildung 3–95: Fertigstellung
Inventory |
119
Nach dem Beenden des Wizards, wechselt das bmc automatisch zur Übersichtsseite
des eben neu angelegten Jobs. Nun müssen diesem Job noch Clients oder Benutzer
zugewiesen werden.
Sofern Sie die Unterstützung des Wizards nicht benötigen, können Sie zur Erstellung
auch den Schalter Neu Expert verwenden. In diesem Fall öffnet sich nur ein einzelner
Dialog, indem Sie sämtliche Angaben hinterlegen können.
Falls Sie eine Inventarisierung nicht mehr benötigen, so kann diese in der htm l Ansicht des Clients im Register Inventur mit einem Klick auf das rote Kreuz auch
gelöscht werden. Das ist zum Beispiel dann sinnvoll, wenn die Inventarisierung
veraltete Daten aufgrund eines Hardwareaustausches enthält. Wenn zu einem
Eintrag weiterführende Informationen vorhanden sind, können diese in einem
Popup-Fenster dargestellt werden.
Inventarisieren von Software
Die baramundi Softwareinventarisierung ermöglicht ein exaktes Erfassen der auf
den Zielsystemen installierten Software. Dabei werden besonders Programme erkannt, die nicht über baramundi Deploy verteilt wurden.
Erfassen von Clients
Inventory erfasst Software auf Basis von Dateien und/oder Registry Keys. Der Vorteil
einer Erfassung anhand der Registry Keys – und daher die empfohlene Methode:
Die erforderlichen Softwareerkennungsregeln werden automatisch erstellt und
angewendet.
Bei der Erstellung eines entsprechenden Inventarisierungsjobs wird unter anderem zur Wahl einer Softwareinventarisierungsvorlage aufgefordert. Es stehen zwei
verschiedene Vorlagen zur Verfügung:
Registry Softwareinventarisierungsvorlage. (Abb.3–96) Mit Aktivierung der im Register
Registrierung bereitgestellten Optionen, lässt sich die Registierungsdatenbank eines
Zielsystems auswerten (Registrierung durchsuchen) und auf Basis der gefundenen
Registry Keys die dazu passende Softwareerkennungsregel beim Import automatisch
erstellen. Mit dieser Wahl übernimmt das System die Regelerstellung für Sie.
Abbildung 3–96: Scan über Registrierung
Abbildung 3–97: Scan über Dateien
Standard Softwareinventarisierungsvorlage. (Abb.3–97) Nicht jede, auf den Zielsystemen
installierte Software, hinterlässt Einträge in der Registry. Systemadministratoren kennen sicher PuTTY, Redakteure arbeiten möglicherweise mit TEX – doch keine dieser
Programme erstellt auswertbare Einträge in der Windows-Registrierungsdatenbank
und sind damit auch nicht über die Registry Softwareinventarisierungsvorlage
lokalisierbar. In diesen Fällen können Applikationen auf Basis von Dateien auf dem
Zielsystem ermittelt werden. Dazu ist im Register Dateisystem der zu untersuchende
Festplattenbereich anzugeben sowie eine Dateimaske zu wählen (i.a.R.*.exe), nach
der gesucht werden soll. Im unteren Bereich des Dialogs ist es möglich optional
anzugeben, ob Sie Checksummen ermitteln wollen und welche Scanpriorität dem Job
zugewiesen wird: Die Wahl von Niedrig bewirkt beispielsweise, dass der Scan zwar
mehr Zeit in Anspruch nimmt, jedoch dafür andere, aktuell laufenden Prozesse,
kaum beeinträchtigt.
!
Eine intensive Nutzung von Dateivorlagen erzeugt große Datenmengen, die
das Auswerten erschweren können.
Softwareinventarisierungsvorlagen selbst erstellen. Zudem ist es möglich, Vorlagen zur
Softwareinventarisierung selbst zu erstellen, indem die Optionen unter Registrierung
und Dateisystem variiert werden.
Inventory |
121
Regeln erstellen
Im Ergebnis solcher Scans werden gefundene Dateien in das Verzeichnis Inventory/Inventarisierte Dateien/keine passende Softwareregel geladen.
Auf Dateibasis. Um eine Softwareerkennungsregel zu bauen, klicken Sie unter Inventory/Inventarisierte Dateien/keine passende Softwareerkennungsregel auf die hier
aufgeführten Dateien und wählen Softwareerkennungsregel erstellen.
Unter Allgemein ist der Name obligatorisch, die restlichen Einträge sind
(Abb.3–98) optional: So kann beispielsweise unter Kategorie eine entsprechende Klassifizierung von Programmen vorgenommen werden, die dann auch so im
Clientregister Software angezeigt wird.
Im Register Dateien sind bereits Erkennungsmerkmale wie Größe, Name,
Hersteller aus der ausführbaren Datei
entnommen. Diese Werte sind modifizierbar. Um einen der Einträge zu
entfernen, ersetzen Sie dessen Inhalt
durch den Platzhalter Stern (*). Dieser
Platzhalter repräsentiert einen beliebiAbbildung 3–98: Softwareerkennungsregeln
gen Wert.
!
Löschen Sie hingegen einen Eintrag komplett, z.B.die Versionsnummer,
dann erfolgt ein Abgleich n u r dann, wenn in der .exe-Datei auch keinerlei
Information bezüglich der Version hinterlegt ist!
Nach der Bestätigung Ihrer Einstellungen wird die neu erstellte Regel unter Inventory/Softwareerkennungsregeln geführt und künftig angewendet.
Auf Basis der Registry Keys. Bei einem Scan der Registry Keys werden zu den gefundenen Einträgen automatisch Erkennungsregeln erstellt. Diese sind dann unter
Inventory/Softwareerkennungsregeln ersichtlich.
Abbildung 3–99: Regeldialog (Allgemein)
Abbildung 3–100: Regeldialog (Dateien)
Regeln anwenden
Die Regeln beim Registryscan werden nicht nur automatisch erstellt, sondern
auch automatisch angewendet und stehen danach unter Inventory/Inventarisierte
Dateien/Softwareerkennungsregel angewandt bereit.
Imzuge dieser Regelanwendung wird die erkannte Software am Client unter Umgebung/Logische Gruppierung im Register Software/Nicht kategorisiert angezeigt, sofern
noch keine Regelverknüpfungen zu einer Software stattfanden. Doch auch wenn eine Software bereits über baramundi verteilt wurde – also unter Deploy/Applikationen
vorhanden ist –, werden Anwendungen zunächst unter Nicht kategorisiert geführt.
Erst wenn in den Eigenschaften der Applikation unter Allgemein/Kategorie ein
entsprechender Eintrag erfolgt, wird auch gemäß dieser kategorisiert. Eine solche
Kategorie lässt sich demzufolge auch unter Deploy/Applikationen in den Softwareeigenschaften anlegen und wird dann in den Ansichten sofort übernommen. Die über
baramundi Deploy installierte Software ist von bereits vorhanden gewesenen Anwendungen schnell über das Installationsdatum (nur bei über baramundi verteilter
Software eingetragen) zu unterscheiden.
Die Softwareausstattung des inventarisierten Clients ist damit bereits ersichtlich* .
Das gilt analog auch für auf Dateibasis selbst erstellte Regeln.
*
Wenn auch nicht in der Ausführlichkeit eines Hardware-Scans.
Inventory |
123
i
Die inventarisierten Daten können bei Bedarf auch bequem in ein ExcelTabellenblatt exportiert werden. Dazu ist lediglich auf das entsprechende
Symbol (Ordner mit grünem Pfeil) rechts unter der Registerreihe zu klicken.
Verknüpfung erstellen
Nun ist es in der Praxis so, dass der Ersteinsatz von baramundi nicht in einer
Landschaft von Rechnern mit leeren Festplatten erfolgt, sondern in einer bereits
vorhandenen IT-Struktur etabliert werden muss.
Wird nun (über baramundi) Software verteilt, die davor bereits auf den entsprechenen Rechnern vorhanden war, so steht diese Software als Ergebnis des Scans
zunächst zweimal im Clientregister Software, nämlich unter baramundi Deploy
Applikationen, weil über baramundi verteilt, sowie unter ohne Kategorie, da bereits
vorher vorhanden. Das beeinträchtigt die Übersichtlichkeit.
Mehr noch: Das bloße Finden von Software auf einem Zielsystem bedeutet nicht,
dass diese dann auch über baramundi verwaltet werden kann. Das ist erst möglich,
wenn die entsprechenden Programme dem System unter Deploy/Applikationen zur
Verfügung stehen. Erst dann kann Software installiert/deinstalliert, die Lizenzverwaltung oder aut verwendet werden.
Um diese Probleme zu umgehen, können Applikationen mit Regeln* dergestalt
verknüpft werden, dass eine eindeutige Zuordnung möglich ist. Dazu ist es lediglich
notwendig auf das Kettensymbol am Ende der Kategorieanzeige aufgeführten Regel
zu klicken. Es öffnet sich ein Dialog, indem die zugehörige Applikation ausgewählt
werden kann. Nach Bestätigung der Auswahl wird statt der Regel die entsprechende
Applikation angezeigt und kann künftig verwaltet werden. Diese Verknüpfung
müssen pro Applikation nur einmal angelegt werden. Dabei können Regeln immer
nur jeweils einer Applikation zugeordnet sein! Eine solche Zuordnung zu einer
Regel ist auch direkt unter den Applikationen (Deploy/Applikationen/. . .) respektive
über deren Eigenschaften möglich.
i
Regeln zusammenfügen. Unter dem Knoten Softwareerkennungsregeln lassen sich
die Regeln direkt bearbeiten. Ein Zusammenfügen mehrerer Regeln zu einer
einzigen ist hier via Drag&Drop möglich. Dazu sind die entsprechenden
Regeln zu markieren und auf die zu belassende Regel zu verschieben.
*
oder umgekehrt
Abbildung 3–101: Inventory/Assets
Assets
Asset-Systeme dienen der Verwaltung von Anlagegütern. In der Finanzbuchhaltung
von bilanziellem Interesse, stehen in einer IT-Landschaft eher Punkte wie:
• Art der Anlagegüter,
• Anschaffungskosten der Anlagegüter,
• Lokalität der Anlagegüter
im Fokus der Betrachtung. Es geht also imgrunde um die Verwaltung und «Ortung»
von Hardware* in einer IT-Landschaft. Einen Teil der Funktionalität eines solchen
Systems bieten baramundi Assets.
* Zur Softwareverwaltung stehen baramundi Inventory und baramundi AUT
zur Verfügung.
Inventory |
125
Mit den Asset-Funktionen ist es möglich, Geräte zu verwalten. Insofern können
Drucker, Scanner, Beamer et cetera Eigenschaften zugewiesen, und bestimmten
Clients oder Clientgruppen zugeordnet werden. Das ermöglicht der Systemadministration eine schnelle Lokalisierung der Geräte. Über eine Lagerfunktion lässt
sich überdies feststellen, welche dieser Geräte sich im Einsatz befindet und welche keinen Nutzern zugeordnet sind. Schließlich lassen sich über Assets auch die
Anschaffungs- und Betriebskosten überblicken.
Asset-Typen definieren
Je nach der Beschaffenheit verwalteter Geräte ist es zunächst notwendig, einen
entsprechenden Asset-Typ anzulegen. Typische Geräte sind bereits definiert:
•
•
•
•
•
•
•
•
•
•
Beamer
Digitalkamera
Drucker
Externe Festplatte
KeyCard
Monitor
Multifunktionsgerät mufu
Scanner
SmardcardReader
Switch (Router)/Aktive Netzwerkkomponente
Jedem dieser Typen sind charakteristische Eigenschaften zugeordnet – zu sehen bei
Wahl eines Asset-Typs –, die das Gerät beschreiben. Wird ein weiterer Asset-Typ
benötigt, wählen Sie bMC/Verwaltung/Asset-Typen—Neu–Asset-Typ und tragen im
sich daraufhin öffnendem Dialog die Informationen zum neuen Gerät ein.
Im Register Allgemein ist ein Name (Abb.3–102) anzugeben. Zudem kann ein
entsprechendes Icon* gewählt werden. Im Register Standardwerte können zudem
einige Angaben zum Hersteller, zu den Kosten und dergleichen mehr (Abb.3–
103) hinterlegt werden; die Einträge technischer Informationen erfolgen in den
Eigenschaften des jeweiligen Asset-Typs. Diese Eigenschaften sind im Kontextmenü
des Asset-Typs unter Neu—Eigenschaften zu editieren. In diesem Dialog ist es unter
Verwendung eines entsprechenden Eigenschaftstyps möglich, Angaben zum Gerät
*
Das Bild muss als .ico-Datei vorliegen.
Abbildung 3–102: Asset-Typ (Allgemein)
Abbildung 3–103: (Standardwerte)
zu hinterlegen. Es können für ein Gerät mehrere Eigenschaften gesetzt werden.
Assets anlegen. Assets können bestimmten Clients oder Clientgruppen zugeordnet
werden. Erfolgt eine solche Zuordnung nicht, wird das entsprechende Gerät im
Asset-Lager geführt.
Assetanlage am Client. Um nun ein Gerät einem Client oder einer Clientgruppe zuzuordnen, markieren Sie das gewünschte Zielsystem und wählen im Kontextmenü
Neu—Asset.
Im ersten Dialog (Abb.3–104) ist dabei zunächst der Asset-Typ anzugeben und in
den darauffolgenden Dialogen sind neben dem Namen (obligatorisch) noch weitere
Angaben zum Asset und dessen Kosten möglich. Sind sämtliche Angaben getroffen
und bestätigt (öffnet sich der Eigenschaftsdialog des Assets) wird das neue Gerät
unter dem jeweiligem Client im Knoten Umgebung/Logische Gruppierung geführt.
Asset-Lager. Den baramundi Assets ist eine auch Lagerfunktion zugeordnet. Unter
Inventory/Asset-Lager werden sämtliche Geräte geführt, denen keinerlei Zielsysteme
zugeordnet sind. Das hat zweierlei Auswirkungen:
Inventory |
127
Abbildung 3–104: Neues Asset: Typ
Abbildung 3–105: Neues Asset: Parameter
Assetanlage im Lager: Es ist möglich Assets im Asset-Lager anzulegen. In diesem
Falle sind diese Assets noch keinem Client zugeordnet, können aber aufgrund
der Lagerhaltung von der Systemadministration auch nicht übersehen werden. Die
Prozedur entspricht der oben genannten.
Automatischer Lagerzugang bei Clientlöschung: Damit Geräte nach einer Zielsystemlöschung
nicht ungenutzt bleiben oder aus der Asset-Organisation fallen, werden sämtliche,
Clients zugeordnete Assets nach Löschung der Zielsysteme automatisch in das
Lager verschoben. Insofern kann eine Systemadministration solche Geräte auch bei
Zielsystemlöschungen nicht übersehen.
Assets verschieben, kopieren, referenzieren
Sind Asset-Typen definiert und Assets angelegt, können diese via Drag&Drop
jederzeit verschoben werden. Es ist also ohne Weiteres möglich, Assets mit Hilfe
der Maus von einem Client auf einen anderen zu verschieben. Die Folge ist die zu
erwartende: Das entsprechende Gerät wird am ursprünglichen Client entfernt und
stattdessen beim neuen Client eingetragen.
Darüber hinaus können Assets kopiert werden. Beim Wiedereinfügen fragt ein
Programmdialog Möchten Sie die ausgewählten Assets als Referenz einfügen oder
kopieren? Der Unterschied zwischen Referenz und Kopie ist in diesem Fall eben
jener, wie zwischen dem «Selben» und dem «Gleichen», wird nämlich ein Gerät
referenziert, so handelt es sich um das selbe Gerät: Ein Mitarbeiter aus dem Vertrieb
kann seinen Client auf einen Drucker (z.B.der Marke Lennon65) in der Entwick-
Abbildung 3–106: Asset-Lager
lungsabteilung referenzieren lassen – es handelt sich dabei nachwievor um ein und
den selben Drucker, nämlich dem, in der Entwicklungsabteilung. Dort müssen
dann auch die Ausdrucke abgeholt werden.
Bei einer Kopie hingegen handelt es sich um das gleiche Gerät: also einen weiteren
Lennon65. Dieses (baugleiche) zweite Gerät steht aber nun im Vertrieb. Der Vorteil
einer Kopie ist lediglich eine Ersparnis an Schreibarbeit, da sämtliche Werte des
ersten Geräts für das nächste übernommen werden. Ein Referenz-Asset hat in
seinem Kontextmenü auch keinen Eigenschaftseintrag; stattdessen heißt es darin:
Gehe zu tatsächlichem Asset, also in den Eigenschaftsdialog des nichtreferenzierten
Geräts.
i
Insofern ist es auch nicht möglich ein Asset auf den selben Besitzer zu
referenzieren. In einem solchen Falle wird das Gerät automatisch kopiert.
Eine Abfrage erfolgt nicht. Referenzen im Lager sind ebenfalls unzulässig.
Asset-Ansichten
Zum Zwecke einer übersichtlichen Verwaltung der Assets sind im Management
Center entsprechende h tm l-Ansichten (Abb.3–106) verfügbar. In ihnen sind sämtliche verfügbaren Asset-Typen, Assets und Lagerbestände bequem einzusehen und
zu verwalten.
Inventory |
129
Bereits in der Assetübersicht sind die Anzahl der Assets und wieviel sich davon im
Lager respektive in Verwendung befinden ersichtlich. Zudem werden die Kosten
der Anschaffung und des laufenden Betriebs angezeigt.
Die gelisteten Asset-Typen sind aufklappbar. Darunter liegen die einzelnen Geräte.
Angezeigt wird der Name und der aktuelle Standort (Lager- oder Clientzuordnung)
sowie der Besitzer der Assets. Mit einem Mausklick auf den Besitzer springt das
System zum entsprechenden Client und zeigt dessen Asset-Register mit den darin
enthaltenen Geräten an. Auch diese sind aufklappbar und geben in diesem Zustand
Auskunft über die Geräteeigenschaften und Referenzen. Für die Bearbeitung von
Assets stehen Ihnen also die Asset-Register der Clients unter Umgebung zur Verfügung als auch die Asset-Ansicht unter dem Knoten Inventory.
Mit den baramundi Assets stehen Ihnen flexible Funktionen zur Verwaltung von
Assets zur Verfügung. Neben Kostenaspekten und sonstigen Informationen zu den
entsprechenden Geräten, sorgen gerade die Zuordnung zu einzelnen Zielsystemen
sowie die Lagerfunktion für eine hohe Transparenz bezüglich des Einsatzes Ihrer
Hardware.
Application Usage Tracking
Mit baramundi aut ist es möglich, Statistiken bezüglich des Gebrauchs betrieblich
genutzter Software zu generieren. Dadurch wird die Systemadministration in die
Lage versetzt, Einsparpotenziale hinsichtlich nicht oder wenig verwendeter Software präzise lokalisieren zu können und so unnötig anfallende Lizenzkosten zu
vermeiden oder einer konsequenteren Nutzung zuzuführen.
Zudem lassen sich Rückschlüsse bezüglich der Nutzung vergleichbarer Anwendungen – beispielsweise unterschiedliche Textverarbeitungen (MS-Word/OOo-Writer,
Word03/Word07) – ziehen. Auch über die Auswertung solcher Daten sind Kosteneinsparungen denkbar.
Solche Usage-Tracking-Systeme stehen – mitunter zu Recht – im Verdacht, gegen
Datenschutzrichtlinien in Unternehmen zu verstoßen. Diesen Bedenken wurde
bei der Entwicklung von baramundi aut dergestalt Rechnung getragen, dass unser
Modul Zeiträume erfasst, nicht jedoch Zeitpunkte. Das heißt, nicht die genaue
Uhrzeit oder die exakte Anzahl der Verwendungen von Software durch einzelne
Benutzer sind Gegenstand der Analyse, als vielmehr die Betrachtung des Zeitraums
zwischen dem ersten und letzten Einsatz der entsprechenden Applikationen.
Abbildung 3–107: baramundi AUT
Intention von baramundi aut ist also die genaue Messung des Auslastunggrades
lizenzierter Software zum Zwecke der Reduktion betrieblicher IT-Aufwendungen.
Via Voreinstellung ist aut deaktiviert und nicht als Modul in der Suite sichtbar.
Erst nach einer entsprechenden Lizenzierung ist eine Verwendung möglich. Eine
30-tägige aut-Testlizenz ist Bestandteil des bms-Softwarepakets.
Die Wirkungsweise von baramundi AUT
Wir erfassen aus Datenschutzgründen nicht wann oder wie oft Software geöffnet
wurde, sondern lediglich das Datum der ersten und letzten Benutzung. Dabei gilt:
Unbekannt. Den Status unbekannt (ein Nutzungsgrad lässt sich nicht ermitteln)
erhält ein Programm dann, wenn ein Zielsystem seit 30 Tagen nicht mehr
aktiv war oder das Programm nach der Installation bis zu fünf Tage* lang
nicht benutzt wird. (Symbol: in weiß)
* Die fünf Tage Verweilzeit zwischen Installation und Erstbenutzung der
Software begründen sich in eventuellen Ausfalltagen.
Inventory |
131
Kürzlich genutzt. Diesen Status erhält Software, die innerhalb der letzten 30 Tage
benutzt wurde. (Symbol: in blau)
Länger nicht genutzt. Nach mehr als 30 jedoch weniger als 90 Tagen vergangener
Zeit der letzten Nutzung wird eine Software als gelegentlich genutzt gekennzeichnet. (Symbol: in blau)
Ungenutzt. Eine Software gilt als unbenutzt, wenn die letzte Nutzung länger als
90 Tage her ist oder wenn ein Programm installiert und seit fünf oder mehr
Tagen noch nicht aufgerufen wurde. (Symbol: in gelb)
Meldet sich der Client beim Server, liefert dieser eine Liste der zu prüfenden Anwendungen. Der Client kontrolliert dabei minütlich, ob eine dieser Anwendungen
gerade ausgeführt wird. Die vom Client erfassten Daten werden verschlüsselt gespeichert (es ist keine Klartextwiedergabe möglich). Bereits mit der kleinen, bei
jedem Verbindungsaufbau durchgeführten, Inventur des baramundi Agents, werden aut-Daten (erste und letzte Nutzung) übertragen. Sofern noch keine aut-Daten
vorhanden sind, bleibt das Feld letzte Nutzung leer.
baramundi AUT im Einsatz
Um mit aut die Häufigkeit des Einsatzes von Software zu protokollieren, muss
die entsprechende Option Überwachung der Applikationsnutzung aktivieren in den
Eigenschaften der Software (Abb.3–108) im Register AUT aktiviert werden. Der
Agent prüft daraufhin, ob ein bestimmtes Programm – zumeist eine .exe-Datei –
gerade auf dem Zielsystem benutzt wird. Daher ist das (ausführbare) Programm,
anhand dessen die Benutzung der Software erkannt werden soll, in diesem Dialog
mit anzugeben. Eine solche Spezifikation der Überprüfungskriterien erfolgt über
die Schaltfläche Hinzufügen. Darin (Abb.3–109) können, neben dem Pfad zum
entsprechendem Programm selbst, auch weitere Kriterien angegeben werden, um
eine eindeutige Überprüfung zu ermöglichen.
i
In diesen – wie auch an anderen Stellen im Programm – werden Platzhalter,
sogenannte wildcards, unterstützt.
Sind sämtliche Einstellungen getroffen, lassen sich die Ergebnisse einer aut-Analyse
an verschiedenen Stellen der baramundi Management Console verwenden.
AUT am Client. Die aut-Status von Anwendungen auf den Zielsystemen, lassen sich
an den Clients (Umgebung) im Register Software unter Nutzung einsehen.
Abbildung 3–108: Softwareeigenschaften/AUT
Abbildung 3–109: AUT-Kriterien
AUT an der Applikation. Eine graphische Auswertung der aut-Daten ist an der entsprechenden Applikation möglich, und zwar für sämtliche Clients, auf denen diese
Software installiert wurde. Im Register Nutzung stehen Ihnen dazu zwei Statistiken
zur Verfügung. Die Ansicht Überblick liefert ein Tortendiagramm aller Clients,
aufgeteilt nach den jeweiligen Status der Nutzung.
Die rechte Ansicht Trend stellt für einem bestimmten Zeitraum dar, wieviele Zielsysteme mit dieser bestimmten, aut-geprüften Software arbeiteten. Für den Stand
der aktuellen Nutzung lässt sich nach einem Status filtern*. Via Voreinstellung ist
dies ungenutzt, da dieser Zustand für gewöhnlich am meisten interessiert.
*
Die Filtereinstellungen wirken sich jedoch nicht auf die Graphiken aus!
Abbildung 3–110: bMC/Deploy/Applikationen/Anwendung—Nutzung
Inventory |
133
Abbildung 3–111: bMC/Inventory/Applikationsnutzung
AUT-Globalübersicht. Einen globalen Überblick (Abb.3–110) der Applikationsnutzung
bietet der entsprechende Knoten unter Inventory. Dem Administrator wird hier eine
akkumulierte aut-Ansicht über alle relevanten Anwendungen und deren Nutzung
geboten.
Darin werden sämtliche Applikationen namentlich aufgeführt. Es folgen die in
diesem Zusammenhang wesentlichen Informationen: auf wievielen Clients die
betreffende Software Installiert ist und auf wievielen Clients davon wiederum diese
Software Unbenutzt blieb. Daraus, sowie aus dem Eintrag Anschaffungskosten (EUR)
im Eigenschaftsdialog der Software ermittelt sich ein Einsparungspotential, als ein
Produkt aus den einzelnen Lizenzierungskosten und der Anzahl der Clients, die
die entsprechende Software nicht einsetzen. Unter Überblick wird die Clientanzahl
in Prozent gezeigt, die eine untersuchte Applikation kürzlich nutzten (grün), länger
nicht nutzten (gelb), überhaupt nicht nutzten (rot) respektive keine Daten lieferten
(grau) angezeigt.
Abbildung 3–112: Konfiguration/AUT
Abbildung 3–113: Clienteigenschaften/AUT
AUT-Client-Steuerung
Sobald für eine Software die Applikationsüberwachung aktiviert ist, wird aut auf
allen zu diesem Zeitpunkt im System erfassten Clients durchgeführt. Es verbleiben
also zwei Fragen: Was geschieht bei der Erfassung neuer Clients und was, wenn
bestimmte Clients von der Applikationsüberwachung ausgeschlossen sein sollen?
AUT-Voreinstellung. Um auf allen neuen Clients baramundi aut zu aktivieren, ist es
notwendig die entsprechende Option (Abb.3–112) unter Verwaltung/Inventory—
Eigenschaften—Applikationsüberwachung einzustellen. Damit wird für sämtliche,
neu ins System übernommene, Zielsysteme die Applikationsüberwachung aktiviert.
Bei Anlage neuer Datenbanken kann diese Einstellung ebenfalls gewählt werden.
Einzelne Clients von AUT ausschließen. Mitunter ist es nicht gewünscht auf bestimmten
Clients eine Applikationsüberwachung durchzuführen; seien diese beispielsweise
Außendienst-Laptops, Kundensysteme oder die Rechner der Geschäftsleitung. In
einem solchen Fall kann die Applikationsüberwachung direkt in den Clienteigenschaften im Register AUT über die Option Applikationsüberwachung deaktivieren
ausgeschaltet (Abb.3–113) werden. Um sämtliche vorher erhobenen aut-Daten zu
löschen, dient die Schaltfläche Erfasste Daten zurücksetzen.
Inventory |
135
Der Gedanke hinter baramundi aut ist es, die Kosten für Softwarelizenzen zu
minimieren, indem der Einsatz entsprechender Applikationen auf den Clients
gemessen wird. Die dazu nötige Datenermittlung erfolgt in einer Art und Weise, die
wenige Rückschlüsse auf das Nutzungsverhalten des jeweiligen Anwenders zulässt.
Patch Management
Microsoft stellt monatlich Patches (bei Bedarf natürlich auch häufiger) für seine
Betriebssysteme und Applikationen zur Verfügung, um die Software auf dem neuesten Stand zu halten und Sicherheitslücken zu schließen. Der Betrieb einer sicheren
IT-Umgebung verlangt vom Administrator, mindestens einmal pro Monat diese
Patches auf den Systemen zu installieren.
Oft sind bereits wenige Tage nach Veröffentlichung einer Sicherheitslücke sogenannte Exploits im Umlauf, die diese Schwachstelle nutzen, um an Benutzerdaten zu
gelangen oder Schaden anzurichten. Deshalb erfordert das Erscheinen der sicherheitsrelevanten, von Microsoft als kritisch bewerteten, Patches eine unverzügliche
Reaktion in Ihrem Unternehmen.
Auf Basis der Technologie unserer baramundi Management Suite haben wir ein
einfach zu bedienendes Werkzeug für das Patch Management entwickelt. Sie gewinnen für Ihre Patchpolitik uneingeschränkte Flexibilität, die Übersicht über den
Patchstatus Ihrer Rechner und damit ein deutliches Plus an Sicherheit im gesamten
Netzwerk.
Abbildung 3–114: baramundi Patch Management
Patch Management |
137
Voraussetzungen
Alle Microsoft Sicherheitsupdates, die auf Basis des Microsoft Baseline Security Analyzers (m bsa) ermittelt werden, können über den baramundi Management Server erkannt und verteilt werden. Microsoft informiert dazu in einem
Knowledgebase-Eintrag, welche Produkte mit dem m b s a unterstützt werden*. Um
die Definition der Patches sowie die Patchdateien automatisch herunterladen zu
können, benötigt der baramundi Management Server eine Verbindung ins Internet.
Voraussetzung für das Patch Management auf Clientseite ist, neben dem Betriebssystem, eine aktuelle Version des MS xm l Parsers. Dieser ist im Internet Explorer enthalten. Sollte der Parser fehlen, wird eine entsprechende Fehlermeldung
(MSXML Parser missing) angezeigt. Um alle Sicherheitslücken erfolgreich schließen
zu können, wird außerdem der Microsoft Installer benötigt.
Microsoft stellt zur Zeit an jedem zweiten Dienstag im Monat Patches zur Verfügung.
Die baramundi software AG veröffentlicht diese noch am selben Tag und unterstützt mit dem Patch Management Modul die komplette Microsoft Produktpalette
(Windows, Office, sql Server, Visual Studio usw.) in allen verfügbaren Sprachen.
Als Kunde erhalten Sie Detailinformationen zum jeweiligen Patchday im baramundi
Kundenforum.
Im Folgenden soll kurz auf das grundlegende Vorgehen bei einem Patchupdate
eingegangen werden. Wie erwähnt: Einmal monatlich veröffentlicht Microsoft Patches. Neben den Patchdaten liefert Microsoft auch eine Liste der aktuellen Patches,
die wsusscn2.cab in Form einer Datei. Diese Datei wird von baramundi in eine
x m l-Datei namens BPMdata.xml umgewandelt und dergestalt bearbeitet, dass:
• die Patches auf Funktionalität geprüft,
• defekte Patches gesperrt sowie
• die Patchbeschreibungen angepasst werden.
*
http://technet.microsoft.com/de-de/security/cc184924.aspx
baramundi
Microsoft
tes
Q B
Qw PMd
Q
sus ata.x
scnQml
2.ca
bQ
s
Q
pda & U
s
e
h
c
Pat
+
Firewall
?
'$
-
DIP
&%
SERVER
3
+
CLIENT
CLIENT
k
Q
QQ
]
JJ Q
JJ QQ
QQ
QQ
JJ
QQ
J^
s
Q
Q
J
CLIENT
CLIENT
Abbildung 3–115: Arbeitsweise Patch Management
Der Server lädt von der baramundi Webseite beide Dateien herunter. Anhand der
BPMdata.xml werden dann die Patchinformationen in die Datenbank importiert,
die Patchdaten von Microsoft geholt und auf den dip kopiert. Über die wsusscn2.cab
wird auf den Zielsystemen geprüft, welche Patches fehlen oder aktualisiert werden
müssen.
Im Ergebnis aktualisiert der Client bei einem Patch-Job seine lokale Version der
wsusscn2.cab vom baramundi Management Server. Nach einem Patch-Scan wird am
Client eine xm l-Datei angelegt und an den Server geschickt. Das File-Import-Modul
liest diese Datei pro Client ein und schreibt die entsprechenden Informationen in
die Datenbank. Verteilt werden Patches über Patch-Jobs automatisch oder manuell.
Patch Management |
139
Patchkonfiguration
Zur Verteilung von Patches sind einige Vorbereitungen zu treffen. Im Folgenden
wird der gesamte Ablauf kurz dargestellt.
Downloadjobs
Die notwendigen Downloadjobs sind via Voreinstellung bereits angelegt. Im Einzelnen sind das die Downloads für die Dateien wsusscn2.cab und BPMdata.xml. Sie
finden die Jobs unter Verwaltung/Downloadjobs (Abb.3–116).
wsusscn2.cab
• u r l: www.baramundi.de/download/bms/patchmgmt/wsusscn2.cab
• Lokaler Name: {bpmFolder}\wsusscn2.cab
BPMdata.xml
• u r l: http://www.baramundi.de/download/bms/PatchMgmt/bpmdata3.zip
• Lokaler Name: {BMSPath}\FileImport\bpmdata3.zip*
*
Die Dateien werden komprimiert übertragen.
Abbildung 3–116: Verwaltung/Downloadjobs
Downloadjobs können per Intervall geplant
oder über das Kontextmenü eines Downloadjobs sofort ausgeführt werden. In den
Eigenschaften der Downloadjobs oder über
Downloadjobs planen der htm l-Ansicht des
Knotens Patch Management (Abb.3–114),
können auch Intervalle zur Ausführung der
Downloads festgelegt werden. Die Einstellung erfolgt im Listenfeld Intervall – in Abbildung 3–117 lautet die Angabe 5:00 für
täglich 5.00Uhr.
In der Spalte Status ist zu sehen, ob
der Download erfolgreich war; bei ProbleAbbildung 3–117: Downloadjob
men wird eine Fehlermeldung angezeigt.
Nach dem Download wird die BPMData3.zip automatisch entpackt (BPMData.xml) und durch das File Import Modul in die baramundi Datenbank
eingelesen. Der prozentuale Fortschritt dieses Imports wird unter Verwaltung/Server/Modulzustände/Downloader angezeigt. Im obersten Knoten baramundi
Management Center unter Maintenance werden ebenfalls Detaildaten zu Downloadjobs gegeben.
Die wsusscn2.cab wird zwar von www.baramundi.de heruntergeladen, es handelt
sich dabei allerdings um die Originaldatei von Microsoft. Dies lässt sich auch über
die Dateieigenschaften im Register Digitale Signaturen überprüfen. Wir speichern
diese Datei nur zwischen, da Microsoft die wsusscn2.cab oftmals außerhalb der
ursprünglichen Patchzyklen ändert.
Freigabe- und Downloadmodus
In den Einstellungen der htm l-Seite des Knotens Patch Management, unter PMKonfiguration wird zwischen manueller und automatischer Freigabe unterschieden
(Abb.3–118). Sofern die manuelle Freigabe aktiviert ist, muss jeder Patch oder jedes
Bulletin vom Benutzer manuell freigegeben werden. Automatische Freigabe bedeutet nicht, dass automatisch alle Clients mit fehlenden Hotfixes gepatcht werden,
sondern erst über einem entsprechenden Patchupdate-Job.
Zudem können Sie entscheiden, ob Downloads der Patchdateien sofort Bei Verfügbarkeit oder erst Bei Bedarf erfolgen sollen (Abb.3–119). Im zweiten Fall wird
Patch Management |
141
Abbildung 3–118: Freigabemodus
Abbildung 3–119: Downloadmodus
ein Patch erst heruntergeladen, wenn ein Client diesen bei einem Scan als fehlend
ermittelt und das Ergebnis zum bms übertragen hat. Empfohlen wird der Download
bei Verfügbarkeit. Diese Einstellungen sind in der htm l-Ansicht Patch Management
im Arbeitsbereich unter PM-Konfiguration erreichbar. Weitere, detaillierte Angaben
zum Patch Management hält das Register Patch Verwaltung bereit (Abb.3–120).
Bulletins
Ein Bulletin ist der von Microsoft benutzte Begriff für einen Eintrag in die Patchdatenbank. Von einem Bulletin sind in aller Regel mehrere Produkte betroffen, für
die es unterschiedliche Patches gibt. Nach dem erfolgreichen Einlesen der Datei
BPMData.xml befinden sich im bmc unter Patch Management/Bulletins & Patches
sämtliche verfügbaren Bulletins.
Nach einem Update der Datei BPMData.xml oder einer Änderung eines Bulletins,
müssen Sie über das Menüsymbol oder die Taste F5 auf Knotenebene die Ansicht
aktualisieren. Die htm l-Ansicht Patch Management im Register Patch Verwaltung
gibt Ihnen, nach Jahreszahlen gruppiert, einen Überblick über den Downloadzustand der Patches sowie die Information, wie viele nicht davon freigegeben wurden.
Wenn Sie auf solch eine Jahresgruppierung klicken, springt das Programm in die
Detailansicht (Abb.3–121).
Abbildung 3–120: Patch Verwaltung
Abbildung 3–121: Patchliste
Patch Management |
143
Abbildung 3–122: Patchbeschreibung
Abbildung 3–123: Patchinformation
Hier können Sie entweder eine vereinfachte Bulletinfreigabe konfigurieren, indem Sie komplette Bulletins, deren Kontrollkästchen Sie vorher aktiviert haben,
über den Aufgabenbereich freigeben oder deren Freigabe aufheben. Wenn Sie auf
das Pfeilsymbol (Abb.3–122) klicken, werden detaillierte Informationen zu dem
jeweiligen Bulletin angezeigt. Auch hier besteht die Möglichkeit Patches für die
betroffenen Produkte (bis auf Dateiebene) oder ganze Bulletins freizugeben oder
deren Freigabe wieder aufzuheben. Die Freigabe kann auch auf Ebene der Bulletins
oder der Produkte, Service Packs oder Sprache erfolgen. Sofern der Rechner, auf
dem das Management Center ausgeführt wird, auf das Internet zugreifen kann,
ist durch Auswahl eines Patches oder Bulletins in der m mc-Baumstruktur (Patch
Management/Bulletins&Patches) eine Detailinformationen über das Bulletin vom
entsprechenden Hersteller (Abb.3–123) erhältlich.
Auch die Listenansicht bietet erweiterte Möglichkeiten: Über das Kontextmenü
Patches können entsprechende Produkte (bis auf Dateiebene) oder ganze Bulletins
freigegeben oder gesperrt werden. Die Freigabe kann auch auf Ebene der Bulletins,
der Produkte, Service Packs oder Sprache erfolgen.
Patches verteilen
Patchjobs werden – wie gewohnt – in der Jobverwaltung angelegt. Dazu ist der
Jobschritt Systeme mit Patches aktualisieren (Abb.3–125) zu wählen.
i
Es empfiehlt sich, jeweils einen Job zum Scannen und einen weiteren zum
Installieren der benötigten Patches anzulegen. Dadurch erhalten Sie eine
Zustandsmeldung der Clients, ohne den entsprechenden Nutzer zu stören.
Abbildung 3–124: Jobname
Abbildung 3–125: Patchjobschritt
Patch Management |
145
Abbildung 3–126: Nur Scannen
Abbildung 3–127: Scannen und Verteilen
Achten Sie im nächsten Dialog darauf, dass als Aktion nur Scannen (Abb.3–126)
selektiert ist. Im Dropdown-Menü Scankontext können Sie Konfigurierter Installationsbenutzer oder Local System selektieren. Wählen Sie hier bitte Konfigurierter
Installationsbenutzer aus, welcher dann auf den Installationsbenutzer in der Domänenkonfiguration zurückgreift. Abschließend wird der konfigurierte Patch-Scan-Job
in einer Textmeldung zusammengefasst.
Abbildung 3–128: Bulletin Filter
Ein zweiter Job dient dann dazu, die Patches auf dem Zielsystem zu installieren.
Dazu wird auf dem Zielsystem zunächst ein Patch-Scan durchgeführt, die fehlenden
Patches an den baramundi Management Server übermittelt, die freigegeben Patches
laut Ihrer Konfiguration installiert, ein abschließender Reboot durchgeführt und
zuletzt ein erneuter Patch-Scan gestartet.
Bei den Optionen dieses Patch-Jobs wählen Sie Scannen und Verteilen (Abb.3–127).
Der Bulletin Filter gibt Ihnen zudem die Möglichkeit, einen Patch-Job auf bestimmte Bulletins zu beschränken. Beachten Sie in diesem Zusammenhang bitte, dass
hier auch Bulletins, die nicht freigegeben sind angezeigt werden. Das heißt, eine
bestimmte Selektion eines nicht freigegebenen Bulletins hat keinerlei Auswirkung
auf einen Patch-Update-Job. Sie können Ihre Auswahl lediglich auf Bulletins einschränken, die freigegeben sind und dadurch den Rest deaktivieren, um Sonderfälle
abzudecken (Abb.3–128). Wenn Sie einen Patch-Scan-Job oder einen Patch-UpdateJob wie oben beschrieben erstellt haben, können Sie diesem Clients zuweisen.
Ein Beispiel
Es soll nun beispielhaft ein Patchupdate mit anschließender Patchinstallation
gezeigt werden.
Update der Patchdaten
Die Downloadjobs für die wsusscn2.cab sowie BPMData3.zip sind bereits unter
Verwaltung/Downloadjobs vorinstalliert. Auch ein entsprechendes Intervall zum
Patchupdate ist Teil dieser Einstellungen. Insofern benötigen diese Parameter keine
weitere Administration, es sei denn die Intervalle sollen geändert werden. Für das
Beispiel soll dieses Dateiupdate manuell erfolgen:
1. Wählen Sie in der Patch Management h tm l-Ansicht Downloadjobs planen.
2. Im Kontextmenü der PatchMgmt BPMData3.zip wählen Sie Jetzt ausführen.
3. Im Kontextmenü der PatchMgmt wsusscn2.cab wählen Sie Jetzt ausführen.
Sie können die Ausführung der Downloadjobs unter Verwaltung/Server/Modulzustände
beobachten. Der Downloader wird – je nach den eingestellten Intervallen – den
Download anzeigen; der FileConnector signalisiert das Einlesen der BPMData.xml
in die Datenbank.
Patch Management |
147
Patchfreigabe
In der Liste der relevanten Patches sind nun die gewünschten Patches freizugeben.
1.
2.
3.
4.
Wählen Sie im Patch Management das Register Patch Verwaltung
Hier sind zunächst der das entsprechende Jahr sowie
die jeweiligen Patches auszuwählen.
Auswahl und Freigabe erfolgen über das Auswahl-Menü im Aufgabenbereich.
Abbildung 3–129: Patchfreigabe
Der Freigabezustand ist in der gleichnamigen Spalte der Tabelle im Register Patch
Verwaltung ablesbar. Über Freigabe aufheben im Aufgabenbereich können einmal
erteilte Freigaben auch wieder entzogen werden.
i
Auch bei verweigerter Freigabe wird der Patch dennoch heruntergeladen –
nur eben nicht installiert!
Patchdownload (Microsoft)
Sind sämtliche Voreinstellungen getroffen, können die Patches heruntergeladen
werden. Dazu stellt Patch ManagementModul verschiedene Modus zur Verfügung.
1. Wählen Sie im Arbeitsbereich des
Patchmanagements unter Quicklinks
den Eintrag PM Konfiguration.
Unter Downloadmodus stehen drei Alternativen zur Auswahl: Bei Verfügbarkeit lädt den
Patch herunter, sowie dieser von Microsoft
veröffentlicht wurde. Dabei ist es unerheblich, ob der entsprechende Patch tatsächlich
Abbildung 3–130: Downloadjob
benötigt wird oder nicht. Bei Bedarf wird
der Patch nur dann heruntergeladen, wenn nach Ermittlung des Patchstatus (PatchScan-Job) eines Clients der Patch auch fehlt oder aktualisiert werden muss. Bei
Wahl von Kein Download wird der so gekennzeichnete Patch nicht heruntergeladen.
In diesam Fall müssen die Patches manuell auf den dip kopiert werden.
2. Treffen Sie Ihre Wahl bezüglich der Downloadzustände.
3. Wählen Sie unter Freigabemodus den Eintrag Manuell.
Patchinstallation
Schließlich sind die benötigten Patches auf den entsprechenden Zielsystemen zu
installieren. Dies geschieht wie gewohnt über Jobs:
1.
2.
3.
4.
5.
6.
Erstellen Sie einen neuen Job Jobverwaltung/Neu—Job.
Benennen Sie den Job und wählen Sie Systeme mit Patches aktualisieren.
Wählen Sie unter Aktionen den Eintrag Scannen und Verteilen.
Mit dem Bulletin Filter wählen Sie über Bearbeiten die gewünschten Bulletins.
Schließen Sie den Job ab.
Weisen Sie den Job den entsprechenden Clients zu.
Patch Management |
149
Recovery
Das Recovery-Modul ist eine Lösung, mit der Sie praktisch jede Arbeitsplatzumgebung an jedem Ort sichern und wiederherstellen können. Ob unbeabsichtigte
Bedienfehler von Anwendern oder Systemfehlfunktionen, Sie sparen wertvolle Zeit
für aufwendige Fehlersuchen. Recovery besteht derzeit aus den beiden Komponenten Disaster Recovery und Personal Backup.
Disaster Recovery
Disaster Recovery dient der Wiederherstellung einer PC-Festplatte nach einem
Rechner-Notfall (z.B.bei einem zerstörten Dateisystem oder einer defekten Festplatte). Das baramundi Recovery Modul ermöglicht es, ein exaktes Abbild ausgewählter
Laufwerke zu erstellen. Die Systemsicherung erfolgt auf Basis belegter Sektoren.
Der Ablauf kann im Hintergrund erfolgen, während der Anwender am Arbeitsplatz
seiner gewohnten Tätigkeit nachgeht.
Die gesicherten Daten können wahlweise komprimiert in einem Netzwerk oder
lokal auf dem Arbeitsplatzrechner abgelegt werden. Eine Neuinstallation erfolgt von
zentraler Stelle aus, mit allen Systemeinstellungen und benötigten Anwendungen.
Arbeitsweise
Die Sicherung von Laufwerken mit Disaster Recovery vollzieht sich wie folgt:
'$
(1)
Job
bMS
(3)
bdi
-
-
bMA
DIP
&%
6
(2)
'$
HDD
&%
Abbildung 3–131: Recovery: Datensicherung
Der Server (bms) weist den Client (bma) an (1) die Daten einer Festplatte aus zu
lesen (2) und auf dem dip in Form einer Datei abzulegen (3).
Die Sicherung erfolgt als Job-Schritt durch den bms/bma. Der Job-Schritt sichert
ein Volume (das heißt eine Partition). Mehrere Volumes können durch Aneinanderreihung von mehrere Jobschritten (in verschiedene Dateien) gesichert werden. Die
Wiederherstellung der Daten verläuft analog entgegengesetzt:
'$
(1)
PXE
bMS
(2)
-
DIP
bdi
Bootclient
&%
(3)
? $
'
HDD
&%
Abbildung 3–132: Recovery: Datenwiederherstellung
Da bei einem Wiederherstellungsfall ein Betriebssystem in aller Regel nicht zur
Verfügung steht, wird der Client über pxe vom Server aus gestartet (1). Über einen
Job holt sich dieser vom dip (2) die Datensicherungsdatei und spielt sie auf das
Zielsystem zurück (3).
Voraussetzungen und Einschränkungen
Die Wiederherstellung erfolgt immer unter einem dos-Bootclient (auch wenn es
sich nicht um eine Systempartition handelt). Daher gilt es einige Punkte zu beachten:
• Lokal auf dem Client gespeicherte Images müssen einen dos-konformen,
sogenannten 8+3* Dateinamen aufweisen.
• Bei lokal auf dem Client gespeicherten Images funktionieren nicht alle Variablenersetzungen (insbesondere {LatestDate}).
• Laufwerksbuchstaben werden unter dos anders vergeben als unter Windows.
• Unter dos kann nur auf fat16 formatierte Laufwerke (und natürlich NetzwerkLaufwerke) zugegriffen werden. Wird das Image auf einem Netzwerk-Laufwerk
gespeichert, sorgt der Server für die 8+3-Umsetzung des u nc-Dateinamens
und erledigt die entsprechenden Variablenersetzungen.
*
8 Zeichen für den Dateinamen, 3 Zeichen für die Dateierweiterung
Recovery |
151
• Unterstützt werden alle 32-Bit Windows-Betriebssysteme von Windows2000
bis Windows7.
• Die Partition, auf der die Wiederherstellung erfolgt, muss mindestens genauso groß sein wie die Partition, von der die Sicherung stammt. Ist die
Zielpartition größer, wird das Dateisystem nicht expandiert – es steht nach
wie vor der gleiche Platz wie zum Zeitpunkt der Sicherung zur Verfügung
(und nicht mehr).
• Es werden nur Festplatten mit einer Sektorgröße von 512Bytes unterstützt.
Sicherung von Datenträgern
Erstellen Sie einen Job und wählen Sie den Jobschritt Image eines Laufwerks erstellen
(Abb.3–133). Zunächst ist das zu sichernde Laufwerk (Abb.3–134) anzugeben.
Sofern Sie die Priorität auf Niedrig belassen, kann die Sicherung während des
Betriebs durchgeführt werden.
Der Pfad wird nach dem Schema {DIP}\Backup\{Client}\{Client}.bdi gebildet. Darüber hinaus steht die Variable {Date} zur Verfügung. Wichtig ist, dass der Speicherort aus Clientsicht erreichbar und der Servername auflösbar ist. Ebenfalls möglich:
Die Verwendung eines lokalen Laufwerks, sofern eine zweite Partition oder eine
zweite Festplatte auf dem Zielsystem vorhanden ist.
Da dos keine größeren Partitionen als 2GByte erlaubt, kann die Größe der Imageteile nicht höher gesetzt werden. Größere Datenträger werden bei Bedarf in mehreren
Teilen gesichert.
Abbildung 3–133: Jobschritt
Abbildung 3–134: Einstellungen
Abbildung 3–135: Jobschritt
Abbildung 3–136: Einstellungen
Wiederherstellen von Datenträgern
Erstellen Sie einen Job und wählen Sie den Jobschritt Laufwerk aus Image wiederherstellen. Geben Sie aus Clientsicht den Pfad an (Abb.3–135), unter dem das Image
abgelegt ist. Beim Sichern wird die Information über die gesicherte Partition in
der Kopie mit abgelegt. Ist eine andere Partition gewünscht, so kann diese angegeben werden. Dabei werden Festplatten von Null aufwärts hochgezählt, Partitionen
beginnen bei Eins.
Partitionierung durchführen veranlasst eine Partitionierung entsprechend dem Hardwareprofil, das dem Client zugewiesen ist. Eine Partitionierung ist für eine
Systemwiederherstellung normalerweise nur dann erforderlich, wenn der
betroffene Datenträger ausgetauscht wurde. Die Partitionierung erfolgt mit
dem für den Rechner aktiven Hardwareprofil und – daher ist zur Vorsicht
zu raten – löscht unter Umständen alle auf dem Datenträger gespeicherten
Informationen.
Partition aktivieren Diese Option setzt nach einer Wiederherstellung die Partition
aktiv.
Master Boot Record (MBR) schreiben. Der Master Boot Record kann mit einem
Standard Master Boot Record überschrieben werden.
Signatur wiederherstellen. Die Signatur des Betriebssystems wird entsprechend den
Daten wiederhergestellt. Das ist nach der Partitionierung ab Windows Vista
erforderlich.
Recovery |
153
Im nächsten Dialog Image booten, stehen folgende Einstellungen zur Auswahl:
Netzwerkboot aktivieren. Durch die Option Netzwerkboot aktivieren wird in den
Eigenschaften eines zugewiesenen Zielsystems die Option PXE Booten automatisch aktiviert.
Umgebung. Zur Verfügung stehen hier die unter Verwaltung—Bootumgebungen
konfigurierten, dos-basierten Bootumgebungen.
Systemneustart vom Server aus initiieren. Ist das Zielsystem bereits in Betrieb, so
wird ein Systemneustart vom Server aus veranlasst.
Im Ergebnis einer Laufwerkssicherung und -wiederherstellung werden die Daten
einer Festplatte in einer – oder in aller Regel mehrere – bdi-Dateien (baramundi
dish image) gespeichert und zurückgespielt. Diese bdi-Dateien befinden sich nach
Sicherung/zur Wiederherstellung in dem in den Dialogen angegebenen Verzeichnissen, für gewöhnlich auf dem dip. Bei mehreren Sicherungen sorgt die Variable
{LatestDate} für die Wiederherstellung der aktuellen Version.
Personal Backup
Personal Backup funktioniert im Wesentlichen wie Recovery, mit einem Unterschied:
Über Personal Backup werden Dateien und keine Laufwerke gesichert.
Arbeitsweise
Während über Recovery ein System mit sämtlichen Daten gesichert und wiederhergestellt wird, beschränkt sich Personal Backup auf benutzerspezifische Daten:
'$
(1)
Job
bMS
(3)
zip
-
-
bMA
DIP
&%
6
(2)
'$
Dateien
Registry
etc.
&%
Abbildung 3–137: Personal Backup: Datensicherung
Der Server (bms) weist den Client (bma) an (1) die Daten eines Verzeichnisses
auszulesen (2) und auf dem dip komprimiert abzulegen (3). Die Sicherung erfolgt
als Job-Schritt durch den bms/bma. Die Wiederherstellung der Daten verläuft analog
entgegengesetzt:
'$
(1)
Job
bMS
(2)
-
DIP
zip
bMA
&%
(3)
? $
'
Dateien
Registry
etc.
&%
Abbildung 3–138: Recovery: Datenwiederherstellung
Über einen Job holt sich weist der Server den Client an (1) die Daten wiederherzustellen (2) und holt sich dazu die Datensicherungsdatei vom dip (3).
Voraussetzungen und Einschränkungen
Die Hauptaufgabe von baramundi Personal Backup besteht darin, gesicherte Einstellungen für einen ganz bestimmten Benutzer wiederherzustellen, entweder auf
der identischen Applikationsinstallation oder einer ähnlichen Neuinstallation derselben Applikationsversion.
• Eine Migration zu einer neueren Applikationsversion ist in aller Regel nicht
möglich ist – das hängt allerdings von der zu sichernden Anwendung ab.
Sofern Sie diesbzüglich nicht sicher sind, erkundigen Sie sich beim Hersteller.
• Eine Migration zwischen verschiedenen Benutzern ist mit Personal Backup
nicht möglich.
• Personal Backup dient dazu, eine definierte Menge von Dateien und/oder
Registrierungseinträgen zu sichern und wiederherzustellen. Die Menge der
zu sichernden Datenmenge ist also überschaubar. Personal Backup ist nicht
zur Sicherung größerer Datenmengen gedacht. Übersteigt die Datenmenge
unkomprimiert 2GByte, kann es beim Rückspielen der gesicherten Daten zu
Problemen kommen.
Recovery |
155
Abbildung 3–139: Sicherungsvorlagen
Sicherungsvorlagen
Das Sichern benutzerbezogener Einstellungen und Daten basiert auf Vorlagen, in denen festgelegt ist, was im Einzelnen zu sichern ist. Aufgrund der unterschiedlichen
Möglichkeiten und Anforderungen verschiedener Applikationen empfiehlt es sich,
unterschiedliche Sicherungsvorlagen zu erstellen und zu verwenden. Zum Lieferumfang gehört bereits eine Auswahl vordefinierter Sicherungsvorlagen. Diese sind
unter dem Knoten Recovery/Personal Backup Sicherungsvorlagen abgelegt. Neue
Sicherungsvorlagen können jederzeit selbst erstellt und dem System hinzugefügt
werden (Abb.3–139).
Zum Erstellen einer neuen Sicherungsvorlage wählen Sie im Kontextmenü des
Knotens Personal Backup Sicherungsvorlagen den Punkt Neu—Sicherungsvorlage.
Vergeben Sie im Register Allgemein einen passenden Namen für die neue Vorlage
und fügen Sie im Feld Kommentar eine Beschreibung hinzu.
Die anderen Register Dateien und Registrierung enthalten eine Liste von Dateimustern sowie von Registrierungsschlüsseln und -werten. Bei der Angabe von Dateien
können ? und * als Platzhalter sowohl in Verzeichnissen als auch in Dateinamen verwendet werden. Umgebungsvariablen sind im Format %<Variablenname>%, also zum
Beispiel %ProgramFiles%\bsAG\* zu verwenden. Diese werden bis auf die Variablen
%AppData% und %UserProfile% für den bma-Benutzer aufgelöst* . Das heißt %Temp%
wird nach C:\Windows\temp und nicht nach C:\dokume~1\user~1\lokale~1\Temp
aufgelöst. Bei der Sicherung werden allgemeine Daten und benutzerspezifische Da*
Da dieser i.a.R.als Systemdienst läuft ist das SYSTEM.
Abbildung 3–140: Sicherungsvorlage
Abbildung 3–141: Sicherungsvorlage
ten unterschieden. Benutzerspezifisch ist alles, was %AppData% oder %UserProfile%
(literal, nicht aufgelöst) enthält.
Über die Option Unterverzeichnisse einbeziehen ist es möglich, Muster rekursiv
anzuwenden. Sie können Muster angegeben, die in die Sicherung eingeschlossen
und solche, die ausgeschlossen werden. Es wird dabei zunächst eine Liste der
Dateien gebildet, die durch die Einschlusskriterien entstehen, danach werden aus
dieser Liste die Dateien, die das Ausschlusskriterium erfüllen, wieder entfernt.
Die Schaltflächen Einschliessen/Ausschliessen fügen das eingetragene Dateimuster
der Liste hinzu – Einschließen: Das Dateimuster soll gesichert werden; Ausschließen: Das Dateimuster soll nicht gesichert werden. Ein grüner Haken neben einem
Listeneintrag symbolisiert, dass die Dateien dieses Dateimusters in die Sicherung
einbezogen, ein rotes Kreuz symbolisiert, dass die Dateien des Dateimusters von
der Sicherung ausgenommen sind.
Sollen Registrierungspfade gesichert werden, so kann die Auswahl – ebenso wie
bei den Dateien – über die Schaltfläche mit den Auslassungspunkten erfolgen. Ein
Klick auf Einschliessen fügt den Pfad der Liste hinzu.
In einem Sicherungsjob werden eine oder mehrere Sicherungsvorlagen und ein
Pfad für die Sicherung ausgewählt. Bei einem Wiederherstellungsjob wird der
Sicherungssatz angegeben, aus dem wiederhergestellt werden soll. Es ist auch
möglich festzulegen, ob alle Daten in der aktuellen Version wiederhergestellt werden
Recovery |
157
Abbildung 3–142: Datensicherung
Abbildung 3–143: Datensicherung (2)
sollen oder ob eine gezielte Auswahl erfolgen soll. Bei einer gezielten Auswahl muss
ein konkreter Sicherungssatz (für einen konkreten Rechner und einen konkreten
Benutzer) ausgewählt sein. Aus dessen Inhalt lassen sich dann die Daten auswählen.
Daten sichern
Um persönliche Daten zu sichern, erstellen einen Job mit passendem Namen.
Wählen Sie den Jobschritt Datensicherung aus (Abb.3–142). Geben Sie einen Ort für
die Sicherung an, der vom Client erreicht wird. Eine hohe Priorität beeinträchtigt
dabei möglicherweise das System so stark, dass ein angemeldeter Benutzer nicht
mehr weiterarbeiten kann. Die Voreinstellung sollten daher beibehalten werden.
Legen Sie fest, ob nur eine Inkrementelle Sicherung (Abb.3–143) durchgeführt (nur
Veränderungen gegenüber der vorhergehenden Sicherung, erkennbar am gesetzten
Archivbit, werden gesichert) und ob bei der Sicherung das Archivbit zurückgesetzt
werden soll.
Wählen Sie aus der Liste alle Sicherungsvorlagen aus, die verwendet werden sollen.
Sicherungen zurückspielen
Erstellen und benennen Sie einen neuen Job. Wählen Sie den Jobschritt Daten aus
Sicherung wiederherstellen (Abb.3–144). Wählen Sie Pfad und Name der anzulegenden Imagedatei. Dieser Pfad muss aus Sicht des Clients verfügbar sein.
Wählen Sie ein Zielverzeichnis, für die zurückzuspielenden Daten. Möchten Sie
die Daten an deren ursprünglichen Speicherort zurückspielen, belassen Sie diesen
Eintrag (Wiederherstellen in Verzeichnis) bitte leer.
Abbildung 3–144: Datenwiederherstellung
Abbildung 3–145: Datenwiederherstellung
Sind am Zielort bereits Dateien vorhanden, so ist eine entsprechende Verfahrensweise wählbar (ältere, immer, nicht überschreiben). Vorhandene Reg.-Schlüssel können
mit gesicherten Werten zusammengeführt oder komplett oder nicht überschrieben
werden.
Der untere Bereich des Dialogs bietet drei Optionen: Alle gesicherten Daten in
ihrer jeweils neuesten Version für alle Benutzer wiederherstellen sorgt genau dafür.
Wiederherzustellende Daten manuell auswählen: Bei Wahl dieser Option wird der
Sicherungssatz ausgewählt und eingelesen. Eine Liste aller Werte bietet daraufhin
die Auswahl, welche Einträge berücksichtigt werden sollen. Katalogdateien-Dateien
neu erstellen: Hierüber können Katalogdateien neu erstellt werden.
Ein Beispiel
Im Folgenden soll anhand eines kleinen, privateren Beispiels die Funktionsweise
von baramundi Personal Backup verdeutlicht werden. Nehmen wir dazu an, auf
Ihrer Festplatte befänden sich zwei rare Versionen von «Love me tender», die der
King Ihrer Mutter damals in Bad Nauheim persönlich auf ein Tonband hauchte –
unbezahlbar, und daher der Sicherung wert!
Die nunmehr digitalisierten Aufnahmen lovemetender1.mp3 und lovemetender2.mp3
befinden sich im Verzeichnis Elvis und sollen vorsichtshalber gesichert werden (die
Originalbänder verschlang vor zwei Jahren Ihr Labrador).
Nun sollen die Raritäten zunächst gesichert und anschließend wiederhergestellt
werden. Der Einfachheit halber auf der selben Platte, was betrieblichen Ansprüchen
der Datensicherung freilich nicht genügt.
Recovery |
159
Vorbereitungen. Erstellen Sie drei Verzeichnisse, für die Musik (in dieses Verzeichnis
werden die beiden Dateien gelegt, zu Sicherung sowie eines zur Wiederherstellung
der Daten.
Sicherungsvorlage erstellen. Zunächst muss eine entsprechende Sicherungsvorlage angelegt werden, da ja lediglich ein einzelnes Verzeichnis gesichert werden soll:
1. Wählen Sie im Kontextmenü von des Knotens Recovery/Personal Backup
Sicherungsvorlagen Neu—Sicherungsvorlage.
2. Benennen Sie Ihre Vorlage im Register Allgemein.
3. Im Register Dateien wählen Sie den Pfad zum Musik-Ordner.
4. Drücken Sie auf Einschliessen, um die Titel zu laden
5. und beenden Sie den Dialog.
Damit steht Ihnen die neue Vorlage unten Recovery/Personal Backup Sicherungsvorlagen zur Verfügung.
Datensicherung. Nun soll eine komprimierte Sicherungsdatei erstellt werden:
1. Erstellen Sie einen Job mit dem Jobschritt Datensicherung.
2. Unter Sicherungssatz wählen Sie den Pfad zum Verzeichnis Sicherung.
3. Im unteren Dialogbereich wählen Sie Ihre Vorlage und stellen Sie den Job
fertig.
4. Weisen Sie den Job dem entsprechendem Zielsystem zu.
Im Ergebnis befinden sich nunmehr in Ihren Verzeichnis Sicherung eine xml- sowie
eine zip-Datei mit den Sicherungsdaten.
Proben wir den Ernstfall: Löschen Sie nun den Musikordner!
Datenwiederherstellung. Aus der eben erstellten Sicherungsdatei sollen nun die eben
gelöschten Daten wiederhergestellt werden:
1. Erstellen Sie einen Job mit Jobschritt Daten aus Sicherung wiederherstellen.
2. Unter Sicherungssatz wählen Sie den Pfad zum Verzeichnis Sicherung.
3. Unter Wiederherstellen in Verzeichnis wählen Sie den Pfad zum Verzeichnis
Wiederherstellung.
4. Stellen Sie den Job fertig und weisen Sie den Job dem entsprechendem Zielsystem zu.
Nachdem der Job erfolgreich beendet ist, stehen Ihnen die kostbaren Daten im
Verzeichnis Wiederherstellung wieder zur Verfügung. Na dann, love us tender . . .
Recovery |
161
In diesem Kapitel:
• Serververwaltung — 164
• Allgemeine Verwaltung — 174
4
Verwaltung der Suite
Dieses Kapitel widmet sich der Verwaltung der baramundi Management Suite und
folgt im Wesentlichen den Inhalten des Knotens Verwaltung im Management Center.
Ja nach der Gebräuchlichkeit der in den Dialogen zu treffenden Einstellungen,
werden diese mehr oder weniger beschrieben.
Es werden zunächst die Servereinstellungen erläutert. Wichtige Einstellungen in
den darunter liegenden Knoten, werden im Anschluss betrachtet.
Abbildung 4–1: Server/Konfiguration/Grundeinstellungen
Serververwaltung
Unter dem Knoten Server befinden sich sämtliche Einstellungen, die entweder für
den Betrieb des baramundi Management Servers selbst von Bedeutung sind oder in
direkter Beziehung zur Infrastruktur stehen.
Grundeinstellungen
Allgemein. (Abb.4–2) Zunächst seien die grundsätzlichen Einstellungen kurz vorgestellt und erläutert. Diese lassen sich im Dialog Grundeinstellungen treffen.
• Rolle: Der erste installierte Server wird als Master konfiguriert, die weiteren
als p xe Relay.
• Binärpfad: Geben Sie hier den vollständigen Pfad zu den Programmdateien
des baramundi Servers an bzw.die Serverfreigabe dafür.
• Shutdown Timeout: Beim Beenden der bms fährt dieser jedes Modul herunter.
Dazu erhält die hier vorgegebene Shutdown-Zeit, um sich zu beenden. Wird
diese Zeit überschritten, so beendet der baramundi Server das Modul aktiv,
ohne dem Modul weitere Ausführungszeit zu gestatten.
Abbildung 4–2: Allgemein
164 | Kapitel4: Verwaltung der Suite
Abbildung 4–3: Clientidentifizierung
• Primärer DIP: An verschiedenen Stellen können Sie nach einem Verzeichnis
oder einer Datei suchen lassen (Schaltfläche mit Auslassungszeichen). Wenn
dabei in der Pfadangabe die Variable {DIP} vorkommt, wird diese vor dem
Durchsuchen durch den hier angegebenen Wert ersetzt und im Anschluss
wieder umgekehrt.
• Domänenmodell: Windows 2000 oder höher (Active Directory) oder NT 4.0
lan Manager.
• Datenbankverbindungen: Anzahl der zulässigen Datenbankverbindungen.
Die Freigabe und Verzeichnisberechtigung für das bMS$-Share sollte über Leseberechtigung für Jedermann verfügen.
Client-Identifizierung. (Abb.4–3) Die bms erlaubt eine flexible Identifizierung von
Clients. Zu diesem Zweck können verschiedene Kriterien herangezogen werden:
Die Standardidentifizierung ist Hostname-MAC, die weiteren Möglichkeiten sind
Spezialfällen vorbehalten.
•
•
•
•
•
Hostname: Hostname der Clients
mac: mac-Adresse der Clients
LAA: Logische mac-Adresse der Clients
IP: IP-Adresse der Clients
FQDN: fully qualified domain name
Sie haben zudem die Möglichkeit, mac- oder IP-Adressen zu ignorieren. Dies kann
erforderlich sein, wenn Clients falsch identifiziert werden, beispielsweise beim
Vorhandensein virtueller Maschinen oder v pn-Schnittstellen. Diese Schnittstellen
verfügen meist über IP- respektive mac-Adressen aus dem gleichen Kreis. Hier
können Änderungen oder doppelte Einträge stören. Daher sollten solche Bereiche
bei der Client-Identifizierung ignoriert werden. Die Verwendung von Sternchen *
als Wildcard ist dabei möglich; zum Beispiel: 192.168.* um sämtliche IP-Adressen
von 192.168.0.1 bis 192.168.255.254 zu ignorieren.
Kommunikation. (Abb.4–4) Im diesem Register definieren Sie den Kommunikationspfad für den BootClient, tcp/IP-Port-Adressen sowie die Timeouts für die
BootClient-Verbindung und die Management Agent-Verbindung.
Serververwaltung |
165
Abbildung 4–4: Kommunikation
Abbildung 4–5: Management Agent
Management Agent. (Abb.4–5) Hier legen Sie den Quellpfad für die Installation des
baramundi Management Agents fest, seiner Dateien sowie deren Menüeinstellungen
auf einem Netzwerkclient.
Konfiguration
Neben den Grundeinstellungen können über dan Knoten Verwaltung/Server noch
diverse andere Einstellungen getroffen oder geändert werden.
Lizenzen
Unter Lizenzen (Abb.4–6) sind die Lizenzen für die baramundi Management Suite
einzutragen. Soll eine bereits eingetragene Lizenz ersetzt werden, zum Beispiel weil
sie abgelaufen ist oder es sich um eine Demolizenz handelte. Zur Ersetzung von
Lizenzen verfahren Sie wie folgt:
1.
2.
3.
4.
Markieren Sie die zu entfernende Lizenz, wählen Sie Entfernen.
Bestätigen Sie die Sicherheitsabfrage.
Schließen Sie das Lizenzfenster mit Ok.
Öffnen Sie das Lizenzfenster erneut und tragen Sie Ihre Lizenznummer ein.
Abbildung 4–6: Lizenzen
Abbildung 4–7: Jobausführung
Achten Sie dabei unbedingt auf korrekte Schreibweise und entfernen Sie überflüssige
Leerzeichen am Ende. Sofern Sie Lizenzen nachordern möchten: Zur Erstellung
weiterer Lizenzschlüssel benötigt die baramundi software AG folgende Daten: (a)
das Unternehmen, auf das die Lizenzierung eingetragen ist sowie (b) der Name des
Rechners, auf dem der baramundi Server installiert ist.
Im Register Globale Variablen sind der Name des Unternehmens und die Aktivierungscodes zur Freischaltung der von Ihnen erworbenen Lizenzen der baramundi
Management Suite einzutragen. Achten Sie dabei unbedingt auf die Schreibweise,
die Sie in Ihrer Lizenzbestätigung vorfinden. Zudem muss dem Hinweis auf das
Beenden der entsprechenden Dienste Folge geleistet werden.
Jobausführung
Im Register Allgemein (Abb.4–7) des Knotens Jobausführung gilt es, die grundlegenden Parameter zur Ausführung der Jobs festzulegen.
Webserver
Für die Integration des baramundi Kiosks wurde in den baramundi Server ein
Webserver (Abb.4–8) modular integriert. Dadurch ist es zum Beispiel möglich,
Anwenderrichtlinien oder administrative Kontakte dem Benutzer an einer zentra-
Serververwaltung |
167
Abbildung 4–8: Webserver
Abbildung 4–9: PXE-Unterstützung
len Stelle zur Verfügung zu stellen. Legen Sie fest, welche Dienste der Webserver
bereithalten soll. Voraussetzung zur Nutzung des baramundi Kiosks ist ein Webbrowser. Die Adresse des Software Kiosks lautet: http://<baramundi Management
Server>:<Port> Beispiel: http://barasrv:10080.
PXE-Unterstützung
pxe (preboot execution environment) ist ein Verfahren* , das es einem Rechner ermöglicht, vom Netzwerk aus zu booten. Die pxe-Erweiterung (Abb.4–9) zu d hc p
erlaubt die Installation von Betriebssystemen von einem Remote-Server auf eine
lokale Festplatte eines Netzwerk-Clients. Die pxe-Technologie nutzt hierfür das
tcp/IP- und tf tp-Protokoll, sowie den d hcp-Dienst, um Informationen an Systeme
zu senden, die über das Netzwerk bootfähig sind. Für die pxe-Unterstützung der
baramundi Management Suite gelten die folgenden Einstellungen.
• PXE Server aktiv: Markieren Sie dieses Kontrollkästchen, wenn der baramundi
Server eingehende p xe-Anforderungen bearbeiten soll.
* Für technisch detailliertere Informationen zu PXE verweisen wir
auf das Dokument «Preboot Execution Environment (PXE) Spezifikation», Version 2.1 der Intel Corporation vom 20.September 1999
(www.pix.net/software/pxeboot/archive/pxespec.pdf).
• Modus: Eigenständig (Port 67 und 4011): Das pxe-Modul des baramundi Management Servers deckt alle relevanten p xe-Aufgaben ab. Gemischt (nur Port
4011): Das pxe-Modul des baramundi Management Servers wird gemeinsam mit einem d h cp-Server betrieben, bei dem die erweiterte pxe-Option 67
(p xe-Client) definiert ist.
• Bootstrap Loader: Wenn Sie <internal> wählen, wird der Bootstrap Loader
der Netzwerkkarte verwendet. Alternativ, kann die in dem t f tp-Verzeichnis
zur Verfügung stehende Datei BSTRAP.0 verwendet werden.
• Bootpromptanzeige (in Sekunden): Bei Initiierung des Network Based Booting
Process kann über die Funktionstaste F8 an dem anfordernden System ein
Bootmenü angezeigt werden. Wird die Taste nicht gedrückt, startet nach der
hier vorzunehmenden Zeitvorgabe die Standardauswahl.
• Server Discovery legt die Art der Ermittlung der Adresse desp xe-Servers fest.
• Unbekannte Clients: Es wird die Behandlung von Requests festgelegt, deren
mac-Adressen nicht im baramundi Repository verwaltet werden.
• Interfaces ignorieren: Eine durch Semikola getrennte Liste von IP-Adressen
des lokalen Servers, an die keinerlei pxe-Anfragen beantwortet werden sollen.
Standardmäßig reagiert der Server auf allen Schnittstellen.
• Bootcounting aktivieren: Wenn diese Option aktiviert ist, so wird bei jedem
p xe-Boot eines Zielsystems der Bootzähler des Zielsystems um 1 hochgezählt.
• TFTP Server aktiv: Markieren Sie dieses Kontrollkästchen, wenn der baramundi Server eingehende t f tp-Anforderungen bearbeiten soll.
• TFTP Verzeichnis: Vollständiger Pfadname des Verzeichnisses, auf dem die
Dateien zum Download bereitgestellt werden.
PXE blacklisting. Nun wäre es jedoch kaum praktikabel, jeden sich im Netz befindlichen Client über den ersten erkannten pxe-Server booten zu lassen – schließlich ist
es durchaus möglich, dass dies gar nicht beabsichtigt ist: Sei es aufgrund des Betriebs mehrerer pxe-Server (für verschiedene Systeme), sei es aus Sicherheitsgründen
oder schlicht um den Client vor nicht beabsichtigten Datenzugriffen (Installation von Betriebssystemen) zu schützen. Um nun solchen ungewollten Aktionen
wirksam vorzubeugen, kann mittels bms p xe-Blacklisting das Booten bestimmter
Rechner über ein Netzwerk – also das Booten vom baramundi Server über pxe –
von vornherein verhindert werden.
Serververwaltung |
169
RegisterAllgemein: Wenn keine Server aktiv sind, ist ein Serverzugriff via pxe natürlich
von vorn herein nicht möglich. Insofern muss gewährleistet sein, dass im Register
Allgemein die grundsätzlichen Einstellungen zur pxe Unterstützung getätigt sind.
i
Nach der Prüfung der Blacklist-Einstellungen in der Registerkarte Zugriff
werden schließlich immer noch die Einstellungen unter Allgemein geprüft.
Daher dürfen die hier hinterlegten Werte denen unter Zugriff geregelten
Einstellungen auch nicht entgegenstehen! Sollte dem dennoch so sein, sind
die Einstellungen unter Zugriff wirkungslos.
Register Zugriff: Hier stehen Ihnen zwei Möglichkeiten der Deklaration von Zugriffsbeschränkungen zur Verfügung: Die Definition einer blacklist, das heißt sämtliche
gelisteten mac-Adressen werden ignoriert
und die nicht gelisteten dürfen passieren
oder die Definition einer sogenannten whitelist, das heißt ausschließlich gelistete macAdressen werden akzeptiert, der Rest wird
ignoriert. Nehmen wir an, Sie möchten die
drei beispielhaften mac-Adressen listen, einmal white, einmal black, dann editieren Sie
zunächst erst einmal Ihre Liste.
Abbildung 4–10: PXE Zugriff
Black-&Whitelisting
Klicken Sie dazu auf das linke der beiden Icons und der Cursor springt in das
Listenfeld. Tragen Sie dort Ihre mac-Adressen ein. Dabei können Sie auf die übliche
Schreibweise verzichten: Schreiben Sie die 12 Zeichen hintereinander, ein Klick in
das Listenfeld formatiert die Werte ordnungsgemäß. Drücken Sie auf Übernehmen,
damit sind die mac-Adressen gespeichert.
Erst die Wahl einer der zur Verfügung stehenden Optionen legt fest, ob es sich
um eine black- oder whitelist handelt: Allen MAC-Adressen Zugriff gewähren ist
black – denn den Gelisteten wird der Zugriff verweigert. Demzufolge gilt: Allen
mac-Adressen Zugriff verweigern ist white – denn ausschließlich den Gelisteten wird
der Zugriff gewährt. Verweigerte mac-Adressen werden übrigens einfach ignoriert.
Lediglich eine Notiz im baramundi Management Suite-Log zeugt in einem solchen
Fall von dem gescheiterten Versuch.
mac-Adressen beinhalten oftmals spezifische Kennungen, so benutzen manche
Hardware-Hersteller bestimmte Zeichenfolgen. Die in den Abbildung verwendete
Adresse 00:07:E9:xx:xx:xx identifiziert zum Beispiel die Firma Intel. Um solcherlei
Muster möglichst bequem und unter minimaler Tipparbeit zu editieren, sind sogenannte wildcards vorteilhaft. Zwei sehr mächtige können Sie auch beim Ausfüllen
der Listen verwenden, nämlich das Sternchen * für alle möglichen Zeichen sowie
das Fragezeichen ? für ein mögliches Zeichen. Sofern Sie also in unserem Beispiel
sämtliche mac-Adressen der Firma blacklisten möchten, so wäre das mit dem Listeneintrag 00:07:E9* ohne Weiteres möglich und führte zu genau dem gleichen
Resultat wie der oben genannte Eintrag.
Natürlich können Sie Listeneinträge auch ändern oder löschen. Letzteres ist über
das kleine Icon mit dem Kreuz schnell bewerkstelligt (noch schneller freilich mit
der Entf-Taste) und zum Ändern doppelklicken Sie einfach den entsprechenden
Eintrag.
Bedingungen unter den Registern Allgemein und Zugriff. Wie nun hängen die unter den
Registerkarten Allgemein und Zugriff einzustellenden Kriterien zusammen? Es ist
wichtig zu wissen, dass vom System zunächst die Angaben im Zugriff-Register gelesen werden. Erst danach erfolgt die Auswertung der Daten im Register Allgemein.
Sofern sich in dieser Konstellation nichts ausschließt, behandelt das System beide
Angaben als logisch und-verknüpft. Um die ganze Sache ein wenig zu veranschaulichen, ein Beispiel:
Fall 1: Im Register Zugriff gilt Allen MAC-Adressen Zugriff verweigern; aber die
mac-Adresse des zugreifenden Rechners ist «white» gelistet; Im Register Allgemein
gilt: Unbekannte Clients—Anfrage ignorieren.
Ergebnis: Register Zugriff lässt die Anfrage zu, doch Register Allgemein lehnt die
mac-Adresse als unbekannt ab – im Ergebnis kein Zugriff! Wie schaut nun der
umgekehrte Fall aus?
Fall2: Im Register Zugriff gilt: Allen MAC-Adressen Zugriff gewähren, aber die
mac-Adresse des zugreifenden Rechners ist «black» gelistet; Register Allgemein:
Unbekannte Clients—Automatisch erfassen.
Ergebnis: Hier wird die mac-Adresse bereits von der ersten Instanz Zugriff zurückgehalten. Ob nun die zweite Instanz Allgemein die Anfrage akzeptiert oder nicht,
spielt keine Rolle – die p xe-Anfrage wird ignoriert!
Serververwaltung |
171
Downloader
Das Downloader Modul kann Dateien aus dem Internet oder von anderen Quellen
herunterladen. Es wird unter anderem für folgende Anwendungen verwendet:
• Download der bpmData.zip und wsusscn2.cab für das Patchmanagement,
• Download der aktuellen pci Device Definitionen, Download des aktuellen
Regelwerks für die Softwareinventarisierung.
Für das Downloader Modul kann, falls benötigt, ein Proxy Server mit zugehörigem
Login konfiguriert werden. In diesem Fall aktivieren Sie das Kontrollkästchen und
tragen die zugehörigen Daten ein. Dazu ist auch die Angabe des Ports zwingend
erforderlich, zum Beispiel: proxy.baramundi.net:8089
Modulzustände
Abbildung 4–11: Server/Modulzustände
Hier finden Sie Informationen zu den aktuellen Versionen und können über das
Kontextmenü (rechte Maustaste) die einzelnen Module stoppen oder starten. Ist ein
Modul angehalten, so wird dies durch ein gelbes Warndreieck am Rootknoten symbolisiert. Wenn die Status sämtlicher Module unbekannt sind, ist der Serverdienst
höchstwahrscheinlich nicht gestartet.
Lock Manager
Werden die Eigenschaften eines Knotens bearbeitet, so wird ein Eintrag im Lock
Manager erzeugt, der diese Entity für die Bearbeitung durch andere Benutzer sperrt.
Kann ein gesperrter Knoten nicht ordnungsgemäß gespeichert werden, so kann dies
dazu führen, dass der Eintrag im Lock Manager erhalten bleibt und der Knoten
für jede weitere Bearbeitung gesperrt ist. Sollten in dieser Liste solcherlei Einträge
vorhanden sein, können diese Einträge gelöscht werden.
•
•
•
•
•
•
System: Bezeichnung des Clients, auf dem die Sperre gesetzt wurde.
Benutzer: Name des Benutzers auf dem Client, der die Sperre verursacht hat.
Instanz: Numerischer Wert.
Uhrzeit: Datum und Uhrzeit, zu dem die Sperre verursacht wurde.
Knoten: Numerischer Wert.
Schlüssel: Primärschlüssel in der Datenbank.
Ereignisanzeige
In der Ereignisanzeige finden Sie Informationen zu den Servervorgängen.
Abbildung 4–12: Server/Modulzustände
Versionsinformation
Den Versionsinformationen können Sie die Version der wichtigsten Bibliotheken
entnehmen und nach welchem Datenbankschema die Datenbank strukturiert ist.
Serververwaltung |
173
Abbildung 4–13: Server/Versionsinformation
Allgemeine Verwaltung
Neben der Serververwaltung stehen zu den meisten anderen Bereichen der baramundi Management Suite umfangreiche Möglichkeiten der Verwaltung zur Verfügung.
Sicherheitsverwaltung
Die Sicherheitseinstellungen (Abb.4–14) selbst erreichen Sie über den Database
Manager (Startmenü). Im Dialogfeld wählen Sie die untere Option Sicherheit konfigurieren und beenden* mit dem nächsten Dialog den moc.
Über die beiden Listenfelder Domäne und Benutzername ist der Benutzer festgelegt,
der stets auf das System zugreifen kann. Sofern sich die Domäne ändern sollte, sind
hier solcherlei Änderungen anzugeben, damit der Benutzer auch weiterhin auf das
System zugreifen kann.
* Sofern sich der MOC durch den Dialog nicht schließen sollte, trennen Sie
über die MS-DOS-Konsole.
Abbildung 4–14: Database Manager
Abbildung 4–15: Authentifizierung
Sicherheitsprofile
Die Wahl eines berechtigten Benutzers ist
als globale Einstellung zunächst erst einmal
ein grundsätzliches Reglement. Aus diesem
können nunmehr bestimmte Sicherheitsprofile abgeleitet werden, die dann bestimmten
Anwendern zugeordnet, für sicherheitsrelevante Restriktionen sorgen.
Über Sicherheitsverwaltung im Kontextmenü Neu—Sicherheitsprofil kann eine Auswahl derjenigen Bereiche getroffen werden,
die beim Systemstart nicht zur Verfügung
stehen sollen (Abb.4–16). Diejenigen Bereiche der Suite, die in dieser Einstellung nicht
aktiviert sind, werden für einen entsprechenAbbildung 4–16: Auswahl
den Benutzer im baramundi Management
Center gar nicht erst angezeigt. Nach Bestätigung dieser Einstellungen wird das
neue Sicherheitsprofil unter dem gleichnamigen Knoten angelegt und kann Nutzern
zugeordnet werden.
Allgemeine Verwaltung |
175
Rechtegruppen und -benutzer
Im Knoten Sicherheitsverwaltung befindet sich direkt unter den Sicherheitsprofilen der Eintrag Windows Benutzer und Gruppen, in welchem schließlich Benutzer/Benutzergruppen angelegt, und Sicherheitsprofile zugeordnet werden können.
Das Kontextmenü Neu bietet die Auswahl zwischen Windows Benutzer oder
Gruppe und Benutzer oder Gruppe (Direkteingabe). Im ersten Fall kann aber
nach bekannten Gruppen oder Benutzern gesucht werden.
Über die Schaltfläche Objekttypen
(Abb.4–17) ist es möglich festzulegen,
ob es sich bei der Rechteverteilung um
Abbildung 4–17: Benutzer
Benutzer, Gruppen oder beides handelt.
Auch können Sie die Pfade, in denen die entsprechenden Personen vorhanden sind
und in denen bestimmte Rechte gelten sollen, angegeben. Im unteren Listenfeld
sind bestimmte Namen einzutragen und mit Namen überprüfen ist es möglich, deren
Existenz zu testen: Ist der Name bekannt, wird dieser um den Suchpfad ergänzt,
andernfalls wird ein Dialog Name nicht gefunden eingeblendet und um Neueingabe
gebeten. Über die Schaltfläche Erweitert können Sie Ihre Angaben noch verfeinern.
Mit der Direkteingabe ist es über ein Listenfeld möglich, einen Gruppen- oder Benutzernamen direkt an das System zu übergeben. Dort (Verwaltung/Sicherheitsverwaltung/Windows Benutzer und Gruppen) kann den Anwendern über das Kontextmenü
Eigenschaften durch Anklicken ein Sicherheitsprofil (Abb.4–18) oder mehrere Profile zugeordnet werden.
Setzen von Berechtigungen. Nachdem Sicherheitsprofile definiert wurden, die grundsätzlich regeln, welche Elemente der bms Baumstruktur sichtbar sind, können den
verbleibenden Bereichen oder Objekten bestimmte Rechte gewährt beziehungsweise entzogen werden:
•
•
•
•
Full (full): volle Rechte, keine Einschränkungen,
Re (read): Leserechte,
Mo (modify): Ausführungsrechte,
Del (delete): Löschrechte.
Ist ein Benutzer mehreren Sicherheitsprofilen zugewiesen, so wird – wie auch bei
Benutzerrechten unter Windows – jeweils das höchste Recht zugeordnet.
i
Das erste Recht Full erlaubt nicht nur das Lesen, Ausführen und Löschen,
sondern darüber hinaus auch das Ändern der Rechte selbst! Sofern also
Rw+Mo+Del aktiviert sind, ist es eben nicht das Gleiche wie Full.
Dazu wählen Sie im Kontextmenü eines Knotens den Eintrag Eigenschaften und darin die Registerkarte Berechtigungen. In diesem Dialog können zunächst über die Hinzufügen- und Entfernen-Schaltflächen Sicherheitsprofile hinzugefügt und entfernt
und selbigen dann über die Optionsfelder die oben genannten Lese-, Ausführungsund Löschrechte eingeräumt oder verweigert werden. Unter Special ist es zudem
möglich, das Erstellen von Unterknoten (OrgUnit) oder Unterobjekten (Unterobjekt) mit Deaktivierung der entsprechenden Optionen zu verhindern. In allen
Knoten, in denen Unterknoten anlegbar sind, kann über die Option Berechtigungen erben das Berechtigungsschema des darüber liegenden Knotens übernommen
werden. Dieses ist dann auch wiederum editierbar (Abb.4–19).
Sofern Sie nun die Profile erstellt und entsprechenden Benutzern zugeordnet haben,
löschen Sie bitte den Sternchen-Benutzer. Es handelt sich hierbei um ein DefaultProfil, welches jedem Benutzer sämtliche Rechte einräumt. Wird das SternchenProfil beibehalten, können Änderungen nicht wirksam werden. Die Löschung kann
einfach über die Entf-Taste veranlasst werden.
Abbildung 4–18: Sicherheitsprofile
Abbildung 4–19: Berechtigungen
177
!
Achten Sie jedoch vor dem Löschen des Sternchen-Benutzers darauf, dass Sie
im Database Manager unter Sicherheitsprofile ein Administrator eingetragen
ist, der alles darf. Notfalls können Sie dies aber zu einem späteren Zeitpunkt
nachholen. Der Database Manager ist ein Administrationstool, das auch nur
Administratoren zur Verfügung stehen sollte. Gleiches gilt übrigens für den
gesamten Knoten Verwaltung.
Alternativ: Zum Löschen eines Profils klicken Sie dieses an und wählen im Kontextmenü Löschen. Nach der Bestätigung der bms-Rückfrage, wird das Profil unwiederbringlich entfernt. Nach einem Serverneustart über den Kontexteintrag des obersten
bms-Knotens Server starten, sind Ihre Sicherheitseinstellungen dann wirksam.
Ein Beispiel
Wir wollen die bms-Sicherheitseinstellungen kurz noch durch ein Beispiel veranschaulichen. Nehmen wir dazu an, Sie möchten die Bereiche das Inventory-Moduls
aus Datenschutzgründen allein verwalten. Nehmen wir ferner an, all Ihre Kollegen
sollen ansonsten vollen Zugriff auf die Suite erhalten. Damit diese Gruppe sich
nicht Zugriff auf Inventory verschaffen kann, soll sie Einstellungen nur sehen, nicht
aber bearbeiten können.
Sicherheit konfigurieren. Zunächst gilt es die globalen Einstellungen zu wählen, das
heißt in unserem Fall den Administrator (ohne Rechtebegrenzung).
1. Wählen Sie in den Einstellungen des Database Managers Sicherheit konfigurieren und darin das entsprechende Dialogfeld.
2. Geben Sie in den Einstellungen einen Administrator an.
Sicherheitsprofil. Gemäß der oben getroffenen Annahmen gilt es nun ein Sicherheitsprofil zu erstellen, welches das Modul Inventory einer allgemeinen Bearbeitung
entzieht. Inventory wird also nach der Profilerstellung als Eintrag im baramundi
Management Center gar nicht erst angezeigt.
3. Öffnen Sie den Dialog zur Erstellung eines neuen Sicherheitsprofils.
4. Benennen Sie das Profil: Keine Inventur.
5. Deaktivieren Sie die Option Inventory.
Gruppenzuweisung. Zudem ist das eben erstellte Sicherheitsprofil noch der entsprechenden Benutzergruppe zuzuordnen.
6. Wählen Sie unter Verwaltung/Sicherheitsverwaltung/Windows Benutzer und
Gruppen den Kontextmenüeintrag Neu—Windows Benutzer oder Gruppe.
7. Klassifizieren und benennen (Ohneinv) Sie im Dialog diejenige Gruppe/Nutzer,
die von der Verwendung von Inventory ausgeschlossen werden sollen.
8. Wählen Sie im Kontextmenü der erstellte Gruppe (Ohneinv) den Punkt
Eigenschaften. Darin markieren Sie die Option Keine Inventur.
Rechtesteuerung. Schließlich ist der Knoten Verwaltung noch einzuschränken und
zwar dergestalt, dass die Gruppe lediglich Leserechte auf den Knoten erhält. Starten
Sie anschließend den bms-Server neu.
Domänenkonfiguration
Hier werden Installations- sowie Administrationsbenutzer für die zu verwaltenden
Domänen konfiguriert. Der Installationsbenutzer kann für jede Domäne individuell
angelegt werden. Dabei wird der Administrationsbenutzer zur Installation des baramundi Management Agents; der Installationsbenutzer hingegen zur Jobausführung
verwendet. Der Installationsbenutzer benötigt dabei administrative Rechte auf dem
Zielsystem; der Administrationsbenutzer benötigt administrative Rechte in der
Domäne.
Abbildung 4–20: Server/Versionsinformation
179
Abbildung 4–21: Domänen: Allgemein
Abbildung 4–22: Domänen: Aktionen
Allgemein. Im Kontextmenü Neu—Domäne unter Verwaltung/Domänenkonfiguration
können neue Domänen angelegt werden. Im ersten Register des Dialoges ist dazu
zunächst der Name der Domäne (Abb.4–21) anzugeben. Dabei ist die Verwendung
der Platzhalter * und ? zulässig, um mehrere Namen zusammenzufassen.
Der Typ definiert die Art der Domäne. Hier ist auch eine Einstellung Beliebiger Typ
gültig. Dieser spezielle Typ erlaubt die Zuordnung einer Domäne ohne Angabe des
Typs. In der Voreinstellung ist diese Domäneneinstellung mit einem * bezeichnet.
Unter Zugriffaccounts sind dann die das Administratorkonto für die Domäne einzutragen (Administrator), das Kennwort dieses Administratorenkontos (AdminPasswort), das Konto für den Installationsbenutzer (Installationsbenutzer) sowie das
Passwort für dieses Konto (InstallUser-Passwort.)
Mit der Schaltfläche Accouts überprüfen kann getestet werden, ob die Kontoinformationen korrekt sind. Dabei wird das Konto und das zugehörige Kennwort überprüft,
nicht, ob die Gruppe oder das Konto über ausreichend Rechte verfügen. Ist die
Namensauflösung für eine Fremddomäne nicht ordnungsgemäß konfiguriert, kann
das Ergebnis der Abfrage fehlerhaft sein.
Aktionen. Über den Windows-Suchdienst (Abb.4–21) ist die Identifizierung von
neuen Workstations und Servern möglich. Neue Systeme können automatisch in
eine bestimmte logische Gruppierung aufgenommen werden.
Dabei stehen zusätzlich folgende Optionen zur Verfügung:
• Die Option Agent sofort installieren installiert den baramundi Management
Agent auf einem System, sobald dieses neu erfasst wird. Weitere Aktionen
sind damit nicht verbunden, es sei denn, das System wird in eine Gruppe
eingeordnet, der automatisch auszuführende Jobs zugeordnet sind.
• Mit der Option Agent kontinuierlich aktualisieren wird der baramundi Management Agent aktualisiert, wenn die Version des Zielsystems von der Version
des Servers abweicht. Dieser Versionsabgleich wird nur bei Jobausführungen
durchgeführt, nicht beim Start des Dienstes.
Nach einem Versionsupdate werden die Agentversionen bei der ersten Jobausführung aktualisiert. Verwenden Sie unterschiedliche Konten für den Administrationsund den Installationsbenutzer. Achten Sie bitte darauf, dass das Konto des Administrationsbenutzers auch aktiviert ist.
IP-Netzwerke
Sind in Ihrem Netzwerk mehrere IP-Netze
vorhanden, zum Beispiel zur Verwaltung
von Außenstellen verwalten, also über mehrere Standorte verfügen, kann es sinnvoll
sein, mehrere dip-Server zu verwenden, um
die Netzwerklast auf den zumeist langsameren wan-Verbindungen soweit als möglich
zu reduzieren.
Neben Name, also der eindeutigen Bezeichnung des neuen Netzwerks, können unter
DIPS die u n c-Pfade zu mehreren dip-Server
hinterlegt werden. Die dip-Server werden dabei durch Semikola getrennt. Ist dieses Feld
leer, so wird der dip-Server der zugehörigen
Abbildung 4–23: IP-Netzwerk
logischen Gruppierung verwendet. Wenn
die Variable GroupDIPs hinzugefügt wird, erfolgt bei Nichterreichbarkeit der angegebenen dip-Server zusätzlich ein Versuch, die bei der logischen Gruppierung
hinterlegten dip-Server zu erreichen.
181
Bootumgebungen
Sowohl für die Betriebssysteminstallation
als auch für das Zurückspielen eines Images
ist es erforderlich, ein eingeschränktes Betriebssystem in den Arbeitsspeicher des Zielsystems zu laden, um die gewünschten Aktionen automatisiert ausführen zu können.
Vordefiniert sind dabei zwei verschiedene
Bootumgebungen: eine dos-Umgebung und
ein Windows PE (32- und 64-Bit). Damit
die Bootumgebungen von einem Zielsystem
geladen werden können, benötigt das Zielsystem eine p xe-fähige Netzwerkkarte und
mindestens 512 MByte ram für WindowPE. Das Anlegen der Bootumgebungen beAbbildung 4–24: IP-Netzwerk
schreibt «OS-Install» des vorigen Kapitels* ,
weshalb hier nur die Konfigurationsmöglichkeiten vorgestellt werden.
Je nachdem, welche Bootumgebung unter Verwaltung/Bootumgebungen im Kontextmenü Neu gewählt wird, stehen die folgenden Einstellungen zur Verfügung:
• Im Bootmenü anzeigen: Legt fest, ob dieser Eintrag im Bootmenü erscheint,
falls das Bootmenü angezeigt wird.
• Bootimage: Name des zu startenden Bootimages. Anzugeben ist der Name des
Bootimages, das unter C:\Programme\bsAG\bms\TFTPRoot abgelegt wurde.
• config.sys, autoexec.bat, baramndi.ini, lmhosts: Diese Einträge stehen nur bei
dos-Bootimages zur Verfügung und erlauben das direkte Bearbeiten dieser
Dateien aus der Oberfläche heraus. Wenn Sie mit der Maus über dem Dateinamen stehen bleiben, erscheint der Dateiinhalt als Tooltipp.
• System wird neu installiert: Mit dem Starten der Bootumgebung wird das
System neu installiert.
• Schritt wird nicht bestätigt: Das gestartete Image bestätigt die Ausführung des
Schrittes nicht. Der Schritt wird mit dem folgenden Bootvorgang automatisch
als erfolgreich markiert.
• Kommentar: Ermöglicht die Eingabe eines Kommentars.
*
vgl.dazu S.58
Abbildung 4–25: Verwaltung/Variablen
Variablen
Mit Variablen lassen sich vielfältige Informationen zu einem Objekt hinterlegen.
Diese können die Verwaltung der Infrastruktur erheblich erleichtern. Neue Variablen lassen sich über das Kontextmenü Neu—Variable unter Verwaltung/Variablen
hinzufügen. Darin legt der Bereich fest, an welchen Objekten die Variable zur Verfügung stehen soll. Dazu stehen folgende Variablentypen Typ zur Verfügung:
•
•
•
•
•
•
•
•
Zeichenkette: Beliebiger Text ohne Anführungszeichen oder Apostroph
Zahl: Eine beliebige ganze Zahl
Ein/Aus-Feld: Kontrollkästchen
Editierbares Auswahlfeld: Es kann nur ein Wert aus dem vorgegebenen Wertebereich gewählt werden. Die Bereiche werden durch die Pipe | getrennt
eingegeben, zum Beispiel Quartal1|Quartal2|Quartal3|Quartal4.
Auswahlliste
Datum: Es kann ein Datum über einen Auswahldialog eingegeben werden.
Dateiname: kann über den Dateiauswahldialog ermittelt werden.
Verzeichnisname
183
Abbildung 4–26: PatchMGT: Allgemein
Abbildung 4–27: PatchMGT: Sprache
Patch Management
Hier wird eine Basiskonfiguration des Patchmanagements durchgeführt. Folgende
Funktionen stehen dabei über das Kontextmenü Eigenschaften zur Verfügung:
Allgemein
• Die Scanbefehlszeile: (Abb.4–26) ist das Kommando, das einen Patch Scan
initiiert. Diese Zeile sollte im Normalfall unverändert bleiben.
• Patch Base Folder: Der u nc-Pfad, auf dem die Datei wsusscn2.cab zu finden
ist. Diese Zeile sollte im Normalfall* unverändert bleiben.
• Standardwerte setzen: Setzt beide Zeilen auf die Standardwerte zurück.
Sprachen. Aus den zur Verfügung stehenden Sprachen (Abb.4–27) können diejenigen ausgewählt werden, die für das Patchmanagement zur Verfügung stehen
sollen. Da der Umfang der herunterzuladenden Patches verhältnismäßig groß ist,
sollten nur solche Sprachen markiert werden, die in der Infrastruktur auch wirklich
benötigt (i.a.R.die Landessprache und Englisch) werden.
* Normalfall bedeutet hier eine recht übersichtliche Struktur i.S.v.möglichst
nur ein Standort. Andernfalls tragen Sie anstatt des baramundi Servers besser
den DIP ein.
Abbildung 4–28: Produkte
Abbildung 4–29: Benutzerkritikalitäten
• Die Beschreibungen der Bulletins stehen in den Sprachen Deutsch und Englisch zur Verfügung.
• Ein Kontrollkästchen markiert eine Sprache zum Download. Der erfolgt
abhängig von den markierten Sprachen und der Konfiguration im Register
Produkte.
Produkte. In diesem Register (Abb.4–28) kann für die aufgelisteten Produkte festgelegt werden, wann Patches heruntergeladen werden sollen und wie die Freigabe
erfolgen soll.
• Freigabemodus
– Automatisch: Patches für das Produkt werden automatisch freigegeben.
– Manuell: Patches für das Produkt müssen manuell freigegeben werden.
• Downloadmodus
– Bei Verfügbarkeit: Patches für dieses Produkt werden heruntergeladen,
sobald sie verfügbar sind.
– Bei Bedarf: Patches für dieses Produkt werden heruntergeladen, wenn
sie durch einen Patch Scan als fehlend erkannt wurden.
– Manuell: Der Patchdownlod muss manuell veranlasst werden.
185
Abbildung 4–30: Prioritäten
Abbildung 4–31: SLAs
Benutzerkritikalitäten. Standardmäßig sind hier (Abb.4–29) die Kritikalitäten aufgelistet, die der Einstufung durch Microsoft entsprechen. Sollten zusätzliche Kritikalitäten gewünscht sein, können weitere Einträge hinzugefügt werden.
Prioritäten. Hier (Abb.4–30) kann nun festgelegt werden, auf welche Bereiche sich
die zuvor deklarierten Kritikalitäten auswirken. Sollten andere oder zusätzliche
Prioritäten gewünscht sein, können weitere Einträge hinzugefügt werden. Es geht
hier also eher um Gruppieren denn ums Priorisieren.
SLAs. Durch die Prioritäten und die Kritikalitäten ergibt sich eine Tabelle, über
welche die slas (Abb.4–31) (service level agreement) abgebildet werden können.
Der Zellenwert legt die Zeitdauer in Tagen fest, innerhalb derer ein Patch einer
bestimmten Kritikalität auf einer Gruppe Systeme ausgebracht werden muss.
So könnten beispielsweise die Rechner verschiedener Abteilungen eines Unternehmens dergestalt priorisiert werden, dass Rechner – beispielsweise die Desktops der
Buchhaltung – ein als «hoch» kritikalisiertes Sicherheitsupdate sofort, die Laptops
des Außendienstes hingegen in den «nächsten drei Tagen» ausführen müssen. Diese
Einstellungen können auch automatisch erfolgen, werden aber in aller Regel von
einem Administrator vorgenommen.
• Die Spalten werden durch die Prioritäten bezeichnet.
• Die Zeilen werden durch die Benutzerkritikalitäten bezeichnet.
• Die Werte in den Zellen legen die Anzahl der Tage fest, innerhalb derer
ein Patch ausgebracht werden soll. Diese Werte werden zum Berechnen der
Basis-Erfüllungsgrade verwendet.
Recovery
Unter dem Knoten Recovery werden keine Daten angezeigt. Es ist lediglich ein Zugriff auf elementare Einstellungen für das Personal Backup über das Kontextmenü
des Knotens ist möglich.
• Der Pfad für Sicherungssätze ist der u n c-Pfad, auf dem die Sicherungssätze
abgelegt werden sollen. Es ist möglich, die baramundi Variablen bei der
Pfadangabe zu verwenden.
• Passwort für Backup: Schützt die Sicherung gegebenenfalls mit einem Kennwort (von min.16 Zeichen Länge) gegen unberechtigten Zugriff.
• Blacklistet User: Sollen die Einstellungen und Dateien für bestimmte Benutzerprofile, zum Beispiel Administrator, nicht gesichert werden, so hier Domänen
und Benutzer angeben, für die keine Sicherung erfolgen soll.
Inventory
In den Eigenschaften von Verwaltung/Inventory sind einige Einstellungen bezüglich
des Moduls Inventory zu treffen.
Allgemein. Wenn aus einer Regel eine Software generiert wird, dann wird hier der
Ablageort dieser Software festgelegt. Via Voreinstellung ist dies Applikationen. Für
den (sehr unwahrscheinlichen) Fall, dass ein alternativer Ablageort gewählt werden
soll, ist dieser hier, unter verknüpfte Software erstellen in einzustellen.
Applikationsüberwachung. In diesem Register ist die Option Applikationsüberwachung
bei neuen Clients aktivieren einzuschalten, wenn baramundi aut für neu erfasste
Clients automatisch aktiviert werden soll.
187
Abbildung 4–32: Asset-Typ (Allgemein)
Abbildung 4–33: Asset-Typ (Standardwerte)
Asset-Typen
Für die Verwaltung von Geräten unter Inventory/Assets, ist es zunächst notwendig,
einen entsprechenden Asset-Typ anzulegen. Typische Geräte sind bereits definiert:
•
•
•
•
•
•
•
•
•
•
Beamer
Digitalkamera
Drucker
Externe Festplatte
KeyCard
Monitor
Multifunktionsgerät mufu
Scanner
SmardcardReader
Switch (Router)/Aktive Netzwerkkomponente
Jedem dieser Typen sind charakteristische Eigenschaften zugeordnet – zu sehen bei
Wahl eines Asset-Typs –, die das Gerät beschreiben. Wird ein weiterer Asset-Typ
benötigt, wählen Sie Verwaltung/Asset-Typen—Neu–Asset-Typ und tragen im sich
daraufhin öffnendem Dialog die Informationen zum neuen Gerät ein.
Im Register Allgemein ist ein Name (Abb.4–32) anzugeben. Zudem kann ein entsprechendes Icon* gewählt werden. Im Register Standardwerte können zudem einige
Angaben zum Hersteller, zu den Kosten und dergleichen mehr (Abb.4–33) hinterlegt
werden; die Einträge technischer Informationen erfolgen in den Eigenschaften des
jeweiligen Asset-Typs. Diese Eigenschaften sind im Kontextmenü des Asset-Typs
unter Neu—Eigenschaften zu editieren. In diesem Dialog ist es unter Verwendung
eines entsprechenden Eigenschaftstyps möglich, Angaben zum Gerät zu hinterlegen.
Es können für ein Gerät mehrere Eigenschaften gesetzt werden.
DIP-Server Synchronisierung
Die Synchronisation verschiedener dip-Server wird hier konfiguriert. Es gibt zwei
Varianten, eine solche Synchronisation durchzuführen:
• Die Standardkonfiguration ist schnell durchgeführt: Es werden lediglich
zwei dip-Shares benötigt, auf die vom baramundi Management Server aus
zugegriffen wird. Es kann dabei keinerlei Bandbreitenbegrenzung erfolgen,
da der Datentransport über einfaches Kopieren der Dateien funktioniert.
• Bei der erweiterten Variante wird auf den zu synchronisierenden Rechnern
der dip-Sync-Dienst benötigt. Dieser muss gegebenenfalls dort installiert sein.
Die Daten können dann sowohl von einem lokalen Pfad als auch von einem
Share aus synchronisiert werden. Als Erweiterung werden hier die unter
Kommunikation konfigurierten Kommunikationsprofile verwendet.
Um einen erweiterten Synchronisierungsjob anzulegen, müssen zunächst unter
dip-Server die Rechner mit den dip-Sync-Diensten bekanntgemacht gemacht werden.
Für einen Standard-Synchronisierungsjob ist dies nicht notwendig. Über das Kontextmenü des Knotens DIP Server Synchronisierung lässt sich einstellen, wieviele
Synchronisationsjobs gleichzeitig aktiv sein dürfen und in welchen Abständen auf
Veränderungen geprüft werden soll.
DIP Server
Hier (Abb.4–34) wird die Liste der dip-Server verwaltet. Diese sind für den Erweiterten DIP Sync die Rechner, auf denen der dip Sync-Dienst installiert ist. Falls der
*
Muss als ico-Datei vorliegen.
189
Abbildung 4–34: DIP-Server
Abbildung 4–35: Synchronisierungsjob
Dienst auf dem Rechner läuft, wird dies durch das Symbol angezeigt*. Der Name des
dip-Servers muss als f q d n (fully qualified domaine name) eingetragen werden. Eine
solche Synchronisation wird standardmäßig auf dem Port 10090 durchgeführt.
Synchronisierungsjobs
Da der baramundi Management Server zur Verteilung der Installationslast bei
Softwareverteilungsjobs beliebig viele dips unterstützt, ist auch ein Mechanismus
zur Synchronisierung vorgesehen: der dip Sync. Dieser synchronisiert (Abb.4–35)
die dip-Verzeichnisse nach dem Master-Slave-Prinzip, das heißt die Slaves werden
periodisch auf den Zustand des Masters gebracht. Es werden nur Differenzen
abgeglichen und es kann eingestellt werden, wann und wie Slaves synchronisiert
werden. Dazu sind sogenannte Synchronisierungsjobs† zu erstellen.
Register Allgemein. Der Name sollte möglichst selbsterklärend gewählt werden. Vorteilhaft ist die Verwendung von Größer-/Kleiner-Zeichen, um zu verdeutlichen, in
welche Richtung der Abgleich stattfindet.
* Bitte beachten Sie, dass der Rechner, auf dem das Management Center läuft,
hierfür Zugriffsrechte auf dem Rechner benötigt, auf dem der Dienst tätig ist.
† Vgl.dazu S.26
• Das Intervall legt fest, zu welchen Zeiten der Synchronisierungsjob starten
soll. Wird hier kein Wert eingetragen, so erfolgt die Synchronisation sofort bei
Änderung, was jedoch nicht immer erwünscht ist. Beispiele: 14:00 (14.00 Uhr
täglich), 14:30/Mo (jeden Montag um 14.30 Uhr), 15:00/Mo/Di;18:00/Mi/Do
(jeden Montag und Dienstag um 15.00 Uhr, Mittwoch und Donnerstag um
18.00 Uhr).
• Der Quellpfad ist das Verzeichnis auf dem Master-dipServer in unc, das für
die Durchführung der Synchronisation als Referenz herangezogen wird.
• Der Zielpfad ist das Verzeichnis auf dem Slave-dipServer als u n c.
• Die Dateimaske legt fest, welche Dateien bei der Synchronisation berücksichtigt werden sollen, zum Beispiel *.txt oder *.exe.
• Die Methode bestimmt die Art und Weise, nach der die Dateien der dipServerSlaves mit denen des dipServer-Masters verglichen werden. Mögliche Einstellungen sind: Größe->Datum, Größe->Datum->Prüfsumme.
• Schreibgeschützte Dateien werden auf dem Slave überschrieben, wenn dieses
Kontrollkästchen markiert ist.
• Exakte Kopie erstellen: Wird bei der Synchronisierung festgestellt, dass auf einem dipServer-Client ein Verzeichnis existiert, dieses jedoch auf dem dipServerMaster nicht mehr vorhanden ist, so wird auf dem Client das Verzeichnis
gelöscht, sofern Sie dieses Kontrollkästchen markieren.
Bei einem erweiterten Synchronisierungsjob stehen zusätzlich noch die folgenden
Optionen zur Verfügung: Bei Fehler abbrechen und Leere Verzeichnisse kopieren.
Register Ausgeschlossene Verzeichnisse. Falls bei der Synchronisierung Verzeichnisse
ignoriert, also nicht synchronisiert werden sollen – beispielsweise weil bestimmte
Programme an einem anderen Standort nicht benötigt werden – so können diese
Verzeichnisse hier angegeben oder über die Schaltfläche ausgesucht werden.
Active Directory Synchronisierung
Um Software benutzerbezogen verteilen* zu können, ist es zunächst notwendig,
sämtliche, für Verteilungsjobs in Frage kommenden Mitarbeiter im System zu erfassen. Diese sind über den Verzeichnisdienst Active Directory (AD) erreichbar.
*
Vgl.dazu S.25
191
Erweiterter
SyncJob
Abbildung 4–36: Active Directory Synchronisierung
Zur Übernahme der Benutzerdaten wird ein entsprechender Synchronisierungsjob eingerichtet. Im Dialog des Kontextmenüs von Verwaltung/Active Directory
Synchronisierung unter Neu—Active Directory Synchronisierungsjob sind die dafür
notwendigen Informationen anzugeben.
Name: Geben Sie dem Job (wie üblich) einen aussagekräftigen Namen.
Typ: Hier ist zur Zeit nur die Benutzersynchronisierung möglich.
Quelle: Die Datenquelle ist über eine Schaltfläche wählbar.
Intervall: Hier ist ein Zeitraum zur Aktualisierung der Benutzerdaten einstellbar: entweder als Uhrzeit, wie 18:30 oder als Tagesangabe Mo bis So. Verknüpfungen sind über / und ; möglich. Bsp.: 15:00/Mo;18:00/Di für Montags
15.00 Uhr und Dienstags 16.00 Uhr.
• Leere Organisationseinheiten nicht synchronisieren: Mit Aktivierung der Option werden leere Organisationseinheiten bei der Synchronisierung ignoriert.
• Filter: Möglichkeit einer Selektion über l d ap-Syntax.
•
•
•
•
Nach Abschluss und Bestätigung Ihrer Eingaben mit Ok, liegt der Job unter Verwaltung/Active Directory Synchronisierung. Hier ist im Kontextmenü des Jobs der
Eintrag Jetzt ausführen zu wählen oder eben das eingestellte Intervall abzuwarten,
um die Synchronisierung zu starten. Im Ergebnis werden die Benutzer und Gruppen unter Umgebung/Active Directory Benutzer & Gruppen eingetragen. Mit der
Übernahme dieser AD-Benutzerdaten ist es nunmehr möglich, Jobs auch benutzerbezogen durchzuführen.
Abbildung 4–37: Datenbankwartungsaufgaben
Datenbankwartungsaufgaben
Es gibt eine Reihe von Aufgaben, die regelmäßig durchgeführt werden sollten, um
eine Datenbank übersichtlich zu halten, wie zum Beispiel das regelmäßige Löschen
von nicht mehr benötigten Inventarisierungsdaten. Es kann aber auch jede beliebige
s q l-Anweisung ausgeführt werden.
Einer Wartungsaufgabe ist zunächst ein Name zu geben. Unter Typ gelten die
folgenden Einstellungen:
• Historie verkleinern: Verkleinern der Protokolltabellen. Die Variable KeepHours legt dabei die Anzahl der letzten Stunden fest, die vom Log nicht
gelöscht werden sollen (Default=144).
• Hardware-/Software-/WMI- und Benutzerdefinierte Inventarisierungen bereinigen: Löscht veraltete Inventarisierungen. Die Variable KeepScans regelt dabei
die Anzahl der neuesten Scans, die nicht gelöscht werden sollen (Default=2).
• SQL ausführen: Direktes Ausführen von beliebigen sql-Anweisungen. Der
Variable SQL<n> folgt hier die Anweisung, die ausgeführt werden soll, wobei n
eine beliebige Zahl zwischen 1 und 32767 ist und fortlaufend deklariert sein
muss. Die Variablen {Date} und {DateTime} können für das aktuelle Datum
ohne und mit der Uhrzeit verwendet werden. Alle Anweisungen werden
innerhalb einer Transaktion ausgeführt.
• Objekte exportieren: Exportieren der bms-Objekte in Dateien zu Sicherungszwecken. Die Variable <Objects> entspricht dabei dem Namen der Datei, in
193
die die Objekte exportiert werden sollen. Die Variablen Date und DateTime für
das aktuelle Datum ohne und mit Uhrzeit können im Dateinamen verwendet
werden. <Objects> können sein: Components, HardwareProfiles, InstallEngines, Drivers, OSs, Applications, Bundles, Clients oder DynamicGroups.
Die erzeugten Exporte können über die Importschnittstelle wieder geöffnet
werden.
• Softwareinventarisierungsregelwerk anwenden
• Revisionslog exportieren: Exportieren und Löschen des gesamten Revisionslogs. Die Variablen Date und DateTime, für das aktuelle Datum – ohne und
mit Uhrzeit –, können im Dateinamen verwendet werden.
Auch Wartungsaufgaben können im Intervall ausgeführt werden. Beispiele: 14:00
(14.00 Uhr täglich), 14:30/Mo (jeden Montag um 14.30 Uhr), 15:00/Mo/Di;18:00/Mi/Do
(Montag, Dienstag 15.00 Uhr und Mittwoch, Donnerstag 18.00 Uhr).
Downloadjobs
Um den Informationsstand auf dem
baramundi Management Server aktuell zu halten, ist es möglich für den
Download der Definitionsdateien Intervalle zu wählen, in denen diese
aus dem Internet heruntergeladen und
anschließend in die Datenbank importiert werden. Die Downloadjobs
zum Aktualisieren der Dateien für das
Patchmanagement sowie die Aktualisierung der pci-Datenbank sind bereits vordefiniert. Eine Überprüfung
der Intervalleinstellungen ist ratsam.
Zusätzlich können weitere Dateien editiert werden. An den vordefinierten
Jobs sollten, abgesehen vom Intervall,
Abbildung 4–38: Downloadjob
keinerlei weiteren Änderungen erforderlich sein. Das Kontextmenü zu einem Downloadjob (Abb.4–38) ermöglicht eine
unmittelbare Ausführung des Jobs.
Abbildung 4–39: Profil
Abbildung 4–40: Regeln
Bandbreitenmanagement
Das Bandbreitenmanagement ermöglicht die Steuerung der Netzwerkauslastung
bei der Synchronisierung von dips. Die Konfiguration besteht dabei aus dreierlei
Einstellungen: (1) Es müssen mindestens zwei IP-Netzwerke definiert sein. (2)
Ferner muss mindestens ein Profil angelegt werden, das die Parameter der Netzwerkauslastung vorgibt. (3) Über eine Regel wird schließlich eine Verknüpfung
zwischen den IP-Netzwerken und den Profilen erzeugt. Darüber hinaus wird das
Bandbreitenmanagement wie folgt aktiviert.
Profile. Ein neues Bandbreitenprofil lässt sich über das Kontextmenü erzeugen.
Darin muss ein Name vergeben sowie die genutzte Bandbreite eingestellt werden.
Ein solches Bandbreitenprofil kann nun Systemen zugeordnet werden.
Nehmen wir beispielsweise an, ein Kaufhaus möchte dip-Synch-Operationen nachts
– also außerhalb der Geschäftszeiten – eine große, tagsüber jedoch nur eine kleine
Bandbreite einräumen. In diesem Falle wird unter Profile eine dementsprechende
Verbindung (Abb.4–39) erstellt.
Regeln. Unter Verwaltung/Bandbreitenmanagement/Regeln im Kontextmenü Neu—
Kommunikationsregel sind dann die Verbindungen sowie deren Zeiten festzulegen.
195
• Quelle/Ziel: Hier sind diejenigen Netzwerke anzugeben, deren Kommunikationsgeschwindligeit geregelt werden soll.
i
Die Netzwerke, deren Kommunikationsgeschwindigkeit eingestellt werden
soll, müssen zuvor unter Verwaltung/IP-Netzwerke angelegt worden sein.
• Profil: Hier sind die zuvor editierten Regeln einzustellen.
• Zeitraum: Geben Sie hier die Zeiträume ein, in denen die Profile eingesetzt
werden sollen.
Die Regeln stellen die Verbindung zwischen den Bandbreitenprofilen und den IPNetzwerken her. Dabei stehen die zuvor konfigurierten Netzwerke und Profile in
Pulldown-Menüs zur Verfügung. Der zugehörige Zeitraum wird über die folgende
Syntax eingetragen: hh:mm-hh:mm (z.B. 09:00-18:00/Mo/Di/Mi/Do/Fr).
Reservierte Lizenzen
Für sämtliche Softwareverteilungsjobs, bei denen eine Anwendung verteilt werden
soll, für die das Lizenzmanagement aktiviert ist, wird während der Jobausführung eine Lizenz aus dem Lizenzpool reserviert. Sie ist dann in dieser Auflistung
ersichtlich. Damit wird verhindert, dass ein und dieselbe Lizenz gleichzeitig in
mehreren Jobtargets* verwendet wird. Außerdem werden so Inkonsistenzen bei
der Lizenzzählung vermieden. Nach erfolgreichem Abschluss des Jobs wird die
Lizenz aus dieser Auflistung wieder entfernt. Schlägt der Job fehl, so verbleibt der
Reservierungseintrag in der Datenbank und die Lizenz steht ferner nicht mehr zur
Verfügung. Ist sichergestellt, dass die hier geblockten Einträge nicht zu aktiven Jobs
gehören, können die Einträge gelöscht werden.
Revisionslog
Das baramundi Management Center bietet die Möglichkeit, alle Aktionen zu protokollieren, bei denen Objekte in der Datenbank verändert werden. Es gibt drei Arten
von Änderungen:
* Ein Jobtarget entspricht der Zuordnung eines Jobs zu einem einzelnen
Zielsystem.
1. Erstellen eines Objekts,
2. Ändern eines Objekts,
3. Löschen eines Objekts.
Jede Änderung wird dabei dergestalt protokolliert, dass ein Objekt jeweils vor und
nach der Änderung in einer Tabelle der Datenbank gespeichert wird. Als Format
wird dabei xm l verwendet. Beachten Sie bitte, dass ein aktiviertes Revisionslog die
Performance des moc-Servers erheblich beeinträchtigt (verlangsamt den Server etwa
um 50 Prozent). Zur Sicherheit werden die Daten verschlüsselt in der Datenbank
gespeichert.
Tools
Unter Tools finden Sie Verknüpfungen zu vier nützlichen Helfern:
•
•
•
•
dem Datenbankmanager,
dem Boot Media Wizard,
dem Cryptor, der die Verschlüsselung von bspw.Kennwörtern ermöglicht,
dem Analyser, mit dessen Hilfe sich häufige Fehlermeldungen erklären lassen.
197
In diesem Kapitel:
• Fehlermeldungen—200
• Fehleranalyse—203
• baramundi Support—210
5
Hilfen zur Suite
Nun, nachdem die wesentlichen Bestandteile und Module der baramundi Management Suite behandelt wurden, soll das letzte Kapitel für weiterführende Hilfen,
häufige und daher bekannte Fehlerquellen sowie Hinweise zur Unterstützung im
Umgang mit unserer Software dienen.
Auch bei Softwaresysteme, wie dem unsrigen, kann es zu Fehlern kommen. Die
Problemfälle im Umgang mit der baramundi Management Suite sind in aller Regel
diese: Jobs werden auf den Zielsystemen nicht ausgeführt oder vorzeitig wegen
eines Fehlers abgebrochen. Zunächst stellen wir Ihnen Fehlerursachen vor, mit
denen das baramundi Consulting häufiger konfrontiert ist. Möglicherweise helfen
Ihnen diese Angaben, ein Problem schnell zu lösen.
Eine Hürde auf dem Weg zur Beseitigung von Fehlern ist es zunächst einmal deren
Ursächlichkeit zu lokalisieren. Daher wird in diesem Kapitel auch auf die Analyse
von Fehlern eingegangen. So bieten beispielsweise die Auswertung der Logdateien
oftmals erste Ansätze beim Aufspüren von Fehlern.
Ebenfalls Gegenstand der Betrachtung: Updates der baramundi Management Suite,
denn solche wird es – mit der weiteren Evolution der Suite – natürlich immer wieder
geben. Wie mit solchen Updates umzugehen ist und was dabei zu beachten werden
sollte, erfahren Sie in diesem Kapitel ebenso, wie Einzelheiten zum baramundi
Support.
Fehlermeldungen
In diesem Abschnitt möchten wir Ihnen häufig auftretende Fehler, soweit sie nicht
in anderen Kapiteln bereits abgehandelt wurden, vorstellen, und Ihnen bei dieser
Gelegenheit zugleich Hinweise auf deren Behebung geben.
Konfiguration
Etliche Probleme der Management Suite sind mit der Konfiguration verbunden.
Wir wollen Ihnen im Folgenden einige Fehler vorstellen.
«Could not connect to MOC»
1. Prüfen Sie, ob der angegebene Server der baramundi Management Server ist.
Wenn nicht, öffnen Sie eine m mc, fügen Sie das Snapin baramundi Management Suite hinzu und geben Sie im Verbindungskontext den richtigen Server
an. Kann die Verbindung nun erfolgreich aufgebaut werden, können Sie die
Konfiguration abspeichern.
2. Sind alle Dienste gestartet? Prüfen Sie den sql-Server und den baramundi
Management Object Connector.
3. Wurde bei einem Update auch die Konsole aktualisiert? Sie können dies
leicht prüfen, indem Sie die Version der aktuellen baramundi Management
Suite auf dem Server (Verwaltung/Server/Versionsinformation) mit der installierten Version der Konsole (C:\Programme\bsAG\bMS\bmc.dll) vergleichen.
Performanceprobleme
In einzelnen Fällen kann es vorkommen, dass sich der baramundi Management
Server träge verhält und langsam reagiert. Dies kann die im folgenden vorgestellten
zwei Ursachen haben:
1. Läuft der Microsoft sql-Server auf dem gleichen System, prüfen Sie bitte, ob
ausreichend physikalischer Speicher auf der Festplatte vorhanden ist. Möglicherweise ist eine Datenbankwartungsaufgabe nicht vollständig durchgelaufen und die ld f-Datei ist voll. Verkleinern Sie in diesem Fall die ld f-Datei
und prüfen Sie auch die Größe der Datenbank (m d f).
200 | Kapitel5: Hilfen zur Suite
2. Überprüfen Sie die Arbeitsspeicherauslastung der laufenden Prozesse. Am
einfachsten geht dies mit Hilfe des Taskmanagers. Prüfen Sie bitte den Object Connector (moc.exe). Nimmt sich dieser zuviel Speicher, starten Sie die
Dienste neu.
Der Database Manager findet die Datenbank nicht
Wenn der Datenbank Manager den s q l-Server nicht finden kann, handelt es sich
möglicherweise um eine instanzierte sql-Server-Installation. Bei s q l Server 2005
Express ist dies stets der Fall. Es kann aber auch bei sql Server 2000, 2005 und
2008 vorkommen. Geben Sie in einem solchen Fall den Namen des Datenbankservers gefolgt von einem Backslash und dem Instanznamen an; sql 2005 Express:
Servername\SQLExpress.
Advanced DIP Sync legt kein Logfile an
Wenn der Advanced dip Sync Dienst ordnungsgemäß installiert ist, aber dennoch
die Dateisynchronisation nicht protokolliert, also keine Logdatei auf dem dip-Server
zu finden ist, muss die Bibliothek bucoprotocolserver.dll registriert werden. Dazu
öffnen Sie ein Kommandozeilenfenster auf dem dip-Server und geben dort folgende
Befehlszeile ein:
Regsvr32 C:\Programme\bsag\Protocolserver\bucoprotocolserver.dll
Sonstiges
Abschließend möchten wir Ihnen noch einige Fehlerquellen außerhalb des Konfigurationsprozesses vorstellen. Auch diese Fehler sind beim Support oft nachgefragt
und schnell behoben.
Sicherheitskonfiguration zeigt keine Auswirkung
Wurde die Sicherheitskonfiguration ein/ausgeschaltet, so muss der baramoc neu
gestartet werden, damit die Änderungen wirksam werden.
Fehlermeldungen |
201
Änderung DIP-Sync-Konfiguration
Beachten Sie bitte beim Anlegen oder Bearbeiten von Objekten, die mit dem dip-Sync
in einem Zusammenhang stehen, dass das dip-Sync-Modul neu gestartet werden
muss.
Herunterfahren des baramundi Management Servers
Je nachdem, wie viele Sitzungen beim baramundi Management Server zum Zeitpunkt des Herunterfahrens geöffnet sind, kann es zu Verzögerungen wegen TimeOuts kommen. Generell versucht der baramundi Management Server beim Herunterfahren sämtliche Sitzungen zu beenden. Dies kann bei einer großen Anzahl
von ausstehenden/laufenden Jobs oder Jobzielen zu Verzögerungen führen.
Jobausführung funktioniert nicht
Sofern Jobs nicht wie gewünscht ausgeführt werden, so kann es dafür verschiedene
Ursachen geben. Ein Grund wäre zum Beispiel ein nicht gestarteter baramundi
Management Serverdienst. Überprüfen Sie hierfür das baramundi Management
Suite-Symbol im baramundi Management Center im Rootknoten. Hier muss ein
grüner Pfeil sichtbar sein. Ansonsten können eventuelle Fehlermeldungen im baramundi Log unter \\{Server}\bms$\Logs oder in der Ereignisanzeige eingesehen
werden.
Falls clientseitig Probleme auftreten, sollte zunächst die korrekte Kommunikation
vom Server zum Client und zurück überprüft werden. Funktioniert ein Ping vom
Server zum Client und zurück? Stimmt die Namensauflösung? Konnte der baramundi Management Agent aktualisiert werden? Fehlermeldungen hierzu finden
Sie in der Windows-Ereignisanzeige oder im bfcrx.log (%windir%\system32\).
Sind Netzwerkprobleme ausgeschlossen und sämtliche baramundi-Komponenten
weisen den selben Versionsstand auf, gehen Sie im baramundi Management Center jeden Schritt noch einmal durch und überprüfen Sie gegebenenfalls solche
Detaileinstellungen wie beispielsweise Jobintervalle, Gültigkeiten, automatische
Zuweisungen, Softwarekonfigurationen und so weiter.
Fehleranalyse
Wie bei manuellen Installationen, kann es auch in der automatisierten Softwareverteilung zu Fehlern kommen. Das bedeutet, Jobs werden auf den Zielsystemen nicht
ausgeführt oder vorzeitig wegen eines Fehlers abgebrochen. Ist solchen Fällen stehen Ihnen verschiedene Informationsquellen zur Verfügung. Die Fehlermeldungen,
die Ihnen bei der Analyse helfen, sind dabei in den meisten Fällen selbsterklärend,
sodass bereits die Meldung darüber informiert, warum und an welcher Stelle ein
bestimmter Fehler aufgetreten ist. Oft sind eine fehlerhafte Syntax in der Jobdefinition, fehlerhafte Installationsdateien oder fehlende Zugriffsrechte, eine falsche oder
fehlgeschlagene Namensauflösung oder auch Berechtigungsprobleme mit Freigaben
oder verwendeten Domänenkonten Ursache solcher Fehler. In aller Regel enthält
bereits die Fehlermeldung aussagekräftige Informationen über die Ursache eines
Fehlers. Sollten Sie einmal Schwierigkeiten bei der Fehleranalyse haben, hilft Ihnen
unser Support gerne weiter.
Register: Problemfälle
Schlägt die Ausführung eines Jobs fehl, so werden im Register Problemfälle alle
Zielsysteme als fehlerhaft aufgelistet, bei denen der Job nicht ordnungsgemäß
abgearbeitet werden konnte.
Abbildung 5–1: Register Problemfälle
Fehlermeldungen |
203
Das Register Problemfälle finden Sie in der html-Ansicht für alle Unterknoten der
Jobverwaltung und der Jobs selbst, sowie bei allen logischen Gruppierungen unter
dem Knoten Umgebung. Um Detailinformationen abzufragen, klicken Sie einmal
auf das Symbol links neben dem Jobnamen. Dadurch öffnen Sie ein Informationsfenster, das die zugehörigen Informationen beinhaltet.
Register: Log
Eine zusätzliche Informationsquelle zur Fehleranalyse stellt das Log dar. Das Register befindet sich in der htm l-Ansicht in allen Zielsystemen (Abb.5–2). Das Log gibt
darüber Auskunft, welche Aufgaben vom Server auf dem Zielsystem zuletzt bearbeitet wurden (auch erfolgreiche), in Verbindung mit welchem Modul die Aufgaben
in Zusammenhang stehen und in welchem Benutzerkontext sie ausgeführt werden
sollten. Der Zeitraum der dargestellten Meldungen, die Anzahl der dargestellten
Meldungen und einiges mehr ist im oberen Bereich der Seite einstellbar.
Abbildung 5–2: Register Log
Erreichbarkeit prüfen
Die Unerreichbarkeit eines Systems kann vielerlei Ursachen haben. Wenn Sie zum
Beispiel den baramundi Management Agent auf einem bereits installierten Windows XP-System mit Service Pack 2 und aktivierter Firewall installieren wollen,
so könnte das bereits deshalb nicht funktionieren, wenn die Firewall den Zugriff
verhindert. Dann nämlich ist auch ein Ping auf das Zielsystem normalerweise nicht
erfolgreich.
Betreiben Sie einen Windows 2003 Server in Ihrem Unternehmen, ist es möglich
diese Zielsysteme über die Domänenrichtlinien entsprechend konfigurieren. Steht
Ihnen diese Möglichkeit nicht zur Verfügung, so muss die Firewall manuell vorübergehend deaktiviert werden, damit der baramundi Management Agent installiert
werden kann. Andernfalls müssen Sie die Installation vor Ort manuell einleiten. Bei
der Installation des baramundi Management Agents werden alle benötigten Ports
in der Firewall eingetragen und entsprechend freigeschaltet, so dass die Firewall
danach wieder aktiviert werden kann.
Um die grundsätzliche Erreichbarkeit des Zielsystems zu
prüfen, können Sie einen Ping über das baramundi Management Center ausführen. Diese Möglichkeit steht Ihnen
sowohl im Aufgabenbereich (Abb.5–3) als auch über das
Kontextmenü zur Verfügung. Ist der Ping erfolgreich, ist
auch der Clientstatus ermittelbar. Dieser wird dann als
Symbol in der rechten unteren Ecke des Rechnersymbols
in der Konsolenstruktur angezeigt. Das funktioniert sowohl über den Aufgabenbereich als auch über das Kontextmenü.
Abbildung 5–3: Ping
Bisweilen kommt es auch vor, dass bei der Namensauflösung über d ns in der d ns-Datenbank ein veralteter Eintrag vorliegt. Wenn Sie
sich also sicher sind, dass das Zielsystem erreichbar sei, prüfen Sie über nslookup
(ausführbar über die Kommandozeile) die Aktualität des Eintrages und gleichen
Sie die IP-Adresse entsprechend ab. Informationen zu Mechanismen und Diagnosetechniken zur Namensauflösung (Netbios, wins, d ns, mac-Adressen, IP-Adressen)
entnehmen Sie Ihren Betriebssystem- Handbüchern oder den Dokumentationen zu
tc p/IP Netzwerken.
i
Beachten Sie, dass eine funktionierende Namensauflösung die Voraussetzung für alle Funktionalitäten der baramundi Management Suite darstellt.
Fehlermeldungen |
205
Abbildung 5–4: BMA.log
Logdateien
Sowohl auf den Zielsystemen, auf denen der baramundi Management Agent installiert ist, als auch auf dem baramundi Management Server werden standardgemäß
Logdateien über die Aktivitäten der einzelnen Komponenten beziehungsweise Module aufgezeichnet. Die Logdatei des baramundi Management Agents finden Sie im
Installationsordner. Für gewöhnlich liegt dieser unter C:\Programme\bsAG\bma.
Dort finden Sie eine Datei namens bma.log.
Es handelt sich dabei, wie bei anderen Logdateien auch, um eine Textdatei im
Klartext mit Datums- und Zeiteinträgen. Sie können diese Logdatei mit jedem
beliebigen Texteditor öffnen. Falls Sie sich die Logdatei eines Zielsystems ansehen möchten, können Sie diese bequem über das baramundi Management Center
herunterladen, indem Sie aus dem Aufgabenbereich des Zielsystems den Eintrag
Management Agent Log wählen. Zusätzlich steht Ihnen zu Analysezwecken noch
die Möglichkeit zur Verfügung, über die Funktion Explorer Drive C auf das Systemlaufwerk des Zielsystems zuzugreifen. Da auf dem Client für gewöhnlich nur
wenige Aktionen ausgeführt werden, ist diese Logdatei nur wenige Kilobyte groß.
Zusätzlich gibt es auf dem Server weitere Logdateien. Standardmäßig liegen diese
unter dem Pfad C:\Programme\bsAG\bms\Logs.
BMC - Datum.log
Die Logdatei des baramundi Management Center
MOC - Datum.log
Die Logdatei des baramundi Management Object Connector
BMS - Datum.log
Die Logdatei des baramundi Management Servers
Halten Sie diese Logdateien bereit, wenn Sie sich an unseren Support wenden möchten. Ihr zuständiger Bearbeiter teilt Ihnen bei Bedarf mit, welche Informationen er
aus den Logdateien benötigt.
bMS-Updates
Neue Versionen der baramundi Management Suite werden im baramundi Kundenforum (www.baramundi.de/forum) bereitgestellt. Jede neue Version – unabhängig,
ob es sich um einen Patch, ein Service-Pack, oder ein neues Release handelt – wird
in Form eines neuen Threads publiziert. Wenn Sie ein entsprechendes Abonnement
im Forum aktiviert haben, wird beim Erscheinen einer neuen Version automatisch
eine E-Mail generiert, die über das Update informiert.
Neue Versionen werden in der Regel mit zwei Downloadlinks publiziert:
• Als iso-Image, das mittels eines geeigneten Brennprogramms, wie zum Beispiel Nero, auf eine dvd gebrannt werden kann. Dieses iso-Image enthält
sämtliche Drittanbieterkomponenten, die Bestandteil des Auslieferungspaketes sind und für eine funktionierende Installation der baramundi Management Suite benötigt werden.
• Als Update-Distribution. Darin sind die Drittanbieterkomponenten nicht
enthalten. Um ein Update durchzuführen, ist diese Version ausreichend, da
die Drittanbieterkomponenten bei einem Update nicht aktualisiert werden
müssen.
Beide Setups können zum Update einer bestehenden Installation verwendet werden.
Zum Aktualisieren des Servers gehen Sie folgendermaßen vor:
1. Erstellen Sie ein Backup des baramundi Management Servers und der sq lDatenbank. Sichern Sie insbesondere manuell angepasste Dateien wie das
p xe-Bootimage, die startup.ini o.ä.
2. Beenden Sie den baramundi Management Server und den baramundi Management Object Connector.
3. Deinstallieren Sie die Vorgängerversion vollständig. Eine Updateinstallation
über das Setup wird nicht unterstützt!
4. Führen Sie das Setup (bms.exe) von der lokalen Konsole des Servers aus und
folgen Sie den Anweisungen auf dem Bildschirm.
Fehlermeldungen |
207
!
Während des Setups ist es möglich, dass Sie zum Neustart Ihres Systems
aufgefordert werden. Führen Sie diesen bitte unbedingt durch! Starten Sie
dann das Setup erneut, damit die noch fehlenden Komponenten installiert
werden können.
5. Beachten Sie die Besonderheiten beim Update, in RelNotes.pdf.
6. Starten Sie im Anschluss den Datenbankmanager und wählen Sie die Option Datenbank aktualisieren, um Ihre Datenbank gegebenenfalls auf den
aktuellsten Stand zu bringen.
7. Stellen Sie individuell angepasste Dateien, die Sie wie in Punkt1 beschrieben
gesichert haben, wieder her.
8. Aktualisieren Sie Relay Server, bmc und dip Sync Installationen.
9. Starten Sie den baramundi Management Server.
!
Nach der Serveraktualisierung muss nun der baramundi Management Agent aktualisiert werden.
Wird der Agent nicht aktualisiert, so kann dies zu fehlerhafter Jobausführung auf den Zielsystemen führen.
Ist die Einstellung Automatische Aktualisierung aktiviert (Knoten Verwaltung/Server/
Konfiguration/Grundeinstellungen/Eigenschaften—Management Agent) so wird der
bma auf einem Zielsystem in dem Moment aktualisiert, zu dem ein Job auf dem
Zielsystem ausgeführt werden soll. Dabei wird zuerst der vorhandene bma deinstalliert und danach der neue bma installiert. Wurde die automatische Aktualisierung
deaktiviert, so muss die Agentaktualisierung manuell gestartet werden. Dies kann
entweder über die h tm l-Ansicht des entsprechenden Clients geschehen oder aber
aus dem Kontextmenü (Rechtsklick) heraus, an einer übergeordneten logischen
Gruppierung. In diesem Fall werden sämtliche untergeordneten Zielsysteme aktualisiert.
Fehler: Serverdienst startet nicht mehr. Wurde in der Domänenkonfiguration ein verifizierbarer Benutzerkontext eingetragen? Der eingetragene Benutzer muss hinsichtlich
Benutzername und zugehörigem Kennwort aufgelöst werden können. In der Domänenkonfiguration sollte zumindest die Domäne angelegt sein, zu der der baramundi
Management Server gehört.
Überprüfen Sie, ob die erforderlichen Freigaben gesetzt worden sind und jeder Benutzer zumindest Leserechte auf Freigabe- und Verzeichnisebene erhielt. Außerdem
sollte keine Benutzerbegrenzung gesetzt sein.
• C:\Programme\bsAG\BMS, freigegeben als BMS$
• C:\Programme\bsAG\bms\dosComm, freigegeben als dosComm$
• C:\Programme\bsAG\bms\dosInst, freigegeben als dosInst$
Wurde vor dem Update auch die Vorgängerversion deinstalliert? Überprüfen Sie
ferner, ob die Lizenz abgelaufen ist. In diesem Fall sollte bei der Anmeldung an der
Konsole eine entsprechende Warnmeldung erscheinen.
Fehler: Agent lässt sich nicht aktualisieren oder kann nicht verteilt werden.
1. Stellen Sie sicher, dass auf dem Zielsystem keine Firewall aktiviert ist, die die
Agentinstallation behindert.
2. Hat der konfigurierte Administrationsbenutzer auf dem Zielsystem administrative Rechte?
3. Ist eventuell eine Firewall zwischen dem baramundi Server und dem Zielsystem, auf der die benötigten Ports nicht freigeschaltet sind?
a) Soll der Agent an einem Außenstandort aktualisiert werden, der nur
eine schmalbandige Anbindung an das Netz des baramundi Servers
hat, so kann es dazu kommen, dass der Server folgenden Fehler meldet:
Agent konnte nicht installiert/aktualisiert werden.
b) Sind sämtliche anderen Einstellungen korrekt, so liegt der Fehler möglicherweise daran, dass der Server nicht lange genug auf die Erfolgsmeldung des Zielsystems wartet, da die Übertragung der Installationsdateien zu viel Zeit beansprucht (TimeOut). In diesem Fall wird der
Agent aber dennoch erfolgreich installiert. Dies lässt sich in der h tm lAnsicht im Register Allgemein feststellen: Wird dort nach einiger Zeit die
korrekte Agentversion angezeigt, verlief die Aktualisierung erfolgreich.
c) Ein auszuführender Job, der den Aktualisierungsvorgang hervorrief,
wird nach dem TimeOut neu geplant (ca.15 Minuten später), da der Job
nicht zugewiesen werden konnte. Ist zu diesem Zeitpunkt die Agentaktualisierung bereits abgeschlossen, so wird der Job auch ausgeführt.
4. Prüfen Sie, ob im Agentlog (C:\Programme\bsAG\bMA\bma.log) der Pfad
zu den Installationsdateien richtig aufgelöst wird. Korrigieren Sie gegebenenfalls den Pfad über Verwaltung/Server/Konfiguration/Grundeinstellungen—
Eigenschaften/Management Agent/Installationskommando.
5. Es kann erforderlich sein, die Freigabe- und Sicherheitsberechtigung (unter
Windows) auf Jeder—Ausführen zu setzen.
Fehlermeldungen |
209
baramundi Support
Den baramundi Support erreichen Sie werktags von 9.00 bis 17.00 Uhr via E-Mail
an [email protected] oder telefonisch unter +49-821-56708500. Sofern Sie den
baramundi Support in Anspruch nehmen möchten, halten Sie die entsprechende
Fehlermeldung, am besten als Screenshot sowie die relevanten Abschnitte der
Logdateien bereit.
Darüber hinaus pflegen wir seit Jahren ein Anwenderforum im Internet und zwar
unter www.baramundi.de/forum, in welchem Entwickler und Anwender regelmäßig
Erfahrungen/Informationen austauschen. Ein Blick auf die dort bereit gestellten
Inhalte lohnt sich für gewöhnlich sehr.
In diesem Kapitel:
• Kommunikationsschema — II
• Skriptschema — III
• MSI-Fehlerwerte — IV
• baramundi Variablen — IX
Anhang
Nun, da die Bereiche der baramundi Management Suite in den vorigen Kapiteln
behandelt wurden, sollen anhänglich noch einige Themen aufgegriffen werden.
Zunächst eine Abbildung über das Zusammenspiel der Komponenten der baramundi Managemenet Suite-Kommunikation. Das Schema möge ein besseres Verständnis
bezüglich der Abläufe im baramundi Verwaltungsnetz verschaffen.
Mitunter ist der Anwender in den Fehlermeldungen mit m si-Fehlerwerten konfrontiert. Damit in einem solchen Falle nicht erst lange recherchiert werden muss, folgt
eine Auflistung dieser Fehlercodes und deren Bedeutung.
Die Benutzung von baramundi Variablen sind ein effizienter Weg zur Automatisierung von Verwaltungsaufgaben. Eine Aufzählung, Klassifizierung sowie ein kleines
Beispiel zum Thema, sollen in die Arbeit mit Variablen einführen.
Kommunikationsschema und Portbelegung
Abbildung 5–5: Kommunikationsschema
II | Anhang
Ablaufschema zur Skriptierung im Automation Studio
Abbildung 5–6: Skriptschema
Ablaufschema zur Skriptierung im Automation Studio |
III
Die MSI-Fehlerwerte und deren Bedeutung
Der Anwender sieht sich zuweilen mit m si-Fehlern konfrontiert. Um eine größere
Recherche zu vermeiden, seien diese nachfolgend aufgelistet*.
!
Die angegebenen Fehlerwerte sind Dezimalwerte; mitunter muss der Wert
aus dem Return-Code noch ermittelt werden: Dazu sind die unteren 16 Bits
der Fehlermeldung in einen Dezimalwert umzuwandeln.
Beispiel: 0x8007000D => 000D => 13 = ERROR_INVALID_DATA
ERROR_SUCCESS (Fehlerwert 0) Aktion wurde erfolgreich abgeschlossen (kein
Fehler).
ERROR_INVALID_DATA
(Fehlerwert 13) Die Daten sind ungültig.
ERROR_INVALID_PARAMETER (Fehlerwert 87) Einer der Parameter war ungültig.
ERROR_INSTALL_SERVICE_FAILURE Fehlerwert 1601 Kein Zugriff auf den Windows
Installer- Dienst. Wenden Sie sich an das Supportpersonal, um sicherzustellen, dass der Windows Installer-Dienst korrekt registriert wurde.
ERROR_INSTALL_USEREXIT (Fehlerwert 1602) Die Installation wurde vom Benutzer
abgebrochen.
ERROR_INSTALL_FAILURE (Fehlerwert 1603) Schwerwiegender Fehler bei der Instal-
lation.
ERROR_INSTALL_SUSPEND (Fehlerwert 1604) Installation angehalten, unvollständig.
ERROR_UNKNOWN_PRODUCT (Fehlercode 1605) Dieser Vorgang ist nur für Produkte
gültig, die zurzeit installiert sind.
ERROR_UNKNOWN_FEATURE (Fehlerwert 1606) Die Funktionskennung ist nicht
registriert.
ERROR_UNKNOWN_COMPONENT (Fehlerwert 1607) Die Komponentenkennung ist nicht
registriert.
ERROR_UNKNOWN_PROPERTY (Fehlerwert 1608) Unbekannte Eigenschaft.
*
Quelle: http://support.microsoft.com/kb/290158/de
IV | Anhang
ERROR_INVALID_HANDLE_STATE (Fehlerwert 1609) Der Handlezustand ist ungültig.
ERROR_BAD_CONFIGURATION (Fehlerwert 1610) Die Konfigurationsdaten für dieses
Produkt sind beschädigt. Wenden Sie sich an den Support.
ERROR_INDEX_ABSENT (Fehlerwert 1611) Der Kennzeichner der Komponente ist
nicht verfügbar.
ERROR_INSTALL_SOURCE_ABSENT (Fehlerwert 1612) Die Installationsquelle für dieses
Produkt ist nicht verfügbar. Stellen Sie sicher, dass die Quelle vorhanden ist
und Sie Zugriff darauf haben.
ERROR_INSTALL_PACKAGE_VERSION (Fehlerwert1613) Dieses Installationspaket
kann durch den Windows Installationsdienst nicht installiert werden. Sie
müssen zunächst ein Windows Service Pack mit einer neueren Version des
Windows-Installationsdienstes installieren.
ERROR_PRODUCT_UNINSTALLED (Fehlerwert 1614) Das Produkt wurde deinstalliert.
ERROR_BAD_QUERY_SYNTAX (Fehlerwert 1615) Die sql-Abfragesyntax ist ungültig
oder wird nicht unterstützt.
ERROR_INVALID_FIELD (Fehlerwert 1616) Das Eintragsfeld ist nicht vorhanden.
ERROR_INSTALL_ALREADY_RUNNING (Fehlerwert 1618) Es wird bereits anderweitig
eine Installation ausgeführt. Beenden Sie den anderen Installationsvorgang,
bevor Sie diese Installation fortsetzen.
ERROR_INSTALL_PACKAGE_OPEN_FAILED (Fehlerwert 1619) Dieses Installationspaket
konnte Nicht geöffnet werden. Stellen Sie sicher, dass das Paket vorhanden
ist und Sie darauf zugreifen können, oder wenden Sie sich an den Hersteller der Anwendung, um sicherzustellen, dass es sich um ein gültiges
Windows-Installationspaket handelt.
ERROR_INSTALL_PACKAGE_INVALID (Fehlerwert 1620) Dieses Installationspaket
konnte Nicht geöffnet werden. Wenden Sie sich an den Hersteller der
Anwendung, um sicherzustellen, dass es sich um ein gültiges WindowsInstallationspaket handelt.
ERROR_INSTALL_UI_FAILURE Fehlerwert 1621 Beim Starten der Benutzeroberfläche
des Windows-Installationsdienstes ist ein Fehler aufgetreten. Wenden Sie
sich an den Support.
Die MSI-Fehlerwerte und deren Bedeutung |
V
ERROR_INSTALL_LOG_FAILURE Fehlerwert 1622 Beim Öffnen der Datei des Installations-
protokolls ist ein Fehler aufgetreten. Stellen Sie sicher, dass das angegebene
Protokoll vorhanden ist und Sie in die Datei schreiben können.
ERROR_INSTALL_LANGUAGE_UNSUPPORTED (Fehlerwert 1623) Die Sprache dieses
Installationspakets wird von Ihrem System nicht unterstützt.
ERROR_INSTALL_TRANSFORM_FAILURE (Fehlerwert 1624) Fehler bei der Übernahme
der Transformationspakete. Stellen Sie sicher, dass die Transformationspfade gültig sind.
ERROR_INSTALL_PACKAGE_ REJECTED (Fehlerwert 1625) Systemrichtlinien verhin-
dern diese Installation. Wenden Sie sich an den Systemadministrator.
ERROR_FUNCTION_NOT_CALLED (Fehlerwert 1626) Die Funktion konnte nicht ausge-
führt werden.
ERROR_FUNCTION_FAILED (Fehlerwert 1627) Beim Ausführen der Funktion ist ein
Fehler aufgetreten.
ERROR_INVALID_TABLE (Fehlerwert 1628) Eine ungültige oder unbekannte Tabelle
wurde angegeben.
ERROR_DATATYPE_MISMATCH (Fehlerwert 1629) Die angegebenen Daten haben den
falschen Typ.
ERROR_UNSUPPORTED_TYPE (Fehlerwert 1630) Daten mit diesem Typ werden nicht
unterstützt.
ERROR_CREATE_FAILED (Fehlerwert 1631) Der Windows-Installationsdienst konnte
nicht gestartet werden.
ERROR_INSTALL_TEMP_UNWRITABLE (Fehlerwert 1632) Der Ordner für temporäre
Dateien ist entweder voll oder außerhalb des Zugriffs. Stellen Sie sicher,
dass der Ordner für temporäre Dateien vorhanden ist und dass Sie Schreibzugriff darauf haben.
ERROR_INSTALL_PLATFORM_UNSUPPORTED (Fehlerwert 1633) Dieses Installationspaket
wird von dieser Plattform nicht unterstützt.
ERROR_INSTALL_NOTUSED (Fehlerwert 1634) Komponente auf diesem Computer
nicht verwendet.
VI | Anhang
ERROR_PATCH_PACKAGE_OPEN_FAILED (Fehlerwert 1635) Das Patchpaket konnte
nicht geöffnet werden. Stellen Sie sicher, dass das Patchpaket vorhanden
ist und dass Sie darauf zugreifen können, oder wenden Sie sich an den
Hersteller, um sicherzustellen, dass es sich um ein gültiges Patchpaket für
den Windows-Installationsdienst handelt.
ERROR_PATCH_PACKAGE_INVALID (Fehlerwert 1636) Das Patchpaket konnte nicht
geöffnet werden. Wenden Sie sich an den Hersteller der Anwendung, um
sicherzustellen, dass es sich um ein gültiges Patchpaket für den WindowsInstallationsdienst handelt.
ERROR_PATCH_PACKAGE_UNSUPPORTED (Fehlerwert 1637) Dieses Patchpaket kann
vom Windows- Installationsdienst nicht verarbeitet werden. Sie müssen zunächst ein Windows Service Pack mit einer neueren Version des
Windows-Installationsdienstes installieren.
ERROR_PRODUCT_VERSION (Fehlerwert 1638) Eine andere Version des Produkts ist
bereits installiert. Die Installation dieser Version kann nicht fortgesetzt
werden. Verwenden Sie die Systemsteuerungsoption Software, um die
vorhandene Version dieses Produkts zu konfigurieren oder zu entfernen.
ERROR_INVALID_COMMAND_LINE (Fehlerwert 1639) Ungültiges Befehlszeilenargu-
ment. Ausführliche Befehlszeilenhilfe finden Sie im sdk des WindowsInstallationsprogramms.
ERROR_INSTALL_REMOTE_DISALLOWED (Fehlerwert 1640) Installation über eine
Terminal Server-Clientsitzung nicht zulässig für aktuellen Benutzer.
ERROR_SUCCESS_REBOOT_INITIATED (Fehlerwert 1641) Das Installationsprogramm
hat einen Neustart durchgeführt. Dieser Fehlercode steht in Windows
Installer Version1.0 nicht zur Verfügung.
ERROR_PATCH_TARGET_NOT_FOUND (Fehlerwert 1642) Das Upgradepatch kann
nicht vom Windows-Installationsdienst installiert werden, da das zu
aktualisierende Programm nicht vorhanden ist oder eine andere Version
des Programms mit dem Patch aktualisiert wird. Überprüfen Sie, ob das
zu aktualisierende Programm vorhanden ist und das richtige Updatepatch
verwendet wird. Dieser Fehlercode ist in Windows Installer Version1.0
nicht verfügbar.
Die MSI-Fehlerwerte und deren Bedeutung |
VII
ERROR_SUCCESS_REBOOT_REQUIRED (Fehlerwert 3010) Ein Neustart ist erforderlich,
um die Installation abzuschließen. Dies betrifft keine Installationsvorgänge,
bei denen die Aktion ForceReboot ausgeführt wird. Beachten Sie, dass
diese Fehlermeldung erst in einer zukünftigen Version des Installationsprogramms verfügbar ist.
VIII | Anhang
baramundi Variablen
Variablen sind eine Art Platzhalter für Eingaben, die keinen festen Wert, sondern
vielmehr eine Auswahl an Eingabemöglichkeiten definieren. In der Management
Suite werden Variablen stets in geschleiften Klammern, als in der Form {VARIABLE}
verwendet.
Je nach Anwendung lassen sich die Variablen für die baramundi Management Suite
in folgende Kategorien einteilen:
• Globale Variablen
– Servervariablen
– Clientvariablen
• Benutzerdefinierte Variablen
– Client
– Organisationseinheit
– ad s Benutzer oder Gruppe
– Hardwareprofil
– Software
– Komponente
– Patch Bulletin
– Job
Variablen lassen sich dann in baramundi Deploy Skripten, oder in der Jobverwaltung
sowie den Modulen Deploy und OS-Install – zumeist über die entsprechenden
Registerkarten – verwenden. Dabei gilt folgende Notation:
{Bereich.Kategorie.Name} für benutzerdefinierte baramundi Variablen,
{%Name%} für Windowsvariablen (in Prozentzeichen).
Globale Variablen
Globale Variablen werden durch das System selbst genutzt, sind durch das System
vorgegeben und nicht in der Datenbank aufgeführt. In aller Regel werden globale
Variablen in Verbindung mit baramundi Deploy Scripts benutzt. Andernfalls wird
es in der folgenden Übersicht erwähnt.
baramundi Variablen |
IX
Variable
Kategorie
Verwendung
Beschreibung
{Server}
Server
Deploy
IP-Adresse des Management-Servers
aus Sicht des Clients
{ServerHostname} Server
Deploy
Hostname des Management-Servers
{PrimaryServer}
Server
Deploy
Name des primären Management
Servers (bei mehreren Servern)
{DIP}
Server
Deploy, AgentInstallation
Vollständiger Pfad zum dip aus Sicht
des Clients
{Depot}
Server
Alias* für {DIP}
{Parent}
Client
Vollständiger Pfad zum dip aus Sicht
des Clients
{CDROM}
Client
Deploy
Pseudovariable; sofern im Installationskommando angegeben,
wird der Laufwerksbuchstabe
des CD-Laufwerks verwendet.†
(Keine Verwendung im baramundi
Development Skripten!)
{BMSPath}
Server,
Client
Deploy
Installationsverzeichnis der bms;
Pfad zu bms/bma
{BMAPath}
Client
Deploy
Installationsverzeichnis des Agents
auf dem Client
{HWProfile}
Client
Deploy
Harwareprofil des Clients
{InstallEngine
Client
Deploy
Name des Installationsmechnismus‡
{Script}
Client
Deploy
Alias von InstallEngineFile
{InstallTarget
Client
Deploy
Pfad des Zielverzeichnisses
File}
Path}
* Zumeist historisch begründeter Zweitname einer Variable.
† B e i s p i e l: Das Installationskommando einer Applikation sei
«{CDROM}\setup.exe», dann wird «D:\setup.exe» ausgeführt, wenn das
CD-ROM-Laufwerk des Clients durch «D:» gekennzeichnet ist.
‡ In den Applikationseigenschaften der im Register Installation/Mechanismus:
baramundi Deploy Package, baramundi Deploy Script usw.
X | Anhang
Variable
Kategorie
Verwendung
Beschreibung
{License}
Client
Deploy und
OS-Install
Lizenzschlüssel
{License}
Client
Deploy und
OS-Install
Lizenzschlüssel
{Company}
Server,
Client
Deploy
Name der lizenznehmenden Firma
{Username}
Client
Deploy
am Client aktuell angemeldeter
Windows-Benutzer
{GroupSDIPs}
Client
Deploy
Liste der dips einer Gruppe IPNetzwerke
{InstallUser
Client
OS-Install
Name des Installationsbenutzers*
(Keine Verwendung in baramundi
Development Skripten!)
Client
OS-Install
Passwort des Installationsbenutzers* (Keine Verwendung in
baramundi Development Skripten!)
Client
OS-Install
Account des Installationsbenutzers* (Keine Verwendung in
baramundi Development Skripten!)
{AdminUserName}
Client
OS-Install
Name des Administrators* (Keine
Verwendung in baramundi Development Skripten!)
{AdminUser
Client
OS-Install
Passwort des Administrators* (Keine
Client
OS-Install
Account des Administrators* (Keine
Name}
{InstallUser
Password}
{InstallUser
Account}
Password}
{AdminUser
Account}
{LCID}
Client
aktuelle eingestellte Sprache des
Clients als numerischer Code
* Wird während der Ausführung einer Betriebssysteminstallation bereitgestellt, um im Unattended File die benötigten Daten von Installations- und
Administrationsbenutzer zu integrieren.
XI
*
Variable
Kategorie
Verwendung
{LangID}
Client
{Domain}
Client
Domäne des Clients
{Client}
Client
Hostname des Clients
{Mashine}
Client
Alias von {Client}
{OSType}
Client
Betriebssystem des Clients*
{RegisteredUser} Client
Deploy
Name des registrierten Benutzers
{Client:IP}
Client
Deploy
Primäre IP-Adresse des Clients
{PrimaryIP}
Client
Deploy
Alias von {Client:IP}
{Client:MAC}
Client
Deploy
Primäre mac-Adresse des Clients
{PrimaryMAC}
Client
Deploy
Alias von {Client:MAC}
{Group}
Client
Deploy
Logische Gruppierung des Clients
{Architecture}
Client
Deploy
Hardwarearchitektur des Clients
(32-/64-Bit)
{Arch}
Client
Deploy
Alias von {Architecture}
{ServerPort}
Client
AgentInstallation
tcp/u dp-Port des Servers
Alias für {LCID}
DOS
Windows NT 4.0
Windows 2000
Windows XP
Windows XP, 64 Bit
Windows Server 2003
Windows Server 2003, 64 Bit
Windows Vista
Windows Vista, 64 Bit
Windows Server 2008
Windows Server 2008, 64 Bit
Windows 7
Windows 7, 64 Bit
Windows Server 2008 R2, 64 Bit
XII | Anhang
Beschreibung
:
:
:
:
:
:
:
:
:
:
:
:
:
:
DOS
NT4
W2000
XP
XP_x64
W2003
W2003_x64
Vista
Vista_x64
W2008
W2008_x64
Win7
Win7_x64
W2008_x64
Variable
Kategorie
Verwendung
Beschreibung
{ClientPort}
Client
AgentInstallation
tcp/u dp-Port des Clients
{AgentOptions}
Client
AgentInstallation
Agentoptionen: Numerisch kodierter Wert
OS-Install
Legt der Ausführung einer Betriebssysteminstallation das für
den Client eindeutige Verzeichnis
an, in welchem beispielsweise der
bms-Dateien für die Installation
abgelegt sind. (Die Variable existiert
nur, wenn das bDS im Rahmen eines
OS-Install-Jobs läuft!)
{UnattendedFile} Client
{BPMFolder}
Client
Patch Management
Pfad der Patchmanagement-Dateien
{ScanResult}
Client
Inventory
Ergebnis eines Patch-Scans
{UniqueClient
Client
OS-Install
Temporäre Dateiablage während
einer Betriebssysteminstallation
{OSTargetDrive}
Client
OS-Install
Laufwerk einer Betriebssysteminstallation
{ResponseFile}
Client
Deploy
Name der Antwortdatei nach der
Installation
Directory}
Benutzerdefinierte Variablen
Die Management Suite bietet zudem die Möglichkeit der Definition eigener Variablen. Je nach gegebenen Bereich, werden die so generierten Variable in den
Eigenschaftsdialogen des entsprechenden Objekts in der Registerkarte Variablen
geführt. Zur Veranschaulichung des Umgangs mit benutzerdefinierten Variablen,
sei hier ein sehr einfaches Beispiel gegeben:
Sämtliche Rechner eines Netzwerks sollen bestimmten Kostenstellen zugeordnet
werden, um Gerätegruppen identischer Kostenstellennummer in dynamischen
Gruppen zusammenzufassen und gemeinsam mit Jobs zu versehen.
XIII
Abbildung 5–7: Variable
Abbildung 5–8: Variable am Client
Definition der Variable
Zunächst muss eine entsprechende Variable angelegt werden. Dazu wählen Sie Verwaltung/Variable—Neu—Variable (Abb.5–7) und hinterlegen Sie in diesem Dialog
die gewünschten Angaben.
Im Beispiel handelt es sich um den Breich Client, da sich die Variable an den
Zielsystemen auswirkt. Kategorie und Name sind frei wählbar, in unserem Fall eben
Allgemein und Kostenstelle. Der Typ ist ein Begriff, also eine Zeichenkette.
Nach Abschluss der Eingaben steht die neue Variable nebst Kategorie in den Clienteigenschaften (Abb.5–8) zur Verfügung und kann mit Werten – im Beispiel B5-3 –
versehen werden.
Verwendung von benutzerdefinierten Variablen
Wird nun verschiedenen Zielsysteme über deren Eigenschaften im Register Variablen der Kostenstelle ein gleichlautender Wert zugeordnet, so können aus den
Clients, die diese Variable aufweisen, dynamische Gruppen gebildet werden.
Wählen Sie dazu Umgebung/Dynamische Gruppe—Neu—Dynamische Gruppe und
geben Sie dieser einen aussagekräftigen Namen (Alle Clients der Kostenstelle B5-3).
Im Auswahlschalter unter Bedingungen klicken Sie bitte Neue Bedingung hinzufügen
– im Ergebnis erscheint die seltsam anmutende Zeichenkette * = * in der Sie auf den
XIV | Anhang
Abbildung 5–9: Bedingung
Abbildung 5–10: Variable
ersten Ausdruck klicken und Benutzerdefinierte Variable—Allgemein—Kostenstelle
(Abb.5–9) wählen. Im rechten Ausdruck ist schließlich der Variablenwert zu hinterlegen (Abb.5–10), also B5-3.
Im Anschluss steht die neue dynamische Gruppe im gleichnamigen Knoten bereit;
auf sie können nunmehr Jobs verteilt werden.
XV
Index
Active Directory Benutzer&Gruppen,
41
Active Directory Synchronisierung, 191
Allgemeine Verwaltung, 174
Analyzer, 98
Application Usage Tracking, 130–136
Praxis, 132
Steuerung, 135
Wirkungsweise, 131
Applikationsintegration, 76
Applikationsüberwachung, 187
Arbeitsbereich, 14
Assets, 125–130
Anlage, 127
Ansichten, 129
bearbeiten, 128
Lager, 127
Typen, 126
Aufgabenbereich, 15
Aufzeichnungsmodus, 104
Automation Studio, 92
Automatische Jobzuweisung, 36
Backend, 1
Bandbreitenmanagement, 195
baramundi
Kiosk, 37
Kommunikationsschema, II
Management Agent, 45
Support, 210
Topologie, 1
Variablen, IX
BDX, 52
Beispiele
Benutzerbezogene Jobs, 32
Benutzerdefinierte Variablen, XIII
Hardwareprofile, 66
Jobverwaltung, 24
OS-Install, 69
Patch Management, 147
Personal Backup, 159
Sicherheitseinstellungen, 178
Softwareverteilung, 79
Benutzerbezogene Jobs, 25
Benutzereinstellungen, 28
Berichte, 50
Betriebssystemverteilung, 60
Black&White-Listen, 170
Boot Media Wizard, 58
Bootimage erstellen, 58
Bootumgebungen, 182
BPMdata.xml, 140
XVII
Bulletins, 142
Bundle-Integration, 77
Citrix Presentation Server, 83–90
Installation, 90
Konfiguration, 87
Live-Inventarisierung, 84
Rechtemanagement, 84
Servereinstellungen, 85
Client–Server–Interaktionen, 22
Clienterfassung, 6, 120
Clientüberwachung, 41
Crystal Reports, 5
Database Manager, 5
Daten sichern, 158
Datenaustausch, 52
Datenbankfehler, 201
Datenbankwartungsaufgaben, 193
Datenschutz (AUT), 130
Debugger, 106
Deploy, 74–82
Applikationsintegration, 76
Arbeitsweise, 74
Beispiel, 79
Bundle-Integration, 77
Softwareverteilung, 75
DIP-Server Synchronisierung, 189
Disaster Recovery, 150–154
Arbeitsweise, 150
Datenträgersicherung, 152
Datenträgerwiederherstellung, 153
Voraussetzungen, 151
Domänenkonfiguration, 179
Downloader, 172
Downloadjobs, 140, 194
Drag&Drop, 44
XVIII | INDEX
Dynamisch nachgeladene Benutzer,
28
Dynamische Gruppen, 40
Entsperrung, 49
Ereignisanzeige, 173
Erreichbarkeit, 205
Export, 52
Favoriten, 43
Fehleranalyse, 203
Fehlerliste (Automate), 104
Fehlermeldungen, 200
Freigabe- und Downloadmodus, 141
Frontend, 3
Getting Started, 6
GUI Aktion, 98
Gültigkeit, 21
Hardwareinventarisierung, 7, 115
Hardwareprofile, 65
Historie, 32
Import, 52
Installation der Suite, 3
Installationsmechanismen, 78
InstallShield Setup, 82
Inventarisierungsvorlagen, 120
Inventory, 115–124, 187
Clienterfassung, 120
Hardwareinventarisierung, 115
Inventarisierungsregeln, 122
Softwareinventarisierung, 120
WMI-Inventarisierung, 117
IP-Netzwerke, 181
Jobergebnisse, 23
Jobs (Definition), 20
Jobschritte, 17
Jobverwaltung, 15
Jobvoraussetzungen, 37
Jobvorbereitung, 60
Keine Logfile, 201
Kommunikationsschema, II
Komponenten anlegen, 64
Lock Manager, 173
Log (Register), 204
Logdateien, 206
Logische Gruppierung, 38
Management Center, 12
Matchpoints, 66
Microsoft Installer (MSI), 79
Modulzustände, 172
Monitoring, 42
MSI-Fehlerwerte, IV
Navigationsbaum, 13
Netzwerkumgebung, 41
OS-Install, 56–73
Beispiel, 69
Betriebssystemverteilung, 60
Hardwareprofile, 65
Komponentenanlage, 64
Treiberintegration, 62
Vorbereitungen, 57
Vorgehensweise, 56
Partitionierung von Festplatten, 69
Patch Management, 137–149, 184
Arbeitsweise, 138
Beispiel, 147
Freigaben, 141
Patches verteilen, 145
Patchkonfiguration, 140
Performanceprobleme, 200
Personal Backup, 154
Arbeitsweise, 154
Beispiel, 159
Datensicherung, 158
Sicherungen zurückspielen, 158
Sicherungsvorlagen, 156
Persönliche Einstellungen, 54
Preboot eXecution Environment (PXE),
56
Problemfälle (Register), 203
PXE-Unterstützung, 168
Rechtegruppen und -benutzer, 175
Recovery, 150, 187
Regelerstellung (Inventory), 122
Register ein- und ausblenden, 14
Reporting, 50
Reservierte Lizenzen, 196
Revisionslog, 196
Serververwaltung, 164–173
Ereignisanzeige, 173
Grundeinstellungen, 164
Konfiguration, 166
Lock Manager, 173
Modulzustände, 172
Versionsinformation, 173
Sicherheitsprofile, 175
Sicherung von Datenträgern, 152
Sicherungen zurückspielen, 158
Sicherungsvorlagen, 156
INDEX |
XIX
Skriptschema, III
Softwareinventarisierung, 120
Softwareverteilung, 8, 75
Statusleiste, 15
Suchkriterien, 103
Synchronisierungsjob, 26
Systemarchitektur, 1
Systemerfassung, 45, 46
Tools, 197
Treiberintegration, 62
Ubds, 31
Umgebung, 38
Updates, 207
User Settings, 28
Variablen, IX, 111, 183
benutzerdefiniert, XIII
global, IX
Versionsinformation, 173
Verwaltung der Suite, 163
Webserver, 167
Wiederherstellen von Datenträgern,
153
Windows Automated Installation Kit,
58
WMI-Inventarisierung, 117
wsusscn2.cab, 140
Zeitsteuerung von Jobs, 20
Zielsystemerfassung, 120
XX | INDEX

1 Einführung in die Suite

Transcription

Similar documents

PDF herunterladen

TuneUp Utilities 2011

CA IT Client Manager - CLI-Referenzhandbuch

genucenter Version 5.2 Release Notes

microsoft xp task manager softwaretools

Installationsanleitung

Leseprobe Windows XP - Die Expertentipps

JobScheduler: API - Software- und Organisations

Installation der Linux-Distribution Fedora

jobscheduler - Flipbeets.com

PO Box 80 · 86651 Monheim/Germany Phone: +49 9091 502

Check_MK für jedermann

BMC BladeLogic Server Automation 8.7: Foundation – Teil 2

Windows Registry - Windows XP für Senioren

Ingenium File-Manager - SEGNO Industrie Automation GmbH

WorkCentre M123/M128, WorkCentre Pro 123/128

Nero BackItUp

Mobile Device Management mit baramundi

Installations-Anleitung USB/RS485 Konverter für efector octavis