Entscheidungshilfe

Guest

Hallo!
<
bin gerade dabei, mich zwischen On und NetInstall zu entscheiden. Einer der Knackpunkte für uns ist der Unterschied beim Erstellen der Pakete. Snapshot (Netinstall) oder Installations-SPY (On). Aus meiner Sicht stellt sichs so dar, dass in einem Unternehmen mit gleichen Rechnern, Software und Systemen der Snapshot die bessere Lösung ist. In anderen Unternehmen, bei denen die Rechner sehr unterschiedlich aussehen (verschiedene Betriebssysteme, unterschiedlich Hardware, keine einheitlichen Treiber usw.) und vor allem Clients admin-Rechte habe und somit den Rechner "verunstalten" eher die Variante mit dem SPY (z B OnTech) vorzuziehen ist?

Gibts in dem Bereich Erfahrungsberichte bzw. spricht irgendetwas für/gegen Snapshot?

Das ist jetzt wieder politisch aber es gibt mindestens drei Möglichkeiten.

Ich kenne eine Vielzahl von Firmen, die Netinstall verwenden und auch damit zufrieden sind. Insbesondere dann, wenn nur Standard-Software verteilt wird, die bereits in geeigneter Form geliefert wird ist das eine perfekte Sache.
Der Glanz verblasst etwas wenn es an ältere Anwendungen und an "Non-Standard-Sachen" geht.

Ein Admin schreibt mir:
----------------------------
Ein Snapshot Verfahren ist für uns nicht akzeptabel, da
- bei etwa X00 verschiedenen Softwareprodukten auf ca. XXXX PCs dies aus meiner Sicht nicht mehr zu beherrschen ist
- viele Hersteller den Support verweigern, wenn die SW nicht ordnungsgemäß installiert wurde. Dies trifft bei Fachapplikationen vermehrt zu, da hier oftmals der Hersteller selbst nicht weiß, was sein Setup so macht (Ein Hoch auf die Entwicklungstools mit integriertem Setup-Builder).

Denken Sie sich statt den X eine beliebige Zahl, es geht hier nicht um das konkrete Beispiel sondern um das Admin-Geschäft an sich.

Eine steigende Anzahl davon wollen aber auch nur zusätzlich die Möglichkeit Pakete "visuell zu installieren", weil es Problemfälle gibt, die sich gegen ein Repackaging als MSI sträuben.

Warum das so ist steht hier:
http://www.doctordeploy.com/viewtopic.php?t=72 (post über Repackaging-Probleme).

Oder weil es einfach schneller geht. Beispiel wie schnell es geht hier als Video: http://www.winrobots.com/shtmls/visual%20automation-choice.shtml

Die Möglichkeit bieten dann nur Skripting-Verfahren, wie oben geschildert.

Da kommt natürlich ON ins Spiel die hier ein sehr einfach zu bedienendes Standard-Verfahren haben, welches auch überwiegend gut funktioniert. Die Praxis zeigt dann aber, dass keiner ALLES kann:
-------------------------------
"Da es keine Möglichkeit gibt, den Status von Buttons abzufragen kommt es des Öfteren zu folgendem Problem:
Während Dateien kopiert/gelöscht werden oder sonst eine Aktion vom Setup durchgeführt wird ist der "Weiter/Ende" Button disabled, das Fenster wurde aber erkannt. Wird jetzt das Steuerelement nicht innerhalb einer bestimmten Zeit (wenige Sekunden) bedient kommt es zu einer Fehlermeldung in der Art „can not do action on this control“ und das Skript bricht ab. Es gibt zwar eine Compiler Option mit der man den Abbruch verhindern kann, jedoch kommt es hierbei teilweise dann wieder zu anderen Problemen."

Und so greifen dann auch hier der ein und andere wieder zu einem ergänzenden Fremdprodukt, hauptsächlich da wo das integrierte System nicht greift.

Kann keiner alles?
------------------------
Jedenfalls gibt es baramundi, als mögliche dritte Alternative. Baramundi bietet ein sehr offenens System, unterstützt beide genannten Verfahren (Snapshoot und visuelles Skripting) ohne die oben genannten Nachteile.

In jedem Fall, egal für welche der Lösungen Sie sich entscheiden, bietet ein "visuelles Verfahren" (je nachdem) auch weitere Möglichkeiten.

