Daim

Nein, dass ist nicht möglich. Aber warum auch? Wenn du ohnehin eine R2-Lizenz hast, installiere die zweite R2-CD und gut ist. Tut auch nicht weh ;) .

R2 ist der Nachfolger von Windows Server 2003 und heute das aktuelle Betriebssystem. Ein Service Pack ist ein Service Pack und ist somit keine Betriebssystemkomponente. Nein, ein anderer Server ist es nicht. Beachte meine Antwort in dem Link von Günther. In dem du dir eine R2-Lizenz besorgst und die betroffenen Server auf R2 aktualisierst ;) .

Kann garnicht sein, denn der Windows Server 2008 kommt doch erst noch raus. Der ist zur Zeit in der RC1. Aber klar, dann gilt es zu prüfen ob die eingesetzten Applikationen unter Windows Serevr 2008 noch laufen. Wie immer eben bei einer Migration.

Warum denn, wenn man fragen darf?

Servus, technisch gesehen ist das recht einfach. Du legst lediglich die zweite R2 CD in den Server und aktualisierst somit den Server auf R2. Damit der Server auf R2 aktualisiert werden kann, muss: 1. eine R2-Lizenz gekauft werden oder es besteht Software Assurance 2. Das SP1 muss auf dem Server installiert sein 3. Eine R2-Seriennummer muss vorliegen. Handelt es sich bei dem Host um einen DC, musst du vorher das ADPREP von der zweiten R2-CD ausführen. Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 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.

Wie gesagt, dank der VM-Technologie ist eine Migration von NT auf 2003 "recht einfach" möglich und vorallem auch sicher. Im übrigen kann man von NT auf 2003 noch direkt migrieren bzw. ein Inplace-Update durchführen. Aber eine Migration bzw. Inplace-Update von NT auf Windows Server 2008 ist nicht möglich. Hier müssen dann zwei Migrationen durchgeführt werden. Zuerst von NT auf 2003 SP1, dann von 2003 SP1 auf Windows Server 2008.

Bei mir schon. Die Seite ist auf eine neue Plattform gestellt worden. Evtl. dauert es noch einwenig bis die DNS-Umstellung überall angekommen ist. Versuche es zu einem späteren Zeitpunkt erneut. Sie ist ok.

Frei vergeben kannst du ihn schon, du solltest aber nur meine oben genannten Empfehlungen beherzigen, denn ansonsten kannst du in der Zukunft damit Probleme bekommen. Denn z.B. wird in einer single-label Umgebung, der Einatz von Exchange Server 2007 nicht unterstützt. Dann kommt noch hinzu, dass sich das Service Pack 1 für den Exchange Server in einer sigle-label Umgebung nicht installieren lässt. Siehe: faq-o-matic.net | Die technische Online-Community » Welcher Name ist der beste für eine AD-Domäne? Erstens halte ich das für nicht notwendig und zweitens hilft dir dieses Buch nicht wirklich bei der technischen Umsetzung der Migration. Ich hatte dieses Buch mir ebenfalls bei der Migration damals von NT zu 2003 zugelegt und war enttäuscht davon. Die Antworten hier aus dem Board helfen dir mehr ;) .

Servus Edgar, na meistens in kleineren Umgebungen ist oftmals kein Geld für einen dedizierten zweiten Domänencontroller verfügbar. Dann empfehle ich meistens, auf bestehender Hardware die den Ansprüchen einer VM genügt, mindestens in einer VM einen zweiten DC zu installieren. Oder aber, auf einer älteren Client-Hardware die bereits ausgemustert ist, einen zweiten DC zu installieren. Denn ein reiner DC braucht nicht viel Ressourcen. Dieser dient lediglich zur "Absicherung" der Domäne in Fall eines Crashes des ersten DCs.

Servus, das "Hub and Spoke" Modell bei verteilten WINS-Servern ist sogar dringend anzuraten. Siehe: faq-o-matic.net | Die technische Online-Community » Wie sollte WINS konfiguriert werden?

Ich sagte nicht, dass es da nichts gibt, --> mir <-- ist in dieser Richtung nichts bekannt. Aber evtl. kann jemand anderes einen Link liefern. Das ganze liegt doch aber auch auf der Hand. Z.B. sollte ein Exchange Server nicht auf einem DC installiert werden. Technisch funktioniert das, es wird eben von Microsoft nicht empfohlen.

Nachtrag: Natürlich bleiben dabei die Benutzer- sowie Computerkonten erhalten. Nach dem Inplace-Update ist im Idealfall alles so wie vorher und der Benutzer merkt davon nichts. Du kannst aber auch eine Migration von der NT-Domäne in eine neue Windows Server 2003 Domäne duchführen. Mit ADMT kannst du die Benutzer- sowie Computerkonten von der NT- in die 2003er Domäne migrieren. Das schöne daran, dabei bleiben am Client die Einstellungen (Profile) erhalten. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To Es führen viele Wege nach Rom ;) .

