olc

Da stimme ich mit Dir vollkommen überein - nur war das eben überhaupt nicht Thema dieses Threads. Ich überlese jetzt mal den Unterton. Ja, vollkommen trivial. Wenn der Schema-Master in einem abgetrennten Netz steht oder der Schedule geschlossen ist, ist genau dies der Fall - keine Änderungen werden nach "draußen" repliziert. Genau das war es, was oben mehrfach gesagt wurde. Ich verstehe also das Problem nicht. Er muß nicht mehr verschoben werden, das wurde ja schon vorher erledigt. Also wieder verstehe ich das Problem nicht? Und da ich ein Systemstate Backup habe, welches bei der Rücksicherung neben anderen Komponenten die Registry und die NTDS.DIT + Logfiles zurücksichert (und das auf beiden verschobenen / offline DCs), ist das ganze überhaupt kein Thema mehr. Und selbst wenn das nicht möglich wäre: Dann nehme ich das System im worst case Szenario (Achtung: Ich betone ausdrücklich "worst case") endgültig vom Netz und seize den Schema Master auf einen anderen DC. Durch die Trennung vom "Restnetz" tut das im Normalfall nicht weh. Ok, da gebe ich Dir Recht. Darauf hätte man noch einmal explizit hinweisen können. Ich weiß wieder nicht genau, worauf Du hinaus willst. Ich habe den Artikel natürlich gelesen (langsam werde ich Deinen in den Raum geworfenen, nicht greifbaren Behauptungen bzw. Untertönen überdrüssig), sonst hätte ich ihn nicht verlinkt. Du hast Recht, vom "Rückweg" wird dort nicht gesprochen, aber dafür habe ich ihn auch nicht verlinkt. Er sollte das Thema nur grundsätzlich um einige Aspekte bereichern. Vielleicht hätte ich einen Absatz vor der Verlinkung einfügen sollen. Bitte fasse meine Aussagen nicht als Angriff auf - denn so sind sie nicht gemeint. Aber um gleiches bitte ich Dich ebenso. Der Ton macht die Musik - und natürlich auch auch die Verlinkung auf Quellen, die man bestenfalls als "offiziell" bezeichnen kann. ;) Viele Grüße olc

Hi Nils, wie oben angemerkt wollte ich den Thread hier nicht kapern, aber scheinbar geht es halt nicht anders. :rolleyes: Sei mir nicht sauer, wenn ich solchen Aussagen keinerlei Bedeutung zugestehe. Du sprichst von AD-Experten, gibst jedoch keinerlei Quellen an. BTW: Was sind AD-Experten - ist ein weites Feld, in dem es viele Graustufen und Spezialisierungen gibt. Aber scheinbar haben wir verschiedene Dinge gemeint (siehe unten). Das setzt voraus, daß Du weißt womit ich mich befasse. Das möchte ich bezweifeln und diese Aussage führt in eine vollkommen falsche Richtung, wenn Sie nicht gleich vollkommen obsolet ist. Wer sagt dem Leser, daß Du der "besser qualifizierte AD-Experte" bist? Du sprichst wieder von einem Blog-Artikel, den Du nicht weiter benennst. Ich (und sicherlich auch andere, die diesen Eintrag hier lesen), werden jetzt wahrscheinlich nicht "dieses Board" / das gesamte Board nach irgend einem Blog-Artikel durchsuchen. Oder meintest Du den oben verlinkten Artikel - dann wäre eine andere Wortwahl klasse gewesen. Ja, da stimme ich Dir in zweierlei Hinsicht zu: Wir sprachen scheinbar tatsächlich von unterschiedlichen Dingen. Da Du oben als Zitat die Aussage von Daim direkt beantwortet hast, in der es ganz offensichtlich und ohne jeden Zweifel um die Microsoft-eigenen Schema Erweiterungen mittels ADPREP ging, konnte man von nichts anderem ausgehen als von dem, wovon ich schrieb. Entschuldige wenn ich nachfrage, aber ich habe es scheinbar überlesen (und auch gerade beim nochmaligen Lesen nicht finden können): Wo genau hast Du das eindeutig geschrieben? Fortsetzung folgt...

