Daim

Servus, versuche dich erst einmal an diesem Artikel, dann schauen wir weiter: Ereigniskennung 16650: Die Kontenkennungszuweisung wurde unter Windows 2000 und Windows Server 2003 nicht initialisiert

Servus, das kann man über das sichern und wiederherstellen des SBS realisieren. Mit dem Unterschied, dass das wiederherstellen auf neuer Hardware durchgeführt wird. Sichern und Wiederherstellen von Windows Small Business Server 2003

Nein, ein isolieren des Servers ist nicht notwendig. Da das Upgrade an einem Wochenende durchgeführt wird, werden wahrscheinlich auch keine Änderungen im AD durchgeführt, so das es auch nichts großes zu replizieren gibt. Von daher sehe ich keine Probleme, den Server im Netz zu lassen.

Genau so sieht es nämlich aus. Treffe deine Vorkehrungen (Sicherung) für den Fall der Fälle in jedemfall.

Dann tue dir keinen Zwang an ;) . Das passt. Warum willst du hier neu installieren und machst kein Inplace-Upgrade ? Da bereits bei dir Exchange mit der Version 2003 läuft, brauchst du lediglich das Betriebssystem-Update durchzufühen. Du sparst dir mit einem Inplace-Upgrade eine Menge Arbeit. Yusuf`s Directory - Blog - Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update) Es ist zwar nicht verkehrt, aber du kannst es auch einfacher erledigen ;) .

Off-Topic: Tja... das nennt man "südländische Intuition". Abgesehen davon solltet ihr Lotto spielen, denn wenn ihr den Pott gewinnt, braucht ihr garkeine Kugeln mehr und könntet euch direkt einen Wahrsager einstellen ;) .

Das steht doch ebenfalls in meiner Antwort oben ;) .

Aloha, ich sach mal zu allem: Ja ;) . Da fehlt aber noch der Punkt, das der gecrashte DC (denn einen BDC sowie PDC gibt es seit Windows 2000 nicht mehr und nein, die FSMO-Rolle PDC-Emulator zählt nicht als solches) aus dem AD zu entfernen ist. Das geht entweder mit NTDSUTIL oder ADSIEdit. Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung @roesti Installiere auf dem bestehenden DC das DNS und führe anschließend in der Kommandozeile ein "net stop netlogon && net start netlogon" aus. Danach solltest du den anderen Server als zusätzlichen DC erneut hinzufügen können. Entferne aber vorher die Leiche aus dem AD. Und merke dir für die Zukunft, auf jedem DC auch das DNS zu installieren und speichere die Forward Lookup Zone im AD, dann profitierst du einmal von den "Nur sicheren" Updates und zum anderen, erledigt die AD-Replikation für dich den Rest.

Salut, wurde der Rechner zufällig geclonet/geimaget ?

Servus, dann vergiss nicht das ADPREP von der zweiten R2-CD zu verwenden. Was sonst noch alles zu beachten ist, erfährst du aus diesem Artikel: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen Da bereits bei dir Exchange 2003 läuft, brauchst du lediglich das AD-Schema mit ADPREP von der zweiten R2-CD zu aktualisieren. Aber auch wenn eine Schemaaktualisierung von nöten sei, würde dir der Assistent das an entsprechender Stelle melden und danach könntest du immer noch das Schema aktualisieren.

Nein, dass Kennwort ist nicht das Problem. Ich persönlich würde die Kennwörter auch nicht mitnehmen, sondern neue vergeben lassen. ADMT stellt ohnehin dann die Option "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" ein. Aber der Registry-Key hat, sofern ich das auf die schnelle sehen konnte, nichts mit dem Kennwort zu tun. Setze diesen mal und starte danach den DC neu und versuche es erneut.

Auch wenn der folgende Artikel eine Migration von NT zu 2003 beschreibt, wende diesen mal an. Es gibt keinen ADMT-Artikel der eine Migration von Windows Server 2003 zu Windows Server 2003 beschreibt. Daher ist es einen Versuch wert. Stichwort: TcpipClientSupport How to configure the Active Directory Migration Tool to migrate user passwords from a Windows NT 4.0 domain to a Windows Server 2003 domain

Aha, also doch noch etwas im Trust-Busch. Lösche die Vertrauensstellung nochmals und erstelle diesmal den Trust mit NETDOM. Was spricht ein Verify dann ? P.S. Meine Seite läuft wieder.

Musst du mal auf der Connect-Seite danach suchen. Ich weiß es nicht. Die laufen AFAIK nicht unter dem Namen 2008, sondern Vista. In diesem frühen Beta-Stadium sind die Produkte nicht im Technet bzw. MSDN-Abo erhältlich. Wenn, dann tauchen die dort zu einem späteren (ausgereifteren) Zeitpunkt auf.

Ja, dass kommt auf die Strategie an. Ich bin ein Freund davon, in der Freigabeberechtigung "Jeder - Vollzugriff" einzutragen, um dann die eigentliche Berechtigung in den NTFS-Rechten festzulegen. Aber so oder so, beides führt zum Ziel. P.S. Ich hatte die Lösung extra nicht gepostet, um den OP mehr zum nachdenken bzw. zur Eigeninitiative zu bewegen (was wir öfters tuen sollten) ;) .

Servus die gibt es nicht auf der 2008er DVD. Genau so sieht es aus. Die Tools sind gerade in der Beta raus und gibt es eben nur auf Connect. Abgesehen davon, hast du die 64Bit-Variante der Tools erwähnt. Die 32Bit Variante trägt den Namen "Windows6.0-KB941314-x86.msu".

Servus, das kann ja auch nicht funktionieren, wenn in der FREIGABE die Domänen-Benutzer lediglich mit dem Recht LESEN berechtigt sind. Denn es greift bei der Freigabe-/NTFS-Berechtigungen immer das restriktivere Recht.

Genau darauf deutet es hin. Da der DC namentlich im ADMT nicht angezeigt wird, kommt diese Fehlermeldung auch hin. Das kuriose ist, der physikalische Zugriff besteht, lediglich das ADMT ist im glauben, dass es keine Verbindung hätte. Ich hätte adhoc auf DNS sowie Verbindungsprobleme getippt bzw. das die Vertrauensstellung nicht 100% korrekt funktioniert. Überprüfe sicherheitshalber den TRUST, z.B. mit NETDOM. Das ist auch das schärfste. Meine Seite liegt auf dem Web-Server des Veranstalters der ICE. Der Webspace ist wieder voll und muss erweitert werden. Ich habe bereits eine Mail geschickt und hoffe, dass das heute Abend behoben wird. Also nur Geduld haben bitte ;) .

Ne. nicht "logisch". Das hätte funktionieren können und abgesehen davon, was ist in der IT schon logisch ;) . Welche Fehlermeldung erhälst du denn, wenn du als Ziel dann nicht einen DC auswählst, sondern <Any domain controller> auswählst ? Du nutzt die Version 3 von ADMT ? Keine besonderen als die Standard-Dienste die auf einem DC ohnehin automatisch laufen. Hast du sicherheitshalber mal das Whitepaper zu ADMT durchforstet bezgl. x64Bit ? Das würde ich einmal tun.

Off-Topic:Dann bitte das nächstemal besser nichts sagen :rolleyes:

Servus, yepp, dass funktioniert problemlos. Es gibt lediglich etwas zu beachten, dass wenn das 64Bit System, der erste Windows Server 2003 --> R2 <-- DC werden soll. Beachte dazu in diesem Artikel den Abschnitt: Erster Windows Server 2003 R2 64 Bit Domänencontroller in einer Windows Server 2003 32 Bit Domäne Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Alles andere wäre zu aufwändig. Die Attribute sind ja bereits im Schema enthalten (Employee-ID sowie Employee-Number), demzufolge brauch man das Schema nicht zu erweitern. Das "Problem" ist dabei eben, diese anzusprechen in Form von der Eingabe in einem Feld. Wenn man das in die Benutzereigenschaften eines Benutzes eintragen möchte (z.B. im Reiter Allgemein oder sonstwo), dann müsste man mit C++ ran. Das denke ich, sprengt den Rahmen. Da wäre die HTA-Variante das einfachste.

Servus, das ist schwierig. Wenn du Exchange im Einsatz hättest bzw. die Exchange Schema-Erweiterung durchgeführt hättest, stehen dir 15 Attribute zur Verfügung. Diese könntest du für deine Zwecke verwenden. Ich würde das aber über das Kontextmenü (HTA) lösen, was auch einfacher zu realisieren ist. Siehe diese Anleitung: Yusuf`s Directory - Blog - Personalnummer im AD eintragen

