daabm

@SaschaVolk Du bist schon zu sehr auf die von Dir ausgedachte Lösung fixiert. Besser wäre hier im Forum erst mal "klar die Anforderungen definieren" und die Anfrage dann von jeder dafür möglichen Lösung zu befreien. Das führt in der Diskussion erfahrungsgemäß zu den besten Lösungsvorschlägen.

Schlechte leider auch Könnte man jetzt per Reverse NAT lösen, ändert aber nichts daran, daß Du Recht hast und man in produktiven Business-Netzen einen großen Bogen um 192.168/16 machen sollte.

Fehlermeldungen im Wortlaut sind immer hilfreich. Ein "whoami /groups" auf der Commandline sagt Dir schon mal, wer Du eigentlich bist. Und dann sehen wir weiter PS: Warum meldet sich ein Dom-Admin auf einem Client an? Der hat da nichts verloren, dafür erstellt man sinnvollerweise eine AD-Gruppe "Client-Admins".

@tesso hat's schon zweimal erwähnt: Alles, was hinter Invoke-Command steht, findet REMOTE statt. Und dort (auf dem anderen Rechner) existiert diese Variable $UserSID nicht, weil Du sie nicht per -Argumentlist an Invoke-Command übergibts. Da gibt's glaub Millionen von Fragen dazu bei Superuser.com Variante 2 funktioniert, weil Du hier kein Remote-Command ausführst, sondern lokal einfach zu einer Remote Registry verbindest. Die Befehle laufen aber nach wie vor lokal, also da, wo $UserSID existiert. Alles nur eine Frage des Scope

Was genau bedeutet "Zugriff auf die Dateien"? Wenn Du sie lesen kannst, kannst Du sie auch woanders hin kopieren. Was genau geht schief? Falls Du Dateien auf den C$-Shares in andere Ordner auf den gleichen C$-Shares kopieren/verschieben willst, scheiterst Du an UAC. Suchbegriffe: EnableLinkedConnections und UnfilterAdministratorToken. Und natürlich auch prüfen, wie sich das gleiche nicht im Explorer verhält (der mit UAC überhaupt nicht zurechtkommt), sondern auch auf der Comamndline

Hier ist schon der erste Fehler. Den "Hinweg" bekommst Du so hin, den Rückweg aber nicht.... Rest vom Thread muß ich erst noch lesen Und nachdem ich jetzt durch bin: Wenn es nur darum geht, ein zweites Netz zu haben, in dem Geräte sind, die iwie ins Internet kommen - stell da einen eigenen DHCP rein, der passend verteilt. Wenn das aber im Konzern-Netz mitspielen soll, dann scheiterst Du am fehlenden Routing auf dem Rückweg, weil dein "privates" Netz im Konzern-Routing unbekannt ist.

Gerne. Gibt hier so ein lustiges Feature, mit dem man Posts als Antwort oder hilfreich oder so markieren kann

Da kommt IMHO üblicherweise vorher noch eine Abfrage nach der Auflösung. Wenn man die einfach mit Esc wegdrückt, landet man bei der "alten" direkten Verbindung ohne RDP.

Naja, der Eventlog-Name sollte schon korrekt angegeben werden. Tipp: "Applocker" ist falsch Den richtigen Namen findest Du in jedem Applocker-Event, das Dich interessiert. Vermutlich brauchst Du 2 oder 3 Logs (Exe/MSI/Script/AppX/xyz). Edit: Das Skript hängt vermutlich als geplanter Task an einem Event-Trigger. Mit ein wenig Forschung kann man sich das Event dann auch direkt holen, das landet soweit ich weiß in Aufrufparametern des Tasks (und ja, auch ich müßte da erst forschen - hab ich noch nie gemacht, aber wenn ich so was implementieren würde, wäre das auf jeden Fall so möglich). Edit 2: Falsches Forum - hier bist Du richtig https://www.mcseboard.de/forum/71-windows-forum-—-scripting/

Du bist nicht alleine - https://www.giga.de/downloads/windows-10/tipps/loesung-wsus-fehler-0x8024401c-windows-10-updates/ Mehrfach versuchen sollte das irgendwann lösen.

Wir sind zwar keiner Deiner Kunden, aber bei uns könntest das sehen Sieht lustig aus - bei "whoami /groups" bin ich zeitgleich in den Domain Admins von 3 Domänen

