19
MSI Packet verteilen
Hallo alle zusammen,
ich bin zuzeit drüber ein MSI Packet per Softwareverteilung auszurollen. Habe das MSI zugewiesen und gesagt er solle es beim Anmelden installieren.
Ich gehe auf meinen Client gpupdate /force -> CMD sagt Abmelden? -> JA , und dann melde ich mich an und sehe auch beim Anmelden ... wird installiert für 4 sekunden
Ich schaue auf den PC und es hat nichts gebracht ...
Es handelt sich hier um das Tobit.MSI pakt für das Updaten des Clients
Wenn ich es manuell update schlägt er ja auch immer fehl -> Sie haben nicht die Rechte der Gruppe Administratoren für die Installation von david client sind diese Rechte unbedingt notwendig ......
Ich habe MSI Pakete so verstanden das Wenn man (jeder oder authentifizierte Benutzer Vollzugriff haben ) und sie können auch auf dem Pfad vom MSI da es zum testen auf einem public NAS liegt ...
Übersehe ich grad eine Sicherheitseinstellung?
Finden tut er ja das paket -> also Benutzerzuordnung stimmt schonmal
Berechtigung -> Jeder und Authentifizierte Benutzer =Vollzugriff
MSI Datei kann erreicht werden -> liegt auf Public NAS
Gruss
Joey hoff ihr habt nen tipp für mich
ich bin zuzeit drüber ein MSI Packet per Softwareverteilung auszurollen. Habe das MSI zugewiesen und gesagt er solle es beim Anmelden installieren.
Ich gehe auf meinen Client gpupdate /force -> CMD sagt Abmelden? -> JA , und dann melde ich mich an und sehe auch beim Anmelden ... wird installiert für 4 sekunden
Ich schaue auf den PC und es hat nichts gebracht ...
Es handelt sich hier um das Tobit.MSI pakt für das Updaten des Clients
Wenn ich es manuell update schlägt er ja auch immer fehl -> Sie haben nicht die Rechte der Gruppe Administratoren für die Installation von david client sind diese Rechte unbedingt notwendig ......
Ich habe MSI Pakete so verstanden das Wenn man (jeder oder authentifizierte Benutzer Vollzugriff haben ) und sie können auch auf dem Pfad vom MSI da es zum testen auf einem public NAS liegt ...
Übersehe ich grad eine Sicherheitseinstellung?
Finden tut er ja das paket -> also Benutzerzuordnung stimmt schonmal
Berechtigung -> Jeder und Authentifizierte Benutzer =Vollzugriff
MSI Datei kann erreicht werden -> liegt auf Public NAS
Gruss
Joey hoff ihr habt nen tipp für mich
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 241267
Url: https://administrator.de/contentid/241267
Ausgedruckt am: 05.11.2024 um 17:11 Uhr
19 Kommentare
Neuester Kommentar
hast du eine gpo für user oder computer erstellt? lg martin
Für User weils die anleitung von David so wollte
Für Computer auch grad mal gemacht selbes ergebnis ....
Moin,
bei manchen Paketen hilft hier das setzen der GPO AlwaysInstallElevated (Windows Components\Windows Installer):
http://blogs.technet.com/b/fdcc/archive/2011/01/25/alwaysinstallelevate ...
Grüße Uwe
bei manchen Paketen hilft hier das setzen der GPO AlwaysInstallElevated (Windows Components\Windows Installer):
http://blogs.technet.com/b/fdcc/archive/2011/01/25/alwaysinstallelevate ...
Grüße Uwe
Hey
Und mit diesem Always installe kann der User dann alles Installieren? Oder nur die MSI Pakete die ich freigebe weil so wie ich das verstehe , kann er dann alle msi pakte installieren egal ob ich das Freigegeben hab oder nicht ...
Grüß Joey
Und mit diesem Always installe kann der User dann alles Installieren? Oder nur die MSI Pakete die ich freigebe weil so wie ich das verstehe , kann er dann alle msi pakte installieren egal ob ich das Freigegeben hab oder nicht ...
Grüß Joey
sicher das ist natürlich nur das Mittel der letzten Wahl, falls alle Stricke reißen. Du kannst die Policy ja nach der erfolgreichen Ausrollung wieder zurücknehmen.
Noch zur Info:http://social.technet.microsoft.com/Forums/windowsserver/en-US/1aecdac4 ...
Noch zur Info:http://social.technet.microsoft.com/Forums/windowsserver/en-US/1aecdac4 ...
Das würde aber ja bedeueten -> ich gebe jedem die Möglichkeit an diesem Patchtag alles zu installieren ...
Weil wenn Alwaysinstall ausgerollt ist und dann David installiert ist nehme das Alwaysinstall wieder weg aber dann Arbeitet ja erstmal der Angestellte ... und könnte an diesem Tag alles installieren
Weil die Rechte wären ja erst nach einem Abmelden/Neustart wieder aktuell...
Ich denke das muss irgendwie anders gehn .... wir sind noch eine Recht kleine Firma 40 PC´s aber dieser Email Client wird auch an größere Firmen verkauft ... und glaube nicht das die alle so ein Sicherheitsrisiko eingehen
Oder heißt es dann wieder Arbeiten am Sonntag für das einspielen eines Updates ? :D
Weil wenn Alwaysinstall ausgerollt ist und dann David installiert ist nehme das Alwaysinstall wieder weg aber dann Arbeitet ja erstmal der Angestellte ... und könnte an diesem Tag alles installieren
Weil die Rechte wären ja erst nach einem Abmelden/Neustart wieder aktuell...
Ich denke das muss irgendwie anders gehn .... wir sind noch eine Recht kleine Firma 40 PC´s aber dieser Email Client wird auch an größere Firmen verkauft ... und glaube nicht das die alle so ein Sicherheitsrisiko eingehen
Oder heißt es dann wieder Arbeiten am Sonntag für das einspielen eines Updates ? :D
Mit "bei der Anmeldung installieren" kannst Du das ohne Alwaysinstallelevated nicht machen und das ist indiskutabel weil es ein großes Risiko ist, so etwas zu setzen.
Mach also entweder eine normale Zuweisung zu den Computerobjekten (empfohlen), oder, wenn es unbedingt nutzergebunden sein soll, ohne die Option "bei der Anmeldung iunstallieren".
Mach also entweder eine normale Zuweisung zu den Computerobjekten (empfohlen), oder, wenn es unbedingt nutzergebunden sein soll, ohne die Option "bei der Anmeldung iunstallieren".
Wenn ich es Benutzergebunden mache ohne "bei der Anmeldung installieren " Wann installiert er es dann ? muss der Benutzer dann was klicken? oder läuft das im stillen ab
Computerobjekten schlägt er ja leider auch fehl ... =( er ziegt es zwar bei der anmeldung an obwohl es nicht angeklickt ist (installieren bei anmeldung) aber das dauert 4 sekunden dann ist es weg also macht das anscheinend nichts oder?
Computerobjekten schlägt er ja leider auch fehl ... =( er ziegt es zwar bei der anmeldung an obwohl es nicht angeklickt ist (installieren bei anmeldung) aber das dauert 4 sekunden dann ist es weg also macht das anscheinend nichts oder?
also macht das anscheinend nichts oder?
schalte doch einfach die Windows Installer Protokollierung ein:http://support.microsoft.com/kb/2545723/de
dann weißt du was Sache ist
Computerobjekten schlägt er ja leider auch fehl ... =...
mit dem "=..." willst Du ausdrücken, dass sich der Fehler bei computergebundenen Zuweisungen gleich äußert? Nein, das siehst Du falsch. Eine computergebundene Zuweisung wird sich immer vor der Anmeldung installieren, Du hast nun vermutlich beides konfiguriert.Wenn ich es Benutzergebunden mache ohne "bei der Anmeldung installieren " Wann installiert er es dann ? muss der Benutzer dann was klicken? oder läuft das im stillen ab
Der Nutzer kann es dann über appwiz.cpl ->"Programme vom Netzwerk installieren" installieren (ohne Adminrechte!)
Hab ich mal aktiviert und in der Datei steht das :
Error 1406. Could not write value MSIPath to key \Software\Tobit\MSI\DVWIN32. System error . Verify that you have sufficient access to that key, or contact your support personnel.
=== Logging stopped: 18.06.2014 13:56:59 ===
Wenn ich es richtig versteh will das MSI in die Registery und einen Key ändern ?
Und da ich den Benutzer das recht der Registery bearbeitung weggenommen hab gehts nicht oder?
Error 1406. Could not write value MSIPath to key \Software\Tobit\MSI\DVWIN32. System error . Verify that you have sufficient access to that key, or contact your support personnel.
=== Logging stopped: 18.06.2014 13:56:59 ===
Wenn ich es richtig versteh will das MSI in die Registery und einen Key ändern ?
Und da ich den Benutzer das recht der Registery bearbeitung weggenommen hab gehts nicht oder?
Zitat von @Blindzerokiller:
Und da ich den Benutzer das recht der Registery bearbeitung weggenommen hab gehts nicht oder?
wenn du da was gefummelt hast vermute ich das stark....Und da ich den Benutzer das recht der Registery bearbeitung weggenommen hab gehts nicht oder?
Wie macht ihr denn so ein szenario?
Was dürfen eure Client?
Registry bearbeiten?
Programme installieren?
Oder benutzt wirklich jeder dieses Tool und geht das risiko für einen Tag ein?
Oder geht ihr an einem Sonntag in die Firma und lasst alle pcs per wake on lan anmachen -> meldet euch an per skript oder so und dann wenn alle fertig sind abmelden und das rechterollout zurück?
Was dürfen eure Client?
Registry bearbeiten?
Programme installieren?
Oder benutzt wirklich jeder dieses Tool und geht das risiko für einen Tag ein?
Oder geht ihr an einem Sonntag in die Firma und lasst alle pcs per wake on lan anmachen -> meldet euch an per skript oder so und dann wenn alle fertig sind abmelden und das rechterollout zurück?
wenn deine Clients bzw. User keine Adminrechte haben und die UAC entsprechend aktiviert ist, können diese sowieso keine lebenswichtigen Reg-Keys ändern, also brauchst du hier schon mal garnichts "extra" konfigurieren.
Da du hier anscheinend doch mehrere Policies in Richtung Benutzerrechte verstellt hast, ist mir klar warum bei dir die Softwareverteilung nicht so läuft wie sie soll. Hier greift vieles ineinander, da sollte man dann auch schon die Zusammenhänge alle kennen bevor man solche Dinge zusätzlich einschränkt, sonst wirst du immer auf irgendwelche Probleme stoßen die du dir nicht erklären kannst.
Halte dich an die best practices die du zum Thema "Software Deployment" zu genüge im Web findest.
Grüße Uwe
Da du hier anscheinend doch mehrere Policies in Richtung Benutzerrechte verstellt hast, ist mir klar warum bei dir die Softwareverteilung nicht so läuft wie sie soll. Hier greift vieles ineinander, da sollte man dann auch schon die Zusammenhänge alle kennen bevor man solche Dinge zusätzlich einschränkt, sonst wirst du immer auf irgendwelche Probleme stoßen die du dir nicht erklären kannst.
Halte dich an die best practices die du zum Thema "Software Deployment" zu genüge im Web findest.
Grüße Uwe
Mmm das probier ich dann gleich nochmal mit dem Computerzugewiesen, denke zwar ich habe es gelöscht bei benutzer.
appwiz.cpl ist gesperrt
(Wenn man das alleine aktivieren kann , müsste man das ganze doch per batch laufen lassen können ohne das der Benutzer was klickt oder?)
Also muss ich dem Client irgendwie ein bisschen rechte geben denk ich mal...
appwiz.cpl ist gesperrt
(Wenn man das alleine aktivieren kann , müsste man das ganze doch per batch laufen lassen können ohne das der Benutzer was klickt oder?)Also muss ich dem Client irgendwie ein bisschen rechte geben denk ich mal...
Zitat von @Blindzerokiller:
appwiz.cpl ist gesperrt (Wenn man das alleine aktivieren kann , müsste man das ganze doch per batch laufen lassen
können ohne das der Benutzer was klickt oder?)
ganz falscher Ansatz, behebe deine rigiden bzw. falsch gesetzten Einschränkungen, dann funktioniert das wie vorgesehen. Der Fehler liegt hier zu 99% an deinen falsch gesetzten Berechtigungenappwiz.cpl ist gesperrt
(Wenn man das alleine aktivieren kann , müsste man das ganze doch per batch laufen lassenkönnen ohne das der Benutzer was klickt oder?)
Also muss ich dem Client irgendwie ein bisschen rechte geben denk ich mal...
"bißchen Rechte geben"? 
Ja mach das, das spart uns hier erheblich an Diskutiererei warum es nur bei "Dir" nicht geht ...
Hi,
ich muss mich mal einmischen ...
@Blindzerokiller
Mit "Und da ich den Benutzer das recht der Registery bearbeitung weggenommen hab gehts nicht oder?" vermute ich doch mal, dass Du hier die Policy "Zugriff auf Programme zum Bearbeiten der Registrierung verhindern" aktiviert hast?
Falls ja, @colinardo, hat er wohl nichts an den ACL in der Regitry geändert. Außerdem wäre das bei Zuweisung per Computer irrelevant.
Mir sind selbst immer wieder MSI Pakete untergekommen, welche aus solchen Gründen (".. Could not write ..") nur interaktiv mit einem Administrator-Konto installieren werden konnte, UAC an oder aus. Der Grund ist fast immer, dass dann während der Installation an solchen Registry-Keys (oder auch Ordnern im Dateisystem) Berechtigungen gesetzt werden, die dann nur noch DIE Administratoren Schreibrecht gewähren. Warum auch immer. Ich muss hier "Absicht" der Programmierer unterstellen.
Jedenfalls gelingt mir hier meistens der pragmatische Ansatz: Was solls? Protokoll mitschreiben. Bei Zugriffsfehler in Registry oder Dateisystem die Pfade identifizieren. Diese dann z.B. per Script oder GPO-Erweiterung vorher erstellen, und per GPO die Berechtigungen dafür festlegen. Wenn das Paket dann wieder die Berechtigungen ändert, dann auch dafür sorgen, dass "Local System" (bei Zuweisung per Computer) oder die Gruppe "Benutzer" (bei Zuweisung per Benutuzer) dort keinen "Vollzugriff" haben (Berechtigungen nicht ändern können).
Was manchmal auch helfen kann ist, das Paket mit "msiexec /a" neu zu packen.
Es kann auch daran liegen, dass im Paket "Install per Machine" fest eingestellt ist, was dann dazu führt, dass die Zuweisung per Benutzer dann wohl aus Prinzip fehlschlägt. Diese Eigenschaft kann man z.B. mit Orca (http://msdn.microsoft.com/en-us/library/aa370557(v=vs.85).aspx) bearbeiten. (wenn man per Benutzer zuweisen will)
Vielleicht hifts ...
E.
ich muss mich mal einmischen ...
@Blindzerokiller
Mit "Und da ich den Benutzer das recht der Registery bearbeitung weggenommen hab gehts nicht oder?" vermute ich doch mal, dass Du hier die Policy "Zugriff auf Programme zum Bearbeiten der Registrierung verhindern" aktiviert hast?
Falls ja, @colinardo, hat er wohl nichts an den ACL in der Regitry geändert. Außerdem wäre das bei Zuweisung per Computer irrelevant.
Mir sind selbst immer wieder MSI Pakete untergekommen, welche aus solchen Gründen (".. Could not write ..") nur interaktiv mit einem Administrator-Konto installieren werden konnte, UAC an oder aus. Der Grund ist fast immer, dass dann während der Installation an solchen Registry-Keys (oder auch Ordnern im Dateisystem) Berechtigungen gesetzt werden, die dann nur noch DIE Administratoren Schreibrecht gewähren. Warum auch immer. Ich muss hier "Absicht" der Programmierer unterstellen.
Jedenfalls gelingt mir hier meistens der pragmatische Ansatz: Was solls? Protokoll mitschreiben. Bei Zugriffsfehler in Registry oder Dateisystem die Pfade identifizieren. Diese dann z.B. per Script oder GPO-Erweiterung vorher erstellen, und per GPO die Berechtigungen dafür festlegen. Wenn das Paket dann wieder die Berechtigungen ändert, dann auch dafür sorgen, dass "Local System" (bei Zuweisung per Computer) oder die Gruppe "Benutzer" (bei Zuweisung per Benutuzer) dort keinen "Vollzugriff" haben (Berechtigungen nicht ändern können).
Was manchmal auch helfen kann ist, das Paket mit "msiexec /a" neu zu packen.
Es kann auch daran liegen, dass im Paket "Install per Machine" fest eingestellt ist, was dann dazu führt, dass die Zuweisung per Benutzer dann wohl aus Prinzip fehlschlägt. Diese Eigenschaft kann man z.B. mit Orca (http://msdn.microsoft.com/en-us/library/aa370557(v=vs.85).aspx) bearbeiten. (wenn man per Benutzer zuweisen will)
Vielleicht hifts ...
E.
Hey
schonmal danke an alle für die Hilfe
Werd jetzt mal alle vorgenommen Einstellungen in unserer Domain überprüfen, was alles aktiviert ist. (Hab nicht ich erstellt ..)
Kann gut sein das es an Rechten scheitert von schreiben , in einem Tobit Forum sprachen Sie mal davon das das MSI Paket auf Hardware (Druckertreiber / Faxware was geändert wird und deswegen ohne Admin nicht funktioniert ... )
Nachdem ich alles mal zamgetragen hab meld ich mich nochmal vill fällt mir dann ja was auf was nicht geht
Das das MSI flasch gemacht wurde weiß ich nicht , aber ich hab ja beide wege versucht
MFG Joey
schonmal danke an alle für die Hilfe
Werd jetzt mal alle vorgenommen Einstellungen in unserer Domain überprüfen, was alles aktiviert ist. (Hab nicht ich erstellt ..)
Kann gut sein das es an Rechten scheitert von schreiben , in einem Tobit Forum sprachen Sie mal davon das das MSI Paket auf Hardware (Druckertreiber / Faxware was geändert wird und deswegen ohne Admin nicht funktioniert ... )
Nachdem ich alles mal zamgetragen hab meld ich mich nochmal vill fällt mir dann ja was auf was nicht geht
Das das MSI flasch gemacht wurde weiß ich nicht , aber ich hab ja beide wege versucht
MFG Joey
