You searched for softwarepaket erstellen - Workplace Management Blog https://www.wpm-blog.de/ ... ideas and solutions making workplace management easier Sun, 24 Nov 2024 17:07:34 +0000 de hourly 1 https://wordpress.org/?v=6.1.7 Gefährliche Aktivierungsoption https://www.wpm-blog.de/gefaehrliche-aktivierungsoption/ https://www.wpm-blog.de/gefaehrliche-aktivierungsoption/#respond Tue, 18 Feb 2020 17:00:33 +0000 https://www.wpm-blog.de/?p=2556 In der Empirum Management Console schlummert eine Option, die zumeist fatale Folgen hat. Bei Schulungen, Trainings und Einweisungen bezeichne ich die nachfolgende Option gerne mit die Niemals, Nie, auf keinen Fall auswählen Option :). Bei … Weiterlesen

Der Beitrag Gefährliche Aktivierungsoption erschien zuerst auf Workplace Management Blog.

]]>
In der Empirum Management Console schlummert eine Option, die zumeist fatale Folgen hat. Bei Schulungen, Trainings und Einweisungen bezeichne ich die nachfolgende Option gerne mit die Niemals, Nie, auf keinen Fall auswählen Option :).

Bei welcher Aktion wird mir diese Option angeboten?

Bei der Aktivierung einer kompletten Gruppe anstatt einem einzelnen Computerobjekt, wird einem im Aktivierungsassistenten beim zweiten Schritt der nachfolgende Dialog angeboten.

Aktivierung Verteilungsoptionen

Welche Auswirkung hat die Option?

Durch das Setzen der Option „Für alle untergeordneten Elemente übernehmen“, die ich unten eingerahmt habe, überschreibt die angezeigte Verteilungsoption alle bereits vorhandenen Verteilungsoptionen der darunter liegenden Softwarepaketen. Dies hat zur Folge, dass gesetzte Optionen wie Zeitplaner, Deinstallieren etc. mit „Installieren, Erneuern“ überschrieben wird. Die Aktivierung einer Gruppe hat sowieso zur Folge, dass alle darunter befindlichen Computerobjekte aktiviert werden – eine „Übernahme für darunter befindliche Objekte“ ist nicht gesondert notwendig!

Was kann ich tun, wenn ich diese Option fälschlicherweise aktiviert habe?

Wenn Du diese Option ausgewählt hast, oder eben ein Kollege, und das „Problem“ bemerkst, solltest Du als nächstes zur Sicherheit die gesamte Struktur deaktivieren und falls DepotServer im Einsatz sind zur Sicherheit eine Synchronisation des Jobs „ESubdepot_MachineValues“ oder eben „ESubdepot_MachineValues_QuickSync_Night“ forcieren.

Im Nachgang musst Du dich vergewissern, welche Abweichungen welche Folgen haben.
Das Überschreiben eines Zeitplaners, oder der Option „Nicht Anzeigen“ ist zumeist nicht so kritisch. Das Überschreiben von „Deinstallieren“ mit „Installieren, Erneuern“ sorgt dagegen für zumeist ungewünschte Effekte. Für den ersten Fall, kann man sich überlegen, stückweise die Optionen wieder zu setzen und neu zu aktivieren.

Für das Wiederherstellen des Ursprungszustandes im zweiten Fall hilft meines Erachtens nur eine Rücksicherung der Datenbank. Dies hat natürlich den Verlust, der seit der Sicherung durchgeführten Änderungen, zur Folge. Neben neuen Softwarezuweisungen, sind dies auch Rückmeldungen der Softwareverteilung und Inventarisierungsstände.

Deswegen, bitte auch immer neue Kollegen proaktiv auf diese Option und ihre mögliche Auswirkungen hinweisen.

Weiterer Hinweis

Wenn man tatsächlich für alle neuen Verteilungen eine besondere Verteilungsoption („Ablehnen möglich: 5“ oder ähnlich) setzen möchte, so sollte man die Experte, Verteilungsoptionen… Funktion nutzen.