Auch hier ein Beispiel aus einer E-Mail eines Admins:
-------------------------------------------------------------------
Als Beispiel (aus meinem Admin-Leben)
Ruft mich neulich gegen 17:00 Uhr ein Kollege im Büro an. Er sagte zu mir er hätte da ca. 80 Dateien die mit dem Programm XY erstellt wurden, und müsste diese Ausdrucken. Bis morgen früh 8:00 Uhr. Das Problem war, die Applikation war nicht mehr verfügbar und die Dateien mussten so erst umständlich in einem anderen Programm importiert werden.
Da dachte ich mir „bist ja nicht blöd, hast ja WinRobots. Gesagt, Getan.
Vorgang mit der „Gelben Liste“ aufgezeichnet, schleife rumgebaut, fertig, fast (TDL\1000 + TDL\100) ohne weitere Anpassungen. Der Kollege hatte um 19:00 seine PDFs (zum selberdrucken).

In jeder Firma gibt es mal solche Jobs die man lieber automatisieren möchte. Ein gutes Skripting-Verfahren kann nicht nur Buttons in Installationsprogrammen drücken, sondern überall wo es welche gibt.

theogott wrote:

Ein Admin schreibt mir:

Code:

Ein Snapshot Verfahren ist für uns nicht akzeptabel, da...

bitte den code-tag auch nur fuer code verwenden. danke. d'oh!

Danke für den Hinweis. Ich habs gleich geändert!

Magnum Joined: 16 Jun 2004 Posts: 33

Einfach mal Prism Deploy testen oder vorführen lassen, dann beantworten sich Fragen von selbst...

Wir setzen Prism bei 1500 clients ein und hatten auch alles getestet.

Abgesehen davon, dass man es natürlich genauso wie alle anderen Verfahren durch WinRobots ergänzen könnte Smile

-
hat Prism bereits ein integriertes Scripting Verfahren bzw. welche Mechanismen verwendet Prism um Installationen "via Setup" zu installieren?

Magnum Joined: 16 Jun 2004 Posts: 33

braucht Prism nicht. Löst intern Variablen auf und kann eigene Variablen
definieren und vor Installation auslesen. Kann sogar das Update
Verzeichnis suchen lassen und es ist dann egal ob eine Software auf c:,
d: oder e: upzudaten ist, die Pakete suchen sich selbst den Weg (eine
Umsetzung der Registry erfolgt automatisch). Funzt in unserer
inhomogenen Umgebung (WinNt, XP, 2000 und einige 98er) hervorragend.

Es funktioniert mit allen unseren zu verteilenden Anwendungen oder
Einstellungen (ca. 800 zur Zeit).

Rollback auch über eine beliebige Historie hinweg ist integriert, sowie
eine optimierte Übertragung und CheckPoint Restart. Wir fahren zwei
sprachige Betriebssysteme (ungefähr die Hälfte der Anwender Deutsch, die
andere Englisch). Hatte aus Versehen mal eine Anwendung sprachvertauscht
ausgerollt. Zwei Mausklicks und danach war wieder alles richtig...

Eine Installation ist durch die optimierte Übertragung verdammt schnell.
Einfach mal vorführen lassen, die Demo ist recht gut und zeigt schnell
die Unterschiede.

>braucht Prism nicht.
Das hört sich ja so an, als hätte Prism das Snapshooting neu erfunden.

>in unserer inhomogenen Umgebung
Verstehe ich das richtig, bei Prism erfolgen alle Installationen auf der Client-Seite mit Snapshooting/Repackaging und MSI - d.h. ohne "Original-Setup-Installationen"?

Und zwar ausschliesslich?

Magnum Joined: 16 Jun 2004 Posts: 33

theogott wrote:

>braucht Prism nicht.
Das hört sich ja so an, als hätte Prism das Snapshooting neu erfunden.

yeap, sogar NTFS und Registry Rechte werden mitgeschnitten. Digitale
Signatur von Updates, Smart Update (Regelbasiert ohne Inventur), Exklusive
Rollbackeigenschaft, WakeOnLan über Router hinweg, optimierte
Übertragung usw., soweit ich weiss ist einiges patentiert.

theogott wrote:

>in unserer inhomogenen Umgebung Verstehe ich das richtig, bei Prism
erfolgen alle Installationen auf der Client-Seite mit
Snapshooting/Repackaging und MSI - d.h. ohne
"Original-Setup-Installationen"?

Und zwar ausschliesslich?

Nö, kann auch jedwedes Kommando unter jedwedem Account (auch auf dem
Login Bildschirm) versenden. Also auch native Installationen.

Habe alle Möglichkeiten.

Kann auch Client Migrationen durchführen und Maschinen wieder in den
Grundzustand versetzen (ReturnToState).

Magnum Joined: 16 Jun 2004 Posts: 33

Nachtrag: soweit ich weiss existiert die Technologie schon in der 7. Generation (basierend auf der PictureTaker Technologie) und wurde über Jahre weiterentwickelt (man merkt es dem Produkt an, die Qualtität ist meines Erachtens hervorragend).