daabm

Ich stimme dem zu und setze es mal in meine Wahrnehmung um: Hier kommen oft Anfragen, die bereits einen vorgedachten Lösungsweg enthalten. Die Anfrage bezieht sich dann aber nur noch auf den Lösungsweg, der irgendwie nicht funktioniert - und nicht auf das ursprüngliche Problem. Hat man das erst mal klar umrissen und vielleicht sogar in ein Flußdiagramm umgesetzt, ist es meistens viel einfacher. Und nein, das soll jetzt keine Kritik am TO oder an diesem speziellen Thread sein - das zieht sich quer durch alle Foren auf allen Plattformen

Offen oder zu, mit oder ohne Abstand, das hängt EXTREM vom Gesamtkonzept ab... Aktive Lüftung im Boden und/oder in der Decke oder den Schränken? Kalt/Warm-Gänge? So pauschal kann man das nicht beantworten.

GRRRR - es ist DAS Active Directory, nicht DIE Active Directory! Und ansonsten dürfte der Post von @NorbertFe wohl passen. Unter der Annahme, daß Sicherheitsfilter und Link und WMI-Filter nicht das Problem sind

Will jetzt keiner hören, aber ich hab alle 2016er, die zu mir gehören, inplace auf 2019 gehoben. Alle ohne Probleme (bis auf einen Bug in Windows Defender ATP, der für Hyper-V "Compute" Service ne Sonderregel mitbrachte, die wieder raus mußte). @lukasf besorg Dir mal err.exe (Download bei MS, gehört zu Exchange), mit dem kannst die meisten Errorcodes aufdröseln, vielleicht gibt das einen Hinweis. winerror.exe geht auch, das war zumindest mal im SDK dabei. Hilft, wenn man die Ursache und Schwere dieser Fehler interpretieren will.

Du leitest ins servergespeicherte Profil um? Ganz blöde Idee - da brauchst schon EINEN Share für die Profile und EINEN Share für die Umleitungen... Erschließt sich durch Nachdenken Edit: Eigentlich brauchst den ersten Share gar nicht - servergespeicherte Profile braucht man nur noch in TS-Umgebungen, nicht auf dem FAT Client.

Wenn der Explorer zickt, scheitern fast alle - woher ich das weiß? Da gibt's zu viele Schnittstellen, wo sich was verhaken kann...

Ich werfe mal https://www.urbackup.org/ in den Ring

Ich hätte das gar nicht erst als Upgrade gemacht, sondern gleich "clean". Aber ok, machste halt zweimal

Verwenden nicht mal wir - und unsere größten ntds.dit liegen bei etwa 13 GB, Sysvol weiß ich nicht aber auch deutlch mehr als 10 GB Repliziert sich alles irgendwann, und erst dann startet der neue DC das Advertising. IFM ist irgendwie Technik aus dem letzten Jahrhundert (ok, da gab's noch kein AD, fühlt sich aber halt so an )

...hat aber "eigentlich" pro SID ein Unterverzeichnis. Und damit sind meine Kenntnisse zum Papierkorb auch schon erschöpft - ich bin auf der Commandline unterwegs, da gibt es eh keinen

Relevante Daten des Benutzers kopieren ist i.d.R. die beste Lösung. Wenn man da ein halbwegs klares Prinzip hat, was und wo gespeichert wird, ist die Sicherung dieser "relevanten" Daten eine Sache von Minuten. Und dann platt und neu machen. Das ist fast immer (>99%) die für alle günstigste und beste Lösung. Ok, ich hab mich jetzt ein paar Mal wiederholt

Hinter den Profilordnern steckt die SID des Users. Wenn zur aktuellen SID schon ein Ordner existiert, der zu einer anderen SID gehört, wird die Domain angehängt. Alternativ und/oder zusäzlich laufende Nummern. Schau auf den Clients mal in HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList...

Ich bin kein Netzer - aber ich habe bittere Erfahrungen mit erratischem Verhalten der Netzwerk-Infrastruktur inkl. VPN, Routing und Firewalls. "Immer identisch" wäre wünschenswert, entspricht aber nicht dieser Erfahrung...

Das Konstrukt ist mindestens fragwürdig - und ohne "ping-success" erübrigt sich jede weitere Analyse. Da wirst Du per Forum auch kaum Unterstützung kriegen - das ist so low-level, daß das remote nicht zu unterstützen ist. IP-Netzmaske, IP-Adresse, Firewalls.

@MurdocX Bidi oder nicht ist egal, da geht's nur drum, wo User und Service (=Zielserver) zuhause sind (und nein, es gibt keine Ausnahmen - es geht bei den Trust Directions ausschließlich darum, wer wofür ein TGS haben will). Und wenn die Netzwerk-Firewalls (wie fast alle) die Pakete einfach droppen, dauert es natürlich einige Zeit bis zum Timeout und NTLM-Fallback. Das Paket wird ja verschickt, aber es kommt halt KEINE Antwort ala "no route" oder "destination unreachable", sondern einfach "nichts". Soweit ich weiß - aber ohne Garantie - müßte 88 reichen. 464 ist Passwort Änderung, das wird da eher selten vorkommen. Und 389/3268 sollte nicht benötigt werden. Aber das unterschreibe ich niemals

Du kannst mal testhalber HKLM\Software\Policies und HKLM\Software\Microsoft\Windows\CurrentVersion\Policies einfach komplett löschen, dann gpupdate /force. Mit Glück hat sich da nur was verhakt. Mit Pech fährt MSFT grad GPOs an die Wand... Rein "technisch" hast Du alles richtig gemacht.

Mit mir hat noch nie einer was geteilt, das mach immer nur ich

Nein, ist nicht so und war auch nie so. DCs sind keine "Kerberos-Proxies", sondern sagen Dir nur, wo Du hingehen sollst ("Referral"). Immer lesenswert dazu: http://technet.microsoft.com/en-us/library/bb742433.aspx Würde mich interessieren, wo im Netz Du das gefunden hast

Kerberos über Firewalls ist etwas "zickig", wenn da restriktiv geblockt wird. In Deinem Fall müssen wohl die RDS-Server von A die DCs aus B erreichen, weil der User ja aus B kommt. Grundsätzlich muß jeder Computer mit interaktivem Logon alle DCs erreichen, die a) zu seiner eigenen Domain gehören b) zu jeder Domain gehören, aus der ein trusted User kommen könnte

wenn Du keine Non-Windows-Geräte damit verwalten willst, würde ich das Stand heute noch nicht machen. Da kommt zu oft ein Stopschild, wenn man OS-nahe Komponenten verwalten will, und zwingend ist meist ganz vorne auch eine OS-Weiche

URL ist alles von http bis zum letzten Zeichen. Host ist der Teil zwischen :// und dem nächsten / (vereinfacht - ein Port wird natürlich ggf. herausgefiltert, genauso die obskure EInbettung von User:Password@Host).

Heute war alles ruhig, Workaround geht fröhlich in den Breiteneinsatz - und der restliche Patchday ist am Montag auch fertig verteilt. Läuft bei uns (Also nicht alles läuft, aber das läuft wirklich gut und schnell...)

AKA PEBKAC SCNR...

Der TO hat schon recht - Server gehören in das eine VLAN, Clients und Drucker in ein anderes. Wenn man genug Luft hat, auch Drucker und Clients getrennt... Stichwort "Tier Trennung"...

@Nobbyaushb Lokaler Admin ist komplett überbewertet Und in der Tat spricht das geschilderte Szenario nicht wirlich für eine "nicht gewerbliche Nutzung".