Nein --> eigentlich nicht. Denn wie die Domänenstruktur aussieht, ist dem RID-Master völlig egal. Es kommt vielmehr darauf an, wie die Verbindung zum RID-Master aussieht. Wenn der RID-Master ausgelastet ist, hohe Latenz in den Ping-Zeiten hat etc. kann es gut sein, dass das dauert. Mich wundert das aber nicht, denn das AD hat teilweise sein "Eigenleben", es hält sich nämlich nicht immer an die Theorie ;) .

Servus, eine Richtlinie in dem Sinne ist mir nicht bekannt. Wenn man einen dedizierten DC einsetzt (idealerweise natürlich zwei DCs), vermeidet man einen Single Pont of Failure. Wenn auf einer Maschine alles läuft und dieser crasht, ist erstmal alles weg. Die Domäne, die Benutzerkonten, die Dienste, die Applikation etc. Das sollte vermieden werden. Dazu kann man sich auch mit einer VM behelfen. Das bedeutet, zumindest sollte ein zweiter DC in einer VM laufen. Es kommt natürlich auf die Größe des Unternehmens darauf an. Aber wenn möglich, sollten die Infrastrukturserver dediziert laufen, ohne das irgendwelche weiteren Applikationen darauf laufen, wie es z.B. Exchange oder SQL darstellt.

Servus, na das wird aber auch mal langsam Zeit ;) . Das einfachste wäre, wenn du ein Inplace-Update durchführst. Das bedeutet konkret, wenn die Hardware des PDCs für den Windows Server 2003 tauglich ist, dann solltest du in dieses die 2003er CD einlegen und auf 2003 updaten. Wenn die Hardware nicht 2003 tauglich ist, würde ich einer VM einen NT-BDC installieren und diesesn dann zum PDC stufen. Das schöne an der VM ist, du bekommst weniger Treiber-Probleme. Nach der Betriebssysteminstallation stufst du den BDC zum PDC und aktualisierst diesesn dann auf 2003 und installierst das AD. Nach der Betriebssysteminstallation startet der Active Directory-Assistent automatisch und du musst dann noch das AD installieren. Das schwierige dabei ist z.B. der DNS-Namen der Domäne. Dieser sollte gut gewählt werden. Du solltest auf keinen Fall einen einfachen Namen, genannt single-Label Domänennamen verwenden. 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. 5. Noch besser wäre die TLD AA, ZZ und die Bereiche QM–QZ und XA–XZ. Diese TLDs sind für die private Verwendung reserviert. ISO 3166 - Wikipedia Des Weiteren wird in einer single-label Umgebung, der Einatz von Exchange Server 2007 nicht unterstützt. Zudem kommt noch hinzu, dass sich das SP1 für Exchange in einer solchen Umgebung nicht installieren lässt. Zu Risiken und Nebenwirkungen fragen sie das Board oder Daim ;) .

Dann korrigieren wir direkt weiter... Das war bis Windows 2000 SP4 so. Ab Windows 2000 SP4 versucht der DC bereits nach Verbrauch von 50% des RID-Pools, dass standardmäßig aus 500 RIDs besteht, zu erneuern. Im Klartext, wenn ein DC 250 RIDs verbraucht hat, versucht dieser vom RID-Master neue anzufordern. "Domain controller has failed to obtain a new identifier pool" error event in Windows 2000 Server SP3 and earlier

Das ist korrekt. Diensten gibt man ein Benutzerkonto, dass lediglich die gerade benötigten Rechte erhält. Und nur bei diesen Konten könnte man die Option in den Benutzereigenschaften setzen, dass das Kennwort nie abläuft. Ideal wäre es aber, wenn natürlich auch das Kennwort dieser Konten regelmäßig geändert wird. Die Begründng dazu habe ich bereits in meiner ersten Antwort aufgeführt. Was bringt es mir, wenn ich das Kennwort des Domänen-Admins in den Safe lege und zeitgleich einen zweiten Domänen-Admin einrichte, mit lediglich einem anderen Namen? Entscheidend ist wie gesagt die SID, der Name ist nur Schall und Rauch. Eins ist auch klar, in den Empfehlungen die Microsoft ausgibt, wird oftmals das maximale - wenn auch nicht immer 100%ig anwendbare - aufgeführt, damit die IT-Abteilung zumindest den Gefahren bewußt wird und Maßnahmen ergreift.

Das kann dann aber nur den lokalen Administrator auf dem Client gelten, z.B. mit dem Benutzernamen "HansWurst". Wenn der Benutzer diese Rechte LOKAL benötigt, dann ja. Idealerweise aber natürlich nur soviel Rechte wie nötig. Das bedeutet, wird für eine Applikation Admin-Rechte benötigt, sollte die Applikation angepasst werden und nicht dem Benutzer zuviele Rechte verpasst werden. Soll der Benutzer Rechte in der Domäne erhalten, dann ist es die sinnvollste Variante, dem Benutzer ein weiteres Benutzerkonto zu zuweisen, dem die benötigten Rechte in der Domäne delegiert worden sind. Wenn der Benutzer Arbeiten in der Domäne ausführen muss, meldet er sich mit diesem Benutzerkonto an und sobal er fertig ist, meldet er sich mit seinem normalen Benutzerkonto erneut an. Während der täglichen Arbeit, sollte JEDER - und das zählt die IT ebenso - mit einem Benutzerkonto angemeldet sein, der lediglich Benutzer-Rechte hat. Erst wenn administrative Arbeiten durchgeführt werden sollen, sollte man sich mit einem administrativen Konto anmelden. Siehe: Gruppenrichtlinien - Übersicht, FAQ und Tutorials

