Columbus Software Deployment

Transkript

1 Columbus Software Deployment Benutzerhandbuch Modulversion 7.1 Stand: 12.11

2 Copyright Brainware Consulting & Development AG All rights reserved Das vorliegende Werk ist in all seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion, der Vervielfältigung auf fotomechanischem oder anderen Wegen und der Speicherung in elektronischen Medien. Ungeachtet der Sorgfalt, die auf die Erstellung von Text, Abbildungen und Programmen verwendet wurde, können weder Brainware Consulting & Development AG, noch Autor, Herausgeber oder Übersetzer für mögliche Fehler und deren Folgen eine juristische Verantwortung oder irgendeine Haftung übernehmen. Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. können auch ohne besondere Kennzeichnung Marken sein und als solche den gesetzlichen Bestimmungen unterliegen. Produktversion 7.1 Dokumentversion 02 Dokumenttitel Herstellung Druck und Verarbeitung Columbus Software Deployment - Benutzerhandbuch Brainware Consulting & Development AG Brainware Consulting & Development AG Veröffentlichungsdatum / 02 / deu Brainware Consulting & Development AG Sumpfstr. 15 CH-6300 Zug support@brainwaregroup.com / 02 / deu 2/114

3 Inhalt 0 Allgemeines Typografische Konventionen Hilfestellungen Lizenzierung Produktbeschreibung Einleitung Softwarepaketierung Columbus Softwareverteilung Vorteile von Columbus Software Deployment Funktionsweise Systemkomponenten Master Server Site Server Management Console Management Client Verwendete Begriffe OTB (Object Transfer Bus) SW-Paket Brainware.log Benutzeroberfläche PackageStudio Konzeptionelles Prozessbeispiel Rollen der Softwareverteilung Prozess der Softwareverteilung Umgebung Single Depot Depotstruktur Multiple Server Beispiel für einen Freigabeprozess Wichtige Hinweise Betriebliche Überlegungen Installation Basisinstallation Modulinstallation Konfiguration Umgebung bereitstellen Agent aktivieren und zuweisen Software Deployment Agent konfigurieren SW-Depot definieren / 02 / deu 3/114

4 Verbindungsparameter Netzwerk-Zugriff einstellen Verwendung von Checksummen SW-Pakete bereitstellen Aktualisierung durchführen Aktualisierung überprüfen Betrieb Pakete verwalten Pakete aktivieren Pakete verteilen SW-Pakete an Computer zuweisen Paket an Benutzer zuweisen SW-Pakete an Sites zuweisen Softwaregruppen Software-Gruppe erstellen/löschen Software einer Gruppe zuweisen Software-Gruppe zuweisen Software-Gruppe entziehen Vererbte Gruppen Gruppendefinitionen verteilen Distribute Software Groups SW-Pakete installieren Ersetzen von Dateien in Benutzung Variablen in der Konsole importieren Pakete erstellen PackageStudio konfigurieren Register General Register Tools Register Filters Register FileFilters Register Variables Register Package configuration defaults Register MSI wrapper Vorlage für die Paketdokumentation Einleitung Neues SW-Paket erstellen Before-Snapshot erstellen Applikation installieren After-Snapshot erstellen Paket generieren Fehler bei der Erstellung SW-Paket auf basierendem Snapshot erstellen PackageMaker verteilen Paket bearbeiten Symbolleisten Navigator Automatisierte Aktionen Hex-Werte konvertieren Variablen ersetzen Verknüpfungen verschieben Registrierungseinträge filtern / 02 / deu 4/114

5 INI-Dateien konvertieren Automatisierte Aktionen konfigurieren Manuelle Aktionen CheckFiles Paket dokumentieren Paket komprimieren Kommentarzeilen entfernen Paket installieren Zeilen austesten Kommandozeilenhilfe Paket testen Wrapper-Paket für MSI erstellen MSI-Datei auswählen Optionen festlegen Eigenschaften angeben Angeben von Reparaturoptionen Aufzunehmende Dateien auswählen Protokolloptionen festlegen SW-Paket Eigenschaften Assistent abschliessen Wichtige Hinweise Anhang Columbus SWDeploy Emergency Stop Client-Startparameter Software Shopping Software on Demand Software on Order Columbus Dynamic Config Einleitung Einrichtung und Konfiguration Konfigurationsparameter Reihenfolge der Auswertung Performanceauswirkungen Befehlszeilenprogramme Bandbreitensteuerung Columbus PackageMaker Optionen Generic Directories Value lists Text/Ini files Weitere Optionen Paketeigenschaften Filter Directory relocations Script-Vorlagen Konfigurationsdateien PkgMaker.cfg Default Package Verwendete Variablen in PackageMaker Variablen für Benutzer- und Computernamen Weitere Variablen Columbus PackageStudio Ausführen von Spezialaufgaben Bulk Actions (Massenaktionen) Ausführen von der Befehlszeile Run time Anforderungen / 02 / deu 5/114

6 7.3.3 Fehlende Snapshot.ini DuplicatesChecker Was ist Duplicate Checker DuplicatesChecker konfigurieren Automatisieren der Duplikatprüfung Auflösen von Konflikten ANSI oder Unicode / 02 / deu 6/114

7 Allgemeines 0 Allgemeines Es freut uns, dass Sie sich für Brainware und Columbus entschieden haben. Mit Columbus steht Ihnen ein mächtiges integriertes Software- und Lifecycle Management Werkzeug zur Verfügung mit dem Sie Routinearbeiten automatisieren, Transparenz im Betrieb fördern und Servicelevel verbessern können. Dieses Handbuch unterstützt Sie dabei, die vielfältigen Möglichkeiten von Columbus gewinnbringend in Ihrem Unternehmen einzusetzen. 0.1 Typografische Konventionen In diesem Handbuch werden verschiedene Formatierungen verwendet um bestimmte Begriffe und Aktionen hervorzuheben. Spezielle Hinweise und Tipps werden je nach Gewichtung mit einer anderen Hintergrundfarbe dargestellt. Formatierung Fette Schrift Kursivschrift Dreieck Symbol " " Spitze Klammer ">" Systemschrift GROSSBUCHSTABEN TASTE+TASTE Beschreibung Elemente in der Software oder im Betriebssystem, wie Menüpunkte, Buttons oder Elemente einer Auswahlliste Hervorhebungen (wichtige Details) und Verweise auf andere Kapitel oder Dokumente Schritt einer Handlungsanweisungen Befehlsmenüabläufe, z.b. Datei > Öffnen Verzeichnisse, Code- und Scriptbeispiele Tastenbezeichnungen, z.b. SHIFT, STRG, oder ALT Tastenkombinationen, bei welchen der Benutzer eine Taste gedrückt halten muss und eine weitere Taste drückt, z.b. STRG+P oder ALT+F4. Hinweis Wichtig Achtung Wird für Hinweise oder Tipps verwendet, welche die Arbeit erleichtern oder für zusätzliche Informationen die das Verständnis für das Produkt fördern. Informationen die der Benutzer beachten sollte da sonst Probleme oder Mehraufwand im Betrieb entstehen können. Informationen die der Benutzer beachten muss um Fehlfunktionen des Systems (Abstürze, Datenverluste, Systemausfall) zu verhindern. 0.2 Hilfestellungen Für zusätzliche Informationen und Unterstützung empfehlen wir unsere Website Hier finden Sie sämtliche Columbus Dokumentationen, eine Knowledgebase und ein Supportformular für Fragen an unsere Spezialisten / 02 / deu 7/114

8 Allgemeines Support Auf der Supportseite finden Sie den Link zur Knowledgebase, das Supportformular und Informationen zu unserem Kundendienst. Navigieren Sie in ihrem Browser zu und klicken Sie auf der rechten Seite auf Support. Beginnen Sie ihre Suche in der Knowledgebase wo die häufigsten Supportfälle aufgeführt sind. Falls Sie nicht fündig werden, können Sie das Supportformular für weiterführende Informationen benutzen. Beschreiben Sie ausführlich ihr Anliegen, damit ihnen unsere Spezialisten so rasch wie möglich helfen können. Klicken Sie auf Supportformular. Füllen Sie mindestens die mit * markierten Felder aus und klicken Sie auf Anfrage absenden. l Sie erhalten eine Bestätigung, dass ihre Anfrage im System aufgenommen wurde. Für telefonischen Kontakt finden Sie auf der Supportseite die entsprechenden Telefonnummern. Dokumentation Für die aktuellen Dokumentationen steht auf unserer Website ein eigener Downloadbereich zur Verfügung. Dieser enthält alle Handbücher im PDF und CHM Format in deutscher und englischer Sprache. Einige technische Handbücher sind derzeit nur in Englisch verfügbar. Navigieren Sie in ihrem Browser zu und wählen Sie auf der rechten Seite Downloads + Lizenzen. Klicken Sie auf Login, melden Sie sich mit ihrem Benutzernamen und Kennwort an und klicken Sie auf Anmelden. Wählen Sie beim Downloadtyp Dokumentation, das gewünschte Modul und klicken Sie dann auf Suchen. l Eine Übersicht aller zur Verfügung stehenden Dokumentationen wird angezeigt. Klicken Sie auf das gewünschte Format und Sprache, um die PDF/CHM-Datei in der jeweiligen Form zu downloaden. Den Acrobat Reader finden Sie auf der Supportseite oder direkt unter Hinweis Bei der Installation werden die Dokumente standardmässig in das Verzeichnis [C:\Program Files]\Columbus kopiert. Um die Konsolen-Hilfe in Deutsch anzuzeigen, muss im Unterverzeichnis \Console die Datei CMC_de.chm in CMC.chm umbenennt werden. Schulungsinformationen Brainware hat grosses Interesse daran, dass unsere Produkte und Lösungen fachgerecht, qualifiziert und sachgemäss eingesetzt und betrieben werden. Aus diesem Grund bieten wir eine Reihe verschiedener Kurse an. Sämtliche Informationen über Kursarten und Daten finden Sie unter dem Menüpunkt Kalender > Training / 02 / deu 8/114

9 Allgemeines 0.3 Lizenzierung Die Lizenzierung von Columbus erfolgt auf Basis der Anzahl Computer für die Columbus eine Leistung erbringt. Eine solche Leistung kann z.b. die Installation des Betriebssystems, die Inventarisierung oder die Verteilung von Software-Patches sein. Die vom Kunden gewünschte Leistung bestimmt wiederum die zu lizenzierenden Module. Eine Lizenz ist grundsätzlich an einen Computer gebunden, unabhängig davon ob die Lizenz nur einmalig oder kontinuierlich genutzt wird. Im Rahmen einer Ersatzbeschaffung ist jedoch die Übertragung auf einen neuen Computer möglich. Die Übernutzung der Lizenz ist nicht gestattet. Neben Computern ist Columbus in der Lage Daten von zusätzlichen Netzwerkgeräten (Router, Switches, Printer usw.) aufzunehmen welche als so genannte Not Managed Devices verwaltet werden. Diese Geräte erfordern keine Columbus Lizenz solange sie im Status Not Managed belassen werden, sind aber in der Anzahl auf maximal 200% der erworbenen Columbus Lizenzen begrenzt. Beispiel Ein Kunde betreibt ein Netzwerk mit 250 Computern und erwirbt hierfür eine entsprechende Lizenz von Columbus. In diesem Falle erlaubt das System die zusätzliche Erfassung von maximal 500 Not Managed Devices. Columbus verfügt über einen aktiven Lizenzcheck für alle Columbus-Module. Überschreitungen werden sowohl an der Konsole als auch in der Protokolldatei gemeldet. Eine Überschreitung führt zu einer Deaktivierung bestimmter Dienste und fordert den Benutzer der Konsole dazu auf die Datenbasis zu bereinigen oder Lizenzen zu beschaffen. Zusammenfassung Die Brainware Lizenzregeln beinhalten folgende Punkte: Jedes mit Columbus bediente Gerät, das aus Sicht Columbus eine Leistung erbracht hat, benötigt eine Lizenz. Die Übertragung der Lizenz auf ein anderes Gerät ist begrenzt auf Ersatzbeschaffungen. Die Anzahl der Geräte im Status Device not Managed ist auf 200% der erworbenen Lizenzmenge beschränkt. Die Anzahl der Geräte im Status Device status locked (entsprach unter Columbus 6 dem Status Inventory and OSDeploy) darf 110% der erworbenen Lizenzmenge nicht überschreiten. Bei einer Überschreitung der Lizenzmenge erscheint beim Start oder während der Arbeit mit der Konsole ein Hinweis, erlaubt die Konsole noch eine 10 minütige Arbeitssitzung (bei gravierender Überschreitung), verweigern alle Komponenten die Aufnahme weiterer Geräte. Wichtig Wird ein Gerät von Managed auf Not Managed gesetzt, löscht Columbus die zugehörigen Konfigurations- und Inventardaten. Eine Lizenz umfasst zeitlich unbegrenzt das nicht exklusive Nutzungsrecht der Software für die aktuelle Version einschliesslich sämtlicher Hotfixes für ein Jahr ab Rechnungsdatum / 02 / deu 9/114

10 Produktbeschreibung K A P I T E L 1 1 Produktbeschreibung In diesem Kapitel Einleitung Funktionsweise Benutzeroberfläche Dieses Kapitel gibt eine kurze Einführung in die Materie und beschreibt die Grundfunktionalität von Columbus Software Deployment. 1.1 Einleitung Softwareverteilung nennt man Prozesse zur Installation von Software auf Computern oder Servern in Betrieben. Viele Benutzer verfügen nicht über die notwendigen Kenntnisse oder Berechtigungen, um Software selbst zu installieren. Daher ist es in vielen Organisationen üblich, dass qualifizierte Mitarbeiter diese Aufgabe für die Benutzer erledigen. Bei einer grossen Anzahl von Computern und Applikationen ist es notwendig, diese Tätigkeit zu automatisieren. Ziel einer Softwareverteilung ist es, eine vollautomatische Erstinstallation, Konfiguration und Wartung einer grossen Anzahl von Computer mit minimalem Aufwand zu realisieren. Weiterhin muss ein störungsarmer und sicherer Betrieb der betreuten Umgebung erreicht werden. Häufig strebt man auch an, dass die Computer möglichst einheitlich mit Software ausgestattet werden. Als Nebeneffekt erhält man eine Kontrolle über die Ausnutzung der vorhandenen Softwarelizenzen. Bei der Softwareverteilung ist auch die Fähigkeit zur sauberen Deinstallation von Applikationen unverzichtbar. Wenn ein Benutzer z.b. seinen Job innerhalb des Unternehmens wechselt, braucht er unter Umständen nicht nur neue Software, sondern auch manche Applikationen nicht mehr. Diese müssen schon aus Gründen des Lizenzmanagements korrekt von seinem Computer entfernt werden. Bei wandernden Benutzern (Roaming) kann es sogar erforderlich sein, die Software zu Beginn einer Arbeitssitzung zu installieren und am Ende wieder zu entfernen. Softwareverteilung ist zudem mittlerweile nicht mehr nur eine zentral gesteuerte Aufgabe. Immer mehr Unternehmen gehen dazu über, den Benutzern über Shops die Möglichkeit zu geben, die benötigte Software selbst auszuwählen. Das erlaubt eine differenziertere Steuerung, wer welche Software erhält und führt in Verbindung mit klaren Kostenzuordnungen auch dazu, dass tendenziell weniger Lizenzen benötigt werden. Solche Shops, typischerweise über Web erreichbar, werden mehr und mehr zu einer Grundfunktionalität der Softwareverteilung. Warum paketieren Die Software-Pakete ermöglicht eine einfache, firmenweite Softwareverteilung auf jedem Computer. Bei der Paketerstellung wird die installierte Software an die Einstellungen und Standards einer Firma angepasst. Dies ermöglicht einheitlich konfigurierte Computer die den Support vereinfachen / 02 / deu 10/114

11 Produktbeschreibung Vorteile der Paketierung Software Managementsysteme wie Columbus werden hauptsächlich eingesetzt, damit die Installation und Wartung von Software in einer vernetzten Umgebung vereinfacht wird. Ein weiterer Grund ist die Schaffung modularer Umgebungen, in der für die Wartung sowohl vernetzter als auch eigenständiger Computer ähnliche Methoden eingesetzt werden können. Das bedeutet, dass Treiber und Anwendungen, nachdem sie einmal entwickelt und getestet wurden, in den verschiedensten Umgebungen mit einem minimalen Aufwand an Rekonstruktion wieder verwendet werden können. Dieser Prozess bringt folgende Vorteile mit sich: Reproduzierbare Ergebnisse ermöglichen eine einfache Fehleranalyse und -behebung. Fehlerminimierung bei der Softwareinstallation da keine Benutzereingabe nötig ist. Geringere Anforderungen an das Know-how der Support-Mitarbeiter. Benutzer können sich mit der System-Wiederherstellungsfunktion selber helfen Softwarepaketierung Auch wenn die Verteilung von Software eine etablierte Funktion ist, gibt es doch erhebliche Unterschiede in der Umsetzung. Das wohl am häufigsten diskutierte Thema ist dabei das Verfahren für die Erstellung von Software-Paketen. Ein Software-Paket ist eine Sammlung von Dateien welche eine Applikation automatisiert installiert und konfiguriert. Der klassische Ansatz zur Paketerstellung sind Snapshot-Verfahren, bei denen zunächst der Zustand eines Systems ermittelt wird, anschliessend eine Software installiert und danach der nun aktuelle Systemzustand ausgelesen wird. Durch den Vergleich der beiden Systemstatus lassen sich alle Änderungen ermitteln, die durch die Softwareinstallation durchgeführt wurden. Wenn diese Änderungen in Dateisystem und Registry in gleicher Form bei anderen Systemen durchgeführt werden, sollte dort im Ergebnis die Software ebenfalls lauffähig sein. Diese Snapshots haben sich bewährt. Dennoch gibt es alternative Ansätze. Ein Verfahren ist die Analyse einer Standardinstallation und deren Automatisierung. Anstelle dieses Ansatzes können Antwortdateien für die Automatisierung der Installation oft auch über dokumentierte Parameter erstellt werden. Die grösste Bedeutung haben in den letzten Jahren aber die MSI-Dateien erlangt. MSI steht für Microsoft Installer und ist ein Standardformat für Installationspakete. Diese MSI-Dateien können mit Hilfe von MSTs (Microsoft Transformations) angepasst werden. Sowohl die Erstellung von MSIs als auch von MSTs sind nicht trivial. MSIs und Snapshots schliessen sich dabei nicht aus. Auf Basis von Snapshots, also den Differenzinformationen von zwei Systemzuständen, lassen sich auch MSIs erstellen. MSI-Pakete können installiert werden, um auf Basis der Snapshots zu ermitteln, welche Änderungen tatsächlich vorgenommen werden und dafür ein spezielles Installationspaket zu erstellen. Für die Verwendung von MSIs spricht, dass es sich um ein Standardformat handelt. Software-Paket die auf Basis von Snapshots gebildet wurden, sind aber oftmals viel schlanker, weil sie nur die tatsächlich erforderlichen Änderungen enthalten. Damit kann die bei der Softwareverteilung entstehende Last massiv reduziert werden. Da es nicht das perfekte Verfahren gibt, sondern nur Verfahren, die für verschiedene Aufgabenstellungen besser geeignet sind, unterstützt Columbus sowohl Snapshots als auch MSIs. Tipp Die Erstellung und vor allem die Anpassung der Software-Paket für die jeweilige Umgebung kann unabhängig vom verwendeten Verfahren komplex werden und setzt Erfahrung voraus. Brainware bietet dazu kompetente Unterstützung. Beachten Sie das Kursangebot auf / 02 / deu 11/114

12 Produktbeschreibung Columbus Softwareverteilung Wichtig bei der Softwareverteilung ist eine Gesamtsicht, die von der Betriebssysteminstallation über die Verteilung von Paketen und dem Management von Patches bis zur Inventarisierung reicht. Isolierte Werkzeuge für einzelne Aufgabenstellungen würden zu schlecht integrierten, aufwändigen Lösungen für das Clientmanagement führen. Columbus ist eine umfassende Lifecycle Management Lösung mit einem hohen Integrationsgrad, deckt dabei aber die Kernfunktionen des Clientmanagements auf hohem Niveau ab, ist also z.b. in der Lage, Software auch in grossen, geografisch verteilten Netzwerken mit optimierter Ausnutzung der verfügbaren Bandbreiten zu verteilen. Dazu gehören optimierte Software-Pakete, die möglichst klein sind, ebenso wie eine effiziente Bandbreitensteuerung. Columbus ist die eine durch jahrelange Erfahrung und Sachkompetenz geprägte Lösung, die einerseits heute zur erforderlichen Verbesserung der Effizienz bei der Administration beiträgt und andererseits so angelegt ist, dass sie auch den ständig wachsenden Anforderungen an das Clientmanagement gerecht wird weil sie mit klaren Rollenmodellen für eine sichere, delegierte Administration arbeitet, weil sie Freigabeprozesse für Software-Pakete und Patches unterstützt und weil Themen wie das Lifecycle Management und das Assetmanagement schon heute durch das Produkt abgedeckt werden. Paketierung mit PackageMaker und PackageStudio Zusammen mit PackageStudio bildet PackageMaker das Columbus Paketierungssystem welches eine grosse Flexibilität und viele Optionen für die Paketerstellung bietet. PackageMaker besteht aus der ausführbaren Datei PkgMaker.exe und wendet das Verfahren der Aufzeichnung zweier Snapshots an. Ein Snapshot wird vor und ein anderer nach der Installation erstellt. PackageMaker vergleicht diese und erstellt das SW-Paket mit den nötigen Dateien und Scripts in der Columbus Scriptsprache mit der erforderlichen Verzeichnisstruktur. Columbus unterstützt verschiedene Paketformate. PackageMaker legt einen so genannten Wrapper (Hülle) um die Software-Pakete damit diese in der Konsole verarbeitet werden können. Hinweis Weitere Informationen zu PackageMaker finden Sie im Handbuch Columbus PackageMaker. In PackageStudio werden automatisierte Aktionen zur Verbesserung der SW-Pakete ausgeführt. Überflüssige und gefährliche Registry-Einträge werden mit konfigurierbaren Filtern entfernt. Alle festen Laufwerksbuchstaben, Pfadanweisungen, Benutzer- und Computernamen sowie Verknüpfungen werden durch Variablen ersetzt, um das SW-Paket flexibel zu halten. Des Weiteren können mit dem DuplicatesChecker Abhängigkeiten und Konflikte mit anderen Paketen überprüft werden. Vorteile von Columbus Software Deployment Columbus Software Deployment unterstützt alle handelsüblichen Paketformate wie MSI Original Hersteller Setuproutinen oder Snapshot. Notebook/Laptop, Desktop PC und Server Hardware, Microsoft Windows Betriebssystem ab Windows NT (Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista) / 02 / deu 12/114