Der Beitrag Gefährliche Aktivierungsoption erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/gefaehrliche-aktivierungsoption/feed/ 0
Empirum WinPE Paket – DriverIntegration Ersatz https://www.wpm-blog.de/empirum-winpe-paket-driverintegration-ersatz/ https://www.wpm-blog.de/empirum-winpe-paket-driverintegration-ersatz/#comments Tue, 01 Jan 2019 13:51:56 +0000 https://www.wpm-blog.de/?p=2132 Das Empirum WinPE Paket, das ich hier vorstelle ist dazu gedacht das Matrix42 Paket „DriverIntegration“ zu ersetzen. Mein Paket heißt PrepareDRVbyModel_Packages, da mein erstes WinPE Paket die Treiber aus der EmpInst Verzeichnis Struktur holt. Was … Weiterlesen

Der Beitrag Empirum WinPE Paket – DriverIntegration Ersatz erschien zuerst auf Workplace Management Blog.

]]>
Das Empirum WinPE Paket, das ich hier vorstelle ist dazu gedacht das Matrix42 Paket „DriverIntegration“ zu ersetzen. Mein Paket heißt PrepareDRVbyModel_Packages, da mein erstes WinPE Paket die Treiber aus der EmpInst Verzeichnis Struktur holt. Was macht das originale Matrix42 DriverIntegration Paket? Es sucht in einer drivers.ini nach dem Hersteller und Model und kopiert abhängig davon die Treiber nach C:\EmpirumAgent\Drivers. In diesem Verzeichnis sucht die automatisierte Windows Installation (WindowsInstallation Paket) nach nicht bekannten Treibern. Dies kann man in der unattend.xml im WindowsInstallation Paket Verzeichnis sehen. Jetzt kommt wahrscheinlich der längste Beitrag, den ich bis dato geschrieben habe …

PrepareDRVbyModel_Packages

Mein Ersatz bietet (meines Erachtens:)) einige Vorteile und weicht in den nachfolgenden Punkten von dem Matrix42 Grundgedanken ab:

  • es ist „gesprächiger“ und man kann eher nachvollziehen, was es macht (siehe Screenshots am Ende des Beitrages)
  • der Ablageort der Treiber kann angepasst werden vom Standard: Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
  • der Ablageort der Drivers.ini kann angepasst werden vom Standard: Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
  • es kann festgelegt werden, ob die WinPE Installation weitergehen soll, auch wenn kein Eintrag in der drivers.ini, Treiber, etc. gefunden wurde.

Übersicht dieses Beitrages

  • Import der OS-Packages
  • Kurze Einführung: Hardware Model zu Treiber/Software Zuordnung per drivers.ini
  • Möglichkeiten mit PrepareDRVbyModel_Packages
  • Einführung PostOSInstallation Paket
  • Download
  • Fehlersuche
  • Screenshots

Import der OS-Packages

Zuerst ist es notwendig, die zusätzlichen OS-Package über das Software-Depot zu importieren. Danach muss die Reihenfolge arrangiert werden, damit die richtige Abarbeitung während der OS-Installation gewährleistet ist:

  • <WinPE-D-2PXE> (optional aber empfohlen)
  • DiskPartitioning
  • <PrepareDRVbyModel_Packages>
  • WindowsInstallation
  • PxeOffAndReboot
  • DomainJoin
  • <PostOSInstallation> (optional aber empfohlen)
  • EmpirumAgentSetup

Hardware Model zu Treiber/Software Zuordnung

Die Zuordnung Model zu Treiber geschieht wie bei dem Paket der Matrix42 über die drivers.ini Datei. Diese ist im Standard unter Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers abgelegt.

Aufbau der Drivers.ini
[<WMI Manufacturer>]
<WMI Model>=<Ordner, *.ZIP, *.cab unterhalb von Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers>

z.B.
[Dell Inc.]
OptiPlex 7010=DellOptiplex7010
;alternativ OptiPlex 7010=DellOptiplex7010.zip
;alternativ OptiPlex 7010=DellOptiplex7010.cab

Möglichkeiten mit PrepareDRVbyModel_Packages

Nachfolgend sind die Möglichkeiten erläutert, die sich aufgrund der Anpassung und Erweiterung ergeben. Diese Möglichkeiten können über die Variablen in der Management Console gesteuert werden. Die aufgeführten Variablen sind alle unter der Variablen Sammlung „PrepareDRVbyModel_Packages“ zu finden.

DriversAreMandatory:
Das Matrix42 Paket drehte sich bis vor kurzem solange in der Schleife bis ein Treiber in der drivers.ini gefunden wurde.
Dies ist für eine produktive Umgebung, den Dienstleister etc. gut so.
Wenn man jedoch einen Computer ohne spezifische Treiber installieren will (zum Test), dann muss man im Matrix42 Falle einen drivers.ini Eintrag erzeugen mit einem Verweis auf ein leeres Verzeichnis.
Dieses Verhalten wurde mit dem DriverIntegration 2.6 Pakete verändert – man kann es jedoch nicht steuern.

