dmetzger

@Daim: :wink2: @Kornholic: Existiert der Ordner c:\windows\sysvol auf dem Domänencontroller, und was sind seine Inhalte? Falls der Ordner existiert: Existieren ein Unterordner c:\windows\sysvol\sysvol und darin eine Verzweigung <DOMÄNE>, und ist dieser Unterordner freigegeben als \\<DOMÄNE>\sysvol ?

Gerne geschehen. Und danke vielmals für Deine Rückmeldung im Forum.

Eine autoritative Wiederherstellung von AD hätte dies behoben, vorausgesetzt es existieren aktuelle Sicherungen. Die Exchange-Datenbanken lassen sich selbstverständlich wiederherstellen, entweder aus Sicherungen oder ggf. aus den lokalen Dateien. Welche Schritte in welcher Reihenfolge vorzunehmen sind/vorgenommen werden können, ist aus der Ferne jedoch schwer zu beantworten. Du hast offenbar verschiedene Dinge selbst probiert bis hin zur Neuinstallation des neuen Exchange Server 2010 SP1. Ich lese daraus (und möchte Dir nicht zu nahe treten): - Du kennst die Verfahren nicht zur Bearbeitung der AD-Datenbank und ggf. deren Wiederherstellung; - Du kennst die Verfahren zur Notfallbehandlung von Exchange Server 2010 nicht; - Du scheinst mit der aktuellen Situation überfordert. Mein Ratschlag ist, Dir eine externe Fachperson zur Behebung der aktuellen Notfallsituation zu suchen. Diese Person kann vor Ort die Umgebung analysieren und feststellen, welche Daten und Informationen vorhanden sind und ggf. zur Behebung genutzt werden können. Du kannst diese Verfahren später in einer nichtproduktiven Umgebung anwenden und üben, um für zukünftige Probleme an Sicherheit zu gewinnen. Mir scheint es zu riskant, wenn Du unter grossem Druck den Zustand alleine zu reparieren versuchst.

Das ist ohne Virtualisierung ebenfalls möglich. Persönliche Ansicht im Wissen, dass es verschiedene mit jeweils guten Argumenten gibt: - Servervirtualisierung ja, sofern ein virtualisierter Server nicht mehr als 50% der physischen Resourcen eines Hosts beansprucht (How Microsoft IT does it); wir virtualisieren Server täglich und in erheblichem Ausmass. Abhängig vom Kundenumfeld, Domänencontroller in der Regel physisch abhängig von der Last (Benutzerzahl, Topologie etc.). - Softwarevirtualisierung teils, um z.B. Inkompatibilitäten mit Betriebssystem der Clients aufzufangen (Applikationen, die unter Win7 nicht laufen) oder ggf. verschiedene Versionen auf den Clients einsetzen zu können (z.B. MS Access 2007 lokal installiert, MS Access 2010 virtualisiert). Wir virtualisieren Software nicht durchgehend, weil es schick ist, sondern berücksichtigen die Topologie und Netzwerkinfrastruktur ebenso wie die Leistung der Clients und Serverumgebung. - Desktopvirtualisierung für einfache Arbeitsumgebungen, nicht aber für Arbeitsplätze mit z.B. CAD und/oder Programmierung. Abhängig ebenfalls von Topologie, Netzwerkinfrastrukturund Leistung der Clients und Serverumgebung.

Hat er mit diesen beiden Zeilen eigentlich schon. Warten wir mal ab, was er zu den Sysvol- und Netlogon-Freigaben meldet, ehe wir mit D2/D4 beginnen:)

@Daim: Kann ich hier zuerst fertig machen? Es sind bisher die typischen Symptome eines FRS-Problems mit Burflags-Lösung. Er kann ja auch den Domänennamen-Master nicht erreichen (siehe Zitat in Deinem Beitrag oben), keinen GC, keinen KDC etc.

Genau. Also nochmals: Kannst Du die Sysvol- und Netlogon-Freigaben mittels \\<DOMÄNE>\sysvol respektive \\<DOMÄNE>\netlogon erfolgreich aufrufen? Ich gehe im Moment davon aus, dass Du kein Problem mit der PDC-Rolle hast, sondern mit dem File Replication Service (FRS), möchte aber aus der Ferne sicher sein, ehe ich dich auf den Reparaturweg verweise.