Hi, ich möchte jetzt hier keinen Flamewar anzetteln, bei dem jeder seine ganz persönliche Meinung zum Thema kund tut - aber trotzdem ein, zwei Zeilen dazu: Du sprichst von "der empfohlene Weg". Wer empfiehlt diesen Weg? Sicher nicht Microsoft. Natürlich kann man a) jede LDIF-Datei einzeln importieren und b) wie von Dir beschriebnen den Import mittels LDIFDE manuell durchführen und Fehler überspringen, um diese danach gegenzuprüfen und zu beheben. Mit ziemlicher Sicherheit ist das jedoch nur erfahrenen "Tiefenkennern" zu empfehlen, nicht dem normalen AD-Admin, auch wenn er sich "recht gut" auskennt. Es mag Szenarien geben wo das Sinn macht, im Normalfall jedoch definitiv nicht. Genau darum hebst Du den Schema-Master ggf. in eine eigene Site mit einem Schedule, der zum Zeitpunkt der Schema-Erweiterung nicht geöffnet ist oder nimmst die beiden angesprochen DCs, also den Schema-Master und einen Replikationspartner, lieber gleich aus dem Netz in einen abgeschotteten Bereich. Schlägt dann etwas fehl, kannst Du die beiden DCs schlichtweg wieder herstellen, ohne dabei einen Forest-Recovery fahren zu müssen. Genau aus diesem Grund ist das genannte Vorgehen das korrekte. Siehe auch Aktives Verzeichnis Blog : Schema Erweiterungen - Riskant oder unkritisch? . Viele Grüße olc

Hi, da hast Du Recht - in jedem Fall ist der Applikationshersteller gefragt. Nur leider sind selbst die "Big Player" teilweise nicht in der Lage Ihre Applikationen entsprechend anzupassen. Wie gesagt: ADAM macht in diesem Zusammenhang wohl eher weniger Sinn. Wahrscheinlich läuft es (wenn der Applikationshersteller da nicht nachpflegen kann) auf einen NLB oder aber DNS Round Robin hinaus. Viele Grüße olc

Hi, das Verhalten ist im Grunde nicht die Lösung, sondern ein Provisorium. Das Problem ist das DNS Design, da kann auch kein (kurzfistiger) Hotfix helfen. Anbei eine kurze Erläuterung, warum das Öffnen weiterer UDP Ports das Problem entschärft: Viele Grüße olc

Hi, ADAM + NLB bringt Dir im Grunde ja keine Verbesserung im Vergleich zu AD / DCs + NLB. Da Du in jedem Fall die Last verteilst, ist es egal ob dahinter ADAM Instanzen oder DCs stehen. Im Gegenteil, Du verkomplizierst die Umgebung dadurch nur noch. Kerberos etc. kann ADAM nicht, es ist ein reiner Verzeichnisdienst ohne Zusatzfunktionen. Du müßtest die Kerberos-Anfragen also so oder so an einen DC / KDC weiterleiten. Ich will damit nicht sagen, daß ADAM keinen Sinn macht. Nur in dieser Konstellation sehe ich keine Vorteile. Viele Grüße olc

Hi Maria, sieht so aus, als ob dort ein Konflikt zwischen beiden Ordnern aufgetreten ist und der eine daher als "Verlierer" umbenannt wurde, siehe: Ggf. solltest Du einmal prüfen, ob Du die Inhalte ohne Datenverluste wieder auf dem derzeit noch korrekten System wieder zusammenfügen kannst (manuell), um dann den "fehlerhaften" Replikationsordner wieder neu der FRS Replikationsgruppe hinzuzufügen. Bin mir nicht sicher, ob es einen einfacheren Weg dafür gibt. FRS ist schon so lange her... ;) Viele Grüße olc

