Daim

Klar, dass wäre es auf alle Fälle. Andernfalls würde der Markt schon von selbst darauf reagieiren, in dem sie auf Windows XP bleiben. :cool:

Servus, also den Server wird es definitiv nur noch als x64Bit-Version geben. Die x32-Bit Version ist Geschichte. Ach warum denn... das ist ein Grund um sich neue Hardware zuzulegen. :p

Salut, lagen die Word-Vorlagen (DOT) auch auf einem Netzlaufwerk? Siehe auch: WD: Das Öffnen von Word-Dokumenten dauert sehr lange

Servus, es heißt "AD". :p Wie die Kollegen bereits mit ihren Links darauf hingewiesen haben, du musst das ADPREP von der zweiten R2-CD auf dem Windows Server 2003 Schemamaster ausführen und nicht von der ersten R2-CD. OK, dass kannst du so machen und stellt auch kein Problem dar. Klar. "Gefährlich", garnicht. Nein, keineswegs. Denn das R2 ist keinerlei Update der Betriebssystemkomponenten. R2 müßte man eher "Feature-Pack" nennen. Die erste CD von R2 ist ein Windows Server 2003 mit Service Pack 1. Die zweite CD macht daraus ein "R2" indem Zusatzkomponenten unter Systemsteuerung - Software eingetragen werden, die man dann für bestimmte Szenarien nachinstallieren kann. Nein wird es nicht. Auch das sichern des System-States bringt für das Schema nichts, da die Schemapartition nicht autoritativ wiederhergestellt werden kann. Wenn du einen "älteren" Schema-Stand haben möchtest, müsstest du ein "Forest-Recovery" durchführen. Vor der Schemaaktualisierung brauchst du aber auch ohnehin keine "Angst" zu haben. Denn dort kann nichts "kaputt" gehen. Entweder die Schemaaktualisierung wird durchgeführt oder nicht. Es werden also keine halben Attribute oder Klassen erstellt, da jede Aktion der Schemaaktualisierung eine Transaktion darstellt. Beachte einfach die Links die man dir gepostet hat.

Das ist natürlich auch eine Variante, dass SYSVOL-Problem zu lösen. ;) Das hätte man aber auch "einfacher" lösen können. Aber dann bestanden wohl noch weitere Probleme. Na Hauptsache es läuft jetzt.

Servus, eine primäre "AD integrierte" Zone. Also eine Forward Looup Zone (FLZ), die im AD gespeichert wird. Denn somit werden die DNS-Informationen zwischen den DCs automatisch durch die AD-Replikation repliziert. Der Adminstrator muss nichts "extra" konfigurieren. Dabei sollte auch darauf geachtet werden, dass bei der dynamischen DNS-Aktualisierung die Einstelung "Nur sichere Updates" eingestellt wird. Weder noch. Wenn die FLZ AD-integriert gespeichert wurde, installierst du auf deinen zusätzlichen DCs nur das DNS und wartest lediglich die AD-Replikation ab. Siehe auch: Yusufs Directory Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Danke für den Hinweis, dass sollte natürlich nicht fehlen (wird eingearbeitet). Ja, dass sieht gut aus.

Salut, na klar wird das von Microsoft beschrieben. Lies dir die folgende Seite und vorallem die Links unter den weiterführenden Informationen durch. Yusufs Directory Blog - Active Directory Replikation durch eine Firewall "Mein" Google ist voll von Links. Evtl. solltest du deine Suchtechnik "überarbeiten". Einen DC hinter einer Firewall zu platzieren? Es kommt vor und ist möglich, es kommt aber eher in sicherheitskritischen Bereichen vor. Es kommt eben auf die Anforderung und Umgebung an.

Servus, genau so ist es. Ein ähnliches Verhalten siehst du auch bei dem Benutzernamen "Müller". Das "ü" wird auch als "u" interpretiert. Der Benutzer "Müller" könnte sich dann auch als "Muller" anmelden. Daher sollte man Umlaute möglichst vermeiden. Siehe: You cannot add a user name or an object name that only differs by a character with a diacritic mark Dafür aber bereits bekannt. ;)

Servus, im ADPrep.log steht unter anderem die Meldung: Ist das SFU installiert und falls ja, vermute ich weiter, dass dieses das Problem darstellen könnte. Suche im Internet mal danach, denn dazu gibt es (leider) zu viele Hinweise. Weiterhin erscheint als weitere Fehlermeldung im LDIF.log: Hier könntest du sicherheitshalber eine Analyse über die AD-Datenbank laufen lassen. Siehe: Yusufs Directory Blog - Die Active Directory-Datenbank reparieren Des Weiteren könnte man auch eine Offline-Defragmentierung des AD durchführen. Denn falls evtl. Schäden in der AD-DB bestehen sollten, könnten diese durch eine Offline-Defragmentierung beseitigt werden (natürlich nur nach vorheriger Datensicherung). Die Offline-Defragmentierung wird nämlich durch das erstellen einer neuen AD-DB durchgeführt. Performing offline defragmentation of the Active Directory database Wenn nichts hilft, könntest du noch einen zweiten Windows Server 2003 DC installieren (z.B. in einer VM), auf diesem die FSMO-Rollen verschieben und das ADPREP erneut in der VM ausführen.

