Daim

Hola, ich ergänze auch mal. ;) Da ab Windows 2000 jeder Client standardmäßig alle 30 Tage sein Computerkontokennwort ändert, kannst du genau an dieser Stelle ansetzen. Du erstellst z.B. eine Abfrage und ermittelst, welche Clients ihr Kennwort größer 30 Tage nicht geändert haben. Man muss natürlich vorsichtig sein, wenn Clients längerfristig nicht im Netzwerk sind (z.B. Baustellen-PCs). How to detect and remove inactive machine accounts

Servus, z.B. mit Dsquery: Dsquery * domainroot -filter (objectCategory=Computer) -attr distinguishedName location operatingSystem operatingSystemVersion operatingSystemServicePack -limit 0 > C:\Dsquery.txt Oder mit Repadmin, aus den Windows Support Tools (alles in einer Zeile und nach dem /atts: kommt KEIN Leerzeichen): Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter: (&(objectcategory=computer)(primaryGroupID=516))" /subtree /atts: operatingSystem,operatingSystemVersion,operatingSystemServicePack

Hallo, ich denke, ersteres. Das beruht wohl alles auf einem Missverständnis. Ich dachte über "dieses" Stadium wären wir schon hinweg. ;) Ich meinte eben das in den ACLs, ein Name und nicht die SID --> angezeigt <-- wird und eben nicht direkt die SID. Der Name kann natürlich nur angezeigt werden, wenn sie - wie du schon erwähnt hast - aufgelöst werden kann. Das die angezeigten Namen in der Windows-Welt ohnehin nur "Schall und Rauch" sind und sich dahinter die SID verbirgt, ist uns doch allen klar.

Na was wird denn bei "deinen" ACLs angezeigt? Der Name des Zugriffsberechtigten oder solch ein Eintrag: S-1-5-21-....? Genau, der Name nämlich. ;)

Salve, ... und in den ACLs? ;)

Du darfst diesen Artikel ruhig lesen, der beißt auch nicht. ;) Yusufs Directory Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Salve, dein AD funktioniert doch zur Zeit auch, obwohl das NTDS-Verzeichnis auf der USB-Platte gespeichert ist. Wenn du aktuell weitere DCs in der Domäne hast, dann ist das doch der Beweis dafür, dass es damit keine Probleme gibt. Das Eventlog berichtet auch über aktuelle Probleme. Wenn das AD ordnungsgemäß installiert wurde, dann stellt die USB-Platte kein Problem dar. Das bereitet bei der Domänenaktualisierung auf Windows Server 2008 keine Probleme. Du aktualisierst die Domäne wie in dem folgenden Artikel beschrieben auf Windows Server 2008 und fügst den neuen Server, als zusätzlichen DC der Domäne hinzu. Yusufs Directory Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen Danach kontrollierst du ob die AD-Replikation funktioniert und behälst insbesondere das Eventlog im Auge. Denn falls Probleme enstehen sollten, verrät dir das Eventlog dies sehr schnell. Auf dem neuen DC sollte auch das DNS installiert werden. Yusufs Directory Blog - Einen zusätzlichen DC in die Domäne hinzufügen Die FSMO-Rollen solltest du ebenfalls auf den 2008er DC verschieben sowie den globalen Katalog aktivieren. Yusufs Directory Blog - Die FSMO-Rollen verschieben Yusufs Directory Blog - Globaler Katalog (Global Catalog - GC)

