Problem mit Pfadangaben in GPO 32/64-Bit

[kaineanung 14]

Hallo Leute,

 

ich bereite unseren Umstieg von LOGON-Script auf GPO vor und habe gerade ein Problem bei dem ihr mir hoffentlich helfen könnt.

Im LOGON-Script haben wir zu beginn ermittelt ob es sich um ein Office 32 oder 64-Bit Version handelt und den Pfad zum Office-Produkt in eine Variable gesetzt.

Im weiteren Verlauf wollen wir im LOGON-Script eine DOTM-Datei in einem Unterverzeichnis von Office tauschen und greifen eben über die Variable auf den korrekten Pfad zu.

Somit ist es egal ob Office nun im 'Progam Files' oder 'Program Files (x86)' liegt.

 

 

Bei GPO habe ich keine Möglichkeit vorher herauszufinden welche Bit-Version installiert ist und entsprechend Pfad zu setzen.

Ich müsste also 2x die Gleiche Dateioperation erstellen mit jeweils unterschiedlichen Pfadangaben. Um sauber zu arbeiten könnte ich ja noch die Zielgruppenadressierung nutzen und dort per MSI-Produktcode zu bestimmen ob das jeweilige Vorhaben ausgeführt werden soll oder nicht (32 Bit-Ausführung nicht bei 64-Bit Office ausführen und umgekehrt).

 

ABER: das ist ja dann alles Doppelt und b***d. Gibt es nicht vielleicht einen Möglichkeit doch eine Dateioperation auszuführen (BAT-Start- bzw. Anmelde-Script in diesem Falle) wo es egal ist ob im 32-Bit oder 64-Bit-Pfad gearbeitet wird?

[testperson 1.680]

Hi,

vor 2 Stunden schrieb kaineanung:

ich bereite unseren Umstieg von LOGON-Script auf GPO vor und habe gerade ein Problem bei dem ihr mir hoffentlich helfen könnt.

um es ziemlich kurz zu machen: Ich würde beim Script bleiben. ;)

 

Gruß

Jan

[daabm 1.355]

...und bei GPP könntest Du eine Zielgruppenadressierung auf Datei nutzen - mußt dann halt 2 Items machen. Oder Registry - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun:InstallPath (wenn Du ClickToRun hast, sonst natürlich anders). Geht alles irgendwie

Aber Logonskript würde ich auch beibehalten - gibt irre viel, was damit viiiiel einfacher und zuverlässiger und schneller ist als rein mit GPOs.

[kaineanung 14]

