Jump to content
kaineanung

Problem mit Pfadangaben in GPO 32/64-Bit

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

...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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


Werbepartner:



×
×
  • Create New...