Buenas noches, hat der DC zufällig mehr als eine Netzwerkkarte oder wurde Routing und Ras installiert? Falls ja, dann ist beides auf einem DC seitens Microsoft nicht supportet. Technisch kann man es aber zum laufen bekommen, was aber jederzeit (in die Zukunft blickend) zu Fehler führen kann. Wenn du im Internet nach "Multihomed DC" suchst, wirst du jede Menge dazu finden. Active Directory communication fails on multihomed domain controllers Die Clients die sich nicht anmelden können, welchen DNS-Server haben sie in ihren TCP/IP-Einstellungen zu dem Zeitpunkt eingetragen? Suche nach diesem und den folgenden Fehlern auf der EventID.net Seite und gehe den Kommentaren nach. EventID.Net - Troubleshooting information for Windows event logs Schreibe mal etwas mehr über die Systemkonfiguration und wie die Umgebung aussieht. Existieren z.B. weitere DCs und existiert eine aktuelle und funktionierende Systemstatus-Sicherung (System State)? Das Verzeichnisdienstprotokoll in der Ereignisanzeige meldet keine Fehler? Installiere dir mal die Windows Support Tools (passend zum Service Pack) und führe mal das DCDIAG sowie NetDIAG aus. Download details: Windows Server 2003 Service Pack 1 32-bit Support Tools Download details: Windows Server 2003 Service Pack 2 32-bit Support Tools Du kannst sicherheitshalber auch die Konsistenz der Active Directory-Datenbank überprüfen: Yusufs Directory Blog - Die Active Directory-Datenbank reparieren

Du könntest den DC "mit Gewalt" zum Arbeitsgruppenserver herunterstufen. Nach einem Neustart kannst du dich dann mit dem Administrator und dem Kennwort für den Modus "Verzeichnisdienste wiederherstellen" anmelden. Ich persönlich halte nichts von dieser Variante, wobei es aber eine Möglichkeit wäre. Du könntest dir einen Dienstleister zur Hilfe holen, dann besteht evtl. die Chance, dass das System "schnell" wieder betriebsbereit ist. Aber wenn auf dem DC ohnehin nicht viel passiert, kann man ihn evtl. auch gleich neu aufsetzen.

Genau, oder auf deutsch Domänencontroller. Nein, das "Active Directory" wird mit AD abgekürzt. Der Systemstatus kann mit Bordmitteln, nämlich mit "Start-Ausführen-NTBACKUP" gesichert werden. Was damit gesichert wird, verrät dir dieser Artikel. Yusufs Directory Blog - Einen Server mit rücksichern des System State zum DC stufen Man kann die AD-Datenbank samt den Logs auf eine andere Partition verschieben. Aber natürlich nicht einfach per Explorer, sondern mit NTDSUTIL. Die Frage wäre, ob das NTDS-Verzeichnis direkt bei dem heraufstufen auf D: plaziert wurde oder es später dorthin verschoben wurde und falls ja, wie? Yusufs Directory Blog - Active Directory Datenbank (NTDS.DIT) samt Logs (EDB*.LOG) verschieben Na super... Das System State ist das mindeste, was an einem DC gesichert werden muss! Entweder hat die AD-Datenbank einen defekt oder das Verzeichnis wurde auf eine nicht unterstützte Variante verschoben. Ich schlimmsten Fall, die Domäne neu aufsetzen. Ja, nämlich die NTDS.dit (also die AD-Datenbank).

Salve, lass mich raten. Dieser DC ist natürlich der einzigste DC und es besteht keine aktuelle System State-Sicherung? Du könntest auch ohne eine Wiederherstellung eine Analyse durchführen und falls Fehler gemeldet werden, diese mit einem FIXUP versuchen zu beseitigen. Falls das aber dein einzigster DC sein sollte, dann ist auch bei diesem Vorhaben Vorsicht geboten. Nicht das dadurch noch mehr "kaputt" geht. Yusufs Directory Blog - Die Active Directory-Datenbank reparieren Wenn eine funktionierende Systemstatus-Sicherung existiert, dann kann man den DC auf alle Fälle wiederherstellen. How to perform an authoritative restore to a domain controller in Windows 2000 Falls mehrere DCs existieren (was ich nicht denke), dann könntest du diesen DC mit Gewalt herunterstufen [1] und anschließend neu zum DC stufen. Aber ohne eine Sicherung besteht die Gefahr, dass am System noch mehr defekt ist. [1] Yusufs Directory Blog - Das Active Directory gewaltsam vom DC entfernen

