daabm

Für nen Anfänger ist Dein Code aber ziemlich - hm - fortgeschritten... Import-CSV erzeugt ein Array von Arrays - für jede Zeile eines. Wenn die Spalten Header haben, kannst mit "Select-Object" die passende Spalte extrahieren. Und - das wirst Du von andern auch noch hören - hier gibt es keine Lösungen, nur Hilfe zur Selbsthilfe "Was genau wo genau" macht höchstens Olaf ab und zu...

Zuerst mal: Nein, du willst KEINE universellen Gruppen benutzen. Nie. Zweitens: dsa.msc bringt je nach UAC-Einstellungen zwar einen Admin-Credentials-Dialog. Da kann der User aber auch seine "normalen" Creds eingeben, dann läuft sie halt in seinem Kontext. Drittens: Was genau funktioniert wie genau nicht? "Users" ist übrigens die falsche Gruppe - ich würde bei Delegationen nie mit automatischen Builtin-Gruppen arbeiten. Kann sein, daß es schon alleine daran liegt. Und wenn Du die Verwaltung von "Users" delegierst, dann ist damit genau gar nichts erreicht - das ist eine automatische Builtin-Gruppe, was soll da delegiert werden? Du mußt schon die Rechte auf die jeweiligen Benutzer- und Gruppen-Objekte delegieren (bzw. auf die OU, wo die sinnvollerweise drin sind).

Ist das der reale Code? Du fügst $data hinzu, lange bevor es gefüllt wird? Und ich würde der Listbox halt ein eindimensionales Array verfüttern, kein mehrdimensionales (wie es Import-CSV erzeugt). Select-Object dürfte Dir helfen nach dem Import-CSV

Berechtigungsprobleme sind heutzutage eigentlich keine Berechtigungsprobleme, sondern tatsächlich Konzeptprobleme.

Ne, wird er nicht. Wie denn auch und vor allem - warum?

Oh - doch, das tun sie. Wenn Du das reinprogrammierst, sogar extrem granular und flexibel...

Explorer - Drag'n'Drop? Verschieben geht ruck zuck...

So sieht's aus - ohne Anforderungen und ohne Qualitätsansprüche geht natürlich alles. Auch das, was eigentlich totaler Müll wäre

Ok .- wenn man RUP nutzt, sollte das hier aktiviert werden: https://gpsearch.azurewebsites.net/#2567 Sonst hast Du Deine aktuellen Probleme Und nein, nachträglich aktivieren hilft nicht, da ist das Kind schon in den Brunnen gefallen. Da Du von Orderumleitung sprichst: In den Umleitungsoptionen kann man die Admins ebenso hinzufügen. Wurde das nicht gemacht, gilt das oben gesagte sinngemäß

Kopierst Du die Datei? Dann würdest Du die Sicherheitszone "mitnehmen"... Und was Excel bei Öffnen und dann "Speichern unter" damit macht, da wäre ich dann komplett raus. Ich bin Sysadmin, kein Anwendungsbetreuer

Doch, es ist so daß Microsoft das nicht vorgesehen hat, daß bei der ANmeldung eines Users Dinge laufen, die NICHT im Kontext und mit den Rechten dieses User laufen.

RDP -> Server -> AppLocker. Mehr braucht man da eigentlich nicht. Und für die Schlangenöl-Fans noch den Defender aktivieren, ok

Was meinst Du mit "an ihrem lokale Ort"? C:\Users? Da geht das nie einfach so per Explorer - nimm ne Admin-Commandline... Und wozu überhaupt? Lokale Profile (und damit auch lokale Kopien servergespeicherter Profile) löscht man über Arbeitsplatz - Eigenschaften - Erweitert - Benutzerprofile. Oder über WMI (Win32_UserProfile). Wenn Du nur das Verzeichnis entsorgst, gibt es hinterher Probleme mit Apps.

Wir sind so ein RZ - Du mußt erst mal die Anforderungen klar beschreiben. Vorher gibt's keine sinnvollen Antworten

Die Office-Optionen sind seit längerem schon etwas "übergreifend"

Du hast vermutlich ein Problem mit Sicherheitszonen... Steck den Hostname und den FQDN des Servers im IE in die Trusted Sites, dann sollte es gehen.

Vermutlich würde es dem TO helfen, seine ADMX mal zu aktualisieren

Portfast ist aktiviert? Oder wie auch immer das heute heißt Alternativ https://www.gruppenrichtlinien.de/artikel/ssd-zu-schnell-synchroner-startvorgang-nicht-moeglich/

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.

Nein. Wenn keine Domänenverbindung besteht, geht das unendlich lange. Dein Problem ist ein anderes, aber das hast Du ja noch nicht wirlich beschrieben.

Skript unsichtbar ging mit VB-Script prima - "wscript //B logon.vbs". Heute wäre mir nichts direkt so einfaches bekannt.

Umpf - isses jetzt klar? "User ist Mitglied" und "NICHT User ist Mitglied" Und wir verbinden per Agent - aka "Skript". Besser is das.

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.

a) Korrekt. Deshalb auch "synchrone Anmeldeskripts" deaktivieren. c) Wenn a) umgesetzt, passiert das doch automatisch. Ich würde aber grundsätzlich was anderes empfehlen: 1. Anmeldeskripts synchron lassen. Hat den Vorteil, daß sie laufen, bevor der Desktop kommt. Das wiederum spart Nerven mit Netzlaufwerken und Druckern. Darf aber dann sonst auch NIX rein, was Zeit kostet. 2. Alles, was länger dauert, über "Diese Programme bei der Benutzeranmeldung ausführen" starten. Das läuft immer asynchron und erst, wenn der Desktop da ist (Run-Key in Registry, sinngemäß)

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