Hi, <sarkasmus> Na ja, soll schon vorkommen, daß eine DNS Abfrage nicht möglich ist, wenn etwas mit dem TCP/IP Stack nicht in Ordnung ist. Zieh doch mal einen Netzwerktrace. :D </sarkasmus>. ;) Viele Grüße olc

...und nebenbei erfinden wir hier noch schnell das Perpetuum Mobile und bekommen dafür den Nobelpreis und eine ganze Menge Kohle. Ach ja - und den Zorn der "Stromerzeuger" bzw. "Energieerzeuger". :jau: Gruß olc

Hi, ich muß zu meiner Schande gestehen, daß der Hinweis mit den SPNs falsch war. Kerberos zwischen getrusteten Forests geht erst ab Forest Modus Windows Server 2003, wenn ich mich nicht irre. Ich bin nicht so der Trust-Experte, also bitte vergebt mir. ;) Es ist schon merkwürdig, daß Du über den FQDN auf die Maschine kommst, jedoch mittels Hostnamen nicht. Das verwundert doch sehr, zumal Du den Hostnamen pingen kannst (und hoffentlich auch die korrekte IP-Adresse zurück bekommst)? Sah für mich erst einmal nach einem Kerberos Problem aus, was jedoch nicht sein kann (siehe oben). Vielleicht kannst Du von beiden Zugriffsversuchen einmal einen Netzwerktrace ziehen (also Gut- und Schlechtfall, sprich Zugriff über FQDN und Zugriff über Hostnamen) und gegenprüfen, was unterschiedlich ist. Vielleicht kommt man damit weiter. Viele Grüße olc

Hi, Daß auf dem W2K3 Server die benötigten SPNs für den W2K Server (ohne DNS Suffix) nicht aufgelöst werden können (dies jedoch auf dem W2K Server funktioniert), ist der Grund für die Probleme (ok, soweit waren wir schon). Kannst Du den Server srv_l7test aus der 2003er Domäne pingen (nicht den FQDN, sondern den Hostnamen)? Gruß olc

Hallo nochmal, Das hatte ich vorhin überlesen. Das heißt, daß der Zugriff auf die Dateiserver über die Angabe des FQDN klappt? Was sagt ein "setspn -L srv_2test" und ein "setspn -L srv_7test", ausgeführt jeweils auf dem 2000 Server und auf einem der 2003er Systeme? ITHome hat vollkommen Recht - unter Umständen sind die WINS Einträge schlichtweg nicht korrekt und daher kein Mapping auf die SPNs möglich. Viele Grüße olc

Hallo Ralf, nein, das kannst Du nicht anstoßen. Hintergrund ist, daß diese Dateien durch den Zugriff gesperrt sind (sogenanntes "locking") und erst wieder repliziert werden können, wenn die Sperrung aufgehoben ist. Das ist der Sinn einer Sperrung. ;) Du kannst Dir über die Sessions der Freigaben jedoch anzeigen lassen, wer ggf. über das Netzwerk darauf zugreift und denjenigen bitten, die Datei zu schließen. Dann wird die Datei nach einiger Zeit wieder repliziert. Viele Grüße olc

Hi, läuft in der Windows Server 2003 Domäne die Replikation korrekt? Wie viele DCs stehen in der 2003er Domäne? Hast Du im Eventlog der 2003er DCs eventuell Meldungen zu Replikationsproblemen? Viele Grüße olc

Off-Topic: Sorry Leute - ich weiß man will hier keine Klugsch*** hören: Aber wurde nie zuvor einen Rücksicherungstest gemacht? Es erschrickt einen doch immer wieder, daß so etwas scheinbar nicht vor dem Fehlerfall durchgeführt wird und man dann erst im Notfall feststellt, daß der geniale Agent das nicht packt. Was übrigens echt eine Glanzleistung ist. :D

Hi, ergänzend zu ITHomes Link noch der folgende: Ask the Directory Services Team : Automatic creation of user folders for home, roaming profile and redirected folders. Ist meines Erachtens recht einsteigerfreundlich. :) Viele Grüße olc