Hola, das ist eine gesunde Einstellung, denn wie heißt es so schön: Man/n wächst mit seinen Aufgaben. Jedoch sollte man auch seine Grenzen kennen. ;) In deinem Fall, auf alle Fälle. Absolut. Du benötigst in den Aussenstellen nicht zwingend einen Exchange-Server. Du könntest lediglich in der Zentrale Exchange-Server betreiben. Dafür ist doch der Cached-Mode gedacht. Aber das kommt auf das Mailverhalten der Aussenstellen an. Ja, du kannst Aufgaben im Active Directory an die entsprechenden Leute delegieren. Das ist ja gerade das schöne am Active Directory. Man kann nun im Gegensatz zu Windows NT, eine hierarchische Organisationsstruktur erstellen und die Objekte innerhalb einer Domäne, in mehrere Organisationseinheiten (OUs) organisieren. Die Verwaltung der einzelnen OUs können dann wiederum auf einer aufgabenbasierten Ebene, an die entsprechenden Personen delegiert werden. Den entsprechenden Link dazu, hast du bereits von LukasB erhalten. Genau. Also zuerst muss natürlich auf IP-Ebene alles korrekt konfiguriert sein. Das Routing zu den Aussenstellen muss funktionieren. Du könntest dann die DCs für die Aussenstellen dann in der Zentrale installieren, mit dem IP-Adressbereich der Zentrale und änderst anschließend nach dem verschieben, die IP des DCs. Yusufs Directory Blog - Einen zusätzlichen DC in die Domäne hinzufügen Yusufs Directory Blog - Einen Domnencontroller an einen anderen Standort verschieben Oder du installierst die DCs direkt in den Aussenstellen, mit der IFM-Funktion. Aber das ist erst ab Windows Server 2003 möglich. Yusufs Directory Blog - Domänencontroller-Installation von einer Sicherung Im Snap-In "Active Directory-Standorte und -Dienste" erstellst du für jeden physikalischen Standort jeweils einen AD-Standort samt AD-Subnetz. Danach verschiebst du die DC-Icons an ihren entsprechenden AD-Standort. Beachte dazu unbedingt den o.g. Link "Einen Domänencontroller an einen anderen Standort verschieben". Wenn die Aussenstellen untereinander keine Verbindung haben, also eine klassische Hub-and-Spoke Topologie existiert, könntest du noch die Überbrückung in "Standorte und Dienste" deaktivieren. Dann hält sich die AD-Replikationen an deine Standortverknüpfungen.

Salut, dann erstelle dir doch z.B. mit dem kostenlosen VMWare Converter von deiner Umgebung eine VM-Testumgebung und spiele deine Tests in der VM-Testumgebung durch. Die Testumgebung sollte natürlich keine Verbindung zur produktiven Umgebung haben. Aber auch auf die Sicherheit sollte in der Testumgebung geachtet werden, denn sie enthält schließlich alle Kennwörter der Domäne. VMware Converter zur Migration von Workstations zu virtuellen PCs oder zu virtuellen Masch - VMware Gruß und fröhliche Weihnachten

Was die Berechtigungen von SQL oder Shrepoint betrifft, wirst du Hand anlegen müssen. ADMT ändert die Dateisystemberechtigungen (Freigabe- bzw. NTFS-Berechtigungen), aber nicht die Berechtigungen innerhalb von SQL oder Sharepoint.

Salve, dafür sind wir doch hier. You are welcome. :) Natürlich, eine Migration ist keine kleine Angelegenheit und die Wahrheit kommt erst bei der produktiven Migration zum Vorschein. Bei einer Test-Migration lernt man die einzelnen Schritte und das Migrationswerkzeug kennen, aber der Teufel steckt wie so oft im Detail, was aber eben vieles erst bei der echten Migration eintritt. Das Werkzeug lernt man eben bei einer Test-Migration kennen. Aber hier im Board sind auch eine Menge Leute, die eine Menge Migrationserfahrungen haben und dir/euch zur Seite stehen. Ich persönlich finde z.B. auch ein anderes Migrationswerkzeug, nämlich den AD Migrations-Manager von Quest genial. Kostet allerdings auch etwas. Schaue dazu am Montag auf meine Webseite. Den Link findest du in meiner Signatur.

