Ok – nun gibt es (surprise, surprise) eine andere Meldung, die ich bisher noch gar nicht gesehen habe:
Aber dafür steht in den Results nun auch erstmals:
Herunterfahren
Name Zuletzt ausgeführt Skriptreihenfolge im Gruppenrichtlinienobjekt Ausschlaggebendes Gruppenrichtlinienobjekt
\\server\sysvol\<meine-domain>\scripts\default-school\custom\windows\veyon-silent.bat 21.12.2020 20:17:08 Nicht konfiguriert veyon-Silent-Installation
Immerhin wurde also jetzt versucht, das Script ausführen – das Paket ist aber leider weiterhin nicht drauf. Das spricht nun alles für ein Rechteproblem bzw für den Zugriff auf die .exe-Datei (für veyon gibt es meines Wissens kein .msi-Paket) in dem program-Ordner.
Hallo Michael,
ich hab das gerade mit einem Windows Server getestet. Ein LM7 oder einen anderen Samba hab ich aktuell nicht da.
Mit GPO und Skript mit folgendem Inhalt \\PDC\Software_Verteilung\veyon.exe /S hat es funktioniert.
Ich tippe jetzt bei dir auf ein Rechteproblem des Freigabeordners.
Die GPO wird übernommen, das Skript mit Silentinstallation funktioniert, also bleibt nur das.
Ich teste da mal noch etwas und gebe dann Rückmeldung.
Definitiv. Gerade im Moment.
Windows führt GPOs mit dem Benutzer „System“ aus, das ist quasi root. Das Computer-Konto oder der Benutzer regelt nur die Zugriffsrechte, auf wen die GPO angewendet wird.
Beide Endungen sind erlaubt. CMD ist neuer als BAT und es gibt ein paar Unterschiede im Detail, aber hier ist das egal
Ja, mittlerweile bin ich auch sicher, dass es ein Rechteproblem ist … ich habe zusätzlich nochmal eine GPO für 7zip.msi angelegt und auf den Server nach \\server\default-school\program\7zip\7zip.msi gepackt. Im Windows-Explorer kann auf diesen Ordner zugegriffen werden … aber offenbar steht der für die Softwareinstallation beim Systemstart dem User „System“ nicht zur Verfügung?!
Ich habe in den results nun auch einen 2. Fehler, der besagt, dass die Installation nach 550 Millisekunden abeschlossen wurde – dann aber die Meldung, dass auf die Quelle nicht zugegriffen werden kann.
Wenn das so ist, geht die Frage nochmal an die @Entwickler: Wie ist das offiziell gedacht? Wohin sollen denn Pakete gepackt werden, die per GPO verteilt werden sollen? Es gibt neben default-school ja auch noch linuxmuster-global– wo liegt da der Unterschied? Warum gibt es diese Unterscheidung überhaupt? Oder anders gefragt: Wie muss man die smb.conf gestalten, damit der Zugriff klappt?
Hier nochmal zum Vergleich – es sieht zunächst ziemlich identisch aus :
[default-school]
comment = Share for default-school
hide unreadable = Yes
path = /srv/samba/schools/default-school
read only = No
strict allocate = Yes
valid users = LINUX\administrator @LINUX\SCHOOLS
[linuxmuster-global]
comment = Share for school global
hide unreadable = Yes
path = /srv/samba/global
read only = No
strict allocate = Yes
valid users = LINUX\administrator @LINUX\SCHOOLS
In den ACLs sind Unterschiede zu sehen:
[root@server:~]$ getfacl /srv/samba/schools/default-school
getfacl: Removing leading '/' from absolute path names
# file: srv/samba/schools/default-school
# owner: root
# group: ssl-cert
user::rwx
user:3000018:r-x
user:3000020:r-x
user:3000021:r-x
group::---
group:root:---
group:LINUX\134domain\040admins:rwx
group:LINUX\134s_default-school:r-x
group:LINUX\134students:r-x
group:LINUX\134teachers:r-x
mask::rwx
other::---
default:user::rwx
default:user:3000004:rwx
default:user:3000019:rwx
default:group::---
default:group:root:---
default:group:LINUX\134domain\040admins:rwx
default:group:LINUX\134admins:rwx
default:mask::rwx
default:other::---
Und im Vergleich dazu:
[root@server:~]$ getfacl /srv/samba/global
getfacl: Removing leading '/' from absolute path names
# file: srv/samba/global
# owner: 3000022
# group: root
user::rwx
user:3000004:rwx
user:3000025:r-x
user:3000026:r-x
user:3000027:r-x
group::---
group:root:---
group:LINUX\134domain\040admins:rwx
group:LINUX\134global-admins:rwx
group:LINUX\134schools:r-x
group:LINUX\134global-students:r-x
group:LINUX\134global-teachers:r-x
mask::rwx
other::---
default:user::rwx
default:user:3000004:rwx
default:user:3000022:rwx
default:group::---
default:group:root:---
default:group:LINUX\134domain\040admins:rwx
default:group:LINUX\134global-admins:rwx
default:mask::rwx
default:other::---
Am einfachsten in die GPO selber oder eben auf einem UNC Pfad wo der entsprechende User/Computer zugriff hat. Ein Share auf dem die Computer zugreifen können gibt es im Standard nicht.
Global ist nur bei Multischulumgebungen Interessant und kann daher in einer Single Schule nahezu ignoriert werden. Wichtig ist nur zu wissen, dass dort der Global-Admin auch sein Home hat.
Die muss nicht angepasst werden. Davon würde ich auch schwer abraten.
Hallo @Maurice und @Blair
Den ersten Teil des Satzes verstehe ich nicht … ich dachte, dass ich genau das die ganze Zeit mache?!
Mittlerweile weiß ich es allerdings ganz sicher: Es liegt an der Freigabe \\server\default-school\program\ von der ich bisher dachte, dass sie (auch) zu diesem Zweck verwendet werden kann. Ich habe es zu Testzwecken einfach so gemacht, dass ich die Installationsdateien zu veyon und 7zip lokal auf Laufwerk D:\ abgelegt habe. Und siehe da: Die automatische Installation läuft: Sowohl veyon als auch 7zip wurden automatisch beim Systemstart installiert!
Daher stellt sich nun eigentlich „nur“ noch die Frage, wie die Zugriffsrechte auf den Ordner program erweitert werden müssen, damit es auch über den UNC-Pfad klappt!??
„Zuletzt“ übrigens nochmal eine Frage, die direkt gaaaaanz am Anfang meiner „Expedition in die wundersame GPO-Welt“ aufgetaucht ist. Beim ersten Start des Gruppenrichtlinieneditors hatte ich diese Meldung:
Ich habe das nach einigem Zögern mit OK abgenickt und hoffe, dass dadurch auf dem Server nichts wesentliches verstellt wurde oder neue Probleme möglicherweise erst dadurch verursacht wurden??
… und noch eine Ergänzung: ich habe die .msi/.exe-Pakete probeweise mal auf ein anderes Share gelegt. Wir haben ein XigmaNAS – da gibt’s ein paar Samba-Shares … und was soll ich sagen: Damit lief es! Sowohl veyon-setup.exe als auch 7zip.msi als auch putty.msi wurden anstandslos installiert.
Jetzt stehen mehrere Dinge fest:
Die LOKALE Richtlinie „auf Netzwerk warten“ MUSS auf jeden Fall gesetzt werden
Das Server-Share \\server\default-school\program ist ootb nicht geeignet, da die Rechte nicht ausreichen
Und noch etwas fiel mir auf: Nachdem die Installation von 7zip.msi erfolgreich lief, habe ich das Paket nochmal deinstalliert um zu schauen, ob es beim nächsten Start wieder drauf ist … Fehlanzeige! Bei veyon funktioniert das zuverlässig aber bei 7zip nicht! Dazu passt offenbar:
Vielleicht könntest du erläutern, wie mit Samba eine entsprechende Freigabe erstellt werden kann.
@Michael
Ich denke, mit „Am einfachsten in die GPO selber“ ist der entsprechende Ordner im SYSVOL gemeint. Jede von dir erstellte GPO wird in einem eigenen Ordner abgelegt. Von einem Windows Client ist das normalerweise unter \\server\sysvol\deinedomain\Policies. Die Ordner in diesem Pfad enthalten die einzelnen erstellten GPOs.
Der Pfad wäre dann soetwas wie \\server\sysvol\deinedomain\Policies{72B6D74E-300F-4AE2-9776-DA2A75965349}, wobei der letzte Teil durch die Gruppenrichtlinienverwaltung in der entsprechenden GPO unter Details/EIndeutige ID zu finden ist.
Das hat bei mir funktioniert.
Es ist aber dennoch kein wirklich sinnvoller Ort für eine Softwareverteilung.
Schau mal, ob es vom Windows Client ein Verzeichnis \\Server\netlogon gibt. Wenn die Veyon Dateien da hineinkommen, dann sollte es auch gehen. Skript und GPO anpassen!
ok – DEN Ort finde ich allerdings auch nicht sinnvoll, um da die Pakete zu parken.
Das sollte schon einfacher/zentraler gehen. So wie Du es vorgeschlagen hattest mit \\server\software_verteilung\ o.ä. ist es schon übersichtlicher.
Übrigens bleibt es dabei, dass ich auf dem Server diesen Fehler bekomme:
[root@server:~]$ samba-tool gpo aclcheck
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'][0]
Weil man es doch da kaum wiederfindet, oder?! Oder wie gehst du bei einem Update eines Paketes vor? Bsp: Alte .msi-Datei gegen neue tauschen … Suchst du da nicht ewig?
Hallo Maurice.
Ok. Es geht hier immer nur um Spezial-Software für gewisse Clients. Daher sind es vermutlich tatsächlich nur weniger Verzeichnisse.
Bestes Beispiel
veyon – das soll hier nur auf ganz bestimmte Clients (funktioniert jetzt)
Anderes Beispiel:
Bestimmte Desktop-Icons auf gewisse Clients
Drittes Beispiel (bei dem es aber scheinbar schon wieder komplizierter wird?)
Default-Browser auf Firefox festlegen
Default Profile der User klein halten (geht das überhaupt über GPOs???)
Bestimmtes WLAN für Hardwareklasse vorgeben und automatisch verbinden lassen. Das scheint >>> so zu gehen!
Die Installation von Software ist also nur ein Teil dessen, was mir so vorschwebt … die meiste Software ist eh bereits im default-LINBO-Image enthalten …
Wenn das mit GPOs alles gut funktioniert, muss ich mich nicht auch noch in OPSI o.ä. einarbeiten – hoffe ich zumindest …
Hallo Christoph … das war aber auch ein dickes Brett, da es anfangs ja gleich an mehreren Stellen geklemmt hat … hinzu kam, dass es anfangs kaum Logs gab.
Aber wenn es nun funktioniert, ist ja was erreicht … jetzt muss sich aber noch zeigen, ob man diesen Weg wirklich der Neuerstellung eines LINBO-Images vorzieht?!?
Was vielleicht noch reizvoll wäre: Wie ist das, wenn man Treiber nur in bestimmten Räumen benötigt … sofern es das Paket auch als .msi-Datei gibt, könnte man das nun ja auch damit gezielt an den Ort des Geschehens bringen…
Zudem haben wir ein paar Beamer-Wagen. Da lief das bisher so, dass ein automatischer Login stattgefunden hat. Auch das scheint mit GPOs halbwegs machbar zu sein – ob das jedoch sinnvoll ist, steht auf einem anderen Blatt…
Wenn das .msi/.exe Paket auf einem älteren Samba/NAS funktioniert und auf dem Samba 4 nicht, dann könnte eventuell das execute Bit auf der Installationsdatei fehlen. D.h. dann sollte auch ein manuelles Ausführen der Datei durch Doppelklick scheitern.
Mit Samba 4 wurde eingeführt, daß das Ausführungsrecht überprüft wird. Will man das übergehen, so kann man in /etc/smb.conf.admin setzen:
:
von 2013 (!!):