Falls die Active Directory-Datenbank (NTDS.DIT) einen Schaden haben oder Inkonsistent sein sollte, kann man diese versuchen zu reparieren.
Dazu geht man folgendermaßen vor:

• Zuerst muss der Domänencontroller unter Windows 2000 sowie Windows Server 2003 im Modus Verzeichnisdienstwiederherstellung (Windows-Domänencontroller) gestartet werden.
  Auf das Auswahl-Menü gelangt man, wenn man im Bootvorgang des DCs die F8-Taste drückt. Die Anmeldung erfolgt dabei mit dem "Kennwort für den Wiederherstellungsmodus" das beim Heraufstufen des DCs vergeben wurde.
  
  
• Ab Windows Server 2008 ist es nicht zwingend notwendig den DC im Modus Verzeichnisdienstwiederherstellung zu starten, denn es kann im laufenden Betrieb der Dienst Active Directory-Domänendienste (AD-DS) samt den abhängigen Diensten Dateireplikationsdienst, Kerberos-Schlüsselverteilungsdienst, Standortübergreifender Messagingdienst und DNS-Server angehalten werden. Dazu ist entweder in der Dienstesteuerung (services.msc) der Dienst Active Directory-Domänendienste oder in der Kommandozeile mit net stop ntds anzuhalten.
  
  
• Danach gilt es unter START-AUSFÜHREN oder aus der Kommandozeile heraus, dass NTDSUTIL aufzurufen.
  Ab Windows Server 2008 muss nach dem Starten von NTDSUTIL anschließend die Active Directory-Instanz aktiviert werden. Dieses ist mit dem Befehl activate instance ntds möglich.
  
  
• In der NTDSUTIL-Kommandozeile gibt man FILES ein, um in die File-Maintenance Eingabeaufforderung zu gelangen.
  
  
• Zuerst sollte ein Integritätstest der NTDS.DIT mit dem Befehl Integrity durchgeführt werden. Falls nach dem Test Fehler angezeigt werden, könnte man mit NTDSUTIL versuchen diese zu beheben. Nach dem Integritätstest wird ein Protokoll im Verzeichnis "%windir%\ntds\ntds.integ.raw" erstellt, in dem Informationen zum Gesundheitszustand der AD-Datenbank enthalten sind.
  
  

• Mit "q" (oder quit) gilt es die File-Maintenance Ebene zu verlassen, um in die NTDSUTIL Ebene zu gelangen.
  
  
• Hier gilt es den Befehl SEMANTIC DATABASE ANALYSIS einzugeben, damit man in die "Semantic Checker" Ebene gelangt.
  
  
• Dort angelangt, aktiviert man mit dem Parameter VERBOSE ON die Option, um detaillierte Informationen zu erhalten.
  
  
• Als nächstes gibt man den Befehl GO FIXUP ein, um eine Reparatur über die NTDS.DIT laufen zu lassen. Anschließend wird zum einen in der Kommandozeile eine Zusammenfassung angezeigt und zum anderen wird ein Protokoll im Verzeichnis "C:\dsdit.dmp.0" mit ausführlichen Informationen erstellt.
  

• Anschließend verlässt man mit zweimaliger Eingabe von "q" die Kommandozeile und startet den Domänencontroller im normalen Modus neu.
  Ab Windows Server 2008 startet man den Dienst Active Directory-Domänendienste in der Dienstesteuerung oder in der Kommandozeile mit net start ntds.

Nach dem Neustart des DCs, gilt es die Funktionsfähigkeit der NTDS.DIT zu überprüfen.
Sollten immer noch Probleme existieren, können mit den Windows Support Tools DCDIAG [1] und NetDIAG, weiteres Troubleshooting betrieben werden. Falls auch dieses nicht zum Erfolg führt, sollte die Active Directory-Datenbank aus einer System State Sicherung wiederhergestellt und nach dem Restore, die Konsistenz der Datenbank überprüft werden.

Weitere Informationen:

[1] Domänencontroller mit DCDIAG prüfen
DCDiag and NetDiag in Windows 2000 Facilitate Domain Join and DC Creation

Es kommt immer wieder auch heute noch vor, dass Administratoren in den TCP/IP-Einstellungen ihrer Domänencontroller die das DNS installiert haben, als "Ersten DNS"-Server ihn selbst eintragen, aber mit der Localhost-Adresse 127.0.0.1. Dort sollte die "echte" IP-Adresse eingetragen werden, nicht zuletzt wegen:
RAS Clients Receive 127.0.0.1 for DNS Server Address 

Trägt man den DC selbst als ersten DNS-Server ein, können bei einem Neustart die bekannten Fehlermeldungen mit der Fehler-ID: 4000, 4004, 4015 ...usw. in der Ereignisanzeige auftauchen, da dass DNS starten möchte, es aber nicht kann weil dass Active Directory noch nicht geladen wurde bzw. bereit ist.

Weiterhin könnte es unter Windows 2000 zu gravierenden Fehlern kommen, das Microsoft als DNS Server becomes an island [1] bezeichnet.
Dieser Fall kann eintreten, wenn als „Bevorzugter DNS-Server“ oder „Alternativer DNS-Server“ der Domänencontroller selbst eingetragen wird.
Stattdessen empfiehlt Microsoft, als primären DC/DNS-Server den allerersten DC/DNS-Server in der Gesamtstruktur und als sekundären,
einen anderen DC/DNS-Server einzutragen.

Daher habe ich die möglichen DNS-Server Einstellungen hier mal aufgeführt:

• Gängige Praxis ist auch die "Überkreuz" Einstellung. Existieren zwei DCs in der Domäne, so trägt man jeweils den anderen DC als "Bevorzugter DNS-Server" in den TCP/IP-Einstellungen des DCs ein und sich selbst dann als zweiten.
• Einziger DC/DNS: Diesen trägt man selbst mit seiner echten IP (kein Localhost) ein. Es gibt ja bloß diesen einen.
• Mehrere DCs/DNS: Wenn man einen zweiten DC/DNS installiert, trägt man in den TCP/IP Einstellungen einen bestehenden (i.d.R. den ersten
  DC/DNS) als "Bevorzugter DNS-Server" ein und erst wenn die Replikation stattgefunden hat, stellt man diesen wenn gewünscht um.
• Man kann unter Windows Server 2003 jeden DC als DNS-Server installieren, wo jeder sich selbst als ersten und einzigsten DNS-Server eingetragen hat.
• Man setzt alle DCs auf den ersten installierten DC/DNS, der der einzige zentrale DNS Server ist und bleibt.
• Eine Kombination wäre, als ersten DNS trägt man einen "zentralen" DNS ein um z.B. bei einem Serverstart den typischen Fehlern aus dem Weg zu gehen, wo DNS loslegen möchte, aber der Verzeichnisdienst noch nicht geladen/bereit ist - und als zweiten trägt man ihn selbst ein.

Die Empfehlung geht unter Windows Server 2003 dahin, einen zentralen/anderen DC/DNS-Server als ersten DNS-Server in den TCP/IP-Einstellungen und den DC/DNS-Server selbst, als sekundären DNS-Server einzutragen.
Inseleffekt vermeiden

Weitere Informationen:
[1] DNS Server becomes an island when a domain controller points to itself for the _msdcs.ForestDnsName domain
Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003

Seit Windows 2000 gibt es nicht mehr die beiden Funktionen BDC (Backup Domain Controller) sowie PDC (Primary Domain Controller), die es zu Zeiten von NT gab. Damals konnten Änderungen nur auf dem PDC ausgeführt werden (Single Master Replikation). Das Active Directory (AD) ab Windows 2000 verhält sich grundlegend anders als Windows NT 4.0-Domänen, denn eine Unterscheidung (ob BDC oder PDC) gibt es in einer Active Directory-Domäne nicht mehr. Vielmehr sind alle Domänencontroller (DC) einer Active Directory-Domäne (fast) gleichberechtigt. Somit können in einer AD-Domäne die Änderungen an Attributen und Objekten die auf einem DC getätigt wurden, unter allen DCs mitgeteilt, sprich repliziert werden (Multimaster-Replikation).  

Nun gibt es Situationen, in denen eine ausschließliche Multimaster-Replikation eher zu Konflikten führen würde.
Das betrifft beispielsweise eine Active Directory-Schema Erweiterung, die aus Gründen der Konsistenz lediglich von einem einzigen Domänencontroller ausgeführt werden sollten (nämlich dem DC, der die Rolle des Schemamasters innehat). Daher findet beim Active Directory zusätzlich zur Multimaster-Replikation für die Verzeichnispartition bzw. Namenskontexte für bestimmte Aufgaben, ein Einzelmaster-Betrieb statt. Denn für spezielle Aufgaben, darf nur ein einziger DC entweder in der Domäne oder Gesamtstruktur, diese ausführen. Aus diesem Grund spricht Microsoft auch von „Flexible Single Master Operations“, kurz FSMO.

Ab Windows 2000 kamen fünf Betriebsmaster hinzu, die eine besondere Rolle in einer Domäne/Gesamtstruktur einnehmen.
Die fünf FSMO-Rollen wären:

1. Schemamaster (existiert nur einmal pro Gesamtstruktur)
2. Domänennamenmaster (existiert nur einmal pro Gesamtstruktur)
3. RID-Master (Relative ID) (existiert nur einmal pro Domäne)
4. PDC-Emulator (existiert nur einmal pro Domäne)
5. Infrastrukturmaster (existiert nur einmal pro Domäne)
6. Des Weiteren existiert je eine Infrastrukturmasterrolle pro Anwendungsverzeichnispartition, wie es z.B. ab Windows Server 2003 die ForestDNSZones und DomainDNSZones darstellt.

Es gibt Vorgaben, was die Aufteilung der FSMO-Rollen auf einem oder mehreren DCs betrifft:

1. Der Schemamaster sowie Domänennamenmaster sollten zusammen auf einem DC liegen (und dieser sollte auch ein GC sein).
2. Der RID-Master sowie PDC-Emulator sollten ebenfalls auf dem gleichen DC liegen.
3. Wenn mehrere Domänen in einer Gesamtstruktur existieren, darf der Infrastrukturmaster einer Domäne, nicht auf einem DC liegen, der auch die Funktion des globalen Katalogs (GC=Global Catalog) trägt, es sei denn, man deklariert jeden DC dieser Domäne zum GC.
   

   Genauer gesagt, es muß jeder DC einer Domäne auch GC sein, wenn der Infrastrukturmaster dieser Domäne auf einem GC liegt.
   Unabhängig davon, wieviele DCs in anderen Domänen der Gesamtstruktur existieren.
   

   Wenn allerdings jeder Domänencontroller einer Domäne, der Bestandteil einer Gesamtstruktur mit mehreren Domänen ist, auch den globalen Katalog enthält, gibt es keine Arbeit für den Infrastrukturmaster. Der Infrastrukturmaster kann auf einen beliebigen Domänencontroller in dieser Domäne gestellt werden.
   
   Oder wenn die Umgebung aus einem Single-Domänen Forest besteht, dann spielt es auch keine Rolle, ob der DC auf dem der Infrastrukturmaster liegt ebenfalls auch globaler Katalog ist oder nicht.
   
   Der Infrastrukturmaster, der globale Katalog und der AD-Papierkorb

   FSMO placement and optimization on Active Directory domain controllers
   
   
   

4. Ansonsten wird auf dem Infrastrukturmaster auf dem der GC aktiviert ist, ständig die EventID 1419 protokolliert.
   Dieser Fehler wird nur dann behoben, wenn der Infrastrukturmaster auf einen DC verschoben wird der kein GC ist oder der GC
   auf einem DC aktiviert wird, der nicht die Rolle des Infrastrukturmasters innehat. Der Fehler wird auch dann nicht mehr
   protokolliert, wenn auf jedem DC einer Domäne (sei es ein Single-Domänen oder Multi-Domänen Forest) der GC aktiviert wurde.
   
   Event ID 1419 Generated on a Domain Controller

    

5. In 99% der Umgebungen ist es empfehlenswert, alle Rollen auf einem DC zu halten.

Man kann alle Rollen auf einen anderen DC im laufenden Betrieb, ohne das die Benutzer dadurch beeinträchtigt werden geschweige denn davon etwas mitbekommen, seit Windows 2000 entweder über die grafische Oberfläche oder in der Kommandozeile mit NTDSUTIL verschieben. Mittels der MMCs lassen sich die FSMO-Rollen in den Snap-Ins Active Directory-Schema, Active Directory-Domänen- und -Vertrauensstellungen sowie Active Directory-Benutzer und -Computer übertragen.

Die Rollen werden aber auch automatisch während dem Herunterstufen des Rolleninhabers auf einen anderen DC übertragen.

Die FSMO-Rollen mit DCPROMO verschieben

Tipp: Es ist empfehlenswert das Übertragen der Rollen in der grafischen Oberfläche direkt von dem zukünftigen Rolleninhaber durchzuführen. Somit ist es nicht notwendig weder in den MMCs noch mit NTDSUTIL zuerst eine Verbindung zum Ziel-DC herzustellen und es sind vor allem weniger "Schritte" notwendig.

Die Besonderheit der Infrastrukturmasterrolle ab Windows Server 2003

Es gibt ab Windows Server 2003 eine Besonderheit was die Rolle des Infrastrukturmasters anbetrifft. Denn mit Windows Server 2003 wurden Anwendungsverzeichnispartitionen eingeführt, wie z.B. im DNS die ForestDNSZones und DomainDNSZones. Ab Windows Server 2003 existiert nämlich zusätzlich je ein Infrastrukturmaster pro Anwendungsverzeichnispartition (1 Infrastrukturmaster für ForestDNSZones und je ein Infrastrukturmaster pro DomainDNSZones).

Das bedeutet für eine Gesamtstruktur mit zehn Domänen in der lediglich die Standard-Anwendungsverzeichnispartition (im DNS) genutzt werden, folgende Aufteilung der FSMO-Rollen:

1. Ein Schemamaster
2. Ein Domänennamenmaster
3. Zehn RID-Master (Relative ID)
4. Zehn PDC-Emulatoren
5. Zehn Infrastrukturmaster für die Domänen bzw. Domänenpartitionen
6. Ein Infrastrukturmaster für die Anwendungsverzeichnispartition "ForestDNSZones"
7. Zehn Infrastrukturmaster für die Anwendungsverzeichnispartition "DomainDNSZones"

Es existieren also insgesamt 21 Infrastrukturmaster in der Gesamtstruktur. Leider werden aber die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen beim Übertragen (Rolleninhaber ist online) auf einen anderen DC weder über die GUI noch über NTDSUTIL (NTDSUTIL - Transfer) mit "verschoben". Diese müssen zusätzlich noch händisch auf einen anderen DC übertragen werden. Auch beim übernehmen (Rolleninhaber ist offline, z.B. DC-Crash) der FSMO-Rollen auf einen anderen DC, müssen zusätzlich die Infrastrukturmaster der Anwendungsverzeichnispartitionen händisch übernommen werden.

Die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen "ForestDNSZones und "DomainDNSZones" lassen sich wie folgt auf einen anderen DC verschieben:

1. Unter Windows 2000 und Windows Server 2003 gilt es zuerst die Windows Support Tools (auf der Server-CD im Verzeichnis Support\Tools) zu installieren.
2. Danach startet man das ADSIEdit, was ab Windows Server 2008 bereits "on Bord" ist.
3. Im ADSIEdit wählt man mit einem Rechtsklick auf den Eintrag "ADSI Edit" die Option "Connect to..." aus.
4. Im darauffolgenden Fenster "Connection Settings" ist im Bereich "Connection Point" die Option "Select or type a Distinguished Name or Naming Context" auszuwählen.
5. In dem Feld trägt man dann den Distinguished Name (DN) der entsprechenden Anwendungsverzeichnispartition ein, um sich mit dieser Verzeichnispartition zu verbinden. Im Fall der "ForestDNSZones" würde der DN so lauten:
   DC=ForestDNSZones,DC=Root-Domäne,DC=TLD
6. Anschließend verbindet man sich noch mit den einzelnen (je nach Anzahl der Domänen) "DomainDNSZones" Partitionen. Der DN lautet wie folgt:
   DC=DomainDNSZones,DC=Domäne,DC=TLD
7. Wenn man nun im ADSIEdit auf der linken Seite die einzelnen Verzeichnispartitionen mit denen man sich verbunden hat erweitert, findet man auf der rechten Seite das Objekt CN=Infrastructure. Mit einem Rechtsklick auf dieses Objekt ruft man die Eigenschaften des Objekts auf und ändert dort den Wert im Attribut fSMORoleOwner.
8. Der Wert im Attribut sieht z.B. so aus:
   CN=NTDS Settings,CN=DCON01,CN=Servers,CN=<Standort>,CN=Sites,CN=Configuration,DC=intra,DC=dikmenoglu,DC=de

Existieren evtl. noch selbst erstellte Anwendungsverzeichnispartitionen, so müssen die Infrastrukturmasterrollen dieser Vezeichnispartitionen ebenfalls auf einen anderen DC verschoben werden, wenn der Ursprungsrollenträger aus der Domäne entfernt werden soll oder nicht mehr zur Verfügung steht.

Der folgende Befehl kann dazu verwendet werden, die Verzeichnispartitionen die in der Gesamtstruktur existieren sich anzeigen zu lassen:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne -attr ncname

Möchte man sich lediglich die Anwendungsverzeichnispartitionen die in der Gesamtstruktur existieren anzeigen lassen, so ist das mit diesem Befehl möglich:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne -filter (systemflags=5) -attr ncname

Die Infrastrukturmasterrollen der jeweiligen DomainDNSZones-Partition lässt sich wie folgt herausfinden:
Dsquery * CN=Infrastructure,DC=DomainDNSZones,DC=<die jeweilige Domäne>,DC=TLD -attr fSMORoleOwner

Siehe auch:
Die Infrastrukturmaster der Anwendungsverzeichnispartitionen


 

Den Schemamaster in der grafischen Oberfläche online übertragen

Die Rolle des Schemamasters kann innerhalb einer Gesamtstruktur, auf jeden DC egal aus welcher Domäne übertragen werden. Um die Rolle des Schemamasters vom ursprünglichen auf einen anderen Domänencontroller über die grafische Oberfläche zu übertragen, muss zuerst das Schema Snap-In registriert werden. Dazu geht man auf „Start-Ausführen“ und gibt dort folgenden Befehl ein regsvr32 schmmgmt.dll. Danach lässt sich das Schema Snap-In in einer MMC hinzufügen. Das Schema Snap-In erscheint nicht unter „Start-Programme-Verwaltung“ wie die bereits existierenden AD-Snap-Ins.

Die genaue Vorgehensweise ist wie folgt, wozu Schema-Admins Rechte benötigt werden:

1. Unter Start-Ausführen öffnet man mit der Eingabe von MMC eine leere MMC-Konsole.
   
   
2. In der MMC klickt man auf Datei - Snap-In hinzufügen/entfernen...
   
   
3. Unterhalb von Verfügbare Snap-Ins: wählt man das Snap-In Active Directory-Schema aus und klickt auf die Schaltläche Hinzufügen und anschließend auf OK.
   
   
4. Auf dem ursprünglichen Rolleninhaber gilt es mit einem Rechtsklick auf Active Directory-Schema [FQDN] im Kontextmenü den Eintrag Active Directory-Domänencontroller ändern... auszuwählen.
   
   
5. Es muss der DC ausgewählt werden, auf dem die Schemamasterrolle übertragen werden soll.
   
   Hinweis: Führt man das übertragen der Schemamasterrolle gleich auf dem zukünftigen Rolleninhaber durch, so ist das verbinden zum Ziel-DC nicht notwendig da man sich bereits auf diesem befindet.
   
   
6. Mit einem erneuten Rechtsklick auf Active Directory-Schema [FQDN] muss diesmal im Kontextmenü der Eintrag Betriebsmaster... ausgewählt werden.
   
   
7. Im Dialogfenster Schemamaster ändern klickt man auf die Schaltfläche Ändern und bestätigt die nachfolgende Abfrage mit Ja.
   
   
8. Die fehlerfreie Übertragung auf den Ziel-DC ist mit OK zu bestätigen.
   
   
9. Zum Schluss schließt man mit einem Klick auf Schließen das Dialogfenster Schemamaster ändern.

Den Domänennamenmaster in der grafischen Oberfläche online übertragen

Die Rolle des Domänennamenmasters kann innerhalb einer Gesamtstruktur, auf jeden DC egal aus welcher Domäne übertragen werden. Die Rolle des Domänennamenmasters lässt sich vom ursprünlglichen auf einen anderen DC in der MMC Active Directory-Domänen und -Vertrauensstellungen mit Organisations-Admins Rechten übertragen.
Die einzelnen Schritte wären folgende:

1. Zuerst ruft man das Snap-In Active Directory-Domänen und -Vertrauensstellungen unter Start-Programme-Verwaltung auf.
   
   
2. Auf dem ursprünglichen Rolleninhaber gilt es mit einem Rechtsklick auf den Eintrag Active Directory-Domänen und -Vertrauensstellungen [FQDN] die Option Domänencontroller ändern... auszuwählen.
   
   
3. Nun muss der DC ausgewählt werden, auf den die Betriebsmasterrolle übertragen werden soll.
   
   Hinweis: Führt man das übertragen der Domänennamenmasterrolle gleich auf dem zukünftigen Rolleninhaber durch, so ist das verbinden zum Ziel-DC nicht notwendig da man sich bereits auf diesem befindet.
   
   