13 Produktbeschreibung und Microsoft Terminal Server sowie die Citrix Metaframe Erweiterungen. Portable Columbus Software-Pakete können ohne Modifikationen auf den genannten Gerätetypen, Betriebssystemen und Plattformen eingesetzt werden. Auf jedem System, das mittels Software Deployment verwaltet wird, muss der Management Client installiert sein. Bei der praxisorientierten Softwareverteilung müssen viele Rahmenbedingungen berücksichtigt werden. Software Deployment bietet dafür viele Leistungsmerkmale wie z.b.: Verteilung über Netzwerk (LAN, WAN, MAN, Internet, VPN, DSL, ISDN, RAS, usw.) oder alternative Offline Medien wie CD-ROM, DVD Object Transfer Bus (OTB), IP basierte Kommunikation mit dynamischer Bandbreitenlimitierung Komprimierung und Chiffrierung LDAP Import/Synchronisation (NT4, Microsoft AD, Novell NDS) Versionierung und Update Management Trennung von Benutzer- und Maschinenteil während der Softwareinstallation Sprachunabhängigkeit Installation erfolgt im Hintergrund Der Benutzer benötigt keine Administratorenrechte Software on Demand (auf Seite 80) und Software on Order (auf Seite 81) 1.2 Funktionsweise Systemkomponenten Im Folgenden werden die Systemkomponenten und ihre Grundfunktionen erklärt, welche für ein funktionierendes Columbus Software Deployment nötig sind / 02 / deu 13/114

14 Produktbeschreibung Master Server Der Master Server, der auch die Columbus Datenbank enthält, ist das Herzstück eines Columbus Systems über das alle Komponenten miteinander kommunizieren. In der Columbus Datenbank werden alle benötigten Informationen gesammelt und stehen so auch für ein umfassendes Reporting zur Verfügung. Im Grundsatz beruht das Columbus System darauf, dass einerseits ein aktueller Zustand einer Device in der Datenbank gespeichert ist, andererseits über Zuweisung von Aufträgen (z.b. Software, Betriebssystem) ein neuer Zielzustand definiert wird der dann in Zusammenarbeit mit allen beteiligten Komponenten herbeigeführt wird. Als Datenbankbasis dient Firebird SQL, ein SQL Server der aus Sicht Funktion, Performance und Sicherheit höchsten Anforderungen genügt und neben Microsoft Plattformen auch verschiedenen UNIX und Linux Derivate unterstützt. Da Firebird ein OpenSource Spinoff der schon lange bekannten Interbase ist, fallen für das Datenbanksystem keine Lizenzkosten an. Site Server Der Columbus Site Server stellt jeweils für mehrere Agenten die Plattform für den Betrieb in einer bestimmten Lokation zur Verfügung. Alle Management Clients kommunizieren jeweils mit dem Site Server der wiederum mit dem zentralen Master Server kommuniziert. Diese klar strukturierte Kommunikation stellt eine vereinfachte Konfiguration von Routern und Firewalls dar und erlaubt klare Definition der nutzbaren Bandbreiten und zentraler Security. Da Columbus eine beliebige Menge solcher Site Server erlaubt, können diese auch in Niederlassungen eingesetzt werden, in denen der Zugriff von aussen (selbst im internen Firmennetz) aufgrund strenger Sicherheitsrichtlinien nicht möglich ist. Ein Site Server hat grundsätzlich immer die Möglichkeit die Funktionalität aller Module in Form von zu aktivierenden Agenten anzubieten. Welche Agenten schlussendlich auf einem jeweiligen Server aktiviert werden, hängt von den aktuellen Bedürfnissen des Standortes ab. Je nach Grösse der Umgebung kann es auch sinnvoll sein mehrere Site Server an einem Standort einzusetzen. Die Agenten die auf dem Site Server aktiviert werden verwalten zum Beispiel die lokalen Depots (Verzeichnisse) in welchen z.b. die Software-Pakete und Disk Images für die Betriebssysteminstallation enthalten. Management Console Das Verwaltungsinstrument von Columbus ist die Management Console (CMC). In der Konsole werden Daten eingesehen und Aufträge für die Computer vergeben. Zu diesem Zweck kommuniziert diese Komponente mit der Datenbank und trägt dort jegliche Änderungen ein. Da die Konsole bis auf wenige Spezialfunktionen nicht direkt mit Clients kommuniziert sondern nur via Datenbank, deren Veränderungen dann wiederum von den Infrastruktur Servern an die Clients weitergegeben werden entsteht eine hochskalierbare Umgebung in der auch die zu nutzenden Kommunikationswege und damit Router- und Firewall Konfigurationen klar definiert sind. Die Konsole kann sowohl zentral auf einem Server als auch auf einzelnen administrativen Clients installiert werden. Wichtig Die Management Console erlaubt den Zugriff auf vielerlei Funktionen inklusive dem kompletten Neuaufsetzen von Computern. Der Zugriff auf die Konsole und die Definition welchem Benutzer welche Funktionen zugestanden werden sollte deshalb gut durchdacht werden um Risiken einer Fehlbedienung zu minimieren / 02 / deu 14/114

15 Produktbeschreibung Management Client Die Management Client Komponente ist auf den Zielcomputern installiert und überprüft bei jedem Start oder je nach Konfiguration zu bestimmten Zeiten ob Aktionen zur Ausführung bereitstehen. Nach jeder Aktion erfolgt via Site Server eine Meldung des aktuellen Zustandes zurück an die Columbus Datenbank. Der Management Client kann über verschiedene Techniken die später in diesem Handbuch beschrieben sind auf einem Zielsystem installiert werden Verwendete Begriffe Im Folgenden werden einige Begriffe erklärt, die für das Verständnis der folgenden Kapitel wichtig sind. OTB (Object Transfer Bus) OTB ist ein optimiertes, IP basierendes Client/Server Protokoll und ermöglicht die sichere und kontrollierte Kommunikation bei einfacher Administration und Konfiguration. OTB bietet eine transparente Kompression, eine verschlüsselte Kommunikation und zentrale Bandbreitenkontrolle. NetBIOS Freigaben und lokale Datenbanktreiber sind nicht mehr notwendig. OTB erreicht eine Reduktion der zu übertragenden Datenmengen zwischen dem Management Client und Server um ca. 90%. OTB beinhaltet zusätzliche Caching Mechanismen welche auch die Anzahl der effektiven Datenbankanfragen reduziert und so die Leistungsfähigkeit von Netz und Datenbank erhöht. SW-Paket Ein SW-Paket ist eine Sammlung von Dateien welche eine Applikation automatisiert installiert und konfiguriert. Das Columbus SW-Paket wird durch die Datei Package.ini definiert. Ist diese Datei in einem Verzeichnis vorhanden ist, wird dieses von Columbus als SW-Paket erkannt. Ein Paket enthält einen Server-Teil im Verzeichnis \Server und einen Client- und User-Teil im Verzeichnis \Cache. Jeder Teil verfügt über eigene Verfahren für die Installation und Entfernung welche die entsprechenden Aktionen definieren. Zusätzlich sind zwei Scriptdateien Package.wms (Delivery-Script, Configuration-Script) im Stammverzeichnis und im Verzeichnis \Cache vorhanden. Diese enthalten die Befehle für die Installation des Pakets. Objekt Paketverzeichnis Server\ProgramFiles Cache Client User Package.wms History.log Info.rtf Package.ini Beschreibung Besteht aus Paketname und -version und setzt sich aus [Identifier]\[Version.Patch] zusammen. Enthält die benötigten Programmdateien. Dieses Verzeichnis wird im ServerAdd auf den Client kopiert und enthält die zur Installation benötigten Dateien. Enthält Computer spezifische Konfigurationen. Enthält Benutzer spezifische Konfigurationen Configuration-Script, Scriptdatei welche vom ServerAdd ins Cache-Verzeichnis kopiert wurde. Diese erstellt Registry-Einträge und kopiert die Programmdateien. Protokolldatei, besteht nur wenn der CRC Check aktiviert ist. Beschreibung über Inhalt und Zweck des SW-Pakets. Definitionsdatei für das SW-Paket. Definiert und identifiziert das SW-Paket und enthält wichtigen Angaben, wie z.b. Name, Identifier, Version / 02 / deu 15/114

16 Produktbeschreibung Objekt Package.wms Beschreibung Delivery-Script, Scriptdatei mit den Anweisungen für die Installation. Brainware.log Alle Columbus Komponenten führen eine zentrale Protokolldatei Brainware.log welche im Systemverzeichnis C:\Windows gespeichert wird. In dieser Datei werden sämtliche Aktionen protokolliert, welche vom Infrastruktur Server und Management Client ausgeführt werden. Der Inhalt der Datei wird regelmässig abgeschnitten (max. 2 MB) und kann in jedem gebräuchlichen Texteditor geöffnet werden / 02 / deu 16/114

17 Produktbeschreibung 1.3 Benutzeroberfläche PackageStudio In PackageStudio werden automatisierte Aktionen zur Verbesserung der SW-Pakete ausgeführt. Überflüssige und gefährliche Registry-Einträge werden mit konfigurierbaren Filtern entfernt. Alle festen Laufwerksbuchstaben, Pfadanweisungen, Benutzer- und Computernamen sowie Verknüpfungen werden durch Variablen ersetzt, um das SW-Paket flexibel zu halten. Des Weiteren können mit dem DuplicatesChecker Abhängigkeiten und Konflikte mit anderen Paketen überprüft werden. Benutzeroberfläche Die Oberfläche von PackageStudio besteht aus dem NavigationPanel auf der linken Seite und dem WorkPanel in der Mitte. Der Navigator führt Step-by-Step durch den Bereinigungsprozess und zeigt im mittleren Bereich die jeweiligen Detaildaten an / 02 / deu 17/114

18 Konzeptionelles K A P I T E L 2 2 Konzeptionelles In diesem Kapitel Prozessbeispiel Umgebung Wichtige Hinweise Prozessbeispiel Rollen der Softwareverteilung Beim Einsatz eines Softwareverteilsystems sind etliche Personen involviert. Typischerweise unterscheidet man die folgenden Rollen: Der Administrator betreibt, pflegt und konfiguriert das System. Die Anwender erhalten benötigte Anwendungen automatisch installiert und konfiguriert. Der Softwarehersteller liefert die Applikationen und das Setup Programm Der Paketierer verpackt das Setup Programm der Applikation in ein Paket des Softwareverteilsystems Ein Produktverantwortlicher legt für eine Applikation die Konfiguration und die Art der Installation fest. Der Support unterstützt bei Störungen oder Problemen den Anwender. Er erhält vom Administrator Informationen über die Konfiguration des Systems. Leitet Störungen nach Qualifikation zur Lösung an den Administrator weiter. Der Netzwerkbetreiber betreibt das Netzwerk, auf dem die Softwareverteilung stattfindet. Ist bei kleinen Organisationen oftmals identisch mit dem Administrator. Bei grossen Organisationen wird das Netzwerk fast immer unabhängig betrieben. Der Serverbetreiber betreibt die notwendigen Server. Ist bei kleinen Organisationen oftmals identisch mit dem Administrator. Bei grossen Organisationen werden Server meist unabhängig betrieben. Die Rollen sind nicht immer scharf voneinander trennbar. Auch können, oftmals bei kleineren Firmen und Organisationen, mehrere Rollen durch eine Person ausgefüllt werden / 02 / deu 18/114

19 Konzeptionelles Prozess der Softwareverteilung Die Applikationen werden nicht direkt auf den Computern der Benutzer installiert. Zuerst bringt der Paketierer diese in ein Standard-Paketformat, um eine einheitliche vollautomatisierte Verteilung und Installation zu gewährleisten. Die erstellten Pakete werden ausführlich getestet, bevor sie in der produktiven Umgebung auf Paket Servern zur Verteilung bereitgestellt werden. Ein Administrator weist über die Management Console die SW-Pakete den entsprechenden Zielcomputern zu. Auf den Computern werden die zugewiesenen SW-Pakete ohne Mitwirkung des Benutzers durch den Management Client installiert. 2.2 Umgebung Damit der Software Deployment Agent korrekt konfiguriert werden kann, müssen auf dem Infrastruktur Server wo der Agent laufen soll, gewisse Verzeichnisse bereitgestellt und mit einer Windows Freigabe zugänglich gemacht werden. Wir sprechen dann von einem Depot. Für die meisten Umgebungen ist das vom Setup erstellte Standardverzeichnis \OSDepot (Single Depot) ausreichend. Für komplexere Umgebungen und Anforderungen lässt sich dieses Verzeichnis auch funktionsbezogen aufteilen und strukturieren (Multiple Depots). Ein Agent unterstützt bis zu 10 unterschiedliche Verzeichnisse, welche sich auch auf verschiedenen Servern (Multiple Server) befinden können / 02 / deu 19/114

20 Konzeptionelles Single Depot Tipp Wir empfehlen, mit nur einem Verzeichnis zu beginnen. Dies erleichtert die Erstkonfiguration da im Agent auch nur ein Verzeichnis konfiguriert werden muss. Verzeichnis \OSDepot Beschreibung Basisverzeichnis für die Ablage der SW-Pakete Depotstruktur In grösseren Firmen sind oft unterschiedliche Personen in den SW-Paket-Freigabeprozess involviert. Je nach Aufgabe sind auch nur einzelne Personen für bestimmte Funktionen autorisiert oder die Ablage der SW-Pakete physikalisch getrennt. Dies ist vor allem dann nützlich, wenn aus Sicherheitsüberlegungen getrennte Entwicklungs-, Test- und Produktivumgebungen aufgebaut werden. Beispiel für eine mögliche Aufteilung der Depotstruktur: Verzeichnis \SWDepot...\Development...\QA...\Pilot...\Production Beschreibung Standardverzeichnis für die Ablage der Pakete. Wird vom Setup eingerichtet. Verzeichnis indem Pakete erstellt und bearbeitet werden. Nach Fertigstellung und ersten erfolgreichen Tests durch den Entwickler, werden diese ins Verzeichnis \QA verschoben. Häufig will man unfertige Pakete gar nicht auf einem produktiven Infrastruktur Server haben und lagert diese daher gänzlich auf ein Testsystem aus. Das entspricht dann einem Mischbetrieb aus Multiple Depot und Multiple Server. Verzeichnis in dem zu testende Pakete gespeichert werden. Erst nach erfolgreichem Systemtest werden diese in ein produktives Verzeichnis (\Pilot oder \Production) verschoben. Eigenes Verzeichnis in der Produktionsumgebung für neue Pakete nach bestandenem Systemtest. Diese Pakete können z.b. nur für bestimmte Pilotsysteme bereitgestellt und nach erfolgreichem Betrieb ins Verzeichnis \Production verschoben werden. Für alle im Einsatz verfügbaren Pakete. Nur dieses Verzeichnis wird in der produktiven Umgebung beim Agent konfiguriert, damit nur diese Pakete verteilt werden. Nur Pakete in diesem Verzeichnis werden auf weitere Infrastruktur Server repliziert Multiple Server Anstatt das SW-Paket-Depot in verschiedene Unterverzeichnisse zu unterteilen, können für die unterschiedlichen Funktionen auch verschiedene Depot-Server verwendet werden. In diesem Fall empfehlen wir einen zentralen Download-Server, einen Test-Server und die produktiven Infrastruktur Server. Auf diesen Servern wird dann nur ein Single Depot benötigt. Möglich und häufig auch sinnvoll ist ein Mischbetrieb aus Multiple Depot und Multiple Server Betrieb / 02 / deu 20/114

21 Konzeptionelles Beispiel für einen Freigabeprozess Folgende Aufgabenverteilung ist dabei vorstellbar: Die SW-Paketentwickler speichern die neu erstellten SW-Pakete im Verzeichnis \Development und bearbeiten Sie dort. Sobald die SW-Pakete fertig gestellt sind werden Sie ans QA-Team weitergeleitet. Bestimmte Mitarbeiter kontrollieren nun die SW-Pakete auf formale und technische Aspekte und stellen die Funktionstüchtigkeit und Korrektheit der Benutzerkonfiguration sicher. Erst nach erfolgreichem Testdurchlauf wird ein SW-Paket in die produktive Umgebung verschoben, wo die Administratoren die SW-Pakete verteilen können. 2.3 Wichtige Hinweise Im Folgenden erhalten Sie einige Tipps aus der Praxis, wie Sie am besten mit diesem System loslegen und was Sie dabei beachten müssen Betriebliche Überlegungen Automatisieren Sie das Einlesen neuer Software-Pakete, indem sie ein wiederkehrendes Intervall konfigurieren. Beachten Sie, dass die SW-Depots frisch eingelesen sind bevor sich am Morgen die Benutzer anmelden. Falls SW-Pakete auf externe Site Server repliziert werden, muss auf diesen Servern ein Refresh nach Abschluss der Replikation stattfinden, damit die neuen SW-Pakete vor Ort zur Verfügung stehen. Dieser Schritt kann bei der Nutzung von Columbus Replication automatisch durchgeführt werden. Wenn Sie mit automatischen Gruppen oder Patch-Paketen arbeiten, werden die SW-Pakete nach einem Refresh des SW-Depots automatisch zugewiesen und installiert. Stellen Sie sicher, dass die SW-Pakete vor einer generellen Verteilung unbedingt auf einigen Test- und Pilotsystemen getestet worden sind / 02 / deu 21/114

22 Installation K A P I T E L 3 3 Installation In diesem Kapitel Basisinstallation Modulinstallation Eine Beschreibung der notwendigen Voraussetzungen und Schritte für eine erfolgreiche Installation des Columbus Basis Systems finden Sie im Handbuch Installation. Dieses Kapitel beschreibt nur die Besonderheiten der Software Deployment Installation. 3.1 Basisinstallation Für die Installation benötigen Sie die Setupdatei Columbus 7.1.exe und die Lizenzdatei License.xml. Diese Dateien erhalten Sie auf unserer Website > Downloads und Lizenzen. Jedes Modul benötigt verschiedene Columbus Komponenten die bei der Installation zur Auswahl stehen. Die folgenden Komponenten müssen für jedes Columbus System mindestens einmal im Netzwerk installiert werden. Komponente Beschreibung Database Server Der Datenbank Server wird benötigt, damit die Applikationen auf die Daten zugreifen können. Die Columbus Datenbank besteht aus zwei Datenbankdateien und speichert alle benötigten für die Verwaltung der Computer. Infrastructure Server Der Infrastruktur Server stellt verschiedene Agenten für die Verwaltung des Columbus Systems zur Verfügung. Es muss mindestens ein Infrastruktur Server eingerichtet werden. Dieser kann auch zusammen mit dem Datenbank Server auf einem Computer installiert sein / 02 / deu 22/114

23 Installation Komponente Management Console Beschreibung Mit der Management Console wird das Columbus System unternehmensweit verwaltet. Die Konsole kann sowohl auf einem Server als auch auf einer Workstation installiert sein. Hinweis Wir empfehlen die Konsole auf dem zentralen Datenbank Server zu installieren und konfigurieren und von dort aus über Kopieren des Verzeichnisses oder ein Software-Paket auf weitere Computer zu verteilen. 3.2 Modulinstallation Für die Installation von Software Deployment werden die zusätzlichen Komponenten benötigt. Komponenten Software Deploy Beschreibung > Software Depot Verzeichnis für die Speicherung von Software Paketen. Je nach installierten Optionen enthält dieses Verzeichnis das Client Update Paket, RemotelyAnywhere Pakete und ein Paket für den InventoryScanner. > Packaging Tools (Optional) Tools zum Erstellen und Bearbeiten von Software-Paketen. Gerade auf Testsystemen wird auch diese Option auf dem Server installiert und von diesem gestartet. Bei produktiven Servern werden diese Komponenten zumeist auf Arbeitsplatzcomputern installiert. > OS Depot Job Wenn auf diesem Server ein OSDepot installiert ist, oder installiert werden soll, wählen Sie auch die Option OS Depot Job an. Dann wird dort ein Job hinzugefügt, welcher den Client beim OSDeploy mitinstalliert. Management Client Dieser Agent muss auf allen Computern installiert sein, wenn Sie den Scanner über das Paket oder einen Job verteilen wollen. Die weitere Verteilung des Client kann über die Funktion Client Rollout in der Konsole wahrgenommen werden / 02 / deu 23/114

24 Konfiguration K A P I T E L 4 4 Konfiguration In diesem Kapitel Umgebung bereitstellen Agent aktivieren und zuweisen Software Deployment Agent konfigurieren SW-Pakete bereitstellen Dieses Kapitel beschreibt die notwendigen Konfigurationsschritte, um SWDeploy zu betreiben. Die Konfiguration setzt sich aus folgenden Arbeitsschritten zusammen: Umgebung bereitstellen (auf Seite 24) Software Deployment Agent aktivieren und zuweisen (siehe Seite 24) Software Deployment Agent konfigurieren SW-Pakete bereitstellen (auf Seite 28) Preboot Services Agent konfigurieren 4.1 Umgebung bereitstellen Damit der Software Deployment Agent korrekt konfiguriert werden kann, müssen auf dem Infrastruktur Server wo der Agent laufen soll, gewisse Verzeichnisse bereitgestellt und mit einer Windows Freigabe zugänglich gemacht werden. Wir sprechen dann von einem Depot. Hinweis In diesem Kapitel wird der Ablauf anhand der Depotstruktur im Kapitel Konzept (siehe "Depotstruktur" auf Seite 20) beschrieben. So erstellen Sie eine Umgebung Wechseln Sie im Explorer in das vom Setup erstellte Standardverzeichnis \OSDepot. Erstellen Sie die Unterverzeichnisse \Development, \QA, \Pilot und \Production. 4.2 Agent aktivieren und zuweisen Bevor ein Agent genutzt werden kann, muss dieser einer Firma zugewiesen und aktiviert werden. Mit der Aktivierung wird ein Agent vom entsprechenden Infrastruktur Server geladen und seine Funktion eingeschaltet. Der Agent lädt danach die Standardkonfiguration und nimmt seinen Dienst auf. So aktivieren Sie den Agenten Wechseln Sie in der Konsole in die Ansicht Infrastructure und markieren Sie den Infrastruktur Server. l In der Liste unterhalb erscheinen alle auf diesem Server verfügbaren Agenten. Markieren Sie den Software Deployment Agent. l In der RibbonBar werden alle zur Verfügung stehenden Funktionen angezeigt / 02 / deu 24/114