Servus, das ist lediglich sinnvoll, um den internen "möchtegern" Hacker aus der Firma einen Strich zu spielen. Denn dieser glaubt ja, dass er der größte wäre und versucht sich als der "Administrator" in das System reinzu*****n. Er versucht eben dass Kennwort für den Domänen-Administrator mittels einer Brute Force Attacke herauszufinden. Wenn dieser aber nicht der "echte" Domänen-Admin ist, hat er Zeit und Mühe investiert und beim Erfolg, hat er lediglich die Rechte eines z.B. eines Benutzers mit dem Konto. Damit kann er nicht viel anstellen. Der clevere Angreifer versucht sich nicht durch den Namen des Benutzerkontos in das System einzuschleichen (in dem Fall Administrator), sondern durch die SID (S-1-5-Domäne-512). Denn diese ist eindeutig. Der gewiefte Angreifer kennt die Zuordnung der SID genau und hat somit einen Ansatz, mit Tools wie User2Sid eine Brute Force Attacke durchzuführen. Wenn also z.B. der Benutzer "HansDampf" DER Domänen-Administrator ist, reicht es für den Ahnungslosen Angreifer aus, um ihn ins leere laufen zu lassen. Aber für die schweren Jungs, nicht im geringsten. Es ist eine weitere, wenn auch kleinere Hürde für den Angreifer. Du kannst das so machen, aber 100% verlassen solltest du dich natürlich nicht darauf. Das verstehe ich nicht, was meinst du damit?

Aloha, ja, dass ist es. Genau so sieht es nämlich aus. Genau aus den bereits hier in dem Thread genannten Gründen und die von dir aufgeführten Punkten, macht es Sinn den Exchange auf einer separaten Maschine laufen zu lassen. Dieser sollte eben kein DC sein. Technisch ist das zwar möglich, wird aber eben von seitens Microsoft nicht supportet.

Servus, dann lass diesen neu erstellen. Führe dazu diesen Artikel aus. Das Stichwort lautet, den Wert im Schlüssel BURFLAGS setzen. How to rebuild the SYSVOL tree and its content in a domain

Da kannst du dir nicht sicher sein. Einer der Anwender kann doch - und wenn es nur aus versehen ist - den Haken für die Veschlüsselugn gesetzt haben und im Fall der Fälle - sind die Daten verloren. Du könntest höchstens für die Zukunft das EFS komplett deaktivieren. Das musst du überprüfen, automatisch wird das aber nicht passieren.. Deine FLZ wird sich sicherlich im AD befinden. Demzufolge brauchst du nach dem demoten lediglich die DNS-Einträge händisch zu entfernen (z.B. NS-Eintrag). Der Rest erledigt sich automatisch während dem demoten. Ein NETDOM QUERY /FSMO zeigt dir den Träger der FSMO-Rollen. Oder: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Wenn du den zweiten Link durchgelesen hast, ist an alles gedacht.

Servus Edgar, nein, dass erübrigt sich nicht. Im Gegenteil, eine Weiterleitung wäre einzurichten. Die Root-Server reagieren oftmals langsamer als die DNS-Server des ISPs. Eben nicht. Ein Forwarder wäre zu empfehlen.

Das musst du mir bitte genauer erklären. Wie bist du genau vorgegangen um das herauszufinden?

Servus, wenn dieser der erste DC der Domäne war, sichere das EFS-Zertifikat. Was muss ich tun, um den ersten DC zu deinstallieren? - faq-o-matic.net Ansonsten gilt es noch die Dienste zu übernehmen wie z.B. DHCP/WINS sowie DNS (das sollte ohnehin auf jedem DC installiert werden). Ab Windows Server 2003 werden zwar die FSMO-Rollen während dem demoten automatisch verschoben, dieses würde ich aber selbst durchführen, um einfach diesen Schritt bewußt zu tätigen und damit man auch weiß, auf welchem DC die FSMO-Rollen verschoben worden sind. Aus der DHCP-Autorisierung solltest du den DC ebefalls entfernen, sofern auf dem DC der DHCP installiert war. Nach dem herunterstufen gehe das DNS durch und kontrolliere ob der DC dort als Nameserver ausgetragen wurde und falls nicht, lösche ihn händisch. Das gleiche gilt für WINS. Dann entferne noch nach dem demoten die Hülle des DCs im Snap-In "Standorte und Dienste". Die Daten sind natürlich zu übernehmen, sowie Drucker. Für alles weitere kannst du dich an diesen Artikel halten Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen