Daim

Servus, und genau damit erreichst du das, was du möchtest. Die Anleitung von "fluehmann" ist korrekt. Das entscheidende dabei ist die IP-Überbrückung zu deaktivieren, denn dann hält sich die AD-Replikation explizit an deine vorgegebenen Standortverknüpfungen.

Servus, ich wette das es sich um eine VM-Umgebung handelt. Stimmts oder habe ich recht? ;) Dann hast du eine VM kopiert/geclonet um dir Arbeit zu sparen. Bevor eine Vertrauensstellung vom Local Security Authority (LSA) Prozess erstellt wird, prüft dieser die Eindeutigkeit folgender Auflistung: - Den NetBIOS Namen der Domäne - Den Fully Qualified Domain Name (FQDN) der Domäne - Die Security Identifier (SID) der Domäne Diese drei Punkte müssen eindeutig sein, da ansonsten keine Vertrauensstellung zu Stande kommt.

Servus, die 32Bit Standard-Serverversion, egal ob Windows Server 2003-Standard oder Windows Server 2008-Standard kann standardmäßig 4GB RAM verwalten. Nur die 32Bit-Enterprise Version kann max 64GB RAM adressieren. Der Windows Server 2008 Standard in 64Bit kann 64GB RAM adressieren. Der Windows Server 2008 Enterprise in 64Bit kann 2TB RAM adressieren. Siehe: Memory Limits for Windows Releases (Windows)

Servus, vielleicht bist du den folgenden Artikel noch nicht durchgegangen. You cannot delete a file or a folder on an NTFS file system volume

Servus, du öffnest unter "Start - Programme - Verwaltung" das DNS-SnapIn und rufst mit einem Rechtsklick auf die Forward Lookup Zone die Eigenschaften auf. Anschließend klickst du auf den Reiter "Zonenübertragungen". Unter Start-Ausführen rufst du die MMC "domain.msc" auf. Dort klickst du mit einem Rechtsklick auf die Domäne und wählst die Eigenschaften aus. Im Reiter Vertrauensstellungen findest du dann die eingerichteten Vertrauensstellungen. Mit NETDOM das sich in den Windows Support Tools befindet und ab Windows Server 2008 bereits on Bord ist.

Servus, das ist möglich, aber in einem Szenario wo sich noch andere DCs in der Domäne befinden ist diese Vorgehensweise wenn es sich nur um den DC dreht, unnötig. Sofern weitere DCs in der Domäne existieren, ist es einfacher bei einem DC-Crash den gecrashten DC händisch aus dem AD zu entfernen und eine andere Maschine ganz normal als zusätzlichen DC der Domäne hochzustufen. How to move a Windows installation to different hardware 1. Image auf einem DC ist keine gute Idee. LDAP://Yusufs.Directory.Blog/ - Images als Sicherung? 2. Warum möchtest "unbedingt" das System State rücksichern, wo doch noch weitere DCs in der Domäne existieren? Wenn ein DC in einer Aussenstelle crasht oder geklaut wird, entfernst du diesen DC händisch aus dem AD [1] und installierst auf einer anderen/neuen Maschine einen neuen zusätzlichen DC, ohne das System State einer anderen Maschine rückzusichern. Denn bekanntlich wird mit der System State-Sicherung auch die Registry mit gesichert, in der sich die Treiber- und Hardwareinformationen befinden. 3. Den "neuen" DC kannst du dann in der Zentrale mit den IP-Informationen der Zentrale installieren und anschließend die Maschine zur Aussenstelle verschicken. In der Aussenstelle vergibst du dem DC die IP-Informationen der Aussenstelle und verschiebst ggf. den DC in der MMC "Standorte und Dienste" von der Zentrale zur Aussenstelle [2]. Ja, mit NTBACKUP würde das funktionieren. Die genaue und spezielle Vorgehensweise wird im o.g. Artikel erläutert. Aber nochmals, für die reine DC (und DNS) Funktion ist diese Vorgehensweise eher umständlich. Einfach eine neue zusätzliche Maschine, als zusätzlichen DC der bestehenden Domäne hinzufügen. [1] LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen [2] LDAP://Yusufs.Directory.Blog/ - Einen Domnencontroller an einen anderen Standort verschieben

Servus, wie wäre es für den Anfang mit der 70-622. Dann wärst du MCITP - Enterprise Support Technican. Wenn du dann noch Lust hast, kannst du noch die 70-623 machen und wärst zusätzlich MCITP - Consumer Support Technician. Wenn du später dann noch Lust hast und dich an die Server traust, kannst du den MCITP - Server Administrator (ehemals MCSA) anvisieren. Und wenn du groß bist und von Zertifizierungen nicht genug bekommen kannst, machst du den MCITP - Enterprise Administrator. Aber welche Richtung du mit den Zertifizierungen einschlägst, kommt hauptsächlich auf deine Erfahrung an. Denn wenn du später z.B. nur für Exchange zuständig bist, wäre der MCITP - Enterprise Messaging Administrator für dich sicherlich mehr interessant. Oder wenn du mehr mit SQL zu tun hättest, würde der MCITP - Database Administrator in Frage kommen. Microsoft Learning: Microsoft Certified IT Professional (MCITP) Die Zertifizierungen stellen schließlich den --> Nachweis <-- deiner bisherigen praktischen Berufserfahrungen auf "Papier" dar, nicht umgekehrt wie viele es hier vielleicht glauben.

Und genau das ist doch der Punkt. Sie tun es nicht und sparen leider wie so oft, am falschen Ende das Geld. Das hat natürlich für den Kunden auch seine Vorteile. Wenn "etwas" schief läuft, kann er dir in den Hintern treten. ;) DU brauchst die Empfehlung auch nicht auf dich zu beziehen. Du wüsstest ja auch was bei einem DC-Crash zu tun ist. Andere wissen das eben nicht und um genau "diese" geht es mir hier. Jemand der weiß was bei einem DC-Crash zu tun wäre, meldet sich dann auch nicht hier im Board. Bei einer Wiederherstellung müsstest du dich dann aber um eine Technologie weniger kümmern. Der Kunde möchte schließlich "schnell" wieder Geld verdienen. Abgesehen davon nutzen doch nicht alle KMUs Exchange, SQL usw. Andere nutzen evtl. bloß einfache Fileservices und die Daten liegen auch noch auf einer externen HDD (ja, diese KMUs gibt es auch). Ihre wichtigen Rechnungen die sie mit Word erstellt haben und unbedingt an ihre Kunden verschicken möchten. Ja, DU hast es getestet und wußtest was zu tun ist. Nicht jeder weiß das. Und das Thema "Imaging" ist wieder ein anderes. Nochmals, andere tun das nicht. ACK.

Mir ging es nur darum, Edgar den Fehler 13568 mehr zu erläutern und das er eben nicht die Beschreibung durchführt.

Servus Edgar, nur zur Info. Bei dem Fehler 13568 empfiehlt der MS-PSS selbst nicht die Anweisung die in der Beschreibung des Fehlers steht durchzuführen. Stattdessen setzt du auf einem DC auf dem das SYSVOL-Verzeichnis keine Probleme bereitet (SYSVOL ist freigegeben, Junction Points existieren...) den Burflags D4 Schlüssel. Was alles vorher überprüft werden sollte, erfährst du von hier: LDAP://Yusufs.Directory.Blog/ - Dateireplikationsfehler mit der ID 13568

Erneut? Du meinst wohl mit der Empfehlung eines zweiten DCs. Es ist in einem Disaster-Recovery Fall sogar mehr als nur schön. Und natürlich ist es kein "muss", denn die Admins von solchen Umgebungen von denen du redest haben ja bei einem DC-Crash alles im Griff und können mit einem kühlen Kopf in kurzer Zeit die Domäne wiederherstellen. Denn schließlich existiert ja eine aktuelle und vor allem funktionierende System State Sicherung. Oder etwa doch nicht? Oder melden sich einige dieser Admins in genau solch einem Fall hier im Mcseboard und Fragen nach Rat, wie es hier regelmäßig vor kommt? Nein, nicht "eher"! Eher ist es für das Unternehmen von Vorteil. Trotzdem ist ein zweiter DC eher von Vorteil als ein Nachteil, auch wenn es kein "muss" ist. Aber für viele KMUs wäre ein zweiter DC schon ein "muss", denn wie oft erleben wir hier im Board wie ein aufgelöster Admin seinen gecrashten DC retten möchte und schlicht mit der Situation überfordert ist. Ganz genau nämlich. Die Firma begeht ohnehin schon einen Fehler, denn diese Aufgabe ist - ohne dem TO nahe zu treten - nicht für einen Praktikanten geeignet.

Salut, dann installiere die Programme und aktiviere den Kompatibilitätsmodus (Rechtsklick auf die EXE -> Reiter Kompatibilität) für jedes Programm. Dort wählst du dann "Windows Server 2003 (Service Pack 1)" aus.

Servus, ja. Nicht für DHCP. Nein. Du kannst auch AD-Standorte samt Subnetz für physikalische Standorte erstellen, wo sich kein DC vor Ort befindet. AD-Standorte erstellt man unter anderem auch, damit der Client für die Authentifizierung einen DC im DNS ausfindig machen, der "seinem" AD-Standort am nähesten ist. Entscheidend dabei sind die Standortverknüpfungskosten die in der MMC "Standorte und Dienste" konfiguriert wurden. Lies dir den folgenden Artikel dazu durch, dann wird es klarer: LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort

Servus, das kann man auch mit vorherigen Serverversionen konfigurieren: LDAP://Yusufs.Directory.Blog/ - Anmeldungen protokollieren @ricster360 Wenn du die GPO aktivieren würdest, beachte dabei aber die rote Schrift im o.g. Artikel, dann wird die IP-Adresse in der Beschreibung des Eventlogeintrags protokolliert.

Servus, in dem folgenden Artikel geht es auch um Windows Server 2003: LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Die Vorgehensweise ist im Prinzip bei allen Serverversionen gleich.

Ohh... na ob dieses Vorhaben etwas für einen Praktikanten ist...? Standardmäßig hat jeder "Authentifizierte Benutzer", sprich alle Domänen-Benutzer das Leserecht auf das AD. Wenn du dir auf deiner Admin-Workstation das Adminpak installierst, welches du auf einem Windows Server 2003 im Verzeichnis %windir%\system32 findest, dann kannst du z.B. die MMC "AD-Benutzer und -Computer" öffnen und hast das Leserecht auf die Objekte. Das solltest du in jedemfall.

Nein, du lässt nichts weg. Du hast nur wahrscheinlich ein Copy&Paster in den Punkten 6+9 zu viel gemacht. Dort änderst du zwei mal den Schemamaster. ;) Das passt schon. Abgesehen davon werden die FSMO-Rollen auch automatisch während dem herunterstufen des Rolleninhabers auf einen anderen DC verschoben. Das bedeutet, auch wenn du es vergessen würdest eine Rolle händisch zu verschieben, würde die Rolle automatisch während dem herunterstufen des DCs mit DCPROMO verschoben werden. LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen mit DCPROMO verschieben Die Daten kopierst du eben mit den ACLs auf den neuen DC, falls der DC zeitgleich auch ein Fileserver ist. Welche Werkzeuge du dazu verwenden kannst, ist in dem Link in meiner vorherigen Antwort beschrieben. Was die Dienste anbetrifft musst du ja wissen, welche auf dem 2003er DC laufen und wie diese übernehmen werden können. Ggf. setze dich mit den Herstellern in Verbindung. Wie du z.B. DHCP übernehmen kannst, ist ebenfalls in dem Link meiner vorherigen Antwort beschrieben. Uiuiuiii... jetzt wirds ernst. Wie verknüpfen denn die clients ihre Netzlaufwerke? Ändisch oder automatisiert bei der Anmeldung eben mit einem Loginskript, welches sich im NETLOGON-Verzeichnis des DCs befindet.

Servus, ja, die Richtung stimmt schon mal. Ausser das du dich verschrieben hast und zwei mal den Schemamaster ändern möchtest. ;) Du musst natürlich dann noch alle Daten sowie Dienste auf den 2008er DC übertragen und ggf. das Loginskript anpassen. An was du alles denken solltest, beschreibt dir dieser Artikel: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen Aber wie Nils es bereits angesprochen hatte, ein einziger DC in der Domäne ist definitiv ein DC zu wenig.

Ich hatte weder unter Windows Server 2003 diese Probleme, noch unter Windows Server 2008. Funktioniert so wie es sein muss.

Dann verwende doch die "Automated System Recovery- ASR" Sicherung. The Storage Team at Microsoft - File Cabinet Blog : Automated System Recovery (ASR) in Windows Server 2008 and Vista SP1

Primär geht es erst mal um den Domänenfunktionsmodus. Den Gesamtstruktur- sowie Domänenfunktionsmodus kann man erst beim Heraufstufen des allerersten DCs (also beim erstellen einer Gesamtstruktur) ab Windows Server 2008 bestimmen. Genau so sieht es aus [2]. Du müsstest wenn dann ein Forest-Recovery durchfühen (was du nicht möchtest). [2] LDAP://Yusufs.Directory.Blog/ - Den Domänen- und Gesamtstrukturfunktionsmodus zurückstufen

Du kannst dir ruhig den Artikel durchlesen, den ich verlinkt habe. Der beißt auch nicht.

Servus, nein, ist er nicht. Bitte trenne dich von der Begrifflichkeit "PDC und BDC". Seit der Einführung des Active Directory mit Windows 2000 gibt es nur noch DCs. In einer AD-Umgebung hat jeder DC das Schreibrecht, im Gegensatz bei einer NT-Umgebung wo lediglich der PDC das Schreibrecht hatte. Das siehst du falsch. Prinzipiell kannst du einen Windows Server 2003 als zusätzlichen DC einer Windows Server 2008 Domäne hinzufügen. Es kommt dabei aber zwingend auf den Domänenfunktionsmodus [1] an. Wenn dieser auf "Windows Server 2008" sein sollte, dann ist es nicht mehr möglich, einen Windows Server 2003 als zusätzlichen DC zur Domäne hinzuzufügen. Der Domänenfunktionsmodus muss sich auf "Windows 2000 pur", "Windows Server 2003 Interim" oder "Windows Server 2003" befinden, damit der 2003er zum DC heraufgestuft werden kann. [1] LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

Deshalb muss diese Meldung mit der EventID 13516 zwingend im Eventlog protokolliert werden. You are welcome.

Servus, dann überprüfe doch zuerst mit dem Artikel, ob das SYSVOL-Verzeichnis soweit in Ordnung ist und ob z.B. die Junction Points existieren usw. Wenn das alles soweit passt, setzt du auf diesem DC den Burflags D4 Schlüssel. Vorher musst du den NTFRS-Dienst anhalten. Mit diesem Schlüssel wird dieser DC quasi als "Master" für das SYSVOL-Verzeichnis gesetzt. Anschließend startest du den NTFRS-Dienst und kontrollierst ob im Eventlog die ID 13566 und was zwingend erscheinen muss 13516 protokolliert werden.