Samba 4 als AD: GPOs werden nicht ausgeführt
Hallo.
Ich weiß -- diese Frage lief schon x-fach ... trotzdem komme ich nicht weiter und hoffe, dass hier jemand einen guten Tipp hat.
Ich habe zu Testzwecken eine neue GPO erstellt: 7zip als automatische MSI-Installation -- die GPO ist vorhanden und verknüpft.
Sie wird auch richtig angezeigt, wenn ich auf dem Server
ausführe.
Allerdings wird die Installation auf dem Win10-Client nicht ausgeführt. Ich habe bereits
(als Admin!)
laufen lassen und auch
-- dort wird die Richtlinie aber nicht bei den
aufgeführt.
Installiert ist ein Ubuntu 18.04 LTS Server mit Samba 4.7.6 (aus der Paketverwaltung)
Zudem wundere ich mich darüber, dass ich auf dem Server bei Verwendung des Befehls:
Diese Fehlermeldung bekomme:
Die Suche nach dem Fehler liefert zwar viele Treffer -- aber nirgendwo eine Lösung.
Der Befehl läuft hingegen fehlerfrei durch
Ich sollte noch dazu sagen: eine andere GPO, die z.B. Netzwerk-Shares mit Laufwerksbuchstaben
verknüpft, wird bei jeder Anmeldung fehlerfrei ausgeführt! Das funktioniert also.
Ach ja -- und diesen ewig langen aber ziemlich alten Thread habe ich natürlich gefunden und den dort vorgeschlagenenen Workaround vom 20.11. auch schon ausprobiert -- hier hat das aber leider auch nichts gebracht. Die automatische Softwareinstallation will einfach nicht anlaufen...
Hat jemand eine gute Idee, wonach ich da schauen kann?
Danke!
Ich weiß -- diese Frage lief schon x-fach ... trotzdem komme ich nicht weiter und hoffe, dass hier jemand einen guten Tipp hat.
Ich habe zu Testzwecken eine neue GPO erstellt: 7zip als automatische MSI-Installation -- die GPO ist vorhanden und verknüpft.
Sie wird auch richtig angezeigt, wenn ich auf dem Server
samba-tool gpo list <laptop-name>
Allerdings wird die Installation auf dem Win10-Client nicht ausgeführt. Ich habe bereits
gpupdate /force
laufen lassen und auch
gpresult /H results.html /f
Gruppenrichtlinienobjekte --> Angewendete Gruppenrichtlinienobjekte
Installiert ist ein Ubuntu 18.04 LTS Server mit Samba 4.7.6 (aus der Paketverwaltung)
Zudem wundere ich mich darüber, dass ich auf dem Server bei Verwendung des Befehls:
samba-tool gpo aclcheck -k yes
ERROR(<type 'exceptions.KeyError'>): uncaught exception - 'No such element'
File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 176, in _run
return self.run(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/samba/netcmd/gpo.py", line 1150, in run
ds_sd_ndr = m['nTSecurityDescriptor']
Der Befehl
samba-tool ntacl sysvolcheck
Ich sollte noch dazu sagen: eine andere GPO, die z.B. Netzwerk-Shares mit Laufwerksbuchstaben
verknüpft, wird bei jeder Anmeldung fehlerfrei ausgeführt! Das funktioniert also.
Ach ja -- und diesen ewig langen aber ziemlich alten Thread habe ich natürlich gefunden und den dort vorgeschlagenenen Workaround vom 20.11. auch schon ausprobiert -- hier hat das aber leider auch nichts gebracht. Die automatische Softwareinstallation will einfach nicht anlaufen...
Hat jemand eine gute Idee, wonach ich da schauen kann?
Danke!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 634064
Url: https://administrator.de/contentid/634064
Ausgedruckt am: 04.12.2024 um 08:12 Uhr
11 Kommentare
Neuester Kommentar
mal mit GPRESULT /h gpresult.html checken warum die GPO nicht ausgeführt wurde. Damit man die Maschinen-GPOs angezeigt kriegt, muß man gpresult in einem CMD unter dem Adminkonto ausführen. An einem echten DC bzw. Server mit den GPO-Editor als Feature kann man auch eine GPO simulieren.
Ist oft nur eine falsche Platzierung, gibt ja grundsätzlch benutzerbaisete GPOs und Maschinenbasierte GPOs und eine für Domänencontroller.
Höchstwahrscheinlich trifft irgendeine Filterbedingung für deinen Windows 10 Client nicht zu.
Ist oft nur eine falsche Platzierung, gibt ja grundsätzlch benutzerbaisete GPOs und Maschinenbasierte GPOs und eine für Domänencontroller.
Höchstwahrscheinlich trifft irgendeine Filterbedingung für deinen Windows 10 Client nicht zu.
Hi,
Ergo
E.
- MSI-Installationen über GPO werden ausschließlich beim Computerstart angewendet und ggf. ausgeführt.
- Win10 mit seinem standardmäßigem "Hetz-Boot" "überspringt" einiges:
- das Netzwerk ist zu spät verfügbar
- wenn man Win10 "herunterfährt", dann wird es nicht vollständig heruntergefahren. Dem zur Folge startet es beim Wiedereinschalten auch "nicht vollständig" --> keine Ausführung von MSI-Software-Installation
- wenn man Win10 "neustartet", dann wird es vollständig heruntergefahren und startet anschließend auch vollständig --> MSI-Software-Installation wird ausgeführt, wenn Netzwerk verfügbar ist.
Ergo
- am Win10 Richtlinie aktivieren, dass bei Start und Anmeldung immer auf das Netzwerk gewartet werden soll
- am Win10 den Schnellstart deaktivieren (irgendwo bei den Energieoptionen)
E.