daabm

Sieht aus, als wenn es zu kompliziert wäre - vielleicht hilft es, wenn Du bei der ursprünglichen Anforderung anfängst und nicht erst da, wo etwas nicht mehr umsetzbar ist?

Dann ringe dich durch. Den Rest hast Du ja schon als ergebnisfrei ausprobiert....

...und ich verstehe schion die Frage nicht

Lösche einfach die zugehörigen Reg-Werte. Ohne DC-Verbindung werden GPOs nie angewendet.

https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html Mehr kann ich dazu nicht beitragen. Warum das nicht alle so machen, weiß ich nicht. Restricted Groups sind Grütze.

Ich korrigiere diesen grünen Frosch mal: Loopback gilt nicht "pro GPO oder für GPOs", sondern "für den Computer"... Mööp

Wie Norbert schrub .- wenn man schon auf die schräge Idee kommt, Laufwerke per GPP zu verbinden, braucht man für jedes Laufwerk 2 Einträge: Einen mit "Aktualisieren" und einen mit "Löschen". Das Item Level Targeting dann halt "invertiert". Und alles ist im Fisch - bzw. in Butter

Und warum klickst Du nicht einfach mal 3 Links weiter? https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-configure Mußt Du halt selber basteln - Du kannst ja die Liste von haveibenpwnd.org einbinden https://haveibeenpwned.com/Passwords Ach nee geht nicht, können nur 1000 Einträge sein...

Du suchtst "Simple Bind verhindern" (Steckt in den dsHeuristics, wenn ich das noch richtig weiß.) Windows-Clients in der Domäne haben damit kein Problem - die verwenden "Secure Channel", der ist verschlüsselt. Damit kannst Du aber NICHT verhindern, daß ein Drittclient per LDAP mit User/Kennwort ankommt, damit verhinderst Du nur, daß er damit auch noch Erfolg hat. LDAPS verpackt das dann wenigstens in SSL/TLS, so daß es nicht mitgelesen werden kann.

Stimmt "gpupdate /force /boot" ginge auch - oder einfach so neu starten.

Um das mal mit Erfahrungswerten ein wenig einzugrenzen: Member fliegen nicht "einfach so" aus einer Domäne. Dabei ist es unerheblich, wie lange sie offline sind - die Kennwortänderung eines Computerkontos wird immer vom Member initiiert, nie von einem Domain Controller. Und der Member merkt sich auch noch das vorherige Kennwort - schlägt die Authentifizierung mit dem aktuellen fehl, probiert er es mit dem vorherigen. Könnte ja ein DC erwischt worden sein, der noch nicht repliziert hat... Hast Du einen lokalen Admin (LAPS?), mit dem Du Dich im Fehlerfall anmelden kannst, um etwas weiter zu diagnostizieren, z.B. Eventlogs mal analysieren und ein paar Versuche mit NLTest zu machen? Wenn nein, wird's schwierig...

...wenn es mit einem Client gut ist und mit 2 nicht, würde ich die Infrastruktur verantwortlich machen: Verkabelung/Switche...

...und um die Ursprungsfrage einfach mal direkt zu beantworten: "gpupdate /?" liefert Dir die Antwort. Falls Du sie nicht erkennst: "/wait:0"...

Hier ist sehr viel durcheinander, und in jedem Beitrag gibt es Codeschnipsel, die auch immer nur auszugsweise sind. Vielleicht mal zurück auf Los und "komplett schildern"? Zum Anfangsproblem: Aus einer CMD mit .\script.ps1 zu arbeiten ist grenzwertig. Du weißt nicht, was das aktuelle Arbeitsverzeichnis ist ("cd" ohne Parameter verrät Dir das). Mit %~dp0 kommst Du an das Verzeichnis ran, in dem die CMD liegt (mehr dazu: "for /?"). Und mit >>log.txt 2>&1 kannst Du Batch-Output in eine Datei schreiben. Bei den Credentials hast Du vermutlich einen recht trivialen Logikfehler drin, aber in den Codeschnipseln von bisher ist das total undurchsichtig. "Falsches Kennwort" sagt für mich, daß Du Dich irgendwie im Konvertieren verrannt hast.

Adapterspezifsche Einstellungen per GPP direkt zu machen geht nicht - die Adapter verstecken sich hinter GUIDs... Prüf lieber, ob Deine GPO-Settings auf den Clients überhaupt ankommen. "gpresult /h report.html" in einer Admin-Commandline ist Dein Freund.

vhd nach vhdx geht ja noch, aber mir fehlt der Vorteil dabei - was kann vhdx besser? Davon abgesehen, auf einem USB-Laufwerk dürfte das Tage dauern...

Basisverzeichnis ist das Homelaufwerk, das kann ja für jeden User "irgendwo" liegen. Der Stammpfad ist für alle User gleich, und er kann sich natürlich vom Homelaufwerk unterscheiden. Es macht also NICHT das gleiche. Und beides taugt nix Wenn Du schon umleitest, leite um nach %homeshare%%homepath%Documents (ja, ohne "\").

Bissele OT, aber: O2016 sei die letzte Office-Version, die als MIS-Installation (ohne O365) den gleichen Funktionsumfang hat wie die O365-Version. Sagt unser Office-PFE...

Ich glaube, daß Du O365 willst - Du hast Dich nur nicht dazu durchgerungen, das auch zuzugeben Muß ja nicht die Online-Variante sein...

Nein, Du willst meinem "Vorschlag" nicht nachgehen. LOM ist nichts für KMU-Umgebungen, sorry. Und LOM ist eine globale Einstellung, da geht nix "selektiv". Da wäre es einfacher, die Gruppenstruktur so umzubauen, daß die delegierten Gruppen eben KEINE Auswirkungen weiter oben haben. Für Gruppen gilt prinzipiell das gleiche wie für GPOs: Was sich in unteren OUs befindet, darf weiter oben nicht verwendet werden. Sonst kann man nicht sinnvoll delegieren.

10 Leute, 10 Meinungen Beruflich: KeePass. Privat: LastPass - die Integration in alles mögliche ist da einfach unbezahlbar.

Transfer über das RDP-Mapping ist eine gnadenlose Krücke Schnarchlangsam. Besser gemeinsame SMB-Shares, die halt in beiden Umgebungen verfügbar sind. ym2c...

JEA taugt dafür nicht - da kannst die Sichtbarkeit der AD-Objekte nicht einschränken. Wenn das mit Bordmitteln gelöst werden MUSS, braucht es LOM (List Object Mode), und da fängt dann der ganz große Spaß an... Ich frage mal ganz anders: Was ist denn die Auswirkung, wenn der delegierte Admin da Computer und User aufnehmen kann? Was geht dann kaputt oder funktioniert nicht mehr oder hat zu viele Rechte?

Fehlende Rechte... Auf was auch immer genau, ich bin kein Exchange-Mensch, aber ich kenne das auch aus unserer Mail-Lösung, daß Du bei fremden Terminen eben NICHT siehst, wer zu- und abgesagt hast.

SPN geht halt nur bei Kerberos - das meiste dürfte NTLM sein. Ein DNS-Alias kann da helfen, aber wer per IP zugreift, hat immer verloren