Hi, erster Treffer bei Google: Error Message Occurs When You Create a Distributed File System Root Viele Grüße olc

Hi, ich denke nicht, daß Du per PowerShell ein LDAP-Objekt ohne eine Verbindung zum ADSI-Provider abrufen kannst. Daher die Frage: Wie genau sieht denn Dein Script aus? Entweder Du stellst die Verbindung manuell her oder Du nutzt beispielsweise die PowerShell AddOns von Quest, bei denen ein "Get-QADPermission" CMDlet existiert, welches das ganze stark vereinfacht. Siehe PowerShell Commands for Active Directory by Quest Software . Viele Grüße olc

Hi, Das ist korrekt. Sind die Berechtigungen auf den Namespace denn korrekt vergeben? Wenn Du eine "Zugriff verweigert" / "Access denied" Fehlermeldung bekommst, sollte vorher ein Authentifizierungsdialog geöffnet worden sein. Es sei denn, Benutzername des zugreifenden Benutzers außerhalb der Domäne ist gleich dem Benutzernamen eines nicht berechtigen Domänenbenutzers bei unterschiedlichem Kennwort. Wenn Du die Verbindung über "Netzlaufwerk verbinden" im Explorer herstellst und die korrekten Benutzerdaten eines Domänenaccounts übergibst - kommst Du dann auf den Namespace? P.S.: Ein freundliches "Hallo" oder "Vielen Dank" ist nicht nur ein Frage der Erziehung, es wirkt auch ab und an Wunder wenn es darum geht, Menschen dazu zu bewegen, einem weiter zu helfen. :) Viele Grüße olc

Hi Johannes, es gibt sicherlich eine Menge Möglichkeiten dafür. Eine davon ist diese hier: dir /A:-D ABC* /S /B \\rechner\test > C:\gefunden.txt P.S.: Mit FIND kann man schon eine Menge machen. :) Vielleicht schaust Du Dir ja auch einmal die PowerShell an, diese ist "zukunftsfähig" und bietet Dir eine Menge guter Möglichkeiten zur Weiterverarbeitung der generierten Daten. Viele Grüße olc

Hi Cat, so wie ich das bisher gesehen habe, bekommt man die Oberfläche unter Windows nicht so stark verändert, wie man es bräuchte, um so einen "Style" hinzubiegen. Werden die gepatchten DLLs bei Windows Updates wieder ausgetauscht? Sicherlich ja oder? Grundsätzlich ist es außerdem so, wie Du sagtest: Es ist in jedem Fall minder vertrauenswürdig, solche Quellen anzuzapfen. Aber interessieren würde mich das auch. :D Viele Grüße olc

Hi Maxif, coole Frage, habe ich in der Form auch noch nirgendwo gelesen. :D Mir bekannt gibt es keine solchen "Styles" für XP oder Vista. Zwar gibt es einige Anpassungen, aber damit bekommst Du es nicht so weit hin, wie mit anderen Systemen. Du müßtest eher auf Linux gehen, dort gibt es diverse Fenstermanager, mit denen Du allerhand anstellen kannst. Schau mal auf folgende beiden Seiten, da gibt es einen "Vorgeschmack" auf das, was unter Linux möglich ist (siehe "Themens / Sytles"). ;) Eyecandy for your KDE-Desktop - KDE-Look.org Eyecandy for your GNOME-Desktop - GNOME-Look.org Viele Grüße olc