Der Benutzer bzw. die Gruppe die im Feld "Verwaltet von", genauer im Attribut ManagedBy des RODC-Computerkonto angegeben wurde, ist der lokale Administrator der Maschine. Derjenige kann sich dann lokal mit seinem Benutzernamen an dem RODC anmelden und administrative Tätigkeiten durchführen (z.B. Treiber bzw. Software installieren), ohne das der Benutzer/die Gruppe weitere Rechte auf die Domäne bzw. andere DCs erhält. Der RODC wurde speziell für Aussenstandorte entwickelt. Denn oftmals besteht die Anforderung die Maschine lokal vor Ort von jemandem betreuen zu lassen, so das derjenige irgendwelche Wartungsarbeiten an der Maschine durchführen kann, aber dafür keine Rechte im Active Directory benötigt. Genau für dieses Szenario bietet sich der RODC an. Weil im Fall des Domänen-Admins dieser eben standardmäßig auf jeder Maschine in der Domäne Administrator-Rechte besitzt, auch auf dem RODC. Das Feld "Verwaltet von" in den Eigenschaften eines RODC-Computerkontos, ist eine Möglichkeit einen speziell für diese Maschine, lokalen Administrator zu definieren.

Salut, wenn es sich hierbei um den Domänen-Administrator handelt, hast du diesen denn aus der Gruppe "Abgelehnte RODC-Kennwortreplikationsgruppe" entfernt? Denn falls ein Benutzer in der abgelehnten- sowie zulässigen RODC-Kennwortreplikationsgruppe Mitglied ist, so hat die abgelehnte Gruppe immer Vorrang! Demnach kann sich der Admin nur am RODC anmelden, wenn der beschreibbare DC erreichbar ist. Ich gehe von "zweitem" aus. Hm... ich vermute du hast etwas missverstanden. Lies dir doch den folgenden Artikel durch, dann sollte es klarer werden. Yusufs Directory Blog - Die Installation eines RODC

Salut, das mag vielleicht bei dir so gewesen sein, jedoch ist die Mindestvoraussetzung, dass sich alle DCs im Forest auf "Windows 2000 SP4" befinden. Ich vermute eher das ein Sprach-Problem vorliegt. Hoffen wir mal, dass sich der OP noch meldet.

Nein.

Buenos dias, danke, gleichfalls. Das entsprechende Subnetz wurde ebenfalls erstellt und mit dem AD-Standort verknüpft? Erscheinen denn die Einträge im DNS, wenn du auf dem betroffenen DC den folgenden Befehl ausführst: net stop netlogon & net start netlogon ? Trage zum Test auch mal einen anderen DNS-Server in den TCP/IP-Einstellungen des DCs ein und führe den Befehl erneut aus. Denn dabei registriert der Anmeldedienst (Netlogon) auf dem DC die Einträge im DNS, die sich in der Datei "netlogon.dns" befinden. Die Datei "netlogon.dns" befindet sich im Verzeichnis "%windir%\system32\config" und enthält alle Einträge, die für die Registrierung der Ressourceneinträge (SRV-Records) des DCs benötigt werden. Das hätte automatisch funktionieren sollen, denn der Hase kann noch woanders begraben liegen. Demnach würde ich weiter forschen.

Hallo, nein, ein Cross-Upgrade von 32Bit auf 64Bit wird nicht supportet. Das bedeutet, du kannst nicht die 64Bit Windows Server 2008 DVD in das CD/DVD-Laufwerk eines 32Bit Windows Server 2008 Server einlegen und diesen dann auf 64Bit aktualisieren.

Aloha, danke und dito. Wird das ADPREP /FORESTPREP, das du auf dem Windows Server 2003-Schemamaster ausführst denn erfolgreich abgeschlossen? Stimmt die Sprache des ADPREPs mit der Sprache des installierten Windows Server 2003 überein? Versuche das ganze doch erneut und halte dich dabei penibel an diesen Artikel (achte dabei auf den roten Absatz): Yusufs Directory Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen Welche Meldung erhälst du denn in der Kommandozeile, wenn du diesen Befehl ausführst? Keine? Dann liegt höchstwahrscheinlich ein Sprachproblem vor.

