wie kann ich mir ein Software Rollout anhand meines Beispiels in einem Konzern vorstellen?
Nehmen wir an der Konzern verwendet eine deployment Software.
Konzern möchte ein IE Plugin installieren, welches als MSI Paket vorliegt. Stößt man das Paket lokal an, werden Admin Rechte benötigt.
Das MSI Paket kann man div. Parametern versehen und somit ‚silent‘ installieren.
Es werden Teile des zu installierenden Plugins bspw. in c:\Program files… abgelegt und Teile in der Registry unter HKEY_Current_User
Wie geht der Rollout denn jetzt vor sich?
Unter welchem User oder lokalem Systemkonto (oder was weiß ich) wird wann die Software ‚installiert‘?
Die Einträge die in die Registry geschrieben werden, können importiert werden oder werden die bei der ersten Anmeldung des entsprechenden Users geschrieben?
Rechte des Users:
Er darf nur in sein Profil auf der HDD schreiben und hat nat. Rechte für den User Pfad in der Registry.
Er hat an der Maschine selbst nur User Rechte.
Kannst du in eurer Software auch bestimmen, ob eine Kiste runterfahren soll und sich mit einem bestimmten User erneut anmelden soll?
Dann würde ich es nämlich so machen, dass über die Deployment-Software der Rechner als Admin angemeldet wir, Software wird installiert und dann wird der User wieder abgemeldet bzw. der Rechner neu gestartet.
Ich bin nur auf der Seite der das MSI Paket hat. Installieren will das ein Kunde von uns. Seine angeblichen Spezialisten bekommen das nicht hin. Ich wusste zu wenig über das Thema bisher. Hab mich aber gut informieren können über gruppenrichtlinien.de.
wie kann ich mir ein Software Rollout anhand meines Beispiels
in einem Konzern vorstellen?
Es ist eine gottverammte (Tschuldigung) Tüftel-Arbeit, dank Microsofts inzwischen völlig verkorkstem Systemdesign, und kein Tool der Welt kann daran wesentlich etwas ändern. So ist es.
Nehmen wir an der Konzern verwendet eine deployment Software.
Konzern möchte ein IE Plugin installieren, welches als MSI
Paket vorliegt. Stößt man das Paket lokal an, werden Admin
Rechte benötigt.
Denkfehler. Mit der Deployment-Software hat das nichts zu tun, das Problem liegt tiefer.
Du möchtest die Software natürlich nur einmal installiert haben, also per Maschine. In der Regel wird das auch durch die Lizensierung so erzwungen. Enstsprechende Einträge wohnen logischerweise unter HKEY_LOCAL_MACHINE. Um da reinzuschreiben reichen die Rechte eines normalen Benutzers nicht, folglich braucht’s einen Hintergruddienst unter System- ode Admin-Privilegien dafür. Seit dem Windows Installer ist auch im Betriebssystem einer vorhanden, der aber wegen grober Schwächen (z.B fehlendes Reporting) für größere Rollouts nur 2. Wahl ist. Deshalb haben große Verteilsystme ihren eigenen, in der Hinsicht etwas ausgefeilteren Installationsdienst. Mit dem eigentlichen Problem hat das aber nichts zu tun.
Du musst/willst oft Benutzereinstellungen mitverteilen. Da HKEY_CURRENT_USER immer eine benutzerspezifische Sache ist, und man genau genommen nur in seinen eigenen HKEY_CURRENT_USER Key schreiben kann, schreibt der Installationsdienst benutzerspezifische Einträge entweder garnicht oder an die falsche Stelle. HKEY_CURRENT_USER stt technisch sauber nur mit dem Login des entsprechenden Users zur Verfügung. Also muss man mit dem benuterspezifischen Tteil warten, bis sich der User anmeldet, und disen Teil auch bei jedem künftig anmeldenden User wiederholen.
Manche Programmierer - siehe z.B. auch Microsofts Internet Explorer Leute oder die Office Truppe - haben aus diesem Grund eigene Behandlungen für benutzerspeziische Defaultwerte eigebaut, man sieht z.B. beim ersten Login bis hete idR. die Profilinitialisierung des Internet Explorer einmal ablaufen. Auch Office hat einen eigenen, proprietären Mechnismus sich Defaultwerte zu besorgen, sobald ein Benutzer zum ersten Mal eine Office-Komponente öffnet. Die zugehörigen Defaultwerte lesen die initialisierprogramm aus eigenen daten aus, teilweise aus Textdateien, XMLdateien oder aus speziell dafür angelegten Registry-Keys unter HKEY_LOCAL_MACHINE.
Fazit: man muss eigentlich zwei Pakete verschicken. Ein maschinnspezifisches einmalig an jede Maschine, und ein benutzerspezifisches einmalig für jeden Benutzer bei seiner nächsten Anmeldung. Ersteres bedient den HKEY_LOCAL_MACHINE, letzteres den HKEY_CURRENT_USER.
Das benutzerspezifische Paket konkurriert dabei auch mit anderen Mechanismen, die nach HKEY_CURRENT_USER schreiben können, z.B. Login-Scripts und Gruppenrichtlinien mit selbstdefinierten (custom) ADM Vorlagen. Man kann also auch drauf verzichten, wenn man seine Eintäge anders an den Client bringt. Und man braucht es nicht, wenn die zu verteilende Software einen eigenen Intialisiermechanismus mitbringt (muss sich dann aber naürlich mit dem proprietären Initalisiermecanismus beschäftigen um herauszufinden, wie man seine eigenen Werte da reinbekommt).
Und bevor jemand auf die naheliegende Idee kommt: das „Default User“ Profil hilft nicht, das macht zwar etwas Ähnliches, aber dummerweise nur ein einziges Mal, nämlich bei der Erstanmeldung eines Benutzers an einer Maschine. Da man Software oft viel später ausrollt ist es nicht zu gebrauchen. Für eine Erstbetakung von Maschinen dagegen kann man es durchaus einsetzen um den benutzerspezifischen Teil abzufackeln. und der .Default Rregistry-Key behanelt den Login-Bildschirm, hilft also auch nicht.
Das Denk modell mit den 2 Paketen weist also die richtige Richung.