Lies dir das Whitepaper zu ADMT durch und führe ggf. eine Test-Migration in einer Testumgebung durch. Dann wird einiges klarer. ;)

Salut, Download details: Windows SBS 2003 to 2008 Migration Guide

Klar, es gibt verschiede Möglichkeiten den Domänennamen zu wählen. Für die Wahl des Domänen-Namens, gibt es mehrere Varianten: 1. Der Active Directory-Name lautet so wie die Internetdomain. 2. Der Active Directory-Name ist eine Subdomäne zum externen Internet-Auftritt. Bedeutet, wenn der Inet-Auftritt "Contoso.com" lautet, so wäre der AD-Name "intra.contoso.com". Diese Variante, wäre auch meine empfohlene. 3. Der Active Directory-Name ist ein anderer als die Inet-Domain z.B. contoso.local usw. Sogar die Endung LOCAL kann zu Problemen führen, denn damit könnten Probleme mit Apple-PCs auftreten. Auch wäre es denkbar, dass die Endung LOCAL offiziell wird (sowie info, biz usw.). 4. Oder der Webauftritt lautet contoso.de und die interne AD-Domäne lautet contoso.net. Dabei sollten natürlich beide Domains beim ISP registriert werden. 5. Die TLD AA, ZZ und die Bereiche QM–QZ und XA–XZ. ISO 3166 ? Wikipedia 6. Einen abstrakten AD-Domänennamen, unabhängig vom Firmennamen. Das hat den Vorteil, wenn sich die Firma umbenennt, muss nicht sofort die AD-Domäne wegen einem Namen unbenannt werden. Ja, dass wird auch geändert. Auf den Clients sowie Memberservern wird ein Agent installiert, der die lokalen Änderungen vornimmt. Nach einem Neustart gehört der Server dann der neuen Domäne an, AD-technisch und auch lokal. Nein, du siehst es so wie es sein muss ;) . Nach der Migration ist alles so, wie wenn du einen neuen Server der Domäne hinzufügen würdest.

Damit erstellst du quasi die Ziel-Domäne. Die Quell- sowie Ziel-Domäne müssen natürlich parallel laufen, damit die Migration mit ADMT stattfinden kann. Korrekt. Bei den Computerkonten kannst du Clients sowie Memberserver migrieren, aber keine DCs. DCs müssen aus der alten Domäne herunter- und in der neuen Domäne heraufgestuft werden. Du migrierst ja nicht das komplette Schema der alten Domäne, sondern lediglich gewisse Objekte. Da passiert nichts. Du migrierst doch deine gewünschten Objekte in die neue Domäne und deinstallierst am Ende die alte Domäne. Du baust die neue Domäne so auf, mit der gewünschten Anzahl an DCs, so wie du es geplant hast. Um mit ADMT zu migrieren, ist eine Namensauflösung und eine Vertrauensstellung notwendig. Um eine Vertrauensstellung zwischen der alten und neuen Domäne zu erstellen, muss der NetBIOS- sowie der DNS-Name der AD-Domäne ohnehin eindeutig sein. Nach der Migration der Clients und Mitgliedsserver gehören die Maschinen sowieso nur einer Domäne, nämlich der neuen Domäne an. Bei der Wahl des Domänen-Namens, gibt es mehrere Varianten, wobei ich ein Freund dieser Variante bin: - Der Active Directory-Name ist eine Subdomäne zum externen Internet-Auftritt. Bedeutet, wenn der Internet-Auftritt "Contoso.com" lautet, so wäre der AD-Name "intra.contoso.com".

