daabm

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

Auch wenn es schon beantwortet ist: Wenn ich sowas per Skript auswerten will, dann trage ich es auch so ein, daß es per Skript einfach auswertbar ist - XML oder CSV oder so   Lesen kann man das dann immer noch.

Teuer ist relativ. Richtig teuer wird es erst, wenn man zu spät realisiert, daß man hätte investieren sollen.

ym2c...

Ne, wollen tut er nicht, aber müssen tut er sollen  

Ich gebe zu, daß ich das Problem "so" noch nie hatte... Vielleicht hilft das explizite NTLM-Auditing? 

https://blogs.technet.microsoft.com/askds/2009/10/08/ntlm-blocking-and-you-application-analysis-and-auditing-methodologies-in-windows-7/

Jo, da würde ich mich auch mal in UAC einlesen und das restricted Token...

Da brauchts kein Google.... Trend Micro -> "tm....sys", da sind wir schon im Boot  

Da hast Du die A-Karte gezogen. Wenn die - schlecht programmierte - Anwendung den Pfad "statisch" speichert, musst Du individuell korrigieren. Well Known Folders gibt es ja auch erst seit ca. 25 Jahren...

Ich weiß jetzt nicht, was das Azure-Cmdlet für eine Fehlermeldung ausspuckt (fehlt oben leider), aber mit Add-Member kannst ja fast beliebige Properties an ein Objekt pappen. Und wenn Du diese Property vorher als Objekt erstellst, kann das auch ein beliebiger Objekttyp sein.

Das ist der falsche (Legacy) Weg - der geht auf Netbios/NTLM. Korrekt wäre "Zuweisen von Benutzerrechten" per GPO. Und wenn bei RDP noch NLA aktiv ist, dann funktioniert Dein Weg eh nicht mehr.

Ich werf meine 2 Cent auch noch dazu Ja.