Variablenwerte:
0, WinPE fährt mit der WindowsInstallation fort, auch wenn kein Treiber in der drivers.ini gefunden wurde.
1, Matrix42 Standardverhalten – das System läuft in der Schleife und führt die WindowsInstallation nicht fort.
Somit kann man für eine produktive Struktur (Konfigurationsgruppe) sicherstellen, dass die Installation nur mit bekannten Hardware-Typen durchgeführt wird.

DriversRootPath:
Die Idee, den DriversRootPath anpassbar zu machen, hatte mehrere Gründe:
Selektive Synchronisation der Treiber: Hiermit kann man die Treiber direkt unter Packages\Drivers ablegen und mit einem angepassten „ESubDepot_Packages“ SyncJob diese für bestimmte Standorte auslassen und mit einem selbsterstellten ESubDepot_PackagesDrivers diese separat synchronisieren lassen.
Treiber-Update Softwarepakete: Durch eine Erweiterung der Ablage um eine Setup.inf, DPInst.exe und xml kann man eine Aktualisierung der Treiber auf bestehenden Systemen durchführen und mass dazu die Treiber nicht mehrmals ablegen. Dies werde ich in einem späteren Beitrag nochmals aufgreifen.

Variablenwerte:
„leer“ bedeutet Matrix42 Standardwert:Matrix42\OsPackages\Drivers, das entspricht Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
Kommentar:
Hinweis: Man kann in der drivers.ini auch Teilpfade angeben.
Für eine Kopie eines Ordners zum Beispiel: OptiPlex 7010=Dell\Optiplex7010\1.0\PNP
Für die Nutzung einer ZIP Datei zum Beispiel: OptiPlex 7010=Dell\Optiplex7010\1.0\PNP\Optiplex7010.zip
Wichtig: Der Pfad wird ab dem Packages Ordner angegeben!

DriversINIPath:
Die Idee hierbei war, dass man eine zweite drivers.ini Datei, unabhängig von einer produktiv genutzten, einsetzen kann.
Darin kann man Einträge für eine bekannte Hardware auf einen anderen Pfad, ZIP, etc. setzen und somit vorab bzw. parallel testen.
Somit kann für eine bestimmte Konfigurationsgruppe ggf. der Wert: Matrix42\OsPackages\Drivers\Test sein.
In diesem Ordner muss dann die alternative drivers.ini abgelegt sein.

Variablenwerte:
„leer“ bedeutet Matrix42 Standardwert:Matrix42\OsPackages\Drivers, das entspricht Empirum\Configurator\Packages\Matrix42\OsPackages\Drivers
Wichtig: Der Pfad wird ab dem Packages Ordner angegeben!

Perfekt funktioniert PrepareDRVbyModel_Packages mit dem PostOsInstallation Paket von mir. Das genannte Paket prüft ob es eine C:\EmpirumAgent\Drivers\HWspecificSW\Setup.inf gibt und führt diese aus.

Möglichkeiten des PostOsInstallation

Das PostOSInstallation Paket ist einfach und ruft eine abgelegt PostOSInstall.bat auf.
Hinweis: Diese Datei solltet ihr vor der ersten Benutzung einsehen und anpassen!
Die Batch Datei hat heute mindestens drei Funktionen:

  • Es importiert eine von dem PrepareDRVbyModel_Packages Paket erstellte Registry Datei, die ähnliche Werte in die Registry schreibt (HKLM\Matrix42\Installer), wie die EPE Installation.
  • Es passt die durch Matrix42 vorgegebenen Firma, Benutzer, Support etc. Informationen in der Registry an, die man bei der EPE Installation in der Betriebssystemvorlage angegeben hat.
  • Es führt eine Setup.inf aus dem C:\EmpirumAgent\Drivers\HWspecificSW Ordner aus, falls diese vorhanden ist. Somit kann man wieder im „Hardware-Profil“ Treiber per PNP und per EXE/MSI installieren.

Somit ist die PostOSInstall.bat eine Art Ersatz für die EmpirumAgent.bat/UEMAgent.bat.