Na wer sagts denn... so muss das sein. Ja, wenn das SYSVOL Probleme bereitet ist das schon sher ärgerlich. Aber alles was du dazu brauchst, ist einen kühlen Kopf und diesen Thread mit samt den Informationen sowie Artikeln. Denn ich habe dir bereits alles geschrieben gehabt, wie sich das SYSVOL PRoblem beseitigen lässt. Zusätzlich mit der Angabe der Artikeln ist dieses Problem auf jedenfall zu beseitigen. Wie dem auch sei, behalte das Eventlog im Auge und setze nicht alle Tools an (FRSDiag, Sonar..). Das halte ich für unnötig und teilweise auch irritierend, denn die Tools sind etwas älter und zeigen auch schonmal ein Missing Junction Points an, obwohl es aber vorhanden ist.

Eieieiiii... das ADMT ziert sich aber ganz schön, es kann aber nicht mehr viel sein ;) . Wenn ich es richtig in Erinnerung habe, hast du das ADMT in der Quell-Domäne installiert? Falls ja, installiere doch mal das ADMT in der Ziel-Domäne und füge den Domänen-Admin aus der Ziel-Domäne, auf einem Test-Rechner in die lokale Gruppe der Administratoren. Anschließend versuche eine Test-Migration und kontrolliere ob es funktioniert. Gehe aber zusätzlich nochmals das Whitepaper zu ADMT durch, was du sicherlich schon gemacht hast, aber ein zweitesmal schadet nicht ;). Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To Der Name "intranet.kirche-ort.de" ist der DNS-Name der Domäne, aber nicht der NetBIOS-Name der Domäne. Denn der NetBIOS-Name einer Domäne kann lediglich 15 Zeichen lang sein. Der DNS-Name meiner eigeneen Domäne lautet "intra.dikmenoglu.de", der NetBIOS-Name lautet aber "Dikmenoglu". Das kann aber auch lediglich ein Anzeigefehler sein, wie er z.B. bei einer AD-Suche ebenfalls erscheint. Es wird dann als Domäne lediglich das erste Oktett vom DNS-Namen der Domäne angezeigt. Mit Sicherheit nicht. Das war auch unnötig. Mir fehlte nur der Überblick was du bisher getan hattest bzw. von wo/was nach wo/was migriert wird. Klar habe ich die, wer hat die nicht. Aber ich führe meine Wunschliste immer selbst aus. Danke der Nachfrage. Lass uns eine Cola bei einem Treffen (evtl. auf dem 2008er Launch?) trinken und gut ist ;) .