25 Konfiguration Wählen Sie im Menüfeld General die Funktion Assign. Wählen Sie aus dem Listenfeld die Firma und klicken Sie auf Apply. l In der Liste wird vor dem Software Deployment Agent die zugehörige Firma in der Spalte Company eingeblendet. Wählen Sie dann in der RibbonBar die Funktion Activate. l In der Tabellenübersicht wechselt in der ersten Spalte das Agent aktiviert worden ist. -Icon und zeigt an, dass der l Es kann bis zu 5 Minuten dauern, bis sich der Agent bei der Datenbank meldet. In der Spalte Last Contact wird anschliessend Datum und Uhrzeit der letzten Verbindung protokolliert. Um festzulegen für welche Teile der Organisation der Agent seine Dienste anbieten soll, muss eine funktionale Zuweisung per Drag&Drop im Strukturbaum erfolgen. So weisen Sie den Agenten einer Firma oder Site zu Markieren Sie den Software Deployment Agent. Ziehen Sie den Agent per Drag&Drop auf eine Firma oder Site im Strukturbaum. Der Agent wird nach einer solchen Aktion seine Funktion für die entsprechende Site und alle darunter liegenden Sites (Vererbung) anbieten. Eine solche Vererbung kann unterbrochen werden, indem in einer tieferen Stufe wieder ein anderer Agent zugewiesen wird. Der aktuell zuständige Agent für eine Site ist jeweils in der Konsole über das Site Management ersichtlich. 4.3 Software Deployment Agent konfigurieren Nachdem der Agent aktiviert und einer funktionalen Einheit zugewiesen ist, kann dieser nun konfiguriert werden. So konfigurieren Sie den Agenten Markieren Sie den Agent in der Ansicht Infrastructure. Wählen Sie in der RibbonBar die Funktion Configure / 02 / deu 25/114

26 Konfiguration SW-Depot definieren In diesem Dialogfenster wird definiert, in welchem Verzeichnis der Agent nach vorhandenen Software-Paketen suchen soll. Auch bei der Paketerstellung wird das SW-Paket in diesem Verzeichnis gespeichert. Wählen Sie eine JobID aus und geben Sie im Feld Source den Pfad zum Basisverzeichnis \SWDepot an. l Der Pfad kann manuell eingegeben oder über den l -Button gesucht werden. Feld Job # Source Beschreibung Für jedes zu scannende Verzeichnis wird eine eigene ID (0-9) verwendet. Für Verzeichnisse auf anderen Servern wird die UNC-Notation (\\servername\freigabe\verzeichnis) benötigt. Die notwendigen Verbindungsparameter werden über Access Parameters (siehe "Verbindungsparameter" auf Seite 26) erfasst. Hinweis Befindet sich das Depot auf dem gleichen Server sind keine Verbindungsparameter erforderlich. Verbindungsparameter Falls sich ein angegebenes Verzeichnis auf einem anderen Datenserver befindet als der Agent, wird Columbus als Standard die gleichen Verbindungsinformationen verwenden wie oben. Falls anderen Verbindungsinformationen notwendig sind, deaktivieren Sie Use the same account to access the network" und geben die entsprechenden Informationen ein. Feld Domain User / Password Beschreibung Domänenname Benutzername und Passwort des Benutzers / 02 / deu 26/114

27 Konfiguration Netzwerk-Zugriff einstellen In der Regel greift der Agent mit dem angegebenen Account oder als Systembenutzer auf das als SW-Depot konfigurierte Verzeichnis zu. Wenn sich aber z.b. das Verzeichnis auf einem Novell Netware oder Linux Server befindet, muss für den Netzwerkzugriff ein anderer Account angegeben werden, als für die lokale Windowsanmeldung. Markieren Sie die Option Use the same account to access the network und klicken Sie auf Apply. - oder - Deaktivieren Sie die Checkbox und definieren Sie den Account für den Netzwerkzugriff / 02 / deu 27/114

28 Konfiguration Verwendung von Checksummen Jedes Paket besitzt zur Kontrolle eine Checksumme (CRC). Columbus bietet die Möglichkeit, bei inkorrekter CRC-Information das SW-Paket zu deaktivieren. Solche Pakete und Patches werden dadurch von einer Verteilung ausgeschlossen, sobald eine unautorisierte Dateimanipulation stattgefunden hat. Tipp In einer Testumgebung empfehlen wir, diese Optionen zu deaktivieren, damit nicht nach jeder Korrektur die Checksumme neu berechnet wird. Markieren Sie die Optionen und klicken Sie auf Next. Option Deactivate packages with wrong CRC Deactivate packages without CRC information Deactivate packages with old version of CRC Beschreibung Software-Pakete mit einer falschen CRC-Summe werden deaktiviert. Software-Pakete mit einer fehlenden CRC-Information werden deaktiviert. Software-Pakete mit einer alten CRC Summe (Columbus 3.5) werden deaktiviert. -Icon dar- Pakete mit inkorrekter CRC-Information werden in der Softwareliste mit einem gestellt. Icon Beschreibung CRC Checksumme des Pakets ist korrekt CRC Checksumme des Pakets fehlt oder ist falsch Warnung alte CRC Checksumme 4.4 SW-Pakete bereitstellen Nach jedem Hinzufügen von Paketen zum SW-Depot sowie bei Modifikationen an den Paketdefinitionen muss der entsprechende Agent eine Aktualisierung durchführen. Dabei wird das Depotverzeichnis gescannt und neu eingelesen und alle Änderungen in die Datenbank übernommen. Erst dann stehen die Pakete für eine Verteilung bereit / 02 / deu 28/114

29 Konfiguration Aktualisierung durchführen Markieren Sie den Software Deployment Agent in der Ansicht Infrastructure. Wählen Sie in der RibbonBar die Funktion Schedule. Wählen Sie zwischen sofortiger Ausführung und einer Ausführung zu geplantem Datum/Uhrzeit mit eventueller Wiederholung. Bei geplantem Event tragen Sie das Datum und die Startzeit für die erste Aktualisierung ein. Markieren Sie bei Bedarf die Option Repeat action für eine regelmässige Aktualisierung und wählen Sie den gewünschten Zeitabstand. Klicken Sie auf OK. Hinweis Wenn bereits ein regelmässiges Aktualisierungsintervall konfiguriert ist, können Sie jederzeit eine zusätzliche einmalige Aktualisierung durchführen. Das wiederkehrende Intervall wird dadurch nicht überschrieben / 02 / deu 29/114

30 Konfiguration Aktualisierung überprüfen Markieren Sie den Software Deployment Agent in der Ansicht Infrastructure. Wechseln Sie in das Register Scheduled Actions. l Jede geplante Aktion wird in der Liste aufgeführt. Objekt Name Action Timer Repeat Beschreibung Name des Infrastruktur Server auf dem der Agent installiert ist. swrefresh, aktualisiert die Softwareliste wann die Aktion ausgeführt wird, in welchem Intervall die Aktion ausgeführt wird Scheduled By und wer die Aktion konfiguriert hat. Ist eine Aktion nicht erfolgreich, verbleibt diese in der Action Queue und wird vom Infrastruktur Server gemäss dem üblichen fünfminütigen Intervall so lange wiederholt, bis sie erfolgreich abgeschlossen wird. Dies kann der Fall sein, wenn z.b. der Datenpfad oder die Verbindungsparameter falsch konfiguriert wurden. Wenn Sie eine wiederkehrende Aktualisierung löschen wollen, dann Markieren Sie die Aktion und wählen im Kontextmenü Delete Selected Action(s) / 02 / deu 30/114

31 Betrieb K A P I T E L 5 5 Betrieb In diesem Kapitel Pakete verwalten Pakete aktivieren Pakete verteilen Softwaregruppen SW-Pakete installieren Variablen in der Konsole importieren Dieses Kapitel beschreibt die grundlegenden Funktionen, um ein Software Deployment System zu betreiben. Das Software Deployment System ist jetzt vollständig installiert und konfiguriert, es fehlen aber immer noch die zu verwaltenden Computer. Bevor diese mit Columbus verwaltet und SW-Pakete installiert werden können, muss der Computer in der Management Console erfasst, der Management Client konfiguriert und auf dem Computer installiert und gestartet sein. Das Handbuch Columbus Grundlagen beschreibt im Abschnitt Computer Objekte einbinden die Einrichtung und Erfassung von Computer-Objekten / 02 / deu 31/114

32 Betrieb 5.1 Pakete verwalten Die Verwaltung der Software-Pakete erfolgt in der Infrastructure Ansicht der Konsole. Wenn Sie den Software Deployment Agent anwählen, werden im Detailregister Software Packages alle Software-Paket, die sich im Depot befinden, in der Liste angezeigt. 5.2 Pakete aktivieren Damit Pakete überhaupt installiert werden können, müssen sie in der Paketliste aktiviert sein. Nur aktivierte Pakete werden vom Client bei den Scans und der Installation berücksichtigt. Auf diese Weise können problematische Pakete von einer weiteren Verteilung ausgeschlossen werden. Wechseln Sie in die Ansicht Infrastructure und markieren Sie den Software Deployment Agent. Markieren Sie in der SW-Paketliste das SW-Paket und wählen Sie im Kontextmenü Activation > Activate selected packages. Option Activate selected packages Deactivate selected packages Beschreibung Die markierten Pakete werden aktiviert und für die Verteilung freigegeben. Die markierten Pakete werden deaktiviert und für die Verteilung gesperrt / 02 / deu 32/114

33 Betrieb Option Reset activation flag Beschreibung Damit wird der Status der markierten Pakete wieder auf den Standard zurückgesetzt. 5.3 Pakete verteilen Neben der direkten Zuweisung von Paketen an Computer und Benutzer können Pakete auch einer Site oder der ganzen Firma zugewiesen werden. Zusammenhängende Software kann in Gruppen zusammengefasst werden welche dann wie einzelne Pakete verteilt werden können. Pakete können folgenden Objekten zugewiesen werden: Computer Benutzer Firmen oder Sites Gruppen Der Management Client installiert die Software-Pakete beim nächsten Start, zu vorgegebenen Zeitpunkten oder sofort und liefert einen genauen Status über den Installationsverlauf an die Konsole zurück. Vor dem Ausrollen von neuen Paketen sollte die IT-Abteilung zunächst auf Testsystemen überprüfen, ob Updates zu Problemen mit installierten Anwendungen führen. Bei besonders kritischen Systemen kann zuvor mit Imaging ein Festplatten-Image als Backup erstellt werden SW-Pakete an Computer zuweisen Die Zuweisung der SW-Pakete ist mit der Management Console denkbar einfach. So weisen Sie SW-Pakete an Computer zu Markieren Sie im Fenster Devices einen (oder mehrere) Computer. Wechseln Sie in das Register Software Packages und markieren Sie das Software-Paket. l Es können auch mehrere Objekte gleichzeitig markiert werden. Wählen Sie im Kontextmenü Assign to selected > Machines. - oder - Ziehen Sie die markierten SW-Pakete per Drag&Drop in das Fenster Devices. l Sie müssen nicht das einzelne Objekt treffen. Die Zuweisung erfolgt immer an alle markierten Objekte. Bestätigen Sie die Sicherheitsabfrage mit OK um die Paketzuweisung abzuschliessen Paket an Benutzer zuweisen Software-Paket, welchen einen speziellen Benutzerteil enthalten der nicht automatisch allen Benutzern zugewiesen werden soll, müssen den entsprechenden Benutzern manuell zugewiesen werden. Diese Software-Pakete sind in der Paketliste in der Spalte Assign mit dem Symbol gekennzeichnet. Die Paket-Zuweisung an Benutzer erfolgt analog der Zuweisung an Computer. So weisen Sie SW-Pakete einem Benutzer zu Markieren Sie im Fenster Users einen (oder mehrere) Benutzer. Wechseln Sie in das Register Software Packages und markieren Sie das Software-Paket / 02 / deu 33/114

34 Betrieb l Es können auch mehrere Objekte gleichzeitig markiert werden. Wählen Sie im Kontextmenü Assign to selected > Users. - oder - Ziehen Sie die markierten SW-Pakete per Drag&Drop in das Fenster Users. l Sie müssen nicht das einzelne Objekt treffen. Die Zuweisung erfolgt immer an alle markierten Objekte. Bestätigen Sie die Sicherheitsabfrage mit OK um die Paketzuweisung abzuschliessen SW-Pakete an Sites zuweisen Nebst der bekannten Zuweisung von Software an Computer können SW-Pakete auch einer Firma oder Site zugeteilt werden. Die Zuweisung von Software an ganze Firmen oder Sites hat den Vorteil, dass man sich dabei die Vererbung innerhalb des hierarchischen Strukturbaum zunutze machen kann. Statt die Zuweisung für jeden Computer oder Benutzer wiederholen zu müssen, kann die Zuweisung einmalig an die Site oder Firma erfolgen und die Computer Objekte werden dann nur noch fraglicher Site oder Firma untergeordnet, wodurch diese die Zuweisung erben. Dieses Konzept erlaubt mit einer organisatorischen Strukturierung die Definition von Firmenoder Abteilungsstandards. So weisen Sie SW-Pakete einer Site zu Wechseln Sie in das Register Software Packages und markieren Sie das Software-Paket. l Es können auch mehrere Objekte gleichzeitig markiert werden. Ziehen Sie die markierten SW-Pakete per Drag&Drop auf die Firma oder Site im Strukturbaum. Bestätigen Sie die Sicherheitsabfrage mit OK um die Paketzuweisung abzuschliessen. So entfernen Sie ein einer Site zugewiesenes SW-Paket Wechseln Sie in die Ansicht Site Management. Markieren Sie im Strukturbaum die Site und wechseln Sie in das Register Software. Markieren Sie das SW-Paket und wählen Sie im Kontextmenü Deny/Remove Software / 02 / deu 34/114

35 Betrieb 5.4 Softwaregruppen Die Zuweisung von Paketen an Computer und Benutzer lässt sich vereinfachen, wenn zusammengehörige Software oder Computer, mit gleichen Anwendungsprofilen in Gruppen zusammenfasst werden Software-Gruppe erstellen/löschen So erstellen Sie eine Software-Gruppe Wechseln Sie in das Detailregister Deployment Groups. Klicken Sie in die leere Zeile und wählen Sie im Kontextmenü Grouping > Add Group. Geben Sie im nachfolgenden Dialog der neuen Gruppe einen Namen. l Die Option Perform Operation for all Software Depots in the database ermöglicht die Erstellung der Gruppe für alle verfügbaren SW-Depots. Klicken Sie auf Add um den Vorgang abzuschliessen. So löschen Sie eine Software-Gruppe Markieren Sie eine oder mehrere Software-Gruppen und wählen Sie im Kontextmenü Grouping > Delete Group oder Delete selected Groups / 02 / deu 35/114

36 Betrieb Software einer Gruppe zuweisen So weisen Sie Software einer Gruppe zu Wechseln Sie in das Register Software Packages. Markieren Sie die Software-Paket und wählen Sie im Kontextmenü Grouping > Add Software to Group. Wählen Sie die Software-Gruppe aus und klicken Sie auf Add Software-Gruppe zuweisen Gruppen werden gleich wie Pakete zugewiesen. Markieren Sie die Computer und Benutzer, welche Mitglieder dieser Gruppe werden sollen. Markieren Sie im Fenster Resources in der Registerkarte Groups die gewünschte Gruppe. Ziehen Sie die Gruppe per Drag&Drop ins Computer respektive Benutzer Fenster / 02 / deu 36/114

37 Betrieb Software-Gruppe entziehen Gruppen werden gleich wie Pakete wieder entzogen. Markieren Sie im Fenster Devices den Computer oder im Fenster Users den Benutzer, von denen Sie die Gruppe wieder entfernen möchten. Wechseln Sie in das Register Software. Markieren Sie die Software-Gruppe und wählen Sie im Kontextmenü Remove/Deny Software. Vererbte Gruppen Wenn die Gruppe nicht direkt, sondern von einer Site über Vererbung zugewiesen wurde, dann können Sie die Gruppe nicht einfach entfernen, da ja alle Computer in dieser Site diese Gruppe zugewiesen haben. Wenn Sie Remove / Deny wählen, dann übersteuern Sie diese vererbte Zuweisung. Die Gruppe ist Denyed. Wollen Sie die ursprüngliche Zuweisung über die Vererbung wiederherstellen, wählen Sie die Funktion Grant Gruppendefinitionen verteilen Gruppendefinitionen gelten grundsätzlich nur innerhalb eines SW-Depots. Sie können aber auf weitere Depots übertragen werden, damit z.b. auf lokalen Infrastruktur Servern die gleichen Gruppen zur Verfügung stehen. So verteilen Sie eine Gruppe auf andere SW-Depots Wechseln Sie in die Ansicht Infrastructure. Markieren Sie den Software Deployment Agent und wählen Sie im Kontextmenü Distribute groups to other SW depot(s) / 02 / deu 37/114

38 Betrieb Distribute Software Groups Der Distribute Software Groups Wizard wird gestartet. Wählen Sie nun die SW-Depots aus, auf die die Gruppendefinitionen verteilt werden sollen. Wenn Sie die Option Remove groups / group contents on target first auswählen, werden vorgängig alle Gruppen auf dem Zieldepot gelöscht. Damit können Sie auf dem Zieldepot eine identische Gruppenstruktur sicherstellen. Markieren Sie die Option Distribute to all depots of this company, um die Gruppendefinitionen auf alle weiteren Software Deployment Agents, die der gleichen Firma zugewiesen sind, zu verteilen. Mit dieser Option können Sie in allen Sites einheitliche Gruppen zur Verfügung stellen. Wenn Sie diese Option nicht aktivieren, müssen Sie die einzelnen SW-Depots, auf die die Gruppendefinitionen verteilt werden sollen, aus der Liste auswählen. Wählen Sie Next>>, um die Gruppendefinitionen zu verteilen. Hinweis Die den Gruppen zugewiesenen Software-Pakete müssen auch auf den Zieldepots zur Verfügung stehen, damit die Gruppendefinitionen vollständig übernommen werden können / 02 / deu 38/114

39 Betrieb 5.5 SW-Pakete installieren Zugeteilte SW-Pakete werden auf dem Zielcomputer vom Management Client installiert, beim Hochfahren des Computers, bei der Anmeldung eines Benutzers, zu vorgegebenen Zeitpunkten (Client Konfiguration), wenn der Administrator die Installation von der Konsole her auslöst oder wenn der Benutzer im Client die Funktion Updates anwählt. Am Ende liefert der Management Client einen genauen Status über den Installationserfolg an die Konsole zurück Ersetzen von Dateien in Benutzung Der Client kann auch diverse Software und vor allem SW-Pakete ohne Reboot hintereinander installieren. Unter Windows besteht dabei das Problem, das gewisse Systemdateien, welche in Benutzung sind, nicht korrekt überschrieben werden können. Microsoft stellt zur Behebung dieses Problems das Programm QCHAIN.EXE zur Verfügung, welches auch von einigen Patch Management Tools verwendet wird. Columbus hat diese Funktion bereits im Client eingebaut und benötigt daher die Datei QCHAIN.EXE nicht. Diese Funktionalität analog QChain ist aber nicht per Default aktiviert. Dementsprechend muss entweder QChain verteilt oder der Client entsprechend konfiguriert werden. Der Konfigurationseintrag heisst FileRenameCleanup und kann folgende Werte beinhalten: Wert Beschreibung 0 Kein Cleanup 1 Wenn Columbus einen Reboot ausführt 2 Beim Shutdown des Columbus Diensts 3 Bei Fall 1 und Fall 2 Hinweis QChain funktioniert nur mit Dateien, die eine Versionsinformation beinhalten damit ein Vergleich der beiden Dateien möglich ist / 02 / deu 39/114

40 Betrieb 5.6 Variablen in der Konsole importieren So importieren Sie Variablen Markieren Sie im Strukturbaum das Element Computers und aktivieren Sie das Detailregister Variables. Klicken Sie mit der rechten Maustaste auf einen leeren Bereich und wählen Sie im Kontextmenü Import from file. Klicken Sie auf Browse und wählen Sie die Datei. Die Importdatei benötigt die folgende Struktur: [Variables] MachineType=Desktop Department=Marketing / 02 / deu 40/114

41 Pakete erstellen K A P I T E L 6 6 Pakete erstellen In diesem Kapitel PackageStudio konfigurieren Einleitung Neues SW-Paket erstellen SW-Paket auf basierendem Snapshot erstellen PackageMaker verteilen Paket bearbeiten Paket testen Wrapper-Paket für MSI erstellen Dieses Kapitel beschreibt die Paketerstellung mit der Standardkonfiguration von Columbus PackageMaker. Die Konfigurationsanpassungen von PackageMaker an die Firmenstandards und die Paketvoreinstellungen werden im Kapitel Konfiguration beschrieben. 6.1 PackageStudio konfigurieren Für die Konfiguration von PackageStudio öffnen Sie den Optionendialog. Wählen Sie im Menü Tools > Options. - oder - im Navigator Configure PackageStudio / 02 / deu 41/114