[Update am 27.08.2019] Die Version 1.5 unterstützt nun auch die Drivers.json Datei, die per WinPEDriverAssistant erstellt wird. Es werden auch Intel NUCs erkannt und ASUS Motherboards. Beide zuletzt genannte Typen werden vom DriverIntegration Paket nicht unterstützt. Bei der Nutzung des PostOSInstallation Paketes, die darin enthaltene PostOsInstall.bat anpassen!

Download

Empirum WinPE PreOS Package zum optimierten Treiberhandling.

PrepareDRVbyModel_Packages 1.5 (388 Downloads )
MD5 Hash der Downloaddatei: 175D4CD2FD119A371EDDA21211D6C0C761A7A50F

PrepareDRVbyModel_Packages 1.1 (413 Downloads )
MD5 Hash der Downloaddatei: 0D3415555E6197DC510B02E946D96C5169FD8529

Los geht’s

Schritt 1:
Zuweisen der Pakete für eine Konfigurationsgruppe:

  • <WinPE-D-2PXE> (optional aber empfohlen)
  • DiskPartitioning
  • PrepareDRVbyModel_Packages
  • WindowsInstallation
  • PxeOffAndReboot
  • DomainJoin
  • PostOSInstallation (optional aber empfohlen)
  • EmpirumAgentSetup
  • Betriebssystem (per Variable oder aus dem rechten Baum)
  • WinPE (Bootkonfiguration)
  • Agent-Template

Schritt 2:
Setzen der Variablen für die oben genannten Pakete (siehe hierzu ggf. auch das WinPE Dokument der Matrix42).
Zuordnung des Betriebssystems

Schritt 3:
Zuweisen eines Computers

Schritt 4:
Aktivieren von PXE und Software (OS.INI ist nicht notwendig!)
Achtung:nicht während einer aktiven WinPE Phase den Computer nochmals aktivieren (dies kann ab WinPE 1.4.11 wieder getan werden).

Rückmeldungen sind willkommen!

Fehlersuche:

  • Erster Anlauf: In der Management Console auf dem entsprechenden Computer das PXE-Log ansehen
  • Informationen zum Ablauf der OS-Packages befinden sich in Empirum\EmpInst\Wizard\OS\Auto\<MAC8> oder <UUID>\debug_Matrix42.Platform.Service.Host.log.
    Suchen nach [wpm-blog und darunter sollten weitere Informationen zu finden sein …

Beispielhafte Screenshots:

DriversAreMandatory = 0 und keine passende Zuordnung/Treiber in drivers.ini gefunden

DriversAreMandatory = 1 und keine passende Zuordnung/Treiber in drivers.ini gefunden

DriversAreMandatory = 1, passende Zuordnung/Treiber in drivers.ini gefunden, abweichende DriversIniPath Variable, Treiber werden kopiert

Der Beitrag Empirum WinPE Paket – DriverIntegration Ersatz erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-winpe-paket-driverintegration-ersatz/feed/ 9
Empirum – Software Paketierung Selbststudium https://www.wpm-blog.de/empirum-software-paketierung-selbststudium/ https://www.wpm-blog.de/empirum-software-paketierung-selbststudium/#comments Mon, 08 Sep 2014 21:29:53 +0000 https://www.wpm-blog.de/?p=1317 Im Laufe der Zeit habe ich nun bereits einige Artikel veröffentlicht, die sich immer wieder um die Software Paketierung bzw. Software Verteilung mit Empirum (Matrix42 Physical Workspace Management, UEM – Unified Endpoint Management, Client-Management) drehen. … Weiterlesen

Der Beitrag Empirum – Software Paketierung Selbststudium erschien zuerst auf Workplace Management Blog.

]]>
Empirum Software ManagementIm Laufe der Zeit habe ich nun bereits einige Artikel veröffentlicht, die sich immer wieder um die Software Paketierung bzw. Software Verteilung mit Empirum (Matrix42 Physical Workspace Management, UEM – Unified Endpoint Management, Client-Management) drehen. Damit man die einzelnen Artikel einfacher für ein Selbststudium nutzen kann, habe hier einmal alle Artikel mit dem Bezug zur Software Paketierung und Verteilung zusammengefasst, somit eine Art Anleitung zur „Empirum Paketierung“. Da die Seitenlinks recht selbst sprechend sind, habe ich mir jetzt auch nicht mehr die Mühe gemacht, diese nochmals „hübsch“ aufzubereiten. Für die regelmäßigen Leser gibt es hier nichts Neues – für alle anderen eine „interne“ Link-Sammlung.