Microsoft stellt eine Menge Tools zur Verfügung. Natürlich kann es nicht alles abdecken. Denn das Motto lautet: Leben und leben lassen. So überleben die Dritt-Anbieter. Aber wenn du einen Hardwarewechsel mit einem Drittanbieter Tool durchführst, kann natürlich Microsoft die ordnungsgemäße Funktion des Servers nicht gewährleisten. Denn woher soll Microsoft denn wissen, was und wie das Tool solch einen Wechsel durchführt? Das bedeutet, bei Problemen nach solch einem Wechsel, bist du auf dich und ggf. auf den Support des Dritt-Anbieter Tools, alleine gestellt. Für die Umgebung bzw. Ausfallsicherheit der Systeme, ist jedes Unternehmen auf sich gestellt. DU musst doch wissen und entscheiden, was bei einem Server-Crash zu tun ist. Das kann doch nicht Microsoft für dich beurteilen. Z.B. sollte auch in einer SBS-Umgebung, ein weiterer Domänencontroller existieren. Wie du den Rest abfängst, hängt von dir und der Umgebung ab. OK, dann weißt du jetzt, dass es kein Tool ist, sondern Anleitungen.

Hola, dann führe doch den Hardwarewechsel folgendermaßen durch: Migrating Windows Small Business Server 2003 to New Hardware Diese Art wäre eine nicht supportete Variante. Halte dich besser an den o.g. Link. Und ja, dabei hast du mehr zu tun, aber du bist auf der sicheren Seite. Das ist kein Tool, sondern eine Ansammlung von Artikeln und Anweisungen. Ich gehe davon aus, dass du dieses hier meinst: SBS Migration

Bonjour, also wenn du uns die passenden Stellen posten würdest, könnten wir dir besser helfen. Oder sind diese Informationen Geheim? ;) Ja, das zeigt zumindest, dass die AD-Replikation funktioniert. Jedoch hat das wenig Bedeutung auf die NTFRS-Replikation, mit der nunmal das SYSVOL-Verzeichnis repliziert wird. Die Troubleshooting-Tools für den NTFRS wären: - Sonar - Ultrasound - FRSDiag - NTFRSUTL Wenn die IP des DNS-Servers dein Problem nicht löst, schau dir den Link meiner ersten Antwort an.

Salve, selbstverständlich haben wir das gelesen. Aber warum die Arbeit selbst machen, wenn es andere bereits (vielleicht besser?) getan haben, was für erschwingliches Geld erworben werden kann. Abgesehen davon, war das eine Ergänzung meinerseits. Ich im Gegenteil, finde sie - natürlich je nach Level der Schulung - gerade für die Anwenderschulung als ausreichend. Selbstverständlich kommt es immer auf das Level der Schulung an. Man kann sich ja selbst ein Bild über die Unterlagen machen und anschließend beurteilen, ob es die richtigen sind.

Salut, ich kann dir als kommerzielle Schulungsunterlagen, wärmstens den HERDT-Verlag ans Herz legen. Das Preis-Leistungsverhältnis ist m.E. sehr gut. HERDT-Verlag - Willkommen in unserem Online-Shop! Viele Grüße und guten Rutsch

Hi Franky-Boy, wenn das nicht so wäre, dann hätte der OP kein Netlogon/SYSVOL Problem. ;) Nur wenn ADPREP tadellos durchgeführt wurde, lässt sich der Windows Server 2008 zum DC stufen. Da der OP explizit nach dem Netlogon/SYSVOL fragt, muss der neue Server bereits zum DC gestuft sein. Guten Rutsch.

Servus, dann erstelle das SYSVOL-Verzeichnis per Hand. Wenn du dich an den folgendene Artikel hälst, hast du das recht fix durchgeführt. How to rebuild the SYSVOL tree and its content in a domain Das kann nicht sein. Das SYSVOL-Verzeichnis wird in deiner Umgebung vom NTFRS repliziert. Demnach müssten im Dateireplikationslog des Windows Server 2008 jede Menge Fehler auftauchen. Du solltest ohnehin das DCDIAG auf dem neuen DC ausführen. Somit prüfst du den generellen Zustand des neuen DCs. Auf dem neuen DC sollte auch das DNS installiert und der GC aktiviert sein. An die Clients verteilst du dann den neuen DC als zusätzlicher DNS-Server.

Salut, genau so ist es. Daher sollten die FSMO-Rollen und insbesondere der PDC-Emulator immer auf dem aktuellsten (mit dem neusten Betriebssystem installiert) DC liegen. Siehe auch: Yusufs Directory Blog - Der PDC-Emulator Abgesehen davon macht es in den meisten Umgebungen Sinn, alle FSMO-Rollen auf einem DC zu haben. Yusufs Directory Blog - Die FSMO-Rollen verschieben