Sind die Sysvol- und Netlogon-Freigaben auf dem einzigen DC vorhanden? Primär und sekundär gibt es bei Active Directory nicht; alle sind Master.

Ist es der einzige DC in dieser Domäne? Wie lautet die gesamte Fehlermeldung, kommen darin auch weitere Passagen vor wie: "Warning: DcGetDcName(GC_SERVER_REQUIRED) call failed, error 1717 A Global Catalog Server could not be located - All GC's are down." Das könnte dann auf Probleme mit dem Netlogon-Dienst hinweisen.

Der einfachste Weg, nichts zu vergessen, ist die Installation mit Hilfe der Standardskripte im Ordner "scripts" auf dem Installationsmedium. In diesem Fall einer Standardinstallation von Exchange Server 2010 lautet die Eingabe im CMD-Fenster aus dem genannten Verzeichnis: "servermanagercmd -ip Exchange-Typical.xml" Da es ein W2K8R2 ist, wird er kurz anmerken, dass servermanagercmd in zukünftigen Versionen nicht mehr unterstützt werden wird, danach aber die Voraussetzungen für Hub Transport, Mailbox Server und CAS installieren. Der RPC-über-HTTP-Proxy gehört dazu:) Im "scripts"-Verzeichnis finden sich weitere Skripte für rollenbasierte Installationen und Verwaltungsaufgaben.

Wurden die Routinggruppen-Konnektoren zur und von der "Erste Administrative Gruppe" des SBS 2003/Exchange Server 2003 während der Migration entfernt? Mit ADSIedit kannst Du in der AD-Datenbank nachschlagen, ob die Gruppe noch eingetragen ist und sie ggf. entfernen. Der Pfad ist in der Fehlermeldung genannt: "CN=erste administrative gruppe,CN=Administrative Groups,CN=DOMAINNAME,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DOMAINNAME,DC=local"

Die Virtualisierungsumgebung wird vom Hyper-V-Host zur Verfügung gestellt, nicht vom SAN. Insofern ist auch dieser Punkt ein K.O.-Kriterium.

Das ist nicht durchgehend korrekt. Ein Standard-Gateway ist der Zugang zu allen anderen Subnetzen, die nicht das eigene sind oder für die nicht explizit andere Gateways zugewiesen sind. Ein Subnetz kann mehrere Gateways in benachbarte Subnetze haben, falls die eigene Umgebung mehrere Subnetze/Zonen umfasst. Für diese Subnetze müssen je nach Topologie ebenfalls Gateways definiert und statisch oder dynamisch zugewiesen werden. Statisch z.B. "route add -p 192.168.90.0 mask 255.255.255.128 192.168.7.1" Will heissen: Der Weg ins Subnetz 192.168.90.0/25 führt aus unserem Beispiel-Subnetz (z.B. 192.168.7.0/24) über den Gateway 192.168.7.1, der natürlich in unserem eigenen Subnetz sein muss. Genau wie ein Zimmer (Subnetz) mit mehreren Türen (Gateways), die in bestimmte andere Zimmer führen - und möglicherweise weitere Zimmer dahinter -, während nur eine Tür (Standard-Gateway) zur Aussenwelt öffnet. (Wobei der Standard-Gateway nicht zwingend immer unmittelbar benachbart ins Internet führt.) Dynamisch zugewiesen werden solche Gateways per DHCP in W2K3 mittel Option 249 und ab W2K8 mittels Option 121. Ist das nicht eine schöne Thematik für den Sonntag?

- Domänencontroller deaktivieren die "disk write caching"-Funktion auf allen Volumen mit AD-Daten, um die AD-Datenbank zu schützen. Dies beeinflusst wiederum die Leistung des Hyper-V-Host negativ. Things to consider when you host Active Directory domain controllers in virtual hosting environments - Das Failover-Clustering von Domänencontrollern ist nicht supported (aus einleuchenden Gründen -> Replikation, verteilte Datenbank). Du kannst somit kein Failover-Clustering von Hyper-V-Hosts machen, die gleichzeitig Domänencontroller sind. Windows 2000, Windows Server 2003, and Windows Server 2008 cluster nodes as domain controllers