42 Pakete erstellen Register General Eintrag Use PackageStudio Navigator Single click in Navigator performs the selected task Maximize windows opened from Navigator Log automated actions Show message when single automated action has been processed Do not show Automated Actions Dialog if the automated actions have been performed before Update Check sum after saving the package Language Character set Automated action on package open Beschreibung Der Navigator wird aktiviert. Die ausgewählte Aufgabe wird mit einem Klick sofort ausgeführt. Die von einer Navigator-Aktion geöffneten Fenster werden automatisch maximiert. Alle durch die automatisierten Aktionen vorgenommenen Änderungen werden im Fenster Activity and Analysis Protocol aufgezeichnet. Meldung über die Anzahl der vorgenommenen Änderungen. Die automatisierten Aktionen werden bei jedem Öffnen eines Pakets ausgeführt. Die folgenden Optionen stehen zur Auswahl. always - bei jedem Speichern der Paketdateien wird die Prüfsumme berechnet und gespeichert. only if Check sum info already exists - aktualisiert die Prüfsumme, wenn sie bereits zuvor für das Paket berechnet wurde. never Diese basiert auf den Windows-Sprachressourcen, die von jeder Win32-Anwendung automatisch erkannt und, falls vorhanden, automatisch geladen werden. Verwendeter Zeichensatz Hier können die automatisierten Abläufe einzeln aktiviert werden / 02 / deu 42/114

43 Pakete erstellen Register Tools In diesem Dialogfenster werden die Parameter zum Starten von DuplicatesChecker angeben (ein externes Tool für die Suche nach doppelten Vorkommen bzw. Konflikten zwischen Paketen). Ausserdem können Sie hier zusätzliche Tools angeben (die nicht Bestandteil von PackageStudio sind), die während des Paket-Bereinigungsprozesses verwendet werden können. Eintrag Location Parameters Beschreibung Pfad und Dateinamen für Duplicates Checker. Parameter (siehe "Automatisieren der Duplikatprüfung" auf Seite 111) für den Aufruf von Duplicates Checker. Confirm Parameters Definiert ob die Parameter automatisch oder durch Bestätigung mitgegeben werden. User Tools Caption Program Start directory Parameters Klicken Sie auf der linken Seite auf einen Eintrag in der Liste, um die Einstellungsfelder für das gewünschte Benutzertool zu aktivieren. Diese Bezeichnung wird im PackageStudio im Menü Tools angezeigt. Pfad und Dateiname für das Programm. Datei kann über das [...]-Icon gesucht werden. Das Laufwerk und Verzeichnis, das beim Starten des Programms als Standardeinstellung festgelegt werden soll. Parameter für den Programmstart. Tipp Wenn Sie einen Verweis auf das Verzeichnis des aktuellen Pakets übergeben müssen, können Sie %PKGDIR% verwenden / 02 / deu 43/114

44 Pakete erstellen Register Filters Hier können Sie diese Registrierungseinträge vordefinieren und kategorisieren. Da manche Registrierungseinträge in dem einen Paket zulässig sind, in anderen jedoch nicht enthalten sein sollten, können Sie die verwendeten Filter für jedes zu filternde Paket aktivieren und deaktivieren. Daher sollten Sie alle Registrierungsschlüssel, die bekanntermassen Probleme verursachen können, hier angeben, und den entsprechenden Filter (bzw. die Filterkategorien) vor dem Überprüfen eines Pakets aktivieren. Hinweis Das Erstellen dieser Standard-Registrierungsstruktur erfordert detaillierte Kenntnisse der Windows-Registrierung. Wenn alle Paketierer PackageStudio verwenden, empfiehlt es sich, im Rahmen von Package- Maker möglichst wenige Filter zu verwenden, da PackageStudio folgende Vorteile bietet: Die Filter lassen sich nach Pakettyp aktivieren bzw. deaktivieren. Der Filterungsprozess kann mehrmals ausgeführt werden. In PackageStudio werden Platzhalter unterstützt. Im Lieferumfang von PackageStudio ist eine Reihe vordefinierter Filter für die Registrierung enthalten, mit denen sich die Qualität der meisten Pakete verbessern lassen sollte, ohne dass wichtige Einträge gelöscht werden. Wenn Sie daher nicht sicher sind, welche Einträge zu verwenden sind, ziehen Sie die Standardeinstellungen heran. Button Add Filter Edit Filter Delete Filter Beschreibung Fügen Sie hiermit neue Einträge hinzu. Hiermit können Sie einen vorhandenen Eintrag ändern. Hiermit können Sie einen einzelnen Eintrag oder einen ganzen Abschnitt löschen. Section: Der Abschnitt, unter dem der Filter angezeigt werden soll. Abschnitte werden verwendet, um alle im Abschnitt enthaltenen Filter schnell zu aktivieren bzw. deaktivieren. Filter: Der zu filternde Pfad der Registrierung / 02 / deu 44/114

45 Pakete erstellen Beispiele Um alle Benutzereinstellungen für den Editor von Windows zu filtern, verwenden Sie HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\NOTEPAD (bei diesen Einträgen wird die Groß- und Kleinschreibung nicht beachtet). Um alle Brainware-Einstellungen (in einer Hivestruktur der Registrierung) zu filtern, verwenden Sie SOFTWARE\Brainware (am Beginn einer Zeile ist keine Angabe von Platzhaltern erforderlich). Verwenden Sie {{*}} als Platzhalter: HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\{{*}}\PARAMETERS\TCPIP \LEASEOBTAINEDTIME Sie können auch nach bestimmten Werten (und nicht nur Schlüsseln) filtern: HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\EXTENSION S\.INI Um einen Registrierungsfilter standardmässig zu aktivieren muss sowohl der Registrierungsfilter selbst als auch der Abschnitt, in dem sich der Filter befindet, aktiviert sein. Die folgenden Kombinationen sind möglich: Filter aktiviert: Der Filter ist standardmäßig aktiv. Filter deaktiviert: Der Filter ist standardmäßig nicht aktiv. Zur Aktivierung muss der Filtereintrag aktiviert werden Register FileFilters In der Regel enthält jedes Paket eine Vielzahl von Dateien. Einige dieser Dateien sind möglicherweise unnötig. Alle Pakete können daher auf solche Dateien überprüft werden. Hier können Sie diese Dateien vordefinieren und kategorisieren. Da manche Dateien in einem Paket zulässig sind, in anderen jedoch nicht enthalten sein sollten, können Sie die verwendeten Filter für jedes zu filternde Paket aktivieren und deaktivieren. Daher sollten Sie alle Dateien, die nicht im Paket enthalten sein sollten, hier angeben, und den entsprechenden Filter (bzw. die Filterkategorien) vor dem Überprüfen eines Pakets aktivieren. Die Eintragungen sind hierarchisch sortiert. Durch die Filterung einer hierarchisch höher gelegenen Ablage werden auch dessen Unterablagen samt ihrem Inhalt gefiltert. Es können jedoch / 02 / deu 45/114

46 Pakete erstellen nach erfolgter "von oben-nach-unten" Festlegung lokal "von-unten-nach-oben" Teilfestlegungen geändert werden. Button Add Filter Edit Filter Delete Filter File Folder Beschreibung Fügen Sie hiermit neue Einträge hinzu. Hiermit können Sie einen vorhandenen Eintrag ändern. Hiermit können Sie einen einzelnen Eintrag oder einen ganzen Abschnitt löschen. Einzelne Dateien, welche gefiltert werden sollen. Ganze Dateiablagen, oder der zu filternde Pfad" Register Variables Variablen werden verwendet, damit ein Paket portierbar wird und können als eine Art Textersatz betrachtet werden. Die von PackageStudio verwendeten Variablen stammen aus 2 Quellen: Generische, innerhalb von PackageStudio definierte Variablen (Configuration > Options > Variables) Paketspezifische Variablen (diese stammen aus der Snapshot.Ini des zu bearbeitenden Pakets). Aus der Snapshot.Ini werden alle Variablen innerhalb des Abschnittes [Directories] verwendet, wie auch die 2 Einträge Machine und User aus dem Abschnitt [Options]. Im Lieferumfang von PackageStudio ist eine Reihe vordefinierter Variablen enthalten, die in der Regel nicht geändert werden sollten. Sie können jedoch andere Variablen hinzufügen. Normalerweise empfiehlt es sich, ein Basispaket zu erstellen, das verschiedene Konfigurationseinstellungen umfasst. Solche Einträge können der Variablenliste hinzugefügt werden. Beispiel Wenn ein Paket Verweise auf C:\WINNT\Profiles\Administrator\Application Data enthält, wird dieses Paket nur bei einem Benutzer funktionieren, dessen Name Administrator lautet. Selbst bei einer Änderung in C:\WINNT\Profiles\%_User%\Application Data wird dieses Paket unter Windows 2000 nicht ordnungsgemäss funktionieren, da das Benutzerprofil nicht mehr im Verzeichnis C:\WINNT abgelegt ist. Wenn Sie die Variablenersetzung von PackageStudio ausführen, werden solche Verweise in %_ApplicationData% geändert und funktionieren sowohl in NT 4.0 als auch Windows / 02 / deu 46/114

47 Pakete erstellen In PackageStudio werden verschiedene Variablen verwendet, die nicht in diesem Fenster angezeigt werden, z.b. %_Windows%, %_ProgramFiles% usw. Diese Variablen sind Bestandteil aller Pakete, da die Werte für diese Verzeichnisvariablen von Paket zu Paket verschieden sein können. Die eigentliche Umgebung des Computers, auf dem das Paket aufgezeichnet wurde, wird von PackageMaker in der Datei SNAPSHOT.INI gespeichert. Beispiel Das Basispaket enthält die Variable %CDDrive%, die auf das Laufwerk zeigt, das dem lokalen CD-ROM-Laufwerk zugewiesen ist. In einem solchen Fall können Sie X:\ als zu suchenden Text und %CDDrive% als Text für die Ersetzung hinzufügen. Eine Liste aller für die Funktion Apply variables verwendeten Variablen können Sie im Fenster Variables currently active anzeigen (nur, wenn ein Paket geladen ist). Die Reihenfolge, in der die Einträge in diesem Fenster angezeigt werden, entspricht genau der Reihenfolge ihrer Verarbeitung. Die Sortierreihenfolge der Variablen ist abhängig von der Länge des zu ersetzenden Textes (die Verarbeitungsreihenfolge entspricht genau der Position, an der die Variablen im Fenster Parameters angezeigt werden). Wenn Sie bestimmte Variablen vor allen anderen (unabhängig von ihrer Länge) verarbeiten möchten, können Sie dem zu suchenden Text das ##PRE## -Tag hinzufügen. Wenn Sie den Inhalt einer anderen Variablen verwenden möchten, verwenden Sie das #RESOLVE# -Tag. Spezialfunktionen Variable ##PRE## #RESOLVE# #MSIRESOLVE#: Beschreibung Weist PackageStudio an, zuerst diese Variable zu verwenden. In der Regel werden alle Variablen nach Länge sortiert. Wenn mehrere Variablen mit einer ##PRE##-Funktion vorhanden sind, werden diese ebenfalls nach Länge sortiert. Beispiel: Fügen Sie ##PRE##%%SYSTEMROOT%% als text to be searched hinzu. Weisen Sie den Wert #RESOLVE#%_Windows% zu. Dies bewirkt, dass alle Vorkommen von %%SystemRoot%% von PackageStudio durch den Wert ersetzt werden, der der Variablen %_Windows% zugeordnet ist. Dies erfolgt, BEVOR der normale Prozess der Variablenersetzung gestartet wird. Weist PackageStudio an, zu versuchen, eine Variable aufzulösen (aus der Liste der statischen Variablen von PackageStudio wie auch aus den Directory-Relocation-Variablen, die mit jedem Paket mitgeliefert werden). Wie bei #RESOLVE#, nur werden hier die Verzeichnisse in das MSI-Format konvertiert (z. B. C:\WINDOWS anstelle von C:\WINNT). Beispiel Wenn Sie vor dem Zuordnen anderer Variablen zunächst alle Vorkommen von %SYSTEMROOT% auflösen möchten, müssen Sie ##PRE##%%SYSTEMROOT%% als text to be searched angeben. Wenn %SYSTEMROOT% durch denselben Wert ersetzt werden soll, der auch %_Windows% zugewiesen ist, geben Sie #RESOLVE#%_Windows% als Variable an / 02 / deu 47/114

48 Pakete erstellen Register Package configuration defaults Das Fenster Package Definition / Configuration enthält verschiedene Felder, in denen sich Kombinationsfelder mit auswählbaren Werten befinden. Die in diesen Kombinationsfeldern angezeigten Werte können hier angegeben werden. Wenn Sie nicht zulassen möchten, dass Werte verwendet werden, die sich nicht in der Liste befinden, aktivieren Sie die Option Limit to List / 02 / deu 48/114

49 Pakete erstellen Register MSI wrapper Die wichtigsten Optionen können mit dem Dialogfeld für die Optionen in PackageStudio konfiguriert werden. Path to the default package (Pfad zum Standardpaket) Wenn benutzerdefinierte Paketvorlagen verwendet werden sollen, kann der Pfad zum Standard-Paketverzeichniss ([Default Package]) hier angegeben werden. Wenn kein Pfad angegeben wurde und kein [Default Package]-Verzeichnis im Anwendungsverzeichnis von Package- Studio vorhanden ist, werden die Standardvorgaben verwendet. Dieses Verhalten ist dasselbe wie in PackageMaker. Verwenden Sie PackageMaker, um die Paketvorlagen benutzerdefiniert anzupassen und das Verzeichnis [Default Package] zu erstellen. Default Package Directory (Standardpaketverzeichnis) Standardpfad für die Speicherung der neu erstellten Software-Pakete. Generic Public Properties (Generische öffentliche Eigenschaften) Dies ist eine Reihe von (meist) allgemeinen, gültigen öffentlichen Eigenschaften. Die Werte können durch Auswahl der Optionsfelder im Assistenten angegeben werden. Syntax Beschreibung Parameter Werte Standardwert [Default value] Wert Wert[ Wert...]=Standardwert Für alle öffentlichen Eigenschaften können Werte angegeben werden. Werte müssen durch ein getrennt werden. Dies ist der Wert, der standardmässig ausgewählt sein sollte; er muss wiederum ans Ende gestellt werden, getrennt durch = Dieser Eintrag bedeutet, dass für diese Eigenschaft der Standardwert der MSI-Datei zu verwenden ist. Beispiel Hierdurch werden zwei Optionsfelder mit den Werten 0 und 1 generiert, wobei 1 standardmässig ausgewählt ist. 0 1= / 02 / deu 49/114

50 Pakete erstellen Hinweis In Public Properties können Sie andere Eigenschaften aus der MSI-Datei verwenden. Der Wert wird zum Installationszeitpunkt aus der MSI-Datei abgerufen. Solche Eigenschaften müssen in ## eingeschlossen sein. Das Zielverzeichnis wird anhand des Anwendungsnamens erstellt. TargetDir=C:\Apps\##PRODUCTName## Vorlage für die Paketdokumentation Wenn ein Paket geladen wird und keine Paketdokumentationsdatei Info.rtf vorhanden ist, wird von PackageStudio überprüft, ob die Datei Sample.rtf (in dem Verzeichnis, in dem sich PackageStudio befindet) vorhanden ist. Wenn keine Sample.rtf vorhanden ist, wird die interne Standarddatei von PackageStudio verwendet. 6.2 Einleitung PackageMaker verwendet für die Paketerstellung das Snapshot-Verfahren. Vor und nach der Installation einer Applikation wird ein Snapshot erstellt und sämtliche Änderungen in einem SW-Paket gespeichert. Vorgehen bei der Paketerstellung Before-Snapshot erstellen (auf Seite 51) Applikation installieren (auf Seite 53) After-Snapshot erstellen (auf Seite 54) SW-Paket generieren (siehe "Paket generieren" auf Seite 56) / 02 / deu 50/114

51 Pakete erstellen 6.3 Neues SW-Paket erstellen So erstellen Sie ein SW-Paket Starten Sie PackageMaker über Start > Programs > Columbus > PackageMaker. - oder - Doppelklicken Sie die Setupdatei PkgMaker.exe im Verzeichnis C:\Program Files\Columbus\Packaging. Klicken Sie im Willkommensfenster auf Next. l Wird die Option Don't display this page again markiert, erscheint das Dialogfenster beim Start nicht mehr. Wählen Sie die Option Create a Package und klicken Sie auf Next. Unter Windows Vista steht zusätzlich die Option zur Auswahl, ob die Applikation Vista kompatibel ist oder nicht. Tipp Wir empfehlen die Option bei Unsicherheit nicht zu aktivieren, da gewisse Bereiche automatisch gefiltert werden / 02 / deu 51/114

52 Pakete erstellen Before-Snapshot erstellen In einem ersten Schritt wird der IST-Zustand des Computers in einem Snapshot aufgezeichnet. Überprüfen Sie den Speicherort und den Namen des Snapshot. Wechseln Sie in das Register Select drives. Im Register Select drives werden die Laufwerke angezeigt, welche beim Snapshot aufgezeichnet werden. Standardmässig ist das Laufwerk C:\ markiert. Ist z.b. das Benutzerprofil auf dem Laufwerk U:\ abgelegt, wird dieses zusätzlich markiert. Markieren Sie die Laufwerke. Klicken Sie auf Set selected drives as default um die Einstellung zu speichern. Klicken Sie auf Next. Wurde bereits ein Before-Snapshot erstellt, erscheint eine Sicherheitsabfrage welche auf das Überschreiben aufmerksam macht / 02 / deu 52/114

53 Pakete erstellen Hinweis Wir empfehlen die Snapshots immer zu überschreiben. Dies stellt sicher, dass immer der aktuelle Systemstatus gespeichert wird. Klicken Sie auf Yes um die Sicherheitsmeldung zu bestätigen und den Snapshot zu überschreiben. l Die Aufzeichnung des Systemstatus beginnt. Während der Aufzeichnung des Systemstatus wird der Fortschritt angezeigt. Alle Dateien und Registry-Einträge werden von PackageMaker erfasst und registriert. Diese Informationen werden in einem Snapshot gespeichert Applikation installieren Die Installation der zu paketierenden Applikation kann direkt aus PackageMaker gestartet werden. Ebenso ist eine manuelle Installation möglich oder Änderungen an der Systemeinstellungen, welche im Snapshot gespeichert werden. Während der Installation bleibt PackageMaker inaktiv und muss deshalb nicht geöffnet bleiben. Wird PackageMaker durch die Option Close PackageMaker oder ein Neustart des Installationsprogramms geschlossen, fährt der Assistent beim nächsten Start von PackageMaker bei der Option Generate the Package weiter. Tipp Tipp Wir empfehlen, das System nach der Installation immer neu zu starten. Schliessen Sie PackageMaker nicht manuell oder über Cancel. Ansonsten fährt PackageMaker beim nächsten Start nicht mit der Generierung eines SW-Pakets fort. Markieren Sie die gewünschte Option. Geben Sie den Pfad zu der Installationsdatei an. - oder - Klicken Sie auf den Button [...] um die Installationsdatei zu suchen / 02 / deu 53/114

54 Pakete erstellen Markieren Sie die Option Close PackageMaker und klicken Sie auf Next. Option Launch a setup program Manually install or configure applications Beschreibung Mit dem Button [...] wird die Setupdatei gesucht und ausgewählt. Mit diesem Vorgehen wird verhindert, dass der Explorer gestartet werden muss und dessen Registry-Einträge in das SW-Paket übernommen werden. Wird diese Option gewählt muss das Setup manuell über dem RUN-Befehl gestartet werden. Hinweis Starten Sie das Setup nicht über den Explorer, da dieser Konfigurationsänderungen verursacht. Close PackageMaker Mit dieser Option wird PackageMaker nach dem Start des Setup beendet. Wichtige Hinweise Mit der Verwendung von PackageMaker erst fortfahren, nachdem die Applikation installiert und konfiguriert ist. Bietet eine Applikation eine dedizierte Netzwerkinstallation, sollte zuerst diese und dann der Teil für die Client-/Benutzer-Konfiguration ausgeführt werden. Diese Setup-Option ermöglicht in der Regel eine problemlosere Konfiguration, falls mehrere Benutzer diese Applikation auf demselben Computer ausführen. Nach einem Neustart wieder mit dem gleichen Benutzerkonto anmelden und alle Netzwerkverbindungen wie zuvor wieder herstellen. Tipp Wir empfehlen Konfigurationseinstellungen in einem separaten SW-Paket zu erstellen. So muss bei nachträglichen Konfigurationsänderungen nicht das Haupt-Paket verteilt werden, sondern nur ein Konfigurations-Patch / 02 / deu 54/114

55 Pakete erstellen After-Snapshot erstellen Nach dem Neustart fährt PackageMaker mit dem Dialogfenster für die Paketerstellung fort. Hinweis Wurde PackageMaker manuell beendet, beginnt PackageMaker beim nächsten Start wieder am Anfang. In diesem Fall wählen Sie die Option Create Package based on an existing snapshot und wählen den letzten Before-Snapshot aus. Markieren Sie die Option Generate a package und klicken Sie auf Next. Option Generate a package Do not generate a package Beschreibung Diese Option ist standardmässig ausgewählt. Mit dieser Option wird der Vorgang abgebrochen. Zusätzlich besteht die Möglichkeit den aktuellen Before-Snapshot zu löschen / 02 / deu 55/114

56 Pakete erstellen Die im Before-Snapshot aufgenommenen Laufwerke werden angezeigt. Vor dem Fortfahren überprüft PackageMaker, ob alle zu überwachenden Laufwerke verfügbar sind. Überprüfen Sie den Speicherort und den Namen des Snapshot. Markieren Sie die Option Keep the snapshot for further usage und klicken Sie auf Next. Option Keep the snapshot for further usage Beschreibung Mit dieser Option wird der Snapshot zur späteren Verwendung gespeichert, z.b. für künftige SW-Paket die auf dem jetzigen Stand basieren. Klicken Sie auf Yes um die Sicherheitsmeldung zu bestätigen und den Snapshot zu überschreiben / 02 / deu 56/114