Irgendwas machen wir dann aber falsch. Wir benutzen Windows 20013 als DC-Server und da war GPO noch nicht wirklich mächtig. Jetzt steigen wir um auf 2016 und will endlich weg vom irre lang dauerenden LOGON-Scrupt (5-6 Konsolen poppen auf und verschwinden wieder, dauert gefühlt eine Ewigkeit bis man was machen kann und muss man irgendwo nebenbei was eintippen (Groupware-Logon) fliegt der Fokus während des Startvorganges immer weg usw.. ). :(

 

Da wäre mir eine Hintergrundlösung viel lieber und ich wundere mich, nein, ich bin sogar entsetzt das ihr LOGON-BAT dem GPO bevorzugt! Das wird mir jetzt wirklich und ohne Spaß Kopfzerbrechen und schlaflose Nächte bereiten. Ich habe auch schon soo viel Zeit in den Umstieg gesteckt!

 

 

Am 13.8.2019 um 20:16 schrieb daabm:

...und bei GPP könntest Du eine Zielgruppenadressierung auf Datei nutzen - mußt dann halt 2 Items machen.

Mir wurde hier gesagt das Anmeldescript für
Kopiervorgänge (Robocopy) besser sei. Dort kann ich aber keine Zielgruppenadressierung machen. Muss ich das dann wieder 'BAT-Like' machen wie bisher mit prüfen welcher Pfad denn vorhanden ist und entsprechend im Script reagieren?

Ist das so auch von MS so angedacht?

[daabm 1.355]

Ich hab nix von logon.bat geschrieben - meine heißen immer logon.vbs oder logon.ps1. Wenn da 5 Konsolenfenster aufpoppen, ist das eher Chaos bei der Administration. Und wenn es "irre lange" dauert, ist das auch Chaos bei der Administration. Lang dauernde Anmelde-Tasks startet man asynchron in eigenen Threads. Gibt genug Möglichkeiten dafür.

[kaineanung 14]

Nein, die LOGON.BAT wird ja abgeschafft.

Wenn Scripte dann ja nur noch in GPO->Anmeldescript.

Aber in diesen Scripten (bei mir ersteinmal BAT da ich nicht wei0ß ob VBS ein Vorteil bringen würde und PowerShell ich keine Ahnung von habe) muss ich nach wie vor dann prüfen ob 23 oder 64-Bit und dann entsprechend Robocopy anweisen Vorlagendateien in das richtige Verzeichnis (z.B. Startup-Verzeichnis von Office) zu kopieren.

 

"Irre lange" war bisher in der Logon-Bat mit 5 aufpoppenden Konsolen nacheinander. Das will ich jetzt wegbekommen. Daher auch meine Sorge vor Scripten statt GPO....

Aber Scripte die ich per GPO starte sind ja unsichtbar wie ich bisher sehe...

und asynchron werde ich es dann machen wenn es zu lange dauert...

 

Zu Asynchron habe ich ja in einem anderen Thread bereits Fragen gestellt wie ich das denn mache. Davon gemerkt habe ich nämlich nichts obwohl ich testweise über 100 MB kopiert habe beim Login. Desktop hat sich immer erst danach aufgebaut, egal ob ich 'Anmeldescripts gleichzeitig ausführen' aktiviert oder deaktiviert hatte...

[Nobbyaushb 1.471]

OT: wozu kopiert man 100MB beim logon?

 

Und - wir arbeiten auch viel mit GPP / GPO, aber unser Logon startet mit kixtart - Ende OT

[kaineanung 14]

vor 29 Minuten schrieb Nobbyaushb:

OT: wozu kopiert man 100MB beim logon?

 

Das hatte ich geschrieben:

vor 32 Minuten schrieb kaineanung:

Davon gemerkt habe ich nämlich nichts obwohl ich testweise über 100 MB kopiert habe beim Login

 

Stichwort: 'testweise'.

Ich wollte einfach sehen ob es nach dem Desktopaufbau oder davor kopiert wird. Bei 1-2 MB ist die Zeit zu kurz um es genau bestimmen zu können. Daher testweise eben 100 MB.

Fazit ist aber wie ich bereits geschrieben habe: Desktop wird erst danach aufgebaut. Egal ob 'Anmeldescripts gleichzeitig ausführen' aktiviert oder deaktiviert ist.

[MurdocX 952]

Ergo, nicht für den Login geeignet. Damit müssen andere Varianten genutzt werden.

 

Tipp: Die Powershell ist ein sehr nützliche, starke und objektorientierte Skriptsprache. 

 

Mach es wie @Nobbyaushb empfohlen hat über die Zielgruppenadressierung. Es können ja 10 Skripts existieren, jedoch sollte dadurch so wenig wie möglich ausgeführt werden.

[kaineanung 14]

vor 2 Minuten schrieb MurdocX:

Mach es wie @Nobbyaushb empfohlen hat über die Zielgruppenadressierung. Es können ja 10 Skripts existieren, jedoch sollte dadurch so wenig wie möglich ausgeführt werden.

Nobby hat irgendwas von kixstart geschrieben gehabt. Das ist ja kein MS-Tool 'onboard' und wir haben das nicht. Ausserdem würde ich erstmal gerne bei bordmitteln bleiben wollen bevor ich mich selber überzeugt habe das die nicht gut sind.

 

Was die Zielgruppenadressierung angeht:

Bei GPO gibt es die ja so nicht:

Benutzerkonfiguration->Richtlinien->Windows-Einstellungen->Skripts(Anmelden/Abmelden)->Anmelden

Dort kann ich dann beliebig viele Scripts hinzufügen, Reihenfolge ändern und das war es... Aber Zielgruppenadressierung gibt es bei GPP. Scripte soll ich dem jedoch bevorziehen laut diversen Aussagen hier.

Daher bin ich jetzt verwirrt und frage deshalb nochmals: Soll ich GPP mit Zielgruppenadressierung verwenden (dort dann je ein Script für 32 und eines für 64 Bit Systeme mit Zielgruppenadressierung -> entsprechend ermitteln und dann laufen lassen) oder soll ich Scripte wie BAT verwenden und dies wie bisher auch in dem Script ermitteln ob 23 oder 64-Bit und entsprechend kopieren?

 

[daabm 1.355]

Nimm 24 Bit, das ist genau ein Kasten... SCNR

Und lies Dich mal in die verschiedenen Möglichkeiten ein, wie man administrativ was ausführen kann. Task bei Anmeldung, Logonskript, "Run" etc.

[PyroTFD 14]

@kaineanung wenn du wirklich per GPO was ausrollen willst und dort auf 32 oder 64 Bit Office prüfen, dann wird die Sache auch nicht besser.
Das Problem ist, dass du dann mit einem fachmännischem Griff per WMI - Check auf die Ordner zugreifen musst und DAS dauert noch länger als wenn du es mit einem Skriptlein machst. Der Rechner wird nämlich alle Ordner erst mal auflisten müssen und daher einlesen...
WMI in den GPOs für 32 Bit

SELECT * from Win32_Directory WHERE Name="C:\\Program Files (x86)\\Microsoft Office\\Office16\\STARTUP" bzw.

SELECT * from Win32_Directory WHERE Name="C:\\Program Files (x86)\\Microsoft Office\\root\\Office16\\STARTUP"   (je nach Office Version)

WMI in den GPOs für 64 Bit dementsprechend

SELECT * from Win32_Directory WHERE Name="C:\\Program Files\\Microsoft Office\\Office16\\STARTUP" bzw.

SELECT * from Win32_Directory WHERE Name="C:\\Program Files\\Microsoft Office\\root\\Office16\\STARTUP"   (je nach Office Version)

...ob das Skript .vbs oder .ps1 oder .kix oder .cmd/.bat als Endung hat ist entweder reine Vorliebe des Admins oder je nach Bedarf zu überlegen

IMHO einer der schnellsten Checks für CMDs ist auf den Pfad der ospp.vbs zu checken - die ist nämlich jeweils in den Verzeichnis, der Office Version (wenn in "%programfiles(x86)%\microsoft office\office16\ospp.vbs" - dann 32-Bit) 

Vorteil ist, wenn du es als ein Allgemeines Skript schreibst, dann kannst es in diesem dann auch prüfen ob 32 oder 64 Bit und je nachdem die restlichen Befehle ausführen lassen. - wenn es geht, dann setze es einfach in eine Variable und schon brauchst du wahrscheinlich keine weiteren Unterschiede mehr von den ausgeführten Dingen.

und wie und wo du das Skript ausführst - ob als Startskript am Client, im Netlogon (per Link oder GPO getriggert) das kommt am ehesten auf den Einsatz des jeweiligen Skriptes an - da bin ich ganz auf Seiten von @daabm  :)

