Daim
-
Gesamte Inhalte
4.534 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Daim
-
-
Servus,
die downgeloadete Version läuft bei mir erste Sahne.
Allerdings benutze ich die Beta Version von der Connect Seite.
-
Nur der Server meckert jetz immer LSASRV fehler.
Spieglein spieglein an der Wand, welche Fehler-ID wird protokolliert?
Ist das die Event-ID 40960/40961 und kommt der Fehler laufend oder lediglich nach einem Neustart?
Bitte die genauen Fehlermeldungen Source sowie Fehler-ID posten.
-
Servus,
ist das SP2 vom Windows Server 2003 installiert?
Ich höre in letzter Zeit des öfteren von Problemen mit dem SP2 in Bezug auf ARCServe.
Allerdings waren es alles kleiner ARCServe v. 11.5.
-
-
Die Beta die frei zum Downloaden ist.
OK. Die Beta 3 Build 6001 also.
Achso, ich dachte ich müsste das auf der W2k3 CD ausführen..Ne, dass kann ja nicht funktionieren.
Das Active Directory-Preperation Tool (kurz ADPREP) aktualisiert bzw. bereitet das Active Directory-Schema auf die neue Server-Version vor. Das ADPREP von der 2003er CD, aktualisiert das Schema auf die Version des 2003er Servers und somit auf die AD-Version 30, bei R2 auf die Version 31. Das bringt natürlich nichts, wenn du das ADPREP ausführen würdest um den Windows Server 2008 hinzuzufügen.
Also musst du das ADPREP natürlich von der 2008er DVD ausführen, damit das Schema 2008 tauglich aktualisiert wird. Somit wird das Schema auf die Version 40 aktualisiert (Stand: Heute).
Das bedeutet, führe das ADPREP von der 2008er DVD mit dem Schalter /FORESTPREP auf dem 2003er Schema-Master aus. Danach musst du aber noch das ADPREP mit dem Schalter /DOMAINPREP auf dem Infrastruktur-Master der Domäne, in der du den 2008er DC hinzufügen möchtest ausführen. Besser wäre es aber, wenn du direkt ADPREP mit dem Parameter /DOMAINPREP /GPPREP ausführst. Somit würden direkt Berechtigungen bzgl. GPOs gleich richtig gesetzt werden.
auf der 2008 DVD ist das mit dabei?Yepp. Im Verzeichnis <CD-Laufwerk>:\Sources\Adprep>
-
Servus
Allerdings erhalte ich einen Fehler das ich doch bitte "adprep /forestPrep" auf dem DC ausführen soll. Das habe ich getan, aber es klappt immer noch nicht.du hast das ADPREP von der 2008er DVD auf dem Schema-Master deines 2000/2003er DCs ausgeführt?
Welche BETA Version nutzt du?
-
Ist das Dateireplikations-Protokoll nun sauber oder erscheinen dort immer noch regelmäßig Fehler? Du kannst auch zum TEst den NTFRS Dienst stoppen und neu starten. Gehe dazu in die Kommandozeile und führe folgendes aus "net stop ntfrs && net start ntfrs". Kontrolliere danach das Dateireplikations-Protokoll ob Fehler auftauchen.
Hast du geprüft (evtl. mit dem Tool Junction Link Magic) ob die Junction Points tatsächlich existieren? Gehe auch die weiterführenden Artikel in dem Link den ich gepostet habe nach. Die Junction Ponts müssen alle korrekt existieren.
-
Servus,
fangen wir mal Step-by-Step an.
Der Fehler 13568 ist einer der beseitigt werden muss.
Die Fehler 13508+13509 sind Folge-Fehler dessen. Wenn also der Fehler 13568 behoben ist, lösen sich die beiden anderen von alleine.
Für den Fehler 13568 lies dir diesen Artikel durch:
Yusuf`s Directory - Blog - Dateireplikationsfehler mit der ID 13568
Für den Fehler 53258 führe diesen Artikel durch:
-
Servus,
oder nur keine 2000 DCs in der Gesamtstruktur?genau so sieht es aus ;).
Den Domänenfunktionsmodus bzw. Gesamtstrukturfunktionsmodus kann man während dem Betrieb umstellen. Es sind quasi "drei Klicks" und die Domäne bzw- Gesamtstruktur ist umgestellt. Es ist eben darauf zu achten, dass damit, je nach Ebene, älterere DCs nicht mehr existieren dürfen/können.
In einen anderen Domänenmodus kann man nur dann wechseln, wenn alle bestehenden DCs die neue Ebene unterstützen. Bedeutet, möchte man in den Domänenfunktionsmodus "Windows Server 2003", dann dürfen weder NT-BDCs noch 2000 DCs mehr in der Domäne existieren, da ansonsten das heraufstufen nicht möglich ist.
Das gleiche gilt für die Gesamtstruktur. Möchte man die Gesamtstruktur auf den Gesamtstrukturfunktionsmodus "Windows Server 2003" heraufstufen, müssen vorher alle bestehenden Domänen in dem Domänenfunktionsmodus "Windows Server 2003" sein.
Bestehende Vertrauensstellungen sind davon nicht betroffen bzw. haben mit dieser Umstellung kein Problem und funktionieren weiterhin.
Falls mehrere Domänen in einer Gesamtstruktur existieren, dann sollte die Umstellung der einzelnen Domänen respektive Gesamtstruktur "zügig" vollzogen werden. Denn wenn man sich dabei Zeit lässt, können Replikationsprobleme auftauchen.
Das Herauf stufen des Domänenfunktionsmodus kann entweder über das Snap-In „Active Directory-Benutzer und –Computer“ oder „Active Directory-Domänen und -Vertrauensstellungen“ erledigt werden (mit einem Rechtsklick auf den FQDN), wobei die Gesamtstruktur ausschließlich im Snap-In „Active Directory-Domänen und -Vertrauensstellung“ heraufgestuft werden kann. Beides lässt sich ebenfalls durch bearbeiten (mit LDP.exe oder ADSIEdit.msc) des Attributs msDS-Behavior-Version herauf stufen.
Siehe auch:
How to raise domain and forest functional levels in Windows Server 2003
http://support.microsoft.com/kb/322692/en-us
Fazit: Der Modus beeinträchtigt weder die Clients, noch die Memberserver!
-
Servus,
versuche dein Glück mal im Skript-Center:
http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx?mfr=true
-
Du bist ja sowas wie eine wandelnde KB :D den Eindruck bekommt man nach einem Blick in Dein Blog
Das fasse ich als Kompliment auf :p und bedanke mich recht herzlich :cool: .
-
Servus,
Doch dann hat man verloren:yepp. Da hatte ich kurzzeitig an diesem Tag zu verquer gedacht.
Danke für den Hinweis.
Der Artikel (bzw. alle AD-Artikel) sind mir sehr wohl bekannt ;).
-
Hallo AD-Freunde,
Microsoft hat ein AD-Komponenten sowie Feature Poster basierend auf Windows Server 2008 veröffentlicht.
Das AD-Poster für Windows Server 2003 war schon Klasse, aber das für Windows Server 2008 ist einfach brilliant.
Seht selbst:
Yusuf`s Directory - Blog - Active Directory Komponenten Poster
-
-
Du musst aber noch die Frage mit dem Bundeskanzler beantworten :p .
Mein Tipp: Ihr solltet dazu einen externen Dienstleister zuziehen.
Man kann aus jeder NL eine Sub-Domäne kreieren oder aber, was ich persönlich bessen finde, dass Ein-Domänen Modell wählen. Dazu muss aber die Situation bewertet werden, dass man so in einem Forum nicht durchführen kann. Daher ein externer Dienstleister.
Die Struktur Frage ist elementar.
Der Nachteil bei mehreren Domänen wären z.B.:
- Bei mehreren Domänen ist der adminstrative Aufwand (Updates,Virenscanner usw.) höher, da auch jede Domäne zwei DCs haben sollte.
- Dadurch entstehen hohe Hardware- sowie Lizenzkosten.
- Jeder DC sollte/muss vor Ort physikalisch geschützt sein.
- Jede Domäne muss gesichert werden (Backup).
Bei mehreren Domänen wären die Vorteile, wenn man z.B. unterschiedliche DNS-Namensräume haben möchte. Oder unterschiedliche Administratoren sollen "nur" ihre eigene Domäne verwalten und nur dort der Admin sein. Mit mehreren Domänen kann man unterschiedliche Kennwortrichtlinien anwenden.
Der Vorteil einer Domäne wäre z.B. das man nur eine DNS-Zone/Domäne verwalten muss. Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration.
Solche Fragen sollte man eben mit einem erfahrenen Systemhaus klären.
-
kann eben vorkommen jetzt hatte ich denn Fall und der Backup war 62 Tage alt...
OK, aber du wirst selbst zugeben, dass das eher ein seltener Fall ist.
GlaubeDu weißt wer glaubt? Richtig, der Pfarrer :p .
wir reden schon wieder aneinander vorbei. Ich meinte bei mir wurde der Wert durch die SP2 Installation nicht auf 180 gesetzt sondern blieb bei 60 Tagen.Ich denke, du liest die Antworten die man dir gibt nicht richtig.
Lies meine Antwort im Post #7 durch bzw. meine unten stehende Erklärung mit "meiner Theorie".
Ist dieser Fall, als du vom Backup das Objekt rückgesichert hast, auch nach der Installation des SP2 aufgetreten?
Falls ja, dann stimmt meine eigene Theorie und diese Artikel The default tombstone lifetime (TSL) value remains at 60 days instead of increasing to 180 days in Windows Server 2003 R2 ist eher verwirrend.
Bisher galt eben bezgl. der Tombstone-Lifetime die Devise, dass der Wert anhand des ERSTEN Domänencontrollers in einer NEUEN Gesamtstruktur festgelegt wird. Der allererste DC ist entscheidend. Welche Server-Version mit welchem SP ist auf dem Server installiert, BEVOR dieser zum DC gestuft wurde. Die TSL kann nicht pro Domäne vergeben werden, sondern, diese wird einmalig mit dem erstellen des ersten DCs einer Gesamtstruktur festgelegt.
Die TSL kann natürlich jederzeit von Hand geändert werden.
Meine Theorie: Da also nach dem installieren des SP2 dir der Fehler mit der TSL immer noch angezeigt wird, würde das bedeuten, man installiert den ERSTEN DC mit BEIDEN R2-CDs und installiert anschließend das SP2. Erst danach würde der Wert von TSL 180 Tage betragen.
Im Attribut selbst hingegen, würde aber weiterhin <Not Set> stehen, was leider verwirrend ist, da man genau wissen und merken muss, mit welcher Version der allererste DC erstellt wurde.
Ich versuche mal intern bei Microsoft das mit dem Artikel bezgl. SP2 zu klären.
Sobald ich eine Info habe, werde ich es hier verkünden.
-
Servus,
das bedeutet, du migrierst von NT auf Windows Server 2003?
Soll die NT-Domäne aktualisiert oder eine neue AD-Gesamtstruktur aufgebaut werden?
Welche Anbindung besteht zwischen den Niederlassungen?
Wer war der erste Bundeskanzler und wer hat ihn gewählt?
Wieviele Mitarbeiter arbeiten in den jeweiligen NLs?
Für den Einstieg im Thema AD sind diese Artikel sehr hilfreich:
Windows Server 2003 – Schritt-für-Schritt-Anleitungen für das Active Directory
Windows Server 2003 Active Directory-Betriebshandbuch: Inhaltsverzeichnis
-
Dann sollte euch - wie lefg es bereits erwähnte - die Vertragsgrundlage klar sein.
Lasst euch die bestehenden Verträge, die mit dem alten Dienstleister bestehen zur Durchsicht geben, um bei den Verhandlungen die besten Karten zu haben.
Das ganze neu aufbauen, kann man jederzeit. Das ist lediglich Fleißarbeit ;).
-
ich bin mir da ehrlich gesagt nicht sicher in wie weit der dienstleister dazu verpflichtet ist die ad daten rauszugeben ... vor allem in welcher form ... ich könnte mir vorstellen, dass er nur dazu verpflichtet ist, uns die daten mitzuteilen ... aber die könnte man ja auch auf nem blatt papier ausgedrucken :D ...
Da bin ich mir aber 100% sicher!
Wem gehört das Netz bzw. die Domäne? Dem Kunden oder dem Dienstleister?
Der Dienstleister wartet lediglich das Netz/die Domäne/die Hardware und der Kunde gibt ihm die benötigten Informationen (Admin-Kennwort) damit der Dienstleister seine Arbeit durchführen kann. Ende der Durchsage.
gibt es nen ne notfalllösung mit der man das ad auf der einen seite exportiert und dann aus der anderen wieder importiert ohne das man eine direkte verbindung zwischen den beiden domänen hat? schön wär halt wenn ich dem dienstleister sagen könnte exportier die ad struktur mit dem tool und schick sie mir zu damit ich sie auf meiner seite wieder importiere.Nein, so etwas gibt es nicht. Du hast eine Migration vor dir worin auch Exchange und Citrix involviert ist. Du kannst eben mit CSVDE oder LDIFDE die Benutzer exportieren und erneut importieren. Was passiert aber mit den Computerkonten bzw. Benutzerprofilen?
Du müsstest in jedemfall jeden Client anfassen, wenn du dann möchtest... viel Spass.
Daher kann ich es nur abermals wiederholen ---> ADMT und wenn es sein muss, mit dem Rechtsanwalt.
-
Servus,
achte darauf, dass in der Root-Domäne firma.local eine Sub-Domäne _msdcs.firma.local existiert. Diese Zone sollte in der Gesamtstruktur repliziert werden. In der Forward Lookup Zone (FLZ) firma.local sollte weiterhin ein silbriger Ordner _msdcs, also die Delegierung für die Zone _msdcs.firma.local existieren. I n den Eigenschaften des DNS-Servers der Root-Domäne trägst du einen Forwarder entweder auf den Router, besser aber auf den DNS-Server deines ISPs ein. Somit hast du schon mal eine saubere Ausgangsbasis.
Nun erstellst du deine erste Sub-Domäne nl1.firma.local. In den TCP/IP-Einstellungen des Servers trägst du einen DNS-Server aus der Root-Domäne ein. Nach dem heraufstufen wartest du die Replikation ab und erst wenn diese stattgefunden hat, kannst du die DNS-Server Einstellung in den TCP/IP-Settings ändern. Ich würde aber alle DCs auf einen DNS zeigen lassen und den DC selbst, als zweiten DNS-Server eintragen.
Yusuf`s Directory - Blog - Welcher DNS-Server sollte eingetragen werden ?
Wenn nun die Replikation stattgefunden hat, richtest du in der Root-Domäne, im DNS, eine Delegierung für den Ordner nl1 unterhalb deiner FLZ ein. Somit wird auch dieser Ordner silbrig. In den Eigenschaften des DNS von nl1 trägst du ebenfalls einen Forwarder (z.B. DNS-Server des ISPs) ein. Des Weiteren richte auf dem DNS von nl1 eine bedingte Weiterleitung auf die Root-Domäne firma.local ein.
So machst du das für jede Sub-Domäne.
-
Servus,
wie wurde denn das System ursprünglich installiert (händisch, geimaget oder geclonet)?
Du kannst mit dem Parameter /checkupgradeonly prüfen, ob bei einer Migration etwas bemängelt wird.
-
- Server 2003 Standard, Server 2003 Enterprise, Gemischter Modus
Warum wechselt ihr nicht in den Domänenfunktionsmodus bzw. Gesamtstrukturfunktionsmodus Windows Server 2003, um gerade von den Vorteilen die dieser Modus bezgl. der AD-Replikation bietet, profitieren könnt?
How to raise domain and forest functional levels in Windows Server 2003
- ein paar DC's je Standort, viele StandorteExistieren denn auch Standorte im Sinne des AD?
Bestehen im Snap-In "Active Directory-Standorte und -Dienste" Standorte (gelbe Icons) und wurden den Standorte die entsprechenden Subnetze zugewiesen?
Ein Standort kann mehr als eine Domäne enthalten und eine einzige Domäne kann sich über mehrere Standorte erstecken. Jedem Standort sollte auch das entsprechende Subnetz zugeordnet werden. Wenn du mehrere Standorte einrichtest, kann sich der Client am nächstliegenden Domänencontroller authentifizieren.
Der dritte Standort ist am Entstehen, wo auch das Problem auftrat, dass beim zweiten DC beim Eingliedern in die untergeordnete Domain keine NTDS Settings auf den Root Servern eingetragen wurden. Deswegen die erste Frage, ob es begrenzt sei.Du schreibst "zweiten DC". Existiert also bereits ein erster DC in der neuen Sub-Domäne?
Sehen auf diesem die AD-Einstellungen korrekt aus?
Ist das DNS auf den DCs installiert? Steht in den TCP/IP-Settings ein bestehender DNS-Server (z.B. ein DC/DNS aus der Root) drin?
Hängt dazwischen eine Firewall? Falls ja, kontrolliere ob die benötigten Ports offen sind:
Yusuf`s Directory - Blog - Active Directory Replikation durch eine Firewall
-
das mache ich ja schon, nur wenn die Systemstate Sicherung älter ist wie 60 Tage kann ich von ihr auch kein Restore mehr machen... also doch verloren wie ich oben meinte.
Wie oft kommt das denn bei dir vor, dass du ein Objekt nach der TSL (sei es nun mit 60 oder 180 Tagen) wiederherstellen musst?
du sprichst hier aber nur vom Installationsmedium Win 2003 R2 mit SP2 um erneute Verwirrungen vorzubeugen :).Nein. Ich spreche von den CDs Windows Server 2003 R2, worin das SP1 integriert ist (slipstreamed) und NICHT das SP2.
Eine Installation von SP2 veränderte bei mir die 60 Tage nichtUnd wie hast du das verifiziert? Jetzt sag nicht weil im Attribut <Not Set> steht ...
-
und das restore geht dann auch wenn der Systemstate älter ist als der Tombstone?
Nein, natürlich nicht. Das hatte ich auch nicht geschrieben.
Man sollte selbsterklärend regelmäßig eine System State Sicherung tätigen und diese in den Backup-Plan mit aufnehmen.
Noch etwas: ich habe direkt von der Win 2003 R2 CD1 installiert und gleich im Anschluß die CD2 installeirt und erst dann meine Domäne erstellt.Somit beträgt die TSL 60 Tage.
CD2 besitzt keinen Tombstone schema.ini Eintrag.Eben und genau das ist ein Fehler der mit SP2 behoben wurde.
Aber laut meinen Tests besitzen meine Server eine Grabsteinzeit von 60... werde ihn von Hand auf 180 eintragen...Das stimmt ja auch. Du hättest nur die erste CD installieren dürfen und dann den Server zum DC heraufstufen. Somit hätte die TSL 180 Tage, ansonsten 60 Tage.
Aber das steht soch alles in dem von mir bereits verlinkten Artikel (liest das etwa keiner?).
Windows Server 2000 Migration - Empfehlung, Tipps, Erfahrung
in Windows Server Forum
Geschrieben
Servus,
Du musst im ersten Schritt das Schema aktualisieren bzw. auf Windows Server 2003 vorbereiten. Dazu führst du das Tool ADPREP von der Windows Server 2003 CD aus. Falls die neue Maschine ein Windows Server 2003 --> R2 <-- sein sollte, beachte bitte, dass du das ADPREP von der zweiten R2 CD verwendest. Denn das ADPREP bei R2 befindet sich auf beiden CDs.
Du führst das ADPREP mit dem Schalter /FORESTPREP auf deinem 2000er Schema-Master aus. Anschließend führst du ADPREP mit dem Schalter /DOMAINPREP auf dem Infrastruktur-Master in der Domäne aus, in der du den Windows Server 2003 hinzufügen möchtest.
In den TCP/IP-Einstellungen des Windows Server 2003 trägst du einen bestehenden 2000er DC/DNS-Server ein. Erst wenn nach dem promoten (heraufstufen) die Replikation stattgefunden hat, kannst du die DNS-Einstellung verändern. Beachte bitte diesen Artikel:
Yusuf`s Directory - Blog - Welcher DNS-Server sollte eingetragen werden ?
Deine Forward Lookup Zone sollte idealerweise AD-integriert gespeichert sein.
Danach kannst bzw. solltest du die FSMO-Rollen auf den 2003er DC verschieben sowie auf diesem den globalen Katalog aktivieren.
Lies dir dazu diese Artikel durch:
Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben
Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC)
Was du sonst noch alles machen musst bzw. beachten solltest, erfährst du von diesem Artikel:
Yusuf`s Directory - Blog - Den ersten/einzigsten Domänencontroller austauschen
Wenn du den 2000er DC worauf Exchange läuft aktualisieren wolltest, dann muss zuerst Exchange 2000 auf Exchange 2003 upgedatet werden. Denn Exchange 2003 läuft unter Windows Server 2000 aber nicht umgekehrt (Exchange 2000 auf Windows Server 2003), dass geht nicht. Daher _muß_ zuerst ein Exchange Update gemacht werden und dann das Betriebssystemupdate von Windows Server 2000 auf Windows Server 2003.
Was 64Bit anbetrifft:
Man kann Auf einem 64-Bit DC mehr Benutzer pro DC zulassen. Das ist in großen Netzen mit vielen Benutzern pro Standort durchaus sinnvoll. Auch bei intensiver Exchange-Nutzung wäre dieser Schritt sinnvoll. Zumal bei Exchange 2007 64Bit zwingend wäre.
Was die Hardware anbetrifft, ist die Hardware seit den ca. letzten 3-4 Jahren 64Bit tauglich. Mit der 64Bit Version kann man mehr RAM einbauen. Das könnte man aber auch bei der 32Bit Enterprise Version.
http://www.microsoft.com/downloads/details.aspx?FamilyID=52e7c3bd-570a-475c-96e0-316dc821e3e7&DisplayLang=en