57 Pakete erstellen Paket generieren Die Eigenschaften des SW-Pakets werden in der Konfigurationsdatei Package.ini eingetragen. Der Verzeichnisname, in dem das Paket gespeichert wird, setzt sich aus den Angaben [Identifier.Language\version.patch] zusammen. Geben Sie die notwendigen Angaben ein. Klicken Sie auf Next und die Paketerstellung beginnt. Eintrag Description Identifier Version Patch Platform Language Beschreibung Name der paketierten Applikation. Bei der Zuweisung der Software-Pakete in der Management Console ist nur dieser Name sichtbar. Interner, alphanumerischer Name des SW-Pakets der auch die Installationsreihenfolge der SW-Pakete bestimmt. Maximale Länge: 60 Zeichen. Version des SW-Pakete und nicht die Version der Applikation. Maximale Länge: 10 Zeichen. Haupt-SW-Paket muss immer die Patch-Version 0 aufweisen. Mit jedem Patch-SW-Paket wird diese Nummer erhöht. Maximale Länge: 10 Zeichen Plattform, auf der das Paket erstellt wurde. Trägt zu einer eindeutigen Paket-ID bei, hat jedoch keine technische Funktionalität. Maximale Länge: 10 Zeichen Information für die Paketverwaltung. Trägt zu einer eindeutigen Paket-ID bei, hat jedoch keine technische Funktionalität. Maximale Länge: 10 Zeichen. Hinweis Die Gesamtlänge des zusammengesetzten Package-Identifiers (Kurzversion = Identifier_Sprache_Version) ist auf 65 Zeichen, resp. 75 Zeichen bei der langen Version (Identifier_Sprache_Version_Patch) beschränkt / 02 / deu 57/114

58 Pakete erstellen Patch-SW-Paket Wird ein Patch-SW-Paket erstellt, muss dieses die gleichen Werte für Identifier, Version, Platform und Language aufweisen wie das Haupt-SW-Paket. Klicken Sie auf den Button Get entries. Wählen Sie die Package.ini des SW-Pakete aus, für das Sie einen Patch erstellen möchten. l Alle Elemente, die identisch sein müssen, werden geladen und abgeblendet angezeigt. Passen Sie die Felder Description und Patch an und klicken Sie auf Next. Der Before- und After-Snapshot wird nun von PackageMaker miteinander verglichen. Alle Änderungen, die zwischen den beiden Snapshots stattgefunden haben, werden in das SW-Paket kopiert. Klicken Sie auf Close um PackageMaker zu schliessen / 02 / deu 58/114

59 Pakete erstellen l Bleibt die Option Launch PackageStudio after closing PackageMaker aktiviert, startet PackageStudio automatisch Fehler bei der Erstellung Wird im Dialogfenster Finished eine rote Meldung angezeigt, ist bei der Paketerstellung ein Fehler aufgetreten. Die rote Meldung enthält den Pfad zu einer detaillierten Beschreibung welche von PackageMaker in der Datei Errors.txt im Paketverzeichnis gespeichert wird. In diesem Beispiel wurde eine Datei nicht kopiert, weil sie in Verwendung war / 02 / deu 59/114

60 Pakete erstellen Beenden Sie die Applikation und kopieren Sie die Datei manuell in das SW-Paket. Wenn PackageMaker nach Dateien auf Laufwerken sucht, die nicht in den Directory relocations (auf Seite 96) konfiguriert sind, kann das Programm keinen Platz für diese im SW-Paket ermitteln. PackageMaker erstellt dann ein Verzeichnis im Stammverzeichnis des SW-Pakete und benennt dieses [Laufwerkbuchstabe]_Drive, wie z.b.: X_Drive. Diese Dateien werden in kein Ziel kopiert. Fügen Sie im entsprechenden Abschnitt eine copy-anweisung hinzu. Verschieben Sie diese Dateien oder Verzeichnisse in den Server-, Client- oder User-Teil. Fügen Sie dem zugehörigen Script-Abschnitt die entsprechende copy-anweisung hinzu. 6.4 SW-Paket auf basierendem Snapshot erstellen Wird diese Art der Paketerstellung verwendet, muss die Applikation vor dem Ausführen von PackageMaker bereit installiert und/oder konfiguriert sein. So erstellen Sie ein Paket Starten Sie PackageMaker über Start > Programs > Columbus > PackageMaker. Markieren Sie die Option Create a package based on an existing "before snapshot" und klicken Sie auf Next / 02 / deu 60/114

61 Pakete erstellen Markieren Sie einen bestehenden Before-Snapshot und klicken Sie auf Next. Element Look in Select snapshot Beschreibung Standardverzeichnis für Snapshots, mit dem Button [...] kann ein anderes Verzeichnis gewählt werden. Alle im gewählten Verzeichnis vorkommenden Snapshots werden angezeigt. Snapshot properties Eigenschaften des gewählten Snapshots. Diese können nicht verändert werden und dienen nur der Verifizierung. Der weitere Verlauf ist identisch zu der Erstellung eines neuen SW-Pakets. 6.5 PackageMaker verteilen Um im produktiven Umfeld effizient und professionelle SW-Pakete zu erstellen, empfehlen wir PackageMaker mit einem Columbus SW-Paket zu verteilen. Vorteile Alle Paketierer benutzen die gleichen Vorlagen und Einstellungen. Vereinfachte Qualitätsprüfung durch bestimmte SW-Paket-Definitionen. Konfigurieren Sie PackageMaker wie vorgängig beschrieben. l Hierzu gehören sowohl die Options (siehe "Optionen" auf Seite 89) wie auch die Standardpaketstrukturen und -filter, wie im Kapitel Standardwerte für die Paketgenerierung (siehe "Paketeigenschaften" auf Seite 93) beschrieben. Verteilen Sie das erstellte SW-Paket auf die jeweiligen Computer. Kopieren Sie alle Dateien die Konfigurationseinstellungen (siehe Tabelle) enthalten auf die jeweiligen Computer. Folgende Dateien enthalten Konfigurationseinstellungen für PackageMaker. Einige der Dateien sind erst vorhanden, nachdem die Standardwerte geändert wurden. Datei PkgMaker.exe Beschreibung Ausführbare Datei / 02 / deu 61/114

62 Pakete erstellen PkgMaker.cfg Konfigurationsdatei PkgMaker_Filter.txt Filter-Datei [Default Package] Paketvorlagenverzeichnis > Package.ini Paketdefinitionsdatei > Package.wms Paket Delivery-Script > \Cache > Package.wms Paket Configuration-Script > [Default Package] 6.6 Paket bearbeiten In diesem Kapitel wird das Vorgehen mit der Standardkonfiguration beschrieben. Die Konfigurationsanpassung von PackageStudio wird im Kapitel Konfiguration (siehe "PackageStudio konfigurieren" auf Seite 41) beschrieben. So öffnen Sie ein Paket Starten Sie PackageStudio über Start > Programs > Columbus > PackageStudio. - oder - Doppelklicken Sie die Setupdatei PkgStudio.exe im Verzeichnis C:\Program\Files\Columbus\Packaging. Klicken Sie im Navigator auf Load Package und wählen Sie im Paketverzeichnis die Datei Package.ini aus / 02 / deu 62/114

63 Pakete erstellen Benutzeroberfläche Die Oberfläche von PackageStudio besteht aus dem NavigationPanel auf der linken Seite und dem WorkPanel in der Mitte. Der Navigator führt Step-by-Step durch den Bereinigungsprozess und zeigt im mittleren Bereich die jeweiligen Detaildaten an. Symbolleisten Die Hauptsymbolleiste ist ständig sichtbar und im Gegensatz zu den Kontextabhängigen Icons ständig sichtbar. Icon Shortcut Beschreibung Open Columbus Package CTRL+O Öffnet ein bestehendes Columbus-Paket durch Auswählen der Package.ini. Save all CTRL+S Speichert alle geänderten Paketdateien. Save file Print Print setup Speichert nur die geöffnete und geänderte Datei. Druckt die geöffnete Datei aus. Dialogfeld der Druckeroptionen zur Konfiguration der Druckereinstellungen Copy CTRL+C Kopiert den Text in die Zwischenablage. Cut CTRL+X Schneidet markierten Text aus und kopiert diesen in die Zwischenablage. Paste CTRL+V Fügt den Inhalt der Zwischenablage wieder ein. Hide navigator Navigator ein- und ausschalten / 02 / deu 63/114

64 Pakete erstellen Icon Shortcut Beschreibung Tile window Cascade window Arrange window Minimize window Show Package configuration/definition window Show Delivery script window Show Configuration script window Show Package documentation window Browse files within the current package Show ini files Show variables currently used Show activity and analysis protocol Stop current action Command help Help About Exit Fenster nebeneinander anordnen. Fenster überlappend anordnen. Bearbeitbare Fenster anordnen, z.b. Configuration-Script. Alle anderen Fenster, wie z.b. das Protokollfenster, werden minimiert. Alle Fenster minimieren. Definitions- und Konfigurationsdatei anzeigen. Delivery-Script anzeigen Configuration-Script anzeigen Dokumentation anzeigen. Dateien im aktuellen Paket suchen. Zeigt alle INI-Dateien an. Zeigt die verwendeten Variablen an. Zeit das Aktivitäts- und Analyseprotokoll an. Hält die derzeitige Aktion an SHIFT+F1 Öffnet das Fenster der Befehlszeilenhilfe F1 Information über das Produkt und die Version Beendet PackageStudio Die folgenden Symbole werden nur im Kontext eingeblendet, bei dem sie benötigt werden. Dies betrifft die Bearbeitungsfenster und Dokumentfenster. Icon Select Font Go to ServerAdd section Beschreibung Schrifteigenschaften in der Paketdokumentation, werden im RTF-Format gespeichert. Sprungmarke zum [ServerAdd] Teil des Delivery-Scripts Go to ServerRemove section Sprungmarke zum [ServerRemove] Teil des Delivery-Scripts Go to ServerRepeat section Disable selected lines Enable selected lines Decrease font size Increase font size Go to UserAdd section Go to ClientAdd section Go to UserRemove section Sprungmarke zum [ServerRepeat] Teil des Delivery-Scripts Derzeit ausgewählte Zeilen deaktivieren. Solche deaktivierte Zeilen können wieder aktiviert werden Derzeit ausgewählte deaktivierte Zeilen aktivieren Angezeigte Schriftgrösse im Script-Bearbeitungsfenster verringern, damit mehr Text im Fenster Platz findet Angezeigte Schriftgrösse im Script-Bearbeitungsfenster erhöhen, um die Lesbarkeit zu verbessern Sprungmarke zum [UserAdd] Teil des Configuration-Scripts Sprungmarke zum [ClientAdd] Teil des Configuration-Scripts Sprungmarke zum [UserRemove] Teil des Configuration-Scripts / 02 / deu 64/114

65 Pakete erstellen Icon Go to ClientRemove section Go to UserRepeat section Go to ClientRepeat section Beschreibung Sprungmarke zum [ClientRemove] Teil des Configuration-Scripts Sprungmarke zum [UserRepeat] Teil des Configuration-Scripts Sprungmarke zum [ClientRepeat] Teil des Configuration-Scripts Navigator Mit den Buttons Next und Back wird die entsprechende Aktion ausgeführt. Im unteren Teil des Navigators wird zu jeder Aktion eine Beschreibung angezeigt. Um eine Aktion separat auszuführen, wird diese markiert und mit Perform task ausgeführt. ein- und ausge- Der Navigator wird mit dem Button schaltet Automatisierte Aktionen Beim Öffnen des Pakets im PackageStudio erscheint automatisch das Dialogfenster für die automatische Bereinigung. Diese automatisierten Aktionen können nachträglich auch manuell ausgeführt werden. Markieren Sie die Aktionen und klicken Sie auf Perform. Hinweis Bei allen automatisierten Aktionen, wie auch beim Entfernen der auskommentierten Zeilen, wird der Text zwischen Begin Script und End Script nicht geändert. Dies verhindert, dass Befehle des Windows Scripting Host geändert werden / 02 / deu 65/114