---

 

Anmerkung meinerseits, weil es ja heißt: Es würde nicht gehen - würde es schon, es wäre nur mehr als schlecht es so zu nutzen!

 

bearbeitet 27. August 2019 von PyroTFD

[daabm 1.355]

@PyroTFD Je nach Office-Version geht das viel einfacher - Group Policy Preferences mit Zielgruppenadressierung "Datei vorhanden" oder Registry -> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun (der Pfad ist natürlich je nach Office-Version ein anderer...) Mit der Registry-Variante könnte man sich theoretisch wohl auch durch die File Associations über docx oder so was an Office herantasten

Der WMI-Filter auf Dateien ist übrigens sauschnell, wenn man nicht vergißt, den vollständigen Pfad anzugeben - also vor allem inklusive Laufwerk und komplettem Pfad. Ein Filter auf "cmd.exe" dauert in der Tat sehr lange

[PyroTFD 14]

@daabm jo, das wäre auch eine Möglichkeit. Mittlerweile gibt es für solche Dinge so viele verschiedene Möglichkeiten, dass es schon fast wieder witzig ist.

docx oder andere neue Dateiendungen würde ich nicht unbedingt empfehlen. Da kann es schon mal andere Office Hersteller auch erwischen :)

(zB: WPS Office oder LibreOffice können ja auch mit docx umgehen....)  ;)