dmetzger

Das ursprüngliche EFS-Zertifikat ist selbstsigniert und kann nicht verlängert, sondern muss ersetzt werden. Falls keine interne Zertifizierungsstelle (CA) zur Verfügung steht, kannst Du mittels "cipher /r" ein neues Zertifikat erstellen und der EFS-Richtlinie in der Standard-Domänenrichtlinie zuordnen (Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Richtlinien öffentlicher Schlüssel -> Verschlüsselndes Dateisystem). z.B. "cipher /r:c:\cert" -> erstellt eine .cer- und eine .pfx-Datei. Wenn Ihr regelmässig mit EFS arbeitet, empfehle ich die Einrichtung einer internen CA zur Ausstellung von EFS-Zertifikaten. Wann wurde der Server installiert? Unter W2K3 lief das selbstsignierte EFS-Zertifikat nach 3 Jahren ab, unter W2K8 R2 (Neuinstallation Gesamtstruktur, nicht Migration) scheinen es nun 100 Jahre zu sein.

Zurück zur Ursprungsfrage: Verstehe ich korrekt, dass es um die Wiederherstellung auf einem neuen Servergerät geht, da das alte ausgefallen/nicht mehr verfügbar ist?

Hauptsache, es läuft wieder:)

Sind das die Server- oder die Bereichsoptionen? Und was sagt er zur Option 006 "DNS-Server"?

Klasse C genügt. Wie lauten die IP des SBS und des Routers, und wie lautet der DHCP-Adressbereich für die Clients inkl. Optionen (Gateway, DNS)?

Assistent nochmals ausführen und Subnetzmaske zurück auf 255.255.0.0 setzen. Offenbar ist der SBS jetzt ausserhalb des Bereichs, den die Clients erkennen.

Kannst Du nachstehenden CMD-Befehl absetzen und das Ergebnis publizieren? "setspn -l WIN-F5FUUFJ1OAU" (ohne Anführungszeichen; WIN-F5FUUFJ1OAU scheint der zufällig generierte Computername Deines DCs zu sein) Ebenso solltest Du abklären, ob der Domänencontroller das Recht zum Eintragen von SPNs (Service Principal Name) hat. Das geht wie folgt: -> dsa.msc -> Ansicht -> Erweiterte Features -> OU "Domain Controllers" -> Rechtsklick auf "WIN-F5FUUFJ1OAU" (Computerobjekt Deines Domänencontrollers" -> Reiter "Sicherheit" -> "Erweitert". In diesem Fenster sollte der Eintrag "SELF -> "Bestätigtes Schreiben an Dienstprinzipal (nicht geerbt)" mit der Berechtigung "Zulassen" enthalten sein. Ändere den IP-Eintrag Deines DCs dahingehend, dass 192.168.2.100 auch der primäre DNS-Eintrag ist (Host 127.0.0.1 ersetzen). Anschliessend "ipconfig /registerdns" ausführen und Netlogon-Dienst neu starten. Was ist das Ergebnis?

Möglicherweise eine externe oder die IP des Standard-Gateways? Internet scheint ja zu funktionieren, aber das grundsätzliche interne DNS-Elend ist hier manifestiert:

Existieren die domänenlokalen Sicherheitsgruppen "DHCP-Administratoren" und "DHCP-Benutzer"?

Wenn es bloss 10 Freigaben sind, kannst Du diese auf die temporären Server manuell anlegen und die untergeordneten Ordner inkl. Berechtigungen mittels robocopy kopieren. Ein zweiter Weg ist das Anlegen von DFS-Namensräumen (die Zweigstellen-DCs haben ja bereits W2K3 R2) und die Replikation der Freigaben auf zuerst die temporären und anschliessend die neuen permanenten Server. DFSN (falls nicht bereits vorhanden) empfiehlt sich ohnehin an Stelle von UNC-Pfaden, da zukünftige Migrationen/Ausbauten für die Nutzer absolut transparent verlaufen und Du z.B. Laufwerkszuordnungen per Skript oder GPO Preferences nicht ändern musst. Falls Du mit dem Gedanken spielst, mittels Acronis Images der DCs zu erstellen und diese in Betrieb zu nehmen, solltest Du zuerst hier lesen: How to detect and recover from a USN rollback in Windows Server 2003 Du kannst mittels Registry-Schlüssel "Database restored from Backup" das zwangsweise Herunterstufen und anschliessende Heraufstufen mittels dcpromo umgehen. Der Schlüssel ist nicht offiziell in nicht-virtualisierten Umgebungen unterstützt und sollte ausschliesslich im Notfall als letzte Ausflucht angewendet werden. Der saubere Weg ist, je einen neuen Domänencontroller in den Zweigstellen einzurichten und die Freigaben zu migrieren. Falls die bisherige Hardware weiter verwendet werden muss/soll, migrierst Du je zweimal alt -> temporär -> neu. Ich würde keinen anderen Weg wählen, wärs mein Kunde.

Unter Hyper-V haben wir das jeweils so gelöst (müsste mit ESX und ESXi ebenfalls funktionieren): - virtuelle Floppy mit Antwortdatei erstellt; - Floppy und ISO des SBS-Installationsmediums mit der VM verbunden; - VM gestartet und durchlaufen lassen.

Das würde ich nun wirklich nicht tun. Ein Hyper-V-Host sollte mit wenigen Ausnahmen (RRAS) keine anderen Rollen und Funktionen ausführen. Wieso nicht eine zweite VM für den SQL Server des SBS 7? Nun bin ich kein Datenbankspezialist, aber mein Bauch sagt mir, dass der SQL vielleicht Schwierigkeiten macht, wenn beim Starten seiner Dienste kein DC seiner Domäne verfügbar ist. Kompetentere Personen in diesem Forum können bstimmt mehr dazu sagen.

Du hast selbstverständlich Recht, dass der Client immer einen DC findet, sofern Netzwerkkonnektivität zu mindestens einem DC besteht. Andererseits wissen wir, dass jeder DC generische SRV-Einträge in der _msdcs.<Domäne>-Zone registriert, falls nicht anders konfiguriert. Der DC, den unser herumirrender Client findet, kann demnach auch irgendwo am anderen Ende der Welt an einem untergeordneten Standort stehen, gefunden über die generischen SRV-Einträge. Die ursprüngliche Frage von Muffel bezieht sich darauf, einen Standard-DC für Clients festzulegen, die in einem nicht zugeordneten Subnetz aufstarten. Schränke ich die Registrierung generischer SRV-Einträge z.B. auf DCs ein, die in gut vernetzten Standorten (vorzugsweise Hubs) stehen, wird sich unser Client mit diesen verbinden statt mit irgendeinem DC in irgendeiner Nebenstelle. Ist das so nachvollziehbar? Und selbstverständlich gibt es auch AutoSiteCoverage für Standorte ohne DCs. Ich denke aber, dass das hier nicht das Thema ist, sondern wir von einem nicht fertig konfigurierten Standort (lokales Subnetz nicht zugeordnet) ausgehen und nur einfach mal verhindern wollen, dass unser Client sich unkontrolliert mit irgendeinem DC irgendwo auf der Welt einlässt:wink2: Auch wenn es ggf. nicht EIN Standard-DC ist, sondern mehrere, aber kontrolliert an bestimmten Standorten. Ganz bestimmt ist aber die von NilsK gestellte Umgebungsfrage nach der logischen und physischen Toplogie respektive die Antworten ausschlaggebend, welches Verfahren das geeignete ist. In grösseren Umgebungen mit vielen Standorten ist die Einschränkung der Registrierung generischer SRV-Einträge üblich und nötig. Bei zwi oder drei Standorten mit schnellen WAN-Verbindungen lohnt sich der Aufwand nicht. Am einfachsten ist es, wie Muffel vermutet, die Standorte sauber mit zugeordneten Subnetzen zu konfigurieren. Dann hätten wir aber nicht diese nette Unterhaltung:)

Ein verbreiteter Ansatz für grössere Umgebungen (viele Standorte mit und ohne DCs) findet sich hier: How to optimize the location of a domain controller or global catalog that resides outside of a client's site "To Configure Domain Controllers or global catalogs to Not Register Generic Records"

Aber auch da wollen wir nach bestem Wissen und Gewissen schaffen;) 5000 Beiträge und stets wertvoll - Gratuliere!

Ich würde das nicht tun, es sei denn, Du hast einen weiteren physischen DC (oder einen weiteren virtuellen auf einem anderen Host), der bereits verfügbar ist, wenn Du den neuen Host startest. Im anderen Fall: - kann der Host beim Starten keine Computerrichtlinien der Domäne lesen, da kein Domänencontroller verfügbar ist; - kann es Anmeldeprobleme mit Domänenkonten geben, da beim Anmelden kein Anmeldeserver verfügbar ist; - erfolgt die Erstanmeldung am Host nach jedem Neustart mit NTLM statt Kerberos, weïl kein KDC verfügbar ist (How the Kerberos Version 5 Authentication Protocol Works - kann der DCLocator auf dem Host beim Starten die Informationen über den nächsten Standort nicht aktualisieren (DsGetDCName), etc. etc. Falls der Hintergrund Deiner Überlegung z.B. der ist, dass Du zentrale Dienste der Domäne wie KMS oder AV etc. nutzen willst, gäbe s auch die Lösung, das DNS-Suffix der Domäne im Netzwerkadapter des Hosts einzutragen -> "DNS Suffix für diese Verbindung" und den Host als alleinstehenden Server zu belassen. Du kannst in den Eigenschaften der VM das Startverhalten festlegen. Dazu ist kein Powershell-Script nötig. Je nachdem starten die VMs nicht, sofort oder verzögert nach dem Start des Hosts.

Vielleicht sind Deine Informationen nicht ausreichend, um sich aus der Ferne ein klares Bild zu verschaffen? Eine Frage ist z.B., ob die DCs am zweiten Standort gewöhnliche schreibare DCs oder RODCs sind. RODCs der Version W2K8 R1 lassen Schreibzugriffe auf den Netlogon-Ordner zu, aber diese Änderungen werden nicht auf schreibbare Domänencontroller repliziert, da diese einem RODC grundsätzlich nicht vertrauen und mit diesen nur unidirektional ausgehend replizieren (davon ausgehend, dass alle schreibbaren DCs mindestens W2K3 SP1/SP2 mit dem RODC Compatibility Pack sind). Nebst Dcpromo kann man den Sysvol mittels Registry-Eintrag authoritativ oder nicht authoritativ wiederherstellen - Schlüssel setzen und DFSR-Dienst neu starten: Registry Keys and Values for Backup and Restore (Windows) Ich meine aber aus der Ferne zu ahnen, dass Dir dieser Registry-Schlüssel in diesem Fall nicht helfen wird, da die Sysvol-Replikation offenbar von Beginn an auf mehreren Geräten am zweiten Standort nicht funktioniert oder funktioniert hat. Es liegt an Dir, Deine Umgebung möglichst detailiert zu dokumentieren, damit Dir evt. geholfen werden kann.

Das meine ich ebenfalls - 1 Forest, mehrere bis zahlreiche Domänen. Den Szenarien liegt zu Grunde, dass die Domänenpartitionen nicht repliziert werden sollen oder können.

Mir fallen verschiedene Szenarien ein, in denen Multidomänen-Umgebungen unumgänglich sind. Stichworte sind Marine- und Kreuzfahrtschiffe, Bohrinseln (SMTP-Replikation!) und Unternehmen mit mehreren Exchange-Organisationen (mehrere Gesamtstrukturen). Auch Risikokapitalgeber benötigen oft mehrere Domänen oder Gesamtstrukturen (Zugriff auf zentrale Mittel, einfaches Spin-off).

- Wie werden die Profilordner repliziert (DFSR?) - Wie sind die Profilpfade in den Benutzer-Kontoeigenschaften eingetragen (UNC\DFS)?

Salü miteinander Ich suche Leute aus der Schweiz, die entweder den Small Business Server 2008 oder den Essential Business Server 2008 als Vorabversionen bereits bei Schweizer Kunden installiert haben. Ich möchte gerne die Erfahrungen solcher Kunden für einen Bericht in der Schweizer "Computerworld" sammeln. Mir sind beide Systeme bekannt, da ich über Microsoft Connect als Beta-Tester teilgenommen habe, nur kenne ich bisher keine Firma, die den EBS oder SBS 2008 bereits evaluieren. Vielen Dank für die Unterstützung!

Habe ich dann auch gemerkt... Aber irgendwie ist er in meiner Liste aufgetaucht?

Vielelicht sind die System Recovery 7.0 von Symantec eine Lösung? Die erstellen fortlaufend Images vom SBS, die unter VMware und Virtual Server lauffähig sind. Damit kannst Du im Notfall eine virtuelle Kopie des SBS auf einem anderen Servergerät laufen lassen, bis das Original wieder zur Verfügung steht. Echtes Failover ist das nicht, aber es verkürzt Ausfallzeiten erheblich und rettet einen einigermassen aktuellen Datenbestand. Nachteile: Du brauchst natürlich einen zweiten Server, auf den das SBS-Image gesichert wird, und der für einen virtualisierten SBS-Betrieb vorbereitet ist. Dieser Server muss leistungsmässig den virtuellen SBS verkraften können. Ausserdem brauchst Du die SBS-Version von Backup Exec System Recovery 7.0, die auch was kostet.

Es gibt keine Redundanz mit einem SBS, da er sich nicht clustern lässt. Zweimal Exchange nutzt da auch nichts, weil jedes Postfach nur auf je einem Exchange Server sein wird. Werden die Postfächer gleichmässig verteilt, verliert bei einem Serverausfall schön immer die Hälfte der Nutzer die Verbindung zum eigenen Postfach. Wie das Systemhaus da Redundanz erkennen will, ist mir schleierhaft.

Auf der zuvor erwähnten Webseite von Microsoft findest Du die wichtigsten Informationen und Antworten auf Deine Fragen in einem Abschnitt: "Microsoft-Volumenlizenzkunden können Lizenzen für die öffentliche IM-Konnektivität für Live Communications Server 2005 für die vorhandenen Live Communications Server-Benutzer bestellen. Lizenzen für öffentliche IM-Verbindungen sind als Abonnement pro Benutzer und pro Monat erhältlich und stellen einen Zusatz zur Live Communications Server-CAL (Client Access License) dar." Du musst also Volumenlizenzkunde sein, sonst gibt es keine öffentliche Anbindung. Du kannst den LCS dann noch immer einrichten, allerdings nur als geschlossenes System innerhalb des Betriebs. Andererseits lohnt sich die beschäftigung mit dem LCS in Hinsicht auf sein Nachfolgeprodukt Office Communications Server 2007, das in verbindung mit Exchange Server 2007 bestehende Telefonzentralen ablösen und durch VoIP mit Office-Integration ersetzt (und mit Live Meeting 2007 grosse Webkonferenzen ermöglicht). In Deinem Fall würde ich mit dem Windows Live Messenger beginnen und einige Wochen oder Monate Erfahrungen sammeln, wie sehr er als Werkzeug gebraucht (missbraucht) wird. Falls Du gute Erfahrungen machst, wäre der nächste Schritt, die Kosten und den Nutzen einer Migration zu LCS festzustellen und diese je nachdem vorzunehmen.