dmetzger

Beratung ist auch Wissenstransfer, was grundsätzlich nichts schadet. Man kann nicht immer ausschliesslich von sich selbst lernen. Ich masse mir an, wirklich sehr viel zu bestimmten Themen zu wissen. Trotzem ziehe ich für grössere Projekte immer wieder spezialisierte Berater hinzu, weil sie in mir weniger vertrauten Bereichen mehr Erfahrung haben oder um die eigenen Ideen einem Belastungstest zu unterziehen. Das ist für die Kunden gut, weil wir schneller, besser und kostengünstiger das Ziel erreichen, während wir uns weiteres Wissen aneignen können (aber nicht auf Kosten der Kunden). Wir sind ja ausschliesslich dem Wohl des Kunden verpflichtet. Noch bin ich keinem begegnet, der alles über alles weiss.

Du beschaffst Dir am besten ein kommerzielles SSL-Zertifikat, dem Dein ActiveSync-Handy "automatisch" vertraut. StartCom Free SSL Certification Authority StartSSL? Certificates & Public Key Infrastructure Securing an Exchange 2007 Client Access Server using a 3rd party SAN Certificate

Ja, ist es. Je nach Bezugsquelle lässt sich auf das benötigte Installationsmedium schliessen. Das wollen wir alle, das ist nichts Neues. Du hast MSDN-Installationsmedien genannt. Ich möchte Dich darauf hinweisen, dass diese nicht für produktive Instanzen genutzt werden dürfen, auch und vor allem nicht in staatlichen Institutionen. Falls der Eindruck entsteht, Du oder Dein Kunde wollten sich nicht an bindende Bestimmungen halten, wirst Du für diesen Fall mit hoher Wahrscheinlichkeit keine weitere Unterstützung erhalten. Ich gehe aber davon aus, dass es nichts zu verbergen gibt und Du die Frage gerne beantwortest, damit Dr.Melzer gewohnt kompetent helfen kann.

@Magicpeter: http://www.mcseboard.de/rules.php#nr7

Vor allem dauert das Einrichten weit weniger lang, als wir jetzt schon darüber geschwatzt und dabei zweimal auf die gleiche Information verwiesen haben.

Google ist hilfreich. You Had Me At EHLO... : Allowing application servers to relay off Exchange Server 2007

Ist ja interessant, eine richtige Pointe! :D Meines Wissens hat MS selbst eine einfachere Struktur ohne eigene Domäne pro Standort, sondern bloss regional, wobei Redmond eine eigene Region ist. :) Deshalb erstaunt mich, dass München eine solche AD-Struktur empfiehlt, auch weil es ausreichend viele publizierte und interne AD Design Guides von MS gibt, in denen das Gegenteil nachzulesen ist.

Das ist halt Pech und wird in Zukunft irgendwann als Altlast und Problem erkannt werden. Aber dann ist der schlaue Kopf nicht mehr da oder alle anderen sind schuld. Also: subdomäne.emea.firma.com, und das rund 30 Mal? :confused: Wenn ja, weiss Euer schlauer Kopf etwas, was wir nicht wissen und MS wahrscheinlich ebenfalls nicht. Ihr sollt diese Migration in einer Woche durchziehen? :shock: Insgesamt meine ich, dass dieses Szenario den Rahmen womöglich übersteigt, den dieses Forum an Hilfestellung leisten kann oder soll (persönlice Meinung!). Eine solche Aufgabe sollte durch Migrationsspezialisten vor Ort und während ausreichender Zeit begleitet werden. Edit: Nils ist unabhängig von mir zum gleichen Schluss gekommen, während ich hier diesen Beitrag geschrieben habe. Das weist darauf hin, dass diese Einschätzung möglicherweise zutrifft. (Auch weil wir solche komplexen Szenarien als bezahlte Spezialisten begleiten und ich für meinen Teil es gegenüber Auftraggebern kaum begründen könnte, dass ich dieses spezialisierte Wissen an anderer Stelle verschenke.)

Genau, so ist es. faq-o-matic.net 4 GB RAM mit Windows Vista

Guten Morgen Im Süden ist es kalt in den Minusgraden. Gut, darf man beim Kunden im Warmen sitzen und Postfächer verschieben. Noch eine oder zwei Stunden, dann kommt endlich die Familie auf die Kosten, mit Schlitteln am Hausberg. Habt Spass! Daniel

Guten Morgen Nahemoth Vielleicht beschäftigst Du Dich trotzdem bei Zeit und Gelegenheit mit den Migrationsszenarien, um für einen späteren Fall bestens vorbereitet zu sein. Ein Stichwort ist ADMT.: Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains Ein weiterer Vorschlag ist ein zweiter Domänencontroller als Absicherung für den Fall, dass einer aussteigt - wenn nur einer vorhanden ist, stehst Du sonst ohne Domäne da.

Darf ich wissen, weshalb nicht Windows Server 2008 oder 2008 R2?

Ja,ja, ja, Du hast Recht. Das machen wir beide zwar im Schlaf, doch der Präzision wegen ist es dem TO gegenüber notwendig, diesen Punkt zu ergänzen. Nein, bleib noch ein bisschen. Du warst Diese Woche viel zu wenig hier. :cry: Off-Topic:Yusuf, ich erwische mich schon dabei, bei jedem Beitrag zu überlegen, wie Du ihn wohl formulieren würdest. Diese Challenge macht mir Spass im kollegialen Sinn!

Lass AD Replikation die eigene Topologie bestimmen, das funktioniert meistens viel besser als manuelle Konfigurationen, vor allem im kleinen Umfeld wie bei Dir. Dafür gibts ja den ISTG pro Standort. Einer der wichtigen Vortiel ist, dass Du in diesem Fall keine speziellen Konfigurationen dokumentieren und später beachten musst, wenn z.B. physische Standortverbindungen geändert werden und/oder neue hinzukommen. In der dssite.msc musst Du im Grund nur Standorte erstellen, die Subnetze eintragen und den Standorten zuordnen sowie das Intersite-Replikationsintervall von standardmässig 180 Minuten ggf. verkürzen (Minimum ist 15 Minuten).

Das ist das Hauptargument der anderen Fraktion. :) Wie erwähnt, es handelt sich um eine ebenfalls valide Konfiguration. (Wir unsererseits gehen von zuverlässigen WAN-Anbindungen aus. ;)) Hier findest Du ein paar "offizielle" Gedanken (auch mit den Nachteilen der von mir genannten Konfiguration): Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003 Ja natürlich, das regelst Du mit dem DHCP. Clients sollen möglichst nahe gelegene DNS-Server abfragen.

Prinzipiell ja.

Die folgenden Threads enthalten reichlich Informationen: http://www.mcseboard.de/windows-server-forum-78/domain-controller-umbenennen-170887.html http://www.mcseboard.de/active-directory-forum-79/netbios-name-nachtraeglich-aendern-170910.html

Du hast selbstverständlich das Recht, Deine eigenen Erfahrung zu machen. Wir haben sie schon. ;)

Wiederspruch. Die beiden DNS am Hauptstandort zeigen kreuzweise primär auf den jeweils anderen Server am Hauptstandort und sekundär auf sich selbst. (Falls es weitere DNS-Server am Hauptstandort gibt, zeigen diese primär und sekundär in jeweils identischer Konfiguration ebenfalls auf die beiden "Chef-DNS-Server".) Die DNS-Server in den Aussenstellen zeigen jeweils primär auf den einen DNS-Server am Hauptstandort und sekundär auf den zweiten DNS-Server am Hauptstandort, wobei diese Konfiguration für alle DNS-Server an den Aussenstandorten die gleiche ist. Hauptargument hier ist die maximale Vereinfachung von Konfigurationen. Das ist die 1:1 Best Practice gelehrt in Redmond. :) Es gibt allerdings zur Konfiguration der Aussenstandorte auch die Fraktion, die gemäss dem zitierten Auszug aus dem oben geposteten Link vorgeht. Deren Argumentation ist grundsätzlich ebenfalls valid.

ms-DS-BehaviorVersion 2 = Windows Server 2003. Du musst die Gesamtstruktur- und Domänen-Funktionsebene heraufstufen. ms-DS-Behavior-Version Attribute (Windows) Ich rate aber grundsätzlich von einer Domänenumbenennung ab, auch wenn die Funktion vorhanden ist. Besser ist die Migration in eine neue Domäne, auch weil Exchange Server mit Ausnahme der Version 2003 SP2 das Umbenennen von Domänen nicht unterstützt und es viele Applikationen gibt, die mit einer Umbenennung ebenfalls nicht umgehen können.

Wurden die Nutzer aus einer anderen Exchange-Organisation migriert? Das Problem lässt sich einfach lösen: Bei User B Outlook öffnen, eine beliebige Stellvertretung eintragen, übernehmen, neue Stellvertretung wieder löschen, übernehmen. Das sollte es dann gewesen sein.

@MuMichel: Du kannst die SIDHistory migrieren, nicht aber die SID. Werden Objekte in eine andere Domäne migrieren, erhalten sie eine neue SID: SID-History Attribute (Windows) Mich würde es noch immer interessieren, aus welchem Grund man eine einfache Infrastruktur in eine komplexe überführt. Wir haben gelernt: Alles Geniale ist einfach. Es muss also gute Beweggründe geben, davon abzuweichen, nur hast Du sie bisher nicht genannt.

Wenn ich fragen darf: Aus welchem Grund?

Und wenn die Anforderungen definiert sind, d.h. auch tatsächlich DCs an den Aussenstandorten erforderlich sind (z.B. langsame WAN-Verbindungen, lokale Instanzen einer Exchange-Organisation, zahlreiche Benutzer), dann noch folgender Gedanke: Ein zusätzlicher schreibbarer DC an Stelle eines RODCs an mindestens einem Aussenstandort ist auch eine Sicherheit für den Fall, dass der Hauptstandort mit den sonst einzigen schreibbaren DCs abbrennt.

Schade. Habe ich bereits getan: die öffentliche Website getrennt auf einem Webserver in einer DMZ betreiben oder für wenig Geld zu einem Website-Hoster auslagern. Aber Du bist offenbar resistent und möchtest das nicht hören. Und ich möchte keine technische Hilfestellung zu einer Konfiguration geben, von der ich abrate. Viel Glück.