Los geht’s!

Diese Linksammlung ist auf dem Stand: 07.04.2020

Generelles

Erstes Paket erstellen und verteilen

Paketierung – Erweitert

Software-Management

Paketierung – Besonderes zur Verteilung

Anpassen der Paketierungsvorlagen

Der Beitrag Empirum – Software Paketierung Selbststudium erschien zuerst auf Workplace Management Blog.

]]>
https://www.wpm-blog.de/empirum-software-paketierung-selbststudium/feed/ 2
Softwarepakete erstellen und verfeinern https://www.wpm-blog.de/softwarepakete-erstellen-und-verfeinern/ Wed, 03 Oct 2012 10:13:57 +0000 https://www.wpm-blog.de/?p=283 Die Erstellung von Softwarepaketen kann mit Hilfe der bei Matrix42 mitgelieferten Werkzeuge geschehen. Die Werkzeuge sind über das „Packaging Center“ erreichbar. Dieses liegt als Paket vor, kann aber auch direkt aufgerufen werden. Das Packaging Center … Weiterlesen

Der Beitrag Softwarepakete erstellen und verfeinern erschien zuerst auf Workplace Management Blog.

]]>
Die Erstellung von Softwarepaketen kann mit Hilfe der bei Matrix42 mitgelieferten Werkzeuge geschehen. Die Werkzeuge sind über das „Packaging Center“ erreichbar. Dieses liegt als Paket vor, kann aber auch direkt aufgerufen werden.

Das Packaging Center befindet sich auf dem Empirum Server unter Empirum\Configurator\Packages\Matrix42\Packaging Center\<Versionsnummer>\Empirum Packaging Center.exe.

Die meistgenutzten Werkzeuge können jedoch auch ohne Umwege über das Packaging Center aufgerufen werden.

Das sind:

  • PackageWizard.exe (Assistent zum Erstellen von Software Paketen)
  • Empirum Package Editor.exe (Editor mit zwei Ansichten und Unterstützungsvarianten: Normal/Erweitert)

Wenn man tatsächlich eine Software in ein Paket fassen möchte, beginnt man zumeist mit dem PackageWizard und nimmt ggf. im Nachgang noch Änderungen mittels des Editors vor. Hat man etwas Routine und Verständnis gewonnen, so kann man gerade für bestimmte Zwecke sich direkt mit dem Editor, oder auch einem Editor seiner Wahl direkt an die Bearbeitung der Setup.inf machen. Vorlagen für die verschiedenen Installationsvarianten liegen im Unterverzeichnis „Templates“ des Packaging Centers.

Wie auch immer man ein Paket erstellt hat, so wird es zur Einbindung in die Empirum Management Console unter Empirum\Configurator\Packages abgelegt.

Die Ablagestruktur sollte wie folgt eingehalten werden:

Empirum\Configurator\Packages\<Hersteller bzw. Developername>\<Software>\<Version>\Install\<Setup.inf>

 

Besonderheiten:

  • Die Version sollte eine Zahl sein, bei der nachfolgende Versionen höhere Zahlen darstellen.
  • Die Setup.inf muss nicht zwangsläufig Setup.inf heißen. Wenn der Name von Setup.inf abweicht, so muss dieser konsequenterweise auch in der Setup.inf umbenannt werden, da diese hier mindestens zwei Mal referenziert wird.
  • Auch der Install Ordner kann anders lauten, dies muss jedoch auch in der Setup.inf angepasst werden.

Der Beitrag Softwarepakete erstellen und verfeinern erschien zuerst auf Workplace Management Blog.

]]>
Aufwand zur Erstellung eines Softwarepaketes https://www.wpm-blog.de/aufwand-zur-erstellung-eines-softwarepaketes/ Tue, 07 Aug 2012 21:05:26 +0000 https://www.wpm-blog.de/?p=170 Häufig wird man gefragt, wie hoch der Aufwand zur Erstellung eines Softwarepaketes ist. Diese Aufgabe kurz und knapp zu beantworten fällt zumeist schwer. Warum? Die Erstellung eines Softwarepaketes besteht aus der Erstellung und den dazugehörigen … Weiterlesen