4. Dann ist mit einem Rechtsklick auf den Eintrag Active Directory-Domänen und -Vertrauensstellungen [FQDN] der Eintrag Betriebsmaster... auszuwählen.
   
   
5. Im Dialogfenster Betriebsmaster wird mit einem Klick auf Ändern und bestätigen der nachfolgenden Abfrage mit Ja die Domänennamenmasterrolle auf den angegebenen DC übertragen. 
   
   
6. Mit OK ist die fehlerfreie Übertragung auf den Ziel-DC zu bestätigen.
   
   
7. Zum Schluss schließt man mit einem Klick auf Schließen das Dialogfenster Betriebsmaster.

Wo befinden sich die FSMO-Rollen?

Auf welchem DC die FSMO-Rollen liegen, kann man sich recht einfach mit dem Kommandozeilen-Befehl NETDOM (aus den Windows Support Tools) anzeigen lassen.
Der Befehl dazu lautet: NETDOM QUERY FSMO.

Die etwas aufwändigere Abfrage wäre mit DSQUERY:

dsquery server -hasfsmo schema
dsquery server -hasfsmo name
dsquery server -hasfsmo rid
dsquery server -hasfsmo pdc
dsquery server -hasfsmo infr

Oder mit DCDIAG: DCDIAG /Test:Knowsofroleholders /v


Wer diese Informationen gerne über die grafische Oberfläche erfahren möchte, der kann sich dazu die Windows Support Tools installieren und startet anschließend unter Windows 2000 und Windows Server 2003 das REPLMON. Im nächsten Schritt verbindet man sich mit einem DC und wählt mit einem Rechtsklick auf den NetBIOS-Namen des DCs, die Option Properties aus. Im Reiter FSMO Roles bekommt an dann die oder den Träger der FSMO-Rollen zu sehen.

Weitere Informationen:
Die FSMO-Rollen mit der AD-Powershell verschieben
Reagieren auf Betriebsmasterausfälle
How Operations Masters Work
How To Find Servers That Hold Flexible Single Master Operations Roles
How to view and transfer FSMO roles in Windows Server 2003
How to view and transfer FSMO roles in the graphical user interface
Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
How to Find the FSMO Role Owners Using ADSI and WSH

Auf der Seite von Mark Heitbrink http://www.gruppenrichtlinien.de habe ich über die Scripte, die mit der Installation der GPMC mitinstalliert werden, einen Artikel geschrieben.

Ich erläutere, für was die jeweiligen Scripte zu gebrauchen sind.

Hier der Link zum Artikel:

http://www.gruppenrichtlinien.de/index.html?/Scripting/scripte_der_gpmc.htm

Yusuf

Der Small Business Server hat folgende Merkmale:

1. Der SBS erzeugt seine eigene Root - Domäne
2. Ein SBS kann in eine bereits bestehende Active Directory Domäne integriert werden,
   muss dann allerdings zum einen alle FSMO - Rollen übertragen bekommen und zum anderen, muss der globale Katalog (GC) auf dem SBS aktiviert werden:
   How to install Small Business Server 2003 in an existing Active Directory domain
3. Es können keine Anbindungen bzw. Vertrauensstellungen zu anderen Domänen aufgebaut werden
4. Es ist nicht möglich Subdomänen zu erstellen
5. Es können keine 2 SBS in einer Domäne existieren, falls ein weiterer Server z.B. Domänencontroller wegen Redundanz nötig
   ist, dann kann es ein Windows Server 2000/2003 Standard Edition sein oder höher
6. Alle Server-Applikationen müssen auf einem SBS laufen und können nicht getrennt installiert werden wie z.B. den Exchange Server auf
   eine andere Maschine
7. Es sind keine Terminalservices vorhanden, nur Remote Desktop
8. Ein Terminal Server ist nur als zusätzlicher Memberserver möglich, dann allerdings sind weitere Terminal Services CALs nötig
9. Weitere Server können in eine SBS Domäne integriert werden (DCs oder Memberserver)
10. Beim SBS ist es empfehlenswert die Assistenten zu nutzen um etwas zu konfigurieren bzw. einzurichten und ist nicht zu vergleichen wie
    die Standard-Edition
11. Es sind maximal 75 Anwender bzw. Clients in einer SBS Domäne möglich