Ja, das Homelaufwerk heißt auf deutsch Basisordner. Wenn Du das aktivierst, hat das Auswirkungen auf ein paar Umgebungsvariablen und Standardverzeichnisse. Wenn Du es einfach wie ein gewöhnliches Laufwerk verbindest, nicht.

Die kann seit kurzem übrigens - auch wenn sie noch DHCP macht - nen alternativen DNS ausliefern...

Ideal wäre der Admin-Rechner. Einfacher ist ein Jumpserver, auf dem man sich NICHT mit dem Work-Account anmeldet, sondern mit dem Admin.

Geht nur per Skript. Und über den Sinn von OCX-Registrierungen auf UNC-Pfaden (selbst wenn Du die Berechtigungen noch korrekt hinbekommst) möchte ich nicht diskutieren...

Screenshot wäre hilfreich, und Ihr habt hoffentlich das GPO-Caching abgeschaltet? Edit: Vergiß das mit dem Caching, hab Win7 überlesen - sträflich eigentlich, aber da gab's das noch nicht.

Vergiß "Primäre Gruppe" gleich wieder - das ist eine Krücke aus W2K-Zeiten, als Gruppen noch Limits bei den Mitgliedern hatten... Also hat man ein extra Attribut eingeführt, um Domain Users gescheit nutzen zu können - das waren nämlich oft zu viele für "normale" Gruppen... Und wenn Du das Laufwerk nicht als "Homelaufwerk" im AD-Account eingetragen hast, ist es eh egal, wie Du das verbindest. Idealerweise nur ein Share, immer auf dem gleichen Buchstaben. Und darunter dann Benutzer- oder Gruppenverzeichnisse, die dank ABE nur bei passenden Berechtigungen sichtbar sind. Sich widersprechende Zuordnungen mußt Du _vorher_ organisatorisch lösen, erst dann kommt die technische Umsetzung. Und ansonsten geht's mir wie @MurdocX - zu viel Text, zu wenig "konkretes Doing".

Hm - auch wenn's nicht wirklich hilft: Wir nutzen LDAPS seit Jahren ohne Probleme. Und alle Connect-Fehler waren eigentlich immer Fehler in der Infrastruktur - bevorzugt Firewalls... Nur können wir das immer schlecht beweisen Ein Hinweis auf "Infrastruktur" wäre ein ganz schnell durchzuführender Test - wenn ich das richtig verstanden habe, kannst Du per RDP weiterarbeiten, wenn LDAPS nicht geht? Dann probier in dem Moment mal LDP lokal auf dem DC mit Bind auf sich selbst. Wenn das geht -> Netzwerk...

Warum fragt er nicht selbst? Dieses Forum zu bedienen ist ja keine Raketenwissenschaft, und - meistens - sind hier auch alle recht freundlich

In der Tat - soll es für den Rechner gelten oder für den User?

Ich kapier das mit "SID maskieren" schon nicht... Service-SIDs sind ja nix besonderes, sondern nur die Übersetzung des Service-Namens. Da gibt's nichts zu maskieren. Aber vermutlich versteh ich's komplett falsch, da eh nicht...

Vielleicht hilft da https://michlstechblog.info/blog/windows-10-windows-update-search-returns-error-0x8024500c/ um einen Lösungsansatz zu entwickeln.

Der Frage schließe ich mich direkt an - und zitiere dann mal @NilsK - Was ist denn die "ursprüngliche" Anforderung? Grundsätzlich kann man Freigaben per GPO einrichten - aber man kann sie nicht konfigurieren. Keine Share-Berechtigungen, keine NTFS-Berechtigungen, einfach nix. Das läuft also unter #grütze.

Fehlerquelle #1 bei AD: DNS Fehlerquelle #2: Fehlende TCP-Erreichbarkeit (Firewalls) Dann kommt ganz lange nichts mehr Wenn Du später Eventlog-Einträge erklärt haben möchtest, poste bitte nicht nur die Event-ID - die sagt den wenigsten was. Nimm einfach das ganze Event, ggf. um sensitive Infos bereinigt.

Was hast für Ansprüche an "Kompatibiliät"? Laufen wird 2019 auf jeden Fall, wenn irgendwas ab 2008 läuft. Und die Kernel-Basis von 2019 (inkl Treiberarchitektur und vielem innerem Gerümpel) ist identisch mit Win10 1809 (oder war das noch ne 17xx? Egal, W10 jedenfalls). Hier hat's mit 2019 überall geklappt, auch auf HW, die ursprünglich mit 2012R2 neu angeschafft wurde. Ist glaub sogar der gleiche Xeon drin Nur mehr RAM.