Hallo pep, Deinem Text nach gehe ich davon aus, daß Du Windows Server 2003 R2 mit DFS-R nutzt? Was genau meinst Du mit "Sicherheitsdefinition"? Man muß hier zwischen den NTFS und Freigabeberechtigungen unterscheiden: NTFS Berechtigungen werden über DFS-R repliziert, die Freigabeberechtigungen mußt Du manuell setzen. Hierbei handelt es sich um die Berechtigung, den Namespace als solches zu verwalten. Dies werden im Normalfall nur Administratoren oder delegierte Benutzer tun sollen. Darüber hinaus gibt es jedoch auch noch die Berechtigungen auf den Namespace selbst für zugreifende Benutzer. Hier empfiehlt sich jedoch meist nicht, die Rechte auf dieser Ebene einzugrenzen. Es macht eher Sinn, über die Freigaben der Ziele bzw. den darunter liegenden NTFS Berechtigungen die Zugriffe zu regeln. Dies kann man jedoch nur im konkreten Fall betrachten. Grundsätzlich erst einmal ja. Dazu müssen zwei Bedingungen erfüllt sein: 1. Der Client muß einen DFS-Client mitbringen. Wenn Du von Windows Clients sprichst, sollte dies normalerweise der Fall sein. 2. Du mußt ggf. die Credentials des Benutzer beim Zugriff auf den Namespace / das Share eingeben. Hier brauchst Du dann einen Benutzer, der die entsprechenden Rechte mitbringt. Viele Grüße olc

Hi, Ich kann mir ehrlich gesagt nicht vorstellen, daß es an Virtual PC liegt. Wer weiß, was da während der Installation schief gelaufen ist... Das ist nur die DC GUID bzw. der dazugehörige CNAME. Es müssen unterhalb der _msdcs-Zone (z.B. in den sites, unterhalb der dc Bereiche etc.) die LDAP, KERBEROS und LDAP SRV Einträge korrekt registriert sein, sonst geht nichts in der Umgebung. Ok, also zumindest gestartet. Wie vermutet, die notwendigen Shares sind nicht vorhanden. Du kannst diese jedoch nicht einfach so freigeben, das würde a) das Problem nicht beheben und b) nicht den gewünschten Effekt bringen. Soll heißen Anmeldungen / Domain-Joins wären weiterhin nicht möglich. Du mußt das zugrunde liegende Problem lösen. Ok, dann lohnt im Moment auch kein weitreres "nachforschen". :) Viele Grüße olc

Hi, da der DC scheinbar über DNS aufgelöst werden kann (siehe nslookup als auch die Auflösung des DCs über die _msdcs-Zone), würde ich eher nicht auf DNS tippen. Es sei denn, es wurde nur ein Teil der Einträge durch den NETLOGON Dienst registriert (was nicht auszuschließen ist, siehe unten). Dann wäre DNS jedoch eher das "Opfer". Sind in der _msdcs-Zone LDAP, KERBEROS und GC Einträge für den DC vorhanden? Schaut man in Dein DCDIAG, findet man folgende Fehler: Starting test: NetLogons Unable to connect to the NETLOGON share! (\\HENRY\netlogon) [HENRY] An net use or LsaPolicy operation failed with error 1203, Der angegebene Netzwerkpfad wurde von keinem Netzwerkdienstanbieter angenommen.. ......................... HENRY failed test NetLogons und Starting test: FsmoCheck Warning: DcGetDcName(GC_SERVER_REQUIRED) call failed, error 1355 A Global Catalog Server could not be located - All GC's are down. Warning: DcGetDcName(TIME_SERVER) call failed, error 1355 A Time Server could not be located. The server holding the PDC role is down. Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, error 1355 A Good Time Server could not be located. Warning: DcGetDcName(KDC_REQUIRED) call failed, error 1355 A KDC could not be located - All the KDCs are down. ......................... mydomain.local failed test FsmoCheck Letztere Fehler könnten eine Folge des NETLOGON Problems sein. Vermute ich richtig wenn ich sage, daß der NETLOGON Dienst auf dem DC derzeit nicht gestartet ist (wie auch der KDC Dienst etc.)? Vielleicht kannst Du einmal das Verzeichnisdienst- als auch das Applikations- und System Event Log überprüfen, welche Fehler konkret geloggt werden (inkl. Event IDs und komplette Ereignistexte). Vielleicht bekommt man aus diesen heraus, wo das Problem liegt. Sicherlich wirst Du mindestens 1030 / 1058 Fehler finden, da das SYSVOL nicht geshared ist. Viele Grüße olc