daabm

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

Hm - eigentlich gibt es selten so ausführliche Fehlermeldungen. Ist doch schön, wenn da komplett im Klartext steht, was das Problem ist

"Für die nächsten Patchdays" ist gut... Symantec hat heute vormittag Pattern-Updates für bekannte Exploits ausgeliefert, der Workaround geht morgen bei uns in die Fläche (heute pilotiert...).

Geraten: Die Sandbox läuft mit nem technischen Account, und Du hast die Benutzerrechte modifiziert (seServiceLogonRight oder seDenyServiceLogonRight). Der Rest sollte dann in den diversen Eventlogs zu finden sein, zuvorderst Security.

Such mal nach "ncsi.txt" - das ist so ein Dummy-File, das zur Erkennung von "Internet" heruntergeladen wird. Ich müßte selber auch wieder danach suchen... Und für O365 fällt mir EnableActiveProbing = 0 ein, aber auch da mußt dann noch dazu recherchieren. Ist halt beides "aus der Erinnerung", konkret liegt's im Büro rum.

Olaf, es gibt viel zu viel Code, der viel zu oft läuft und viel zu viele Daten abruft. AD dürfte eines der häufigsten Opfer sein, SQL kommt vermutlich kurz danach oder davor... "Egal" gibt es bei gutem Coding nicht. Get it right in the first place... Warum ich da so hinterher bin? Weil ich schon zu viele unheimliche Begegnungen der dritten Art mit den Auswirkungen von schlechtem Skripting hatte. Und das hatte mit dem Sizing der Infrastruktur nichts zu tun, nur mit der Qualität und Logik der Skripts.

Jo, Exchange ist bei mir halt "out of Scope" - ich wußte nicht mal, daß "mail" ein eigenes Attribut ist, ich dachte bisher immer, daß in "mail" das steht, was in proxyAddresses groß geschrieben ist (was ich schon immer eigenartig fand für die Festlegung der primären Mailadresse...)

Benutzerkontensteuerung: Bei Eingabeaufforderung für erhöhte Rechte zum sicheren Desktop wechseln Benutzerkontensteuerung: UIAccess-Anwendungen das Anfordern erhöhter Rechte ohne Verwendung des sicheren Desktop erlauben. Entweder ersteres deaktivieren oder zweiteres aktivieren, dann klappts mit dem Nachbarn