Der Beitrag Aufwand zur Erstellung eines Softwarepaketes erschien zuerst auf Workplace Management Blog.

]]>
Häufig wird man gefragt, wie hoch der Aufwand zur Erstellung eines Softwarepaketes ist. Diese Aufgabe kurz und knapp zu beantworten fällt zumeist schwer. Warum? Die Erstellung eines Softwarepaketes besteht aus der Erstellung und den dazugehörigen Tests.

Zuerst muss man die Aufgabe für das Softwarepaket mit dem Auftraggeber bestimmen, denn diese bestimmen somit auch die notwendigen Tests.

Um es etwas einfacher zu sagen: „Was soll das Softwarepaket machen?“

  • Sollen alte vorhandene Software-Installationen des gleichen Produktes entfernt werden?
  • Sollen Einstellungen der Software übernommen werden?
  • Soll eine gerade laufende Instanz der Software abgefragt werden?
  • Stellt der Hersteller eine „silent“ Installation zur Verfügung?
  • Sollen nach der Installation auch Einstellungen vorgenommen werden?
  • Sollen die Einstellungen auch für alle Benutzer des Computers vorgenommen werden?
  • Soll das Softwarepaket die Software auch wieder deinstallieren?
  • Sollen auch Dinge gelöscht werden, die nach der Installation der Software hinzugekommen sind?
  • Dokumentation

Ich denke, sie verstehen nun, dass die Frage nicht so leicht beantwortet werden kann, auch wenn man gesagt bekommt…

  • „Die Software hat nur 5 MB.“
  • „Sie müssen immer nur weiter drücken.“

Welche Einflüsse kann man „steuern“?

Ist die Umgebung sehr homogen, fallen weniger Tests an bzgl. möglicher vorhandener Altversionen.

Ist die Software für den Unternehmenseinsatz gedacht/geplant?

Überlegen Sie, ob sie die Software tatsächlich wieder deinstallieren (würden)?

Wie sieht es aus mit Internet Explorer, .NET Framework, AntiVirus.

Gerade im Fall AntiVirus – hier installiert man häufig immer wieder die aktuelle Version der gleichen Software.

Diese kann sich selbst meist wunderbar aktualisieren. Sollte der Tag kommen, an dem sie ihr vorhandenes Produkt austauschen, können sie sich immer noch viele Gedanken zur Entfernung des Vorgängerproduktes machen und dann auch in ein Softwarepaket „gießen“.

Auch wenn ich selbst „perfektionistisch“ veranlagt bin 😉 so sollte jeder Nutzer einer Softwareverteilung seinen Grad an „Perfektion“ (Das Softwarepaket ist fertig.) selbst bestimmen. Bevor sie ein Produkt nicht nutzen, nur weil ihnen jemand sagt bzw. gesagt hat, dass ein Softwarepaket alle oben genannten Merkmale besitzen muss, muss das für sie lange noch nicht zutreffen. Dann erstellen sie lieber ein Softwarepaket, das sich nicht deinstallieren lässt, oder nicht alle Einstellungen beinhaltet – dies hilft ihnen bereits Zeit zu sparen und Installationen zu vereinheitlichen.

 

80/20 Regel!

Wie auch an anderen Stellen trifft hier die 80/20 Regelung sehr häufig zu.

Sie erzielen 80% der Fertigstellung mit 20% Aufwand an Zeit und Geld. Die restlichen 20% kosten sie ggf. 80% Aufwand!

 

Erfahrung

Die Erfahrung bei der Erstellung von Softwarepaketen bzw. der Automatisierung von Softwareinstallationen ist bei all den genannten Punkten nicht zu vernachlässigen. Diese Erfahrung kann man jedoch nur „gewinnen“, wenn man es auch mal selbst „erfährt“ ;).

So werden sie bei den ersten Softwarepaketen mehr Zeit benötigen als jemand, der das schon viele Jahre macht. Es ist also „noch kein Meister vom Himmel gefallen“ und auf der anderen Seite „wer nicht wagt, der nicht gewinnt“ ;).

 

Also, lassen sie sich nicht entmutigen, sondern versuchen sie es!

Vielleicht helfen ihnen auch Tipps und Anleitungen (Tutorials), die hier noch veröffentlicht werden,

oder sie nutzen eine Schulung ggf. auch ganz individuell auf sie zugeschnitten!

Der Beitrag Aufwand zur Erstellung eines Softwarepaketes erschien zuerst auf Workplace Management Blog.

]]>