Oder direkt den/die DNS-Server des ISP. Wenn nichts eingetragen wird, erfolgt beim Windows Server 2003 die Namensauflösung standardmässig per Rootserver-Einträge. Es erfolgt somit immer eine Namensauflösung für Internetadressen. @DrHoschi: Du unterliegst hier einem Grundlagenirrtum. Die Informationen von Zahni sind korrekt.

Nur wenn der primäre DNS-Server nicht verfügbar ist.

Genau. Da würde ich die Energie reinstecken. Sonst führt das Basteln womöglich halbwegs zum Ziel und könnte jemanden veranlassen, den geplanten Umbau für unnötig zu erklären.

Es handelt sich gemäss Deiner Aussage um ein Abbild der physischen Maschine mittels VMware Converter. Wenn die _msdcs-Zone der physischen Maschine in Ordnung ist, muss am Abbild manipuliert worden sein; VMware Converter hat mit Sicherheit die Zone nicht geändert. Du kannst die _msdcs-Zone neu mit allen SRV-Einträgen erstellen. 1. bestehende _msdcs-Zone löschen; 2. eine neue Zone _msdcs.<DOMÄNE> erstellen, AD-integriert, gesamtstrukturweite Replikation; 3. Netlogon Dienst beenden und neu starten; 4. prüfen, ob die _msdcs-Zone vollständig neu angelegt wurde. Du solltest u.a. auch die ObjectGUID des Domänencontrollers pingen können ("ping 23dec5e0-68f2-45b8-8718-93815ddf73af"). Anschliessend mit "netdom query fsmo" feststellen, welche FSMO-Rollen dem SBS zugeordnet sind und ggf. die Zuordnung erzwingen: Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller In der .local-Zone alle Einträge des offenbar unbekannten DCs fusixp01 löschen (Nameserver, Host).

Wie viele Alias-Einträge (CNAME) hast Du im Stamm der Zone _msdcs.dp-ef.local, wie lauten sie und auf welche FQDN verweisen sie? Hat der physische SBS das gleiche Problem?

Wie hast Du ihn in eine VM gezogen?

Zahni hat Recht. Trotzdem interessiert mich, wie viele DCs in der SBS-Domäne sind.

Ich habe die Verknüpfungen zu den Dokumenten eigentlich nicht in der Absicht gepostet, Ideen zu liefern, wie in dieser AD/DNS-Topologie mittels Workarounds ein weitgehend problemfreier Betrieb mit funktionierender interner Namensauflösung erreicht werden kann. Ich wollte vielmehr einen Anstoss und Informationen liefern, sich mit den grundlegenden Architektur von Windows-Domänen/AD/DNS zu beschäftigen, die bestehende Topologie zu überdenken und sie neu so zu bauen, wie sie gebaut sein sollte, nämlich als 1 Gesamtstruktur/1 Domäne mit zwei Standorten. Alles andere ist Basteln.

Diese Massnahmen kosten weniger als geschäftliche E-Mails, die nicht bei den Empfängern ankommen:rolleyes:

Und beantragt beim ISP einen Reverse-DNS-Eintrag.

Das ist nicht richtig. Du kannst maximal 75 Nodes einbinden, darunter auch weitere Domänencontroller. Diese Frage wurde hier im Board im Zusammenhang mit dem SBS 2003 bereits geklärt und ist auch so dokumentiert: Debunking Myths About Additional Domain Controllers In SBS Domains - The Official SBS Blog - Site Home - TechNet Blogs Der SBS ist definitiv gebaut, um DC einer Stammdomäne am Stamm des Namensraums zu sein. Sonst gibts Probleme - aber das siehts Du selbst. Hinweise und Stichworte zu Deinen Auflösungsproblemen findest Du u.a.: Gesamtstrukturübergreifendes Routing von Namensuffixen Konfigurieren von DNS-Clienteinstellungen War es schon damals bestimmt nicht.