Ja, du kannst alle Rollen entweder über die GUI oder über die Kommandozeile mit NTDSUTIL - TRANSFER auf einen anderen DC verschieben. Ja, sind sie. Um die Rolle des Schemamasters über die grafische Oberfläche zu verschieben, führe auf dem DC der die Rolle bekommen soll unter Start-Ausführen diesen Befehl aus: regsvr32 schmmgmt.dll. Danach kannst du das Schema Snap-In in eine MMC hinzufügen. Weitere Details entnimmst du bitte aus diesem Artikel: Yusufs Directory Blog - Die FSMO-Rollen verschieben In den meisten Umgebungen ist es ohnehin sinnvoll, alle Rollen auf einem DC zu haben. Du entfernst die bestehenden DCs mit DCPROMO aus der Domäne. Vorher überträgst du natürlich alle Daten sowie Dienste auf den bestehenden DC. Anschließend fügst du erneut den Server nach der Neuinstallation als zusätzlichen DC der bestehenden Domäne hinzu. Yusufs Directory Blog - Einen zusätzlichen DC in die Domäne hinzufügen Nein, dass musst du nicht. Es spielt keine Rolle auf welchem DC die Rollen liegen, Hauptsache sie sind jederzeit online und erreichbar. Du führst DCPROMO aus und wählst an entsprechender Stelle, dass du einen "zusätzlichen Domänencontroller fü eine bestehende Domäne" installieren möchtest. Nach dem heraufstufen installierst du noch das DNS. FSMO-Rollen werden dabei aber nicht automatisch verschoben. Beachte dazu den o.g. Link.

Genau. Das kann man machen, jedoch muss das hochsetzen vor dem ausschalten passieren, so das der Filial-DC diese Änderung repliziert bekommt. Ich würde aber nicht dazu raten, die TSL zu verändern. Die TSL beträgt mindestens 60 Tage und länger wird wohl (und sollte auch nicht) der DC nicht ausgeschaltet bleiben.

Überprüfe mal die ACL der C: Partition und kontrolliere, ob das SYSTEM darauf Zugriff hat. Du könntest die ACL ggf. mit einem anderen Server vergleichen. Dein eigentliches Ziel ist es doch den DC herunterzustufen. Du könntest diesen natürlich auch auf die gewaltsame Weise wie hier bereits erwähnt wurde, mit DCPROMO /Forceremoval herunterstufen. Anschließend muss dann noch der DC aus den Metadaten des AD entfernt werden. Siehe auch (nicht vom Titel verwirren lassen): Yusufs Directory Blog - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen

Aloha, solange die Tombstone Lifetime (TSL) nicht überschritten wird, hat das keine größeren Auswirkungen. Yusufs Directory Blog - Die Tombstone Lifetime Falls die TSL überschritten werden sollte, kann man das zwar auch wieder zum laufen bekommen, jedoch mit einem erheblich höheren Administrationsaufwand, den aber kein Mensch brauch. Stichwort dazu lautet "Lingering Objects", zu deutsch "herumlungernde Objekte". Yusufs Directory Blog - Lingering Objects (veraltete Objekte) Nach dem starten des Filial-DCs, achte darauf das sich der DC mit seinen Replikationspartnern ordnungsgemäß repliziert. Werfe dabei einen Blick in das Eventlog des DCs, dort sollten dann keine Fehler erscheinen. Du könntest zusätzlich - ich würde es einen Tag später durchführen - die beiden Windows Support Tools DCDIAG sowie NetDIAG auf dem DC ausführen, um den Gesundheitszustand des DCs zu überprüfen. Aber das Eventlog verrät dazu auch schon eine Menge.

Ahh... ok, verstehe. Dann hatte es falsch verstanden. Diesen Samba hatte ich natürlich komplett ausgeblendet und wollte nur darauf hinweisen, dass es prinzipiell möglich ist.

Bonjour, doch natürlich, beides kann migriert werden. Stichwort "SIDHistory" und "Password Export Server (PES) [1]" (<-- gehört zum ADMT). [1] Downloaddetails: PES v3.1 (x86)