66 Pakete erstellen Hex-Werte konvertieren In technischer Hinsicht hat die Konvertierung von Hex-Werten keine Auswirkungen auf das SW-Paket. Der Vorteil besteht in der besseren Lesbarkeit. Besonders Registry-Einträge vom Typ REG_MULTI_SZ, bei denen es sich um Zeichenfolgenlisten mit jeweils einer Zeichenfolge pro Zeile handelt, werden im Hex-Format aus der Registrierung exportiert, obwohl es sich um Klartext handeln könnte. Register32 'HKey_Local_Machine' 'System\CurrentControlSet\Services\Eventlog\Application' 'Sources' 'H#4D C69656E74' 'REG_MULTI_SZ' /ADD Dieser Wert der Registrierung würde bei der Ersetzung von Hex-Einträgen in die folgende Klartextzeichenfolge übersetzt. Register32 'HKey_Local_Machine' 'System\CurrentControlSet\Services\Eventlog\Application' 'Sources' 'MSDTC Client' 'REG_MULTI_SZ' /ADD Hinweis Zeichen die in Texteditoren Probleme verursachen können, werden daher nicht geändert (alle Einträge, die Zeichen mit einem ASCII-Code unter 32 enthalten). Variablen ersetzen Bei der Aktion Apply Variables liest PackageStudio alle Variablen aus dem SW-Paket. Dies schliesst den Benutzer- und Computernamen wie auch alle Verzeichnisumsetzungen (Directory Relocations) mit ein. Anschliessend werden die generischen Variablen aus der Datei PkgStudio.ini gelesen. Alle Variablen werden der Länge nach sortiert (ausser die Einträge, die mit dem Präfix ##PRE## versehen sind). Dies ist wichtig zur Vermeidung unvollständiger Variablen. Beispiel C:\Windows sollte mit %_Windows% adressiert sein. C:\Windows\System32 sollte mit %_WindowsSystem% adressiert sein. Werden diese Einträge nicht der Länge nach sortiert, würden einige Einträge möglicherweise in %_Windows%\System32, anstelle von %_WindowsSystem% übersetzt. Diese Variablen sind im Fenstern Variables in der gleichen Reihenfolge aufgelistet, in der sie verarbeitet werden. Im Menü Configuration > Resolve Variables before applying variables wird angegeben, ob bereits vorhandene Variablen aufgelöst werden sollen, bevor die neuen Variablen zugeordnet werden. In PackageStudio wird dann versucht, die ursprünglichen Werte für alle bekannten Variablen einzutragen. Dies kann auch als Wiederherstellung der letzten Ersetzung betrachtet werden. Danach befinden sich z.b. wieder die festen Pfade in den Paket-Scripts. Anschliessend wird die Ersetzung der Variablen erneut durchgeführt. Wurden Definitionen geändert, werden die neuen Variablen ersetzt. Verknüpfungen verschieben Bei der Aktion Move Shortcuts wird der Client-Teil auf Verknüpfungen untersucht, die dann in den User-Teil verschoben werden. Voraussetzung ist, dass vorher die Funktion Apply variables ausgeführt wurde. Beispiel Hinweis Eine Zeile wie Shortcut '%_CommonPrograms%\Utilities\Total Commander.lnk' '%_PkgTarget%\Totalcmd\Wincmd32.exe' '' die in der Regel in [ClientAdd] zu finden ist, wird in den Sektion [UserAdd] verschoben und in Shortcut '%_Programs%\Utilities\Total Commander.lnk' '%_PkgTarget%\Totalcmd\Wincmd32.exe' '' konvertiert. Bei den meisten Installationsroutinen werden Verknüpfungen im Systemverzeichnis Alle Benutzer erstellt. Somit können Programme nur für bestimmte Benutzer sichtbar gemacht werden / 02 / deu 66/114

67 Pakete erstellen Registrierungseinträge filtern Bei der Aktion Filter Registry Entries wird das Script auf Registry-Einträge überprüft, die unnötig oder möglicherweise gefährlich sind. Im Menü Configuration > Activate registry Filters wird gesteuert, welche Einträge zu filtern sind. Hinweis In diesem Menü können nur vorhandene Registry-Filter aktiviert oder deaktiviert werden. Um neue Filter hinzuzufügen zu ändern oder zu löschen wählen Sie im Menü Configuration > Options das Register Registry Filters. INI-Dateien konvertieren Mit der Funktion Detect and convert INI Files werden alle Dateien überprüft und diejenigen Dateien automatisch ausgewählt, die vollständig mit dem Iniwrite-Befehl von Columbus geschrieben werden können und die möglicherweise feste Pfade enthalten. Klicken Sie auf eine Datei und der Inhalt wird angezeigt. Hinweis Nicht im Listenfeld aufgeführte Dateien können nicht konvertiert werden. Fehlermeldungen Während der Konvertierung können Fehler auftreten, wenn die INI-Datei ungültige Zeichen enthält oder nicht den INI-Konventionen entspricht. Error Error -1 Beschreibung Allgemeiner Verarbeitungsfehler Error 1 Beide Arten von Trennzeichen werden verwendet, z.b. ' und ". Error 2 Error 7 Datei konnte nicht geöffnet werden. Datei konnte nicht konvertiert werden, da sie keinem Paketkontext zugeordnet werden konnte (Server-, Client- oder User-Teil). Dies kann vorkommen, wenn keine Snapshot-INI vorhanden ist oder wenn eine INI-Datei von einem Verzeichnis abgerufen wurde, für das keine Verzeichnisumsetzung (Directory Relocation) definiert war. Automatisierte Aktionen konfigurieren Tipp Wurden die automatisierten Aktionen bereits ausgeführt, empfehlen wir die Konfiguration so anzupassen, dass die automatisierten Aktionen nur einmal ausgeführt werden. Wählen Sie im Menü Configuration > Options. Markieren Sie die Option Do not show Automated Actions Dialog if the automated actions have been performed before / 02 / deu 67/114

68 Pakete erstellen Manuelle Aktionen Nach Abschluss der automatisierten Aktionen wird das SW-Paket mit manuellen Schritten fertig gestellt. CheckFiles In diesem Abschnitt wird überprüft, ob Dateien, welche nicht zu der eigentlichen Applikation gehören, gelöscht werden können. Des Weiteren können noch allfällige statische Pfade in den Konfigurationsdateien durch bereits vorhandene oder selber definierte Variablen ersetzt werden. Paket dokumentieren Für die Dokumentierung der Pakete ist die Datei Info.rtf vorgesehen. Der Inhalt dieser Datei wird in der Management Console angezeigt. Wählen Sie im Navigator die Funktion Edit Package Documentation. Schreiben Sie in den vorgegebenen Absätzen die notwendigen Informationen. Tipp Wir empfehlen mindestens eine kurze Erklärung zum Bestimmungszweck, Empfänger der Software und kurze Installationshinweise für den Administrator zu verfassen. Dies erleichtert einer anderen Person die Nachvollziehbarkeit. Paket komprimieren Bei grossen Paketen (z.b. Office 2007) wird durch die Komprimierung des Pakets die Installation beschleunigt und der Netzwerkverkehr und die lokalen Speicherplatzanforderungen verringert. Mit der Aktion Compress and save the package werden alle Dateien in den Server- und Cache-Verzeichnissen von einem Paket in ZIP-Dateien verschoben. Jedes Verzeichnis, für den ein eigener copy-befehl in den Scripts vorhanden ist, wird in einer eigenen ZIP-Datei komprimiert und der copy-befehl wird automatisch in einen expand-befehl konvertiert. Hinweis Voraussetzung für diese Aktion ist, dass die Variablen zugeordnet sind. Wählen Sie im Navigator die Funktion Compress and save the package. - oder - Wählen Sie im Menü Actions > Compress Package. Bei dieser Funktion ist es erforderlich, dass Sie zuvor die Variablen zugeordnet haben. Hinweis Kann eine Zeile nicht in einen expand-befehl konvertiert werden oder im Paket wurde das Verzeichnis, nicht aber der copy-befehl gelöscht, wird dies im Activity Log im Register Warnings angezeigt / 02 / deu 68/114

69 Pakete erstellen Kommentarzeilen entfernen Mit dieser Funktion besteht die Möglichkeit, die zu entfernenden Zeilen anzuzeigen. Hinweis Verwenden Sie diese Funktionalität mit Vorsicht. Nach dem Entfernen der Zeilen ist keine Überprüfung mehr möglich, ob z.b. auch erforderliche Einträge herausgefiltert oder auskommentiert wurden. Auskommentierte Zeilen im SW-Paket haben keinerlei Leistungseinbussen zur Folge. Wählen Sie im Menü Actions > Remove remarked lines. Markieren Sie die Aktionen und klicken Sie auf Remove. Option Automated actions Manual disabling Other Beschreibung Betrifft die Zeilen ;PS_RegUser, die durch die automatische Registry-Filterung und Verknüpfungsverschiebung deaktiviert wurden. Betrifft die Zeilen ;PS_LRem, die über den Befehl Disable selected lines im Kontextmenü deaktiviert wurden. Betrifft alle anderen Zeilen, die mit einem Semikolon beginnen. Paket installieren Mit der Aktion Install the package on the current Computer wird das aktuell geladene Paket auf dem Computer eingerichtet. Hinweis Management Client 6 oder höher muss eingerichtet, konfiguriert und aktiv sein. Zeilen austesten Die einzelnen Zeilen der Scripts können manuell auf ihre Richtigkeit überprüft werden, indem sie einzeln ausgeführt werden. Markieren Sie die Scriptzeile und wählen Sie im Kontextmenü Execute selected line(s). l Fehler werden in der Protokolldatei Brainware.log dokumentiert / 02 / deu 69/114

70 Pakete erstellen Kommandozeilenhilfe Die einzelnen Befehlszeilen der Scripts können durch Zuhilfenahme des Command Help erstellt bzw. überprüft werden. Setzen Sie den Cursor auf das Befehlswort und drücken Sie SHIFT+F1. - oder - Wählen Sie im Menü Help > Command Help. 6.7 Paket testen Testen Sie nach abgeschlossener Überarbeitung das SW-Paket auf einem anderen Computer. Überprüfen Sie ob alle in das SW-Paket importierten Dateien und Verzeichnisse Teil der zu installierenden Anwendung sind. Löschen Sie nicht benötigte Verzeichnisse und Dateien (z.b. Readme.txt). Verschieben Sie das SW-Paket in das SW-Depot und führen Sie in der Konsole einen Software-Refresh aus. Weisen Sie das SW-Paket einem Computer mit den entsprechenden Vorbedingungen zu. Führen Sie die Systemtest durch, z.b. installieren und entfernen des SW-Pakete, Funktionalität, Leistung und Stabilität. Empfehlungen für das Testverfahren Die Tests nicht auf dem gleichen Computer ausführen, welcher zur Erstellung verwendet wurde. Die Tests werden nicht vom Paketierer ausgeführt. Der Tester verändert keine SW-Pakete sondern notiert sämtliche Fehlverhalten / 02 / deu 70/114

71 Pakete erstellen 6.8 Wrapper-Paket für MSI erstellen Der MSI Wrapper Wizard in PackageStudio hilft bei der Generierung der Columbus Paketstruktur. So erstellen Sie ein MSI-Paket Starten Sie PackageStudio über Start > Programs > Columbus > PackageStudio. Wählen Sie im Menü File > New MSi wrapped package. Geben Sie an, ob mit dem Paket lediglich eine Standardinstallation ausgeführt wird, oder ob das SW-Paket ausserdem die Reparaturfeatures der MSI-Quelle unterstützen soll. Sie müssen diese Option daraufhin testen, ob die MSI-Setuproutine der Anwendung dieses Feature ordnungsgemäss und den Microsoft-Richtlinien entsprechend unterstützt. Zur Entfernung des SW-Pakets können Sie angeben, ob Sie die eingebaute Entfernungsroutine des msi-setup verwenden möchten, oder ob keine Entfernung angeboten werden soll. Testen Sie die Entfernungsroutinen des MSI-Setup gründlich auf Computern, auf denen eine Vielzahl anderer Software installiert ist, um sicherzugehen, dass keine gemeinsam verwendeten Komponenten entfernt werden. Markieren Sie die Optionen und klicken Sie auf Next / 02 / deu 71/114

72 Pakete erstellen MSI-Datei auswählen Geben Sie an, in welchem Teil des SW-Pakets die Installation ausgeführt werden soll. Geben Sie den Pfad zu der MSI-Datei an. - oder - Klicken Sie auf die Suchen-Icon [...] um die Datei zu suchen. Markieren Sie die gewünschten Optionen und klicken Sie auf Next. Eintrag Server Client User Beschreibung Die MSI-Quelle verbleibt auf dem Paketserver und wird von dort aus installiert. Bei einer Reparatur und Wiederherstellung müssen alle Dateien erneut vom Server abgerufen werden. Die MSI-Quelle wird in das Columbus Cache-Verzeichnis kopiert und von dort aus installiert. Die Reparatur und Wiederherstellung wird durch die lokale Quelle beschleunigt, benötigt jedoch viel Festplattenspeicher. Die MSI-Quelle wird in das Columbus Cache-Verzeichnis kopiert und von dort aus installiert. Die Installation kann interaktiv geschehen, da sie im Kontext des angemeldeten Benutzers ausgeführt wird. Je nach MSI-Setuproutine benötigt der Benutzer möglicherweise Administratorrechte. Die Reparatur und Wiederherstellung wird durch die lokale Quelle beschleunigt, benötigt jedoch viel Festplattenspeicher / 02 / deu 72/114

73 Pakete erstellen Optionen festlegen MSI-Dateien unterstützen eine Vielzahl verschiedener Installationsoptionen (Public Properties) die in einer Transformationsdatei oder als Befehlszeilenparameter bereitgestellt werden können. Einige Anbieter stellen für Ihre Anwendungen Ressourcen- oder Bereitstellungskits zur Verfügung. Diese Tools sollten zur Erstellung angepasster Transformationsdateien verwendet werden. So enthält das Microsoft Office Resource Kit beispielsweise Assistenten, mit denen sich die Transformationsdatei einfacher erstellen lässt, da mehr Informationen über die möglichen Optionen bereitgestellt werden. Der MSI Wrapper Wizard hilft bei der Erstellung einer neuen Transformationsdatei oder bei der Angabe der Befehlszeilenparameter. Mit dem Assistent ist lediglich die Änderung der Public Properties möglich. Dies sind Eigenschaften, die der ursprüngliche Ersteller der MSI-Setupdatei zur Änderung freigegeben hat. Markieren Sie die gewünschte Option und klicken Sie auf Next. Option Apply an existing transform file Create a new transform file Specify command line parameters No options Beschreibung Bestehende Transformationsdatei anwenden. Neue Transformationsdatei erstellen. Befehlszeilenparameter definieren. Keine Option / 02 / deu 73/114

74 Pakete erstellen Eigenschaften angeben Wurde die Option Create a new transform file oder Specify command line parameters markiert, wird das folgende Fenster angezeigt. Hier werden alle Public Properties bearbeitet oder benutzerdefinierte Eigenschaften hinzugefügt, welche in der technischen Dokumentation der Anwendung oder in Ressourcenkits gefunden werden. Nehmen Sie die gewünschten Änderungen vor und klicken Sie auf Next Angeben von Reparaturoptionen MSI-Dateien unterstützen in der Regel eine Vielzahl an Reparaturoptionen, die auch von Columbus unterstützt werden. Markieren Sie die gewünschten Optionen und klicken Sie auf Next / 02 / deu 74/114

75 Pakete erstellen Aufzunehmende Dateien auswählen Eine MSI-Setuproutine liefert möglicherweise mehr Dateien als nur die MSI-Datei. Falls das MSI zusätzliche Dateien benötigt, werden diese in diesem Dialogfenster gewählt. Markieren Sie die entsprechenden Dateien und klicken Sie auf Next Protokolloptionen festlegen Eine externe Protokolldatei für alle MSI-Aktionen kann hier gewählt werden. Markieren Sie eine Option und klicken Sie auf Next / 02 / deu 75/114

76 Pakete erstellen SW-Paket Eigenschaften Die Eigenschaften des SW-Pakets werden in der Konfigurationsdatei Package.ini eingetragen. Der Verzeichnisname, in dem das SW-Paket gespeichert wird, setzt sich aus den Angaben [Identifier.Language\version.patch] zusammen. Geben Sie die notwendigen Angaben ein. Klicken Sie auf Next und die Paketerstellung beginnt. Eintrag Storage location Description Identifier Version Platform Language Beschreibung Verzeichnis in dem das SW-Paket gespeichert wird. Standardmässig ist dies das SW-Depot. Name der paketierten Applikation. Bei der Zuweisung der Pakete in der Management Console ist nur dieser Name sichtbar. Interner, alphanumerischer Name des SW-Pakets der auch die Installationsreihenfolge der SW-Pakete bestimmt. Maximale Länge: 60 Zeichen. Version des SW-Pakets und nicht die Version der Applikation. Maximale Länge: 10 Zeichen. Plattform, auf der das Paket erstellt wurde. Trägt zu einer eindeutigen Paket-ID bei, hat jedoch keine technische Funktionalität. WINNT Windows NT, 2000 und XP WIN32 WIN9x Windows 9x bis Millenium Maximale Länge: 10 Zeichen. Information für die Paketverwaltung. Trägt zu einer eindeutigen Paket-ID bei, hat jedoch keine technische Funktionalität. Maximale Länge: 10 Zeichen. Hinweis Die Gesamtlänge des zusammengesetzten Package-Identifiers (Kurzversion = Identifier_Sprache_Version) ist auf 65 Zeichen, resp. 75 Zeichen bei der langen Version (Identifier_Sprache_Version_Patch) beschränkt. Brainware Empfehlung Für die Nummerierung der Pakete verwenden wir folgende Nummernblöcke / 02 / deu 76/114

77 Pakete erstellen Nummerblock Beschreibung Basiskonfigurationen und -Applikationen Microsoft Produkte Applikationen SAP-Applikationen Technische Applikationen, Treiber, z.b. VMware Oracle Kunden-Applikationen Server-Applikationen Brainware Produkte Abschlussarbeiten Assistent abschliessen Nach erfolgreicher Erstellung des SW-Pakets erscheint das folgende Fenster. Klicken Sie auf Close. l Das SW-Paket wird für weitere Änderungen direkt in PackageStudio geladen / 02 / deu 77/114

78 Pakete erstellen Wichtige Hinweise Wenn der Anbieter der MSI-Installation Tools bereitstellt, mit denen benutzerdefinierte Transformationen erstellt werden können, wie z.b. Bereitstellungs- oder Ressourcenkits, verwenden Sie diese Tools zur Erstellung von Transformationsdateien. Wählen Sie im MSI Wrapper Wizard den Installationstyp Apply an existing transform file aus. Wenn Sie benutzerdefinierte Paketierungsvorlagen ([Default Package]) verwenden, müssen die Paketierungsscripte die folgenden Tags enthalten: Verteilscript: #SERVERMSIADD# und #SERVERMSIREMOVE# Konfigurationsscript: #USERMSIADD#, #CLIENTMSIADD#, #USERMSIREMOVE# und #CLIENTMSIREMOVE#. Wichtig Viele MSI-Installation werden mit einer Setupdatei ausgeliefert, mit dem Systemkomponenten installiert werden, die für die Anwendung erforderlich sind, z.b. Aktualisierungen des Internet Explorer oder die Installshield-Laufzeitumgebung. Wenn Sie den MSI-Befehl mit der MSI-Datei verwenden, werden diese Teile nicht ausgeführt. Dies muss in eigenen Paketen erfolgen / 02 / deu 78/114

79 Anhang K A P I T E L 7 7 Anhang In diesem Kapitel Columbus SWDeploy Columbus PackageMaker Columbus PackageStudio Dieses Kapitel beschreibt eventuelle Spezialfunktionen, eher selten benötigten und fortgeschrittene Funktionen welche bereits grundlegende Columbus Kenntnisse voraussetzen. 7.1 Columbus SWDeploy Emergency Stop Bei einem schwerwiegenden Problem mit den Clients kann das gesamte Columbus System deaktiviert werden. Ab diesem Moment installiert kein Client mehr einen Patch oder ein Software-Paket und es werden auch keine Inventarisierungsaktionen durchgeführt. Angefangen Aktionen werde noch zu Ende geführt. So führen Sie den Emergency Stop aus Wählen Sie in der Konsole im Menü Tools > Turn ON Emergency Stop. In allen Konsolen wechselt die Farbe der Menübalken auf Rot. Dadurch wird allen Administratoren, die gerade mit der Konsole arbeiten angezeigt, dass der Emergency Stop aktiviert worden ist. So deaktivieren Sie den Emergency Stop Wählen Sie im Menü Tools > Emergency Stop > deactivate. l Ab diesem Zeitpunkt nehmen die Clients wieder Befehle entgegen / 02 / deu 79/114

80 Anhang Client-Startparameter Wenn sich der Benutzer am Computer anmeldet, wird Columbus gestartet und neue Pakete werden installiert. Je nach der Konfiguration verbleibt Columbus dann in der Taskleiste oder wird vollständig geschlossen. Für Speziallösungen kann es notwendig sein, Columbus.exe von der Befehlszeile aus aufzurufen, um spezielle Aufgaben auszuführen, wie z. B. das Ausführen der Funktion Helpdesk oder Inventory zur Wiederherstellung eines Pakets. Um dies zu ermöglichen, werden in Columbus Befehlszeilenparameter unterstützt, mit denen Columbus gestartet und sofort zu dem angegebenen Menü oder der angegebenen Aktion gesprungen werden kann. Die folgenden Parameter werden unterstützt:!activity (oder!1)!inventory (oder!2)!inv-hw (oder!201)!inv-sw (oder!202)!inv-ms (oder!203)!process (oder!3)!sod (oder!4)!helpdesk (oder!5)!sendmail (oder!501)!systech (oder!6)!hide (oder!7) Software Shopping Softwareverteilung ist mittlerweile nicht mehr nur eine zentral gesteuerte Aufgabe. Immer mehr Unternehmen gehen dazu über, den Anwendern über Shops die Möglichkeit zu geben, die benötigte Software selbst auszuwählen. Das erlaubt eine differenziertere Steuerung, wer welche Software erhält und führt in Verbindung mit klaren Kostenzuordnungen auch dazu, dass tendenziell weniger Lizenzen benötigt werden. Columbus bietet die folgenden Möglichkeiten an: Software on Demand (siehe "Software on Order" auf Seite 81) Software on Order (auf Seite 81) Software on Demand Einzigartig ist die Möglichkeit, Software zum Shopping und zur sofortigen Installation freizugeben, aber dennoch eine gewisse Kontrolle darüber zu behalten. Der Administrator kann die Zuordnungen in der Konsole überwachen und wenn nötig sogar korrigieren. Auch um die Updates zu den Paketen muss sich der Benutzer nicht selber kümmern. Columbus aktualisiert die installierte Software im Rahmen der normalen Softwareverteilung automatisch mit den neuesten Updates. Daneben kann man die Kontrolle, was installiert werden soll auch völlig dem Endanwender überlassen und die Pakete komplett freigeben. Diese Möglichkeit bietet sich auch für Offline Arbeitsplätze an, die somit z.b. über CD/DVD mit Software versorgt werden können. Software on Demand lässt sich auch nur für gewisse Pakete freischalten und kann somit auch zusätzlich zur zentralen Softwareverteilung eingesetzt werden / 02 / deu 80/114

81 Anhang Voraussetzungen Die zu bestellende Software muss in der Konsole auf Distribution by Software on Demand gesetzt werden. Wechseln Sie in die Ansicht Infrastructure. Markieren Sie das Software-Paket und wählen Sie im Kontextmenü Deploy by > Software on Demand. Der Management Client muss entsprechend konfiguriert sein, um SWDeploy zu erlauben. Software aus dem Shop installieren Software on Demand stellt dem Benutzer eine Art Software Shop zur Verfügung und lässt die Benutzer Software-Pakete und Aktualisierungen von einer Liste vorhandener Software auswählen. Diese Funktion wird für Pakete verwendet, die nicht über den Administrator verwaltet werden, sondern es ist dem Endbenutzer erlaubt, die benötigte Software selbst zu wählen und zu installieren. Die Software-Pakete können Ihnen von verschiedenen Quellen wie einem Festplattenlaufwerk, Netzlaufwerk, CD/DVD oder FTP zur Verfügung gestellt werden. Öffnen Sie den Management Client und klicken Sie auf den Menüpunkt Order. Markieren Sie die Software-Pakete und klicken Sie auf Install Software. Klicken Sie auf Exit and Process um das Fenster zu schliessen und die gewählte Software zu installieren. Software on Order Will man den Bestellprozess überwachen und dem Benutzer lediglich erlauben Software zu beantragen aber sicherstellen, dass diese erst nach einem Genehmigungsverfahren installiert wird, empfiehlt sich die Funktion Software on Order. Im Zusammenspiel mit dem Software Order Prozess auf der Columbus OperationsManager Plattform wird der Softwarebestellvorgang in einen elektronischen Businessprozess eingebettet und mit Freigabe-Workflows administriert und kontrolliert. Software on Order lässt sich auch nur für gewisse Pakete freischalten und kann somit auch zusätzlich zur zentralen Softwareverteilung eingesetzt werden. Voraussetzungen Die zu bestellende Software muss in der Konsole auf Distribution by Software on Order gesetzt werden / 02 / deu 81/114

82 Anhang Wechseln Sie in die Ansicht Infrastructure. Markieren Sie das Software-Paket und wählen Sie im Kontextmenü Deploy by > Software on Order. Im OperationsManager muss die COM Workflow Installation/Konfiguration gemäss der Anleitung im Handbuch OperationsManager durchgeführt sein. Einrichten der Infrastruktur Damit die Kommunikation mit dem Workflowtool OperationsManager gewährleistet wird, muss der COM Interface Agent auf einem Infrastruktur Server aktiviert werden. Dieser stellt den Datenaustausch zwischen den beiden Systemen sicher. Er leitet die Bestellungen, die vom Benutzer über den Management Client erstellt werden an den OperationsManager weiter, um das Genehmigungsverfahren in Gang zu bringen. Nach erfolgter Genehmigung wird die bestellte Software automatisch dem Benutzer und seinem Computer zugewiesen. Bestellung aufgeben In der Regel schaltet man im Client die Funktion Software on Demand frei, worauf der Benutzer eine Liste aller bestellbarer Software angezeigt bekommt und die gewünschte Software durch einfache Auswahl bestellen kann. Alternativ kann diese Liste auch über eine eigens dafür eingerichtete Webseite zur Verfügung gestellt werden. Manage Software Orders Im Normalfall werden Bestellungen mit dem Status ordered an den OperationsManager übergeben und durchlaufen dort das definierte Genehmigungsverfahren. Ist dieses beendet, wird die Bestellung an Columbus zurückgeschickt und erscheint mit dem Status complete in der obigen Liste. Im Falle einer Genehmigung wird die Software automatisch zugewiesen und installiert / 02 / deu 82/114

83 Anhang Columbus Dynamic Config Wenn der Management Client ein Software-Paket oder einen Sicherheits-Patch installiert, bezieht er die Software immer von dem für diesen Computer zuständigen Agent. Diese Zuständigkeiten werden aufgrund fixer Gegebenheiten manuell in der Konsole definiert, indem der Administrator den einzelnen Sites die entsprechenden Agenten zuweist. Damit wird sichergestellt, dass ein Computer am Standort A auch die Software von einem lokalen Server am Standort A bezieht und nicht etwa über einen langsame WAN Verbindung vom Hauptsitz. Es gibt aber in vielen Firmen Mitarbeiter, wie Aussendienstmitarbeiter, Verkäufer oder Manager, die z.b. mit einem Notebook an häufig wechselnden Standorten arbeiten. In so einem Fall würden z.b. neue SW-Pakete über das Firmennetzwerk vom Server am Standort A installiert werden, auch wenn sich der Mitarbeiter gerade am Standort B befindet. So wird es oft notwendig die Konfiguration des Management Clients anzupassen, damit er sich immer an den nächstgelegenen Infrastruktur Server wendet. Diese Änderung an der Konfiguration sollte automatisch geschehen dies ist exakt der Einsatzzweck von Columbus Dynamic Config. Was bewirkt Dynamic Config Mit Dynamic Config kann der Management Client ab Version 6.7 vor dem Ausführen von Operationen, wie Softwareinstallationen, spezielle Konfigurations-Scripts abarbeiten. Der Client ist damit in der Lage neben typischen Konfigurationsmerkmalen auch den Infrastruktur Server zu wählen von welcher Software installiert werden soll. Selbst der Datenbank Server, mit dem ein Computer verbunden werden soll, kann gewechselt werden. Da Dynamic Config bei jeder Ausführung von Columbus Operationen aktiv wird, ist ein Neustart des Computers bei einem Netzwerkwechsel (z.b. von Firmen-LAN auf Wireless Access Point) nicht notwendig. Typische Anwendungsbeispiele für Dynamic Config sind: Beim Wechsel zu verschiedenen Standorten im Firmennetzwerk soll der jeweils nächstliegenden Software Server genutzt werden. Das Notebook soll bei der Arbeit zu Hause keine Softwareverteilung vornehmen Bei einem Massenrollout von Computern, welche mit einem einheitlichen Festplatten-Image aufgesetzt werden, soll sich die Konfiguration bei der Auslieferung automatisch an den jeweiligen Standort anpassen. Einleitung Die normale Konfiguration eines Management Clients erfolgt über die Columbus Konfigurationsdatei Columbus.cfg welche diesem während der Installation mitgegeben wird und deren Werte schliesslich in die Registry eingelesen werden. Die Anpassung dieser Werte kann jederzeit über die Management Console mittels Client Configuration Templates vorgenommen werden. Während diese bisher verfügbaren Konfigurationsmöglichkeiten über Dateien, Registry und Konsole voll erhalten bleiben, kommen zwei neue Konfigurationsoptionen dazu. Die Techniken Konfigurations-Script und Konfigurations Template ermöglichen durch Nutzung beliebiger Scriptlogik die automatische Anpassung eines Clients an unterschiedliche Umgebungen. Die Anpassungen in diesen Scripts und Templates haben grundsätzlich Priorität vor den Einstellungen der Client Configuration Templates in der Management Console. Konfigurations-Script Dies ist ein normales Columbus Script, welches vom Client jedes Mal ausgeführt wird bevor dieser mit der Verarbeitung von Inventardaten und Software-Paketen beginnt. Das Script erlaubt z.b. aufgrund der einem Client zugeteilten IP-Adresse den zu verwendenden Infrastruktur Server für Installationen zu bestimmen / 02 / deu 83/114

84 Anhang Konfigurations-Templates Dies sind nichts anderes als Columbus Konfigurationsdateien (Columbus.cfg), welche in übersichtlicher Form die pro Standort zu ändernden Einstellungen enthalten. Diese Einstellungen werden bei Bedarf über einen neuen Columbus Befehl (ClientConfig template ) geladen. Solche Einstellungen könnten natürlich auch über das oben beschriebene Konfigurations-Script erfolgen, dies wird aber bei grösseren Umgebungen sehr schnell unübersichtlich in der Pflege. Hier sind die Templates die bessere Wahl. Einrichtung und Konfiguration Eine Dynamische Konfiguration besteht in den meisten Fällen aus dem Konfigurationseintrag für den Client, um diese zu aktivieren und den dazugehörenden Scripts und Konfigurationsdateien. Zum Umschalten von Clients auf Dynamic Config empfiehlt sich die Verteilung über ein Columbus Paket. Damit können auch eventuelle Updates gewährleistet werden. Client Konfiguration Damit der Management Client überhaupt einmal nach einem Konfigurations-Script sucht, muss folgender neuer Konfigurationseintrag auf dem Client gesetzt sein: AllowConfigScript=1 Dieser Eintrag kann über eine Columbus Konfigurationsdatei oder einen entsprechenden Registry Eintrag an die gewünschten Computer verteilt werden. Konfigurations-Script Das Format der Script-Datei entspricht einer normalen Columbus Script-Datei (WMS) und muss eine Sektion [Config] enthalten. Inhalt können alle normalen Columbus Befehle und auch eingebettete externe Scripts sein. Das Script läuft unter Columbus Service Rechten und kann sämtliche unter Columbus verfügbaren Befehle und Variablen beinhalten. Das Script muss auf dem Client an folgender Stelle hinterlegt werden: [Columbus Cache Verzeichnis]\$CfgTemplate$\config.wms Beispiel C:\Windows\Cache\$CfgTemplate$\config.wms Beispiel Folgendes Script lädt zuerst eine Basiskonfiguration und dann, je nachdem in welchem IP Segment sich der Computer befindet, noch eine spezielle Standortkonfiguration. [Config] ; Load the Base Configuration ClientConfig 'Base' ; Ensure only Clients in IP Range 10.xxx will perform the following configuration steps If '%_PRIMARYIP_SEGMENT1%'<>'10' Then GOTO END ; Is Client in IP Range 10.1.xxx? If '%_PRIMARYIP_SEGMENT2%'='1' Then ClientConfig 'ZUG' ; Is Client in IP Range 10.2.xxx? If '%_PRIMARYIP_SEGMENT2%'='2' Then ClientConfig 'BERN' :END / 02 / deu 84/114

85 Anhang Konfigurations-Templates Damit ein Management Client an unterschiedlichen Standorten mit unterschiedlicher Konfiguration betrieben werden kann, bietet es sich an im Configuration-Script die jeweilig unterschiedlichen Einstellungen des Clients direkt durch Schreiben in die Registry zu setzen was auch grundsätzlich möglich ist. Da dies bei einer grossen Anzahl unterschiedlicher Einstellungen und Standorte aber schnell einmal unübersichtlich werden kann, wurde zusätzlich die Option von Konfigurations-Templates geschaffen. Diese entsprechen in ihrem Inhalt der bereits bekannten Datei Columbus.cfg und können über einen neuen Befehl (ClientConfig template ) geladen werden. [Config] ClientConfig 'Base' Das Laden erfolgt direkt in diesem Befehl, womit dynamisch Veränderungen möglich werden. Die Ablage der Templates erfolgt in einem Unterverzeichnis des Verzeichnisses in dem sich das Konfigurations-Script befindet. [Columbus Cache Verzeichnis]\$CfgTemplate$\[name]\columbus.cfg Beispiel C:\Windows\Cache\$CfgTemplate$\Base\columbus.cfg Verwendet man das Template lediglich zur Umschaltung verschiedener Umgebungen, nicht aber zur Erstinstallation, so genügt es in diesem nur die Einstellungen abzulegen, welche sich pro Standort wirklich ändern. Nach dem Grundsatz so viel wie nötig so wenig wie möglich erspart man sich damit später die Anpassung aller Templates falls eine Grundeinstellung geändert werden soll. Da die Templates und auch das Configuration-Script auf der lokalen Festplatte eines Computers liegen, werden diese typischerweise über Columbus Pakete aktualisiert, wenn dies notwendig wird. Zurücksetzen der Konfiguration Wenn ein Management Client mit Dynamic Config betrieben wird, dann bezieht er seine Konfiguration von lokal gespeicherten Templates. Damit wird ein in der Datenbank zugewiesenes Template übersteuert. Zum Zurücksetzen auf die Standardkonfiguration, z.b. wenn sich der Computer wieder an seinem ursprünglichen Standort befindet, hat man folgende Möglichkeiten. Man kann ein lokales Template mit der Standardkonfiguration bereitstellen. Bei Änderungen muss allerdings eine neue Konfigurationsdatei erzeugt und z.b. mit einem Paket auf die entsprechenden Computer verteilt werden. Falls dieser administrative Aufwand zu hoch ist, besteht auch die Möglichkeit, wieder auf ein in der Konsole dem Computer zugewiesenes Client Config Template zurückzuschalten. Hierzu erstellt man im Konfigurations-Script den Befehl ClientConfig '' mit leerem Parameter, also ohne Template Namen. Damit wird der Client angewiesen ein in der Konsole zugeordnetes Config Template neu einzulesen. Das heisst aber auch, dass er dieses beim Server holt und so Last erzeugt. Wenn sehr viele Computer diese Funktion verwenden, sollte man sich aus Performancegründen überlegen, ob dies z.b. wirklich bei jedem Durchlauf gemacht werden muss / 02 / deu 85/114

86 Anhang Konfigurationsparameter Infrastruktur Server Zuweisung Die Zuweisung der Infrastruktur Server welche z.b. einem Client mit Software beliefern, erfolgt bei Columbus normalerweise aufgrund der Site, in der sich der Computer in der Konsole und damit der Datenbank befindet (ComputerHome). Dies bedeutet also, dass wir zur Steuerung vom Client aus zusätzliche Einträge benötigen, die den automatisch zugeordneten Infrastruktur Server übersteuern können. Diese Möglichkeit wurde durch Einführung neuer Konfigurationsparameter geschaffen, welche sowohl über Konfigurationsdateien Columbus.cfg als auch die Scripts und Templates gesetzt werden können. Konfigurationseintrag _RoamingSWSource _RoamingPMSource _RoamingInvSource Beschreibung Definiert den Namen des Software Servers welcher genutzt werden soll Definiert den Namen des Patch Management Servers welcher genutzt werden soll Definiert den Namen des Inventar Servers welcher genutzt werden soll Die Einträge werden schlussendlich auf dem Computer in der Registry gesetzt. Sie müssen unter folgendem Schlüssel gesetzt sein: HKLocal_MACHINE\Software\Brainware\Columbus\7\Client\Config\Caching Wenn man das Software-Depot auf einem Infrastruktur Server gesplittet hat, so kann man die einzelnen Instanzen unter dem in der Konsole ersichtlichen Namen in der Form ServerName[Description] individuell adressieren. Wichtig Wenn _Roaming... Servereinträge einmal auf einem Client gesetzt wurden, so ist die Zuordnung von Infrastruktur Servern an der Konsole wirkungslos, solange man die Einträge auf dem Client nicht löscht oder zumindest auf einen leeren Wert ('') setzt! Es ist also beim Einsatz der Konfigurations Templates idealerweise so vorzugehen, dass ein Client jeweils ein Basistemplate mit leeren _Roaming... Einträgen hat, welches in seiner Standardsite genutzt wird und dann jeweilige Lokationstemplates mit den gewünschten Einstellungen. Damit ist sichergestellt, dass immer die Einstellungen aus der Konsole gelten, falls eine Bedingung im Konfigurations-Script einmal nicht greifen sollte. Locationvariablen Um den Zugriff auf die IP-Adresse eines Computers im Configuration-Script zu erleichtern und so standortabhängige Konfigurations-Entscheide fällen zu können, wurden neue Variablen im Management Client eingeführt, welche auch in beliebigen anderen Columbus Paketen genutzt werden können: Variable %_PRIMARYIP_SEGMENT1% %_PRIMARYIP_SEGMENT2% %_PRIMARYIP_SEGMENT3% %_PRIMARYIP_SEGMENT4% %_PRIMARYIP_ADDRESS% Beschreibung 1. Segment der IP-Adresse 2. Segment der IP-Adresse 3. Segment der IP-Adresse 4. Segment der IP-Adresse Komplette primäre IP-Adresse Hinweis Im Unterschied zu anderen Columbus Variablen werden diese immer dynamisch aufgelöst und daher nicht in der Registry unter dem Key Variables gespeichert / 02 / deu 86/114

87 Anhang Reihenfolge der Auswertung Da das System die gegenseitige Überlagerung von Einstellungen erlaubt ist es wichtig deren Reihenfolge der Auswertung und damit die Prioritäten zu verstehen. Die Daten werden in folgender Reihenfolge ausgewertet: Bestehende Registry-Konfigurationseinträge Konfigurations-Script (kann dynamisch Werte der Konfiguration verändern) ClientConfig Template welches über die Management Console zugewiesen wurde Lokales Konfigurations Template Über _Roaming... Einträge zugeordnete SW-, Inventory- und PatchMgmt Server Hinweis Hierbei gewinnt der jeweils LETZTE Eintrag in dieser aufgeführten Liste. Performanceauswirkungen Die Nutzung der dynamischen Konfiguration erfordert einige Verarbeitungslogik seitens des Clients womit das Startverhalten zeitlich leicht verzögert wird und mehrere zusätzliche Datenbankabfragen des Clients erfolgen. Will man diese Technik also auf sämtlichen und nicht nur den mobilen Geräten nutzen, so hat dies einen leicht erhöhten Aufwand seitens des Datenbankservers und der Netzwerkast zur Folge / 02 / deu 87/114

88 Anhang Befehlszeilenprogramme DOCMD.exe Erforderliche Dateien DOCMD.exe, Columbus.dll Funktionalität Ermöglicht das Starten eines beliebigen Columbus Befehls von der Befehlszeile oder einer Batchdatei aus. Der Befehl wird gleich wie einem Columbus Script angegeben. Erforderliche Rechte Abhängig von der mit diesem Befehl auszuführenden Operation. Der Benutzer muss über die entsprechenden Rechte verfügen, da der Befehl von diesem Tool im Kontext des angemeldeten Benutzers ausgeführt wird. Beispiel DOCMD rd 'c:\test' DOCMD IniWrite 'MySektion' 'MyKey' 'Value' '%_Windows%\Win.ini' DOSCR.exe Erforderliche Dateien DOSCR.exe, Columbus.dll Funktionalität Ähnlich dem DOCMD-Tool ermöglicht dieses Tool die Ausführung vollständiger Scriptdateien von einer Batchdatei aus. Die Scriptdatei wie auch der Abschnitt müssen in einfachen 'Anführungszeichen' eingeschlossen sein. Erforderliche Rechte Abhängig von der im Script auszuführenden Operation. Der Benutzer muss über die entsprechenden Rechte verfügen, da das Script von diesem Tool im Kontext des angemeldeten Benutzers ausgeführt wird. Beispiel DOSCR 'c:\test\myscript.wms' 'setup' Bandbreitensteuerung Software, welche über das Netzwerk verteilt wird, kann bei hohem Datenaufkommen signifikante Performance-Limitierungen für andere Benutzer und Systeme bewirken. Columbus unterstützt aus diesem Grunde die Möglichkeit, den Datendurchsatz des Software-Verteilsystems pro Netzwerkclient spezifisch einzustellen. Diese Einstellungen können sowohl als permanente Limitierung als auch als temporäre Limitierung zugewiesen werden. Temporäre Bandbreitenlimitierung / 02 / deu 88/114

89 Anhang Die temporäre Bandbreitenlimitierung wird direkt über das Menü Limit Bandwidth Usage einer beliebigen Anzahl Clients gleichzeitig zugewiesen. Temporary bedeutet hierbei, dass die Management Clients diese Einstellung per sofort übernehmen (auch mitten während einer laufenden Verteilung), und diese Limitierung solange beibehalten, bis entweder der Client das nächste Mal neu gestartet wird, oder ein Benutzer sich an diesem Gerät neu anmeldet. Dies bedeutet, dass Sie, wenn erforderlich, in das Geschehen eingreifen können, ohne aber später diese Einstellungen manuell wieder rückgängig machen zu müssen. Fixe Bandbreitenlimitierung Soll der Management Client auf einem Computer permanent nur mit limitiertem Tempo operieren, weil z.b. das Gerät nur über eine 128 KB Anbindung verfügt, welche mit anderen Programmen und Geräten geteilt werden muss, so bietet sich der Einsatz einer fixen Bandbreitenlimitierung an. Diese wird direkt in den Einstellungen des Management Clients vorgenommen. Näheres hierzu erfahren Sie in der Dokumentation der Management Client Configuration. 7.2 Columbus PackageMaker PackageMaker lässt sich vollständig an die technischen Anforderungen und Firmenstandards anpassen. Die Konfiguration wird an zwei Orten geändert. Grundlegende Einstellungen über das Dialogfenster Optionen (auf Seite 89). Werte für die Paketerstellung im Dialogfenster Paketeigenschaften (auf Seite 93). Die Aufteilung in 2 Konfigurationsbereiche ist notwendig, da PackageMaker die Erstellung verschiedener Paketarten unterstützt. Bei diesen müssen unterschiedliche Standardwerte für die Paketierung konfiguriert werden, die allgemeinen Optionen bleiben jedoch für alle SW-Paketarten gleich Optionen Der Button Options wird nur auf dem ersten Dialogfenster angezeigt. So ändern Sie die allgemeinen Optionen Starten Sie PackageMaker über Start > Programs > Columbus > PackageMaker. Klicken Sie auf den Button Options und das Dialogfenster öffnet sich / 02 / deu 89/114

90 Anhang Generic Wechseln Sie in das Register Generic. Ändern Sie die Einstellungen und klicken Sie auf OK - oder - Klicken Sie auf Advanced für weitere Einstellungen. Eigenschaft Character Set Drives to watch Author Language Save file format Show details on screen Beschreibung Verwendeter Zeichensatz, z.b. SHIFTJIS_CHARSET für japanische Umgebungen, DEFAULT_CHARSET für Mittel- und Westeuropa oder USA. Laufwerke für die standardmässig ein Snapshot aufgenommen wird. Eingabe der Laufwerksbuchstaben ohne ':' z.b. CJU für die Laufwerke C:\, J:\ und U:\. Name des Paketierers. Diese Informationen werden im Header-Abschnitt von Package.ini und Package.wms angezeigt. Name der Sprache auf welche umgestellt werden soll, z.b. DE. Aktuell stehen noch keine Sprachressourcen zur Verfügung, diese Option hat somit keine Auswirkung auf das SW-Paket. Format in welchem die Snapshots / Packages gespeichert werden, ANSI, Unicode oder AutoDetect. Bei Autodetect werden Dateien wenn nötig im Unicode-Format gespeichert (wenn sie Unicode beinhalten), ansonsten im ANSI-Format. Ist diese Option aktiv, wird beim Aufzeichnen von Registry und Dateien der aktuelle Pfad angezeigt / 02 / deu 90/114

91 Anhang Directories Wechseln Sie in das Register Directories. Ändern Sie die Verzeichnisoptionen und klicken Sie auf OK oder Advanced. Feld Location of Package- Studio Parameters for PackageStudio Location of Snapshots Beschreibung Gibt an wo PackageStudio gespeichert ist. So wird PackageStudio direkt mit dem neu erstellten SW-Paket gestartet werden. Optionen für den Start von PackageStudio. Die Befehlszeilenschalter sind im Handbuch PackageStudio beschrieben. Standardverzeichnis für die Speicherung der Snapshots. Bleibt dieses Feld leer, werden die Snapshots im Unterverzeichnis Snapshots des Verzeichnisses erstellt, von dem aus PackageMaker gestartet wurde. Location of Packages Standardverzeichnis für die Speicherung der Pakete. Bleibt dieses Feld leer, werden die Pakete im Unterverzeichnis Packages des Verzeichnisses erstellt, von dem aus PackageMaker gestartet wurde / 02 / deu 91/114

92 Anhang Value lists Im Register Value lists besteht die Möglichkeit die Standardwerte für die Dropdownlisten zu verändern. Damit besteht die Möglichkeit, PackageMaker vollständig an Ihre Unternehmensstandards anzupassen. Klicken Sie auf den Button Advanced und die Registerkarte Value Lists wird angezeigt. Markieren Sie eine Feldbezeichung und geben Sie die Werte ein. l Ein Standardwert wird definiert, indem ein *-Zeichen an den Anfang und das Ende eines Wertes gesetzt wird. Markieren Sie die Chechbox Allow values from list only um eine direkte Werteingabe zu verhindern. Werden keine Werte angeben, werden die folgenden Standardwerte verwendet: Feld Standardwert Name of before snapshot Before Name of after snapshot After Package Version 01 Package Patch 0 Package Platform Abhängig vom Betriebssystem WINNT bei Windows NT/2000/XP/2003 WIN9X bei Windows 95/98/ME. Package Language IE Hinweis Das Feld Platform unterstützt kein Standardwert. Der verwendete Wert basiert jeweils auf dem Betriebssystem des Computers, auf dem der Snapshot aufgenommen wird / 02 / deu 92/114

93 Anhang Text/Ini files In früheren Versionen wurden alle Dateien mit der Endung *.ini im Verzeichnis %Windir% als INI-Dateien behandelt, INI-Dateien in anderen Verzeichnissen jedoch nicht. Im Register Text/Ini files besteht nun die Möglichkeit zu definieren, welche Dateien als INI-Dateien behandelt werden sollen und welche nicht. Wechseln Sie in das Register Text/Ini files. Klicken Sie auf Add um eine INI-Datei im Feld Ini files oder Text files hinzuzufügen. - oder - Markieren Sie eine Datei und klicken Sie auf Delete um eine Datei aus der Liste zu entfernen. Weitere Optionen Die folgende Option kann nicht über das GUI konfiguriert werden. Support für 64-Bit-Betriebssystem In der Datei PkgMaker.cfg wird definiert, ob SW-Pakete mit 64-Bit Support erstellt werden. [Options] Support64-BitOS=x Mögliche Werte sind: Wert Beschreibung 0 Kein Support für 64-Bit 1 Default-Wert, wird PackageMaker auf einem 64-Bit-Betriebssystem gestartet, so wird ein SW-Paket erstellt welches vollen 64-Bit-Support beinhaltet / 02 / deu 93/114

94 Anhang Paketeigenschaften Die Einstellungen für die Paketgenerierung werden im Dialogfenster Package Properties über den Button Advanced geändert. Wichtig Beachten Sie die Warnmeldungen in den Dialogfenstern und ändern Sie nur mit Vorsicht, das das SW-Paket ansonsten nicht richtig funktioniert. Klicken Sie im Dialogfenster Package Properties auf den Button Advanced. l Die zusätzliche Register Filter, Directory relocations, Package.ini, Delivery-Script und Configuration-Script werden angezeigt. Der Button Save file ist nur aktiv, wenn Einstellungen geändert wurden. Die Änderungen werden in verschiedene Konfigurationsdateien oder -verzeichnisse geschrieben, und sind für die Paketgenerierung aktiviert. Wird PackageMaker in ein anderes Verzeichnis kopiert (siehe "PackageMaker verteilen" auf Seite 61), müssen auch die Konfigurationsdateien und -verzeichnisse kopiert werden, um die Änderungen zu übernehmen. Filter PackageMaker verfügt über eine präzise Änderungserkennung und verzeichnet alle Dateien sowie fast alle Hivestrukturen der Registry in einem Bericht. Der Vorteil ist, dass sogar SW-Pakete mit Systemgeräten wie Drucker, Modems, Netzwerkkarten oder Monitortreibern erstellt werden können. Ein Nachteil ist jedoch, dass ein SW-Paket Dateien und Registry-Einträge enthalten kann welche nicht benötigt oder nicht verwendet werden sollten. Mit Filtern wird PackageMaker angewiesen, welche Dateien und welche Einträge in den INI-Dateien und der Registry nicht in das SW-Paket aufgenommen werden sollen. Tipp PackageMaker verwendet eine Reihe integrierter Filter welche ein Minimum an Filtern darstellen. Wir empfehlen diese zu aktivieren / 02 / deu 94/114

95 Anhang Filter bearbeiten In der Filter-Datei werden Dateien, Verzeichnisse und Registry-Einträge von der Überwachung durch PackageMaker ausgeschlossen. Diese Einträge werden bei der Paketgenerierung ignoriert. Die Verwendung von Windows-Umgebungsvariablen wie z.b. %SystemRoot% sind zulässig. Wechseln Sie in das Register Filter. l Die integrierten Standardfilter werden angezeigt. Fügen Sie eigene Datei- oder Registry-Filter hinzu oder ändern/löschen Sie vorhandene Filter. l Der Button Save File wird aktiv. Klicken Sie auf den Button Save File. l Die Änderungen werden in der Datei PkgMaker_Filter.txt im Applikationsverzeichnis gespeichert. Änderungen wieder löschen Klicken Sie auf den Button Get Defaults. l Die Datei PkgMaker_Filter.txt wird zusammen mit allen Änderungen gelöscht. l Die integrierten Standardfilter werden wieder angezeigt und verwendet. PkgMaker_Filter.txt Wird ein Standardfilter geändert, wird die Datei PkgMaker_Filter.txt im Applikationsverzeichnis von PackageMaker erstellt. Wenn diese Filter-Datei vorhanden ist, werden nur die Filter in dieser Datei verwendet. Die Standardfilter werden immer von dieser Filter-Datei überschrieben. Ist die Filter-Datei z.b. leer, ist sämtliche Filterung deaktiviert. Mit den Abschnitten [Files], [Registry Keys] und [Ini files] wird PackageMaker angewiesen, welche Einträge nach dem Vergleich zweier Snapshots zu filtern sind (vor der Paketgenerierung). Um diesen Vergleich zu beschleunigen, ist der [PRE Registry Keys] Teil vorhanden, der für die Filterung von Einträgen VOR dem Vergleichen der Snapshots verwendet wird. Wird während der Installation bzw. Konfiguration einer Applikation ein Neustart durchgeführt, verbessert sich die Leistung, wenn die Einträge CONTROLSET00x für die Registry-Keys unter [PRE REGISTRY KEY] aktiviert bleiben. Wird kein Neustart durchgeführt, führt eine Deaktivierung der Einträge zu einer besseren Leistung / 02 / deu 95/114

96 Anhang Hinweis Gespeicherte Snapshots enthalten immer die vollständigen Informationen. Die Filterung (auch die Vorabfilter) werden bei der Paketgenerierung verwendet, nachdem die Snapshot-Daten aufgezeichnet wurden. Directory relocations Mit der Verzeichnisumsetzung (Directory relocations) wird PackageMaker angewiesen, in welchem Bereich eines SW-Pakete die Dateien gespeichert werden. Je nach Umgebung und Anforderungen müssen die Verzeichnisumsetzungen geändert werden. In den meisten Fällen ist für den Benutzer ein Stammverzeichnis (Basislaufwerk) für die benutzerspezifischen Dateien konfiguriert. Einige Applikationen installieren Benutzerdateien in dieses Verzeichnis, welches somit in die Liste der zu scannenden Laufwerke aufgenommen werden muss. Standard Applikationspfad Bei der vorkonfigurierten Standard-Verzeichnisumsetzung wird vom Fall ausgegangen, dass die Applikation im Verzeichnis für die Programmdateien C:\Program Files abgelegt und das SW-Paket immer lokal auf einem Computer installiert wird. Klicken Sie auf den Button Get defaults. Bestätigen Sie die Frage nach dem Standardverzeichnis mit Yes. Klicken Sie auf den Button Save File. Die Verzeichnisumsetzung könnte dann wie folgt aussehen: ; Syntax: Drive:\[Directory]::directory in packagestructure::s C U (Server Client or User part)[::%variable%(for variable replacement in PackageStudio)] ; change the driveletter to your user homedrive ; U:\::CACHE\USER\USERHOME::U:: {Enter variable to be used here} In der auskommentierten Zeile wird empfohlen, das Stammverzeichnis des Benutzers anzugeben. Angepasste Applikationspfade Einige Firmen verwenden das Standard-Applikationsverzeichnis C:\Program Files nicht, da sie eine Verzeichnisbenennung in 8.3-Notation benötigen (z.b. C:\Apps), um alte Applikationen zu unterstützen und paketierte von manuellen Installationen zu trennen. Im folgenden Beispiel werden die Applikationen im Verzeichnis C:\Apps installiert und das Stammverzeichnis des Benutzers ist U:\. Klicken Sie auf den Button Get defaults. Verneinen Sie die Frage nach dem Standardverzeichnis mit No. Die Verzeichnisumsetzung könnte dann wie folgt aussehen: ; Syntax: Drive:\[Directory]::directory in packagestructure::s C U (Server Client or User part)[::%variable%(for variable replacement in PackageStudio)] ; change the driveletter to your user homedrive ; U:\::CACHE\USER\USERHOME::U:: {Enter variable to be used here} ; Change the path, where you install applications. This points to the "application path" in the client configuration C:\APPS::SERVER\APPS::S::%_PkgTarget% C:\Program Files\Common Files::Cache\Client\CommonFiles::C::%_CommonFiles% C:\PROGRA~1\COMMON~1::Cache\Client\CommonFiles::C::%_sCommonFiles% C:\Program Files::Cache\Client\ProgramFiles::C::%_ProgramFiles% C:\PROGRA~1::Cache\Client\ProgramFiles::C::%_sProgramFiles% Ändern Sie diese Einträge und/oder fügen Sie zusätzliche Einträge hinzu / 02 / deu 96/114

97 Anhang Aktivieren Sie die Zeile mit dem Benutzerlaufwerk. Ersetzen Sie U:\ durch den Laufwerkbuchstaben des Stammverzeichnisses. Klicken Sie auf den Button Save File. Tipp Bei administrativen Setups auf einem Netzlaufwerk kann es vorkommen, dass weiterhin Dateien im Verzeichnis C:\Program Files gespeichert werden. Wir empfehlen deshalb, die Applikation nicht im Standardverzeichnis, sondern in einem speziellen Verzeichnis (z.b. C:\Apps\Application) zu installieren damit solche Probleme schon während dem Paketierungsprozess erkannt und behandelt werden können. Das Verzeichnis C:\Apps muss auf dem Management Client als Application Path konfiguriert werden. C:\Apps::Server\Apps::S::%_PkgTarget% Alle Dateien und Verzeichnisse, die unter C:\Apps erstellt werden, werden in das Server-Verzeichnis vom SW-Paket kopiert, das zum Server-Kontext gehört. Wird das SW-Paket in PackageStudio geöffnet, werden durch die automatisierte Aktion Apply Variables alle Vorkommen von C:\Apps durch die Variable %_PkgTarget% ersetzt, die auf jedem Columbus System immer verfügbar ist. Ist ein Management Client mit einem anderen Applikationspfad konfiguriert, z.b. C:\Progs, werden alle SW-Pakete automatisch in C:\Progs installiert. Wird das SW-Paket auf einem Dateiserver installiert, zeigt die Variable auf \\myserver\myshare. Angepasstes Benutzer-Stammverzeichnis Tipp Wir empfehlen, das Stammverzeichnis des Benutzers anzugeben. In der Standardeinstellung sind folgende auskommentierten Zeilen enthalten. ; change the driveletter to your user homedrive ; U:\::CACHE\USER\USERHOME::U:: {Enter variable to be used here} Entfernen Sie das Kommentarzeichen am Anfang der Zeile. Ersetzen Sie U:\ durch den Laufwerkbuchstaben des des Stammverzeichnisses. Tipp Wird eine Variable für das Stammverzeichnis des Benutzers angegeben, empfehlen wir PackageStudio anzuweisen, den Laufwerksbuchstaben U:\ in den Scripten durch die Variable zu ersetzen / 02 / deu 97/114

98 Anhang Ersetzen Sie die Zeichenfolge {Enter variable to be used here} durch den Namen der Variable (eingeschlossen in das Prozentzeichen %). U:\::CACHE\USER\USERHOME::U::%UserData% Alle Dateien und Verzeichnisse, die auf Laufwerk U:\ hinzugefügt oder geändert wurden, werden von PackageMaker im Paketverzeichnis \Cache\User\Userhome abgelegt. Diese gehören zum User-Kontext des SW-Pakete. In PackageStudio wird U:\ durch die Variable %UserData% ersetzt. Beispiel Das Stammverzeichnis des Benutzers ist H:\ für welches keine Variable verwendet wird. Ersetzen Sie U:\ durch H:\ und entfernen Sie die Zeichenfolge {Enter variable to be used here}. H:\::CACHE\USER\USERHOME::U:: Syntax Drive:\[Directory]::Packagedirectory::Context[::%Variable%] Parameter Drive Packagedirectory Context Variable Beschreibung Das überwachte Laufwerk oder Verzeichnis (Laufwerksangabe muss auf \ enden) Der Pfad, unter dem das SW-Paket abzulegen ist: SERVER\Directory CACHE\USER\Directory CACHE\CLIENT\Directory Paket-Teil, in dem die copy-anweisung eingefügt wird: S=ServerPart (ServerAdd/Remove-Abschnitt) C=ClientPart (ClientAdd/Remove-Abschnitt) U=UserPart (UserAdd/Remove-Abschnitt) Wird von PackageStudio bei der Ersetzung der festen Laufwerkseinträge verwendet (optional). Hinweis Wird ein ganzes Laufwerk zugewiesen (mit allen Unterverzeichnissen), muss am Ende ein \ gesetzt werden, auch wenn die verwendete Variable keinen Backslash hat / 02 / deu 98/114

99 Anhang Wird diese Informationen nicht angegeben, werden nur die in PackageMaker integrierten Verzeichnisumsetzungen verwendet. Alle Dateien, die sich auf anderen Laufwerken als C:\ befinden, werden nicht zugewiesen. In der Standardeinstellung werden die Verzeichnisse C:\Program Files und C:\Program Files\Common Files im Server-Kontext abgelegt. Obwohl dies technisch nicht einwandfrei ist, lässt sich dadurch bei lokalen Installationen Festplattenspeicher sparen. Verzeichnisumsetzung zurücksetzen Klicken Sie auf den Button Get defaults. Bestätigen Sie die Frage nach dem Standardverzeichnis mit Yes, um das SW-Paket für die Unterstützung einer lokalen Installation zu optimieren. No, um die serverbasierte Installation des SW-Pakete zu unterstützen. Geben Sie das Basislaufwerk (Stammverzeichnis) des Benutzers an. Klicken Sie auf Save File. Script-Vorlagen Dies sind Vorlagen für die zu erstellenden SW-Pakete. Achten Sie darauf, dass Sie ausschliesslich Informationen hinzufügen, da das Ändern oder Löschen von Einträgen zu einem unvollständigen SW-Paket führen kann. Geänderte Vorlagen werden im Applikationsverzeichnis von PackageMaker als Unterverzeichnis von [Default Package]\*.* (siehe "Default Package" auf Seite 103) gespeichert. Package.ini Im Register Package.ini wird die Standardvorlage für die Initialisierungsdatei Package.ini angezeigt. Wechseln Sie in das Register Package.ini. Drücken Sie die Taste TAB oder klicken Sie in das Bearbeitungsfenster. Hinweis Die Schlüssel Identifier, Language, Version, Patch und Platform im [Package] Teil bilden den eindeutigen Namen des SW-Pakete und müssen immer vorhanden sein. Das SW-Paket ist ansonsten nicht lauffähig. Bearbeiten Sie die Datei, z.b. Kommentare löschen, den Header anpassen oder die bedingte Verwendung (Conditional Usage) standardmässig aktivieren. l Ist der Schlüssel Description nicht vorhanden oder leer ist, wird in der SW-Paket-Liste der Management Console eine leere Zeile angezeigt, wodurch die Zuweisung des SW-Pakete erheblich erschwert wird / 02 / deu 99/114

100 Anhang Klicken Sie auf den Button Save file. l Im Applikationsverzeichnis von PackageMaker wird das Unterverzeichnis \[Default Package] erstellt. l Die Änderungen werden in der neuen Vorlagendatei Package.ini in diesem Verzeichnis gespeichert. Beim Speichern der Datei wird im Applikationsverzeichnis von PackageMaker das Unterverzeichnis \[Default Package] erstellt. Die neue Vorlage wird unter dem Namen Package.ini in diesem Verzeichnis gespeichert. Delivery script Das Delivery-Script des SW-Pakete erhält den Namen Package.wms und wird im Stammverzeichnis des SW-Pakete abgelegt, d.h. im gleichen Verzeichnis wie die Datei Package.ini. Das Script enthält einen [ServerAdd] und [ServerRemove] Teil. Durch den Abschnitt ServerAdd werden die Applikationsverzeichnisse auf das Zielsystem kopiert, und der Client- und User-Teil des SW-Pakete wird in das lokale Cache-Verzeichnis kopiert. Auf diese Weise werden alle Dateien an das Zielsystem geliefert. Wechseln Sie in das Register Delivery-Script. Drücken Sie die Taste TAB oder klicken Sie in das Bearbeitungsfenster um die Datei zu bearbeiten. Bearbeiten Sie die Datei, z.b. Kommentare löschen oder Befehle wie die Überprüfung auf freien Speicherplatz oder die Erkennung der Zielplattform hinzufügen. if diskfree 'C:'<' ' then exit 'Not enough diskspace' if '%_OSTechnology%'='WIN9X' then exit 'Wrong OS, target must have Windows NT/2000/XP installed' if not '%_OSMAjorVersion%'='5' then Exit 'Windows 2000 must be installed' Klicken Sie auf den Button Save file. l Im Applikationsverzeichnis von PackageMaker wird das Unterverzeichnis \[Default Package] erstellt / 02 / deu 100/114

101 Anhang l Die Änderungen werden in der neuen Vorlagendatei Package.wms in diesem Verzeichnis gespeichert. Beim Speichern der Datei wird im Applikationsverzeichnis von PackageMaker das Unterverzeichnis \[Default Package] erstellt. Die neue Vorlage wird unter dem Namen Package.wms in diesem Verzeichnis gespeichert. Änderungen wieder löschen Klicken Sie auf den Button Get Defaults. l Die Datei Package.wms wird zusammen mit allen Änderungen gelöscht. l Die integrierten Standardfilter werden wieder angezeigt und verwendet. Configuration script Das Konfigurationsscript Package.wms wird im Unterverzeichnis \Cache des SW-Pakete gespeichert, demselben Verzeichnis wie für den User- und Client-Teil. Das Script enthält die Abschnitte [UserAdd/Remove] und [ClientAdd/Remove] und kann relativ gross werden. Im Abschnit [ClientAdd] wird der Computer-Teil der Applikation installiert. Die Dateien werden in das Windows- und das Windows-System-Verzeichnis kopiert, und die Registry-Einträge für den Computer werden erstellt. Im Abschnitt [UserAdd] wird der Benutzer-Teil der Applikation installiert. Es werden Dateien in das Benutzerprofil kopiert, Verknüpfungen im Startmenü generiert und die Benutzer Registry-Einträge erstellt. Wechseln Sie in das Register Configurations script. Drücken Sie die Taste TAB oder klicken Sie in das Bearbeitungsfenster um die Datei zu bearbeiten. Hinweis Einige Zeilen dürfen nicht geändert oder gelöscht werden, da diese möglicherweise von PackageStudio verwendet werden. Bearbeiten Sie die Datei, z.b. Kommentare löschen oder Befehle wie die Überprüfung auf freien Speicherplatz oder die Erkennung der Zielplattform hinzufügen. if diskfree 'U:'<' ' then exit 'Not enough diskspace for user' Klicken Sie auf den Button Save file. l Im Applikationsverzeichnis von PackageMaker wird das Unterverzeichnis \[Default Package] erstellt / 02 / deu 101/114

102 Anhang l Die Änderungen werden in der neuen Vorlagendatei Package.wms in diesem Verzeichnis gespeichert. Beim Speichern der Datei wird im Applikationsverzeichnis von PackageMaker das Unterverzeichnis \[Default Package] erstellt. Die neue Vorlage wird unter dem Namen Package.wms in diesem Verzeichnis gespeichert. Änderungen wieder löschen Klicken Sie auf den Button Get Defaults. l Die Datei Package.wms wird zusammen mit allen Änderungen gelöscht. l Die integrierten Standardfilter werden wieder angezeigt und verwendet Konfigurationsdateien Alle Konfigurationsdateien von PackageMaker befinden sich in demselben Verzeichnis wie die ausführbare Datei PackageMaker.exe. Es werden keine Konfigurationsinformationen in der Registry gespeichert, da andernfalls eine Setuproutine notwendig wäre. PkgMaker.cfg Nach dem ersten Start von PackageMaker wird die Datei PkgMaker.cfg erstellt. Diese Datei enthält die grundlegenden Einstellungen für PackageMaker, wie z.b. die konfigurierten Optionen, Wertelisten, Standardlaufwerke, Einstellungen und Verzeichnisumsetzungen. Diese Optionen können und sollten innerhalb des Dialogfeldes für die Optionen bearbeitet werden. Der [Directory Relocations] Teil wird erst angelegt, wenn die Einstellungen für die Verzeichnisumsetzung bearbeitet wurden. [Version] CurrentVersion= [Options] SkipWelcomeScreen=1 DefaultAuthor=MyUserName DrivesToWatch=C CharSet=1 CheckPermissions=0 CheckPermissionsonNewObjects= / 02 / deu 102/114

103 Anhang [PkgStudio] Path= Parameters= [Inifiles] 0=%Windir%\*.ini [Textfiles] 0=%Windir%\System32\drivers\etc\hosts 1=%Windir%\System32\drivers\etc\services Default Package Wenn jedes SW-Paket zusätzliche Dateien oder Verzeichnisse z.b. für die Dokumentation enthalten soll, können diese im Unterverzeichnis [Default Package] des Applikationsverzeichnis abgelegt werden, in dem sich auch PkgMaker.exe befindet. Alle zusätzlichen Dateien und Unterverzeichnisse im Verzeichnis [Default package] werden ohne Änderungen in das neue SW-Paket kopiert. Alle Attribute und Strukturen werden beibehalten Verwendete Variablen in PackageMaker Die folgenden Variablen werden von PackageMaker in den Script-Dateien der generierten SW-Pakete verwendet: Variable %_PkgSource% %_PkgCache% %_Machine% %_User% Beschreibung Verzeichnis, aus dem das SW-Paket installiert wird, wird vom Management Client aufgelöst. Verzeichnis, aus dem der User- und Client-Teil auf dem lokalen Computer zwischengespeichert wird, wird vom Management Client aufgelöst. Computername, auf der das SW-Paket installiert wird. Name des aktuell angemeldeten Benutzers. Variablen für Benutzer- und Computernamen PackageMaker scannt nach Benutzer- und Computernamen in den SW-Paket-Scripten. Diese werden durch die Variablen %_User% und %_Machine% ersetzt, damit das SW-Paket für beliebige Benutzer und Computer eingesetzt werden kann. Hinweis Hinweis Die Ersetzung der Benutzer- und Computernamen durch Variablen erfolgt durch eine einfache Suchen- und Ersetzen Funktion. Verwenden Sie daher eindeutige Benutzer- und Computernamen auf dem Paketierungscomputer. Wenn z.b. der Benutzername User oder IO lautet oder der Computername WINNT oder WS, führt die Ersetzungsfunktion zu irregulären Ergebnissen und das SW-Paket ist nicht lauffähig. Zum Kopieren von Dateien in das Profilverzeichnis des Benutzers wird immer die Variable %_User% verwendet, selbst wenn der Pfad zum Benutzerprofil unterschiedlich war, wie z. B: "%_User%.000" / 02 / deu 103/114

104 Anhang Weitere Variablen Innerhalb von PackageMaker werden keine anderen Variablen zugeordnet. Wir empfehlen jedoch, weitere Variablen mit PackageStudio zuzuordnen. Das SW-Paket wird damit wesentlich flexibler und bietet zusätzlich Multiplattform-Unterstützung. Das bedeutet, dass ein solches SW-Paket ohne Probleme unter Windows NT 4.0 und Windows 2000 installiert werden kann (mit Ausnahme einiger Treiber). Beispiel Auf einem Computer mit Windows NT4 melden Sie sich als Administrator von der Domäne an. Das Benutzerprofil dieses Benutzers wird in C:\WINNT\Profiles\Administrator gespeichert. Wenn Sie sich nun als lokaler Administrator anmelden, lautet das Profil für diesen lokalen Benutzer C:\WINNT\Profiles\Administrator.000. Auf dieses Verzeichnis würde von PackageMaker als C:\WINNT\Profiles\%_User% verwiesen werden. Solche Probleme vermeiden Sie, wenn Sie die Columbus-Systemvariable %_UserProfile% verwenden, wie sie von PackageStudio zugeordnet wird. Bei Verwendung dieser Variablen kann das Paket auch unter Windows 2000 und Windows XP laufen, bei denen das Profilverzeichnis C:\Dokumente und Einstellungen\%_User% ist. 7.3 Columbus PackageStudio Ausführen von Spezialaufgaben Bulk Actions (Massenaktionen) Mit der Funktion Bulk Actions kann die Prüfsumme und/oder der Status automatisch in mehreren Paketen aktualisieren werden. Wählen Sie im Menü Action > Bulk Actions. Geben Sie den Pfad der SW-Paketablage an und klicken Sie auf Scan Package source. Markieren Sie die SW-Pakete und klicken Sie auf Update CRC / Status. Hinweis Es ist nicht möglich, den Status ohne CRC zu aktualisieren / 02 / deu 104/114

105 Anhang Ausführen von der Befehlszeile PackageStudio kann von der Befehlszeile aus verwendet und gesteuert werden um die Verbesserung des Basispakets noch weiter zu automatisieren. Es kann z.b. mit einer Batchdatei das Paket in den Paket-Testbereich kopiert und geöffnet werden, die automatisierten Aktionen ausgeführt und anschliessend das Paket wieder gespeichert werden. Wird das Paket dann manuell geöffnet, sind die meisten Arbeiten bereits erledigt. Beispiel "C:\Program Files\Columbus\Packaging\PkgStudio.exe" /PACKAGE:D:\Columbus\SWDepot\80001_BGInfo_4.EN\01.0 /PROCESS:Y /SAVE:Y Parameter /PACKAGE: [PackageDirectory] /PROCESS:[Y/N] /SAVE:[Y/N] /EXIT:[Y/N] /INIFILES: [ALL/SUGGESTED] Beschreibung Pfad zu dem Verzeichnis, in dem sich Package.ini befindet. Dies kann ein absoluter Pfad (D:\Packages\Delphi5Enterprise.IE\01.1) oder ein relativer Pfad (Delphi5Enterprise.IE\01.1) sein. Wird /PROCESS:Y festgeleget, werden alle automatisierten Aktionen verarbeitet, die zur Ausführung beim Laden eines Pakets konfiguriert sind. Wird /SAVE:Y festgelegt, werden die Paketdateien nach der Ausführung von automatisierten Aktionen gespeichert. Wird /EXIT:Y festgelegt, wird PackageStudio nach der Verarbeitung des Pakets beendet. Gibt an, welche INI-Datei konvertiert werden soll (nur gültig in Verbindung mit /PROCESS:Y) und steht nur zur Verfügung, wenn die Ini-Dateiersetzung ausgeführt wird. ALL: alle gefundenen INI-Dateien werden konvertiert. SUGGESTED: alle INI-Dateien mit festen Pfaden werden konvertiert Run time Anforderungen Die Ausführung von PackageStudio benötigt folgende Dateien: Datei Beschreibung Version Lieferung C4DLL.DLL COMCTL32.DLL Datenbank Funktionen Allgemeine Dialogs Bibliothek oder höher Mit PackageStudio in das Applikationsverzeichnis 4.72 oder höher Durch Microsoft Service Packs, z.b. Office Hinweis Diese Dateien werden zusammen mit PackageStudio installiert sind aber keine Brainware Dateien und werde somit auch nicht von Brainware gewartet / 02 / deu 105/114

106 Anhang Fehlende Snapshot.ini Wird ein Paket geladen, das mit einer früheren Version als PackageMaker 5 erstellt wurde, erscheint die Fehlermeldung Snapshot.ini is missing in package directory. Mit diesem Paket kann normal gearbeitet werden, jedoch funktionieren Convert Ini files und Apply Variables nicht erwartungsgemäss. Lösung für diese Beeinträchtigungen Erstellen Sie einen neuen Snapshot mit und kopieren Sie die Datei Snapshot.ini in das Paketverzeichnis. - oder - Kopieren Sie eine Snapshot.ini von einem anderen Snapshot, der auf dem gleichen Computer oder Betriebssystem aufgenommen wurde, in das Paketverzeichnis DuplicatesChecker Was ist Duplicate Checker Bei DuplicatesChecker handelt es sich um ein Werkzeug für die Suche nach Duplikaten oder Konflikten zwischen verschiedenen Columbus Paketen. Mit diesem können Dateien, Registrierung und INI-Dateieinträge überprüft und Berichte (Reports) über gefundene Duplikate/Konflikte erstellt werden. Mit den Optionen für die Berichterstellung werden die angezeigten Ergebnisse eingrenzt, da die Anzahl an Einträgen in der Regel sehr gross ist / 02 / deu 106/114